1.40 is already in oe-core master you should be able to backport the recipe from there. libnml dependency was already added with wireguard PACKAGECONFIG in 1.38 here: https://git.openembedded.org/open

If you really want to update SRCREVs often for CI jobs, then I would setup separate job with some .inc file which sets SRCREVs of all the components you want to test to AUTOREV and let it run as often

I agree it's a bit annoying that some projects have chosen to rename the existing branches instead of just adopting "main" to be the default branch only for new projects (as the defaults changed e.g.

0002_libcryptopp_8.2.0_use-install-instead-of-cp.patch from your recipe might be interesting as well to guess what went wrong in your case.

No, you should chown the files to be owned by the expected user which exists in the image (probably root like in my commit). Changing the UID of the user on host is very bad work around (as it will fa

* works around: http://errors.yoctoproject.org/Errors/Details/580076/ elfutils-0.148/src/ar.c:1088:56: error: '%-*ld' directive output may be truncated writing between 6 and 10 bytes into a region of

To be honest I don't see much value of these tags for layers not included in the QA testing with oe-core release. I believe we agreed on promoting latest revisions in the branches for selected release

And the variable should be named PREFERRED_VERSION_recipe1 (it's not using pn as an override).

Hi, can I get the write access to meta-python2 as mentioned above? I have 2 fixes to make it parse able with latest oe-core: https://lists.openembedded.org/g/openembedded-devel/message/89201 https://l

Yes, there are significant diffferences in gcc, see: https://gcc.gnu.org/gcc-5/porting_to.html https://gcc.gnu.org/gcc-6/porting_to.html https://gcc.gnu.org/gcc-7/porting_to.html The recipes in public

You're probably mixing incompatible branches of different layers - always use the same branch in all layers. at_least was added in oe-core/dunfell with: https://git.openembedded.org/openembedded-core/

See QT_DIR_NAME variable in meta-qt5 and b716195f609de6547cfdfadfd4fd25292a6bbf09 commit which changed the default value.

https://github.com/webOS-ports/meta-webos-ports/commit/9fd17a67cdbed92df13a14b002a189b4c6c2d442 is an example where it triggers this error, but doesn't trigger the more common host-user-contaminated Q

If you don't really need 3.8 and 3.7.5 from warrior would be good enough for you, then backporting it to thud was relatively straightforward as implemented in: https://github.com/ros/meta-ros/commits/

> I was use using https... that is a typo, sorry... Then fix your typo and it will work, but I think you didn't read what I wrote carefully enough, see the url in the log you pasted: zeus: URL gitsm:/

#yocto

> Note went and modified ./meta/recipes-core/ovmf/ovmf_git.bb to use "http"... That is clearly wrong, you shouldn't change the git:// at the beginning of SRC_URI, just the ";protocol=git" to ";protoco

#yocto

your 2nd meta-intel probably still has: LICENSE_PATH += "${LAYERDIR}/custom-licenses" in layer.conf without having this directory included in the layer?

#yocto

This URL also fetches for me without any issues. If you cannot reach it from your location, you can still put an archive with it to your premirror or redirect it to some other repo accessible to you w

#yocto

There were only a few changes needed between dunfell and gatesgarth to keep it building and I feel guilty for sending half of them - and pinging you on FB :). I don't have interest in python2, but it'

Small typo in commit summary, but other than that please merge :).