|
[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@gmail.com> Sent: Tuesday, February 23, 2021 2:30 PM To: Monsees, Steven C (US) <steven.monsees@baesystems.com> Cc: yocto@lists.yoctoproject.org 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@lists.yoctoproject.org> wrote:
|
||||
|
|
||||
|
Adding USB modem support to Yocto
#raspberrypi
Hi!
|
||||
|
|
||||
|
https://wiki.yoctoproject.org/wiki/TipsAndTricks/Understanding_what_changed_(diffsigs_etc)
toggle quoted messageShow quoted text
On Tue, Feb 23, 2021 at 10:03 AM Monsees, Steven C (US) via lists.yoctoproject.org <steven.monsees=baesystems.com@lists.yoctoproject.org> wrote:
|
||||
|
|
||||
|
Re: Kernel Header UAPI Issue
Bruce Ashfield
On Tue, Feb 23, 2021 at 9:56 AM Karthik Poduval
<karthik.poduval@gmail.com> wrote: Because it's not a simple thing to solve (and there's a bugzilla around for it already, where the thoughts and issues are captured, but that one seems to have been closed and I can't find it at the moment). I do have a WIP class that provides some different modes (https://bugzilla.yoctoproject.org/show_bug.cgi?id=5305), but with corner cases and concerns, it keeps slipping. Feel free to try it out and comment in the bug (I'll try myself to be sure it still applied, it has been a few months). What works for your case, doesn't mean it is a general/supporable solution. But generally speaking, It's an incredibly bad idea to have your libc-headers tied to the kernel you are building. Every time that kernel changes, you basically need to rebuild the entire stack .. hence the bad idea. It is such a common question, that we actually put a warning in the libc-headers recipe itself. We do not really want a parallel set of headers in the shared workdir, that are from the currently built kernel. You'd end up with all sorts of mismatches and cross includes and potential different behaviour per-application. We already have the kernel source installed into the shared workdir, which is what the tips in the libc-headers recipe suggest using. And it honestly isn't so common the need for sanitized headers that the need for something like I did in that bug has made it necessary. Bruce
-- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II
|
||||
|
|
||||
|
OpenEmbedded Happy Hour February 24 9pm/2100 UTC
Denys Dmytriyenko
Hi,
Please join us for the upcoming OpenEmbedded Happy Hour on February 24 for Asia/Pacific timezones @ 2100/9pm UTC (4pm EST): https://www.openembedded.org/wiki/Calendar https://www.timeanddate.com/worldclock/fixedtime.html?msg=OpenEmbedded+Happy+Hour+February+24&iso=20210224T21 -- Regards, Denys Dmytriyenko <denis@denix.org> PGP: 0x420902729A92C964 - https://denix.org/0x420902729A92C964 Fingerprint: 25FC E4A5 8A72 2F69 1186 6D76 4209 0272 9A92 C964
|
||||
|
|
||||
|
Monsees, Steven C (US)
I am trying to understand the warnings/error as seen below…
Building for zeus…
Built kernel image clean updated my SSTATE_MIRRORS directory with the state_cache generated. Rebuilt my image clean again using SSTATE_MIRRORS Image builds clean and behaves correctly when booted…
I then build the SDK, my SSTATE_MIRRORS is defined in sdk-extra.conf, and does properly show up in local.conf (checked after failure) Building extended SDK has no issues.
But on install I see the following warnings and the error at the end… I am not sure what is causing the issue here…
What would cause issues like this ?, and why ?
WARNING: The initscripts:do_install sig is computed to be 375d3c24b574b83fb04dc079fb52dd5e3a0ac31ed265acece2bb689f72f9adfa, but the sig is locked to 40f5d2ac4affab9c60691714590ca00f30130ad2f5dc79f53aaf774957e1d927 in SIGGEN_LOCKEDSIGS_t-corei7-64
There isn’t much in the documentation on this or SIGGEN…
What would be the best/proper approach to resolve issues like this ?
Thanks, Steve
10:44 smonsees@yix490016 /disk0/scratch/smonsees/yocto/workspace_3/builds/sbcb-default> bitbake sbcb-defaultfs-full -c populate_sdk_ext Loading cache: 100% |######################################################################################| Time: 0:00:00 Loaded 3645 entries from dependency cache. NOTE: Resolving any missing task queue dependencies
Build Configuration: BB_VERSION = "1.44.0" BUILD_SYS = "x86_64-linux" NATIVELSBSTRING = "rhel-7.9" TARGET_SYS = "x86_64-poky-linux" MACHINE = "sbcb-default" DISTRO = "limws" DISTRO_VERSION = "3.0.4" TUNE_FEATURES = "m64 corei7" TARGET_FPU = "" meta meta-poky = "my_yocto_3.0.4:f2eb22a8783f1eecf99bd4042695bab920eed00e" meta-perl meta-python meta-filesystems meta-networking meta-initramfs meta-oe = "zeus:2b5dd1eb81cd08bc065bc76125f2856e9383e98b" meta = "master:a32ddd2b2a51b26c011fa50e441df39304651503" meta-intel = "zeus:d9942d4c3a710406b051852de7232db03c297f4e" meta-intel = "v2019.02:f635a364c55f1fb12519aff54924a0a5b947091e"
Initialising tasks: 100% |#################################################################################| Time: 0:00:04 Checking sstate mirror object availability: 100% |#########################################################| Time: 0:00:00 Sstate summary: Wanted 566 Found 298 Missed 268 Current 1794 (52% match, 88% complete) NOTE: Executing Tasks NOTE: Setscene tasks completed NOTE: Tasks Summary: Attempted 6669 tasks of which 5861 didn't need to be rerun and all succeeded. 11:59 smonsees@yix490016 /disk0/scratch/smonsees/yocto/workspace_3/builds/sbcb-default> cd /disk0/scratch/smonsees/yocto/workspace_3/builds/sbcb-default/tmp/deploy/sdk 11:59 smonsees@yix490016 /disk0/scratch/smonsees/yocto/workspace_3/builds/sbcb-default/tmp/deploy/sdk>ls limws-glibc-x86_64-aiox_orange-corei7-64-toolchain-ext-3.0.4.host.manifest limws-glibc-x86_64-aiox_orange-corei7-64-toolchain-ext-3.0.4.sh limws-glibc-x86_64-aiox_orange-corei7-64-toolchain-ext-3.0.4.target.manifest limws-glibc-x86_64-aiox_orange-corei7-64-toolchain-ext-3.0.4.testdata.json x86_64-buildtools-nativesdk-standalone-3.0.4.host.manifest x86_64-buildtools-nativesdk-standalone-3.0.4.sh x86_64-buildtools-nativesdk-standalone-3.0.4.target.manifest x86_64-buildtools-nativesdk-standalone-3.0.4.testdata.json 11:59 smonsees@yix490016 /disk0/scratch/smonsees/yocto/workspace_3/builds/sbcb-default/tmp/deploy/sdk>./limws-glibc-x86_64-aiox_orange-corei7-64-toolchain-ext-3.0.4.sh LIMWS (BAE LIMWS base distro) Extensible SDK installer version 3.0.4 ==================================================================== Enter target directory for SDK (default: ~/limws_sdk): /disk0/scratch/smonsees/testSDK You are about to install the SDK to "/disk0/scratch/smonsees/testSDK". Proceed [Y/n]? Y Extracting SDK..............................................................................done Setting it up... Extracting buildtools... Preparing build system... Parsing recipes: 100% |####################################################################################| Time: 0:01:32 Initialising tasks: 100% |#################################################################################| Time: 0:00:04 Checking sstate mirror object availability: 100% |#########################################################| Time: 0:00:03 WARNING: The initscripts:do_install sig is computed to be 375d3c24b574b83fb04dc079fb52dd5e3a0ac31ed265acece2bb689f72f9adfa, but the sig is locked to 40f5d2ac4affab9c60691714590ca00f30130ad2f5dc79f53aaf774957e1d927 in SIGGEN_LOCKEDSIGS_t-corei7-64 The linux-intel:do_compile sig is computed to be 9898137f78ba37d2fcf7df5a7b7a5dd0e5ddcbc7ce7ade89905bf5132a005a99, but the sig is locked to 06c08387009f9808044e03144d1fa0b984be9f4ad64251e688503c2dabdf5b7c in SIGGEN_LOCKEDSIGS_t-corei7-64-intel-common The imagerecv:do_compile sig is computed to be 644b002b181f27a407c33cc69cfc790201f1b48c4d7783c062d53c247d5704a5, but the sig is locked to a74b10cfc4bad050ca98549b3df41fcd0fa986e08c14e05db44b0227d0b90a0a in SIGGEN_LOCKEDSIGS_t-sbcb-default The tpm2-tss:do_configure sig is computed to be 04cf4c8e1424a46467a43620214fc3a5304863f5cbb662b5b26a5b82d792586f, but the sig is locked to ec4b02e1e3b1796883093be2aca63ec5e51df3dc14b9179be6f86f2675b3fa53 in SIGGEN_LOCKEDSIGS_t-corei7-64 The efitools:do_compile sig is computed to be c2e6dc60a7b8b2414b3761fe4966e031901144e3d32eed60bd580cc46e9b5358, but the sig is locked to 327fbae2aa4a419554ede6847fcc7c367da018e5e9d907a0051e68df5a5a2063 in SIGGEN_LOCKEDSIGS_t-corei7-64 The monkeysphere:do_configure sig is computed to be 8a5cfb349fa84ca524bf680a922d0e1781f5dc9e0b5e0f6e0b135ea88e3f8fa1, but the sig is locked to 8d2bf2edd3194e44de0143088e68703c02a88032bb089ef0a4600f7528695362 in SIGGEN_LOCKEDSIGS_t-corei7-64 The monkeysphere:do_compile sig is computed to be 819f7700a7f611335b8a5e4f8243623c4f01b187f197aa19cd034383af17b41b, but the sig is locked to 822db696400b5a788fbcc0e80f1fe242bd58cab992ff196efac191444d7b3b99 in SIGGEN_LOCKEDSIGS_t-corei7-64 The monkeysphere:do_install sig is computed to be f2f8cb58b07a350eefd41af13e1156abd85659b1865dc278238277d9230e2e3f, but the sig is locked to 9e1ca795df7d73347f0efeeac54c24f1004d59011b97262207e1055f771ee95c in SIGGEN_LOCKEDSIGS_t-corei7-64 The monkeysphere:do_populate_sysroot sig is computed to be ca8fe144be00929f3c42cb36b809a06b85d70c4f9fa1c0f6fd67b07af84d17a1, but the sig is locked to 2a41afd838cdac669dd99deefdc530c5d503329fb1fae2fb3641b490a2bbec8a in SIGGEN_LOCKEDSIGS_t-corei7-64 The monkeysphere:do_package sig is computed to be 29a5daea524a219c5216b5d76447160d006e7db633e38c7d1ade6b599eb6c2ab, but the sig is locked to 2b2cef367c44399221b07f14facff9b1ae598ccc272c4b98ddfc4b08009fc090 in SIGGEN_LOCKEDSIGS_t-corei7-64 The signature:do_configure sig is computed to be 613844241ce15b245abe2fb9306415616c72553e943183307b3496f85637345e, but the sig is locked to 68a818acd3281e28bd57efcd449a0bac0ffaa2733fcb02f6b28b2fe31d36e835 in SIGGEN_LOCKEDSIGS_t-corei7-64 The signature:do_compile sig is computed to be 8b37e4a0e6ec0068b7dda0eccd1e32577daedf248f1c3e71f82f6454d3e4338d, but the sig is locked to 6f291a0f9ba59f355d9a88d646f72bf99a001f862b310e5e435e8b406632b6b4 in SIGGEN_LOCKEDSIGS_t-corei7-64 The signature:do_install sig is computed to be 3a20f56cc04551f13378e9e596daa5eebc385ca965ebdf18adacfa7ef94c9018, but the sig is locked to 8fc761f8bf0215ea2fb9609037a5df0c7e2ad6dd9253555ea5f492b7068e7bff in SIGGEN_LOCKEDSIGS_t-corei7-64 The signature:do_populate_sysroot sig is computed to be 97d2f34ef4b40fe8e324c04346ad0cdf22cde6cc774f336400797cb6a483d08c, but the sig is locked to 93700035bc1a42b4f7e5f05ef30d4bc6fdf2abc0dd1f707b2e745ceed25d5770 in SIGGEN_LOCKEDSIGS_t-corei7-64 The signature:do_package sig is computed to be f59f3584026d4acf71d4300a18ff4bf05c0f3e3b42c2d5264af9be63820a0386, but the sig is locked to bdc6003bbd7a42a83e9a6a7ebe691e93a9744ae96c664d8656907a15af84be1c in SIGGEN_LOCKEDSIGS_t-corei7-64 The grub-efi-native:do_clean_grub sig is computed to be 17c62b3df5a57ee4cbd0e7abf1284a5d499ba4c814aaded564a24085b9fd326c, but the sig is locked to c8835ffb27e0d97b332dddad3fb83bdb849a267a8a0fa7142e66a76696c910ff in SIGGEN_LOCKEDSIGS_t-x86-64 The grub-efi-native:do_configure sig is computed to be a6dfb6cd633432b36b818b63fd6e06e086d189b62cd7fc6370c4e66e9668fa1d, but the sig is locked to 194602954bb4993b85397aeb06557d10ff14b15d52a321389cdbb0139d2ce34c in SIGGEN_LOCKEDSIGS_t-x86-64 The grub-efi-native:do_compile sig is computed to be 583800a58ca2e602d50b4e23485774e8b681f79bf48a1a854b71264a0ddcb733, but the sig is locked to e642b6c931bda1d51bc5394596cdacce7099875d1e873b39849607e03972c5b9 in SIGGEN_LOCKEDSIGS_t-x86-64 The grub-efi-native:do_mkimage sig is computed to be 87a6528cb8624851708b1f4d3fa26beb96f71f1a3cb0c4d48fe0aaf9255fb244, but the sig is locked to bc04f79c9988122be8297c3ea2e7aa13fbe18444b1151a547332112616e11480 in SIGGEN_LOCKEDSIGS_t-x86-64 The grub-efi-native:do_install sig is computed to be 6e8a988562949ae845beb0150acf7702a360094db56096b6e2bbb65820bbb3f0, but the sig is locked to 38427ff1c0bfa569a27a6c5acf51bb3483d882b18a1fa0bfbfaa371822df7837 in SIGGEN_LOCKEDSIGS_t-x86-64 The grub-efi-native:do_populate_sysroot sig is computed to be 3ba3744800732b69e71d33ea0db797a78bb2340727fc54f211bd0f7c1325374c, but the sig is locked to fcd9daa126de91d4d1de701ed1ff1c2774c3e42207e1fff85b86109eb54b290c in SIGGEN_LOCKEDSIGS_t-x86-64 The grub-efi:do_clean_grub sig is computed to be 928fbd9c1d534333f18a6f751ad705c03f083ff00374a781b02e1aee47b92bee, but the sig is locked to 67a039367c0593803d8c70207f079fd8be28dbc6c548b13837fa7eb177b156e0 in SIGGEN_LOCKEDSIGS_t-corei7-64 The grub-efi-native:do_deploy sig is computed to be 4875f4b51c38f31140775a2a4457839eabef2529791cccbb9ed656eef63892fc, but the sig is locked to 6576c95aa5c0c7b505ca2cc02fdde3f678f2b039c2f0b57810b17694b6070a46 in SIGGEN_LOCKEDSIGS_t-x86-64 The grub-efi:do_configure sig is computed to be 84ab069273c4b2703ca4fa200d5fb66adcaffa39b8f36138339d4837b9281a9d, but the sig is locked to e8900241347d4616468e7a4a4c37b8496a1167c2b3d58f7bb55332da645bd7e0 in SIGGEN_LOCKEDSIGS_t-corei7-64 The grub-efi:do_compile sig is computed to be 619bdca4f1a6df8c8c2c7ad49b7289af3477e3c76c00b84229584793f23fb115, but the sig is locked to 56ca563b3bcb66b72f53f51562f41dd0cf9af878335836e8fd6b6a07e32fa8bc in SIGGEN_LOCKEDSIGS_t-corei7-64 The grub-efi:do_mkimage sig is computed to be f212bd74eb95f4d413c9867f853171747fe4fe86912138a0ac79234fe4be73b7, but the sig is locked to 80e9256f12e3070737c81f76310cc408473b92b877b23494cd1b4c2abdffd56d in SIGGEN_LOCKEDSIGS_t-corei7-64 The grub-efi:do_install sig is computed to be 45753f50a553391bd80cf679039cccf879ef1eaca90e1dcfefb432621dfc0000, but the sig is locked to 3910d27330229314b793a94c7085c231a56c1073d7e79d4cceade5a373600252 in SIGGEN_LOCKEDSIGS_t-corei7-64 The grub-efi:do_populate_sysroot sig is computed to be 3437833e837748a59e002f95773a8f61a715bb56c0f20671fa39a71556ad6d5d, but the sig is locked to d0d60bc1d9bf488c7568e592b3b1aeeb2e2796c9994f83fe1b781e0d006e432b in SIGGEN_LOCKEDSIGS_t-corei7-64 The grub-efi:do_package sig is computed to be 81fa6cf23920cea4139ed3cefd6c94a3878580f6a45925279c7d75e3c487f162, but the sig is locked to d7ec82448f34ec8c0169f613fdd14237cebb1951efa3d35d53dc71d24f220cb8 in SIGGEN_LOCKEDSIGS_t-corei7-64 The grub-efi:do_deploy sig is computed to be f7831a1a7e1d8683e1c0c86fd32486ec8d9e5e713d63e39984aa36f50bff7f91, but the sig is locked to 1c781659fad7fb174716d05aa5727f68e710ad7c6593dc178f40866d6e868f19 in SIGGEN_LOCKEDSIGS_t-corei7-64 The tpm2-tools:do_configure sig is computed to be 10fa6cf0c4fa307a427978392ecf60d7a8853e11ca1747ea5ad8743fd42280f3, but the sig is locked to 5e6a2caa27901f95518467ca35b68043fee7802dfa8be39ae51e61c9eedf9a8d in SIGGEN_LOCKEDSIGS_t-corei7-64 The wolfssl:do_configure sig is computed to be 5569ddf9b10e2df9f5de456ca35b9baeb34a1f67617357d5e1a9264baf3d1e0e, but the sig is locked to eaf1b380210718071d8962eeccbd97efad180fabc750b18f4e98661de06ae11f in SIGGEN_LOCKEDSIGS_t-corei7-64 The crush:do_configure sig is computed to be f034116fd9598a09aa975e94dd48964e0d49deecf63d96c436bd4cccc7b68298, but the sig is locked to 64dfc5ff4a9ee29e9a20f1166ec2ee6fe20ffcd93e7618eabd02435c29f219ed in SIGGEN_LOCKEDSIGS_t-corei7-64 ERROR: Task quilt-native.do_fetch attempted to execute unexpectedly
|
||||
|
|
||||
|
Yocto Project Status WW08`21
Stephen Jolley
Current Dev Position: YP 3.3 M3 development Next Deadline: 1st March 2021 YP 3.3 M3 build and YP 3.3 Feature Freeze
Next Team Meetings:
Key Status/Updates:
Ways to contribute:
YP 3.3 Milestone Dates:
Planned upcoming dot releases:
Tracking Metrics:
The Yocto Project’s technical governance is through its Technical Steering Committee, more information is available at: https://wiki.yoctoproject.org/wiki/TSC
The Status reports are now stored on the wiki at: https://wiki.yoctoproject.org/wiki/Weekly_Status
[If anyone has suggestions for other information you’d like to see on this weekly status update, let us know!]
Thanks,
Stephen K. Jolley Yocto Project Program Manager ( Cell: (208) 244-4460 * Email: sjolley.yp.pm@...
|
||||
|
|
||||
|
Re: Trouble booting basic x86 image
Anuj Mittal
On Tue, 2021-02-23 at 01:01 -0800, Paul D. DeRocco wrote:
Yocto Gatesgarth, using meta-intel to build core-image-minimalIt looks like you are using the live option in hddimg image? Can you try adding "rootwait" to kernel parameters and see if that works? Not sure why it's not dropping to shell, but may be try adding explicit call to /bin/sh in meta/recipes-core/initrdscripts/files/init-live.sh before this point to make sure the media is actually mounted at that point. Also, have you tried wic image to see if that works? Thanks, Anuj
|
||||
|
|
||||
|
Re: Kernel Header UAPI Issue
Mikko Rapeli
Hi,
On Tue, Feb 23, 2021 at 06:56:02AM -0800, Karthik Poduval wrote: Hi Mikko,A kernel recipe will provide linux-libc-headers after a "make headers_install" call... So the SRC_URI of linux-libc-headers can be the same as from the linux kernel recipe, or linux kernel recipe can provide (with some tricks, possibly) the linux-libc-headers binary packages. I have an application that uses dmabuf heap that potentially extendsI guess the reason is to split userspace to BSP/board specific and common parts. It's not good if whole userspace bootstrap depends on kernel recipe and any kernel changes requires full bootstrap and recompilation of all userspace. But there are BSP/board specific recipes which do need the real effective kernel headers to interface with kernel drivers, and there are SoC architecture specific ones which just need enough to build gcc and glibc. Both have their pross and cons, and to me there is no clear winner. Cheers, -Mikko
|
||||
|
|
||||
|
Re: Kernel Header UAPI Issue
Karthik Poduval
Hi Mikko,
toggle quoted messageShow quoted text
Do you have an example on how you do that ? Do you bbapend the linux-libc-headers recipe file ? I have an application that uses dmabuf heap that potentially extends across multiple BSP's as its BSP agnostic. I don't want to be patching individual BSP recipes and generating headers. The issue I am facing is due to backporting the patch from 5.6 to 5.4 so the required header isn't a part of the linux-libc-headers.bb recipe. Best would have been a virtual/kernel-keaders target that applications that require BSP headers would add to their recipe DEPENDS. Why is this not a solved issue by yocto project ? Why do individual BSP's need to deal with this differently when the header install mechanism (make headers_install) is the same irrespective of the type of BSP ?
On Tue, Feb 23, 2021 at 5:18 AM <Mikko.Rapeli@bmw.de> wrote:
--
Regards, Karthik Poduval
|
||||
|
|
||||
|
Re: Updating Yocto
Mikko Rapeli
On Tue, Feb 23, 2021 at 09:24:47AM -0500, Claude Bing wrote:
I mentioned that we remove that directory, and it does indeed solve aYes, we're talking about the same thing :) A lot of yocto things don't work well if major changes happen and WORKDIR isn't completely cleaned in between. With various BSP layers things can be even worse and they may actively break both work directory and sstate caches. For any major changes in open source or other meta layers, I wipe build/tmp completely to avoid random problems. In our CI this is the default. Only download cache and sstate mirror are re-used between builds. After this, I don't see many problems and build failures which are not real bugs in either our changes or in upstream, e.g. race conditions in build scripts. Cheers, -Mikko
|
||||
|
|
||||
|
Re: Updating Yocto
Claude Bing
On 2/23/21 7:58 AM, Mikko Rapeli wrote:
Hi,I mentioned that we remove that directory, and it does indeed solve a lot of problems. Not sure that it was clear from the original message, but whenever we get a random error on the first build after the upgrade we run a "bitbake -c cleanall" on that package, and everything works great. The errors do not show up again. Thanks for the reply.
|
||||
|
|
||||
|
Re: Kernel Header UAPI Issue
Mikko Rapeli
Hi,
I know it's not the best or recommended approach, but I find it hard to avoid merging linux-libc-headers recipe with the actual kernel recipe that a distro is using. At least a static copy of some version of uapi headers from that kernel can be used instead of the poky side linux-libc-headers. This helps to get the actual BSP SW delivery headers into userspace, SDK etc. Cheers, -Mikko
|
||||
|
|
||||
|
Re: Updating Yocto
Mikko Rapeli
Hi,
On Mon, Feb 22, 2021 at 12:12:21PM -0500, Claude Bing wrote: Hello all. My organization has been working with Yocto recently, and weWhen both yocto update and your own changes are modifying the same recipes, then conflicts can occur. Most of the time, these recipes have not been extended in our project,If builds are failing, then your environment is breaking something. It might even be the BSP layers that you use. Are we doing something wrong, or is there a more acceptable way toI update all open source meta layers for every run of the update and also resolve any issues by digging into details why the failure happened. I've done dunfell updates with several BSP layers for multiple arm64 SoC's and have not seen major issues. What is useful and one of the best practices, is to clear the bitbake tmp directory in between builds. Depending on details, there can be some cruft there which fails when rebuilding. Cheers, -Mikko
|
||||
|
|
||||
|
Re: [error-report-web][PATCH] report-error.bbclass: Add layer and bitbake version info to error report
Milan Shah
Hi All, This has not been reviewed yet and it is given since January 6th. Please review it and provide review comments if any as soon as possible to resolve this issue. Thanks & Regards, Milan Shah
On Mon, Feb 1, 2021 at 10:06 AM Milan Shah <mshah@...> wrote:
|
||||
|
|
||||
|
Trouble booting basic x86 image
Paul D. DeRocco
Yocto Gatesgarth, using meta-intel to build core-image-minimal
Intel D2700MUD mini-ITX mobo with D2700 Atom Ordinary USB 2.0 flash drive I followed the instructions in the meta-intel README, and had no problems building the intel-core2-32 and intel-corei7-64 machines, as well as the latter with an x32 tune. But whenever I try to boot any of them, I get the following stuff from the kernel: usb 1-6: new high-speed USB device number 4 using ehci-pci usb-storage 1-6:1.0: USB Mass Storage device detected usb-storage 1-6:1.0: Quirks match for vid 090c pid 1000: 400 scsi host4: usb-storage 1-6:1.0 scsi 4:0:0:0: Direct-Access FLASH Drive SM_USB20 1100 PQ: 0 ANSI: 4 sd 4:0:0:0: Attached scsi generic sg0 type 0 sd 4:0:0:0: [sda] 3932160 512-byte logical blocks: (2.01 GB/1.88 GiB) sd 4:0:0:0: [sda] Write Protect is off sd 4:0:0:0: [sda] No Caching mode page found sd 4:0:0:0: [sda] Assume drive cache: write through sda: sd 4:0:0:0: [sda] Attached SCSI removable disk (countdown from 27 to 0) Mounted filesystems Available block devices major minor #blocks name 1 0 4096 ram0 ... (others edited out) 1 15 4096 ram15 8 0 1966080 sda Cannot find rootfs.img file in /run/media/* , dropping to a shell At this point, it doesn't drop to a shell, but just sits there, responding to keys by echoing them, so I have no way of investigating. Ctrl-Alt-Del reboots. Since there is no kernel serial output on this board, even though the kernel command requests it, I videoed the startup, but didn't anything that looked suspicious. I didn't see any message, though, about mounting anything in /run/media. As I've said, I've tried three different builds, totally generic except for using the Intel BSP layer. I've tried two different USB drives. I've tried it with EFI enabled and disabled in the BIOS. I've looked at the drive on the PC, and the contents look normal. So why can't it find the rootfs.img file, which is right there on sda, large as life? Anyone have any ideas what I could be doing wrong? -- Ciao, Paul D. DeRocco Paul mailto:pderocco@ix.netcom.com
|
||||
|
|
||||
|
#toolchain #sdk #qt5 - compiler missing from from do_populate_sdk
#toolchain
#sdk
#qt5
vitalEol
Hi,
We have a functioning image built for our device/platform based on Ti Processor SDK 04.03.00.05; at this point I'm trying to build an SDK for the image that I can distribute to other members of our development team to develop Qt5-based application for our platform. I want to build an SDK installer that includes additional Qt5 components which aren't included in the default Ti SDK like QtConnectivity and QtVirtualKeyboard. I've tried several methods to build the SDK including:
None of the resulting SDK installers appear to include the compiler, after sourcing the environment script I get the following: micheal:buildData$ source /buildData/customToolchain/environment-setup-armv7ahf-neon-linux-gnueabi
micheal:buildData$ $CC
bash: arm-linux-gnueabihf-gcc: command not found
micheal:buildData$
I know that in the past I did manage to get a working SDK/Toolchain using one of the methods above though at the moment none seem to work for me. Regards, Evan
|
||||
|
|
||||
|
Re: [error-report-web][PATCH] parser: make contains_tag ignore non-str fields
Yi Fan Yu
RP,
if you want to get this merged too that would be great. yifan
|
||||
|
|
||||
|
[error-report-web][PATCH] Update to be compatible with python3.5
Yi Fan Yu
mostly changed the way to access request.GET
also tested on python2.7 to be backward compatible Signed-off-by: Yi Fan Yu <yifan.yu@windriver.com> --- Post/parser.py | 2 +- Post/views.py | 14 +++++++------- 2 files changed, 8 insertions(+), 8 deletions(-) diff --git a/Post/parser.py b/Post/parser.py index f54482a..f411e02 100644 --- a/Post/parser.py +++ b/Post/parser.py @@ -17,7 +17,7 @@ from django.core.urlresolvers import reverse class Parser: def __init__(self, data): - self.data = data + self.data = data.decode('utf-8') # returns true if the values contain '<' char # Ignore the failures field (which is an array anyway) diff --git a/Post/views.py b/Post/views.py index cc6aed9..fe7100e 100644 --- a/Post/views.py +++ b/Post/views.py @@ -15,9 +15,9 @@ from django.shortcuts import HttpResponse, render from django.views.decorators.csrf import csrf_exempt from django.shortcuts import redirect from Post.models import BuildFailure, Build, ErrorType -from parser import Parser +from Post.parser import Parser from django.conf import settings -from createStatistics import Statistics +from Post.createStatistics import Statistics from django.core.paginator import Paginator, EmptyPage from django.core.exceptions import FieldError, ObjectDoesNotExist from django.http import JsonResponse @@ -65,12 +65,12 @@ def addData(request, return_json=False): if return_json: response = JsonResponse(result) else: - if not result.has_key('error'): + if not 'error' in result: response = HttpResponse("Your entry can be found here: "+result['build_url']) else: response = HttpResponse(result['error']) - if result.has_key('error'): + if 'error' in result: response.status_code=500 else: if return_json: @@ -125,7 +125,7 @@ def search(request, mode=results_mode.LATEST, **kwargs): items = BuildFailure.objects.all() - if request.GET.has_key("limit"): + if "limit" in request.GET: try: n_limit = int(request.GET['limit']) if n_limit > 0: @@ -202,14 +202,14 @@ def search(request, mode=results_mode.LATEST, **kwargs): ], } - if request.GET.has_key("filter") and request.GET.has_key("type"): + if "filter" in request.GET and "type" in request.GET: items = apply_filter(context, items, request.GET['type'], request.GET['filter']) if mode == results_mode.SPECIAL_SUBMITTER and hasattr(settings,"SPECIAL_SUBMITTER"): #Special submitter mode see settings.py to enable name = settings.SPECIAL_SUBMITTER['name'] items = items.filter(BUILD__NAME__istartswith=name) - elif mode == results_mode.SEARCH and request.GET.has_key("query"): + elif mode == results_mode.SEARCH and "query" in request.GET: query = request.GET["query"] items = items.filter( -- 2.25.1
|
||||
|
|