Hello to Yocto community, As I am much more passive yocto wise these few years ( working on Android build systems and around, this is also a nightmare, I should say ;-) ), I have one Yocto question

One way I have gotten around this is by using an .inc file to create the users/groups and then the recipes that need the user/group require/include that .inc file.

wrote: Just to confirm, this is with master? I think there are some open bugs for useradd issues like this. It is supposed to work but sounds like there are races. If there isn't a bug open for it,

I just ran these tests in (32 bit) qemux86 on top of poky master (e.g. no magic glibc flags), and they all passed. Do they need to be ran after setting the date to the 'post-2038 future' to reveal the

Well, historically we used to have the OpenEmbedded Happy Hour after the sessions on the second day of the Yocto Project Summit and ask people to re-join a different Zoom room to socialize. This

That sounds interesting and something we should probably look into for both issues... That would cause runtime issues but not build time linking ones? Cheers, Richard

We can simply disable COMPAT_32BIT_TIME in the kernel config. -- Alexandre Belloni, co-owner and COO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com

Some time ago I filed https://bugzilla.yoctoproject.org/show_bug.cgi?id=6803 as Debian has a nice sanity check where it warns if non-LFS glibc functions are used. I imagine the same logic could be

<alex.kanavin@...> wrote: I have something like this on yoe/mut branch on contrib repo ( due to musl removing the LFS hacks). However there are packages which need to be fixed at build

Hi, I have intermittent problems with a recipe that creates a user that is member of groups that are created by a different recipe. This is the recipe that creates the groups: # recipe-a.bb inherit

Perhaps, yes. I'm meaning disabling the 32 bit glibc time functions. Right, but the 32 bit time functions/symbols are still available for older binaries. My point is that anything using those older

Hi Richard, Y2038 ptests maybe? Here is the list of integrated tests to ptests: https://github.com/lmajewski/y2038-tests Could you be more specific here? Would you like to disable

Others have made some good comments. My thoughts: * We need to add some runtime tests to oeqa for this (in addition to the ptests) * We need to have a 32 bit ptest run on the autobuilder (qemux86

I have a question here: If I something like below in my recipe SYSTEMD_SERVICE:${PN} = "${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 'one.service', '', d)}" Then, can I add multiple files

For x86, yes. For arm, it varies and I know at least one of our arm hosts doesn't support it, I don't know about the newer ones. In general I think it shouldn't be too bad but we really do need

"Alexander Kanavin" <alex.kanavin@...> wrote: +1 IIRC the MACH=qemux86 was working correctly... Maybe only subset of ptests - i.e. those related to Y2038 could be run? Best regards, Lukasz

Testing the rollover could be done in later stages. I can imagine we'll have enough just by setting the date in the future and getting those magic glibc flags to not cause build fails. Alex

<richard.purdie@...> wrote: I think kvm does allow 32 bit guest on a 64 bit host. But I can imagine making full ptests work on 32 bit guests would be a struggle for reasons unrelated

lists.openembedded.org wrote: What is the potential issue with builtools? To be clear, we don't run ptests on 32 bit targets, only on qemux86-64 and qemuarm64 where we have KVM available. We do run

"Stephen John Smoogen" <smooge@...> wrote: IIRC ptests for y2038 covers this problem in this exact way. Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing