I did just check and these do seem to download ok here: $ wget https://download.qemu.org/qemu-4.1.0.tar.xz --2021-01-19 21:09:28-- https://download.qemu.org/qemu-4.1.0.tar.xz Resolving download.qemu.o

#yocto #kernel

Just to be clear, where did you set that? In a .conf file? If so, you don't need the export bit. If it was in a shell it probably wouldn't work. Also, you didn't answer my other question, did you refe

#yocto #kernel

lists.yoctoproject.org wrote: Did you set: BB_GENERATE_MIRROR_TARBALLS = "1" If not you need to set that. Also, you may need to refetch things initially to ensure all the right things are generated wi

#yocto #kernel

Thanks for reporting back and letting us know. Its now in the archives in case someone else runs into it. Glad you got sorted out too! Cheers, Richard

FWIW this doesn't sound right to me. pyc files (in __pycache__) would cache the code, not data so I don't see how these values would be preserved there. I don't doubt you're seeing some kind of issue

On Sun, 2021-01-03 at 10:44 -0800, Paul D. DeRocco wrote: I've been resurrecting an old Pyro project under Gatesgarth. It's an Intel 32-bit system that needs maximum speed, so I decided to try to buil

Its going to take someone to stand up and provide the first "version" of that and I'm not sure anyone wants to step up and be that person/organisation... It does depend on which data we're talking abo

Hi, The challenge is that Yocto Project lets you build your own custom software, which means you also end up in your own BoM situation. We generally therefore provide tooling that can help you generat

I'm building an rc2 as build-appliance was mis-configured in this build. Cheers, Richard

I'm trying to work out why we need the extra dependencies when the tasks are empty. I can see how adding the inherit would help, I'm less sure how adding the deploy task after the others does though.

Is this a leftover from the previous version of the patch? We don't normally need those constraints? Cheers, Richard

If you set BB_DONT_CACHE = "1" in the recipe, it will force the recipe to reparse each time. That should cause it to rerun find_version and then change hash when the value changes. Its how SRCREV = "$

Thanks for mentioning that, it does sound like that is doing something we no longer should be doing now source_date_epoch is working in most packages properly. There are some files such as the rpm dat

Note that whilst the python headers and library will be in recipe- sysroot, the python3 binaries will not. This is because they're designed to run on the target, not the host you're building on so we

#python

I've been thinking about this and the reason I've not done this is release builds. I'm wondering if we we can somehow make the trigger release build specific. I think is is possible to do this, I've p

I've been wondering about this but I suspect we should drop them from a-full instead... Cheers, Richard

Thanks for this Sangeeta and team! Since this is final 3.2 we're keen to ensure we sort out the issues we can. There was a buildhistory issue that became apparent in the last few days. Adding in the a

This reverts commit d123606c4bef85c2436b40f51e47b602b7600c0b. This change contains races as it will start poking into do_package task directories from do_populate_sysroot. If we want to do this for na

I'm on record as strongly suggesting PACKAGECONFIG entries should be in the base recipes, there isn't a good reason I'm aware of not to do that. Obviously the system is very flexible though... Cheers,

The fetch error means it can't download the file. The above link: (http://xorg.freedesktop.org/releases/individual/lib/libXcursor-1.1.15.tar.bz2) works for me so it suggests something is wrong with th