|
Yocto Technical Team Minutes/Engineering Sync for Feb 23, 2021
Trevor Woerner
Yocto Technical Team Minutes, Engineering Sync, for Feb 23, 2021
archive: https://docs.google.com/document/d/1ly8nyhO14kDNnFcW2QskANXW3ZT7QwKC5wWVDg9dDH4/edit == disclaimer == Best efforts are made to ensure the below is accurate and valid. However, errors sometimes happen. If any errors or omissions are found, please feel free to reply to this email with any corrections. == attendees == Trevor Woerner, Stephen Jolley, Scott Murray, Armin Kuster, Michael Halstead, Steve Sakoman, Richard Purdie, Randy MacLeod, Saul Wold, Jon Mason, Joshua Watt, Paul Barker, Tim Orling, Mark Morton, John Kaldas, Alejandro H, Ross Burton == notes == - 3.2.2 passed QA clean, awaiting final approval from TSC - 3.1.6 built and in QA - 1 week before -m3 should be built (feature freeze for 3.3) - adding RPM to reproducibility, still needs some work - recipe maintainers: please review the patches we’re carrying (push upstream as many as possible) - glibc 2.33 issue should be resolved with latest pseudo - AUH patches are now merged or queued, few of the failures handled - AB issue list is at record high (not good) == general == RP: can’t get stable test results out of AB on master RP: would be nice to get RPM reproducibility issues ironed out, but there are some epoch issues to work through which messes up diffoscope RP: was surprised to see how bad the interactive response is on the cmdline on the builders. it seems like an I/O bottleneck Randy: mostly I/O to SSDs? RP: i believe so RP: it was immediately after a build had been started. so it could be related to downloads or sstate fetching. how much sstate did you expect that build to be reusing? SteveS: version bumps to conman, kernel… yea that could lead to a lot of rebuilds Michael: we’ve been optimizing for throughput for a while. on some other build systems we leave some overhead available for cmdline interactivity. should we start to do that with the YP AB? RP: i think it would have to be backed off by a significant amount to get that breathing space. so maybe yes, but we’d have to look at it to see what to backoff and by how much. looking through the build i see that 77% was pulled from sstate (therefore pulling data off the NAS, then extracting it). Randy: and that’s not coordinated at all, if there are 100 items, then 100 threads? RP: but limited by BB_THREADS JPEW: run by buildbot? maybe we could use cgroups? RP: i don’t think it’s CPU bound, the CPU was 50% idle when the cmdline was very slow MichaelH: sometimes we see that when the system isn’t healthy, i wonder if it’s isolated to specific machines? RP: on the CentOS machine, a command took over 5 minutes to complete. then tried debian, same thing. then logged into the fedora machine and was able to do stuff. but it didn’t seem isolated to any machines, it seemed localized in time (i.e. right after a build had been started), then dropped off. so i feel that it might be related to the initial build startup, probably related to sstate pulling/extraction Randy: could also limit I/O using cgroups RP: we do use IOnice for parts of the build (2.1 and 2.7) Michael: translation: class 2 priority 1; class 2 priority 7 Alejandro: are these sharing any hardware RP: they’re all connected to the NAS Michael: and they’re 100% dedicated to this work RP: i don’t think this is a network bottleneck, i think this is sstate extraction JPEW: maybe a different compression algorithm? gzip is notoriously slow RP: wouldn’t that make it worse? JPEW: does each AB have their own mirror RP: it’s all done over NFS JPEW: network bandwidth should be lower than local unzipping/extraction bandwidth? Alejandro: could we try different I/O scheduling? RP: don’t know RP: had a look at patches. 1,300 patches in oe-core, ~600 in pending the rest are submitted or not appropriate. some of these are 10 years or older, do we still need them? i sent 2 upstream and was told it wasn’t needed anymore (problem fixed in other ways). there’s also one in valgrind that looks similar (different fix upstream) and not needed. Ross: if some people could try to do 1 a day that would be a huge help RP: lots of patches related to reproducibility JPEW: the big issue with perf is that it uses bison (which needs patches) PaulB: read-only mode for PR server. i’ve been working on it, but it’s 1 big patch. there’s code to handle daemonizing and forking which in hash server is using the python mutli-processing. we also want to use the same RPC mechanisms that python is using. are those good lines along which to break the patches down? RP: that sounds perfect PaulB: it was easier to bash on it all together, then go back and break it up into digestible chunks RP: it’s 10 year old code, so i’m not surprised PaulB: i’ve broken out a part that uses JSON RPC, then use that for the server RP: sounds good to me JPEW: me too RP: scaling that code under python2 was a challenge. glad to see this moving forward RP: Randy posted rust patch set. felt it couldn’t be merged in this form (too many patches) Randy: do you want the history squashed? RP: that was my feeling Randy: i’ve been working on it bit by bit as stuff happens upstream which leads to lots of little commits. but i can reorg by logical group and squash the log RP: yes. in one case there were lots of commits to the rust version, then in the end you end up with 2 Randy: someone from MS worked on getting the sdk stuff working RP: given that next Monday is the feature freeze, let’s get the patched out sooner, and worry about the sdk later Randy: ok. last remaining issue is the pre-fetcher but i don’t know much about it. looked at PaulB’s patches PaulB: there are 3 methods floating around, i’ve focused on one of them that i like 1. doing the download ahead of time in do_fetch() 2. let rust-bin do the downloads itself in do_compile() which i don’t like 3. haven’t looked at the last one yet PaulB: i like 1 because it asks rust to output a cargo which the fetcher can then act on Randy: doesn’t rely on crates? PaulB: i think it relies on crates for things that it can’t resolve. however Andreas’ approach relies on getting bitbake to understand cargo-toml file, not sure if that’s a good approach Randy: are there any lessons with Go that we can use? Scott: Bruce would be a good one to talk to PaulB: my understanding with Go is that the code tends to all be placed together in the git repository, so the fetch side is a little simpler Randy: so given the approach we’re using is there anything that needs to be added PaulB: it needs testing Randy: i have a team working on testing the rust compiler itself. they can successfully execute 2/3 of the tests now (of which 99.9% pass). i have a reproducibility test for rust hello world, but it takes a long time to run. any tests you’re thinking of? PaulB: fetcher tests. if you have a “crate://” in a URL, just making sure it gets translated correctly to make sure it doesn’t bitrot Randy: is that an -m3 or -m4 activity RP: if we’ll get it in -m4 for sure we can wait until then. in oe-core we’d want some sort of hello world (make sure compiler works and we can run the binaries) Randy: we have that already RP: both for cross-compiling and target. then reproducibility tests. i’m happy to build them up, as long as there’s a roadmap. for -m3 i think we should get the baseline rust set and the crate fetcher PaulB: crate fetcher overrides the wget fetcher and makes sure everything gets put in the right place. so it just needs a couple test cases; a map of inputs to outputs. i’ll resubmit the patch and include a list of tests that we need to add RP: if someone could reply to Andreas and let him know what’s going on and why we’re going in a slightly different direction than the work he’s submitted PaulB: the fundamental unit is the recipe. devtool is the place for some of the functionality not bitbake Randy: building rust hello world works for all glibc qemu targets but some breakage with musl (risc-v and powerpc) i think Khem is working on the risc-v one. will that hold things up? RP: no PaulB: i have some slightly larger rust packages (larger than hello world) that i think will test things a little more thoroughly, e.g. ripgrep Randy: we’re testing that one already. should we add it to oe-core? RP: it would be good to have something in oe-core to do testing Randy: i think hello world would be good enough for oe-core and leave larger tests for other layers PaulB: there are rust things in oe-core (librsvg, etc) so i think oe-core will have good test things already in them without having to add recipes just for testing’s sake Randy: things also seem to work well on ARM builders Ross: yes, things are on-target TrevorW: started work on 2021 YP conference. conversation moved to conferences@... if you want to follow along or help RP: fetch, workdir, can’t clean up workdir, config changes but can’t cleanup. maybe we should fetch to a special dir and then just symlink PaulB: would it be recipe-specific RP: yes, it would be under $WORKDIR PaulB: would make the archiver easier TimO: there are a number of Go modules that don’t cleanup properly so maybe this would help ScottM: there are lots recipes that do post-processing on files in $WORKDIR before moving them to the artifacts directory, so there could be breakage there PaulB: can we do it first thing next release RP: we’ll give it a try and see TrevorW: i think a lot of BSP layers will be affected RP: i think there’s a lot of chance a lot of things (not just BSPs) will be affected ScottM: there are some BSP things that will be affected, but in AGL we’re doing a lot of $WORKDIR manipulations that aren’t necessarily BSP related as well (several): overall it sounds like a good idea and a good cleanup to try
|
|
|
|
Re: BB_HASHBASE_WHITELIST
Monsees, Steven C (US)
Thanks, will try it out...
toggle quoted messageShow quoted text
-----Original Message-----
From: Quentin Schulz <quentin.schulz@...> Sent: Thursday, February 25, 2021 8:42 AM To: Monsees, Steven C (US) <steven.monsees@...> Cc: yocto@... Subject: Re: [yocto] BB_HASHBASE_WHITELIST External Email Alert This email has been sent from an account outside of the BAE Systems network. Please treat the email with caution, especially if you are requested to click on a link, decrypt/open an attachment, or enable macros. For further information on how to spot phishing, access “Cybersecurity OneSpace Page” and report phishing by clicking the button “Report Phishing” on the Outlook toolbar. On Thu, Feb 25, 2021 at 01:37:18PM +0000, Monsees, Steven C (US) via lists.yoctoproject.org wrote: In local.conf, one usually wants to use _append instead of += since local.conf is parsed pretty early, += will override current values set with ?= or ??=. It might also be overridden if = is used in recipes/conf files. Cheers, Quentin -- StreamUnlimited Engineering GmbH High Tech Campus Vienna, Gutheil-Schoder-Gasse 10, 1100 Vienna, Austria Fax: +43 1 667 20 02 4401 quentin.schulz@..., www.streamunlimited.com
|
|
|
|
Re: BB_HASHBASE_WHITELIST
Quentin Schulz
On Thu, Feb 25, 2021 at 01:37:18PM +0000, Monsees, Steven C (US) via lists.yoctoproject.org wrote:
In local.conf, one usually wants to use _append instead of += since local.conf is parsed pretty early, += will override current values set with ?= or ??=. It might also be overridden if = is used in recipes/conf files. Cheers, Quentin -- StreamUnlimited Engineering GmbH High Tech Campus Vienna, Gutheil-Schoder-Gasse 10, 1100 Vienna, Austria Fax: +43 1 667 20 02 4401 quentin.schulz@..., www.streamunlimited.com
|
|
|
|
BB_HASHBASE_WHITELIST
Monsees, Steven C (US)
Where and when is it appropriate to add to/modify BB_HASHBASE_WHITELIST “ ?
I tried to do : BB_HASHBASE_WHITELIST += “BB_TRACE” in my local.conf but it ended up replacing existing list with just “BB_TRACE”…
basewhitelist changed from '{'TERM', 'FILESPATH', 'CCACHE', 'COREBASE', 'BBPATH', 'STAMPS_DIR', 'EXTERNAL_TOOLCHAIN', 'LOGNAME', 'FILESEXTRAPATHS', 'CCACHE_NOHASHDIR', 'LICENSE_PATH', 'BB_WORKERCONTEXT', 'BB_HASHSERVE', 'BB_UNIHASH', 'HOME', 'DL_DIR', 'SSTATE_HASHEQUIV_OWNER', 'PRSERV_DUMPDIR', 'SDKPKGSUFFIX', 'WORKDIR', 'SSTATE_PKGARCH', 'SSTATE_HASHEQUIV_METHOD', 'PRSERV_HOST', 'CCACHE_DIR', 'PRSERV_LOCKDOWN', 'STAGING_DIR_TARGET', 'STAGING_DIR_HOST', 'PWD', 'USER', 'STAMPCLEAN', 'BUILD_ARCH', 'BBSERVER', 'BB_LIMITEDDEPS', 'SSTATE_HASHEQUIV_REPORT_TASKDATA', 'TMPDIR', 'SHELL', 'THISDIR', 'DEPLOY_DIR', 'PRSERV_DUMPFILE', 'ERROR_QA', 'WARN_QA', 'FILE_DIRNAME', 'extend_recipe_sysroot', 'CCACHE_TOP_DIR', 'PARALLEL_MAKE', 'FILE', 'BB_TASKHASH', 'PATH', 'SSTATE_DIR', 'PKGDATA_DIR'}' to '{'BB_TRACE'}' changed items: {'TERM', 'FILESPATH', 'CCACHE', 'COREBASE', 'BBPATH', 'STAMPS_DIR', 'EXTERNAL_TOOLCHAIN', 'LOGNAME', 'FILESEXTRAPATHS', 'CCACHE_NOHASHDIR', 'BB_WORKERCONTEXT', 'LICENSE_PATH', 'BB_UNIHASH', 'BB_HASHSERVE', 'HOME', 'DL_DIR', 'SSTATE_HASHEQUIV_OWNER', 'PRSERV_DUMPDIR', 'PATH', 'WORKDIR', 'SSTATE_PKGARCH', 'SSTATE_HASHEQUIV_METHOD', 'SSTATE_DIR', 'PRSERV_HOST', 'CCACHE_DIR', 'STAGING_DIR_TARGET', 'STAGING_DIR_HOST', 'PWD', 'USER', 'STAMPCLEAN', 'BUILD_ARCH', 'BBSERVER', 'BB_LIMITEDDEPS', 'SSTATE_HASHEQUIV_REPORT_TASKDATA', 'TMPDIR', 'SHELL', 'THISDIR', 'DEPLOY_DIR', 'BB_TRACE', 'PRSERV_DUMPFILE', 'ERROR_QA', 'WARN_QA', 'FILE_DIRNAME', 'extend_recipe_sysroot', 'CCACHE_TOP_DIR', 'PARALLEL_MAKE', 'FILE', 'BB_TASKHASH', 'SDKPKGSUFFIX', 'PRSERV_LOCKDOWN', 'PKGDATA_DIR'}
Thanks, Steve
|
|
|
|
Re: [qa-build-notification] QA notification for completed autobuilder build (yocto-3.1.6.rc1)
Sangeeta Jain
Hi all,
toggle quoted messageShow quoted text
This is the full report for yocto-3.1.6.rc1: https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib/tree/?h=intel-yocto-testresults ======= Summary ======== No high milestone defects. no new issue found Thanks, Sangeeta
-----Original Message-----
|
|
|
|
Re: Yocto- Apache2 build guide
On 2021-02-24 5:04 a.m., D, Sharmila via lists.yoctoproject.org wrote:
Hi,Hi Sharmila, This doesn't appear to be related to adding apache. Are you able to build core-image-minimal without adding apache2? Can you provide detailed steps wrt what layers and HEAD commits for each layer you are using? Ideally, you'd reproduce on a supported release or on master. That's Dunfell/3.1 or later: https://wiki.yoctoproject.org/wiki/Releases ../Randy With Best Regards, -- # Randy MacLeod # Wind River Linux
|
|
|
|
Re: [meta-security] [PATCH V2 0/8] Some fixes for IMA/EVM
merged
toggle quoted messageShow quoted text
On 2/20/21 4:18 AM, liu.ming50@... wrote:
From: Ming Liu <liu.ming50@...>
|
|
|
|
Multi-planar API support in g_webcam
Sheraz Ali <sheraz.ali@...>
Hi All,
I wanted to know whether g_webcam supports multi-planar API. -- Thanks and Regards Sheraz Ali Shah
|
|
|
|
Monsees, Steven C (US)
Thanks again, these utilities make it much easier to understand and correct the issues...
toggle quoted messageShow quoted text
-----Original Message-----
From: yocto@... <yocto@...> On Behalf Of Monsees, Steven C (US) via lists.yoctoproject.org Sent: Tuesday, February 23, 2021 3:42 PM To: Khem Raj <raj.khem@...> Cc: yocto@... Subject: Re: [yocto] #yocto #sdk External Email Alert This email has been sent from an account outside of the BAE Systems network. Please treat the email with caution, especially if you are requested to click on a link, decrypt/open an attachment, or enable macros. For further information on how to spot phishing, access “Cybersecurity OneSpace Page” and report phishing by clicking the button “Report Phishing” on the Outlook toolbar. Thanks, will go through it... -----Original Message----- From: Khem Raj <raj.khem@...> Sent: Tuesday, February 23, 2021 2:30 PM To: Monsees, Steven C (US) <steven.monsees@...> Cc: yocto@... Subject: Re: [yocto] #yocto #sdk External Email Alert This email has been sent from an account outside of the BAE Systems network. Please treat the email with caution, especially if you are requested to click on a link, decrypt/open an attachment, or enable macros. For further information on how to spot phishing, access “Cybersecurity OneSpace Page” and report phishing by clicking the button “Report Phishing” on the Outlook toolbar. https://wiki.yoctoproject.org/wiki/TipsAndTricks/Understanding_what_changed_(diffsigs_etc) On Tue, Feb 23, 2021 at 10:03 AM Monsees, Steven C (US) via lists.yoctoproject.org <steven.monsees=baesystems.com@...> wrote:
|
|
|
|
Re: Dunfell, nodejs and typescript - short experience report
TRO <thomas.roos@...>
Hi Simon, I'm also thinking there is a need for a bbclass which actually is not using gyp, instead it should be able to "npm run build".
|
|
|
|
Yocto- Apache2 build guide
D, Sharmila <sharmila.d@...>
Hi, I am trying to enable httpd package into my yocto build, steps I followed is as below 1. Added below layer in bblayer.conf file sources/meta-openembedded/meta-webserver 2. Added below line in local.conf file IMAGE_INSTALL_append = "apache2" The yocto build using bitbake core-image-minimal gives below error
WARNING: core-image-minimal-1.0-r0 do_rootfs: busybox.postinst returned 1, marking as unpacked only, configuration required on target. Please provide the solution for the same With Best Regards, Sharmila D
|
|
|
|
Re: Trouble booting basic x86 image
Paul D. DeRocco
From: Mittal, Anuj [mailto:anuj.mittal@...]Thanks for the advice. I decided to try wic, since that's actually the x86 default if you don't set IMAGE_FSTYPES. It also looks cleaner than hddimg, since it has a real ext4 partition and no loop mounting. For the 32-bit build, it produced something my BIOS wouldn't recognize as bootable, even though it looked fine in gparted. For the 64-bit build, it booted part way, crashing on an illegal instruction in systemd. For the 64x32-build, it booted but failed trying to run /sbin/init with error -8 (invalid executable). When I look at the drive in Ubuntu, the properties on that file say it's a link to /lib/systemd/systemd, which makes sense. Strangely, though, it describes it as a shared library. objdump -f says: /media/pauld/platform/sbin/init: file format elf32-x86-64 architecture: i386:x64-32, flags 0x00000150: HAS_SYMS, DYNAMIC, D_PAGED start address 0x00024490 So still no joy. I'd rather get this wic version working than go back to the hddimg version, but I'm not sure what to try next. Ultimately, I'm just trying to get a vanilla reference build, so that when the "real" system I'm creating doesn't work (which is often), I can compare kernel configs, etc., to a known working system. -- Ciao, Paul D. DeRocco Paul mailto:pderocco@...
|
|
|
|
Re: Huawei e3372h & Quectel EG25-G LTE modems
Zoltan Kerenyi Nagy
I'm reading the Quectel dokumentation, and it say that a GobiNet driver should be included as well. But there is no Yocto recipe for that
-- Zolee
|
|
|
|
Re: Huawei e3372h & Quectel EG25-G LTE modems
Zoltan Kerenyi Nagy
Hi Khem,
There is no NetworkManager.conf file on the device. Shoudl I create one? -- Zolee
|
|
|
|
Re: Kernel Header UAPI Issue
Karthik Poduval
Hi Bruce,
Thanks a lot for your patch (attached in bugzilla https://bugzilla.yoctoproject.org/show_bug.cgi?id=5305). I am summarizing all steps once again for the benefit of anyone else who faces the same issue (including myself in the future) and may use this email list as a reference. The basic need was to export kernel headers from kernel source for an application recipe (those headers are not a part of linux-libc-headers recipe). I applied the patch pointed by Bruce https://bugzilla.yoctoproject.org/attachment.cgi?id=4647 to my local BSP layer. The patch has 2 modes of operation (described in the patch documentation). mode1: To make this work I added the following lines to my application recipe. inherit cmake kernel-alt-headers DEPENDS = "gtest rsync-native" EXTRA_OECMAKE = '-DKERNEL_HEADER_DIR:STRING=${WORKDIR}/${KERNEL_ALT_HEADER_DIR}/include' Then in my CMakeLists.txt. include_directories(${KERNEL_HEADER_DIR}) The application compiled fine but there was one side effect that kernel menuconfig (bitbake virtual/kernel -c menuconfig) wasn't able to run as it complained that the source tree wasn't clean and make mrproper was needed. This was resolved by a simple fix to the do_compile_prepend in the patch (added the mrproper command). do_compile_prepend() { if [ "${KERNEL_SOURCE_IS_LOCAL}" = "False" ]; then # install from the staging kernel directory oe_runmake -C ${STAGING_KERNEL_DIR} headers_install INSTALL_HDR_PATH=${WORKDIR}/${KERNEL_ALT_HEADER_DIR} oe_runmake -C ${STAGING_KERNEL_DIR} mrproper fi } mode2: To make this work I added the following line to my kernel recipe. inherit kernel-alt-headers to my application recipe following lines were added. DEPENDS += "virtual/kernel" EXTRA_OECMAKE = '-DKERNEL_HEADER_DIR:STRING=${STAGING_DIR_TARGET}/usr/alt-headers/include' Then in my CMakeLists.txt. include_directories(${KERNEL_HEADER_DIR}) -- Regards, Karthik Poduval On Tue, Feb 23, 2021 at 10:50 AM Bruce Ashfield <bruce.ashfield@...> wrote:
|
|
|
|
Re: Huawei e3372h & Quectel EG25-G LTE modems
On Tue, Feb 23, 2021 at 10:22 PM Zoltan Kerenyi Nagy <kerenyi.nagy.zoltan@...> wrote: Hi, what does NetworkManager.conf look like on the device ? especially mark managed=true and see if that helps
|
|
|
|
Huawei e3372h & Quectel EG25-G LTE modems
Zoltan Kerenyi Nagy
Hi,
I have a barix ipam400 module, the development is done with Yocto. Recently I managed to modify and include the needed kernel modules into the kernel with Yocto. However it still doesnt work. Both module work seemleslly and out of the box with a RaspberryPi, but not with this ipam400 modul. The kernel is 4.10. The latest issue is that when I try to pull up an internet connection the error message is this: device lo not available because device is strictly unmanage These are the kernel module which I have included with bitbake -c menuconfig linux, they are all on the target device now: Do you guys have any idea whats wrong with this setup. I've read the out-of-tree kernel module yocto dokumentation, I did my best and had many suggestions on the forum as well. -- Zolee
|
|
|
|
Re: [opkg-devel] [opkg-utils PATCH v2] Makefile: separate manpages and utils install
Alex Stewart
Merged 1 commit to opkg-utils:master.
74ccbee0f798822041dba5c6564df62a0c60d86b Thanks, -- Alex Stewart Software Engineer - NI Real-Time OS NI (National Instruments) alex.stewart@...
|
|
|
|
[ANNOUNCEMENT] Yocto Project 3.2.2 (gatesgarth-24.0.2) is Released
Vineela
Hello,
We are pleased to announce the Yocto Project 3.2.2 (gatesgarth-24.0.2) Release is now available for download.
http://downloads.yoctoproject.org/releases/yocto/yocto-3.2.2/poky-gatesgarth-24.0.2.tar.bz2 http://mirrors.kernel.org/yocto/yocto/yocto-3.2.2/poky-gatesgarth-24.0.2.tar.bz2
A gpg signed version of these release notes is available at:
http://downloads.yoctoproject.org/releases/yocto/yocto-3.2.2/RELEASENOTES
Full Test Report:
http://downloads.yoctoproject.org/releases/yocto/yocto-3.2.2/testreport.txt
Thank you for everyone's contributions to this release.
Vineela Tummalapalli Yocto Project Build and Release
- -------------------------- yocto-3.2.2 Release Notes - --------------------------
- -------------------------- Repositories/Downloads - --------------------------
Repository Name: poky Repository Location: https://git.yoctoproject.org/git/poky Branch: gatesgarth Tag: yocto-3.2.2 Git Revision: d5d6286a66f46f4523e35e0e3f20cd7396195fdc Release Artefact: poky-gatesgarth-24.0.2 sha: b892e2a70f307c1bb2fdbeef401bfac80ab2d88cb2f564db93c22a62889515be Download Locations: http://downloads.yoctoproject.org/releases/yocto/yocto-3.2.2/poky-gatesgarth-24.0.2.tar.bz2 http://mirrors.kernel.org/yocto/yocto/yocto-3.2.2/poky-gatesgarth-24.0.2.tar.bz2
Repository Name: openembedded-core Repository Location: https://git.openembedded.org/openembedded-core Branch: gatesgarth Tag: 2020-10.2-gatesgarth Git Revision: ebaaee50cb3ac75112827f935c48affaf622ce7f Release Artefact: oecore-gatesgarth-24.0.2 sha: 1a269ac8883745fcd9809eb03ab9ab72cf29096ec956e8493598f212adb0a1a3 Download Locations: http://downloads.yoctoproject.org/releases/yocto/yocto-3.2.2/oecore-gatesgarth-24.0.2.tar.bz2 http://mirrors.kernel.org/yocto/yocto/yocto-3.2.2/oecore-gatesgarth-24.0.2.tar.bz2
Repository Name: meta-mingw Repository Location: https://git.yoctoproject.org/git/meta-mingw Branch: gatesgarth Tag: yocto-3.2.2 Git Revision: 352d8b0aa3c7bbd5060a4cc2ebe7c0e964de4879 Release Artefact: meta-mingw-gatesgarth-24.0.2 sha: c1ede73885c46820a309cbde0ad6314b83ae3167859acb9cf10152691da3f2a3 Download Locations: http://downloads.yoctoproject.org/releases/yocto/yocto-3.2.2/meta-mingw-gatesgarth-24.0.2.tar.bz2 http://mirrors.kernel.org/yocto/yocto/yocto-3.2.2/meta-mingw-gatesgarth-24.0.2.tar.bz2
Repository Name: meta-gplv2 Repository Location: https://git.yoctoproject.org/git/meta-gplv2 Branch: gatesgarth Tag: yocto-3.2.2 Git Revision: 6e8e969590a22a729db1ff342de57f2fd5d02d43 Release Artefact: meta-gplv2-gatesgarth-24.0.2 sha: 27d72c88ba45d8f2e3f397194a4e3cb1ff6d76cca9ada8bc0b14c1fadb1845cd Download Locations: http://downloads.yoctoproject.org/releases/yocto/yocto-3.2.2/meta-gplv2-gatesgarth-24.0.2.tar.bz2 http://mirrors.kernel.org/yocto/yocto/yocto-3.2.2/meta-gplv2-gatesgarth-24.0.2.tar.bz2
Repository Name: bitbake Repository Location: https://git.openembedded.org/bitbake Branch: gatesgarth Tag: 2020-10.2-gatesgarth Git Revision: 0a3bf681530bd63fc0036ca81ef868ab53fde56c Release Artefact: bitbake-gatesgarth-24.0.2 sha: fb4dc9d2f85b7303383dff532360da4ae87a72ad778a252fe0738f2eae09741e Download Locations: http://downloads.yoctoproject.org/releases/yocto/yocto-3.2.2/bitbake-gatesgarth-24.0.2.tar.bz2 http://mirrors.kernel.org/yocto/yocto/yocto-3.2.2/bitbake-gatesgarth-24.0.2.tar.bz2
Repository Name: yocto-docs Repository Location: https://git.yoctoproject.org/git/yocto-docs Branch: gatesgarth Tag: yocto-3.2.2 Git Revision:6bc7e80e4ce0004e8e42ac8dddbff75c521bc19f
- ------------- Contributors - ------------- Adrian Herrera Alexander Kanavin Andrey Mozzhuhin Anuj Mittal Awais Belal Bruce Ashfield Chandana kalluri Changqing Li Chen Qi Chris Laplante Dmitry Baryshkov Dorinda Gratian Crisan Kai Kang Kamel Bouhara Khairul Rohaizzat Jamaluddin Khem Raj Lee Chee Yang Li Wang Mans Rullgard Marek Vasut Mark Jonas Martin Jansa Matt Hoosier Michael Halstead Mike Looijmans Mikko Rapeli Nathan Rossi Oleksiy Obitotskyy Oleksiy Obitotskyy yIEf0zt.mo Ovidiu Panait Paul Barker Peter Bergin Peter Kjellerstedt Richard Purdie Robert Joslyn Robert Yang Ross Burton saloni sangeeta jain Scott Murray Steve Sakoman Tomasz Dziendzielski Vyacheslav Yurkov Wang Mingyu Yi Fan Yu zangrc zhengruoqin Zhixiong Chi
- --------------- Known Issues - --------------- N/A
- --------------- Security Fixes - --------------- libcroco: Added CVE libgcrypt: Whitelisted CVEs sudo: fix CVE-2021-3156 sudo: fix CVE-2021-23240 openssl: set CVE_VERSION_SUFFIX cve_check: add CVE_VERSION_SUFFIX to indicate suffix in versioning gdk-pixbuf: fix CVE-2020-29385 sudo: fix CVE-2021-23239 python3: fix CVE-2021-3177 binutils: Fix CVE-2020-35448 zip: whitelist CVE-2018-13410 and CVE-2018-13684 ffmpeg: Fix CVE-2020-35964, CVE-2020-35965 glibc: CVE-2019-25013 curl: Fix CVE-2020-8284, CVE-2020-8285, CVE-2020-8286 qemu: CVE-2020-28916 qemu: CVE-2020-25723 patch: fix CVE-2019-20633 grub: fix "CVE:" line in one of the patches libexif: fix CVE-2020-0198; CVE-2020-0452 glib-2.0: fix CVE-2020-35457 glibc: CVE-2020-29562 and CVE-2020-29573 cups: Mark CVE-2008-1033 as a non-issue cups: Mark CVE-2009-0032 as a non-issue cups: whitelist CVE-2018-6553 coreutils: add SUSE-specific issues to CVE whitelist qemu: CVE-2020-25624 qemu: CVE-2020-29129 CVE-2020-29130
- --------------- Fixes - --------------- build-appliance-image: Update to gatesgarth head revision poky.conf: Bump version for 3.2.2 gatesgarth release bitbake: lib/bb/fetch2/__init__.py: drop _PYTHON_SYSCONFIGDATA_NAME unsetting python3targetconfig.bbclass: Make py3 dep and tasks only for target recipes gpgme: use python3targetconfig meta: drop _PYTHON_SYSCONFIGDATA_NAME hacks distutils3-base.bbclass: use python3targetconfig python3-pycairo: use python3targetconfig python3: split python target configuration into own class uninative: Upgrade to 2.10 pseudo: Update to work with glibc 2.33 openssh: Backport a fix to fix with glibc 2.33 on some platforms systemd: change /bin/nologin to /sbin/nologin license_image.bbclass: Don't attempt to symlink to the same file image_types.bbclass: tar: use posix format instead of gnu qemu.inc: Should depend on qemu-system-native, not qemu-native kernel.bbclass: fix deployment for initramfs images package: Ensure do_packagedata is cleaned correctly wic/selftest: test_permissions also test bitbake image sstatesig: Add descriptive error message to getpwuid/getgrgid "uid/gid not found" KeyError sanity.bbclass: Check if PSEUDO_IGNORE_PATHS and paths under pseudo control overlap linux-yocto/5.4: update to v5.4.94 linux-yocto-rt/5.4: fix 5.4-stable caused build breakage linux-yocto/5.4: update to v5.4.90 staging: Clean up files installed into the sysroot python3: Avoid installing test data into recipe-sysroot ncurses: Don't put terminfo into the sysroot glibc: update to latest release/2.32/master branch npm.bbclass: use python3 for npm config recipetool: create: only add npmsw url if required npm.bbclass: make shrinkwrap file optional image_types: Ensure tar archives are reproducible strace: increase ptest timeout duration 120->240s ovmf-shell-image: image is only buildable on x86-64 core-image-sato-sdk-ptest: these images need ptest dtc: improve reproducibility python3: Use addtask statement instead of task dependencies lib/oe/patch.py: Don't return command stderr from runcmd function cve-check: replace Looseversion with custom version class ca-certificates: upgrade 20200601 -> 20210119 pseudo: Update to include passwd and file renaming fixes gobject-introspection: Fix variable override order buildhistory.bbclass: avoid exception for empty BUILDHISTORY_FEATURES variable externalsrc: Detect code changes in submodules sanity.bbclass: sanity check for if bitbake is present in PATH sanity: Verify that user isn't building in PSEUDO_IGNORE_PATHS timezone: upgrade to 2021a gstreamer1.0: fix failing ptest devtool: Fix file:// fetcher symlink directory structure oeqa/selftest/cases/tinfoil.py: increase timeout 10->60s test_wait_event externalsrc: Fix parsing error with devtool non-git sources p11-kit: upgrade 0.23.21 -> 0.23.22 linux-yocto: update genericx86 to v5.4.87 bitbake: fetch/git: download LFS content too during do_fetch linuxloader: Avoid confusing string concat errors flex: Fix --noline option behavior devtool: Fix source extraction for gcc shared source toolchain-shar-relocate.sh: Fix handling files with colons wic: Optimise fstab modification for ext2/3/4 and msdos partitions wic: Copy rootfs dir if fstab needs updating wic: Update pseudo db when excluding content from rootfs image_types_wic: Move wic working directory wic: Allow exec_native_cmd to run HOSTTOOLS wic: Ensure internal workdir is not reused wic: Add workdir argument gcc: Backport patch to resolve i*86 tune configuration overrides lib/oe/utils: Return empty string in parallel_make meta: toolchain-shar-relocate.sh: Filter out post-relocate-setup script meta: toolchain-shar-relocate.sh: Do not use $target_sdk_dir as regex boost: drop arm-intrinsics.patch systemd.bbclass: improve error message when a service unit specified in SYSTEMD_SERVICE is not found toolchain-shar-extract.sh: Handle special characters in script path scripts: oe-run-native, fix *-native directories bitbake: data_smart: Ensure hash reflects vardepvalue flags correctly systemd: upgrade 246.6 -> 246.9 binutils: upgrade 2.35 -> 2.35.1 linux-yocto/5.4: update to v5.4.87 mobile-broadband-provider-info: upgrade 20190618 ->20201225 pseudo: Update for arm host and memleak fixes/cleanup pseudo: Add lchmod wrapper pseudo: Drop patches merged into upstream branch pseudo: Update to print PSEUDO_LOGFILE in abort message on path mismatches bitbake.conf: Add /run/ to PSEUDO_IGNORE_PATHS selftest: Add argument to keep build dir license.bbclass: Add COMMON_LICENSE_DIR and LICENSE_PATH dirs to PSEUDO_IGNORE_PATHS bitbake.conf: Prevent pyc file generation in pseudo context wic: Pass canonicalized paths in PSEUDO_IGNORE_PATHS bitbake.conf: Canonicalize paths in PSEUDO_IGNORE_PATHS lib/oe/path: Add canonicalize() oeqa/commands: Ensure sync can be found regardless of PATH initscripts: use quotes for shell variable comparision coreutils: enable xattrs by default for nativesdk diffstat: point the license checksum at the license linux-yocto/5.4: update to v5.4.85 linux-yocto/5.4/cfg: fix FIRMWARE_LOADER warnings linux-yocto/5.4/cfg: fix -tiny warnings linux-yocto/5.8/cfg: fix -tiny warnings linux-yocto/5.4: update to v5.4.83 linux-yocto/cfg: qemuarm64-gfx.cfg: add CONFIG_INPUT_UINPUT linux-yocto/5.4: update to v5.4.82 linux-yocto/cfg: qemuppc: set CONFIG_SCSI to '=y' timezone: upgrade to 2020f man-db: Fix reproducibility issue wic/direct/kparser: ensure fsuuid for vfat and msdos align with format grub: Further reproducibility fix devtool: gitsm:// should be handled same as git:// in upgrades timezone: upgrade to 2020e openssl: Update to 1.1.1i oeqa/selftest/cases/devtool.py: fix typo in ignore_patterns call apr-util: Only specify --with-dbm=gdbm if gdbm support is enabled valgrind: exclude bar_bad/bar_bad_xml from ptests archiver.bbclass: Fix --runall=deploy_archives for images minicom: RDEPENDS on ncurses-terminfo-base ncurses: Make ncurses-tools depend on ncurses-terminfo-base gcc: Add patch to resolve i*86 tune configuration overrides go.bbclass: Use external linker for native packages go: Update 1.15.5 -> 1.15.6 go: Update to 1.15.5 go: upgrade 1.15.2 -> 1.15.3 timezone: upgrade to 2020d kea: fix reproducibility man-db: Avoid reproducibility failures after fixing groff-native groff: Fix reproducibility issue u-boot-tools: Fix reproducibility issue ffmpeg: fix reproducibility ruby: fix reproducibility perl: fix installation failure because of shell issue parted: Make readline dependency optional glibc: Make adjtime() for 32 bit support being called with delta == NULL lttng-modules: fix build against v5.10+ linux-yocto/5.4: update to v5.4.80 linux-yocto-rt/5.4: update to -rt44 grub: Add second fix for determinism issue grub: Fix build reproducibility issue linux-firmware: package firmware for Lontium lt9611uxc bridge linux-firmware: upgrade 20201118 -> 20201218 linux-firmware: package ath11k firmware linux-firmware: upgrade 20201022 -> 20201118 linux-firmware: upgrade 20200817 -> 20201022 wireless-regdb: upgrade 2020.04.29 -> 2020.11.20 uninative: Don't use single sstate for pseudo-native kernel-module-split.bbclass: fix kernel modules getting marked as CONFFILES webkitgtk: fix reproducibility llvm: fix reproducibility meta/lib/oe/reproducible.py: gitsm:// works just as fine as git:// for timestamps populate_sdk_ext: use SDK_CUSTOM_TEPLATECONF variable to enable custom templateconf.cfg meta/lib/oeqa/manual/oe-core.json: Update test_bitbake_devshell image_types: remove obsolete tar comment image_types: sort tarball file listings oeqa/devtool: use Yocto mirror for pv-1.5.3 tarball lz4: Use the new branch naming from upstream buildtools-tarball: add wic dependency into extended buildtools sudo: fix multilib conflict cve-update-db-native: handle all-wildcard versions libsdl2: Add directfb to PACKAGECONFIG rdepends
|
|
|
|
Monsees, Steven C (US)
Thanks, will go through it...
toggle quoted messageShow quoted text
-----Original Message-----
From: Khem Raj <raj.khem@...> Sent: Tuesday, February 23, 2021 2:30 PM To: Monsees, Steven C (US) <steven.monsees@...> Cc: yocto@... Subject: Re: [yocto] #yocto #sdk External Email Alert This email has been sent from an account outside of the BAE Systems network. Please treat the email with caution, especially if you are requested to click on a link, decrypt/open an attachment, or enable macros. For further information on how to spot phishing, access “Cybersecurity OneSpace Page” and report phishing by clicking the button “Report Phishing” on the Outlook toolbar. https://wiki.yoctoproject.org/wiki/TipsAndTricks/Understanding_what_changed_(diffsigs_etc) On Tue, Feb 23, 2021 at 10:03 AM Monsees, Steven C (US) via lists.yoctoproject.org <steven.monsees=baesystems.com@...> wrote:
|
|
|
