Hi, I have a .inc file that contains this information: # Set the MACHINE string, expected to eventually replace the long list of # build settings below EXTRA_OECMAKE +=

As I explained in the bug I filed in your repository, the LICENSE statement is the license of the contents of the packages, not the recipe itself. https://github.com/mguentner/cannelloni clearly says

Martin, U R too fast. Speedy Gonzales. ;-) I do agree that this is the bad practice to change licences for the known recipes. For the can-utils and socketcand. I'll revert this back to GPLv2. But,

Ross, It is now broken even in hardknott. I tried it, just as I tried it before (it worked before). I have no idea what the ERROR is: zoran.s@NBK0005U:~/projects2/yocto/bbb-yocto/build$ bitbake

And here is another example why nobody should be using meta-socketcan: https://github.com/ZoranStojsavljevic/meta-socketcan/commit/cefd86cd1def9ad2e63be527f8ce36a076d7e17c# You cannot change the

The compatibility is because over time things change: override syntax has changed, classes get added or removed, functionality may appear in bitbake. Sometimes the breakage is subtle, and a layer may

That commit really is not in the spirit of things and I'm not happy people are doing that. I'd not be surprised if that stopped working soon. We had a huge problem with unmaintained layers where it

I think we should fix those and we should add the target to the autobuilder but I'm reluctant to add a long test to a-full. The fact it is relatively clean suggests it doesn't regress that often. We

<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