<richard.purdie@...> wrote: I just ran qemux86 full ptest locally. It took 4h:10m (same as qemuarm64 ptest on an arm worker). The fails were: {'python3': ['test_deterministic_sets'],

This is another: https://bugzilla.yoctoproject.org/show_bug.cgi?id=13419 Workarounds are not difficult, but the issue occurring for the first time must be very disorienting. Alex

And this is the commit that did this: https://git.phytec.de/meta-phytec/commit/conf/layer.conf?id=8261e896d2b43211e7377feb38e919336d47c39f Shame on you, phytec. Shame on you. What you do in your

Hi Alexander, Yes. You need to run them with adjusted date: date +'%Y-%m-%d %T' -s "2038-01-19 03:14:07" ptest-runner glibc-tests More

https://bugzilla.yoctoproject.org/show_bug.cgi?id=13904 is one of the bugs I think.

Agreed with Rudolf. If the layer maintainer didn't bother to do at least do one build with new release and adjust LAYERSERIES_COMPAT, then I don't consider that layer well maintained (it could be

To me this indicates that the maintainer of the layer has tested the compatibility of his layer with all of these releases of the Yocto Project. A maintainer of a layer should make a deliberate

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