Hi Alex, I will swap SWAT duty with Lee, Chee Yang. So on 25/02/2022 Chee Yang Lee will be on SWAT duty instead of me. Regards, Naveen

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

There are no rate limiting rules in place on that server. There is a load balancer in front of it that shows several connections reset around the time of the error. I don't have detailed logging about

After the discussion in triage I tried to test some of the theories mentioned on the call. There was this failed

Hi Alexandre, I'm ready to start my shift on Friday. Regards, Oleksiy ________________________________________ Sent: Thursday, February 17, 2022 01:14 To: swat@...; Oleksiy

Hello Oleksiy, Just a reminder that you will be on SWAT duty starting this Friday, please confirm you will be available. -- Alexandre Belloni, co-owner and COO, Bootlin Embedded Linux and Kernel

Hi Richard Thank you for the great work and feedback. I think Nathan did complete the switchover on our master-next and we were planning on cutting it over to the mainline today or Monday. Will take

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

Scott is aware and on top of it. js Richard Purdie <richard.purdie@...> schrieb am Fr., 4. Feb. 2022, 18:51:

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

Hi Richard, Reaching out due to a failure in meta-agl-core on the Autobuilder. Weston has been updated to 10.x, but the bbappend in meta-agl-core is still 9.x based. Do you have plans for

I am on SWAT and will start reviewing the logs in my morning. Sau! -- Sau!

This makes a lot of sense to me and it's clear now. It didn't come across this way in prior responses. Thank you for taking the time to put this together. We can't remove aws-c-common from the

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)

So the main error is: aws-c-auth-0.6.1-r0 do_packagedata_setscene: ExpansionError('SRCPV', '${@bb.fetch2.get_srcrev(d)}', FetchError('The SRCREV_FORMAT variable must be set when multiple SCMs are

The main drawback is that then you are not able to build with BB_NO_NETWORK = 1 and so there is no way to ensure you have locally all the code you need to reproduce the build in case Amazon gets out

The choice to use tags is a deliberate one. For all AWS repos that meta-aws builds recipes we use release tagging to align with a specific release. While tags can move (aka the old school CVS

Ouch, no SRCREVs? I'm guessing we need to extend yocto-check-layer with another test? :) -- Denys

wrote: I did just have a look at the aws-c-iot