| Message ID | c6d2ae3913582947c046d577a9dbf6dc8629909a.1700746611.git.pidge@baylibre.com |
|---|---|
| State | New |
| Headers | show |
| Series | useradd improvements | expand |
On Thu, 2023-11-23 at 13:49 +0000, Eilís 'pidge' Ní Fhlannagáin wrote: > [YOCTO #13419] > > If recipeB creates a user and assigns it to a group created in recipeA, > we need to ensure two things: > > That recipeA is in recipeB's DEPENDS (documentation issue) and that the > sysroot setscene, in the case of a TMPDIR wipeout, is in > USERADDSETSCENEDEPS. > > RP and I discussed adding a USERADD_DEPENDS variable to deal with this, > but there is some magic around DEPENDS that a new variable wouldn't have > so I'm sending this as is for people to poke at. Can you be more specific about this "magic"? I'm still worrying that DEPENDS is too broad, there are many more things in there which we don't want listed as setscene dependencies and I think this needs to be more precise. Cheers, Richard
On 23/11/2023 14:11, Richard Purdie wrote: > On Thu, 2023-11-23 at 13:49 +0000, Eilís 'pidge' Ní Fhlannagáin wrote: >> [YOCTO #13419] >> >> If recipeB creates a user and assigns it to a group created in recipeA, >> we need to ensure two things: >> >> That recipeA is in recipeB's DEPENDS (documentation issue) and that the >> sysroot setscene, in the case of a TMPDIR wipeout, is in >> USERADDSETSCENEDEPS. >> >> RP and I discussed adding a USERADD_DEPENDS variable to deal with this, >> but there is some magic around DEPENDS that a new variable wouldn't have >> so I'm sending this as is for people to poke at. > > Can you be more specific about this "magic"? > > I'm still worrying that DEPENDS is too broad, there are many more > things in there which we don't want listed as setscene dependencies and > I think this needs to be more precise. > > Cheers, > > Richard The interesting thing here is if we do something like: python __anonymous() { setscenedeps = "" if "-native" not in d.getVar("PN") and d.getVar("USERADD_DEPENDS") is not None: for pkg in d.getVar("USERADD_DEPENDS").split(): setscenedeps += " %s:do_populate_sysroot_setscene " % pkg d.setVar("USERADDSETSCENEDEPS", "%s %s" % (d.getVar("USERADDSETSCENEDEPS"), setscenedeps)) } we end up throwing: ERROR: creategroup2-1.0-r0 do_prepare_recipe_sysroot: The sstate manifest for task 'creategroup1:populate_sysroot' (multilib variant '') could not be found. The pkgarchs considered were: qemux86_64, core2-64, x86_64, allarch, none_none-nativesdk. But none of these manifests exists: /home/pidge/poky/build/tmp/sstate-control/manifest-qemux86_64-creategroup1.populate_sysroot /home/pidge/poky/build/tmp/sstate-control/manifest-core2-64-creategroup1.populate_sysroot /home/pidge/poky/build/tmp/sstate-control/manifest-x86_64-creategroup1.populate_sysroot /home/pidge/poky/build/tmp/sstate-control/manifest-allarch-creategroup1.populate_sysroot /home/pidge/poky/build/tmp/sstate-control/manifest-none_none-nativesdk-creategroup1.populate_sysroot The weird thing (hence this being an RFC), is that the patch I sent doesn't throw this. At first, I thought it was something happening with a polluted sstate but I don't think so now. I am absolutely unsure as to why that would be, BUT my suspicion is that this error is related to 14961 (which I'm still poking at).
On 24/11/2023 14:10, Eilís 'pidge' Ní Fhlannagáin wrote: > On 23/11/2023 14:11, Richard Purdie wrote: >> On Thu, 2023-11-23 at 13:49 +0000, Eilís 'pidge' Ní Fhlannagáin wrote: >>> [YOCTO #13419] >>> >>> If recipeB creates a user and assigns it to a group created in recipeA, >>> we need to ensure two things: >>> >>> That recipeA is in recipeB's DEPENDS (documentation issue) and that the >>> sysroot setscene, in the case of a TMPDIR wipeout, is in >>> USERADDSETSCENEDEPS. >>> >>> RP and I discussed adding a USERADD_DEPENDS variable to deal with this, >>> but there is some magic around DEPENDS that a new variable wouldn't have >>> so I'm sending this as is for people to poke at. >> >> Can you be more specific about this "magic"? >> >> I'm still worrying that DEPENDS is too broad, there are many more >> things in there which we don't want listed as setscene dependencies and >> I think this needs to be more precise. >> >> Cheers, >> >> Richard > > The interesting thing here is if we do something like: > > python __anonymous() { > setscenedeps = "" > if "-native" not in d.getVar("PN") and d.getVar("USERADD_DEPENDS") > is not None: > for pkg in d.getVar("USERADD_DEPENDS").split(): > setscenedeps += " %s:do_populate_sysroot_setscene " % pkg > d.setVar("USERADDSETSCENEDEPS", "%s %s" % > (d.getVar("USERADDSETSCENEDEPS"), setscenedeps)) > } > > we end up throwing: > > ERROR: creategroup2-1.0-r0 do_prepare_recipe_sysroot: The sstate > manifest for task 'creategroup1:populate_sysroot' (multilib variant '') > could not be found. > The pkgarchs considered were: qemux86_64, core2-64, x86_64, allarch, > none_none-nativesdk. > But none of these manifests exists: > > /home/pidge/poky/build/tmp/sstate-control/manifest-qemux86_64-creategroup1.populate_sysroot > > /home/pidge/poky/build/tmp/sstate-control/manifest-core2-64-creategroup1.populate_sysroot > > /home/pidge/poky/build/tmp/sstate-control/manifest-x86_64-creategroup1.populate_sysroot > > /home/pidge/poky/build/tmp/sstate-control/manifest-allarch-creategroup1.populate_sysroot > > /home/pidge/poky/build/tmp/sstate-control/manifest-none_none-nativesdk-creategroup1.populate_sysroot > > The weird thing (hence this being an RFC), is that the patch I sent > doesn't throw this. At first, I thought it was something happening with > a polluted sstate but I don't think so now. I am absolutely unsure as to > why that would be, BUT my suspicion is that this error is related to > 14961 (which I'm still poking at). > I had a crack at this tonight. Interestingly enough, limiting the code "fixes" the issue, eg and allows us to use USERADD_DEPENDS: if "-native" not in d.getVar("PN") and d.getVar("USERADD_DEPENDS") is not None and d.getVar("BB_CURRENTTASK") == "package": I guess my question is why would it work with DEPENDS but fail with USERADD_DEPENDS unless we limited to do_package? (hence the magic I'm seeing). I'm still guessing this is something in staging.bbclass that is doing something funny.
On 25/11/2023 15:21, Eilís 'pidge' Ní Fhlannagáin wrote: > On 24/11/2023 14:10, Eilís 'pidge' Ní Fhlannagáin wrote: >> On 23/11/2023 14:11, Richard Purdie wrote: >>> On Thu, 2023-11-23 at 13:49 +0000, Eilís 'pidge' Ní Fhlannagáin wrote: >>>> [YOCTO #13419] >>>> >>>> If recipeB creates a user and assigns it to a group created in recipeA, >>>> we need to ensure two things: >>>> >>>> That recipeA is in recipeB's DEPENDS (documentation issue) and that the >>>> sysroot setscene, in the case of a TMPDIR wipeout, is in >>>> USERADDSETSCENEDEPS. >>>> >>>> RP and I discussed adding a USERADD_DEPENDS variable to deal with this, >>>> but there is some magic around DEPENDS that a new variable wouldn't >>>> have >>>> so I'm sending this as is for people to poke at. >>> >>> Can you be more specific about this "magic"? >>> >>> I'm still worrying that DEPENDS is too broad, there are many more >>> things in there which we don't want listed as setscene dependencies and >>> I think this needs to be more precise. >>> >>> Cheers, >>> >>> Richard >> >> The interesting thing here is if we do something like: >> >> python __anonymous() { >> setscenedeps = "" >> if "-native" not in d.getVar("PN") and >> d.getVar("USERADD_DEPENDS") is not None: >> for pkg in d.getVar("USERADD_DEPENDS").split(): >> setscenedeps += " %s:do_populate_sysroot_setscene " % pkg >> d.setVar("USERADDSETSCENEDEPS", "%s %s" % >> (d.getVar("USERADDSETSCENEDEPS"), setscenedeps)) >> } >> >> we end up throwing: >> >> ERROR: creategroup2-1.0-r0 do_prepare_recipe_sysroot: The sstate >> manifest for task 'creategroup1:populate_sysroot' (multilib variant >> '') could not be found. >> The pkgarchs considered were: qemux86_64, core2-64, x86_64, allarch, >> none_none-nativesdk. >> But none of these manifests exists: >> >> /home/pidge/poky/build/tmp/sstate-control/manifest-qemux86_64-creategroup1.populate_sysroot >> >> /home/pidge/poky/build/tmp/sstate-control/manifest-core2-64-creategroup1.populate_sysroot >> >> /home/pidge/poky/build/tmp/sstate-control/manifest-x86_64-creategroup1.populate_sysroot >> >> /home/pidge/poky/build/tmp/sstate-control/manifest-allarch-creategroup1.populate_sysroot >> >> /home/pidge/poky/build/tmp/sstate-control/manifest-none_none-nativesdk-creategroup1.populate_sysroot >> >> The weird thing (hence this being an RFC), is that the patch I sent >> doesn't throw this. At first, I thought it was something happening >> with a polluted sstate but I don't think so now. I am absolutely >> unsure as to why that would be, BUT my suspicion is that this error is >> related to 14961 (which I'm still poking at). >> > > I had a crack at this tonight. Interestingly enough, limiting the code > "fixes" the issue, eg and allows us to use USERADD_DEPENDS: > > if "-native" not in d.getVar("PN") and d.getVar("USERADD_DEPENDS") is > not None and d.getVar("BB_CURRENTTASK") == "package": > > I guess my question is why would it work with DEPENDS but fail with > USERADD_DEPENDS unless we limited to do_package? (hence the magic I'm > seeing). I'm still guessing this is something in staging.bbclass that is > doing something funny. > A bit more on this. The above is incorrect in that DEPENDS certainly is special in this context (I had inadvertently switched to 'bitbake -f -c package'). Not using the useradd patch works with -f -c (which makes sense) So initial patch works with either -f -c or -c Subsequent USERADD_DEPENDS code works with -f -c only. Which tells me that there is something special about basing the patch on DEPENDS which isn't doing what USERADD_DEPENDS is doing, which again points to something deep in staging. -e
diff --git a/meta/classes/useradd.bbclass b/meta/classes/useradd.bbclass index 4d3bd9a5f56..98c6999a0d2 100644 --- a/meta/classes/useradd.bbclass +++ b/meta/classes/useradd.bbclass @@ -177,6 +177,14 @@ SYSROOT_PREPROCESS_FUNCS += "${SYSROOTFUNC}" SSTATEPREINSTFUNCS:append:class-target = " useradd_sysroot_sstate" +python __anonymous() { + setscenedeps = "" + if "-native" not in d.getVar("PN"): + for pkg in d.getVar("DEPENDS").split(): + setscenedeps += " %s:do_populate_sysroot_setscene " % pkg + d.setVar("USERADDSETSCENEDEPS", "%s %s" % (d.getVar("USERADDSETSCENEDEPS"), setscenedeps)) +} + do_package_setscene[depends] += "${USERADDSETSCENEDEPS}" do_populate_sysroot_setscene[depends] += "${USERADDSETSCENEDEPS}" USERADDSETSCENEDEPS:class-target = "${MLPREFIX}base-passwd:do_populate_sysroot_setscene pseudo-native:do_populate_sysroot_setscene shadow-native:do_populate_sysroot_setscene ${MLPREFIX}shadow-sysroot:do_populate_sysroot_setscene"
[YOCTO #13419] If recipeB creates a user and assigns it to a group created in recipeA, we need to ensure two things: That recipeA is in recipeB's DEPENDS (documentation issue) and that the sysroot setscene, in the case of a TMPDIR wipeout, is in USERADDSETSCENEDEPS. RP and I discussed adding a USERADD_DEPENDS variable to deal with this, but there is some magic around DEPENDS that a new variable wouldn't have so I'm sending this as is for people to poke at. This commit should also fix issues seen in the following bugs: https://bugzilla.yoctoproject.org/show_bug.cgi?id=13279 https://bugzilla.yoctoproject.org/show_bug.cgi?id=13904 https://bugzilla.yoctoproject.org/show_bug.cgi?id=15084 Signed-off-by: Eilís 'pidge' Ní Fhlannagáin <pidge@baylibre.com> --- meta/classes/useradd.bbclass | 8 ++++++++ 1 file changed, 8 insertions(+)