|
[meta-security][PATCH 1/1] LICENSE: adopt SPDX standard names
Joe Slater <joe.slater@...>
From: Robert Yang <liezhi.yang@...>
Modify LICENSE for ding-libs and libmhash. Signed-off-by: Joe Slater <joe.slater@...> --- recipes-security/libdhash/ding-libs_0.6.1.bb | 2 +- recipes-security/libmhash/libmhash_0.9.9.9.bb | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/recipes-security/libdhash/ding-libs_0.6.1.bb b/recipes-security/libdhash/ding-libs_0.6.1.bb index 6046fa0..843850f 100644 --- a/recipes-security/libdhash/ding-libs_0.6.1.bb +++ b/recipes-security/libdhash/ding-libs_0.6.1.bb @@ -2,7 +2,7 @@ SUMMARY = "Dynamic hash table implementation" DESCRIPTION = "Dynamic hash table implementation" HOMEPAGE = "https://fedorahosted.org/released/ding-libs" SECTION = "base" -LICENSE = "GPLv3+" +LICENSE = "GPL-3.0-or-later" LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504" SRC_URI = "https://fedorahosted.org/released/${BPN}/${BP}.tar.gz" diff --git a/recipes-security/libmhash/libmhash_0.9.9.9.bb b/recipes-security/libmhash/libmhash_0.9.9.9.bb index 9b34cb1..35c5ff8 100644 --- a/recipes-security/libmhash/libmhash_0.9.9.9.bb +++ b/recipes-security/libmhash/libmhash_0.9.9.9.bb @@ -7,7 +7,7 @@ DESCRIPTION = "\ " HOMEPAGE = "http://mhash.sourceforge.net/" -LICENSE = "LGPLv2.0" +LICENSE = "LGPL-2.0-only" LIC_FILES_CHKSUM = "file://COPYING;md5=3bf50002aefd002f49e7bb854063f7e7" S = "${WORKDIR}/mhash-${PV}" -- 2.35.1 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: Yocto poky/meta/recipes-devtool/perl
Alexander Kanavin
Can you please attach log.do_patch where the problem can be seen?
toggle quoted message
Show quoted text
Alex On Tue, 29 Mar 2022 at 15:11, Mike Ulan <mausvt@...> wrote:
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: [meta-security][PATCH 1/1] LICENSE: adopt standard SPDX names
Joe Slater <joe.slater@...>
I'll send again for ding-libs and libmhash. Joe
toggle quoted message
Show quoted text
-----Original Message----- |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: [meta-security][PATCH 1/1] LICENSE: adopt standard SPDX names
On 3/29/22 09:18, Joe Slater wrote:
Correct LICENSE for samhain, ecrypt-utils, ding-libs,Mater-next has these. https://git.yoctoproject.org/meta-security/commit/?h=master-next&id=ece41f7543bbd42c57f4208c7309f90cbd02e852 Looks like a few more need to be added based on these changes. -armin
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: [meta-security][PATCH] openscap-daemon: inherit python_setuptools_build_meta
On 3/27/22 19:25, Chen Qi wrote:
setuptools_build_meta has been renamed to python_setuptools_build_meta.I believe this is sitting in master-next. https://git.yoctoproject.org/meta-security/commit/?h=master-next&id=398047a7a6310b1ef70d22430fb6df4effd8cf92 S = "${WORKDIR}/git" |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: Strange sporadic build issues (incremental builds in docker container)
Trevor Woerner
On Thu 2022-03-24 @ 09:31:25 AM, Alexander Kanavin wrote:
I don't. You need to inspect the build tree to find clues why theYes I've been seeing exactly these issues as well. I'm not using any sort of virtualization, I'm using Jenkins to do nightly builds directly on my host. My host machine is openSUSE 15.3. These problems started on Feb 21 for me. Each of my builds starts by doing a "git pull" on each of the repositories, then kicks off a build if any of the repositories changed. A fresh build will always succeed. Doing a "clean" and rebuilding will (I believe) always succeed. My gut feeling is that it somehow has something to do with having an existing build, refreshing the repositories, then rebuilding. I spent weeks trying to find a reproducer. I wrote a script to checkout one version of the repositories (before), build, checkout a newer version of the repositories (after) and rebuilding. Even in cases where I used the exact same hashes that had failed on my Jenkins build and repeating 20 times, in some cases I wasn't able to reproduce the error. I was able to find 1 reproducer involving a build for an imx28evk MACHINE, but even then after 20 iterations 13 were bad and 7 were good. I repeated that set of 20 builds many times and it was never 100% bad. My investigations led me to believe that it might be related to rm_work and/or BB_NUMBER_THREADS/PARALLEL_MAKE. In my Jenkins builds I enable 'INHERIT += "rm_work"' and I also limit the BB_NUMBER_THREADS and set PARALLEL_MAKE. On the cmdline I was able to reduce the number of failures (sometimes to none) by removing the rm_work and THREADS/PARALLEL, but never completely eliminate it. In Jenkins the build failures still felt as random as they were without the change, so I can't say that it's having much effect in Jenkins, but seems to have some effect on the cmdline. I can say this with certainty: Matthias says it seems that the specific recipe that fails is random, but it's not. In every case the recipe that fails is a recipe whose source files are contained in the meta layer itself. For me the failing recipes were always: modutils-initscripts initscripts If you look at the recipes for those packages they do not have a SRC_URI that fetches code from some remote location then uses quilt to apply some patches. In both cases all of the "source" code exists in the layer itself, and somehow quilt is involved in placing them in the build area. I have dozens and dozens of these failures recorded and it is always with a recipe that follows that pattern. But 99%-ish percent of the failures are with the two packages I listed above. The failures aren't related to days when those packages change. The failures are just... sporadic. So the issue is related to: - recipes with in-layer sources - quilt (being run twice (?)) - updating layers, and rebuilding in a build area with an existing build - Feb 21 2022 (or thereabouts) The issue might be related to: - jenkins? - my build host? - rm_work? - BB_NUMBER_THREADS? - PARALLEL_MAKE? |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
[meta-security][PATCH 1/1] LICENSE: adopt standard SPDX names
Joe Slater <joe.slater@...>
Correct LICENSE for samhain, ecrypt-utils, ding-libs,
libmhash, and sssd. Signed-off-by: Joe Slater <joe.slater@...> --- recipes-ids/samhain/samhain.inc | 2 +- recipes-security/ecryptfs-utils/ecryptfs-utils_111.bb | 2 +- recipes-security/libdhash/ding-libs_0.6.1.bb | 2 +- recipes-security/libmhash/libmhash_0.9.9.9.bb | 2 +- recipes-security/sssd/sssd_2.5.2.bb | 2 +- 5 files changed, 5 insertions(+), 5 deletions(-) diff --git a/recipes-ids/samhain/samhain.inc b/recipes-ids/samhain/samhain.inc index 077e118..fe0718d 100644 --- a/recipes-ids/samhain/samhain.inc +++ b/recipes-ids/samhain/samhain.inc @@ -1,6 +1,6 @@ DESCRIPTION = "Provides file integrity checking and log file monitoring/analysis" HOMEPAGE = "http://www.la-samhna.de/samhain/" -LICENSE = "GPLv2" +LICENSE = "GPL-2.0-only" LIC_FILES_CHKSUM = "file://LICENSE;md5=8ca43cbc842c2336e835926c2166c28b" PV = "4.4.6" diff --git a/recipes-security/ecryptfs-utils/ecryptfs-utils_111.bb b/recipes-security/ecryptfs-utils/ecryptfs-utils_111.bb index 9aefc32..5f8cf3c 100644 --- a/recipes-security/ecryptfs-utils/ecryptfs-utils_111.bb +++ b/recipes-security/ecryptfs-utils/ecryptfs-utils_111.bb @@ -6,7 +6,7 @@ DESCRIPTION = "eCryptfs is a stacked cryptographic filesystem \ HOMEPAGE = "https://launchpad.net/ecryptfs" SECTION = "base" -LICENSE = "GPL-2.0" +LICENSE = "GPL-2.0-only" LIC_FILES_CHKSUM = "file://COPYING;md5=8ca43cbc842c2336e835926c2166c28b" DEPENDS = "keyutils libgcrypt intltool-native glib-2.0-native" diff --git a/recipes-security/libdhash/ding-libs_0.6.1.bb b/recipes-security/libdhash/ding-libs_0.6.1.bb index 6046fa0..843850f 100644 --- a/recipes-security/libdhash/ding-libs_0.6.1.bb +++ b/recipes-security/libdhash/ding-libs_0.6.1.bb @@ -2,7 +2,7 @@ SUMMARY = "Dynamic hash table implementation" DESCRIPTION = "Dynamic hash table implementation" HOMEPAGE = "https://fedorahosted.org/released/ding-libs" SECTION = "base" -LICENSE = "GPLv3+" +LICENSE = "GPL-3.0-or-later" LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504" SRC_URI = "https://fedorahosted.org/released/${BPN}/${BP}.tar.gz" diff --git a/recipes-security/libmhash/libmhash_0.9.9.9.bb b/recipes-security/libmhash/libmhash_0.9.9.9.bb index 9b34cb1..35c5ff8 100644 --- a/recipes-security/libmhash/libmhash_0.9.9.9.bb +++ b/recipes-security/libmhash/libmhash_0.9.9.9.bb @@ -7,7 +7,7 @@ DESCRIPTION = "\ " HOMEPAGE = "http://mhash.sourceforge.net/" -LICENSE = "LGPLv2.0" +LICENSE = "LGPL-2.0-only" LIC_FILES_CHKSUM = "file://COPYING;md5=3bf50002aefd002f49e7bb854063f7e7" S = "${WORKDIR}/mhash-${PV}" diff --git a/recipes-security/sssd/sssd_2.5.2.bb b/recipes-security/sssd/sssd_2.5.2.bb index 8bc8787..9f1d627 100644 --- a/recipes-security/sssd/sssd_2.5.2.bb +++ b/recipes-security/sssd/sssd_2.5.2.bb @@ -2,7 +2,7 @@ SUMMARY = "system security services daemon" DESCRIPTION = "SSSD is a system security services daemon" HOMEPAGE = "https://pagure.io/SSSD/sssd/" SECTION = "base" -LICENSE = "GPLv3+" +LICENSE = "GPL-3.0-or-later" LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504" DEPENDS = "acl attr openldap cyrus-sasl libtdb ding-libs libpam c-ares krb5 autoconf-archive" -- 2.35.1 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
[PATCH yocto-autobuilder-helper] config.json: no need to explicitly exclude the NPM tests
Ross Burton <ross@...>
These tests now skip themselves automatically[1] if meta-oe isn't
present, so there is no need to explicitly skip them. [1] oe-core d22ed015d8f38241acb783e1a468fb15d4317670 Signed-off-by: Ross Burton <ross.burton@...> --- config.json | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/config.json b/config.json index 6a77ca8..2ac151d 100644 --- a/config.json +++ b/config.json @@ -190,7 +190,7 @@ }, "step2" : { "shortname" : "OE Selftest", - "EXTRACMDS" : ["${SCRIPTSDIR}/checkvnc; OEQA_DEBUGGING_S= AVED_OUTPUT=3D${BASE_SHAREDDIR}/pub/repro-fail/ DISPLAY=3D:1 oe-selftest = --skip-tests distrodata.Distrodata.test_checkpkg buildoptions.SourceMirro= ring.test_yocto_source_mirror devtool.DevtoolAddTests.test_devtool_add_np= m recipetool.RecipetoolTests.test_recipetool_create_npm reproducible -T m= achine -T toolchain-user -T toolchain-system -j 15"], + "EXTRACMDS" : ["${SCRIPTSDIR}/checkvnc; OEQA_DEBUGGING_S= AVED_OUTPUT=3D${BASE_SHAREDDIR}/pub/repro-fail/ DISPLAY=3D:1 oe-selftest = --skip-tests distrodata.Distrodata.test_checkpkg buildoptions.SourceMirro= ring.test_yocto_source_mirror reproducible -T machine -T toolchain-user -= T toolchain-system -j 15"], "ADDLAYER" : ["${BUILDDIR}/../meta-selftest"] }, "step3" : { @@ -407,7 +407,7 @@ "extravars" : [ "RPM_GPG_SIGN_CHUNK =3D '1'" ], - "EXTRACMDS" : ["${SCRIPTSDIR}/checkvnc; DISPLAY=3D:1 oe-= selftest --skip-tests distrodata.Distrodata.test_checkpkg buildoptions.So= urceMirroring.test_yocto_source_mirror devtool.DevtoolAddTests.test_devto= ol_add_npm recipetool.RecipetoolTests.test_recipetool_create_npm -T machi= ne -T toolchain-user -T toolchain-system -j 15"], + "EXTRACMDS" : ["${SCRIPTSDIR}/checkvnc; DISPLAY=3D:1 oe-= selftest --skip-tests distrodata.Distrodata.test_checkpkg buildoptions.So= urceMirroring.test_yocto_source_mirror -T machine -T toolchain-user -T to= olchain-system -j 15"], "ADDLAYER" : ["${BUILDDIR}/../meta-selftest"] } }, --=20 2.25.1 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Yocto Project Status WW132`22
Stephen Jolley
Current Dev Position: YP 3.5 M4 Next Deadline: 4th April. 2022 YP 3.5 M4 build
Next Team Meetings:
Key Status/Updates:
We did work out the cause of the infamous tinfoil wait_event intermittent issue.
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@...
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Yocto poky/meta/recipes-devtool/perl
Mike Ulan
Hi, I have the question: is anybody aware that patches in a recipe are not fully applied?When retrieved the archive for package unpacked. Аttributes of multiple files are set as readonly. or for 5.22.1 and 5.22 and 5.20 http://www.cpan.org/src/5.0/${BP}.tar.xz lots of read only files in archives. Form man of Patch behavior --read-only=warn by default. So files to be patched with read only attributes remain unchanged. For override patch default behavior on --read-only, i placed in poky/bitbake/bin file with name patch and content: #!/bin/sh /usr/bin/patch --read-only=fail "$@" exvar=$? echo "patch wraper readonly fail" "$@" perror $exvar exit $exvar And as a clearly predictable result, the build of perl failed. To fix problem and apply all patches and particularly my patch to backport issue for my host environment I added to perl_${PV}.bb recipe this: do_patch_prepend() { os.system('chmod -R +rw %s' % d.getVar('S')) } |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: [OE-core] Which vendors maintain SDIO WiFi in mainline stable kernel
Fabio Estevam <festevam@...>
Hi Jupiter,
On Tue, Mar 29, 2022 at 3:16 AM JH <jupiter.hce@...> wrote: The QCA9377 is well supported in the mainline kernel by the ath10k driver: drivers/net/wireless/ath/ath10k/ Just use 5.10 or 5.15 stable tree and there will be no need to use an out-of-tree driver for QCA9377. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: [OE-core] Which vendors maintain SDIO WiFi in mainline stable kernel
Federico Pellegrin
Hi Jupiter, I cannot help you on the specific chip you ask, but responding to the second part of your question I have quite good experience with Microchip WILC1000/3000 on SDIO which, after a part separate repo and then staging, is now in mailine from quite some time: https://github.com/torvalds/linux/tree/master/drivers/net/wireless/microchip/wilc1000 I had also some mixed experience (seemed to be arch releated) otherwise also with SDIO/SPI of SiLabs which is currently in mainline staging: https://github.com/torvalds/linux/tree/master/drivers/staging/wfx These chips are at least currently still on the market (modulo shortage problems), not sure about their projected lifespan (I guess something hard to foresee). Cheers, Federico Il giorno mar 29 mar 2022 alle ore 08:16 JH <jupiter.hce@...> ha scritto: Hi, |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Which vendors maintain SDIO WiFi in mainline stable kernel
JH
Hi,
I could not understand why so many large WiFi chip vendors retreat to stop maintaining WiFi SDIO chips to mainline Linux kernel, and to settle it's chip support to out of the tree, use its own SDK and proprietary kernel tree to source.codeaurora.org or private repository which are not compatible to mainline stable kernel, the kernel configures are also different. I looked at the following link, the mwifiex and mwifiex_sdio support the Marvell (NXP) 88W88 chipset, but only kernel 4.19 was able to build and to run, kernel 5 cannot support 88W88 chipset, any more. Same to Qualcomm, the old Atheros WiFi modules are supported, the QCA-9377-3 chipset is in source.codeaurora.org only supported by old kernel 4.9. Given the OE/Yocto poky kernel build is based on a mainline stable kernel repository, how can I build kernel 5 for 88W88 chipset or QCA-9377-3 from source.codeaurora.org or private repository? Or which WiFi vendors are still well maintaining the WiFi chips for kernel 5, the only sensible solution is to switch WiFi SDIO chips? Appreciate your advice and comments. https://wireless.wiki.kernel.org/en/users/drivers Thank you very much. Kind regards, jupiter |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
M+ & H bugs with Milestone Movements WW13
Stephen Jolley
All,
Thanks,
Stephen K. Jolley Yocto Project Program Manager ( Cell: (208) 244-4460 * Email: sjolley.yp.pm@...
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Enhancements/Bugs closed WW13!
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 400 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.5" and then “3.6”.
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@...
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
psplash: Wrong spashscreen resolution in case of two displays with different resolution
Vasyl Vavrychuk
Hi,
In my system I have two displays (virtual) with different resolution first: 1080x1920 (portrait orientation) second: 640x720 When psplash is run, it shows boot animation with resolution 640x720 on the first display too: +-----------+-----+ | | | | psplash | | | | | | | | +-----------+ | | | | | | Display 1 | | | | | +-----------------+ +-----------+ | | | psplash | | Display 2 | | | +-----------+ Can we achieve 1080x1920 resolution on Display 1? I worth case I don't need boot animation on display 2. Is DRM/KMS backend needed for that? Kind regards, Vasyl |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: QA notification for completed autobuilder build (yocto-3.4.3.rc1)
Teoh, Jay Shen
Hello everyone,
toggle quoted message
Show quoted text
This is the full report for yocto-3.4.3.rc3: 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: firewalld isssue
#yocto
Nicolas Jeker
On Sun, 2022-03-27 at 23:39 -0700, sateesh m wrote:
Hi Team,Judging by this stack exchange thread[1] from a quick search, you might be missing the appropriate kernel configs[2]. [1]: https://unix.stackexchange.com/questions/632113 [2]: https://wiki.gentoo.org/wiki/Nftables#Kernel
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|