> i know that -- in fact, it's the only way i use it -- the question
> is the purpose for checking if $BDIR is zero length first. that is,
> under what circumstances could it *not* be? even invoking the way you
> demonstrate, that variable is empty when tested, and i see nothing
> that could
> There is a non-hypothetical i386 loader, it already exists.
> Unfortunately the loader has to be downloaded and extracted in place
> before anything gets run so it all happens very early. Its done centrally with
> one uninative, not two or per recipe.
>
> I think you might be able to do
We have a vendor-provided cross-compiler toolchain that is distributed as
32-bit binaries. Naturally on my native system (outside of Yocto) I can run
them by first adding the i386 architecture to dpkg, and then doing "apt-get
install -y libc6-dbg:i386 lib32stdc++6 libzstd1:i386
One possible work around which I'm using for some prebuilt native binaries is
to call them with hosts loader (e.g. /lib32/ld-linux.so.2
${STAGING_BINDIR_NATIVE}/my-tool params)
Ooh, nice. Thanks for the tip! Definitely curious about a longer-term
workaround but this is good for the short term.
> > I suspect uninative assumes all binaries are for the main system
> > architecture so its probably trying to change the interpreter to a 64
> > bit one which clearly won't work in this case.
> >
> > It would be a question of stopping it for these binaries somehow...
>
> Maybe a matter of doing
> I suspect uninative assumes all binaries are for the main system architecture
> so its probably trying to change the interpreter to a 64 bit one which clearly
> won't work in this case.
>
> It would be a question of stopping it for these binaries somehow...
Maybe a matter of doing something
> "contains" has special magic where it caches the specific value presence
> rather than the whole string. I'd therefore recommend using the contains
> functions where at all possible for that reason.
So then regarding my other points, it is correctly handled by the signature
code? If so, why
> > So, is changing DISTRO_FEATURES but not changing the build directory
> > expected to work?
>
> Should work but has bugs.
>
> There were some fixed around the thud/zeus timeframe.
>
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=13702
>
> is a recently reported one that has patches in
There is a familiar message in sstate.bbclass that explains: "... It may be you
changed DISTRO_FEATURES from systemd to udev or vice versa. Cleaning those
recipes should again resolve this error, however switching DISTRO_FEATURES on
an existing build directory is not supported - you should
---
meta/recipes-core/meta/cve-update-db-native.bb | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/meta/recipes-core/meta/cve-update-db-native.bb
b/meta/recipes-core/meta/cve-update-db-native.bb
index 57368caf73..f8f13af97c 100644
---
For example, if you just run 'bitbake cve-update-db-native' in a clean
build system, |cve_tmp_file| won't exist yet.
Signed-off-by: Chris Laplante
---
meta/classes/cve-check.bbclass | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/meta/classes/cve-check.bbclass
Signed-off-by: Chris Laplante
---
.../recipes-core/meta/cve-update-db-native.bb | 90 ++-
1 file changed, 47 insertions(+), 43 deletions(-)
diff --git a/meta/recipes-core/meta/cve-update-db-native.bb
b/meta/recipes-core/meta/cve-update-db-native.bb
index 32d6dbdffc..2221825bf8
Previously CVE_CHECK_DB_FILE / CVE_CHECK_DB_DIR was the same across
multiconfigs which led to a race condition wherein multiple
cve-update-db-native:do_populate_cve_db tasks could attempt to write to
the same sqlite database. This led to the following task failure:
Error executing a python
> On Wed, 9 Sep 2020 at 18:35, Chris Laplante via lists.openembedded.org
> wrote:
> >
> > Previously CVE_CHECK_DB_FILE / CVE_CHECK_DB_DIR was the same
> across
> > multiconfigs which led to a race condition wherein multiple
> > cve-update-db-native:do_populate_cv
v1: initial
v2: use lockfile in cve-update-db-native as suggested by Ross Burton
Chris Laplante (4):
cve-update-db-native: add progress handler
cve-check/cve-update-db-native: use lockfile to fix usage under
multiconfig
cve-update-db-native: use context manager for cve_f
cve-check:
Previously CVE_CHECK_DB_FILE / CVE_CHECK_DB_DIR was the same across
multiconfigs which led to a race condition wherein multiple
cve-update-db-native:do_populate_cve_db tasks could attempt to write to
the same sqlite database. This led to the following task failure:
Error executing a python
Signed-off-by: Chris Laplante
---
.../recipes-core/meta/cve-update-db-native.bb | 90 ++-
1 file changed, 47 insertions(+), 43 deletions(-)
diff --git a/meta/recipes-core/meta/cve-update-db-native.bb
b/meta/recipes-core/meta/cve-update-db-native.bb
index 32d6dbdffc..2221825bf8
---
meta/recipes-core/meta/cve-update-db-native.bb | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/meta/recipes-core/meta/cve-update-db-native.bb
b/meta/recipes-core/meta/cve-update-db-native.bb
index d22b66f6c7..328f6ab364 100644
---
For example, if you just run 'bitbake cve-update-db-native' in a clean
build system, |cve_tmp_file| won't exist yet.
Signed-off-by: Chris Laplante
---
meta/classes/cve-check.bbclass | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/meta/classes/cve-check.bbclass
> > But the databases will be identical so that's basically a waste of
> > time. How about adding a lock file so the second task waits for the
> > first to complete, and then does nothing as the database is up to date?
>
> That's a good point. I also considered just making it a
It was always questionable to do this in an anonymous function, but now
with multiconfig it is a critical mistake and leads to more strange
"Exception: sqlite3.OperationalError: disk I/O error" errors.
Signed-off-by: Chris Laplante
---
meta/recipes-core/meta/cve-update-db-native.bb | 14
Signed-off-by: Chris Laplante
---
meta/recipes-core/meta/cve-update-db-native.bb | 1 -
1 file changed, 1 deletion(-)
diff --git a/meta/recipes-core/meta/cve-update-db-native.bb
b/meta/recipes-core/meta/cve-update-db-native.bb
index 242fbc2f30..cf2b251e21 100644
---
Signed-off-by: Chris Laplante
---
meta/recipes-core/meta/cve-update-db-native.bb | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/meta/recipes-core/meta/cve-update-db-native.bb
b/meta/recipes-core/meta/cve-update-db-native.bb
index e4e2451bfd..c2f713312f 100644
---
Hi Richard,
> Most recipe-sysroot dependencies are handled by these prefuncs. "configure"
> is special with a decidated task, prepare_recipe_sysroot which runs
> beforehand.
>
> do_prepare_recipe_sysroot does not have to be run before/after
> fetch/unpack/patch, they're independent tasks. If
> > Is this patch something that should be backported to zeus and friends?
>
> Its fixing a very rare problem that I only ran into whilst doing "interesting"
> things most people don't probably do.
>
> If people were running into those issues I'd backport but for master it was
> more a
Default behavior is not changed. To suppress patched CVEs, set:
CVE_CHECK_REPORT_PATCHED = ""
Signed-off-by: Chris Laplante
---
meta/classes/cve-check.bbclass | 38 --
1 file changed, 22 insertions(+), 16 deletions(-)
diff --git
The addition of this variable also makes it possible to change the
output suffix of the check files, e.g. in local.conf:
CVE_CHECK_MANIFEST_append = ".txt"
CVE_CHECK_RECIPE_FILE_append = ".txt"
Signed-off-by: Chris Laplante
---
meta/classes/cve-check.bbclass | 8
1 file changed, 4
Signed-off-by: Chris Laplante
---
meta/conf/bitbake.conf | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index a318d1ca58..e6338b0c75 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -701,7 +701,7 @@
Hi Richard,
> This looks interesting. Could we add something to the manual about how to
> use it and maybe a test for it as well please?
Halfway through writing the tests, and I realized
LOG_COLORIZER_SUPPRESS_COLORIZED_OUTPUT doesn’t quite work. I wrote a test
recipe with a do_compile that
> * Next week is ELC which is taking place virtually this year and Yocto Project
> has a presence there. There is also a virtual Yocto Project Developer Day:
> https://events.linuxfoundation.org/yocto-dev-day-north-america/
Does anyone know what the intended audience is for the Developer Day
Hi David,
> > "Does anyone know what the intended audience is for the Developer Day
> presentations?"
>
> The official description for the intended audience can be found here:
> https://www.yoctoproject.org/yocto-project-dev-day-virtual-north-america-
> 2020/
>
> We will be covering a lot of
> > Does anyone know what the intended audience is for the Developer Day
> presentations? E.g. would someone who uses bitbake day-to-day but perhaps
> doesn't edit recipes benefit?
> >
>
> I would say look at the schedule and see if there are talks of interest to
> you.
I did, but the schedule
Hi Richard,
> This looks interesting. Could we add something to the manual about how to
> use it and maybe a test for it as well please?
>
> I did write something similar in a different context recently which applies
> here near enough as well:
>
> """
> By documentation, I mean that
Hi Richard,
> You can run these tests individually with "oe-selftest -r imagefeatures" to
> run
> that file or "oe-selftest -r imagefeatures.ImageFeatures.test_bmap" as an
> example of a specific test.
I'm developing the tests for log colorizer and I had a question about
oe-selftest. Is there
This bbclass turns on compiler color diagnostics to make it easier to
visually interpret compiler errors and warnings. It can be used
per-recipe or globally (via INHERIT in local.conf).
You can set the LOG_COLORIZER_SUPPRESS_COLORIZED_OUTPUT variable to turn
off color output - this is intended
Signed-off-by: Chris Laplante
---
meta/classes/base.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index 4c681cc870..5a969b207a 100644
--- a/meta/classes/base.bbclass
+++ b/meta/classes/base.bbclass
@@ -12,7 +12,7
This progress handler intercepts log output, stripping any ANSII color
escape codes. Then the stripped output is fed to the underlying progress
handler which will render the progress bar as usual.
Signed-off-by: Chris Laplante
---
meta/lib/oe/log_colorizer.py | 86
This patch series turns on color compiler diagnostics. It is especially
useful when doing edit-compile-test development work with devtool.
It is based on one I've been using internally for about a
year now.
Limitation: Note that the *.nocolor and *.color logs will only contain the
output of the
From: Chris Laplante
This is because the test expects to find "do_package_write_rpm" in the
bitbake output.
Signed-off-by: Chris Laplante
---
meta/lib/oeqa/selftest/cases/bbtests.py | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/lib/oeqa/selftest/cases/bbtests.py
From: Chris Laplante
This is useful for people using Microsoft Exchange / Office 360, which
butchers patches causing author identity to be lost.
Signed-off-by: Chris Laplante
---
contrib/git-hooks/sendemail-validate.sample | 78 +
1 file changed, 78 insertions(+)
create
From: Chris Laplante
I didn't have time to dig into the npmsw fetcher to understand exactly
why the conflicts happen, but this fixes things in the meantime.
Chris Laplante (1):
classes/npm: utilize lockfile in do_fetch to avoid multiconfig
problems
meta/classes/npm.bbclass | 2 ++
1
From: Chris Laplante
The npmsw fetcher doesn't play nice with multiconfig for some reason.
Concurrent do_fetch tasks for npm recipes can try to download modules at
the same time to ${DL_DIR}/npm2, resulting in races and failed
downloads.
Signed-off-by: Chris Laplante
---
Hi Richard,
> >
> > +do_fetch[lockfiles] += "${DL_DIR}/npm2_fetch.lock"
> > +
> > def npm_global_configs(d):
> > """Get the npm global configuration"""
> > configs = []
>
> If its just multilib, you could put a ${BPN} in the lock name? or is it
> conflicting
> general recipes?
> > But it would happen even without multiconfig, if there is overlap in
> > the node modules that two recipes try to fetch. For some reason the
> > npmsw fetcher (or the proxy fetcher it is using, see
> > bitbake/lib/bb/fetch2/npmsw.py around lines 168-181) are not guarding
> > against two
Hi Anuj,
> Thanks, this is the right way to request a backport. But since this is a
> bitbake
> change, should have been sent to the bitbake list. I had picked this though so
> no need to re-send.
Ah right. Thank you!
Chris
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this
Hello,
> If the client process never sends cooker data, the server timeout will be 0.0,
> not None. This will prevent the server from exiting, as it is waiting for a
> new
> client. In particular, the client will disconnect with a bad "INHERIT" line,
> such
> as:
>
> INHERIT +=
From: Joshua Watt
From: Chris Laplante
If the client process never sends cooker data, the server timeout will
be 0.0, not None. This will prevent the server from exiting, as it is
waiting for a new client. In particular, the client will disconnect with
a bad "INHERIT" line, such as:
Hello all,
Can someone please clarify expected behavior of 'devtool modify virtual/kernel'
when the kernel recipe has an additional SRC_URI entry for the kernel-metadata
repository? For example, the 2021.1 linux-xlnx recipe in the meta-xilinx-bsp
layer (part of meta-xilkinx) uses the
Hi all,
We are using Yocto Zeus (yes, I know...) and I'm trying to track down some
reproducibility issues. My go-to tool is bitbake-diffsigs, but ever since we
started using multiconfig, the tool is pretty much useless with results like
this:
(where mc-one and mc-two are multiconfigs)
> On Thu, 14 Sept 2023 at 21:54, Richard Purdie
> wrote:
> > The tools are already supposed to support doing this with local file
> > sstate sources, they just do a bad job at getting the diffs right. One
> > intent of this work item was to try and understand why they don't work
> > and address
'imp' was deprecated in Python 3.4 and removed in 3.12. The
piece of importlib we use has been around since 3.3.
Signed-off-by: Chris Laplante
---
scripts/lib/recipetool/create_buildsys_python.py | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git
Hi Alexandre,
>
> Thank you for your patches!
>
> Could you remember changing your git config for your next submission:
> https://docs.yo/
> ctoproject.org%2Fnext%2Fcontributor-guide%2Fsubmit-
> changes.html%23fixing-your-from-
> identity=05%7C01%7Cchris.laplante%40agilent.com%7Cd8e4bf9a3b674c
>
From: Chris Laplante
Call _check_src_repo to confirm that the 'devtool' branch is setup as we
expect. This would have caught the basic case of the bug (i.e. where
override branches are not involved).
Signed-off-by: Chris Laplante
---
meta/lib/oeqa/selftest/cases/devtool.py | 1 +
1 file
From: Chris Laplante
Fixes a couple of different issues that all conspired to break 'devtool
modify' for many use cases with kernel-yocto recipes.
To explain, we need to consider the basic flow of how 'devtool modify'
works for a recipe using kernel-yocto.bbclass:
┌──┐
From: Chris Laplante
This relatively exhaustive test is designed to exercise the 'devtool
modify' workflow for kernel recipes, with a focus on SRC_URI override
branches.
Signed-off-by: Chris Laplante
---
meta/lib/oeqa/selftest/cases/devtool.py | 132
1 file changed,
Hi Richard,
Thanks for accepting my patch from a few days ago :). Just wanted to check if
you would like me to send more Python 3.12 compatibility patches. If there are
bigger fish to fry I will hold off, otherwise I'm happy to help with making
everything compatible.
P.S. I ask because I
If you individually run some of the devtool selftests, e.g. with:
oe-selftest -r devtool.DevtoolAddTests.test_devtool_add
then you bypass the sanity check in test_create_workspace that checks
for an existing workspace layer. Eventually, recipetool will be called
in a test, and
The tests will fail anyway (since you will have two 'workspacelayer'
layers), so might as well make it fail faster and be clear.
Signed-off-by: Chris Laplante
---
meta/lib/oeqa/selftest/cases/devtool.py | 36 ++---
1 file changed, 33 insertions(+), 3 deletions(-)
diff --git
Hi Bruce,
> > Is setting up MACHINE too invasive? Or do we come up with a way of only
> setting up override branches for overrides that are valid for the given
> local.conf? I lean towards the latter approach for simplicity.
> >
>
> I admit to not using devtool, and not following much of what
> From: Chris Laplante
>
> Fixes a couple of different issues that all conspired to break 'devtool
> modify' for
> many use cases with kernel-yocto recipes.
>
> To explain, we need to consider the basic flow of how 'devtool modify'
> works for a recipe using kernel-yocto.bbclass:
>
>
> Ugh, actually this needs more work. If a recipe sets KBUILD_DEFCONFIG based
> on MACHINE overrides, then the no-override case will explode when we call
> 'kernel_pre_patch(localdata)'. Since in that case, KBUILD_DEFCONFIG will be
> unset.
Actually, this approach is problematic in general
> Hello,
>
> The series causes:
>
> 2023-10-17 23:07:15,509 - oe-selftest - INFO -
> devtool.DevtoolUpgradeTests.test_devtool_modify_kernel_overrides
> (subunit.RemotedTestCase)
> 2023-10-17 23:07:15,675 - oe-selftest - INFO - ... FAIL
> Stderr:
> 2023-10-17 22:28:35,773 - oe-selftest - INFO -
Hi Alexandre,
> The series causes:
>
> 2023-10-17 23:07:15,509 - oe-selftest - INFO -
> devtool.DevtoolUpgradeTests.test_devtool_modify_kernel_overrides
> (subunit.RemotedTestCase)
> 2023-10-17 23:07:15,675 - oe-selftest - INFO - ... FAIL
> Stderr:
> 2023-10-17 22:28:35,773 - oe-selftest - INFO
> FYI I also sent a patch to fix this issue the day just before you :) You can
> find it
> here:
> https://lists.op/
> enembedded.org%2Fg%2Fopenembedded-
> core%2Fmessage%2F188767=05%7C01%7Cchris.laplante%40agilent.com
> %7C34ce8f731f6f4590172108dbc89c6739%7Ca9c0bc098b46420693512ba12fb
>
We're using honister. We have a recipe that generates a device tree using
devicetree.bbclass. It doesn't do anything special:
SRC_URI = file://system-top.dts
DT_INCLUDE:append = " ${THISDIR}/files"
COMPATIBLE_MACHINE:zynq = "zynq"
inherit devicetree
It's unclear to me how this
Hello,
We're using honister. We have a recipe that generates a device tree using
devicetree.bbclass. It doesn't do anything special:
SRC_URI = file://system-top.dts
DT_INCLUDE:append = " ${THISDIR}/files"
COMPATIBLE_MACHINE:zynq = "zynq"
inherit devicetree
It's unclear to me
We're using honister. We have a recipe that generates a device tree using
devicetree.bbclass. It doesn't do anything special:
SRC_URI = file://system-top.dts
DT_INCLUDE:append = " ${THISDIR}/files"
COMPATIBLE_MACHINE:zynq = "zynq"
inherit devicetree
It's unclear to me how this
> The bitbake-layers command is needed only to generate the layer config file
> (in json format) out of an already existing yocto setup. It does not perform
> the actual layer fetch/setup from the json. That's the feature I like the most
> in my proposal: none of the other tools bootstrap the
Hi all,
Today I'm excited to publish a tool I've been developing internally for about a
year now. It is called 'yb', and you can think of it like a cross between kas,
Google's repo, and myrepos (mr).
Project page: https://github.com/Agilent/yb
Download it here:
Hi Alex,
> do you think any of these pieces could be moved to 'official yocto',
> specifically as bitbake-layers subcommands? I read through the README, and
> it seems that things like 'status' and 'run' would fit very well there.
I would agree that 'status' and 'run' would be useful additions,
Hi Khem,
> opengl in OE context is usually not the same as desktop GL, it means the
> distro
> needs OpenGL supported from the platform.
> It is then accentuated by other things like egl glesv2, glx etc. I think we
> could
> make it a bit better but this is something that sits in the middle of
Hi all,
Just want to check my understanding on something. It seems to me that the
Weston having:
REQUIRED_DISTRO_FEATURES = "wayland opengl
${@oe.utils.conditional('VIRTUAL-RUNTIME_init_manager', 'systemd', 'pam', '',
d)}"
...is overly restrictive because 'opengl' implies desktop OpenGL,
72 matches
Mail list logo
