Message ID | 20240418055843.547573-1-yocto@bsorensen.net |
---|---|
State | Accepted, archived |
Commit | fac654a5445da2603b3435aca8db33fc8411d51b |
Headers | show |
Series | systemd: sed ROOT_HOME only if sysusers PACKAGECONFIG is set | expand |
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
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