Re: [OE-core] [meta-oe][PATCH] libva: Removed virtual/mesa dependency
On 4/24/20 8:01 AM, Bartłomiej Burdukiewicz wrote: > Mesa can be compiled with libva support, in order to avoid recursive > dependency between mesa and libva, virtual/mesa must be removed > from libva recipe. > > Signed-off-by: Bartłomiej Burdukiewicz > --- > meta/recipes-graphics/libva/libva_2.6.1.bb | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/meta/recipes-graphics/libva/libva_2.6.1.bb > b/meta/recipes-graphics/libva/libva_2.6.1.bb > index 92cea83bc1..c1a441a18b 100644 > --- a/meta/recipes-graphics/libva/libva_2.6.1.bb > +++ b/meta/recipes-graphics/libva/libva_2.6.1.bb > @@ -23,7 +23,7 @@ SRC_URI[sha256sum] = > "6c57eb642d828af2411aa38f55dc10111e8c98976dbab8fd62e4862940 > > UPSTREAM_CHECK_URI = "https://github.com/intel/libva/releases; > > -DEPENDS = "libdrm virtual/mesa" > +DEPENDS = "libdrm" I am not sure how it will work with non-mesa graphics stacks. Or is it non-issue ? > > inherit meson pkgconfig features_check > > > > > signature.asc Description: OpenPGP digital signature -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#137456): https://lists.openembedded.org/g/openembedded-core/message/137456 Mute This Topic: https://lists.openembedded.org/mt/73242971/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH 1/3] python3-pbr: change shebang to python3
On 4/24/20 5:40 AM, Richard Purdie wrote: > On Fri, 2020-04-24 at 09:09 +0800, Changqing Li wrote: >> From: Changqing Li >> >> we have offcially dropped python2, so it is possible >> that our code run on python3 only host, so change >> shebang to python3 to avoid error like: >> python: command not found > > I worry this is going to be the start of a huge pile or unstreamable > patches. We may have to provide "python" on target but that probably is > a policy decision we should discuss. > I think python as python3 is used by some distros, but it sets up for same py2->py3 problem when python4 comes out, so perhaps calling out version specific python is a good approach but I think such patches should be accepted upstream first. OE should not define its own policy without upstream python's decision to move forward. > Cheers, > > Richard > > > > signature.asc Description: OpenPGP digital signature -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#137455): https://lists.openembedded.org/g/openembedded-core/message/137455 Mute This Topic: https://lists.openembedded.org/mt/73232210/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [oe-core][PATCH 1/1] re2c: advance to version 1.3
On 4/23/20 12:43 PM, Joe Slater wrote:
> The locations of release archives has changed. We change to pulling
> source from the git repo.
>
> Fix CVE-2020-11958 which applies to versions 1.2 and 1.3.
>
> Signed-off-by: Joe Slater
> ---
> .../recipes-support/re2c/re2c/cve-2020-11958.patch | 48
> ++
> meta/recipes-support/re2c/re2c_1.0.1.bb| 14 ---
> meta/recipes-support/re2c/re2c_git.bb | 23 +++
> 3 files changed, 71 insertions(+), 14 deletions(-)
> create mode 100644 meta/recipes-support/re2c/re2c/cve-2020-11958.patch
> delete mode 100644 meta/recipes-support/re2c/re2c_1.0.1.bb
> create mode 100644 meta/recipes-support/re2c/re2c_git.bb
>
> diff --git a/meta/recipes-support/re2c/re2c/cve-2020-11958.patch
> b/meta/recipes-support/re2c/re2c/cve-2020-11958.patch
> new file mode 100644
> index 000..95a1cb9
> --- /dev/null
> +++ b/meta/recipes-support/re2c/re2c/cve-2020-11958.patch
> @@ -0,0 +1,48 @@
> +From c4603ba5ce229db83a2a4fb93e6d4b4e3ec3776a Mon Sep 17 00:00:00 2001
> +From: Ulya Trofimovich
> +Date: Fri, 17 Apr 2020 22:47:14 +0100
> +Subject: [oe-core][PATCH 1/1] Fix crash in lexer refill (reported by Agostino
> + Sarubbo).
> +
> +The crash happened in a rare case of a very long lexeme that doen't fit
> +into the buffer, forcing buffer reallocation.
> +
> +The crash was caused by an incorrect calculation of the shift offset
> +(it was smaller than necessary). As a consequence, the data from buffer
> +start and up to the beginning of the current lexeme was not discarded
> +(as it should have been), resulting in less free space for new data than
> +expected.
> +---
> + src/parse/scanner.cc | 3 ++-
> + 1 file changed, 2 insertions(+), 1 deletion(-)
> +---
> +
> +CVE: CVE-2020-11958
> +
> +Upstream-Status: Backport [github.com/skvadrik/re2c.git]
> +
> +Signed-off-by: Joe Slater
> +
> +diff --git a/src/parse/scanner.cc b/src/parse/scanner.cc
> +index 1d6e9ef..bd65131 100644
> +--- a/src/parse/scanner.cc
> b/src/parse/scanner.cc
> +@@ -155,13 +155,14 @@ bool Scanner::fill(size_t need)
> + if (!buf) fatal("out of memory");
> +
> + memmove(buf, tok, copy);
> +-shift_ptrs_and_fpos(buf - bot);
> ++shift_ptrs_and_fpos(buf - tok);
> + delete [] bot;
> + bot = buf;
> +
> + free = BSIZE - copy;
> + }
> +
> ++DASSERT(lim + free <= bot + BSIZE);
> + if (!read(free)) {
> + eof = lim;
> + memset(lim, 0, YYMAXFILL);
> +--
> +2.7.4
> +
> diff --git a/meta/recipes-support/re2c/re2c_1.0.1.bb
> b/meta/recipes-support/re2c/re2c_1.0.1.bb
> deleted file mode 100644
> index 4ed8d25..000
> --- a/meta/recipes-support/re2c/re2c_1.0.1.bb
> +++ /dev/null
> @@ -1,14 +0,0 @@
> -SUMMARY = "Tool for writing very fast and very flexible scanners"
> -HOMEPAGE = "http://re2c.sourceforge.net/;
> -AUTHOR = "Marcus Börger "
> -SECTION = "devel"
> -LICENSE = "PD"
> -LIC_FILES_CHKSUM =
> "file://README;beginline=146;md5=881056c9add17f8019ccd8c382ba963a"
> -
> -SRC_URI = "${SOURCEFORGE_MIRROR}/${BPN}/${BPN}-${PV}.tar.gz"
> -SRC_URI[md5sum] = "e2c6cf52fc6a21595f21bc82db5324f8"
> -SRC_URI[sha256sum] =
> "605058d18a00e01bfc32aebf83af35ed5b13180b4e9f279c90843afab2c66c7c"
> -
> -BBCLASSEXTEND = "native"
> -
> -inherit autotools
> diff --git a/meta/recipes-support/re2c/re2c_git.bb
> b/meta/recipes-support/re2c/re2c_git.bb
> new file mode 100644
> index 000..06242ce
> --- /dev/null
> +++ b/meta/recipes-support/re2c/re2c_git.bb
> @@ -0,0 +1,23 @@
> +SUMMARY = "Tool for writing very fast and very flexible scanners"
> +HOMEPAGE = "http://re2c.sourceforge.net/;
> +AUTHOR = "Marcus Börger "
> +SECTION = "devel"
> +LICENSE = "PD"
> +LIC_FILES_CHKSUM = "file://LICENSE;md5=64eca4d8a3b67f9dc7656094731a2c8d"
> +
> +SRC_URI = "git://github.com/skvadrik/re2c.git \
> +file://cve-2020-11958.patch \
> + "
> +
> +# rev of 1.3 tag
> +#
> +SRCREV = "e1901b71c6414c510f10f4cc30c0a05600e55ed1"
> +PV = "1.3+git"
if it is release tag then just set PV = "1.3"
> +
> +# override the default S
> +#
> +S = "${WORKDIR}/git"
> +
> +BBCLASSEXTEND = "native"
> +
> +inherit autotools
Usually inherit should go above BBCLASSEXTEND
>
>
>
>
signature.asc
Description: OpenPGP digital signature
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#137454):
https://lists.openembedded.org/g/openembedded-core/message/137454
Mute This Topic: https://lists.openembedded.org/mt/73226332/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-Core][PATCH 1/6] openssh: Move sshdgenkeys.service to sshd.socket
On 4/23/20 10:14 AM, Andre McCurdy wrote: > On Thu, Apr 23, 2020 at 1:30 AM Alex Kiernan wrote: >> On Wed, Apr 22, 2020 at 7:48 PM Andre McCurdy wrote: >>> On Wed, Apr 22, 2020 at 6:52 AM Alex Kiernan wrote: sshd.socket launches the templated sshd@.service, so by moving the sshdgenkeys.service to sshd.socket, key generation can start in advance of a connection. >>> >>> Is deferring key generation until the first connection a bug or by design? >> >> If you've installed it, presumably you're expecting connections. But I >> agree you could argue it either way. > > The trade off is between slower first boot (or every boot for > read-only rootfs if host keys are not persistent) -vs- slower first > incoming ssh connection. > > Since the first incoming ssh connection may never happen (especially > if ssh is only used for debugging or development), optimising it at > the expense of boot time doesn't seem to be an obvious improvement. > I tend to agree. Perhaps it could be covered under read-only-rootfs DISTRO_FEATURE > > > signature.asc Description: OpenPGP digital signature -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#137453): https://lists.openembedded.org/g/openembedded-core/message/137453 Mute This Topic: https://lists.openembedded.org/mt/73195919/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] RFC wic: Support .wks files for multiple machines
This will only work the way you expect if hte user's local.conf uses ?= or
??= for MACHINE, otherwise setting it in the environment will do nothing.
On Fri, Apr 24, 2020 at 6:30 AM Ricardo Ribalda
wrote:
> If you want to make a disk image containing rootfs for different
> machines, the only way to do it today is by calling wic and passing the
> different rootfs-paths.
>
> Eg:
> combined.wks
> part /export --source rootfs --rootfs-dir=target-image
> part / --source rootfs
>
> bitbake multiconfig:arm:target-image
> wic create combined --rootfs-dir
> target-image=/workdir/build/tmp/work/arm-poky-linux/target-image/1.0-r0/rootfs/
> -e main
>
> This has many drawbacks:
> 1) You need to know the folder location for the target-image
> 2) It is easy to forget updating the target (only running wic and not
>bitbake)
> 3) It is slow
> 4) It does not scale when you have multiple machines
>
> Instead, wic can be given a hint of what machine to search for:
>
> combined.wks
> part /export --source rootfs --rootfs-dir=arm:target-image
> part / --source rootfs
>
> bitbake main
>
> If we ensoure the dependency of target-image from main via
> do_image[mcdepends], all the dependencies are automatically
> handled.
>
> This patch makes wic aware of the machine to use.
>
> Signed-off-by: Ricardo Ribalda Delgado
> ---
> scripts/lib/wic/misc.py | 16 +---
> 1 file changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/scripts/lib/wic/misc.py b/scripts/lib/wic/misc.py
> index 91975ba151..51b43b49aa 100644
> --- a/scripts/lib/wic/misc.py
> +++ b/scripts/lib/wic/misc.py
> @@ -206,7 +206,12 @@ class BitbakeVars(defaultdict):
>
> if image not in self:
> if image and self.vars_dir:
> -fname = os.path.join(self.vars_dir, image + '.env')
> +if image.find(":") != -1:
> +[machine, img] = image.split(":")
> +fname = os.path.join(self.vars_dir, "../../",
> + machine, "imgdata", img + '.env')
> +else:
> +fname = os.path.join(self.vars_dir, image + '.env')
> if os.path.isfile(fname):
> # parse .env file
> with open(fname) as varsfile:
> @@ -220,11 +225,16 @@ class BitbakeVars(defaultdict):
> # Get bitbake -e output
> cmd = "bitbake -e"
> if image:
> -cmd += " %s" % image
> +if image.find(":") != -1:
> +[machine, img] = image.split(":")
> +cmd = "MACHINE=%s %s" % (machine, cmd)
> +else:
> +img = image
> +cmd += " %s" % img
>
> log_level = logger.getEffectiveLevel()
> logger.setLevel(logging.INFO)
> -ret, lines = _exec_cmd(cmd)
> +ret, lines = _exec_cmd(cmd, as_shell=True)
> logger.setLevel(log_level)
>
> if ret:
> --
> 2.26.1
>
>
>
--
Christopher Larson
kergoth at gmail dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Senior Software Engineer, Mentor Graphics
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#137452):
https://lists.openembedded.org/g/openembedded-core/message/137452
Mute This Topic: https://lists.openembedded.org/mt/73241116/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [meta-oe][PATCH] libva: Removed virtual/mesa dependency
Mesa can be compiled with libva support, in order to avoid recursive dependency between mesa and libva, virtual/mesa must be removed from libva recipe. Signed-off-by: Bartłomiej Burdukiewicz --- meta/recipes-graphics/libva/libva_2.6.1.bb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-graphics/libva/libva_2.6.1.bb b/meta/recipes-graphics/libva/libva_2.6.1.bb index 92cea83bc1..c1a441a18b 100644 --- a/meta/recipes-graphics/libva/libva_2.6.1.bb +++ b/meta/recipes-graphics/libva/libva_2.6.1.bb @@ -23,7 +23,7 @@ SRC_URI[sha256sum] = "6c57eb642d828af2411aa38f55dc10111e8c98976dbab8fd62e4862940 UPSTREAM_CHECK_URI = "https://github.com/intel/libva/releases; -DEPENDS = "libdrm virtual/mesa" +DEPENDS = "libdrm" inherit meson pkgconfig features_check -- 2.26.2 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#137451): https://lists.openembedded.org/g/openembedded-core/message/137451 Mute This Topic: https://lists.openembedded.org/mt/73242971/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] Changing DISTRO_FEATURES / build directory
On Fri, 2020-04-24 at 14:20 +, chris.lapla...@agilent.com wrote:
> > "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 doesn’t it show up in task dependencies?
It should be handled correctly and it does show up.
For example,
$ bitbake-dumpsig
./tmp/stamps/core2-64-poky-linux/dbus-test/1.12.16-r0.do_configure.sig*
Variable root_prefix value is ${@bb.utils.contains('DISTRO_FEATURES',
'usrmerge', '${exec_prefix}', '${base_prefix}', d)}
DISTRO_FEATURES{usrmerge} = Unset
which means DISTRO_FEATURES didn't contain "usrmerge". It would only
change hash if DISTRO_FEATURES then did contain it, there is no
absolute value dependency.
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#137450):
https://lists.openembedded.org/g/openembedded-core/message/137450
Mute This Topic: https://lists.openembedded.org/mt/73225609/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] Changing DISTRO_FEATURES / build directory
> "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 doesn’t it show up in task dependencies? Thanks, Chris -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#137449): https://lists.openembedded.org/g/openembedded-core/message/137449 Mute This Topic: https://lists.openembedded.org/mt/73225609/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] Changing DISTRO_FEATURES / build directory
On Fri, 2020-04-24 at 13:59 +, chris.lapla...@agilent.com wrote:
> > > 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 master-next (both to
> > fix and
> > add a test case).
> >
> > Is there a failure with reproducer you have? Which release?
>
> I haven't encountered any bugs yet, no. I am working on adding some
> custom DISTRO_FEATURES to our distro. I was trying to convince myself
> whether vardeps are necessary for DISTRO_FEATURES, and couldn't
> decide. For instance, if I have:
>
> do_unpack_append() {
> echo "${@bb.utils.contains("DISTRO_FEATURES", "my-feature",
> "true", "false", d)}" >> ${S}/whatever
> }
>
> bitbake-dumpsigs on the do_unpack sigdata reveals that
> DISTRO_FEATURES is *not* part of the task dependencies. So I was
> wondering if I needed to do:
>
> do_unpack[vardeps] += "DISTRO_FEATURES"
>
> but looking around poky and meta-openembedded, I don't see anyone
> else doing that kind of thing.
>
> The interesting thing is that the bitbake-dumpsig does have some
> special looking DISTRO_FEATURES output, such as:
>
> DISTRO_FEATURES{usrmerge} = Unset
> DISTRO_FEATURES{my-feature} = Set
>
> So it seems there is some DISTRO_FEATURES specific processing?
>
> It's also unclear to me whether the signature code is able to
> understand bb.utils.contains and automatically pluck out the fact
> that DISTRO_FEATURES should be accounted for.
"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.
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#137448):
https://lists.openembedded.org/g/openembedded-core/message/137448
Mute This Topic: https://lists.openembedded.org/mt/73225609/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] Changing DISTRO_FEATURES / build directory
> > 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 master-next (both to fix and
> add a test case).
>
> Is there a failure with reproducer you have? Which release?
I haven't encountered any bugs yet, no. I am working on adding some custom
DISTRO_FEATURES to our distro. I was trying to convince myself whether vardeps
are necessary for DISTRO_FEATURES, and couldn't decide. For instance, if I have:
do_unpack_append() {
echo "${@bb.utils.contains("DISTRO_FEATURES", "my-feature", "true",
"false", d)}" >> ${S}/whatever
}
bitbake-dumpsigs on the do_unpack sigdata reveals that DISTRO_FEATURES is *not*
part of the task dependencies. So I was wondering if I needed to do:
do_unpack[vardeps] += "DISTRO_FEATURES"
but looking around poky and meta-openembedded, I don't see anyone else doing
that kind of thing.
The interesting thing is that the bitbake-dumpsig does have some special
looking DISTRO_FEATURES output, such as:
DISTRO_FEATURES{usrmerge} = Unset
DISTRO_FEATURES{my-feature} = Set
So it seems there is some DISTRO_FEATURES specific processing?
It's also unclear to me whether the signature code is able to understand
bb.utils.contains and automatically pluck out the fact that DISTRO_FEATURES
should be accounted for.
Thanks,
Chris
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#137447):
https://lists.openembedded.org/g/openembedded-core/message/137447
Mute This Topic: https://lists.openembedded.org/mt/73225609/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH] RFC wic: Support .wks files for multiple machines
If you want to make a disk image containing rootfs for different
machines, the only way to do it today is by calling wic and passing the
different rootfs-paths.
Eg:
combined.wks
part /export --source rootfs --rootfs-dir=target-image
part / --source rootfs
bitbake multiconfig:arm:target-image
wic create combined --rootfs-dir
target-image=/workdir/build/tmp/work/arm-poky-linux/target-image/1.0-r0/rootfs/
-e main
This has many drawbacks:
1) You need to know the folder location for the target-image
2) It is easy to forget updating the target (only running wic and not
bitbake)
3) It is slow
4) It does not scale when you have multiple machines
Instead, wic can be given a hint of what machine to search for:
combined.wks
part /export --source rootfs --rootfs-dir=arm:target-image
part / --source rootfs
bitbake main
If we ensoure the dependency of target-image from main via
do_image[mcdepends], all the dependencies are automatically
handled.
This patch makes wic aware of the machine to use.
Signed-off-by: Ricardo Ribalda Delgado
---
scripts/lib/wic/misc.py | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/scripts/lib/wic/misc.py b/scripts/lib/wic/misc.py
index 91975ba151..51b43b49aa 100644
--- a/scripts/lib/wic/misc.py
+++ b/scripts/lib/wic/misc.py
@@ -206,7 +206,12 @@ class BitbakeVars(defaultdict):
if image not in self:
if image and self.vars_dir:
-fname = os.path.join(self.vars_dir, image + '.env')
+if image.find(":") != -1:
+[machine, img] = image.split(":")
+fname = os.path.join(self.vars_dir, "../../",
+ machine, "imgdata", img + '.env')
+else:
+fname = os.path.join(self.vars_dir, image + '.env')
if os.path.isfile(fname):
# parse .env file
with open(fname) as varsfile:
@@ -220,11 +225,16 @@ class BitbakeVars(defaultdict):
# Get bitbake -e output
cmd = "bitbake -e"
if image:
-cmd += " %s" % image
+if image.find(":") != -1:
+[machine, img] = image.split(":")
+cmd = "MACHINE=%s %s" % (machine, cmd)
+else:
+img = image
+cmd += " %s" % img
log_level = logger.getEffectiveLevel()
logger.setLevel(logging.INFO)
-ret, lines = _exec_cmd(cmd)
+ret, lines = _exec_cmd(cmd, as_shell=True)
logger.setLevel(log_level)
if ret:
--
2.26.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#137446):
https://lists.openembedded.org/g/openembedded-core/message/137446
Mute This Topic: https://lists.openembedded.org/mt/73241116/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH 1/3] python3-pbr: change shebang to python3
On Fri, 2020-04-24 at 09:09 +0800, Changqing Li wrote: > From: Changqing Li > > we have offcially dropped python2, so it is possible > that our code run on python3 only host, so change > shebang to python3 to avoid error like: > python: command not found I worry this is going to be the start of a huge pile or unstreamable patches. We may have to provide "python" on target but that probably is a policy decision we should discuss. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#137445): https://lists.openembedded.org/g/openembedded-core/message/137445 Mute This Topic: https://lists.openembedded.org/mt/73232210/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] selftest/imagefeatures: Enable sanity test for IMAGE_GEN_DEBUGFS
Hi Richard, I did rerun the imagefeatures tests on master and master-next, here are my findings. On master (commit: a44b8d2856a937ca3991cbf566788b0cd541d777), test_image_gen_debugfs test was passing. 2020-04-24 16:05:56,417 - oe-selftest - INFO - test_image_gen_debugfs (imagefeatures.ImageFeatures) 2020-04-24 16:34:54,821 - oe-selftest - INFO - ... ok 2020-04-24 16:34:54,834 - oe-selftest - INFO - -- 2020-04-24 16:34:54,834 - oe-selftest - INFO - Ran 1 test in 1738.418s 2020-04-24 16:34:54,834 - oe-selftest - INFO - OK 2020-04-24 16:35:01,077 - oe-selftest - INFO - RESULTS: 2020-04-24 16:35:01,078 - oe-selftest - INFO - RESULTS - imagefeatures.ImageFeatures.test_image_gen_debugfs: PASSED (1738.40s) 2020-04-24 16:35:01,135 - oe-selftest - INFO - SUMMARY: 2020-04-24 16:35:01,135 - oe-selftest - INFO - oe-selftest () - Ran 1 test in 1740.237s 2020-04-24 16:35:01,136 - oe-selftest - INFO - oe-selftest - OK - All required tests passed (successes=1, skipped=0, failures=0, errors=0) On master-next (commit: a0852af226802e50955e6e5ddd14f773cb42a10f), the test consistently failed at bison do_compile. | gcc -DEXEEXT=\"\" -I. -I./lib -I../bison-3.5.4 -I../bison-3.5.4/lib -DINSTALLDIR=\"/data/eyeoh7/tmp/poky/build-image-minimal-gen-debugs-master-next-st/tmp/work/x86_64-linux/bison-native/3.5.4-r0/recipe-sysroot-native/usr/bin\" -isystem/data/eyeoh7/tmp/poky/build-image-minimal-gen-debugs-master-next-st/tmp/work/x86_64-linux/bison-native/3.5.4-r0/recipe-sysroot-native/usr/include -isystem/data/eyeoh7/tmp/poky/build-image-minimal-gen-debugs-master-next-st/tmp/work/x86_64-linux/bison-native/3.5.4-r0/recipe-sysroot-native/usr/include -O2 -pipe -c -o src/bison-symtab.o `test -f 'src/symtab.c' || echo '../bison-3.5.4/'`src/symtab.c | ../bison-3.5.4/lib/fcntl.c: In function 'rpl_fcntl_DUPFD_CLOEXEC': | ../bison-3.5.4/lib/fcntl.c:507:35: error: 'GNULIB_defined_F_DUPFD_CLOEXEC' undeclared (first use in this function); did you mean 'rpl_fcntl_DUPFD_CLOEXEC'? |static int have_dupfd_cloexec = GNULIB_defined_F_DUPFD_CLOEXEC ? -1 : 0; |^~ |rpl_fcntl_DUPFD_CLOEXEC | ../bison-3.5.4/lib/fcntl.c:507:35: note: each undeclared identifier is reported only once for each function it appears in | Makefile:5414: recipe for target 'lib/libbison_a-fcntl.o' failed | make: *** [lib/libbison_a-fcntl.o] Error 1 | make: *** Waiting for unfinished jobs | mv examples/c/reccalc/scan.stamp.tmp examples/c/reccalc/scan.stamp | WARNING: exit code 1 from a shell command. | NOTE: recipe bison-native-3.5.4-r0: task do_compile: Failed ERROR: Task (virtual:native:/data/eyeoh7/tmp/poky/meta/recipes-devtools/bison/bison_3.5.4.bb:do_compile) failed with exit code '1' I will continue debugging this. Best regards, Yeoh Ee Peng -Original Message- From: Yeoh, Ee Peng Sent: Thursday, April 23, 2020 5:33 PM To: Richard Purdie ; openembedded-core@lists.openembedded.org Subject: RE: [OE-core] [PATCH] selftest/imagefeatures: Enable sanity test for IMAGE_GEN_DEBUGFS Hi Richard, This was surprising, it look like debug filesystem was not being generated given the configuration (IMAGE_GEN_DEBUGFS = "1"). This was exactly the type of error that this automated test was designed to catch. I shall debug this on master and potentially master-next. Thanks, Yeoh Ee Peng 2020-04-23 03:57:33,491 - oe-selftest - INFO - == 2020-04-23 03:57:33,491 - oe-selftest - INFO - FAIL: imagefeatures.ImageFeatures.test_image_gen_debugfs (subunit.RemotedTestCase) 2020-04-23 03:57:33,491 - oe-selftest - INFO - -- 2020-04-23 03:57:33,491 - oe-selftest - INFO - testtools.testresult.real._StringException: Traceback (most recent call last): File "/home/pokybuild/yocto-worker/oe-selftest-fedora/build/meta/lib/oeqa/selftest/cases/imagefeatures.py", line 288, in test_image_gen_debugfs self.assertNotEqual(len(debug_files), 0, 'debug filesystem not generated') File "/usr/lib64/python3.7/unittest/case.py", line 861, in assertNotEqual raise self.failureException(msg) AssertionError: 0 == 0 : debug filesystem not generated -Original Message- From: Richard Purdie Sent: Thursday, April 23, 2020 4:53 PM To: Yeoh, Ee Peng ; openembedded-core@lists.openembedded.org Cc: Humberto Ibarra Subject: Re: [OE-core] [PATCH] selftest/imagefeatures: Enable sanity test for IMAGE_GEN_DEBUGFS On Wed, 2020-04-01 at 13:37 +0800, Yeoh Ee Peng wrote: > Add new testcase to check IMAGE_GEN_DEBUGFS. Test makes sure that > debug filesystem is created accordingly. Test also check for debug > symbols for some packages as suggested by Ross Burton. > > [YOCTO #10906] > > Signed-off-by: Humberto Ibarra > Signed-off-by: Yeoh Ee Peng > --- >
