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
--
Eilís 'pidge' Ní Fhlannagáin
BayLibre - At the Heart of Embedded Linux
www.baylibre.com
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#191236):
https://lists.openembedded.org/g/openembedded-core/message/191236
Mute This Topic: https://lists.openembedded.org/mt/102766836/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
