I noticed Alexandre's build on fedora36-ty-3 was hanging in oe-selftest: https://autobuilder.yoctoproject.org/typhoon/#/builders/86/builds/4815 Looking at the bitbake-cookerdaemon.log, we see: to-work

lists.yoctoproject.org wrote: Right, but it shouldn't have broken another build. I can see how it probably happened, it should only move the file into place if the checksum matches, not download into

I have an idea actually: pokybuild@opensuse154-ty-2:~> ls /srv/autobuilder/autobuilder.yocto.io/current_sources/mesa-22.1.6.tar.xz* -la -rw-r--r-- 1 pokybuild users 16071404 Aug 10 19:08 /srv/autobuil

https://autobuilder.yoctoproject.org/typhoon/#/builders/73/builds/5739/steps/12/logs/stdio I had a look at the unpack log: NOTE: Unpacking /srv/autobuilder/autobuilder.yocto.io/current_sources/mesa-22

We can't have a conditional dependency like that, the task checksums as implemented today wouldn't work and it would break ssttate reuse. Cheers, Richard

It is a fair point. We may as well add it to perl/perl-native. Centos7 still has make 3.82 but I think we now already require buildtools tarball there so we could probably drop the glibc dependency on

lists.yoctoproject.org wrote: Ubuntu 18.04 uses make 4.1 which is old (Oct 2014). I noticed these patches from 2016: https://git.savannah.gnu.org/cgit/make.git/commit/?id=9bb994e8319c2b153cd3d6d61e2c2

https://bugzilla.yoctoproject.org/show_bug.cgi?id=14096 I'm struggling to get the data out from the old builds, one mentions ubuntu1604, there is an ubuntu1804 on both x86 and arm hosts. It is possibl

Hi, Occasionally we see perl do_install failures on the autobuilder. It looks like some kind of make race. With the last failure I saved off the build directory and have spent a lot of time staring at

Investigating a hung job on the autobuilder We've yet another hung job on the autobuilder. I thought I'd write down what I did to investigate it so others can learn how to do it and so I can remember

The AGL file[1] appears to have another entry in it for FallbackTimeservers. It is also complicated by oe-core only doing this for qemu* machines. I'm not sure a single variable is going to work well.

Hi Jan-Simon/Scott, The attached change is going to break meta-agl: https://autobuilder.yoctoproject.org/typhoon/#/builders/120/builds/1032 I think what OE-Core plans to do with a config file isn't un

Hi, We saw an LTP image failure today: https://autobuilder.yoctoproject.org/typhoon/#/builders/95/builds/2937 It was in the contoller tests (cgroup ones). I logged in and was able to grab the backtrac

Hi, We saw a failure in qemux86-64-ltp on fedora35-ty-2: https://autobuilder.yoctoproject.org/typhoon/#/builders/95/builds/2905 I saved the logs here: https://autobuilder.yocto.io/pub/failed-builds-da

After the discussion in triage I tried to test some of the theories mentioned on the call. There was this failed build: https://autobuilder.yoctoproject.org/typhoon/#/builders/79/builds/3169/steps/14/

Just to save some time, for whoever is triaging the currently failing master- next build, I added a change to bitbake which shows errors for questionable git url usage. This appears to: * show errors

Hi Richard, I hate to be the bearer of bad news but there is a bit of an issue with meta-aws and it may be more serious then we originally thought. I've been trying to fix some fetcher issues and came

I did already talk with Scott Murray and there are patches ready for this. I think meta-aws was ok? Cheers, Richard

It may be a deliberate choice but I suspect there are some issues you aren't considering, specifically: a) it breaks anyone doing offline builds b) it means source archives don't function correct c) i

wrote: I did just have a look at the aws-c-iot recipes: https://git.yoctoproject.org/meta-aws/tree/recipes-sdk/aws-c-iot/aws-c-iot_0.0.2.bb https://git.yoctoproject.org/meta-aws/tree/recipes-sdk/aws-c