|
Yocto Project 3.1.14 (dunfell-23.0.14) is Released
Lee Chee Yang
Hi We are pleased to announce the Yocto Project 3.1.14 (dunfell-23.0.14) Release is now available for download.
http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.14/poky-dunfell-23.0.14.tar.bz2 http://mirrors.kernel.org/yocto/yocto/yocto-3.1.14/poky-dunfell-23.0.14.tar.bz2
A gpg signed version of these release notes is available at:
http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.14/RELEASENOTES
Full Test Report:
http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.14/testreport.txt
Thank you for everyone's contributions to this release.
Chee Yang Lee chee.yang.lee@... Yocto Project Build and Release
- -------------------------- yocto-3.1.14 Release Notes - --------------------------
- -------------------------- Repositories/Downloads - --------------------------
Repository Name: poky Repository Location: https://git.yoctoproject.org/git/poky Branch: dunfell Tag: yocto-3.1.14 Git Revision: bba323389749ec3e306509f8fb12649f031be152 Release Artefact: poky-dunfell-23.0.14 sha: 3401d1b660f2284e6e974c4dd1a8a3d5b1d311f87d261c324a84f812a9ad9d9c Download Locations: http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.14/poky-dunfell-23.0.14.tar.bz2 http://mirrors.kernel.org/yocto/yocto/yocto-3.1.14/poky-dunfell-23.0.14.tar.bz2
Repository Name: openembedded-core Repository Location: https://git.openembedded.org/openembedded-core Branch: dunfell Tag: yocto-3.1.14 Git Revision: f3be01483b01c88f8c4ba24ca73ccf1bcc33665c Release Artefact: oecore-dunfell-23.0.14 sha: 9584897dfdab65bd1d70254f25cc91fb6d04e92e4b77b088ed81603da6a57909 Download Locations: http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.14/oecore-dunfell-23.0.14.tar.bz2 http://mirrors.kernel.org/yocto/yocto/yocto-3.1.14/oecore-dunfell-23.0.14.tar.bz2
Repository Name: meta-mingw Repository Location: https://git.yoctoproject.org/git/meta-mingw Branch: dunfell Tag: yocto-3.1.14 Git Revision: 524de686205b5d6736661d4532f5f98fee8589b7 Release Artefact: meta-mingw-dunfell-23.0.14 sha: dcd6e4a799b8f2727279eb640f077ca945a33ad61a2a9f076a72061874847e6d Download Locations: http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.14/meta-mingw-dunfell-23.0.14.tar.bz2 http://mirrors.kernel.org/yocto/yocto/yocto-3.1.14/meta-mingw-dunfell-23.0.14.tar.bz2
Repository Name: meta-gplv2 Repository Location: https://git.yoctoproject.org/git/meta-gplv2 Branch: dunfell Tag: yocto-3.1.14 Git Revision: 60b251c25ba87e946a0ca4cdc8d17b1cb09292ac Release Artefact: meta-gplv2-dunfell-23.0.14 sha: a102bad796e7bbd36881068e18aabf49ce66b41a252ae06101ff3d64d4ce6ec8 Download Locations: http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.14/meta-gplv2-dunfell-23.0.14.tar.bz2 http://mirrors.kernel.org/yocto/yocto/yocto-3.1.14/meta-gplv2-dunfell-23.0.14.tar.bz2
Repository Name: bitbake Repository Location: https://git.openembedded.org/bitbake Branch: dunfell Tag: yocto-3.1.14 Git Revision: be6ecc160ac4a8d9715257b9b955363cecc081ea Release Artefact: bitbake-dunfell-23.0.14 sha: 3f6a3bb828be8196e19b6a46461373cdced08792ac01488f25cdb31a0740e7f3 Download Locations: http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.14/bitbake-dunfell-23.0.14.tar.bz2 http://mirrors.kernel.org/yocto/yocto/yocto-3.1.14/bitbake-dunfell-23.0.14.tar.bz2
Repository Name: yocto-docs Repository Location: https://git.yoctoproject.org/git/yocto-docs Branch: dunfell Tag: yocto-3.1.14 Git Revision: 9c5533b45bfd6a3d383e973a2c40e0f418afcbe9
- --------------- Known Issues - --------------- N/A
- --------------- Security Fixes - --------------- speex: fix CVE-2020-23903 expat: fix CVE-2021-46143 expat: fix CVE-2021-45960 expat fix CVE-2022-22822 through CVE-2022-22827 xserver-xorg: whitelist two CVEs xserver-xorg: update CVE_PRODUCT grub: fix CVE-2020-14372 and CVE-2020-27779 dropbear: Fix CVE-2020-36254 inetutils: fix CVE-2021-40491 vim: fix CVE-2021-4069 openssh: Whitelist CVE-2016-20012 openssh: Fix CVE-2021-41617 bluez: fix CVE-2021-0129
- --------------- Fixes - --------------- build-appliance-image: Update to dunfell head revision poky.conf: Bump version for 3.1.14 release bitbake: hashserv: specify loop for asyncio in python < 3.6 Revert "weston: Use systemd notify," lttng-tools: Add missing DEPENDS on bison-native kernel: introduce python3-dtschema-wrapper linux-yocto/5.4: update to v5.4.172 glibc: Add fix for data races in pthread_create and TLS access parselogs: add a couple systemd false positives expat: Update HOMEPAGE to current url wic: use shutil.which wic: misc: Do not find for executables in ASSUME_PROVIDED cve-check: add lockfile to task cve-update-db-native: use fetch task oeqa/selftest/cases/tinfoil.py: increase timeout 60->120s test_wait_event valgrind: skip flakey ptest (gdbserver_tests/hginfo) bitbake: tests/fetch: Drop gnu urls from wget connectivity test bitbake: utils: Update to use exec_module() instead of load_module() linux-yocto/5.4: update genericx86* machines to v5.4.158 asciidoc: properly detect and compare Python versions >= 3.10 lib/oe/reproducible: correctly set .git location when recursively looking for git repos scripts: Update to use exec_module() instead of load_module() selftest: skip virgl test on fedora 35 scripts/buildhistory-diff: drop use of distutils weston: Backport patches to always activate the top-level surface oeqa/selftest/tinfoil: Update to use test command oeqa/selftest/bbtests: Use YP sources mirror instead of GNU openssl: Add reproducibility fix libpcre2: update SRC_URI linux-firmware: upgrade 20211027 -> 20211216 bitbake: cooker/command: Add a dummy event for tinfoil testing ref-manual: fix patch documentation documentation: further updates for 3.1.13 releases: update to include 3.1.13 selftest: skip virgl test on fedora 34 entirely gstreamer1.0: fix failing ptest bootchart2: remove wait_boot logic
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
[meta-security][PATCH] tpm2-pkcs11: fix RDEPENDS variable
Patrick Williams
The RDEPENDS variable was misspelled and as a result was never fixed up
with the `_${PN}` to `:${PN}` transition. Fix both aspects. Signed-off-by: Patrick Williams <patrick@...> --- meta-tpm/recipes-tpm2/tpm2-pkcs11/tpm2-pkcs11_1.7.0.bb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta-tpm/recipes-tpm2/tpm2-pkcs11/tpm2-pkcs11_1.7.0.bb b/meta-tpm/recipes-tpm2/tpm2-pkcs11/tpm2-pkcs11_1.7.0.bb index d70dbfa..177c3c3 100644 --- a/meta-tpm/recipes-tpm2/tpm2-pkcs11/tpm2-pkcs11_1.7.0.bb +++ b/meta-tpm/recipes-tpm2/tpm2-pkcs11/tpm2-pkcs11_1.7.0.bb @@ -52,5 +52,5 @@ FILES:${PN} += "\ ${datadir}/p11-kit/* \ " -RDEPNDS_${PN} = "tpm2-tools" +RDEPENDS:${PN} = "tpm2-tools" RDEPENDS:${PN}-tools += "${PYTHON_PN}-setuptools ${PYTHON_PN}-pyyaml ${PYTHON_PN}-cryptography ${PYTHON_PN}-pyasn1-modules" -- 2.34.1
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: freecell-solver fetch issue
Andreas Müller
Hi,
toggle quoted messageShow quoted text
Isn't that [1]? I answered and got no response. Why cross-post? [1] https://github.com/schnitzeltony/meta-qt5-extra/issues/88 Cheers Andreas
On Fri, Feb 11, 2022 at 1:50 PM sateesh m <sateesh0457@...> wrote:
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: same build for multiple machine configurations
On Wed, Feb 16, 2022 at 1:36 AM Alexandru Ionita
<alexandru.ionita@...> wrote: I think you can share maximum by using same tunes perhaps for pi3 and pi4 machines but we do not generate single images which will work across multiple SOCs. Thanks.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Interesting discussion on github relating to branch (re)naming
K1AY <challinan@...>
https://github.com/fsnotify/fsnotify/issues/426 I discovered the issue while building something on Warrior. Yeah, I know it's been fixed a couple weeks ago in Yocto, but it brings up a bigger point of discussion. Thought some of you might want to know if you haven't come across the issue yet. Cheers! Chris
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: Yocto Zeus -docker/PREEMPT_RT
Leon Woestenberg
Hello Steven,
Last entry, from July 2021, in this blog says not supported;No, that remark is completely wrong and is mixing up things.Docker for RTOS? - General Discussions / Feature Requests - Docker Community Forums "RTLinux" has nothing to do with the mainstream Linux kernel (except that RTLinux can run the Linux kernel underneath) Forget about those remarks. Mainstream Linux is now almost fully-featured with the PREEMPT_RT work merged, and the Linux kernel can be configured as an RTOS capable kernel. There is more to hard real-time than just the kernel, but that is the kernel part. I would see *no reason* why Docker should not run on Linux, even when preemptive realtime is enabled. In contrast when searching for the PREEMPT_RT / Docker combination I see successful results. What is probably the cause for Docker not working, is that the kernel configuration for the PREEMPT_RT a.k.a. "-rt" kernel in Yocto does not enable all name space support and other capabilities that Docker depends on. I would start comparing .config files at this point, together with the debug/log output of Docker. Especially first learn which CONFIG_ options Docker depends on. Regards, -- Leon Woestenberg leon@... M: +31 6 472 30 372 Sidebranch Embedded Systems Eindhoven, The Netherlands http://www.sidebranch.com On Wed, Feb 16, 2022 at 1:15 PM Monsees, Steven C (US) via lists.yoctoproject.org <steven.monsees=baesystems.com@...> wrote:
Under Yocto, will docker & PREEMPT_RT kernels function correctly, is this combination supported ?
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Yocto Zeus -docker/PREEMPT_RT
Monsees, Steven C (US)
I have 2 platforms one with a standard kernel the other using PREEMPT_RT kernel… both work as expected.
All things being equal, when I add docker container support to both platforms, the standard kernel works just fine, but on the PREEMPT_RT kernel docker does not appear to initialize/work correctly…
I have also tested using both ARM & Intel based HW, and appear tosee the same behavior on both.
Checking online it appears there is chatter about whether docker will run correctly under a PREEMPT_RT kernel. Example:
Last entry, from July 2021, in this blog says not supported; Docker for RTOS? - General Discussions / Feature Requests - Docker Community Forums
Under Yocto, will docker & PREEMPT_RT kernels function correctly, is this combination supported ?
I am currently running zeus based platforms, docker is at version 19.03.2-ce.
Is there a patch to correct for the compatibility issues being seen ?, or Is there a yocto version I might move to which supports both correctly ?
Any input on this would be greatly appreciated.
Thanks, Steve
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
same build for multiple machine configurations
Alexandru Ionita
Hello all, I'm not sure if this is even possible at all. I'm using the meta-raspberry layer to build raspberry images. Whilst I'm able to build images by strictly selecting a raspberry pi machine configuration (MACHINE=raspberrypi3), I would like to know if it's possible to build an image that is compatible with multiple raspberry pi machine configurations. For instance an image that would work for both raspberrypi3 and raspberrypi4. Thanks. Alex
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: [OE-core] [qa-build-notification] QA notification for completed autobuilder build (yocto-3.1.14.rc1)
Richard Purdie
On Tue, 2022-02-15 at 12:46 +0000, Teoh, Jay Shen wrote:
Hi All,Thanks for testing! The TSC did discuss this today and agreed it should be good to release. Cheers, Richard
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Yocto Project Status WW07`22
Stephen Jolley
Current Dev Position: YP 3.5 M3 Next Deadline: 21th Feb. 2022 YP 3.5 M3 build
Next Team Meetings:
Key Status/Updates:
In particular, we’re struggling to understand the intermittent network issue with external hosts we’re seeing very occasionally.
Ways to contribute:
YP 3.5 Milestone Dates:
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@...
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
gpsd bbappend adding new file causing QA errors even with FILES_${PN}:append set
mattwood2000@...
Hi,
I've seen many questions about this with proposed answers but I cannot seem to get this to work for my bbappend to gpsd. I'm simply trying to add an additional systemd service file I created for the gpspipe client. What is strange is that I'm already appending the ${systemd_system_unitdir} in this bbappend to replace gpsd.socket with no error. I'm confused why adding one additional file to a directory that is already being appended could cause the QA error: ERROR: gpsd-3.23.1-r0 do_package: QA Issue: gpsd: Files/directories were installed but not shipped in any package: /lib/systemd/system/gpspipe.service The recipe is below - I've commented out the three lines that cause the error. Anyone have any ideas why this is happening? Thanks, Matt. gpsd_%.bbappend: FILESEXTRAPATHS:prepend := "${THISDIR}/files:" SRC_URI += "\ file://gpsd.default \ file://gpsd.socket \ file://gpspipe.service \ " inherit systemd SYSTEMD_PACKAGES = "${PN}" SYSTEMD_AUTO_ENABLE = "enable" SYSTEMD_SERVICE_${PN}:append = " gpsd.service gpsd.socket gpspipe.service " do_install:append () { install -d ${D}${sysconfdir}/default/ install -d ${D}${sysconfdir}/systemd/system/multi-user.target.wants/ install -d ${D}${sysconfdir}/systemd/system/sockets.target.wants/ install -D -m 600 ${WORKDIR}/gpsd.default ${D}${sysconfdir}/default/ install -D -m 600 ${WORKDIR}/gpsd.socket ${D}${systemd_system_unitdir} # install -D -m 600 ${WORKDIR}/gpspipe.service ${D}${systemd_system_unitdir} ln -s ${systemd_unitdir}/system/gpsd.service ${D}${sysconfdir}/systemd/system/multi-user.target.wants/gpsd.service ln -s ${systemd_unitdir}/system/gpsd.socket ${D}${sysconfdir}/systemd/system/sockets.target.wants/gpsd.socket # ln -s ${systemd_unitdir}/system/gpspipe.service ${D}${sysconfdir}/systemd/system/multi-user.target.wants/gpspipe.service } FILES_${PN}:append = " \ ${sysconfdir}/systemd/system/multi-user.target.wants \ ${sysconfdir}/systemd/system/sockets.target.wants \ ${sysconfdir}/default/gpsd.default \ ${systemd_system_unitdir}/gpsd.socket \ # ${systemd_system_unitdir}/gpspipe.service \ "
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Best laptop for compiling Yocto
Greg Wilson-Lindberg
Hello All, I have a System 76 Serval laptop that I have been using when building Yocto. It seems to be dying and they are on back order now, so not available for replacement. I was wondering what recommendations others would have for a good laptop to use for building Yocto?
Regards, Greg
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: [linux-yocto] Controlling features enable/disable across recipe and meta layers ?
Alexander Kanavin
You need to define several distributions (e.g. several
toggle quoted messageShow quoted text
conf/distro/something.conf files), then you can set DISTRO_FEATURES accordingly in each of them, and then on the recipe level PACKAGECONFIGs can be enabled subject to DISTRO_FEATURES. Note that each of those .conf files can include the same .inc, where the common parts go, and only differ in things that need to be different. Yocto does not provide a way to have different 'products' or 'builds' inside the same distro: you choose a distro, then you choose a target MACHINE (e.g. the hardware), then you choose the image to build. Also, distro definitions do not belong in a BSP layer, they need to go to a separate distro layer. You can ask your colleagues at QC how this was cleaned up for a certain big german automotive customer and look at the resulting layer code. Alex
On Tue, 15 Feb 2022 at 16:05, Pintu Agarwal <pintu.ping@...> wrote:
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: Controlling features enable/disable across recipe and meta layers ?
Pintu Agarwal
Hi,
I have many questions about Yocto features. My main question is: In Yocto what is the best mechanism to define a feature flag such that it can be accessed across many layers and recipes ? We are using Yocto thud and/or dunfell at this moment for 2 different products. From the Yocto document also it is not very clear which one to use. Also, we are confused when one to use when, like we have: DISTRO Feature flag, PACKAGECONFIG variable, IMAGE Feature, Global Macro (setVar, getVar), etc. Example: Currently, we have many different releases and many different products use it. So, we have many distro features, many of them are common and many of them we defined newly for our product. But for our product we have only one component (say: auto-prod). So, when this component is enabled the same release should be built for our product including our feature set. And when this component is disabled, all our features should be disabled like mainline release. So, we wanted to define only one DISTRO feature (auto-prod) and list all our features under this distro. Also we wanted to control all these from a single place, so that enabling/disabling all the features in one shot would be easy and portable. We tried doing it using PACKAGECONFIG but it seems this option can be used only at a recipe level and not visible across all layers. We wanted to do something like this in: auto.conf DISTRO_FEATURES = "auto-prod" if defined (distro-features == auto-prod) ; then PACKAGECONFIG_append-pn-<recipe1> = "f1 f2 ..." PACKAGECONFIG_append-pn-<recipe2> = "f2 f3 ..." PACKAGECONFIG_append-pn-<recipe3> = "f1 f3 f4..." fi So, if we comment DISTRO_FEATURES all the features listed above should be automatically disabled. Note, our feature flags are used across multiple recipes and layers. Bootloader layer, Kernel, meta layer, recipe layer, python source, C source, scripts, etc. Like: edk2, meta-qti-bsp, meta-security, meta-qti-auto, auto-prod-folder, etc. Is there a well defined way in Yocto to achieve such a modular design approach ? If there are any such references please share. Our reference distro is here: https://source.codeaurora.org/quic/le/meta-qti-bsp/tree/conf/distro/auto.conf?h=yocto.lnx.3.0.c28 Thanks, Pintu
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: [qa-build-notification] QA notification for completed autobuilder build (yocto-3.1.14.rc1)
Teoh, Jay Shen
Hi All,
toggle quoted messageShow quoted text
This is the full report for yocto-3.1.14.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, Jay
-----Original Message-----
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: [qa-build-notification] QA notification for completed autobuilder build (yocto-3.4.2.rc2)
Teoh, Jay Shen
Hi all,
toggle quoted messageShow quoted text
Intel and WR YP QA is planning for QA execution for YP build yocto-3.4.2.rc2. We are planning to execute following tests for this cycle: OEQA-manual tests for following module: 1. OE-Core 2. BSP-hw Runtime auto test for following platforms: 1. MinnowTurbot 32-bit 2. Coffee Lake 3. NUC 7 4. NUC 6 5. Edgerouter 6. Beaglebone ETA for completion this Friday, Feb 18. Thanks, Jay
-----Original Message-----
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
M+ & H bugs with Milestone Movements WW07
Stephen Jolley
All,
Thanks,
Stephen K. Jolley Yocto Project Program Manager ( Cell: (208) 244-4460 * Email: sjolley.yp.pm@...
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Enhancements/Bugs closed WW07!
Stephen Jolley
All,
Thanks,
Stephen K. Jolley Yocto Project Program Manager ( Cell: (208) 244-4460 * Email: sjolley.yp.pm@...
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Current high bug count owners for Yocto Project 3.5
Stephen Jolley
All,
Thanks,
Stephen K. Jolley Yocto Project Program Manager ( Cell: (208) 244-4460 * Email: sjolley.yp.pm@...
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Yocto Project Newcomer & Unassigned Bugs - Help Needed
Stephen Jolley
All,
The triage team is starting to try and collect up and classify bugs which a newcomer to the project would be able to work on in a way which means people can find them. They're being listed on the triage page under the appropriate heading: https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs Also please review: https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded and how to create a bugzilla account at: https://bugzilla.yoctoproject.org/createaccount.cgi The idea is these bugs should be straight forward for a person to help work on who doesn't have deep experience with the project. If anyone can help, please take ownership of the bug and send patches! If anyone needs help/advice there are people on irc who can likely do so, or some of the more experienced contributors will likely be happy to help too.
Also, the triage team meets weekly and does its best to handle the bugs reported into the Bugzilla. The number of people attending that meeting has fallen, as have the number of people available to help fix bugs. One of the things we hear users report is they don't know how to help. We (the triage team) are therefore going to start reporting out the currently 401 unassigned or newcomer bugs.
We're hoping people may be able to spare some time now and again to help out with these. Bugs are split into two types, "true bugs" where things don't work as they should and "enhancements" which are features we'd want to add to the system. There are also roughly four different "priority" classes right now, “3.5, “3.6”, "3.99" and "Future", the more pressing/urgent issues being in "3.4" and then “3.5”.
Please review this link and if a bug is something you would be able to help with either take ownership of the bug, or send me (sjolley.yp.pm@...) an e-mail with the bug number you would like and I will assign it to you (please make sure you have a Bugzilla account). The list is at: https://wiki.yoctoproject.org/wiki/Bug_Triage_Archive#Unassigned_or_Newcomer_Bugs
Thanks,
Stephen K. Jolley Yocto Project Program Manager ( Cell: (208) 244-4460 * Email: sjolley.yp.pm@...
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|