Thanks, I have added this to AUH repo too now; I assume there are no changes in the re-sent patchset otherwise? Alex

Since https://lists.yoctoproject.org/g/yocto/message/50282 was merged in autoupgrade-helper git repo, the python script isn't called upgradehelper.py anymore but upgrade-helper.py for consistency

Rename upgradehelper.py into upgrade-helper.py since the conf file and the git repo are named with a dash to separate "upgrade" and "helper". The documentation in the README and upgradehelper.py were

Signed-off-by: Quentin Schulz <foss@...> --- - RESEND because I was not subscribed to the ML with this address already, - please ignore, resent only for archive purposes on the ML, this patch

Signed-off-by: Quentin Schulz <foss@...> --- - RESEND because I was not subscribed to the ML with this address already, - please ignore, resent only for archive purposes on the ML, this patch

A few comments were misleading or incomplete and some defaults were incorrect. Signed-off-by: Quentin Schulz <foss@...> --- - RESEND because I was not subscribed to the ML with this address

Even though a recipe might not have a MAINTAINER set, one still might want to upgrade it. This makes it possible to upgrade said kind of recipes and still keep the stats meaningful by displaying one

Can you please also send a patch to update http://git.yoctoproject.org/cgit/cgit.cgi/yocto-autobuilder-helper/tree/scripts/run-auh#n25 ? Then I can take this patch. I will add the first four patches

Looks like there were 4 failures in this

Hello, We are pleased to announce the second milestone release for Yocto Project 3.2 (yocto-3.2_M2) is now available for

OK nevermind. It seems to be builder issue. When re-installed everything works fine. Sorry for noise. -- as simple and primitive as possible ------------------------------------------------- Marek

Okay, sending now. Thanks, Chandana

Right, I agree with that. Then the patch is fine, but please send it to the correct list: openembedded-core@... Alex

I agree its possible for virgl and qemu to not be tested with other libgl providers other than mesa. But I also think mesa shouldn’t be hardcoded within the two recipes and should use virtual/libgl

It's not up to OE/YP to verify alternatives, it's up to the people providing the alternatives. The question is, is this a MESA dependency or a virtual/gl dependency. If it's the former, then mesa is

Virgl is not verified with anything else than mesa, and will almost certainly fail. And so does qemu. I think you should rather remove glx and virglrenderer from qemu PACKAGECONFIG, so that mesa is

currently have a perfectly functioning zeus-based layer with a small number of out-of-tree kernel modules which build just fine with: $ bitbake kernel-module-fubar against the stock linux-yocto

If there are multiple providers of virtual/libgl and mesa is not the default provider, the recipe compilation fails. Use virtual/libgl to pick the default provider. Signed-off-by: Sai Hari Chandana

Hi Sergey, DEPENDS = "util-linux" (DEPENDS is for build time dependencies and you add the recipe providing the sources for it, RDEPENDS_${PN} is for runtime dependencies and you add packages to it

Yocto Technical Team Minutes, Engineering Sync, for August 11 2020 archive: https://docs.google.com/document/d/1ly8nyhO14kDNnFcW2QskANXW3ZT7QwKC5wWVDg9dDH4/edit == disclaimer == Best efforts are made