Thanks Khem, can you please help explain or give an example of a package that is doing this? If we had separate output packages, are you suggesting we build 3 times- each time after applying a patch

In all cases, the problem is traced back to a Makefile, where something calls $(shell git ... ) to get a git version. I was able to find out because one shell had executed a script

cfriedt 2572369 3821910 0 11:07 ? Ss 0:00 python3 /home/cfriedt/build-zephyr-sdk/sdk-ng/poky/bitbake/bin/bitbake-worker decafbadbeef Perhaps the error is -ENOCAFFEINE?

Build Configuration: BB_VERSION = "1.48.0" BUILD_SYS = "x86_64-linux" NATIVELSBSTRING = "universal" TARGET_SYS = "i686-zephyr-linux" MACHINE =

Hey all, I've done some digging with this myself, but have not found a root cause, fix, or workaround. Google shows me that a number of other users have encountered this problem as well with Yocto,

Bitbake is going to upgrade the minimum python to 3.8, so Ubuntu 18.04 needs to use buildtools tarball to remain compatible Signed-off-by: Joshua Watt <JPEWhacker@...> --- config.json | 7

see how xorg.conf is defined for different qemu based machines in xserver-xf86-config recipe [1] [1] https://git.yoctoproject.org/poky/tree/meta/recipes-graphics/xorg-xserver/xserver-xf86-config >

Current Dev Position: YP 4.2 M1 Next Deadline: 5th December 2022 YP 4.2 Build Next Team Meetings: Bug Triage meeting Thursday December 8th 7:30 am PDT

Bitbake is going to upgrade the minimum python to 3.8, so Ubuntu 18.04 needs to use buildtools tarball to remain compatible Signed-off-by: Joshua Watt <JPEWhacker@...> --- config.json | 4

All, The below were the owners of enhancements or bugs closed during the last week! Who Count richard.purdie@... 2 yashinde145@... 1 Grand Total 3 Thanks, Stephen K. Jolley Yocto Project

All, Below is the list as of top 31 bug owners as of the end of WW49 of who have open medium or higher bugs and enhancements against YP 4.2. There are 99 possible work days left until the final

All, The triage team is starting to try and collect up and classify bugs which a newcomer to the project would be able to work on in a way which means people can find them. They're being listed on

Hello Khem Raj, Thank you for the response.This seems to be a better solution for my use case. But, I didn't understand it completely. Could you please provide an example or any link to documentation?

That is really interesting data as it confirmed there are real world issues which changing the compiler flags is going to break. Thanks for sharing. What you describe is relatively easy for a

systemd-timesyncd uses /var/lib/systemd/timesync/clock to maintain a monotonic system time across reboots even in the presence of RTC failures. If this file doesn't exist, "at the minimum, it will be

Few things comes to mind. You could deploy the systemd unit fragment strategy https://wiki.archlinux.org/title/systemd#Drop-in_files so any customizations you have could be done via these drop-ins

Hello, I have a generic use-case of maintaining the meta layer. I have a custom meta layer. But this layer serves multiple customers who share most of the recipes and files. But some files are

That works for me. I've started preparing a patch for oe-core. -- Ola x Nilsson

That does sound useful, perhaps sharing it as an RFC patch might be a good place to start? We might be able to run one of the autobuilder world targets against it, see how it looks for our core

I have a working sanity checker that checks for any glibc functions affected by -D_FILE_OFFSET_BITS=64 or -D_TIME_BITS=64. The INSANE_SKIP functionality needs some more polish but I'd be happy