systemd: sed ROOT_HOME only if sysusers PACKAGECONFIG is set

From: Christian Bräuner Sørensen <yocto@bsorensen.net>

Fixes a bug introducted in ebafe46379 systemd: upgrade to 255.1.

Besides updating systemd, that commit also made other changes. One of them
being when to perform the replacement in order to fix ROOT_HOME.

Previously, that happened on a configure prefunc and on
${S}/sysusers.d/basic.conf.in.
Now it happens in install and on image/usr/lib/sysusers.d/basic.conf.

However, that file is not present if sysusers is not in PACKAGECONFIG,
since that file in that case is not installed hence resulting in:
sed: can't read <redactedpath>/image/usr/lib/sysusers.d/basic.conf: No such file or directory

Previously, in the case of sysusers not being in PACKAGECONFIG, that was a
"silent error" since the replacement was done but the file was not really
used since the file was not installed.

Signed-off-by: Christian Bräuner Sørensen <yocto@bsorensen.net>
---
 meta/recipes-core/systemd/systemd_255.4.bb | 18 ++++++++++--------
 1 file changed, 10 insertions(+), 8 deletions(-)

Hi

Added CC's that signed off by on commit ebafe46379 systemd: upgrade to 
255.1.

On 4/18/24 07:58, yocto@bsorensen.net wrote:
> From: Christian Bräuner Sørensen<yocto@bsorensen.net>
>
> Fixes a bug introducted in ebafe46379 systemd: upgrade to 255.1.
>
> Besides updating systemd, that commit also made other changes. One of them
> being when to perform the replacement in order to fix ROOT_HOME.
>
> Previously, that happened on a configure prefunc and on
> ${S}/sysusers.d/basic.conf.in.
> Now it happens in install and on image/usr/lib/sysusers.d/basic.conf.
>
> However, that file is not present if sysusers is not in PACKAGECONFIG,
> since that file in that case is not installed hence resulting in:
> sed: can't read <redactedpath>/image/usr/lib/sysusers.d/basic.conf: No such file or directory
>
> Previously, in the case of sysusers not being in PACKAGECONFIG, that was a
> "silent error" since the replacement was done but the file was not really
> used since the file was not installed.
>
> Signed-off-by: Christian Bräuner Sørensen<yocto@bsorensen.net>
> ---
>   meta/recipes-core/systemd/systemd_255.4.bb | 18 ++++++++++--------
>   1 file changed, 10 insertions(+), 8 deletions(-)
>
> diff --git a/meta/recipes-core/systemd/systemd_255.4.bb b/meta/recipes-core/systemd/systemd_255.4.bb
> index e7498c802d..f58a1bc2b6 100644
> --- a/meta/recipes-core/systemd/systemd_255.4.bb
> +++ b/meta/recipes-core/systemd/systemd_255.4.bb
> @@ -271,14 +271,16 @@ WATCHDOG_TIMEOUT ??= "60"
>   
>   do_install() {
>   	meson_do_install
> -	# Change the root user's home directory in /lib/sysusers.d/basic.conf.
> -	# This is done merely for backward compatibility with previous systemd recipes.
> -	# systemd hardcodes root user's HOME to be "/root". Changing to use other values
> -	# may have unexpected runtime behaviors.
> -	if [ "${ROOT_HOME}" != "/root" ]; then
> -		bbwarn "Using ${ROOT_HOME} as root user's home directory is not fully supported by systemd"
> -		sed -i -e 's#/root#${ROOT_HOME}#g' ${D}${exec_prefix}/lib/sysusers.d/basic.conf
> -	fi
> +	if ${@bb.utils.contains('PACKAGECONFIG', 'sysusers', 'true', 'false', d)}; then
> +            # Change the root user's home directory in /lib/sysusers.d/basic.conf.
> +            # This is done merely for backward compatibility with previous systemd recipes.
> +            # systemd hardcodes root user's HOME to be "/root". Changing to use other values
> +            # may have unexpected runtime behaviors.
> +            if [ "${ROOT_HOME}" != "/root" ]; then
> +                    bbwarn "Using ${ROOT_HOME} as root user's home directory is not fully supported by systemd"
> +                    sed -i -e 's#/root#${ROOT_HOME}#g' ${D}${exec_prefix}/lib/sysusers.d/basic.conf
> +            fi
> +        fi
>   	install -d ${D}/${base_sbindir}
>   	if ${@bb.utils.contains('PACKAGECONFIG', 'serial-getty-generator', 'false', 'true', d)}; then
>   		# Provided by a separate recipe

Any input on the patchset ? Would appreciate if it could be included in 
the scarthgap release.

/Christian

On Wed, 24 Apr 2024 at 10:19, Christian B. Sørensen via
lists.openembedded.org <yocto=bsorensen.net@lists.openembedded.org>
wrote:

> Any input on the patchset ? Would appreciate if it could be included in the scarthgap release.

A little patience would help. The patch is fine (and so there's not
input), it's in a staging branch, but integration to master would
happen after scarthgap is out.

Alex

On 24/04/2024 10.36, Alexander Kanavin via lists.openembedded.org wrote:
> On Wed, 24 Apr 2024 at 10:19, Christian B. Sørensen via
> lists.openembedded.org <yocto=bsorensen.net@lists.openembedded.org>
> wrote:
> 
>> Any input on the patchset ? Would appreciate if it could be included in the scarthgap release.
> 
> A little patience would help. The patch is fine (and so there's not
> input), it's in a staging branch, 

How would one know? It's not in master-next, and I don't see any other
branches containing it. Is there some git repo other than
https://git.openembedded.org/openembedded-core/ one could follow to see
that a patch has actually been picked up? The complete radio silence
when submitting to oe-core makes it extremely hard to know if anybody
has even seen a given patch. Ideally, one would get an email
notification (not sent to the list), but just being able to peek at some
staging repo would help avoid "impatient" pings.

> but integration to master would happen after scarthgap is out.

So the plan is to release scarthgap with a known bug and a known fix for
it? Or are you saying this will go into the scarthgap branch before
release, and after that be applied to master?

Rasmus

On Wed, 2024-04-24 at 12:08 +0200, Rasmus Villemoes wrote:
> On 24/04/2024 10.36, Alexander Kanavin via lists.openembedded.org
> wrote:
> > On Wed, 24 Apr 2024 at 10:19, Christian B. Sørensen via
> > lists.openembedded.org <yocto=bsorensen.net@lists.openembedded.org>
> > wrote:
> > 
> > > Any input on the patchset ? Would appreciate if it could be
> > > included in the scarthgap release.
> > 
> > A little patience would help. The patch is fine (and so there's not
> > input), it's in a staging branch, 
> 
> How would one know? It's not in master-next, and I don't see any
> other branches containing it. Is there some git repo other than
> https://git.openembedded.org/openembedded-core/ one could follow to
> see that a patch has actually been picked up? The complete radio
> silence when submitting to oe-core makes it extremely hard to know if
> anybody has even seen a given patch. Ideally, one would get an email
> notification (not sent to the list), but just being able to peek at
> some staging repo would help avoid "impatient" pings.

It is in:

https://git.yoctoproject.org/poky-contrib/log/?h=abelloni/master-next

It has not made it to master-next. 

Your maintainer is doing their best but struggling to keep the release
going, fix the release blocking issues, handle 101 other things and try
to have a live outside the project too without going (any more) insane
or suffering burnout. Replying to every patch on the list isn't
something I can commit to.

We do have plans to allow patchtest to show which patches have been run
through the autobuilder or are contained on testing branches. Sadly
nobody has written that code yet.

> > but integration to master would happen after scarthgap is out.
> 
> So the plan is to release scarthgap with a known bug and a known fix
> for it? 

Yes, that is the plan.

At some point we have to draw a line under the release. It takes time
to put things through QA and to go through the release process so there
is a call to be made about whether it is severe enough of an issue to
stop that. In my view it isn't. You can make a case for why we should
stop the release if you do think that isn't right.

> Or are you saying this will go into the scarthgap branch before
> release, and after that be applied to master?

It needs to be tested against master, hopefully merge there, then it
will go through the stable release process for scarthgap.

I appreciate the processes are a pain at times but they do prevent or
handle a ton of other issues so overall they're a win in general.

Cheers,

Richard

On Wed, 24 Apr 2024 at 12:08, Rasmus Villemoes
<rasmus.villemoes@prevas.dk> wrote:
> How would one know? It's not in master-next, and I don't see any other
> branches containing it. Is there some git repo other than
> https://git.openembedded.org/openembedded-core/ one could follow to see
> that a patch has actually been picked up? The complete radio silence
> when submitting to oe-core makes it extremely hard to know if anybody
> has even seen a given patch. Ideally, one would get an email
> notification (not sent to the list), but just being able to peek at some
> staging repo would help avoid "impatient" pings.

It's a well known problem. Now please go to your manager and ask them
to let you spend time on such a notification system, and maintaining
it until further notice. And then tell us what they say.

Alex