|
Re: SCM usage in source urls and bandwidth
Ross Burton <ross@...>
On Wed, 30 Mar 2022 at 12:10, Richard Purdie
<richard.purdie@...> wrote: f) Switch the problematic recipes to use shallow clones with something like:Even without premirrors this is a lot faster for glibc: $ time git clone git://sourceware.org/git/glibc.git Cloning into 'glibc'... remote: Enumerating objects: 6956, done. remote: Counting objects: 100% (6956/6956), done. remote: Compressing objects: 100% (2938/2938), done. remote: Total 670093 (delta 5328), reused 4750 (delta 3932), pack-reused 663137 Receiving objects: 100% (670093/670093), 205.19 MiB | 16.39 MiB/s, done. Resolving deltas: 100% (573265/573265), done. Updating files: 100% (19011/19011), done. real 1m56.255s $ time git clone git://sourceware.org/git/glibc.git --depth 1 Cloning into 'glibc'... remote: Enumerating objects: 18809, done. remote: Counting objects: 100% (18809/18809), done. remote: Compressing objects: 100% (9704/9704), done. remote: Total 18809 (delta 8812), reused 12185 (delta 7968), pack-reused 0 Receiving objects: 100% (18809/18809), 41.79 MiB | 11.96 MiB/s, done. Resolving deltas: 100% (8812/8812), done. Updating files: 100% (19011/19011), done. real 0m8.701s A full clone fetches 200MB and takes 2 minutes (a lot of that is actually resolving the deltas, not the fetch). A shallow clone of the current HEAD fetches 40MB and is done in 8 seconds. Why would we need a premirror? Ross
|
|
|
|
Re: SCM usage in source urls and bandwidth
Richard Purdie
On Wed, 2022-03-30 at 11:42 +0100, Richard Purdie via lists.yoctoproject.org
wrote: What are our options? As far as I can see we could:I meant to add: f) Switch the problematic recipes to use shallow clones with something like: BB_GIT_SHALLOW:pn-binutils = "1" BB_GIT_SHALLOW:pn-binutils-cross-${TARGET_ARCH} = "1" BB_GIT_SHALLOW:pn-binutils-cross-canadian-${TRANSLATED_TARGET_ARCH} = "1" BB_GIT_SHALLOW:pn-binutils-cross-testsuite = "1" BB_GIT_SHALLOW:pn-binutils-crosssdk-${SDK_SYS} = "1" BB_GIT_SHALLOW:pn-glibc = "1" The challenge here is that in order to be effective, there needs to be a PREMIRROR setup with the shallow tarballs on it. This means we couldn't do e) above and have this have much effect unless we craft some very specific PREMIRROR entries too. Cheers, Richard
|
|
|
|
SCM usage in source urls and bandwidth
Richard Purdie
[list address fixed, sorry]
We've been having bandwidth trouble with downloads.yoctoproject.org so we did some quick analysis to see what the issue is. Basically in speeding up the server which was the rate limit, we hit the limits of the hosting pipe. I'd note a few things: a) it isn't the sstate mirroring, it is nearly all being used by downloads. b) 25% of all our bandwidth is going on "git2_sourceware.org.git.binutils- gdb.git.tar.gz" - i.e. downloading the source mirror binutils tarball c) 15% is on git2_sourceware.org.git.glibc.git.tar.gz i.e. glibc d) OE-Core has downloads.yoctoproject.org as a MIRROR e) poky has it as a PREMIRROR What are our options? As far as I can see we could: a) increase the pipe from downloads.yoctoproject.org but that does come at a non-trivial cost to the project. b) Seek help with hosting some of the larger mirror tarballs from people better able to host them and have that as a first premirror? c) Switch the binutils and glibc recipes to tarballs and patches. I know Khem finds this less convenient and they keep moving back and forward but we keep running into this issue and having to switch back from git. d) To soften the blow of c) we could add devupstream support to the recipes? We could script updating the recipe to add the patches? e) We could drop the PREMIRRORS from poky. This would stop the SCM targets from hitting our mirrors first. That does transfer load to the upstream project SCMs though and I'm not sure that will be appreciated. I did sent that patch, I'm not sure about it though. We are going to need to do *something* though as the current situation can't continue. I'm open to other ideas... Cheers, Richard
|
|
|
|
Re: [OE-core] Which vendors maintain SDIO WiFi in mainline stable kernel
Quentin Schulz
Hi Jupiter,
On 3/29/22 07:16, JH wrote: Hi,It is extremely rare to have vendors not have out-of-tree drivers or forked branches (I don't know of any, personally). Some vendors do end up upstreaming some of their patches in the end to reduce the amount of maintenance they have to do on their downstream drivers/kernel tree. Upstreaming takes time, knowledge and soft (as in "communicating with people") skills that some vendors aren't willing to invest in. It's also usually not an urgent matter (as opposed to have *something* that works, so they can sell the product ASAP). Also, quality of vendor (understand downstream) code is often subpar (to be polite) and would not be accepted as-is in Linux kernel upstream git repository. Finally, it is also a strategical choice for vendors to have an out-of-tree driver so that people stuck with an older kernel can still use this driver/product. One simple example: a bad vendor sells you an SoC with BSP supporting kernel 4.4 (let's say). Now, you want to use a specific WiFi module with this SoC. Fortunately, there's upstream support for it, but only in 5.10 and later. Considering the number of changes between 4.4 and 5.10, you won't be able to easily backport the driver to work on 4.4. This means the WiFi module vendor loses you as a customer because you wont be able to use their solution. Now, you could also have a nicer SoC vendor which provides you with a 5.10 kernel. However, there's an important fix available in 5.16 that isn't in the WiFi driver you have on 5.10. You could try to backport this yourself but not all customers of said WiFi vendor are skilled enough to do this. The WiFi vendor needs to provide support for backporting this for the customer and/or deal with unhappy customers. However, with an out-of-tree driver with appropriate ifdefs everywhere to adapt for specific versions of the Linux kernel ABI, they have ONE driver that is known to work on many different Linux kernel versions. It also makes the maintenance of the driver much more simple for them. This also allows them to do releases much more often than the Linux kernel allows (one every 2-3 months). Considering the usually bad quality of code and maybe lack of proper reviews, you might end up with regressions and more importantly security issues that will never be discovered because less eyes will be on the code. Out-of-tree drivers make sense in a self-feeding loop of vendors not upstreaming stuff because they need to support other vendors not upstreaming, even if they wanted to in the first place. Finally, I've had to patch locally about 3-4 WiFi drivers and the changes weren't implemented by the vendor in the next releases. So you might just have issues other companies have fixed but it was never reported or fixed by the vendor. (Note that upstreaming does not necessarily fix this issue, it just makes it in theory less likely to happen since more people are supposed to use it than some vendor kernel). Also, some vendors are historically reluctant to contribute anything to the upstream Linux kernel and the support of their hardware was added by hobbyists or one of their clients, bearing the costs themselves. I looked at the following link, the mwifiex and mwifiex_sdio supportYou'd need to request the newer versions of mwifiex to NXP (which acquired Marvell some years ago) or patch it yourself. Welcome to the world of downstream support :) Same to Qualcomm, the old Atheros WiFi modules are supported, theYocto only builds what you tell it to build. The company I work for provides[1] Yocto support for a vendor kernel based on Android-flavored 4.4 (note: though we do actually support and encourage using mainline, GPU/VPU support was - years ago - just not comparable between vendor and upstream kernels) for our System on Module, all of this on Honister (latest release of Yocto to date). You just need to create your own recipe (or adapt an existing one) to point to the BSP components your vendor gave you (or whatever you want to use) and build it. Nothing forces you to use linux-yocto 5.14 or whatever else. [1] https://git.theobroma-systems.com/yocto-layers/meta-theobroma-systems-bsp.git/tree/recipes-kernel/linux/linux-tsd_4.4.bb Cheers, Quentin
|
|
|
|
Running chromium with read-only-rootfs
benabid.houssem11@...
Hello Friends ; I have My own Image based on Wayland-Weston image. My Image should be on read-only- rootfs so i use this : can someone help me to configure this VOLATILE-BINDS to get the work done. The Error when running chromium in my image is : Error /root/.config/**/** is read-only Thanks in advance
|
|
|
|
Re: Strange sporadic build issues (incremental builds in docker container)
Matthias Klein
Hi Trevor,
thank you very much for the detailed answer. Yes, you are right, it is mostly the same recipes that fail. But they also change from time to time. Today it happened to me even without Jenkins and Docker, normally in the console with the recipe keymaps_1.0.bb. With the nighly builds over the Jenkins I help myself at the moment that I delete build/tmp before. So far, the problem has not occurred again. Many greetings, Matthias -----Ursprüngliche Nachricht----- Von: Trevor Woerner <twoerner@...> Gesendet: Dienstag, 29. März 2022 18:23 An: Alexander Kanavin <alex.kanavin@...> Cc: Matthias Klein <matthias.klein@...>; yocto@... Betreff: Re: [yocto] Strange sporadic build issues (incremental builds in docker container) 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?
|
|
|
|
Re: OpenEmbedded Happy Hour March 30 5pm/1700 UTC
Denys Dmytriyenko
Reminder, OpenEmbedded Happy Hour is tomorrow. See you all there.
toggle quoted messageShow quoted text
On Thu, Mar 24, 2022 at 06:41:58PM -0400, Denys Dmytriyenko wrote:
All, --
Regards, Denys Dmytriyenko <denis@...> PGP: 0x420902729A92C964 - https://denix.org/0x420902729A92C964 Fingerprint: 25FC E4A5 8A72 2F69 1186 6D76 4209 0272 9A92 C964
|
|
|
|
[yocto 3.1] adding custom testsdk script in own layer
Karthik Poduval
Hi All, We were trying to add a custom sdktest script as shown in example https://docs.yoctoproject.org/test-manual/intro.html#testsdk. The script gets invoked when placed in meta/lib/oeqa/sdk/cases/mysdktest.py However when placed under. <my layer>/lib/oeqa/sdk/cases/mysdktest.py It does not get invoked when running bitbake <my image> -c testsdk The testimage scripts do work when placed under <my layer>/lib/oeqa/runtime/cases/ as they are controlled by the TEST_SUITES variable. Kindly advise on how to proceed. -- Regards, Karthik Poduval
|
|
|
|
Re: firewalld isssue
#yocto
On 2022-03-28 03:18, Nicolas Jeker wrote:
On Sun, 2022-03-27 at 23:39 -0700, sateesh m wrote:Trevor was looking into this as well so I've CCed him.Hi Team,Judging by this stack exchange thread[1] from a quick search, you might ../Randy --JSON blob: # Randy MacLeod # Wind River Linux
|
|
|
|
[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 messageShow 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 messageShow 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.
|
|
|