Re: [OE-core] [PATCH] toolchain-scripts: make rpm work in toolchain
Hi,
I noticed that " dnf: Enable nativesdk " has been merged into master-next. This
patch is necessary for dnf-nativesdk, so please merge too.
Best regards
Lei
> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org [mailto:openembedded-
> core-boun...@lists.openembedded.org] On Behalf Of Zheng, Ruoqin
> Sent: Friday, April 19, 2019 10:55 AM
> To: openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH] toolchain-scripts: make rpm work in toolchain
>
> ping
>
> --
> Zheng Ruoqin
> Nanjing Fujitsu Nanda Software Tech. Co., Ltd.(FNST)
> ADDR.: No.6 Wenzhu Road, Software Avenue,
>Nanjing, 210012, China
> MAIL : zhengrq.f...@cn.fujistu.com
>
>
> > -Original Message-
> > From: Zheng, Ruoqin
> > Sent: Saturday, April 13, 2019 10:37 PM
> > To: openembedded-core@lists.openembedded.org
> > Cc: Zheng, Ruoqin
> > Subject: [OE-core][PATCH] toolchain-scripts: make rpm work in toolchain
> >
> > Rpm need to read the arch info, but $script did not provide it, so add it.
> >
> > Signed-off-by: Zheng Ruoqin
> > ---
> > meta/classes/toolchain-scripts.bbclass | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/meta/classes/toolchain-scripts.bbclass
> > b/meta/classes/toolchain-
> > scripts.bbclass
> > index 1a2ec4f..de50b7e 100644
> > --- a/meta/classes/toolchain-scripts.bbclass
> > +++ b/meta/classes/toolchain-scripts.bbclass
> > @@ -101,6 +101,7 @@ toolchain_shared_env_script () {
> > echo 'export CPPFLAGS="${TARGET_CPPFLAGS}"' >> $script
> > echo 'export KCFLAGS="--sysroot=$SDKTARGETSYSROOT"' >> $script
> > echo 'export OECORE_DISTRO_VERSION="${DISTRO_VERSION}"' >>
> > $script
> > + echo 'export MACHINE_ARCH=${MACHINE_ARCH}' >> $script
> > echo 'export OECORE_SDK_VERSION="${SDK_VERSION}"' >> $script
> > echo 'export ARCH=${ARCH}' >> $script
> > echo 'export CROSS_COMPILE=${TARGET_PREFIX}' >> $script
> > --
> > 1.8.3.1
>
>
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [meta-oe][RFC][PATCH] Remove openssl10
On Thu, Apr 25, 2019 at 03:18:47PM -0500, Mark Hatle wrote: > On 4/25/19 2:28 PM, Adrian Bunk wrote: > > Would you consider this patch appropriate now that warrior has branched? > > The use of OpenSSL10 as a 'second library' is likely no longer needed. But > OpenSSL 1.0 (as an alternative version) to OpenSSL 1.1 is still needed in some > cases.. (FIPS-140-2) Is anyone actually security-maintaining OpenSSL in OE? The just released sumo has both versions of OpenSSL not touched since August, despite just upgrading to the latest versions would fix CVEs. > So removal of openssl10 is fine, but if there are patches for support of both > versions (old/new) of OpenSSL they will be needed at least through the end of > this year for many users. This is now for Yocto 2.8, which will be released October/November this year. > --Mark cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2] libsoup: Upgrade from 2.64.2 to 2.66.1
Signed-off-by: Alistair Francis
---
...no-introspection-when-cross-building.patch | 20 +++
...up-2.4_2.64.2.bb => libsoup-2.4_2.66.1.bb} | 4 ++--
2 files changed, 14 insertions(+), 10 deletions(-)
rename meta/recipes-support/libsoup/{libsoup-2.4_2.64.2.bb =>
libsoup-2.4_2.66.1.bb} (92%)
diff --git
a/meta/recipes-support/libsoup/libsoup-2.4/0001-Do-not-enforce-no-introspection-when-cross-building.patch
b/meta/recipes-support/libsoup/libsoup-2.4/0001-Do-not-enforce-no-introspection-when-cross-building.patch
index 72b029a80b..cd6de853e5 100644
---
a/meta/recipes-support/libsoup/libsoup-2.4/0001-Do-not-enforce-no-introspection-when-cross-building.patch
+++
b/meta/recipes-support/libsoup/libsoup-2.4/0001-Do-not-enforce-no-introspection-when-cross-building.patch
@@ -1,24 +1,28 @@
-From 921888affe66953c92a08ae440e911b016b124be Mon Sep 17 00:00:00 2001
+From 85f7b74fc602214297928afe09347c31d696173d Mon Sep 17 00:00:00 2001
From: Alexander Kanavin
Date: Fri, 15 Feb 2019 14:21:06 +0100
Subject: [PATCH] Do not enforce no-introspection when cross-building
Upstream-Status: Pending
Signed-off-by: Alexander Kanavin
+Signed-off-by: Alistair Francis
---
meson.build | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meson.build b/meson.build
-index 5a92cda..cfb3520 100644
+index 25887f9..6261a7c 100644
--- a/meson.build
+++ b/meson.build
-@@ -262,7 +262,7 @@ enable_gnome = get_option('gnome') and
host_machine.system() != 'windows'
- #
- # GObject introspection #
- #
--enable_introspection = get_option('introspection') and
find_program('g-ir-scanner', required: false).found() and not
meson.is_cross_build()
-+enable_introspection = get_option('introspection') and
find_program('g-ir-scanner', required: false).found()
+@@ -281,7 +281,7 @@ enable_gnome = get_option('gnome') and
host_machine.system() != 'windows'
+ # FIXME: once we start to require meson 0.49.0+ and gnome-introspection
1.58.1+
+ # the we can enable the introspection even for the static build. See
+ # https://github.com/mesonbuild/meson/pull/4478.
+-enable_introspection = get_option('introspection') and
find_program('g-ir-scanner', required: false).found() and not
meson.is_cross_build() and not is_static_library
++enable_introspection = get_option('introspection') and
find_program('g-ir-scanner', required: false).found() and not is_static_library
# Vala API #
+--
+2.20.1
+
diff --git a/meta/recipes-support/libsoup/libsoup-2.4_2.64.2.bb
b/meta/recipes-support/libsoup/libsoup-2.4_2.66.1.bb
similarity index 92%
rename from meta/recipes-support/libsoup/libsoup-2.4_2.64.2.bb
rename to meta/recipes-support/libsoup/libsoup-2.4_2.66.1.bb
index b095397ec2..99fb65844e 100644
--- a/meta/recipes-support/libsoup/libsoup-2.4_2.64.2.bb
+++ b/meta/recipes-support/libsoup/libsoup-2.4_2.66.1.bb
@@ -12,8 +12,8 @@ SHRT_VER =
"${@d.getVar('PV').split('.')[0]}.${@d.getVar('PV').split('.')[1]}"
SRC_URI = "${GNOME_MIRROR}/libsoup/${SHRT_VER}/libsoup-${PV}.tar.xz \
file://0001-Do-not-enforce-no-introspection-when-cross-building.patch \
"
-SRC_URI[md5sum] = "cac755dc6c6acd6e0c70007f547548f5"
-SRC_URI[sha256sum] =
"75ddc194a5b1d6f25033bb9d355f04bfe5c03e0e1c71ed0774104457b3a786c6"
+SRC_URI[md5sum] = "5f04c09a06f6dbe4c4d3f003992145ce"
+SRC_URI[sha256sum] =
"4a2cb6c1174540af13661636035992c2b179dfcb39f4d3fa7bee3c7e355c43ff"
S = "${WORKDIR}/libsoup-${PV}"
--
2.21.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [master][RFC] Adding back wrapper and using OEPYTHON3HOME variable for python3
Hi Richard,
Agreed, will send a v2
Thanks,
Jaewon
-Original Message-
From: richard.pur...@linuxfoundation.org
Sent: Thursday, April 25, 2019 1:50 PM
To: Jaewon Lee ; openembedded-core@lists.openembedded.org;
Manjukumar Harthikote Matha ; Alejandro Enedino Hernandez
Samaniego
Subject: Re: [OE-core][master][RFC] Adding back wrapper and using OEPYTHON3HOME
variable for python3
On Thu, 2019-04-25 at 12:56 -0700, Jaewon Lee wrote:
> +diff --git a/Modules/main.c b/Modules/main.c index a745381..25ca435
> +100644
> +--- a/Modules/main.c
> b/Modules/main.c
> +@@ -1857,6 +1857,11 @@ config_init_home(_PyCoreConfig *config)
> + }
> +
> + int res = config_get_env_var_dup(, L"PYTHONHOME",
> + "PYTHONHOME");
> ++
> ++const char *oepython3home = config_get_env_var("OEPYTHON3HOME");
> ++if (oepython3home) {
> ++res = config_get_env_var_dup(, L"OEPYTHON3HOME",
> "OEPYTHON3HOME");
> ++}
> + if (res < 0) {
> + return DECODE_LOCALE_ERR("PYTHONHOME", res);
> + }
> +--
> +2.7.4
I think the above will leak memory.
Instead I think the code should be something like:
int res;
const char *oepython3home = config_get_env_var("OEPYTHON3HOME");
if (oepython3home) {
res = config_get_env_var_dup(, L"OEPYTHON3HOME", "OEPYTHON3HOME");
if (res < 0)
return DECODE_LOCALE_ERR("OEPYTHON3HOME", res); } else {
res = config_get_env_var_dup(, L"PYTHONHOME", "PYTHONHOME");
if (res < 0)
return DECODE_LOCALE_ERR("PYTHONHOME", res); }
and then a copy of PYTHONHOME isn't created in the OEPYTHON3HOME case.
Cheers,
Richard
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [master][RFC] Adding back wrapper and using OEPYTHON3HOME variable for python3
On Thu, 2019-04-25 at 12:56 -0700, Jaewon Lee wrote:
> +diff --git a/Modules/main.c b/Modules/main.c
> +index a745381..25ca435 100644
> +--- a/Modules/main.c
> b/Modules/main.c
> +@@ -1857,6 +1857,11 @@ config_init_home(_PyCoreConfig *config)
> + }
> +
> + int res = config_get_env_var_dup(, L"PYTHONHOME", "PYTHONHOME");
> ++
> ++const char *oepython3home = config_get_env_var("OEPYTHON3HOME");
> ++if (oepython3home) {
> ++res = config_get_env_var_dup(, L"OEPYTHON3HOME",
> "OEPYTHON3HOME");
> ++}
> + if (res < 0) {
> + return DECODE_LOCALE_ERR("PYTHONHOME", res);
> + }
> +--
> +2.7.4
I think the above will leak memory.
Instead I think the code should be something like:
int res;
const char *oepython3home = config_get_env_var("OEPYTHON3HOME");
if (oepython3home) {
res = config_get_env_var_dup(, L"OEPYTHON3HOME", "OEPYTHON3HOME");
if (res < 0)
return DECODE_LOCALE_ERR("OEPYTHON3HOME", res);
} else {
res = config_get_env_var_dup(, L"PYTHONHOME", "PYTHONHOME");
if (res < 0)
return DECODE_LOCALE_ERR("PYTHONHOME", res);
}
and then a copy of PYTHONHOME isn't created in the OEPYTHON3HOME case.
Cheers,
Richard
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [meta-oe][RFC][PATCH] Remove openssl10
On 4/25/19 2:28 PM, Adrian Bunk wrote: > Would you consider this patch appropriate now that warrior has branched? The use of OpenSSL10 as a 'second library' is likely no longer needed. But OpenSSL 1.0 (as an alternative version) to OpenSSL 1.1 is still needed in some cases.. (FIPS-140-2) So removal of openssl10 is fine, but if there are patches for support of both versions (old/new) of OpenSSL they will be needed at least through the end of this year for many users. --Mark > Adrian > > On Fri, Mar 08, 2019 at 10:39:04PM +0200, Adrian Bunk wrote: >> On Fri, Mar 08, 2019 at 11:21:26PM +0300, Alexander Kanavin wrote: >>> Perhaps you could grep meta-openembedded for openssl10? I do not have >>> access to a Linux machine for the next two weeks to check that, but I think >>> there’s a few items there. Once meta-oe layers are free of openssl10 deps, >>> there is a better case for removing it. >>> ... >> >> My patches to remove the last uses of openssl10 in meta-openembedded >> are already in meta-openembedded master. >> >>> Alex >> >> cu >> Adrian -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [meta-oe][RFC][PATCH] Remove openssl10
Would you consider this patch appropriate now that warrior has branched? Adrian On Fri, Mar 08, 2019 at 10:39:04PM +0200, Adrian Bunk wrote: > On Fri, Mar 08, 2019 at 11:21:26PM +0300, Alexander Kanavin wrote: > > Perhaps you could grep meta-openembedded for openssl10? I do not have > > access to a Linux machine for the next two weeks to check that, but I think > > there’s a few items there. Once meta-oe layers are free of openssl10 deps, > > there is a better case for removing it. > >... > > My patches to remove the last uses of openssl10 in meta-openembedded > are already in meta-openembedded master. > > > Alex > > cu > Adrian -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] qemu: Upgrade from 3.1.0 to 4.0.0
On Thu, Apr 25, 2019 at 7:27 AM akuster808 wrote: > > > > On 4/25/19 6:49 AM, Richard Purdie wrote: > > On Wed, 2019-04-24 at 00:15 +, Alistair Francis wrote: > >> This commit upgrade QEMU to the latest 4.0.0 release. > >> > >> - The COPYING.LIB file has changed SHA to: > >> "Synchronize the LGPL 2.1 with the version from gnu.org" > >> - SDL 1.2 has been removed, along with the --with-sdlabi command > >> line > >> arg > >> - The backported patches have been removed > >> - Al the other patches have been refreshed and the numbering has > >> been > >> updated > > I put this in for testing but it failed as nativesdk-qemu doesn't build > > due to unpackaged files: > > Bug opened: 13308 > > Thanks, > > Your neighborhood swat team. > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/65/builds/535/steps/7/logs/step1b I have updated the patch here: https://github.com/alistair23/openembedded-core/tree/alistair/qemu-4.0.0 Alistair > > > > Cheers, > > > > Richard > > > > -- > ___ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] apr: update to 1.7.0
https://svn.apache.org/viewvc?view=revision=1857391 is the
upstream fix.
Ross
On Thu, 25 Apr 2019 at 17:15, Martin Jansa wrote:
>
> On Thu, Apr 25, 2019 at 04:21:22PM +0100, Burton, Ross wrote:
> > Sadly this breaks subversion target builds:
> >
> > checking for linking Python libraries...
> > checking for apr_int64_t Python/C API format string...
> > configure: error: failed to recognize APR_INT64_T_FMT on this platform
>
> I had recently the same on my gentoo host, the same fix might apply
> here:
> https://github.com/gentoo/gentoo/commit/94454a54314e0b471877ee2d1b44d8a6b9128cea
>
> >
> > Ross
> >
> > On Wed, 24 Apr 2019 at 16:09, Oleksandr Kravchuk
> > wrote:
> > >
> > > Refreshed patches with devtool.
> > >
> > > Signed-off-by: Oleksandr Kravchuk
> > > ---
> > > ...ldcheck.sh-improve-libtool-detection.patch | 10 +++
> > > ...ir-path-references-from-installed-ap.patch | 9 +++
> > > ...configure.in-support-cross-compiling.patch | 12 -
> > > ...04-Fix-packet-discards-HTTP-redirect.patch | 8 +++---
> > > ...-LTFLAGS-to-make-it-work-with-ccache.patch | 10 +++
> > > ...ze-doesn-t-match-in-glibc-when-cross.patch | 27 +--
> > > ...libapr-against-phtread-to-make-gold-.patch | 14 +-
> > > .../apr/{apr_1.6.5.bb => apr_1.7.0.bb}| 4 +--
> > > 8 files changed, 40 insertions(+), 54 deletions(-)
> > > rename meta/recipes-support/apr/{apr_1.6.5.bb => apr_1.7.0.bb} (96%)
> > >
> > > diff --git
> > > a/meta/recipes-support/apr/apr/0001-build-buildcheck.sh-improve-libtool-detection.patch
> > >
> > > b/meta/recipes-support/apr/apr/0001-build-buildcheck.sh-improve-libtool-detection.patch
> > > index 097c195a19..c0426797bd 100644
> > > ---
> > > a/meta/recipes-support/apr/apr/0001-build-buildcheck.sh-improve-libtool-detection.patch
> > > +++
> > > b/meta/recipes-support/apr/apr/0001-build-buildcheck.sh-improve-libtool-detection.patch
> > > @@ -1,19 +1,20 @@
> > > -From 4efdc06fb17b8a00a9eca923caa176be741d1e04 Mon Sep 17 00:00:00 2001
> > > +From 507a36c128c22fad2e7183f3da5bc8424fb42729 Mon Sep 17 00:00:00 2001
> > > From: Hongxu Jia
> > > Date: Thu, 1 Feb 2018 14:56:13 +0800
> > > -Subject: [PATCH 1/7] build/buildcheck.sh: improve libtool detection
> > > +Subject: [PATCH] build/buildcheck.sh: improve libtool detection
> > >
> > > Support customize libtool by variable assigning, it is helpful
> > > for cross compileing (such as libtool=aarch64-linux-libtool)
> > >
> > > Upstream-Status: Submitted [https://github.com/apache/apr/pull/8]
> > > Signed-off-by: Hongxu Jia
> > > +
> > > ---
> > > build/buildcheck.sh | 4 +++-
> > > 1 file changed, 3 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/build/buildcheck.sh b/build/buildcheck.sh
> > > -index ab5df44..f191a41 100755
> > > +index 76ff8ce..44921b5 100755
> > > --- a/build/buildcheck.sh
> > > +++ b/build/buildcheck.sh
> > > @@ -40,7 +40,9 @@ fi
> > > @@ -27,6 +28,3 @@ index ab5df44..f191a41 100755
> > > lt_pversion=`$libtool --version 2>/dev/null|sed -e
> > > 's/([^)]*)//g;s/^[^0-9]*//;s/[- ].*//g;q'`
> > > if test -z "$lt_pversion"; then
> > > echo "buildconf: libtool not found."
> > > ---
> > > -1.8.3.1
> > > -
> > > diff --git
> > > a/meta/recipes-support/apr/apr/0002-apr-Remove-workdir-path-references-from-installed-ap.patch
> > >
> > > b/meta/recipes-support/apr/apr/0002-apr-Remove-workdir-path-references-from-installed-ap.patch
> > > index 72e706f966..6b7156a439 100644
> > > ---
> > > a/meta/recipes-support/apr/apr/0002-apr-Remove-workdir-path-references-from-installed-ap.patch
> > > +++
> > > b/meta/recipes-support/apr/apr/0002-apr-Remove-workdir-path-references-from-installed-ap.patch
> > > @@ -1,8 +1,7 @@
> > > -From 5925b20da8bbc34d9bf5a5dca123ef38864d43c6 Mon Sep 17 00:00:00 2001
> > > +From c06e33851c4b209996682897a02a4219ebf34197 Mon Sep 17 00:00:00 2001
> > > From: Hongxu Jia
> > > Date: Tue, 30 Jan 2018 09:39:06 +0800
> > > -Subject: [PATCH 2/7] apr: Remove workdir path references from installed
> > > apr
> > > - files
> > > +Subject: [PATCH] apr: Remove workdir path references from installed apr
> > > files
> > >
> > > Upstream-Status: Inappropriate [configuration]
> > >
> > > @@ -14,6 +13,7 @@ packages at target run time, the workdir path caused
> > > confusion.
> > > Rebase to 1.6.3
> > >
> > > Signed-off-by: Hongxu Jia
> > > +
> > > ---
> > > apr-config.in | 26 ++
> > > 1 file changed, 2 insertions(+), 24 deletions(-)
> > > @@ -69,6 +69,3 @@ index 84b4073..bbbf651 100644
> > > ;;
> > > --shlib-path-var)
> > > echo "$SHLIBPATH_VAR"
> > > ---
> > > -1.8.3.1
> > > -
> > > diff --git
> > > a/meta/recipes-support/apr/apr/0003-Makefile.in-configure.in-support-cross-compiling.patch
> > >
> > > b/meta/recipes-support/apr/apr/0003-Makefile.in-configure.in-support-cross-compiling.patch
> > > index 4dd53bd8eb..95f45ca896 100644
> > > ---
> > >
Re: [OE-core] [PATCH] apr: update to 1.7.0
On Thu, Apr 25, 2019 at 04:21:22PM +0100, Burton, Ross wrote:
> Sadly this breaks subversion target builds:
>
> checking for linking Python libraries...
> checking for apr_int64_t Python/C API format string...
> configure: error: failed to recognize APR_INT64_T_FMT on this platform
I had recently the same on my gentoo host, the same fix might apply
here:
https://github.com/gentoo/gentoo/commit/94454a54314e0b471877ee2d1b44d8a6b9128cea
>
> Ross
>
> On Wed, 24 Apr 2019 at 16:09, Oleksandr Kravchuk
> wrote:
> >
> > Refreshed patches with devtool.
> >
> > Signed-off-by: Oleksandr Kravchuk
> > ---
> > ...ldcheck.sh-improve-libtool-detection.patch | 10 +++
> > ...ir-path-references-from-installed-ap.patch | 9 +++
> > ...configure.in-support-cross-compiling.patch | 12 -
> > ...04-Fix-packet-discards-HTTP-redirect.patch | 8 +++---
> > ...-LTFLAGS-to-make-it-work-with-ccache.patch | 10 +++
> > ...ze-doesn-t-match-in-glibc-when-cross.patch | 27 +--
> > ...libapr-against-phtread-to-make-gold-.patch | 14 +-
> > .../apr/{apr_1.6.5.bb => apr_1.7.0.bb}| 4 +--
> > 8 files changed, 40 insertions(+), 54 deletions(-)
> > rename meta/recipes-support/apr/{apr_1.6.5.bb => apr_1.7.0.bb} (96%)
> >
> > diff --git
> > a/meta/recipes-support/apr/apr/0001-build-buildcheck.sh-improve-libtool-detection.patch
> >
> > b/meta/recipes-support/apr/apr/0001-build-buildcheck.sh-improve-libtool-detection.patch
> > index 097c195a19..c0426797bd 100644
> > ---
> > a/meta/recipes-support/apr/apr/0001-build-buildcheck.sh-improve-libtool-detection.patch
> > +++
> > b/meta/recipes-support/apr/apr/0001-build-buildcheck.sh-improve-libtool-detection.patch
> > @@ -1,19 +1,20 @@
> > -From 4efdc06fb17b8a00a9eca923caa176be741d1e04 Mon Sep 17 00:00:00 2001
> > +From 507a36c128c22fad2e7183f3da5bc8424fb42729 Mon Sep 17 00:00:00 2001
> > From: Hongxu Jia
> > Date: Thu, 1 Feb 2018 14:56:13 +0800
> > -Subject: [PATCH 1/7] build/buildcheck.sh: improve libtool detection
> > +Subject: [PATCH] build/buildcheck.sh: improve libtool detection
> >
> > Support customize libtool by variable assigning, it is helpful
> > for cross compileing (such as libtool=aarch64-linux-libtool)
> >
> > Upstream-Status: Submitted [https://github.com/apache/apr/pull/8]
> > Signed-off-by: Hongxu Jia
> > +
> > ---
> > build/buildcheck.sh | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/build/buildcheck.sh b/build/buildcheck.sh
> > -index ab5df44..f191a41 100755
> > +index 76ff8ce..44921b5 100755
> > --- a/build/buildcheck.sh
> > +++ b/build/buildcheck.sh
> > @@ -40,7 +40,9 @@ fi
> > @@ -27,6 +28,3 @@ index ab5df44..f191a41 100755
> > lt_pversion=`$libtool --version 2>/dev/null|sed -e
> > 's/([^)]*)//g;s/^[^0-9]*//;s/[- ].*//g;q'`
> > if test -z "$lt_pversion"; then
> > echo "buildconf: libtool not found."
> > ---
> > -1.8.3.1
> > -
> > diff --git
> > a/meta/recipes-support/apr/apr/0002-apr-Remove-workdir-path-references-from-installed-ap.patch
> >
> > b/meta/recipes-support/apr/apr/0002-apr-Remove-workdir-path-references-from-installed-ap.patch
> > index 72e706f966..6b7156a439 100644
> > ---
> > a/meta/recipes-support/apr/apr/0002-apr-Remove-workdir-path-references-from-installed-ap.patch
> > +++
> > b/meta/recipes-support/apr/apr/0002-apr-Remove-workdir-path-references-from-installed-ap.patch
> > @@ -1,8 +1,7 @@
> > -From 5925b20da8bbc34d9bf5a5dca123ef38864d43c6 Mon Sep 17 00:00:00 2001
> > +From c06e33851c4b209996682897a02a4219ebf34197 Mon Sep 17 00:00:00 2001
> > From: Hongxu Jia
> > Date: Tue, 30 Jan 2018 09:39:06 +0800
> > -Subject: [PATCH 2/7] apr: Remove workdir path references from installed apr
> > - files
> > +Subject: [PATCH] apr: Remove workdir path references from installed apr
> > files
> >
> > Upstream-Status: Inappropriate [configuration]
> >
> > @@ -14,6 +13,7 @@ packages at target run time, the workdir path caused
> > confusion.
> > Rebase to 1.6.3
> >
> > Signed-off-by: Hongxu Jia
> > +
> > ---
> > apr-config.in | 26 ++
> > 1 file changed, 2 insertions(+), 24 deletions(-)
> > @@ -69,6 +69,3 @@ index 84b4073..bbbf651 100644
> > ;;
> > --shlib-path-var)
> > echo "$SHLIBPATH_VAR"
> > ---
> > -1.8.3.1
> > -
> > diff --git
> > a/meta/recipes-support/apr/apr/0003-Makefile.in-configure.in-support-cross-compiling.patch
> >
> > b/meta/recipes-support/apr/apr/0003-Makefile.in-configure.in-support-cross-compiling.patch
> > index 4dd53bd8eb..95f45ca896 100644
> > ---
> > a/meta/recipes-support/apr/apr/0003-Makefile.in-configure.in-support-cross-compiling.patch
> > +++
> > b/meta/recipes-support/apr/apr/0003-Makefile.in-configure.in-support-cross-compiling.patch
> > @@ -1,7 +1,7 @@
> > -From d5028c10f156c224475b340cfb1ba025d6797243 Mon Sep 17 00:00:00 2001
> > +From 90b35ba29588ec4359eb8e5f0b8477c46d7baa6b Mon Sep 17 00:00:00 2001
> > From: Hongxu Jia
> > Date: Fri, 2 Feb 2018 15:51:42
Re: [OE-core] [PATCH] apr: update to 1.7.0
Sadly this breaks subversion target builds:
checking for linking Python libraries...
checking for apr_int64_t Python/C API format string...
configure: error: failed to recognize APR_INT64_T_FMT on this platform
Ross
On Wed, 24 Apr 2019 at 16:09, Oleksandr Kravchuk
wrote:
>
> Refreshed patches with devtool.
>
> Signed-off-by: Oleksandr Kravchuk
> ---
> ...ldcheck.sh-improve-libtool-detection.patch | 10 +++
> ...ir-path-references-from-installed-ap.patch | 9 +++
> ...configure.in-support-cross-compiling.patch | 12 -
> ...04-Fix-packet-discards-HTTP-redirect.patch | 8 +++---
> ...-LTFLAGS-to-make-it-work-with-ccache.patch | 10 +++
> ...ze-doesn-t-match-in-glibc-when-cross.patch | 27 +--
> ...libapr-against-phtread-to-make-gold-.patch | 14 +-
> .../apr/{apr_1.6.5.bb => apr_1.7.0.bb}| 4 +--
> 8 files changed, 40 insertions(+), 54 deletions(-)
> rename meta/recipes-support/apr/{apr_1.6.5.bb => apr_1.7.0.bb} (96%)
>
> diff --git
> a/meta/recipes-support/apr/apr/0001-build-buildcheck.sh-improve-libtool-detection.patch
>
> b/meta/recipes-support/apr/apr/0001-build-buildcheck.sh-improve-libtool-detection.patch
> index 097c195a19..c0426797bd 100644
> ---
> a/meta/recipes-support/apr/apr/0001-build-buildcheck.sh-improve-libtool-detection.patch
> +++
> b/meta/recipes-support/apr/apr/0001-build-buildcheck.sh-improve-libtool-detection.patch
> @@ -1,19 +1,20 @@
> -From 4efdc06fb17b8a00a9eca923caa176be741d1e04 Mon Sep 17 00:00:00 2001
> +From 507a36c128c22fad2e7183f3da5bc8424fb42729 Mon Sep 17 00:00:00 2001
> From: Hongxu Jia
> Date: Thu, 1 Feb 2018 14:56:13 +0800
> -Subject: [PATCH 1/7] build/buildcheck.sh: improve libtool detection
> +Subject: [PATCH] build/buildcheck.sh: improve libtool detection
>
> Support customize libtool by variable assigning, it is helpful
> for cross compileing (such as libtool=aarch64-linux-libtool)
>
> Upstream-Status: Submitted [https://github.com/apache/apr/pull/8]
> Signed-off-by: Hongxu Jia
> +
> ---
> build/buildcheck.sh | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/build/buildcheck.sh b/build/buildcheck.sh
> -index ab5df44..f191a41 100755
> +index 76ff8ce..44921b5 100755
> --- a/build/buildcheck.sh
> +++ b/build/buildcheck.sh
> @@ -40,7 +40,9 @@ fi
> @@ -27,6 +28,3 @@ index ab5df44..f191a41 100755
> lt_pversion=`$libtool --version 2>/dev/null|sed -e
> 's/([^)]*)//g;s/^[^0-9]*//;s/[- ].*//g;q'`
> if test -z "$lt_pversion"; then
> echo "buildconf: libtool not found."
> ---
> -1.8.3.1
> -
> diff --git
> a/meta/recipes-support/apr/apr/0002-apr-Remove-workdir-path-references-from-installed-ap.patch
>
> b/meta/recipes-support/apr/apr/0002-apr-Remove-workdir-path-references-from-installed-ap.patch
> index 72e706f966..6b7156a439 100644
> ---
> a/meta/recipes-support/apr/apr/0002-apr-Remove-workdir-path-references-from-installed-ap.patch
> +++
> b/meta/recipes-support/apr/apr/0002-apr-Remove-workdir-path-references-from-installed-ap.patch
> @@ -1,8 +1,7 @@
> -From 5925b20da8bbc34d9bf5a5dca123ef38864d43c6 Mon Sep 17 00:00:00 2001
> +From c06e33851c4b209996682897a02a4219ebf34197 Mon Sep 17 00:00:00 2001
> From: Hongxu Jia
> Date: Tue, 30 Jan 2018 09:39:06 +0800
> -Subject: [PATCH 2/7] apr: Remove workdir path references from installed apr
> - files
> +Subject: [PATCH] apr: Remove workdir path references from installed apr files
>
> Upstream-Status: Inappropriate [configuration]
>
> @@ -14,6 +13,7 @@ packages at target run time, the workdir path caused
> confusion.
> Rebase to 1.6.3
>
> Signed-off-by: Hongxu Jia
> +
> ---
> apr-config.in | 26 ++
> 1 file changed, 2 insertions(+), 24 deletions(-)
> @@ -69,6 +69,3 @@ index 84b4073..bbbf651 100644
> ;;
> --shlib-path-var)
> echo "$SHLIBPATH_VAR"
> ---
> -1.8.3.1
> -
> diff --git
> a/meta/recipes-support/apr/apr/0003-Makefile.in-configure.in-support-cross-compiling.patch
>
> b/meta/recipes-support/apr/apr/0003-Makefile.in-configure.in-support-cross-compiling.patch
> index 4dd53bd8eb..95f45ca896 100644
> ---
> a/meta/recipes-support/apr/apr/0003-Makefile.in-configure.in-support-cross-compiling.patch
> +++
> b/meta/recipes-support/apr/apr/0003-Makefile.in-configure.in-support-cross-compiling.patch
> @@ -1,7 +1,7 @@
> -From d5028c10f156c224475b340cfb1ba025d6797243 Mon Sep 17 00:00:00 2001
> +From 90b35ba29588ec4359eb8e5f0b8477c46d7baa6b Mon Sep 17 00:00:00 2001
> From: Hongxu Jia
> Date: Fri, 2 Feb 2018 15:51:42 +0800
> -Subject: [PATCH 3/7] Makefile.in/configure.in: support cross compiling
> +Subject: [PATCH] Makefile.in/configure.in: support cross compiling
>
> While cross compiling, the tools/gen_test_char could not
> be executed at build time, use AX_PROG_CC_FOR_BUILD to
> @@ -10,13 +10,14 @@ build native tools/gen_test_char
> Upstream-Status: Submitted [https://github.com/apache/apr/pull/8]
>
> Signed-off-by: Hongxu Jia
> +
> ---
> Makefile.in | 10
Re: [OE-core] [PATCH] package_ipk: handle exception for subprocess command
On Thu, Apr 25, 2019 at 4:51 PM Andrey Zhizhikin wrote: > > Thanks a lot, I'll definitely give it a try! Would you be willing to > take this further in into the master branch? Just saw your other patch against [utils/multiprocess_launch], please discard this question. -- Regards, Andrey. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] package_ipk: handle exception for subprocess command
On Thu, Apr 25, 2019 at 3:41 PM wrote:
>
> On Tue, 2019-04-16 at 11:12 +0200, Andrey Zhizhikin wrote:
> > On Tue, Apr 16, 2019 at 10:24 AM
> > wrote:
> > > On Tue, 2019-04-16 at 09:10 +0200, Andrey Zhizhikin wrote:
> > > > On Mon, Apr 15, 2019 at 6:45 PM Richard Purdie
> > > > wrote:
> > > > > On Sun, 2019-04-14 at 16:21 +0200, Andrey Zhizhikin wrote:
> > > > > > Ping.
> > > > > >
> > > > > > On Thu, Mar 28, 2019 at 10:47 AM Andrey Zhizhikin <
> > > > > > andre...@gmail.com
> > > > > > > wrote:
> > > > > > > When opkg-build command fails to execute, subprocess is
> > > > > > > returned
> > > > > > > with
> > > > > > > exception instead of printing to stderr. This causes the
> > > > > > > error
> > > > > > > logging
> > > > > > > not to be printed out, as the "finally" statement does not
> > > > > > > contain
> > > > > > > any
> > > > > > > bitbake error output.
> > > > > > >
> > > > > > > One example of this behavior is when the package name
> > > > > > > contains
> > > > > > > uppercase
> > > > > > > character, which are rejected by opkg-build,
> > > > > > > subprocess.check_output
> > > > > > > would except and no error log would be produced.
> > > > > > >
> > > > > > > This commit catches the exception
> > > > > > > subprocess.CalledProcessError
> > > > > > > and
> > > > > > > produces bb.error output visible to the user.
> > > > > > >
> > > > > > > Signed-off-by: Andrey Zhizhikin
> > > > > > > ---
> > > > > > > meta/classes/package_ipk.bbclass | 2 ++
> > > > > > > 1 file changed, 2 insertions(+)
> > > > > > >
> > > > > > > diff --git a/meta/classes/package_ipk.bbclass
> > > > > > > b/meta/classes/package_ipk.bbclass
> > > > > > > index d1b317b42b..f181f5b4fd 100644
> > > > > > > --- a/meta/classes/package_ipk.bbclass
> > > > > > > +++ b/meta/classes/package_ipk.bbclass
> > > > > > > @@ -234,6 +234,8 @@ def ipk_write_pkg(pkg, d):
> > > > > > > ipk_to_sign = "%s/%s_%s_%s.ipk" % (pkgoutdir,
> > > > > > > pkgname,
> > > > > > > ipkver, d.getVar('PACKAGE_ARCH'))
> > > > > > > sign_ipk(d, ipk_to_sign)
> > > > > > >
> > > > > > > +except subprocess.CalledProcessError as exc:
> > > > > > > +bb.error("OPKG Build failed: %s" % exc.output)
> > > > > > > finally:
> > > > > > > cleanupcontrol(root)
> > > > > > > bb.utils.unlockfile(lf)
> > > > >
> > > > > My main concern is why isn't the raised exception being caught
> > > > > and
> > > > > causing its own error...
> > > >
> > > > The raised exception is actually caught by a finally: statement
> > > > below, and the build gracefully terminates. The problem is that
> > > > finally: block does not contain any valuable output to inform
> > > > user
> > > > what actually happened.
> > >
> > > This isn't how python works. The exception should be "re-raised
> > > after
> > > the finally clause has been executed" to quote the python manual:
> > > https://docs.python.org/3/tutorial/errors.html#defining-clean-up-actions
> > >
> >
> > Sorry, I guess my previous reply was a bit confusing.. I agree, the
> > exception would not be blocked by finally: statement, and this is why
> > the build gracefully shuts down. What the finally: block does not
> > contain is an bb.error() which would provide more information about
> > the source of error return from subprocess.check_output(). In case if
> > this patch is applied - exception would be handled and not propagated
> > further.
> >
> > Can you please advise whether there would another "raise" statement
> > be
> > needed after bb.error in the patch, so that in addition to the
> > subprocess output user would get an entire callstack (like in the
> > case
> > when subprocess.CalledProcessError was not handled). Currently, with
> > this patch user would receive the build error with the error string
> > output from subprocess.check_output().
>
> My worry is that we're making a special case fix and for example the
> other package back ends could have a similar problem (or any other
> users of multiprocess_launch).
>
> I already think subprocess in python is a bit broken as it should share
> e.output if its present in an exception. We already special case that
> in bitbake, the problem here is that our special case code doesn't
> catch this.
Agree, I was also puzzled why there is no valuable output from
subprocess in case exception was raised.
>
> Whilst still ugly, perhaps a better fix might be:
>
> diff --git a/meta/lib/oe/utils.py b/meta/lib/oe/utils.py
> index a4fd79ccb21..59251810d43 100644
> --- a/meta/lib/oe/utils.py
> +++ b/meta/lib/oe/utils.py
> @@ -324,7 +324,12 @@ def multiprocess_launch(target, items, d,
> extraargs=None):
> if errors:
> msg = ""
> for (e, tb) in errors:
> -msg = msg + str(e) + ": " + str(tb) + "\n"
> +if isinstance(e, subprocess.CalledProcessError) and e.output:
> +msg = msg + str(e) + "\n"
> +msg = msg + "Subprocess output:"
> +msg = msg +
Re: [OE-core] [PATCH] qemu: Upgrade from 3.1.0 to 4.0.0
On 4/25/19 6:49 AM, Richard Purdie wrote: > On Wed, 2019-04-24 at 00:15 +, Alistair Francis wrote: >> This commit upgrade QEMU to the latest 4.0.0 release. >> >> - The COPYING.LIB file has changed SHA to: >> "Synchronize the LGPL 2.1 with the version from gnu.org" >> - SDL 1.2 has been removed, along with the --with-sdlabi command >> line >> arg >> - The backported patches have been removed >> - Al the other patches have been refreshed and the numbering has >> been >> updated > I put this in for testing but it failed as nativesdk-qemu doesn't build > due to unpackaged files: Bug opened: 13308 Thanks, Your neighborhood swat team. > https://autobuilder.yoctoproject.org/typhoon/#/builders/65/builds/535/steps/7/logs/step1b > > Cheers, > > Richard > -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] utils/multiprocess_launch: Improve failing subprocess output
Output before this patch:
ERROR: bash-4.4.18-r0 do_package_write_ipk: Fatal errors occurred in
subprocesses:
Command 'PATH="X" opkg-build -Z xz -a "--memlimit=50% --threads=88" Foobar
/media/build1/poky/build/nodistro-glibc/work/core2-64-oe-linux/bash/4.4.18-r0/deploy-ipks/core2-64'
returned non-zero exit status 1.: Traceback (most recent call last):
File "/media/build1/poky/meta/lib/oe/utils.py", line 272, in run
ret = self._target(*self._args, **self._kwargs)
File "/media/build1/poky/meta/classes/package_ipk.bbclass", line 230, in
ipk_write_pkg
shell=True)
File "/usr/lib/python3.6/subprocess.py", line 336, in check_output
**kwargs).stdout
File "/usr/lib/python3.6/subprocess.py", line 418, in run
output=stdout, stderr=stderr)
subprocess.CalledProcessError: Command 'PATH="X" opkg-build -Z xz -a
"--memlimit=50% --threads=88" Foobar
/media/build1/poky/build/nodistro-glibc/work/core2-64-oe-linux/bash/4.4.18-r0/deploy-ipks/core2-64'
returned non-zero exit status 1.
Note how stdout/stderr from the failing command isn't shown.
After this patch:
ERROR: bash-4.4.18-r0 do_package_write_ipk: Fatal errors occurred in
subprocesses:
Command 'PATH="X" opkg-build -Z xz -a "--memlimit=50% --threads=88" Foobar
/media/build1/poky/build/nodistro-glibc/work/core2-64-oe-linux/bash/4.4.18-r0/deploy-ipks/core2-64'
returned non-zero exit status 1.
Subprocess output:Foobar
*** Error: Package name Foobar contains illegal characters, (other than
[a-z0-9.+-])
opkg-build: Please fix the above errors and try again.
We suddenly get a much more usable error message. The traceback is supressed
as its distracting from the real problem in this case.
Ideally python itself would handle this but it doesn't so we have to
wrap the exception. We already do this in bitbake itself for the same reason.
Signed-off-by: Richard Purdie
---
meta/lib/oe/utils.py | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/meta/lib/oe/utils.py b/meta/lib/oe/utils.py
index a4fd79ccb21..59251810d43 100644
--- a/meta/lib/oe/utils.py
+++ b/meta/lib/oe/utils.py
@@ -324,7 +324,12 @@ def multiprocess_launch(target, items, d, extraargs=None):
if errors:
msg = ""
for (e, tb) in errors:
-msg = msg + str(e) + ": " + str(tb) + "\n"
+if isinstance(e, subprocess.CalledProcessError) and e.output:
+msg = msg + str(e) + "\n"
+msg = msg + "Subprocess output:"
+msg = msg + e.output.decode("utf-8", errors="ignore")
+else:
+msg = msg + str(e) + ": " + str(tb) + "\n"
bb.fatal("Fatal errors occurred in subprocesses:\n%s" % msg)
return results
--
2.20.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [RFC,v5] mesa: Convert recipe to use meson build system
- Remove all non related meson patches
- Change radeon driver to r100
- Add python3-mako-native gettext-native to DEPENDS
Based on https://patchwork.openembedded.org/patch/158748/
Signed-off-by: Fabio Berton
---
...0001-Simplify-wayland-scanner-lookup.patch | 44 --
...k-for-all-linux-host_os-combinations.patch | 51
...-winsys-svga-drm-Include-sys-types.h.patch | 35 ---
...M-version-when-using-LLVM-Git-releas.patch | 45 --
...R-for-defining-WAYLAND_PROTOCOLS_DAT.patch | 38
meta/recipes-graphics/mesa/mesa.inc | 60 +--
meta/recipes-graphics/mesa/mesa_19.0.3.bb | 5 +-
7 files changed, 79 insertions(+), 199 deletions(-)
delete mode 100644
meta/recipes-graphics/mesa/files/0001-Simplify-wayland-scanner-lookup.patch
create mode 100644
meta/recipes-graphics/mesa/files/0001-meson.build-check-for-all-linux-host_os-combinations.patch
delete mode 100644
meta/recipes-graphics/mesa/files/0002-winsys-svga-drm-Include-sys-types.h.patch
delete mode 100644
meta/recipes-graphics/mesa/files/0003-Properly-get-LLVM-version-when-using-LLVM-Git-releas.patch
delete mode 100644
meta/recipes-graphics/mesa/files/0004-use-PKG_CHECK_VAR-for-defining-WAYLAND_PROTOCOLS_DAT.patch
diff --git
a/meta/recipes-graphics/mesa/files/0001-Simplify-wayland-scanner-lookup.patch
b/meta/recipes-graphics/mesa/files/0001-Simplify-wayland-scanner-lookup.patch
deleted file mode 100644
index d065e2285c..00
---
a/meta/recipes-graphics/mesa/files/0001-Simplify-wayland-scanner-lookup.patch
+++ /dev/null
@@ -1,44 +0,0 @@
-From e53837ad7b01364f34a533b95f4817c1795789de Mon Sep 17 00:00:00 2001
-From: Fabio Berton
-Date: Wed, 20 Feb 2019 16:17:00 -0300
-Subject: [PATCH 1/4] Simplify wayland-scanner lookup
-Organization: O.S. Systems Software LTDA.
-
-Don't use pkg-config to lookup the path of a binary that's in the path.
-
-Alternatively we'd have to prefix the path returned by pkg-config with
-PKG_CONFIG_SYSROOT_DIR.
-
-Upstream-Status: Pending
-Signed-off-by: Jussi Kukkonen
-Signed-off-by: Otavio Salvador
-Signed-off-by: Fabio Berton
- configure.ac | 7 +--
- 1 file changed, 1 insertion(+), 6 deletions(-)
-
-diff --git a/configure.ac b/configure.ac
-index 1ef68fe68e6..1816a4cd475 100644
a/configure.ac
-+++ b/configure.ac
-@@ -1854,16 +1854,11 @@ for plat in $platforms; do
- fi
- WAYLAND_PROTOCOLS_DATADIR=`$PKG_CONFIG --variable=pkgdatadir
wayland-protocols`
-
--PKG_CHECK_MODULES([WAYLAND_SCANNER], [wayland-scanner],
-- WAYLAND_SCANNER=`$PKG_CONFIG
--variable=wayland_scanner wayland-scanner`,
-- WAYLAND_SCANNER='')
- PKG_CHECK_EXISTS([wayland-scanner >= 1.15],
- AC_SUBST(SCANNER_ARG, 'private-code'),
- AC_SUBST(SCANNER_ARG, 'code'))
-
--if test "x$WAYLAND_SCANNER" = x; then
--AC_PATH_PROG([WAYLAND_SCANNER], [wayland-scanner], [:])
--fi
-+AC_PATH_PROG([WAYLAND_SCANNER], [wayland-scanner], [:])
-
- if test "x$WAYLAND_SCANNER" = "x:"; then
- AC_MSG_ERROR([wayland-scanner is needed to compile the
wayland platform])
---
-2.21.0
-
diff --git
a/meta/recipes-graphics/mesa/files/0001-meson.build-check-for-all-linux-host_os-combinations.patch
b/meta/recipes-graphics/mesa/files/0001-meson.build-check-for-all-linux-host_os-combinations.patch
new file mode 100644
index 00..61e24c6e9f
--- /dev/null
+++
b/meta/recipes-graphics/mesa/files/0001-meson.build-check-for-all-linux-host_os-combinations.patch
@@ -0,0 +1,51 @@
+From 498f230c9446fc7a1b4dc77ff6b84ee1a3b53bf4 Mon Sep 17 00:00:00 2001
+From: Fabio Berton
+Date: Wed, 24 Apr 2019 17:01:24 -0300
+Subject: [PATCH] meson.build: check for all linux host_os combinations
+Organization: O.S. Systems Software LTDA.
+
+Make sure that we are also looking for our host_os combinations like
+linux-musl etc. when assuming support for DRM/KMS.
+
+Also delete a duplicate line.
+
+Signed-off-by: Anuj Mittal
+Signed-off-by: Fabio Berton
+---
+ meson.build | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/meson.build b/meson.build
+index 53d02e31097..c41f6b4e402 100644
+--- a/meson.build
b/meson.build
+@@ -34,6 +34,8 @@ cpp = meson.get_compiler('cpp')
+
+ null_dep = dependency('', required : false)
+
++system_has_kms_drm = ['openbsd', 'netbsd', 'freebsd',
'dragonfly'].contains(host_machine.system()) or
host_machine.system().startswith('linux')
++
+ # Arguments for the preprocessor, put these in a separate array from the C and
+ # C++ (cpp in meson terminology) arguments since they need to be added to the
+ # default arguments for both C and C++.
+@@ -89,8 +91,6 @@ if (with_gles1 or with_gles2) and not with_opengl
+ error('building OpenGL ES without OpenGL is not supported.')
+ endif
+
+-system_has_kms_drm = ['openbsd', 'netbsd', 'freebsd',
Re: [OE-core] [PATCH] qemu: Upgrade from 3.1.0 to 4.0.0
On Wed, 2019-04-24 at 00:15 +, Alistair Francis wrote: > This commit upgrade QEMU to the latest 4.0.0 release. > > - The COPYING.LIB file has changed SHA to: > "Synchronize the LGPL 2.1 with the version from gnu.org" > - SDL 1.2 has been removed, along with the --with-sdlabi command > line > arg > - The backported patches have been removed > - Al the other patches have been refreshed and the numbering has > been > updated I put this in for testing but it failed as nativesdk-qemu doesn't build due to unpackaged files: https://autobuilder.yoctoproject.org/typhoon/#/builders/65/builds/535/steps/7/logs/step1b Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] package_ipk: handle exception for subprocess command
On Tue, 2019-04-16 at 11:12 +0200, Andrey Zhizhikin wrote:
> On Tue, Apr 16, 2019 at 10:24 AM
> wrote:
> > On Tue, 2019-04-16 at 09:10 +0200, Andrey Zhizhikin wrote:
> > > On Mon, Apr 15, 2019 at 6:45 PM Richard Purdie
> > > wrote:
> > > > On Sun, 2019-04-14 at 16:21 +0200, Andrey Zhizhikin wrote:
> > > > > Ping.
> > > > >
> > > > > On Thu, Mar 28, 2019 at 10:47 AM Andrey Zhizhikin <
> > > > > andre...@gmail.com
> > > > > > wrote:
> > > > > > When opkg-build command fails to execute, subprocess is
> > > > > > returned
> > > > > > with
> > > > > > exception instead of printing to stderr. This causes the
> > > > > > error
> > > > > > logging
> > > > > > not to be printed out, as the "finally" statement does not
> > > > > > contain
> > > > > > any
> > > > > > bitbake error output.
> > > > > >
> > > > > > One example of this behavior is when the package name
> > > > > > contains
> > > > > > uppercase
> > > > > > character, which are rejected by opkg-build,
> > > > > > subprocess.check_output
> > > > > > would except and no error log would be produced.
> > > > > >
> > > > > > This commit catches the exception
> > > > > > subprocess.CalledProcessError
> > > > > > and
> > > > > > produces bb.error output visible to the user.
> > > > > >
> > > > > > Signed-off-by: Andrey Zhizhikin
> > > > > > ---
> > > > > > meta/classes/package_ipk.bbclass | 2 ++
> > > > > > 1 file changed, 2 insertions(+)
> > > > > >
> > > > > > diff --git a/meta/classes/package_ipk.bbclass
> > > > > > b/meta/classes/package_ipk.bbclass
> > > > > > index d1b317b42b..f181f5b4fd 100644
> > > > > > --- a/meta/classes/package_ipk.bbclass
> > > > > > +++ b/meta/classes/package_ipk.bbclass
> > > > > > @@ -234,6 +234,8 @@ def ipk_write_pkg(pkg, d):
> > > > > > ipk_to_sign = "%s/%s_%s_%s.ipk" % (pkgoutdir,
> > > > > > pkgname,
> > > > > > ipkver, d.getVar('PACKAGE_ARCH'))
> > > > > > sign_ipk(d, ipk_to_sign)
> > > > > >
> > > > > > +except subprocess.CalledProcessError as exc:
> > > > > > +bb.error("OPKG Build failed: %s" % exc.output)
> > > > > > finally:
> > > > > > cleanupcontrol(root)
> > > > > > bb.utils.unlockfile(lf)
> > > >
> > > > My main concern is why isn't the raised exception being caught
> > > > and
> > > > causing its own error...
> > >
> > > The raised exception is actually caught by a finally: statement
> > > below, and the build gracefully terminates. The problem is that
> > > finally: block does not contain any valuable output to inform
> > > user
> > > what actually happened.
> >
> > This isn't how python works. The exception should be "re-raised
> > after
> > the finally clause has been executed" to quote the python manual:
> > https://docs.python.org/3/tutorial/errors.html#defining-clean-up-actions
> >
>
> Sorry, I guess my previous reply was a bit confusing.. I agree, the
> exception would not be blocked by finally: statement, and this is why
> the build gracefully shuts down. What the finally: block does not
> contain is an bb.error() which would provide more information about
> the source of error return from subprocess.check_output(). In case if
> this patch is applied - exception would be handled and not propagated
> further.
>
> Can you please advise whether there would another "raise" statement
> be
> needed after bb.error in the patch, so that in addition to the
> subprocess output user would get an entire callstack (like in the
> case
> when subprocess.CalledProcessError was not handled). Currently, with
> this patch user would receive the build error with the error string
> output from subprocess.check_output().
My worry is that we're making a special case fix and for example the
other package back ends could have a similar problem (or any other
users of multiprocess_launch).
I already think subprocess in python is a bit broken as it should share
e.output if its present in an exception. We already special case that
in bitbake, the problem here is that our special case code doesn't
catch this.
Whilst still ugly, perhaps a better fix might be:
diff --git a/meta/lib/oe/utils.py b/meta/lib/oe/utils.py
index a4fd79ccb21..59251810d43 100644
--- a/meta/lib/oe/utils.py
+++ b/meta/lib/oe/utils.py
@@ -324,7 +324,12 @@ def multiprocess_launch(target, items, d, extraargs=None):
if errors:
msg = ""
for (e, tb) in errors:
-msg = msg + str(e) + ": " + str(tb) + "\n"
+if isinstance(e, subprocess.CalledProcessError) and e.output:
+msg = msg + str(e) + "\n"
+msg = msg + "Subprocess output:"
+msg = msg + e.output.decode("utf-8", errors="ignore")
+else:
+msg = msg + str(e) + ": " + str(tb) + "\n"
bb.fatal("Fatal errors occurred in subprocesses:\n%s" % msg)
return results
which I think from some local testing gives better output and would
solve your concern and some of mine?
Cheers,
Richard
--
Re: [OE-core] [thud][PATCH] opkg-utils: backport a patch to fix a sstate timestamp issue
On 05.04.2019 16:22, liu.min...@gmail.com wrote:
> From: Ming Liu
>
> When using sstate, two parallel builds can produce two packages
> with the same mtime but different checksums. When later one of
> those two builds fetches the others ipk, the package index does
> not get udpated properly (since mtime matches). This ends up with
> messages such as:
> Downloading file:/../tmp/work/../image/...ipk.
> Removing corrupt package file /../sysroot/../var/cache/opkg/volatile/...ipk
>
> However, in that case, ctime is different. Use ctime instead of
> mtime to prevent failures like this.
FWIW,
Acked-by Stefan Agner
I fixed this in master, and it actually helps us resolving issues we see
on CI on thud branch.
--
Stefan
>
> Signed-off-by: Ming Liu
> ---
> ...pkg-make-index-use-ctime-instead-of-mtime.patch | 59
> ++
> .../opkg-utils/opkg-utils_0.3.6.bb | 1 +
> 2 files changed, 60 insertions(+)
> create mode 100644
> meta/recipes-devtools/opkg-utils/opkg-utils/0001-opkg-make-index-use-ctime-instead-of-mtime.patch
>
> diff --git
> a/meta/recipes-devtools/opkg-utils/opkg-utils/0001-opkg-make-index-use-ctime-instead-of-mtime.patch
> b/meta/recipes-devtools/opkg-utils/opkg-utils/0001-opkg-make-index-use-ctime-instead-of-mtime.patch
> new file mode 100644
> index 000..19778ac
> --- /dev/null
> +++
> b/meta/recipes-devtools/opkg-utils/opkg-utils/0001-opkg-make-index-use-ctime-instead-of-mtime.patch
> @@ -0,0 +1,59 @@
> +From 0cd38bb1bdcdbfc091014a1f39d015a1586a33e6 Mon Sep 17 00:00:00 2001
> +From: Stefan Agner
> +Date: Fri, 19 Oct 2018 17:38:21 +0200
> +Subject: [PATCH] opkg-make-index: use ctime instead of mtime
> +
> +Upstream-Status: Backport
> +
> +When using sstate, two parallel builds can produce two packages
> +with the same mtime but different checksums. When later one of
> +those two builds fetches the others ipk, the package index does
> +not get udpated properly (since mtime matches). This ends up with
> +messages such as:
> + Downloading file:/../tmp/work/../image/...ipk.
> + Removing corrupt package file /../sysroot/../var/cache/opkg/volatile/...ipk
> +
> +However, in that case, ctime is different. Use ctime instead of
> +mtime to prevent failures like this.
> +
> +Suggested-by: Khem Raj
> +Signed-off-by: Stefan Agner
> +Acked-by: Richard Purdie
> +Acked-by: Khem Raj
> +Signed-off-by: Alejandro del Castillo
> +Signed-off-by: Ming Liu
> +---
> + opkg-make-index | 6 +++---
> + 1 file changed, 3 insertions(+), 3 deletions(-)
> +
> +diff --git a/opkg-make-index b/opkg-make-index
> +index 3227fc0..db7bf64 100755
> +--- a/opkg-make-index
> b/opkg-make-index
> +@@ -115,12 +115,12 @@ for abspath in files:
> + pkg = None
> + fnameStat = os.stat(abspath)
> + if filename in old_pkg_hash:
> +- if filename in pkgsStamps and int(fnameStat.st_mtime) ==
> pkgsStamps[filename]:
> ++ if filename in pkgsStamps and int(fnameStat.st_ctime) ==
> pkgsStamps[filename]:
> + if (verbose):
> +sys.stderr.write("Found %s in Packages\n" % (filename,))
> + pkg = old_pkg_hash[filename]
> + else:
> +- sys.stderr.write("Found %s in Packages, but mtime
> differs - re-reading\n" % (filename,))
> ++ sys.stderr.write("Found %s in Packages, but ctime
> differs - re-reading\n" % (filename,))
> +
> + if not pkg:
> + if (verbose):
> +@@ -137,7 +137,7 @@ for abspath in files:
> + else:
> + old_filename = ""
> + s = packages.add_package(pkg, opt_a)
> +- pkgsStamps[filename] = fnameStat.st_mtime
> ++ pkgsStamps[filename] = fnameStat.st_ctime
> + if s == 0:
> + if old_filename:
> +# old package was displaced by newer
> +--
> +2.7.4
> +
> diff --git a/meta/recipes-devtools/opkg-utils/opkg-utils_0.3.6.bb
> b/meta/recipes-devtools/opkg-utils/opkg-utils_0.3.6.bb
> index 4c41774..41cf11c 100644
> --- a/meta/recipes-devtools/opkg-utils/opkg-utils_0.3.6.bb
> +++ b/meta/recipes-devtools/opkg-utils/opkg-utils_0.3.6.bb
> @@ -14,6 +14,7 @@ SRC_URI =
> "http://git.yoctoproject.org/cgit/cgit.cgi/${BPN}/snapshot/${BPN}-${PV
> file://threaded-xz.patch \
> file://pigz.patch \
> file://0001-update-alternatives-Fix-link-relocation-support.patch
> \
> + file://0001-opkg-make-index-use-ctime-instead-of-mtime.patch \
> "
> SRC_URI_append_class-native = " file://tar_ignore_error.patch"
> UPSTREAM_CHECK_URI =
> "http://git.yoctoproject.org/cgit/cgit.cgi/opkg-utils/refs/;
> --
> 2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] package_ipk: handle exception for subprocess command
Hello Richard,
On Tue, Apr 16, 2019 at 11:12 AM Andrey Zhizhikin wrote:
>
> On Tue, Apr 16, 2019 at 10:24 AM wrote:
> >
> > On Tue, 2019-04-16 at 09:10 +0200, Andrey Zhizhikin wrote:
> > > On Mon, Apr 15, 2019 at 6:45 PM Richard Purdie
> > > wrote:
> > > > On Sun, 2019-04-14 at 16:21 +0200, Andrey Zhizhikin wrote:
> > > > > Ping.
> > > > >
> > > > > On Thu, Mar 28, 2019 at 10:47 AM Andrey Zhizhikin <
> > > > > andre...@gmail.com
> > > > > > wrote:
> > > > > > When opkg-build command fails to execute, subprocess is
> > > > > > returned
> > > > > > with
> > > > > > exception instead of printing to stderr. This causes the error
> > > > > > logging
> > > > > > not to be printed out, as the "finally" statement does not
> > > > > > contain
> > > > > > any
> > > > > > bitbake error output.
> > > > > >
> > > > > > One example of this behavior is when the package name contains
> > > > > > uppercase
> > > > > > character, which are rejected by opkg-build,
> > > > > > subprocess.check_output
> > > > > > would except and no error log would be produced.
> > > > > >
> > > > > > This commit catches the exception subprocess.CalledProcessError
> > > > > > and
> > > > > > produces bb.error output visible to the user.
> > > > > >
> > > > > > Signed-off-by: Andrey Zhizhikin
> > > > > > ---
> > > > > > meta/classes/package_ipk.bbclass | 2 ++
> > > > > > 1 file changed, 2 insertions(+)
> > > > > >
> > > > > > diff --git a/meta/classes/package_ipk.bbclass
> > > > > > b/meta/classes/package_ipk.bbclass
> > > > > > index d1b317b42b..f181f5b4fd 100644
> > > > > > --- a/meta/classes/package_ipk.bbclass
> > > > > > +++ b/meta/classes/package_ipk.bbclass
> > > > > > @@ -234,6 +234,8 @@ def ipk_write_pkg(pkg, d):
> > > > > > ipk_to_sign = "%s/%s_%s_%s.ipk" % (pkgoutdir,
> > > > > > pkgname,
> > > > > > ipkver, d.getVar('PACKAGE_ARCH'))
> > > > > > sign_ipk(d, ipk_to_sign)
> > > > > >
> > > > > > +except subprocess.CalledProcessError as exc:
> > > > > > +bb.error("OPKG Build failed: %s" % exc.output)
> > > > > > finally:
> > > > > > cleanupcontrol(root)
> > > > > > bb.utils.unlockfile(lf)
> > > >
> > > > My main concern is why isn't the raised exception being caught and
> > > > causing its own error...
> > >
> > > The raised exception is actually caught by a finally: statement
> > > below, and the build gracefully terminates. The problem is that
> > > finally: block does not contain any valuable output to inform user
> > > what actually happened.
> >
> > This isn't how python works. The exception should be "re-raised after
> > the finally clause has been executed" to quote the python manual:
> > https://docs.python.org/3/tutorial/errors.html#defining-clean-up-actions
> >
>
> Sorry, I guess my previous reply was a bit confusing.. I agree, the
> exception would not be blocked by finally: statement, and this is why
> the build gracefully shuts down. What the finally: block does not
> contain is an bb.error() which would provide more information about
> the source of error return from subprocess.check_output(). In case if
> this patch is applied - exception would be handled and not propagated
> further.
>
> Can you please advise whether there would another "raise" statement be
> needed after bb.error in the patch, so that in addition to the
> subprocess output user would get an entire callstack (like in the case
> when subprocess.CalledProcessError was not handled). Currently, with
> this patch user would receive the build error with the error string
> output from subprocess.check_output().
>
> Thanks a lot!
Can we follow-up on this patch? I'd really appreciate if you can
comment on my points here...
Thanks a lot!
>
> > > subprocess.check_output() would throw this exception every time the
> > > command in sub-process is terminated with the error code, and since
> > > we
> > > do tell it to dump stderr -> stdout - the error message would be
> > > contained in the exception output.
> > > This additional handling of the subprocess.check_output() exception
> > > would extract the stdout from the failed process here and just shows
> > > to the user the actual output from command processing, so that he is
> > > aware what was wrong.
> > >
> > > The case where I personally needed it the most is when the package
> > > name contained upper and lower case characters, which were rejected
> > > by
> > > the opkg-build command and until I introduced the handler - I just
> > > had
> > > an erroneous build failure without any additional information on what
> > > went wrong.
> > >
> > > > This feels like a workaround rather than fixing the underlying
> > > > problem
> > > > which I suspect might be in the parallel execution code exception
> > > > handling.
> > > The exception from subprocess.check_output() is actually expected
> > > and
> > > perfectly handled, so there is no problem with that. This patch would
> > > just deliver a bit more information in the output for user to react
Re: [OE-core] [oe-core][PATCH 1/1] gdk-pixbuf: add timeout to run-ptest
On Fri, 2019-04-19 at 12:58 -0700, Joe Slater wrote: > The default timeout of 300 seconds is far too low for qemu bsp's. > > Signed-off-by: Joe Slater > --- > meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf/run-ptest | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf/run-ptest > b/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf/run-ptest > index 8f90723..b4f982b 100644 > --- a/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf/run-ptest > +++ b/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf/run-ptest > @@ -1,3 +1,5 @@ > #! /bin/sh > > -gnome-desktop-testing-runner gdk-pixbuf > +# The default timeout of 300 seconds is far too low for qemu bsp's. > +# > +gnome-desktop-testing-runner -t 2400 gdk-pixbuf This raises an interesting dilemma. Do we set the timeouts to match a real hardware system, a software emulated qemu or a KVM accelerated qemu? My instinct says we should time these for real hardware and KVM accelerated images only as ptests are simply too slow to realistically run anywhere else. The downside to long timeouts is if something does break, long hanging builds. On that basis I'm not sure we want to start patching all the timeouts for software qemu... Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] resultool/resultutils: Fix module import error
Fix AttributeError: module 'urllib' has no attribute 'request' when using remote http urls. Signed-off-by: Richard Purdie --- scripts/lib/resulttool/resultutils.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/lib/resulttool/resultutils.py b/scripts/lib/resulttool/resultutils.py index aab312dd172..8d17c7cd658 100644 --- a/scripts/lib/resulttool/resultutils.py +++ b/scripts/lib/resulttool/resultutils.py @@ -16,7 +16,7 @@ import os import json import scriptpath import copy -import urllib +import urllib.request import posixpath scriptpath.add_oe_lib_path() -- 2.20.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v3 2/2] bitbake: fetch2/git: git-lfs check
On Thu, 2019-04-25 at 09:54 +0800, Naveen Saini wrote:
> Build will fail if repository has lfs contents in absense of git-lfs tool on
> host.
> Build will pass if repository may or may not contains lfs content if host has
> git-lfs installed.
Bitbake patches need to go to the bitbake list.
> Signed-off-by: Naveen Saini
> ---
> bitbake/lib/bb/fetch2/git.py | 24
> 1 file changed, 24 insertions(+)
>
> diff --git a/bitbake/lib/bb/fetch2/git.py b/bitbake/lib/bb/fetch2/git.py
> index 8185bf4..d862942 100644
> --- a/bitbake/lib/bb/fetch2/git.py
> +++ b/bitbake/lib/bb/fetch2/git.py
> @@ -503,6 +503,15 @@ class Git(FetchMethod):
>
> repourl = self._get_repo_url(ud)
> runfetchcmd("%s remote set-url origin %s" % (ud.basecmd, repourl),
> d, workdir=destdir)
> +
> +if self._contains_lfs(ud, d, destdir):
> +origbbenv = d.getVar("BB_ORIGENV", False)
> +path = origbbenv.getVar("PATH")
> +gitlfstool = bb.utils.which(path, "git-lfs", executable=True)
> +if not gitlfstool:
> +raise bb.fetch2.FetchError("Repository %s has lfs content,
> install git-lfs plugin on host to download" % (repourl))
Can we just rely on the usual PATH here please, I don't think we need
to touch BB_ORIGENV? We can assume the environment will be setup with
git-lfs if its present.
> +
> if not ud.nocheckout:
> if subdir != "":
> runfetchcmd("%s read-tree %s%s" % (ud.basecmd,
> ud.revisions[ud.names[0]], readpathspec), d,
> @@ -553,6 +562,21 @@ class Git(FetchMethod):
> raise bb.fetch2.FetchError("The command '%s' gave output with
> more then 1 line unexpectedly, output: '%s'" % (cmd, output))
> return output.split()[0] != "0"
>
> +def _contains_lfs(self, ud, d, wd):
> +"""
> +Check git lfs repository
If we're going to add a comment, please make it useful, e.g.
Check if the repository has 'lfs' (large file) content
> +"""
> +cmd = "%s grep lfs HEAD:.gitattributes | wc -l" % (
> +ud.basecmd)
> +try:
> +output = runfetchcmd(cmd, d, quiet=True, workdir=wd)
> +except bb.fetch2.FetchError:
> +return False
> +if int(output) > 0:
> +return True
> +else:
> +return False
Can be slightly simplified to:
try:
output = runfetchcmd(cmd, d, quiet=True, workdir=wd)
if int(output) > 0:
return True
except
bb.fetch2.FetchError:
pass
return False
I did wonder if we could/should also catch an exception if the output
can't be turned into an int for some reason with:
except bb.fetch2.FetchError, ValueError:
Cheers,
Richard
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/2] core-image-rt-sdk: make sure that we append to DEPENDS
This also fix postinst intercept hook 'update_gio_module_cache' failed warnings
that are now flagged as errors after the recent chagnes at
lib/oe/package_manager.py
Signed-off-by: Naveen Saini
---
meta/recipes-rt/images/core-image-rt-sdk.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-rt/images/core-image-rt-sdk.bb
b/meta/recipes-rt/images/core-image-rt-sdk.bb
index 0f7f091687..624b7d9430 100644
--- a/meta/recipes-rt/images/core-image-rt-sdk.bb
+++ b/meta/recipes-rt/images/core-image-rt-sdk.bb
@@ -11,7 +11,7 @@ python () {
DESCRIPTION = "Small image capable of booting a device with a test suite and \
tools for real-time use. It includes the full meta-toolchain, development \
headers and libraries to form a standalone SDK."
-DEPENDS = "linux-yocto-rt"
+DEPENDS += "linux-yocto-rt"
IMAGE_FEATURES += "dev-pkgs tools-sdk tools-debug eclipse-debug tools-profile
tools-testapps debug-tweaks"
--
2.17.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/2] core-image-rt: make sure that we append to DEPENDS
This also fix postinst intercept hook 'update_gio_module_cache' failed warnings
that are now flagged as errors after the recent chagnes at
lib/oe/package_manager.py
Signed-off-by: Naveen Saini
---
meta/recipes-rt/images/core-image-rt.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-rt/images/core-image-rt.bb
b/meta/recipes-rt/images/core-image-rt.bb
index 9cb93b3de5..053d23219d 100644
--- a/meta/recipes-rt/images/core-image-rt.bb
+++ b/meta/recipes-rt/images/core-image-rt.bb
@@ -10,7 +10,7 @@ python () {
DESCRIPTION = "A small image just capable of allowing a device to boot plus a \
real-time test suite and tools appropriate for real-time use."
-DEPENDS = "linux-yocto-rt"
+DEPENDS += "linux-yocto-rt"
IMAGE_INSTALL += "rt-tests hwlatdetect"
--
2.17.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] oeqa/core/runner: dump stdout and stderr of each test case
Some CI pipelines might perform further processing of the test output
(for instance, to plot some metrics into a chart). However, Since `thud`
we switched away from the XML-based jUnit reporting, and at the same
time we lost the ability of collecting the stdout and stderr of the
various tests.
We now restore this functionality by adding `stdout` and `stderr` keys
to the JSON reports. This behavior is off by default; in order to enable
it, one must set the `TESTREPORT_FULLLOGS` variable in the bitbake
configuration.
Signed-off-by: Alberto Mardegan
---
meta/classes/testimage.bbclass | 3 ++-
meta/lib/oeqa/core/runner.py | 20
2 files changed, 18 insertions(+), 5 deletions(-)
diff --git a/meta/classes/testimage.bbclass b/meta/classes/testimage.bbclass
index ff1c53b93e..9bb5a5cb0b 100644
--- a/meta/classes/testimage.bbclass
+++ b/meta/classes/testimage.bbclass
@@ -316,7 +316,8 @@ def testimage_main(d):
configuration = get_testimage_configuration(d, 'runtime', machine)
results.logDetails(get_testimage_json_result_dir(d),
configuration,
- get_testimage_result_id(configuration))
+ get_testimage_result_id(configuration),
+ dump_streams=d.getVar('TESTREPORT_FULLLOGS'))
results.logSummary(pn)
if not results.wasSuccessful():
bb.fatal('%s - FAILED - check the task log and the ssh log' % pn,
forcelog=True)
diff --git a/meta/lib/oeqa/core/runner.py b/meta/lib/oeqa/core/runner.py
index df88b85f1c..478b7b6683 100644
--- a/meta/lib/oeqa/core/runner.py
+++ b/meta/lib/oeqa/core/runner.py
@@ -7,6 +7,7 @@ import unittest
import logging
import re
import json
+import sys
from unittest import TextTestResult as _TestResult
from unittest import TextTestRunner as _TestRunner
@@ -45,6 +46,9 @@ class OETestResult(_TestResult):
self.tc = tc
+# stdout and stderr for each test case
+self.logged_output = {}
+
def startTest(self, test):
# May have been set by concurrencytest
if test.id() not in self.starttime:
@@ -53,6 +57,9 @@ class OETestResult(_TestResult):
def stopTest(self, test):
self.endtime[test.id()] = time.time()
+if self.buffer:
+self.logged_output[test.id()] = (
+sys.stdout.getvalue(), sys.stderr.getvalue())
super(OETestResult, self).stopTest(test)
if test.id() in self.progressinfo:
self.tc.logger.info(self.progressinfo[test.id()])
@@ -118,7 +125,8 @@ class OETestResult(_TestResult):
self.successes.append((test, None))
super(OETestResult, self).addSuccess(test)
-def logDetails(self, json_file_dir=None, configuration=None,
result_id=None):
+def logDetails(self, json_file_dir=None, configuration=None,
result_id=None,
+dump_streams=False):
self.tc.logger.info("RESULTS:")
result = {}
@@ -144,10 +152,14 @@ class OETestResult(_TestResult):
if status not in logs:
logs[status] = []
logs[status].append("RESULTS - %s - Testcase %s: %s%s" %
(case.id(), oeid, status, t))
+report = {'status': status}
if log:
-result[case.id()] = {'status': status, 'log': log}
-else:
-result[case.id()] = {'status': status}
+report['log'] = log
+if dump_streams and case.id() in self.logged_output:
+(stdout, stderr) = self.logged_output[case.id()]
+report['stdout'] = stdout
+report['stderr'] = stderr
+result[case.id()] = report
for i in ['PASSED', 'SKIPPED', 'EXPECTEDFAIL', 'ERROR', 'FAILED',
'UNKNOWN']:
if i not in logs:
--
2.17.1
This e-mail and any attachment(s) are intended only for the recipient(s) named
above and others who have been specifically authorized to receive them. They
may contain confidential information. If you are not the intended recipient,
please do not read this email or its attachment(s). Furthermore, you are hereby
notified that any dissemination, distribution or copying of this e-mail and any
attachment(s) is strictly prohibited. If you have received this e-mail in
error, please immediately notify the sender by replying to this e-mail and then
delete this e-mail and any attachment(s) or copies thereof from your system.
Thank you.
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] webkitgtk: set CVE_PRODUCT
Signed-off-by: Chen Qi --- meta/recipes-sato/webkit/webkitgtk_2.24.0.bb | 2 ++ 1 file changed, 2 insertions(+) diff --git a/meta/recipes-sato/webkit/webkitgtk_2.24.0.bb b/meta/recipes-sato/webkit/webkitgtk_2.24.0.bb index 4a82dae..58c06dc 100644 --- a/meta/recipes-sato/webkit/webkitgtk_2.24.0.bb +++ b/meta/recipes-sato/webkit/webkitgtk_2.24.0.bb @@ -29,6 +29,8 @@ inherit cmake pkgconfig gobject-introspection perlnative distro_features_check u REQUIRED_DISTRO_FEATURES = "x11 opengl" +CVE_PRODUCT = "webkitgtk webkitgtk\+" + DEPENDS = "zlib libsoup-2.4 curl libxml2 cairo libxslt libxt libidn libgcrypt \ gtk+3 gstreamer1.0 gstreamer1.0-plugins-base flex-native gperf-native sqlite3 \ pango icu bison-native gawk intltool-native libwebp \ -- 1.9.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/1] webkitgtk: set CVE_PRODUCT
*** BLURB HERE *** The following changes since commit 7f7a7cba4dcd99d7b36a0d747bfd1bba3f9c2288: bitbake: bb: siggen: Print more info when basehash are mis-matched (2019-04-23 23:30:45 +0100) are available in the git repository at: git://git.pokylinux.org/poky-contrib ChenQi/webkitgtk-cve http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=ChenQi/webkitgtk-cve Chen Qi (1): webkitgtk: set CVE_PRODUCT meta/recipes-sato/webkit/webkitgtk_2.24.0.bb | 2 ++ 1 file changed, 2 insertions(+) -- 1.9.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
