Re: [OE-core] [RFC PATCH 3/4] gtk+: remove GTK+ 2
This resulted in a oe-selftest failure for
recipetool.RecipetoolTests.test_recipetool_create_cmake:
https://autobuilder.yoctoproject.org/typhoon/#/builders/87/builds/280/steps/7/logs/step2d
Thanks,
Anuj
On Fri, 2019-07-05 at 17:20 +0100, Ross Burton wrote:
> GTK+ 2 is ancient, and shouldn't be used. It will be moved to meta-
> oe for
> people who do need it, but it shouldn't in oe-core.
>
> [ YOCTO #12673 ]
>
> Signed-off-by: Ross Burton
> ---
> meta/recipes-gnome/gtk+/gtk+.inc | 107 -
>
> ...ok-into-HOME-when-looking-for-gtk-modules.patch | 29 --
> meta/recipes-gnome/gtk+/gtk+/doc-fixes.patch | 22 -
> .../gtk+/gtk+/hardcoded_libtool.patch | 36 ---
> .../gtk+/gtk+/strict-prototypes.patch | 24 -
> meta/recipes-gnome/gtk+/gtk+/toggle-font.diff | 102 -
> ---
> meta/recipes-gnome/gtk+/gtk+/xsettings.patch | 20
> meta/recipes-gnome/gtk+/gtk+_2.24.32.bb| 35 ---
> 8 files changed, 375 deletions(-)
> delete mode 100644 meta/recipes-gnome/gtk+/gtk+.inc
> delete mode 100644 meta/recipes-gnome/gtk+/gtk+/0001-Do-not-look-
> into-HOME-when-looking-for-gtk-modules.patch
> delete mode 100644 meta/recipes-gnome/gtk+/gtk+/doc-fixes.patch
> delete mode 100644 meta/recipes-
> gnome/gtk+/gtk+/hardcoded_libtool.patch
> delete mode 100644 meta/recipes-gnome/gtk+/gtk+/strict-
> prototypes.patch
> delete mode 100644 meta/recipes-gnome/gtk+/gtk+/toggle-font.diff
> delete mode 100644 meta/recipes-gnome/gtk+/gtk+/xsettings.patch
> delete mode 100644 meta/recipes-gnome/gtk+/gtk+_2.24.32.bb
>
> diff --git a/meta/recipes-gnome/gtk+/gtk+.inc b/meta/recipes-
> gnome/gtk+/gtk+.inc
> deleted file mode 100644
> index d6d14a79d5a..000
> --- a/meta/recipes-gnome/gtk+/gtk+.inc
> +++ /dev/null
> @@ -1,107 +0,0 @@
> -SUMMARY = "Multi-platform toolkit for creating GUIs"
> -DESCRIPTION = "GTK+ is a multi-platform toolkit for creating
> graphical user interfaces. Offering a complete \
> -set of widgets, GTK+ is suitable for projects ranging from small
> one-off projects to complete application suites."
> -HOMEPAGE = "http://www.gtk.org;
> -BUGTRACKER = "https://bugzilla.gnome.org/;
> -
> -LICENSE = "LGPLv2 & LGPLv2+ & LGPLv2.1+"
> -
> -LIC_FILES_CHKSUM =
> "file://COPYING;md5=3bf50002aefd002f49e7bb854063f7e7"
> -
> -SECTION = "libs"
> -
> -inherit distro_features_check
> -ANY_OF_DISTRO_FEATURES = "${GTK2DISTROFEATURES}"
> -
> -# This picks stable releases in the 2.x series (but not 2.90
> onwards,
> -# which were GNOME 3 betas).
> -UPSTREAM_CHECK_REGEX = "(?P2\.([0-8]*[02468])+(\.\d+)+)"
> -
> -X11DEPENDS = "virtual/libx11 libxext libxcursor libxrandr libxdamage
> libxrender libxcomposite"
> -DEPENDS = "glib-2.0 pango atk jpeg libpng gdk-pixbuf-native \
> - cairo gdk-pixbuf"
> -
> -PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'directfb
> x11', d)}"
> -
> -PACKAGECONFIG[x11] = "--with-x=yes --with-gdktarget=x11,--with-
> x=no,${X11DEPENDS}"
> -# without --with-gdktarget=directfb it will check for cairo-xlib
> which isn't available without X11 DISTRO_FEATURE
> -PACKAGECONFIG[directfb] = "--with-gdktarget=directfb,,directfb"
> -PACKAGECONFIG[manpages] = "--enable-man --with-xml-
> catalog=${STAGING_ETCDIR_NATIVE}/xml/catalog, --disable-man, libxslt-
> native xmlto-native"
> -
> -inherit autotools gtk-doc pkgconfig update-alternatives gtk-
> immodules-cache gobject-introspection manpages
> -
> -PACKAGES += "libgail gtk-demo"
> -
> -FILES_${PN} += "${bindir}/gtk-update-icon-cache-2.0 \
> - ${bindir}/gtk-query-immodules-2.0 \
> - ${datadir}/themes ${sysconfdir} \
> - ${libdir}/gtk-2.0/${LIBV}/engines/libpixmap.so"
> -
> -FILES_${PN}-dev += " \
> -${datadir}/gtk-2.0/include \
> - ${libdir}/gtk-2.0/include \
> - ${libdir}/gtk-2.0/modules/*.la \
> - ${libdir}/gtk-2.0/${LIBV}/loaders/*.la \
> - ${libdir}/gtk-2.0/${LIBV}/immodules/*.la \
> - ${libdir}/gtk-2.0/${LIBV}/printbackends/*.la \
> - ${libdir}/gtk-2.0/${LIBV}/engines/*.la \
> - ${bindir}/gtk-builder-convert"
> -
> -FILES_gtk-demo = " \
> - ${datadir}/gtk-2.0/demo/* \
> - ${bindir}/gtk-demo \
> - "
> -
> -FILES_libgail = " \
> - ${libdir}/gtk-2.0/modules/libgail.so \
> - ${libdir}/gtk-2.0/modules/libferret.so \
> - "
> -
> -GTKBASE_RRECOMMENDS ?= "liberation-fonts \
> -gdk-pixbuf-loader-png \
> -gdk-pixbuf-loader-jpeg \
> -gdk-pixbuf-loader-gif \
> -gdk-pixbuf-loader-xpm \
> -shared-mime-info \
> -gnome-theme-adwaita \
> -"
> -GTKGLIBC_RRECOMMENDS ?= "${GTKBASE_RRECOMMENDS} glibc-gconv-iso8859-
> 1"
> -
> -RRECOMMENDS_${PN} = "${GTKBASE_RRECOMMENDS}"
> -RRECOMMENDS_${PN}_libc-glibc = "${GTKGLIBC_RRECOMMENDS}"
> -
> -ALTERNATIVE_${PN} = "gtk-update-icon-cache"
>
Re: [OE-core] [PATCH] autoconf-archive: update to 2019.01.06
On Tue, Jul 2, 2019 at 10:54 AM Oleksandr Kravchuk
wrote:
>
> Hi Robert,
>
> Unfortunately I do not have an answer. I failed an issue:
> https://github.com/rsyslog/rsyslog/issues/3738
>
> Let's see what the project suggests.
>
can we have autoconf logs before and after this upgrade ?
its detecting something differently.
> On 02/07/2019 12:34, Robert Yang wrote:
> > Hi Oleksandr,
> >
> > This patch makes
> > meta-openembedded/meta-oe/recipes-extended/rsyslog/librelp_1.4.0.bb
> > and
> > meta-secure-core/meta-tpm2/recipes-tpm/tpm2-tss/tpm2-tss_git.bb
> >
> > fail to build. E.g.:
> >
> > MACHINE = "qemux86"
> > $ bitbake librelp
> >
> > ../../git/src/cmdif.h:52:13: error: no previous declaration for
> > 'relpSCSyslog' [-Werror=missing-declarations]
> >52 | relpRetVal relp##type##C##cmd(relpFrame_t LIBRELP_ATTR_UNUSED
> > *pFrame, relpSess_t *pSess) \
> > | ^~~~
> > ../../git/src/scsyslog.c:45:1: note: in expansion of macro 'BEGINcommand'
> >
> >
> > $ bitbake rsyslog
> > Makefile:14636: *** missing separator. Stop.
> >
> > The errors are wild, do you have any ideas on how to fix them, please?
> >
> > // Robert
> >
> > On 6/27/19 11:44 PM, Oleksandr Kravchuk wrote:
> >> Signed-off-by: Oleksandr Kravchuk
> >> ---
> >> ...f-archive_2018.03.13.bb => autoconf-archive_2019.01.06.bb} | 4 ++--
> >> 1 file changed, 2 insertions(+), 2 deletions(-)
> >> rename
> >> meta/recipes-devtools/autoconf-archive/{autoconf-archive_2018.03.13.bb
> >> => autoconf-archive_2019.01.06.bb} (78%)
> >>
> >> diff --git
> >> a/meta/recipes-devtools/autoconf-archive/autoconf-archive_2018.03.13.bb
> >> b/meta/recipes-devtools/autoconf-archive/autoconf-archive_2019.01.06.bb
> >> similarity index 78%
> >> rename from
> >> meta/recipes-devtools/autoconf-archive/autoconf-archive_2018.03.13.bb
> >> rename to
> >> meta/recipes-devtools/autoconf-archive/autoconf-archive_2019.01.06.bb
> >> index 7d62e52ab8..985a254fcc 100644
> >> ---
> >> a/meta/recipes-devtools/autoconf-archive/autoconf-archive_2018.03.13.bb
> >> +++
> >> b/meta/recipes-devtools/autoconf-archive/autoconf-archive_2019.01.06.bb
> >> @@ -6,8 +6,8 @@ LIC_FILES_CHKSUM =
> >> "file://COPYING;md5=11cc2d3ee574f9d6b7ee797bdce4d423 \
> >> file://COPYING.EXCEPTION;md5=fdef168ebff3bc2f13664c365a5fb515"
> >> SRC_URI = "${GNU_MIRROR}/${BPN}/${BPN}-${PV}.tar.xz"
> >> -SRC_URI[md5sum] = "46b13a5936372297b6d49980327a3c35"
> >> -SRC_URI[sha256sum] =
> >> "6175f90d9fa64c4d939bdbb3e8511ae0ee2134863a2c7bf8d9733819efa6e159"
> >> +SRC_URI[md5sum] = "d46413c8b00a125b1529bae385bbec55"
> >> +SRC_URI[sha256sum] =
> >> "17195c833098da79de5778ee90948f4c5d90ed1a0cf8391b4ab348e2ec511e3f"
> >> inherit autotools allarch
> >>
> --
> ___
> 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
[OE-core] ✗ patchtest: failure for "binutils: fix CVE-2019-12972 C..." and 2 more
== Series Details == Series: "binutils: fix CVE-2019-12972 C..." and 2 more Revision: 1 URL : https://patchwork.openembedded.org/series/18592/ State : failure == Summary == Thank you for submitting this patch series to OpenEmbedded Core. This is an automated response. Several tests have been executed on the proposed series by patchtest resulting in the following failures: * Patch[2/3] gnupg: upgrade 2.2.16 -> 2.2.17 Issue Missing or incorrectly formatted CVE tag in included patch file [test_cve_tag_format] Suggested fixCorrect or include the CVE tag on cve patch with format: "CVE: CVE--" If you believe any of these test results are incorrect, please reply to the mailing list (openembedded-core@lists.openembedded.org) raising your concerns. Otherwise we would appreciate you correcting the issues and submitting a new version of the patchset if applicable. Please ensure you add/increment the version number when sending the new version (i.e. [PATCH] -> [PATCH v2] -> [PATCH v3] -> ...). --- Guidelines: https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/2] xmlcatalog: hold libxml2-native dependency
Put libxml2-native dependency in this class and remove
it from recipes inheriting this class.
In fact, if a recipe inherits this class and does not have
libxml2-native, the xmlcatalog_sstate_postinst would fail.
Signed-off-by: Chen Qi
---
meta/classes/xmlcatalog.bbclass | 2 ++
meta/recipes-devtools/docbook-xml/docbook-xml-dtd4_4.5.bb | 2 --
meta/recipes-devtools/docbook-xml/docbook-xsl-stylesheets_1.79.1.bb | 2 --
3 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/meta/classes/xmlcatalog.bbclass b/meta/classes/xmlcatalog.bbclass
index 075aef8..ae4811f 100644
--- a/meta/classes/xmlcatalog.bbclass
+++ b/meta/classes/xmlcatalog.bbclass
@@ -1,3 +1,5 @@
+DEPENDS = "libxml2-native"
+
# A whitespace-separated list of XML catalogs to be registered, for example
# "${sysconfdir}/xml/docbook-xml.xml".
XMLCATALOGS ?= ""
diff --git a/meta/recipes-devtools/docbook-xml/docbook-xml-dtd4_4.5.bb
b/meta/recipes-devtools/docbook-xml/docbook-xml-dtd4_4.5.bb
index 4b6a28e..6452c8d 100644
--- a/meta/recipes-devtools/docbook-xml/docbook-xml-dtd4_4.5.bb
+++ b/meta/recipes-devtools/docbook-xml/docbook-xml-dtd4_4.5.bb
@@ -8,8 +8,6 @@ HOMEPAGE = "http://www.docbook.org/xml/;
LICENSE = "OASIS"
LIC_FILES_CHKSUM =
"file://${WORKDIR}/LICENSE-OASIS;md5=c608985dd5f7f215e669e7639a0b1d2e"
-DEPENDS = "libxml2-native"
-
# Note: the upstream sources are not distributed with a license file.
# LICENSE-OASIS is included as a "patch" to workaround this. When
# upgrading this recipe, please verify whether this is still needed.
diff --git
a/meta/recipes-devtools/docbook-xml/docbook-xsl-stylesheets_1.79.1.bb
b/meta/recipes-devtools/docbook-xml/docbook-xsl-stylesheets_1.79.1.bb
index ff38e87..c5d3a24 100644
--- a/meta/recipes-devtools/docbook-xml/docbook-xsl-stylesheets_1.79.1.bb
+++ b/meta/recipes-devtools/docbook-xml/docbook-xsl-stylesheets_1.79.1.bb
@@ -14,8 +14,6 @@ UPSTREAM_CHECK_URI =
"http://sourceforge.net/projects/docbook/files/docbook-xsl/
# Reject versions ending in .0 as those are release candidates
UPSTREAM_CHECK_REGEX = "/docbook-xsl/(?P(\d+[\.\-_]*)+(?!\.0)\.\d+)/"
-DEPENDS = "libxml2-native"
-
S = "${WORKDIR}/docbook-xsl-${PV}"
inherit allarch xmlcatalog
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH V2 0/2] buildtools-tarball: add nativesdk-libxml2-utils
Changes in V2: * Let xmlcatalog.bbclass hold 'libxml2-native' dependency. The following changes since commit 2a6094ca8c4aa5c00636df77669e5bca6ad52bcf: oeqa/bbtests: Tweak test bitbake output pattern matching (2019-07-09 23:30:44 +0100) are available in the git repository at: git://git.pokylinux.org/poky-contrib ChenQi/buildtools-xmlcatalog http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=ChenQi/buildtools-xmlcatalog Chen Qi (2): buildtools-tarball: add nativesdk-libxml2-utils xmlcatalog: hold libxml2-native dependency meta/classes/xmlcatalog.bbclass | 2 ++ meta/conf/bitbake.conf | 3 +++ meta/recipes-core/meta/buildtools-tarball.bb| 1 + meta/recipes-devtools/docbook-xml/docbook-xml-dtd4_4.5.bb | 2 -- meta/recipes-devtools/docbook-xml/docbook-xsl-stylesheets_1.79.1.bb | 2 -- 5 files changed, 6 insertions(+), 4 deletions(-) -- 1.9.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/2] buildtools-tarball: add nativesdk-libxml2-utils
For build-sysroots.bb, the xmlcatalog would not be in its
staging directory. Causing the following error for eSDK.
ERROR: build-sysroots-1.0-r0 do_build_native_sysroot: Command
'/PATH/TO/IMAGE/testsdkext/tmp/sysroots/x86_64/usr/bin/postinst-docbook-xml-dtd4-native-xmlcatalog'
returned non-zero exit status 127.
ERROR: build-sysroots-1.0-r0 do_build_native_sysroot: Function failed:
do_build_native_sysroot
The problem could be reproduced by the following steps.
1. Add in local.conf:
IMAGE_INSTALL_append = " btrfs-tools"
DISTRO_FEATURES_append = " api-documentation"
INHERIT += "testsdk"
2. bitbake core-image-minimal -c populate_sdk_ext
3. bitbake core-image-minimal -c testsdkext
So we add nativesdk-libxml2-utils to buildtools-tarball
to ensure the existence of xmlcatalog. Also add it
to HOSTTOOLS_NONFATAL so it could be seen by bitbake.
Signed-off-by: Chen Qi
---
meta/conf/bitbake.conf | 3 +++
meta/recipes-core/meta/buildtools-tarball.bb | 1 +
2 files changed, 4 insertions(+)
diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 5e93f5c..2f64eae 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -517,6 +517,9 @@ HOSTTOOLS_NONFATAL += "scp"
# Link to git-lfs if present
HOSTTOOLS_NONFATAL += "git-lfs"
+# build-sysroot needs xmlcatalog in order for eSDK installation
+HOSTTOOLS_NONFATAL += "xmlcatalog"
+
CCACHE ??= ""
TOOLCHAIN_OPTIONS = " --sysroot=${STAGING_DIR_TARGET}"
diff --git a/meta/recipes-core/meta/buildtools-tarball.bb
b/meta/recipes-core/meta/buildtools-tarball.bb
index 91df6f1..d39d6f7 100644
--- a/meta/recipes-core/meta/buildtools-tarball.bb
+++ b/meta/recipes-core/meta/buildtools-tarball.bb
@@ -25,6 +25,7 @@ TOOLCHAIN_HOST_TASK ?= "\
nativesdk-texinfo \
nativesdk-libnss-nis \
nativesdk-rpcsvc-proto \
+nativesdk-libxml2-utils \
"
MULTIMACH_TARGET_SYS = "${SDK_ARCH}-nativesdk${SDK_VENDOR}-${SDK_OS}"
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] buildtools-tarball: add nativesdk-libxml2-utils
On 07/09/2019 06:18 PM, Richard Purdie wrote:
On Tue, 2019-07-09 at 17:36 +0800, ChenQi wrote:
On 07/09/2019 09:38 AM, ChenQi wrote:
On 07/09/2019 12:47 AM, Richard Purdie wrote:
On Mon, 2019-07-08 at 15:37 +0800, Chen Qi wrote:
For build-sysroots.bb, the xmlcatalog would not be in its
staging directory. Causing the following error for eSDK.
ERROR: build-sysroots-1.0-r0 do_build_native_sysroot: Command
'/PATH/TO/IMAGE/testsdkext/tmp/sysroots/x86_64/usr/bin/postinst
-
docbook-xml-dtd4-native-xmlcatalog' returned non-zero exit
status
127.
ERROR: build-sysroots-1.0-r0 do_build_native_sysroot: Function
failed: do_build_native_sysroot
The problem could be reproduced by the following steps.
1. Add in local.conf:
IMAGE_INSTALL_append = " btrfs-tools"
DISTRO_FEATURES_append = " api-documentation"
INHERIT += "testsdk"
2. bitbake core-image-minimal -c populate_sdk_ext
3. bitbake core-image-minimal -c testsdkext
So we add nativesdk-libxml2-utils to buildtools-tarball
to ensure the existence of xmlcatalog. Also add it
to HOSTTOOLS_NONFATAL so it could be seen by bitbake.
Signed-off-by: Chen Qi
---
meta/conf/bitbake.conf | 3 +++
meta/recipes-core/meta/buildtools-tarball.bb | 1 +
2 files changed, 4 insertions(+)
diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 5e93f5c..2f64eae 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -517,6 +517,9 @@ HOSTTOOLS_NONFATAL += "scp"
# Link to git-lfs if present
HOSTTOOLS_NONFATAL += "git-lfs"
+# build-sysroot needs xmlcatalog in order for eSDK
installation
+HOSTTOOLS_NONFATAL += "xmlcatalog"
I don't mind the buildtools-tarball change but HOSTTOOLS is
starting to
grow to contain far too much random stuff which could impact
reproduciblity.
Is there some other way we could fix this? It still feels like a
dependency problem which we chould fix by adding a missing
dependency
although I appreciate its far from being that simple.
I wonder if there is a way we could teach build-sysroots to be
cleverer
about dependencies?
I'll try to implement it and send out a new patch.
Unfortunately I cannot figure out a good way to implement this.
Could you please help giving me some hints?
What happens if we add:
${@bb.utils.contains('DISTRO_FEATURES', 'api-documentation',
'nativesdk-libxml2', '', d)} \
to
`
meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb
?
This does not work. Using nativesdk-libxml2-utils does not work too.
Both buildtools and eSDK do not use this packagegroup.
I've sent out a V2 of this patch, with change to put the
'libxml2-native' dependency in xmlcatalog.bbclass.
In this way, we can ensure that the xmlcatalog is from our recipe. In
normal build, it's from libxml2-native; in build-sysroots in eSDK, it's
from nativesdk-libxml2-utils. Do you think this is acceptable?
Best Regards,
Chen Qi
Cheers,
Richard
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/3] gnupg: upgrade 2.2.16 -> 2.2.17
Also fixes CVE-2019-13050. Announcement:
https://lists.gnupg.org/pipermail/gnupg-announce/2019q3/000439.html
Signed-off-by: Anuj Mittal
---
.../gnupg/{gnupg_2.2.16.bb => gnupg_2.2.17.bb} | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
rename meta/recipes-support/gnupg/{gnupg_2.2.16.bb => gnupg_2.2.17.bb} (92%)
diff --git a/meta/recipes-support/gnupg/gnupg_2.2.16.bb
b/meta/recipes-support/gnupg/gnupg_2.2.17.bb
similarity index 92%
rename from meta/recipes-support/gnupg/gnupg_2.2.16.bb
rename to meta/recipes-support/gnupg/gnupg_2.2.17.bb
index cb7c6c5c62..e5456dd9b9 100644
--- a/meta/recipes-support/gnupg/gnupg_2.2.16.bb
+++ b/meta/recipes-support/gnupg/gnupg_2.2.17.bb
@@ -19,9 +19,8 @@ SRC_URI = "${GNUPG_MIRROR}/${BPN}/${BPN}-${PV}.tar.bz2 \
SRC_URI_append_class-native = "
file://0001-configure.ac-use-a-custom-value-for-the-location-of-.patch \
file://relocate.patch"
-
-SRC_URI[md5sum] = "d90e186df1c06845880ea58a318f070b"
-SRC_URI[sha256sum] =
"6cbe8d454bf5dc204621eed3016d721b66298fa95363395bb8eeceb1d2fd14cb"
+SRC_URI[md5sum] = "1ba2d9b70c377f8e967742064c27a19c"
+SRC_URI[sha256sum] =
"afa262868e39b651a2db4c071fba90415154243e83a830ca00516f9a807fd514"
EXTRA_OECONF = "--disable-ldap \
--disable-ccid-driver \
--
2.20.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 3/3] libxslt: fix CVE-2019-13117 CVE-2019-13118
Signed-off-by: Anuj Mittal
---
.../libxslt/files/CVE-2019-13117.patch| 33
.../libxslt/files/CVE-2019-13118.patch| 76 +++
.../recipes-support/libxslt/libxslt_1.1.33.bb | 2 +
3 files changed, 111 insertions(+)
create mode 100644 meta/recipes-support/libxslt/files/CVE-2019-13117.patch
create mode 100644 meta/recipes-support/libxslt/files/CVE-2019-13118.patch
diff --git a/meta/recipes-support/libxslt/files/CVE-2019-13117.patch
b/meta/recipes-support/libxslt/files/CVE-2019-13117.patch
new file mode 100644
index 00..ef3f2709f7
--- /dev/null
+++ b/meta/recipes-support/libxslt/files/CVE-2019-13117.patch
@@ -0,0 +1,33 @@
+From c5eb6cf3aba0af048596106ed839b4ae17ecbcb1 Mon Sep 17 00:00:00 2001
+From: Nick Wellnhofer
+Date: Sat, 27 Apr 2019 11:19:48 +0200
+Subject: [PATCH] Fix uninitialized read of xsl:number token
+
+Found by OSS-Fuzz.
+
+CVE: CVE-2019-13117
+Upstream-Status: Backport
[https://gitlab.gnome.org/GNOME/libxslt/commit/c5eb6cf3aba0af048596106ed839b4ae17ecbcb1]
+Signed-off-by: Anuj Mittal
+---
+ libxslt/numbers.c | 5 -
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+diff --git a/libxslt/numbers.c b/libxslt/numbers.c
+index 89e1f668..75c31eba 100644
+--- a/libxslt/numbers.c
b/libxslt/numbers.c
+@@ -382,7 +382,10 @@ xsltNumberFormatTokenize(const xmlChar *format,
+ tokens->tokens[tokens->nTokens].token = val - 1;
+ ix += len;
+ val = xmlStringCurrentChar(NULL, format+ix, );
+- }
++ } else {
++tokens->tokens[tokens->nTokens].token = (xmlChar)'0';
++tokens->tokens[tokens->nTokens].width = 1;
++}
+ } else if ( (val == (xmlChar)'A') ||
+ (val == (xmlChar)'a') ||
+ (val == (xmlChar)'I') ||
+--
+2.21.0
+
diff --git a/meta/recipes-support/libxslt/files/CVE-2019-13118.patch
b/meta/recipes-support/libxslt/files/CVE-2019-13118.patch
new file mode 100644
index 00..595e6c2f33
--- /dev/null
+++ b/meta/recipes-support/libxslt/files/CVE-2019-13118.patch
@@ -0,0 +1,76 @@
+From 6ce8de69330783977dd14f6569419489875fb71b Mon Sep 17 00:00:00 2001
+From: Nick Wellnhofer
+Date: Mon, 3 Jun 2019 13:14:45 +0200
+Subject: [PATCH] Fix uninitialized read with UTF-8 grouping chars
+
+The character type in xsltFormatNumberConversion was too narrow and
+an invalid character/length combination could be passed to
+xsltNumberFormatDecimal, resulting in an uninitialized read.
+
+Found by OSS-Fuzz.
+
+CVE: CVE-2019-13118
+Upstream-Status: Backport
[https://gitlab.gnome.org/GNOME/libxslt/commit/6ce8de69330783977dd14f6569419489875fb71b]
+Signed-off-by: Anuj Mittal
+
+---
+ libxslt/numbers.c | 5 +++--
+ tests/docs/bug-222.xml| 1 +
+ tests/general/bug-222.out | 2 ++
+ tests/general/bug-222.xsl | 6 ++
+ 4 files changed, 12 insertions(+), 2 deletions(-)
+ create mode 100644 tests/docs/bug-222.xml
+ create mode 100644 tests/general/bug-222.out
+ create mode 100644 tests/general/bug-222.xsl
+
+diff --git a/libxslt/numbers.c b/libxslt/numbers.c
+index f1ed8846..20b99d5a 100644
+--- a/libxslt/numbers.c
b/libxslt/numbers.c
+@@ -1298,13 +1298,14 @@ OUTPUT_NUMBER:
+ number = floor((scale * number + 0.5)) / scale;
+ if ((self->grouping != NULL) &&
+ (self->grouping[0] != 0)) {
++int gchar;
+
+ len = xmlStrlen(self->grouping);
+- pchar = xsltGetUTF8Char(self->grouping, );
++ gchar = xsltGetUTF8Char(self->grouping, );
+ xsltNumberFormatDecimal(buffer, floor(number), self->zeroDigit[0],
+ format_info.integer_digits,
+ format_info.group,
+- pchar, len);
++ gchar, len);
+ } else
+ xsltNumberFormatDecimal(buffer, floor(number), self->zeroDigit[0],
+ format_info.integer_digits,
+diff --git a/tests/docs/bug-222.xml b/tests/docs/bug-222.xml
+new file mode 100644
+index ..69d62f2c
+--- /dev/null
b/tests/docs/bug-222.xml
+@@ -0,0 +1 @@
++
+diff --git a/tests/general/bug-222.out b/tests/general/bug-222.out
+new file mode 100644
+index ..e3139698
+--- /dev/null
b/tests/general/bug-222.out
+@@ -0,0 +1,2 @@
++
++1⠢0
+diff --git a/tests/general/bug-222.xsl b/tests/general/bug-222.xsl
+new file mode 100644
+index ..e32dc473
+--- /dev/null
b/tests/general/bug-222.xsl
+@@ -0,0 +1,6 @@
++http://www.w3.org/1999/XSL/Transform;
version="1.0">
++
++
++
++
++
+--
+2.21.0
+
diff --git a/meta/recipes-support/libxslt/libxslt_1.1.33.bb
b/meta/recipes-support/libxslt/libxslt_1.1.33.bb
index 6320a821dc..abc00a09ea 100644
--- a/meta/recipes-support/libxslt/libxslt_1.1.33.bb
+++ b/meta/recipes-support/libxslt/libxslt_1.1.33.bb
@@ -10,6 +10,8 @@ DEPENDS = "libxml2"
SRC_URI = "http://xmlsoft.org/sources/libxslt-${PV}.tar.gz \
file://0001-Fix-security-framework-bypass.patch \
[OE-core] [PATCH 1/3] binutils: fix CVE-2019-12972 CVE-2019-9071
Signed-off-by: Anuj Mittal
---
.../binutils/binutils-2.32.inc| 2 +
.../binutils/binutils/CVE-2019-12972.patch| 51 ++
.../binutils/binutils/CVE-2019-9071.patch | 164 ++
3 files changed, 217 insertions(+)
create mode 100644 meta/recipes-devtools/binutils/binutils/CVE-2019-12972.patch
create mode 100644 meta/recipes-devtools/binutils/binutils/CVE-2019-9071.patch
diff --git a/meta/recipes-devtools/binutils/binutils-2.32.inc
b/meta/recipes-devtools/binutils/binutils-2.32.inc
index 49e6827c1f..31c24a37f5 100644
--- a/meta/recipes-devtools/binutils/binutils-2.32.inc
+++ b/meta/recipes-devtools/binutils/binutils-2.32.inc
@@ -48,6 +48,8 @@ SRC_URI = "\
file://CVE-2019-9075.patch \
file://CVE-2019-9076.patch \
file://CVE-2019-9077.patch \
+ file://CVE-2019-9071.patch \
+ file://CVE-2019-12972.patch \
"
S = "${WORKDIR}/git"
diff --git a/meta/recipes-devtools/binutils/binutils/CVE-2019-12972.patch
b/meta/recipes-devtools/binutils/binutils/CVE-2019-12972.patch
new file mode 100644
index 00..07d1d65467
--- /dev/null
+++ b/meta/recipes-devtools/binutils/binutils/CVE-2019-12972.patch
@@ -0,0 +1,51 @@
+From 30bcc01478433a1cb05b36dc5c4beef7d2c89b5b Mon Sep 17 00:00:00 2001
+From: Alan Modra
+Date: Fri, 21 Jun 2019 11:51:38 +0930
+Subject: [PATCH] PR24689, string table corruption
+
+The testcase in the PR had a e_shstrndx section of type SHT_GROUP.
+hdr->contents were initialized by setup_group rather than being read
+from the file, thus last byte was not zero and string dereference ran
+off the end of the buffer.
+
+ PR 24689
+ * elfcode.h (elf_object_p): Check type of e_shstrndx section.
+
+Upstream-Status: Backport
+CVE: CVE-2019-12972
+Signed-off-by: Anuj Mittal
+---
+ bfd/ChangeLog | 5 +
+ bfd/elfcode.h | 3 ++-
+ 2 files changed, 7 insertions(+), 1 deletion(-)
+
+diff --git a/bfd/ChangeLog b/bfd/ChangeLog
+index 91f09e6346..e66fb40a2c 100644
+--- a/bfd/ChangeLog
b/bfd/ChangeLog
+@@ -1,3 +1,8 @@
++2019-06-21 Alan Modra
++
++ PR 24689
++ * elfcode.h (elf_object_p): Check type of e_shstrndx section.
++
+ 2019-02-20 Alan Modra
+
+ PR 24236
+diff --git a/bfd/elfcode.h b/bfd/elfcode.h
+index ec5ea766de..a35a629087 100644
+--- a/bfd/elfcode.h
b/bfd/elfcode.h
+@@ -755,7 +755,8 @@ elf_object_p (bfd *abfd)
+ /* A further sanity check. */
+ if (i_ehdrp->e_shnum != 0)
+ {
+- if (i_ehdrp->e_shstrndx >= elf_numsections (abfd))
++ if (i_ehdrp->e_shstrndx >= elf_numsections (abfd)
++|| i_shdrp[i_ehdrp->e_shstrndx].sh_type != SHT_STRTAB)
+ {
+ /* PR 2257:
+We used to just goto got_wrong_format_error here
+--
+2.20.1
+
diff --git a/meta/recipes-devtools/binutils/binutils/CVE-2019-9071.patch
b/meta/recipes-devtools/binutils/binutils/CVE-2019-9071.patch
new file mode 100644
index 00..26f4809cf0
--- /dev/null
+++ b/meta/recipes-devtools/binutils/binutils/CVE-2019-9071.patch
@@ -0,0 +1,164 @@
+From c1202057eb9161a86af27d867703235fee7b7555 Mon Sep 17 00:00:00 2001
+From: Nick Clifton
+Date: Wed, 10 Apr 2019 15:49:36 +0100
+Subject: [PATCH] Pull in patch for libiberty that fixes a stack exhaustion bug
+ when demangling a pathalogically constructed mangled name.
+
+ PR 89394
+ * cp-demangle.c (cplus_demangle_fill_name): Reject negative
+ lengths.
+ (d_count_templates_scopes): Replace num_templates and num_scopes
+ parameters with a struct d_print_info pointer parameter. Adjust
+ body of the function accordingly. Add recursion counter and check
+ that the recursion limit is not reached.
+ (d_print_init): Pass dpi parameter to d_count_templates_scopes.
+ Reset recursion counter afterwards, unless the recursion limit was
+ reached.
+
+CVE: CVE-2019-9071
+Upstream-Status: Backport
+Signed-off-by: Anuj Mittal
+---
+ ChangeLog | 16 ++
+ libiberty/cp-demangle.c | 48 ++---
+ 2 files changed, 42 insertions(+), 22 deletions(-)
+
+diff --git a/ChangeLog b/ChangeLog
+index cd631a15b6..4df3aaa62c 100644
+--- a/ChangeLog
b/ChangeLog
+@@ -1,3 +1,19 @@
++2019-04-10 Nick Clifton
++
++ * libiberty: Sync with gcc. Bring in:
++ 2019-04-10 Nick Clifton
++
++ PR 89394
++ * cp-demangle.c (cplus_demangle_fill_name): Reject negative
++ lengths.
++ (d_count_templates_scopes): Replace num_templates and num_scopes
++ parameters with a struct d_print_info pointer parameter. Adjust
++ body of the function accordingly. Add recursion counter and check
++ that the recursion limit is not reached.
++ (d_print_init): Pass dpi parameter to d_count_templates_scopes.
++ Reset recursion counter afterwards, unless the recursion limit was
++ reached.
++
+ 2018-06-24 Nick Clifton
+
+ 2.32 branch created.
+diff --git a/libiberty/cp-demangle.c b/libiberty/cp-demangle.c
+index
Re: [OE-core] Problems with sstate-cache in Artifactory
On Wed, Jul 10, 2019 at 2:28 AM chris.lapla...@agilent.com wrote: > > > DEBUG: For url file://5c/sstate:u-boot-ti-staging:wsl-linux- > > gnueabi:2019.01+gitAUTOINC+06e0b5babe:r17:wsl:3:5cdf9380b9b3f8c94a706344cf19554a_packagedata.tgz > > returning > > https://artifactory.local.gallagher.io/artifactory/rnd-yocto-packages/sstate-cache/wsl-thud/5c/sstate%3Au-boot-ti- > > staging%3Awsl-linux- > > gnueabi%3A2019.01%2BgitAUTOINC%2B06e0b5babe%3Ar17%3Awsl%3A3%3A5cdf9380b9b3f8c94a706344cf19554a_packagedata.tgz; > > downloadfilename=5c/sstate:u-boot-ti-staging:wsl-linux- > > gnueabi:2019.01+gitAUTOINC+06e0b5babe:r17:wsl:3:5cdf9380b9b3f8c94a706344cf19554a_packagedata.tgz > > DEBUG: checkstatus: trying again > > DEBUG: checkstatus: trying again > > DEBUG: checkstatus: trying again > > DEBUG: checkstatus: trying again > > DEBUG: checkstatus() urlopen failed: HTTP Error 404: Not Found > > Is this mapping correct? Does using curl to download > https://artifactory.local.gallagher.io/artifactory/rnd-yocto-packages/sstate-cache/wsl-thud/5c/sstate%3Au-boot-ti-staging%3Awsl-linux-gnueabi%3A2019.01%2BgitAUTOINC%2B06e0b5babe%3Ar17%3Awsl%3A3%3A5cdf9380b9b3f8c94a706344cf19554a_packagedata.tgz;downloadfilename=5c/sstate:u-boot-ti-staging:wsl-linux-gnueabi:2019.01+gitAUTOINC+06e0b5babe:r17:wsl:3:5cdf9380b9b3f8c94a706344cf19554a_packagedata.tgz > work? > Yes, curl/wget can download it. What wrong do you suspect here? Thanks Ankur > Chris -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/2] libva-utils: upgrade 2.4.0 -> 2.5.0
For changes in this release, see:
https://github.com/intel/libva-utils/releases
Signed-off-by: Anuj Mittal
---
.../libva/{libva-utils_2.4.0.bb => libva-utils_2.5.0.bb} | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
rename meta/recipes-graphics/libva/{libva-utils_2.4.0.bb =>
libva-utils_2.5.0.bb} (90%)
diff --git a/meta/recipes-graphics/libva/libva-utils_2.4.0.bb
b/meta/recipes-graphics/libva/libva-utils_2.5.0.bb
similarity index 90%
rename from meta/recipes-graphics/libva/libva-utils_2.4.0.bb
rename to meta/recipes-graphics/libva/libva-utils_2.5.0.bb
index 7b764314bf..fc013d75c3 100644
--- a/meta/recipes-graphics/libva/libva-utils_2.4.0.bb
+++ b/meta/recipes-graphics/libva/libva-utils_2.5.0.bb
@@ -18,8 +18,8 @@ SRC_URI =
"https://github.com/intel/${BPN}/releases/download/${PV}/${BP}.tar.bz2
file://0001-Build-sfcsample-only-when-X11-backend-is-enabled.patch \
"
-SRC_URI[md5sum] = "f5374c4c32ce136e50aea0267887aed5"
-SRC_URI[sha256sum] =
"5b7d1954b40fcb2c0544be20125c71a0852049715ab85a3e8aba60434a40c6b3"
+SRC_URI[md5sum] = "c1fada26c286654859eff33b2562cb79"
+SRC_URI[sha256sum] =
"9238c9d5110d60f935683390b8383fdac3507346384cd5f117a23c6db1d72a17"
UPSTREAM_CHECK_URI = "https://github.com/intel/libva-utils/releases;
--
2.20.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/2] libva: upgrade 2.4.1 -> 2.5.0
For changes in this release, see:
https://github.com/intel/libva/releases
Signed-off-by: Anuj Mittal
---
.../recipes-graphics/libva/{libva_2.4.1.bb => libva_2.5.0.bb} | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
rename meta/recipes-graphics/libva/{libva_2.4.1.bb => libva_2.5.0.bb} (92%)
diff --git a/meta/recipes-graphics/libva/libva_2.4.1.bb
b/meta/recipes-graphics/libva/libva_2.5.0.bb
similarity index 92%
rename from meta/recipes-graphics/libva/libva_2.4.1.bb
rename to meta/recipes-graphics/libva/libva_2.5.0.bb
index 525721f0ae..e75648b2be 100644
--- a/meta/recipes-graphics/libva/libva_2.4.1.bb
+++ b/meta/recipes-graphics/libva/libva_2.5.0.bb
@@ -19,8 +19,8 @@ LIC_FILES_CHKSUM =
"file://COPYING;md5=2e48940f94acb0af582e5ef03537800f"
SRC_URI =
"https://github.com/intel/${BPN}/releases/download/${PV}/${BP}.tar.bz2;
-SRC_URI[md5sum] = "5b5ace9de3f07cb7b8f4d19b6979adf0"
-SRC_URI[sha256sum] =
"e9e053908591b121793eaa5d8aa37675b4cd3af4b12f1f377dff4767f39cee70"
+SRC_URI[md5sum] = "3688212fb7a87947070f3729e91ff7cf"
+SRC_URI[sha256sum] =
"3aa89cd369a506ac4dbe5de7c0ef5da4f3d220bf986403f02fa1f6f702af6878"
UPSTREAM_CHECK_URI = "https://github.com/intel/libva/releases;
--
2.20.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] ✗ patchtest: failure for "core-image-sato-sdk-ptest: Red..." and 1 more
== Series Details == Series: "core-image-sato-sdk-ptest: Red..." and 1 more Revision: 1 URL : https://patchwork.openembedded.org/series/18588/ State : failure == Summary == Thank you for submitting this patch series to OpenEmbedded Core. This is an automated response. Several tests have been executed on the proposed series by patchtest resulting in the following failures: * Issue Series does not apply on top of target branch [test_series_merge_on_head] Suggested fixRebase your series on top of targeted branch Targeted branch master (currently at 78fcea7451) If you believe any of these test results are incorrect, please reply to the mailing list (openembedded-core@lists.openembedded.org) raising your concerns. Otherwise we would appreciate you correcting the issues and submitting a new version of the patchset if applicable. Please ensure you add/increment the version number when sending the new version (i.e. [PATCH] -> [PATCH v2] -> [PATCH v3] -> ...). --- Guidelines: https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Problems with sstate-cache in Artifactory
> DEBUG: For url file://5c/sstate:u-boot-ti-staging:wsl-linux- > gnueabi:2019.01+gitAUTOINC+06e0b5babe:r17:wsl:3:5cdf9380b9b3f8c94a706344cf19554a_packagedata.tgz > returning > https://artifactory.local.gallagher.io/artifactory/rnd-yocto-packages/sstate-cache/wsl-thud/5c/sstate%3Au-boot-ti- > staging%3Awsl-linux- > gnueabi%3A2019.01%2BgitAUTOINC%2B06e0b5babe%3Ar17%3Awsl%3A3%3A5cdf9380b9b3f8c94a706344cf19554a_packagedata.tgz; > downloadfilename=5c/sstate:u-boot-ti-staging:wsl-linux- > gnueabi:2019.01+gitAUTOINC+06e0b5babe:r17:wsl:3:5cdf9380b9b3f8c94a706344cf19554a_packagedata.tgz > DEBUG: checkstatus: trying again > DEBUG: checkstatus: trying again > DEBUG: checkstatus: trying again > DEBUG: checkstatus: trying again > DEBUG: checkstatus() urlopen failed: HTTP Error 404: Not Found Is this mapping correct? Does using curl to download https://artifactory.local.gallagher.io/artifactory/rnd-yocto-packages/sstate-cache/wsl-thud/5c/sstate%3Au-boot-ti-staging%3Awsl-linux-gnueabi%3A2019.01%2BgitAUTOINC%2B06e0b5babe%3Ar17%3Awsl%3A3%3A5cdf9380b9b3f8c94a706344cf19554a_packagedata.tgz;downloadfilename=5c/sstate:u-boot-ti-staging:wsl-linux-gnueabi:2019.01+gitAUTOINC+06e0b5babe:r17:wsl:3:5cdf9380b9b3f8c94a706344cf19554a_packagedata.tgz work? Chris -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/2] core-image-sato-sdk-ptest: Reduce image padding size due to bootimg 4GB limit
This image continues to run out of space on the autobuilder, tweak it a bit
further now the image space requirements were reduced after various ptest
fixes to avoid the error.
Signed-off-by: Richard Purdie
---
meta/recipes-sato/images/core-image-sato-sdk-ptest.bb | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-sato/images/core-image-sato-sdk-ptest.bb
b/meta/recipes-sato/images/core-image-sato-sdk-ptest.bb
index e84beda6ce1..ff297fe324c 100644
--- a/meta/recipes-sato/images/core-image-sato-sdk-ptest.bb
+++ b/meta/recipes-sato/images/core-image-sato-sdk-ptest.bb
@@ -12,10 +12,10 @@ IMAGE_INSTALL += "${PTESTS_FAST} ${PTESTS_SLOW}"
# This image is sufficiently large (~1.8GB) that we need to be careful that it
fits in a live
# image (which has a 4GB limit), so nullify the overhead factor (1.3x out of
the
-# box) and explicitly add just 1200MB.
+# box) and explicitly add just 1100MB.
# strace-ptest in particular needs more than 500MB
IMAGE_OVERHEAD_FACTOR = "1.0"
-IMAGE_ROOTFS_EXTRA_SPACE = "1224288"
+IMAGE_ROOTFS_EXTRA_SPACE = "1124288"
# ptests need more memory than standard to avoid the OOM killer
QB_MEM = "-m 1024"
--
2.20.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/2] oeqa/bbtests: Tweak test bitbake output pattern matching
The output from bitbake will change slightly soon due to runqueue changes,
adpat the test now to account for both the old and new cases.
Signed-off-by: Richard Purdie
---
meta/lib/oeqa/selftest/cases/bbtests.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/lib/oeqa/selftest/cases/bbtests.py
b/meta/lib/oeqa/selftest/cases/bbtests.py
index 2a310bc4af2..17da0fd32c7 100644
--- a/meta/lib/oeqa/selftest/cases/bbtests.py
+++ b/meta/lib/oeqa/selftest/cases/bbtests.py
@@ -40,7 +40,7 @@ class BitbakeTests(OESelftestTestCase):
def test_event_handler(self):
self.write_config("INHERIT += \"test_events\"")
result = bitbake('m4-native')
-find_build_started = re.search(r"NOTE: Test for
bb\.event\.BuildStarted(\n.*)*NOTE: Executing RunQueue Tasks", result.output)
+find_build_started = re.search(r"NOTE: Test for
bb\.event\.BuildStarted(\n.*)*NOTE: Executing.*Tasks", result.output)
find_build_completed = re.search(r"Tasks Summary:.*(\n.*)*NOTE: Test
for bb\.event\.BuildCompleted", result.output)
self.assertTrue(find_build_started, msg = "Match failed in:\n%s" %
result.output)
self.assertTrue(find_build_completed, msg = "Match failed in:\n%s" %
result.output)
--
2.20.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH] Add gnu testsuite execution for OEQA
On Tue, Jul 9, 2019 at 4:48 AM Nathan Rossi wrote: > > On Tue, 9 Jul 2019 at 21:16, Burton, Ross wrote: > > > > This is awesome! > > > > On Sat, 6 Jul 2019 at 12:39, Nathan Rossi wrote: > > > | gcc | g++ | libstdc++ | binutils| gas > > > | ld | glibc > > > x86-64 | 589/135169 | 457/131913 | 1/13008 | 0/ 236 | > > > 0/ 1256 | 166/ 1975 | 1423/ 5991 > > > arm | 469/123905 | 365/128416 |19/12788 | 0/ 191 | > > > 0/ 872 | 155/ 1479 |64/ 5130 > > > aarch64 | 460/130904 | 364/128977 | 1/12789 | 0/ 190 | > > > 0/ 442 | 157/ 1474 |76/ 5882 > > > powerpc | 18336/116624 | 6747/128636 |33/12996 | 0/ 187 | > > > 1/ 265 | 157/ 1352 | 1218/ 5110 > > > mips64 | 1174/134744 | 401/130195 |22/12780 | 0/ 213 | > > > 43/ 7245 | 803/ 1634 | 2032/ 5847 > > > riscv64 | 456/106399 | 376/128427 | 1/12748 | 0/ 185 | > > > 0/ 257 | 152/ 1062 |88/ 5847 > > > > So what I'm really interested in is what those numbers look like for > > e.g. x86-64 on real hardware: are the test suites always failing a > > bit, or are these indicative of problems we've introduced? > these numbers id PASS/FAIL are not usual, usually it should be only handful of failures, but this could be some simple basic missing piece, since dejaGNU is quite picky at times. > Just to clarify, by real hardware are you interested in the tests > running against a system running with a oe distro + kernel. Or just > running on e.g. the build host? > > As for the failing tests, do not put to much emphasis on the values > provided. I am sure there are a number of tests that are failing due > to minor configuration issues that simply need a deeper look at the > test result and output to fix the issue. And the large number of > failures for powerpc are due to qemu user failing due to illegal > instruction. > > The goal would be to get the results similar to what other > users/distro get, by reviewing results posted here: > https://gcc.gnu.org/ml/gcc-testresults/. > And for glibc the results from: https://sourceware.org/glibc/wiki/Release/2.29 > > Thanks, > Nathan > -- > ___ > 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
[OE-core] [PATCH v3] efibootmgr: Pass correct flags to compiler from pkg-config
efivar.h is in usr/include/efirvar directory so it should be added to include search path via -I to compiler cmdline to fix make[1]: *** No rule to make target 'efivar.h', needed by 'efibootmgr.o'. Stop. | make[1]: *** Waiting for unfinished jobs When running clang to generate dependencies -MM -MG -MF it still parses the compile unit and complains if certain header is not found where as gcc does not do that, hence the compile error is only seen when compiling with clang. Signed-off-by: Khem Raj --- v3: Use a backported patch instead of workaround ...8ae0bce776a36ea2001dea63d376be8274ac.patch | 83 +++ meta/recipes-bsp/efibootmgr/efibootmgr_17.bb | 1 + 2 files changed, 84 insertions(+) create mode 100644 meta/recipes-bsp/efibootmgr/efibootmgr/97668ae0bce776a36ea2001dea63d376be8274ac.patch diff --git a/meta/recipes-bsp/efibootmgr/efibootmgr/97668ae0bce776a36ea2001dea63d376be8274ac.patch b/meta/recipes-bsp/efibootmgr/efibootmgr/97668ae0bce776a36ea2001dea63d376be8274ac.patch new file mode 100644 index 00..9525ed8c54 --- /dev/null +++ b/meta/recipes-bsp/efibootmgr/efibootmgr/97668ae0bce776a36ea2001dea63d376be8274ac.patch @@ -0,0 +1,83 @@ +From 97668ae0bce776a36ea2001dea63d376be8274ac Mon Sep 17 00:00:00 2001 +From: Peter Jones +Date: Wed, 6 Mar 2019 13:08:33 -0500 +Subject: [PATCH] Make sure PKGS= is propogated into the submake for "make + deps" + +When we're doing make deps with "$(CC) -MF", gcc and clang have different +behavior, both broken in different ways, which we're hitting because of a +missing -I argument for libefivar's includes. On clang, when a header can't +be found, it emits a rule with the header as a prerequisite without a path, +such as efivar.h here: + +efibootmgr.o: efibootmgr.c fix_coverity.h efivar.h efiboot.h \ + /home/pjones/devel/github.com/efibootmgr/master/src/include/list.h \ + /home/pjones/devel/github.com/efibootmgr/master/src/include/efi.h \ + /home/pjones/devel/github.com/efibootmgr/master/src/include/unparse_path.h \ + /home/pjones/devel/github.com/efibootmgr/master/src/include/efibootmgr.h \ + error.h + +Then the build that utilizes that rule will fail to find the +prerequisite and tell you something like: + +make[1]: *** No rule to make target 'efivar.h', needed by 'efibootmgr.o'. Stop. +make[1]: Leaving directory '/home/pjones/devel/github.com/efibootmgr/master/src' + +With gcc, when a header can't be found, it emits a rule without that header +as a prerequisite, as such (again with efivar.h): + +efibootmgr.o: efibootmgr.c fix_coverity.h \ + /home/pjones/devel/github.com/efibootmgr/master/src/include/list.h \ + /home/pjones/devel/github.com/efibootmgr/master/src/include/efi.h \ + /home/pjones/devel/github.com/efibootmgr/master/src/include/unparse_path.h \ + /home/pjones/devel/github.com/efibootmgr/master/src/include/efi.h \ + /home/pjones/devel/github.com/efibootmgr/master/src/include/efibootmgr.h \ + error.h + +And then your build will fail if you haven't adjusted CFLAGS to tell it +where to find the header. + +Both of these would be better just erroring, but at least gcc's doesn't +insert a *wrong* dependency. + +This patch adds "PKGS=efivar efibootmgr popt" for all deps under src/. +Technically that's overkill, as efibootmgr itself doesn't need popt, but it +doesn't hurt anything to have the extra part there. The resulting +.efibootmgr.d file has the prerequisites expressed correctly: + +efibootmgr.o: efibootmgr.c fix_coverity.h /usr/include/efivar/efivar.h \ + /usr/include/efivar/efiboot.h \ + /home/pjones/devel/github.com/efibootmgr/master/src/include/list.h \ + /home/pjones/devel/github.com/efibootmgr/master/src/include/efi.h \ + /home/pjones/devel/github.com/efibootmgr/master/src/include/unparse_path.h \ + /home/pjones/devel/github.com/efibootmgr/master/src/include/efi.h \ + /home/pjones/devel/github.com/efibootmgr/master/src/include/efibootmgr.h \ + error.h + +This fixes the issue described in github PR #96 + +Signed-off-by: Peter Jones +Upstream-Status: Backport [https://github.com/rhboot/efibootmgr/commit/97668ae0bce776a36ea2001dea63d376be8274ac] +--- + src/Makefile | 7 ++- + 1 file changed, 6 insertions(+), 1 deletion(-) + +diff --git a/src/Makefile b/src/Makefile +index 258bac1..32fa188 100644 +--- a/src/Makefile b/src/Makefile +@@ -31,8 +31,13 @@ efibootdump : PKGS=efivar efiboot popt + efibootnext : $(call objects-of,$(EFIBOOTNEXT_SOURCES)) + efibootnext : PKGS=efivar efiboot popt + ++deps : PKGS=efivar efiboot popt + deps : $(ALL_SOURCES) +- $(MAKE) -f $(TOPDIR)/Make.deps deps SOURCES="$(ALL_SOURCES)" SUBDIR_CFLAGS="$(SUBDIR_CFLAGS)" ++ $(MAKE) -f $(TOPDIR)/Make.deps \ ++ SOURCES="$(ALL_SOURCES)" \ ++ SUBDIR_CFLAGS="$(SUBDIR_CFLAGS)" \ ++ PKGS="$(PKGS)" \ ++ deps + + clean : + @rm -rfv *.o *.a *.so $(TARGETS) diff --git a/meta/recipes-bsp/efibootmgr/efibootmgr_17.bb b/meta/recipes-bsp/efibootmgr/efibootmgr_17.bb index
[OE-core] [PATCH] u-boot: Provide tasks to generate default U-Boot environment(s) images
This change provides tasks to generate default U-Boot environment images
from built U-Boot (via. get_default_envs.sh script).
Those images then can be used to generate wic images (with e.g. eMMC layout).
With such approach the end user doesn't see the "CRC environment" error
after the first boot.
Moreover, those are built per MACHINE (as u-boot itself is) so then could
be used in SWUpdate scenarios with single tar'ed archive with multiple
MACHINE specific *.swu images.
It is also possible to adjust the *_ENVS_* variables in machine specific
conf file.
Test:
Newest master-next for poky repo - SHA1:
eb5b0a0b5e53a6e55a09e66489d3f24d0c6232ee
MACHINE = "beaglebone-yocto" in local.conf
bitbake virtual/bootloader
As a result following links are available in deploy directory:
u-boot-env.img{_r}.
Signed-off-by: Lukasz Majewski
---
meta/recipes-bsp/u-boot/u-boot.inc | 41 ++
1 file changed, 41 insertions(+)
diff --git a/meta/recipes-bsp/u-boot/u-boot.inc
b/meta/recipes-bsp/u-boot/u-boot.inc
index 9a754fd09b..e0ccf1ce1f 100644
--- a/meta/recipes-bsp/u-boot/u-boot.inc
+++ b/meta/recipes-bsp/u-boot/u-boot.inc
@@ -331,3 +331,44 @@ do_deploy () {
}
addtask deploy before do_build after do_compile
+
+# Extract default envs from build U-Boot
+DEFAULT_UBOOT_ENVS_FILE ?= "u-boot-env"
+DEFAULT_ENVS ?= "${DEFAULT_UBOOT_ENVS_FILE}.txt"
+UBOOT_ENVS_DEFAULT ?= "${DEFAULT_UBOOT_ENVS_FILE}-${MACHINE}-${PV}-${PR}.img"
+UBOOT_ENVS_SIZE ?= "65536"
+
+# Generate default environment
+do_gen_default_envs[doc] = "Generate image with default U-Boot environment(s)"
+do_gen_default_envs () {
+${B}/source/scripts/get_default_envs.sh ${B} > ${B}/${DEFAULT_ENVS}
+
+# Generate env image
+${B}/tools/mkenvimage -s ${UBOOT_ENVS_SIZE} -o ${B}/${UBOOT_ENVS_DEFAULT}
${B}/${DEFAULT_ENVS}
+
+# Generate redundant env image
+${B}/tools/mkenvimage -r -s ${UBOOT_ENVS_SIZE} -o
${B}/${UBOOT_ENVS_DEFAULT}_r ${B}/${DEFAULT_ENVS}
+
+rm ${B}/${DEFAULT_ENVS}
+}
+
+addtask gen_default_envs before do_deploy after do_compile
+
+# Deploy default environment
+do_deploy_default_envs[doc] = "Copy images with default U-Boot environment to
deployment directory"
+do_deploy_default_envs () {
+
+ install -d ${DEPLOYDIR}
+
+ install ${B}/${UBOOT_ENVS_DEFAULT} ${DEPLOYDIR}/${UBOOT_ENVS_DEFAULT}
+ install ${B}/${UBOOT_ENVS_DEFAULT}_r ${DEPLOYDIR}/${UBOOT_ENVS_DEFAULT}_r
+
+ cd ${DEPLOYDIR}
+ ln -sf ${UBOOT_ENVS_DEFAULT} ${DEFAULT_UBOOT_ENVS_FILE}.img
+ ln -sf ${UBOOT_ENVS_DEFAULT}_r ${DEFAULT_UBOOT_ENVS_FILE}.img_r
+
+ rm ${B}/${UBOOT_ENVS_DEFAULT}
+ rm ${B}/${UBOOT_ENVS_DEFAULT}_r
+}
+
+addtask deploy_default_envs before do_deploy after do_gen_default_envs
--
2.11.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] systemd: Fix interface bring-up on kernels >= 5.2
On Tue, Jul 9, 2019 at 12:59 PM Ricardo Ribalda Delgado wrote: > > Hi Alex > > That would also be ok. Is this already on a released version or is > only on the "master" branch? > > It's on the v242-stable branch: https://github.com/systemd/systemd-stable/commit/8fbc72f45f4aa84889bc8694a9ce662946464c37 -- Alex Kiernan -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] systemd: Fix interface bring-up on kernels >= 5.2
Hi Alex That would also be ok. Is this already on a released version or is only on the "master" branch? On Tue, Jul 9, 2019 at 1:12 PM Alex Kiernan wrote: > > On Tue, Jul 9, 2019 at 9:43 AM Ricardo Ribalda Delgado > wrote: > > > > With kernels >=5.2 systemd-networkd is unable to bring up the link. > > > > eth0: Could not bring up interface: Invalid argument > > > > This is already reported upstream and fixed on master: > > > > https://github.com/systemd/systemd/issues/12784 > > > > They recommend Debian to backport two patches. > > > > Signed-off-by: Ricardo Ribalda Delgado > > --- > > Could we just move the SRCREV to the top of systemd-stable, which > includes a change that looks a lot like this problem, but isn't the > exact same change? > > -- > Alex Kiernan -- Ricardo Ribalda -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH] Add gnu testsuite execution for OEQA
On Tue, 9 Jul 2019 at 12:47, Nathan Rossi wrote: > Just to clarify, by real hardware are you interested in the tests > running against a system running with a oe distro + kernel. Or just > running on e.g. the build host? > > As for the failing tests, do not put to much emphasis on the values > provided. I am sure there are a number of tests that are failing due > to minor configuration issues that simply need a deeper look at the > test result and output to fix the issue. And the large number of > failures for powerpc are due to qemu user failing due to illegal > instruction. > > The goal would be to get the results similar to what other > users/distro get, by reviewing results posted here: > https://gcc.gnu.org/ml/gcc-testresults/. > And for glibc the results from: https://sourceware.org/glibc/wiki/Release/2.29 Ah that's useful that they publish those. So the test results for 2.29 on x86-64 are: 5961 PASS 21 UNSUPPORTED 17 XFAIL 2 XPASS And your report has 1423 failures, so *something* is broken. As you say, some flaw in qemu-user is most likely the culprit there. Compare to the ARM results: 9 FAIL 5041 PASS 31 UNSUPPORTED 17 XFAIL 2 XPASS Your report has 64 failures, which is much closer even with qemu-user. Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH] Add gnu testsuite execution for OEQA
On Tue, 9 Jul 2019 at 21:16, Burton, Ross wrote: > > This is awesome! > > On Sat, 6 Jul 2019 at 12:39, Nathan Rossi wrote: > > | gcc | g++ | libstdc++ | binutils| gas > > | ld | glibc > > x86-64 | 589/135169 | 457/131913 | 1/13008 | 0/ 236 | 0/ > > 1256 | 166/ 1975 | 1423/ 5991 > > arm | 469/123905 | 365/128416 |19/12788 | 0/ 191 | 0/ > > 872 | 155/ 1479 |64/ 5130 > > aarch64 | 460/130904 | 364/128977 | 1/12789 | 0/ 190 | 0/ > > 442 | 157/ 1474 |76/ 5882 > > powerpc | 18336/116624 | 6747/128636 |33/12996 | 0/ 187 | 1/ > > 265 | 157/ 1352 | 1218/ 5110 > > mips64 | 1174/134744 | 401/130195 |22/12780 | 0/ 213 |43/ > > 7245 | 803/ 1634 | 2032/ 5847 > > riscv64 | 456/106399 | 376/128427 | 1/12748 | 0/ 185 | 0/ > > 257 | 152/ 1062 |88/ 5847 > > So what I'm really interested in is what those numbers look like for > e.g. x86-64 on real hardware: are the test suites always failing a > bit, or are these indicative of problems we've introduced? Just to clarify, by real hardware are you interested in the tests running against a system running with a oe distro + kernel. Or just running on e.g. the build host? As for the failing tests, do not put to much emphasis on the values provided. I am sure there are a number of tests that are failing due to minor configuration issues that simply need a deeper look at the test result and output to fix the issue. And the large number of failures for powerpc are due to qemu user failing due to illegal instruction. The goal would be to get the results similar to what other users/distro get, by reviewing results posted here: https://gcc.gnu.org/ml/gcc-testresults/. And for glibc the results from: https://sourceware.org/glibc/wiki/Release/2.29 Thanks, Nathan -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH] Add gnu testsuite execution for OEQA
This is awesome! On Sat, 6 Jul 2019 at 12:39, Nathan Rossi wrote: > | gcc | g++ | libstdc++ | binutils| gas > | ld | glibc > x86-64 | 589/135169 | 457/131913 | 1/13008 | 0/ 236 | 0/ > 1256 | 166/ 1975 | 1423/ 5991 > arm | 469/123905 | 365/128416 |19/12788 | 0/ 191 | 0/ > 872 | 155/ 1479 |64/ 5130 > aarch64 | 460/130904 | 364/128977 | 1/12789 | 0/ 190 | 0/ > 442 | 157/ 1474 |76/ 5882 > powerpc | 18336/116624 | 6747/128636 |33/12996 | 0/ 187 | 1/ > 265 | 157/ 1352 | 1218/ 5110 > mips64 | 1174/134744 | 401/130195 |22/12780 | 0/ 213 |43/ > 7245 | 803/ 1634 | 2032/ 5847 > riscv64 | 456/106399 | 376/128427 | 1/12748 | 0/ 185 | 0/ > 257 | 152/ 1062 |88/ 5847 So what I'm really interested in is what those numbers look like for e.g. x86-64 on real hardware: are the test suites always failing a bit, or are these indicative of problems we've introduced? Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] systemd: Fix interface bring-up on kernels >= 5.2
On Tue, Jul 9, 2019 at 9:43 AM Ricardo Ribalda Delgado wrote: > > With kernels >=5.2 systemd-networkd is unable to bring up the link. > > eth0: Could not bring up interface: Invalid argument > > This is already reported upstream and fixed on master: > > https://github.com/systemd/systemd/issues/12784 > > They recommend Debian to backport two patches. > > Signed-off-by: Ricardo Ribalda Delgado > --- Could we just move the SRCREV to the top of systemd-stable, which includes a change that looks a lot like this problem, but isn't the exact same change? -- Alex Kiernan -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH] Add gnu testsuite execution for OEQA
On Tue, 9 Jul 2019 at 06:55, Alejandro Enedino Hernandez Samaniego wrote: > > Hey guys, > > On Sat, Jul 6, 2019 at 5:52 AM Richard Purdie > wrote: >> >> On Sat, 2019-07-06 at 11:39 +, Nathan Rossi wrote: >> > This patch is an RFC for adding support to execute the gnu test suites for >> > binutils, gcc and glibc. With the intention for enabling automated test >> > running >> > of these test suites within the OEQA framework such that they can be >> > executed by >> > the Yocto Autobuilder. >> > >> > Please note that this patch is not a complete implementation and needs >> > additional work as well as changes based on comments and feedback from >> > this RFC. >> >> This is rather cool, thanks! >> >> Looking at this was on my todo list once we got the existing OEQA, >> ptest and ltp setups working well. I'm very happy to have been beaten >> to it though. >> >> > The test suites covered need significant resources or build artifacts such >> > that running them on the target is undesirable which rules out the use of >> > ptest. >> > Because of this the test suites can be run on the build host and if >> > necessary >> > call out to the target. >> > >> > The following implementation creates a number of recipes that are used to >> > build/execute the test suites for the different components. The reason for >> > creating separate recipes is primarily due to dependencies and the need for >> > components in the sysroot. For example binutils has tests that use the C >> > compiler however binutils is a dependency for the C compiler and thus would >> > cause a dependency loop. The issue with sysroots occurs with dependence on >> > `*-initial` recipes and the test suites needing the non-initial version. >> >> I think this means you're working with something pre-warrior as we got >> rid of most of the *-initial recipes apart from libgcc-initial. > > > Yup, I agree with this, and yes, we still have initial recipes, which is in > what Nathan based his work. > >> >> > Some issues with splitting the recipes: >> > - Rebuilds the recipe >> >- Like gcc-cross-testsuite in this patch, could use a stashed builddir >> > - Source is duplicated >> >- gcc gets around this with shared source >> > - Requires having the recipe files and maintaining them >> >- Multiple versions of recipes >> >- Multiple variants of recipes (-cross, -crosssdk, -native if desired) >> >> It might be possible to have multiple tasks in these recipes and have >> the later tasks depend on other pieces of the system like the C >> compiler, thereby avoiding the need for splitting if only the later >> tasks have the dependencies. Not sure if it would work or not but may >> be worth exploring. > > > Worth exploring but might end up being more convoluted than necessary IMO. > Benefit vs Complication issue. > > >> >> > Target execution is another issue with the test suites. Note that binutils >> > however does not require any target execution. In this patch both >> > qemu-linux-user and ssh target execution solutions are provided. For the >> > purposes of OE, qemu-linux-user may suffice as it has great success at >> > executing >> > gcc and gcc-runtime tests with acceptable success at executing the glibc >> > tests. >> >> I feel fairly strongly that we probably want to execute these kinds of >> tests under qemu system mode, not the user mode. The reason is that we >> want to be as close to the target environment as we can be and that >> qemu-user testing is at least as much of a test of qemu's emulation >> that it is the behaviour of the compiler or libc (libc in particular). >> I was thinking this and then later read you confirmed my suspicions >> below... > > > I believe the QEMU recipe splitting is also new in the tree, and Nathan isn't > basing his work on that, > so there might be some issues there. I have been working against a relatively recent master, and have been rebasing every now and again. The qemu system/user split likely will not be a big problem, since at least at this point I have kept all the qemu system tooling as runqemu setup in OEQA. So would work fine on master/warrior/thud. > >> >> >> > The glibc test suite can be problematic to execute for a few reasons: >> > - Requires access to the exact same filesystem as the build host >> >- On physical targets and QEMU this requires NFS mounts >> >> We do have unfs support already under qemu which might make this >> possible. >> >> > - Relies on exact syscall behaviour >> >- Causes some issues where there are differences between >> > qemu-linux-user and >> > the target architectures kernel >> >> Right, this one worries me and pushes me to want to use qemu system >> mode. >> >> > - Can consume significant resources (e.g. OOM, or worse trigger >> > bugs/panics in >> >kernel drivers) >> >> Any rough guide to what significant is here? ptest needs 1GB memory for >> example. qemu-system mode should limit that to the VMs at least? >> >> > - Slow to
[OE-core] [PATCH 1/2] libsndfile1: disable use of sqlite3 by default
sqlite3 is only used by the regression testing tool, which is of limited use
unless you're the developer of libsndfile. Add a PACKAGECONFIG for this, but
disable by default.
Signed-off-by: Ross Burton
---
meta/recipes-multimedia/libsndfile/libsndfile1_1.0.28.bb | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-multimedia/libsndfile/libsndfile1_1.0.28.bb
b/meta/recipes-multimedia/libsndfile/libsndfile1_1.0.28.bb
index 77393db8470..7dfee4e96fa 100644
--- a/meta/recipes-multimedia/libsndfile/libsndfile1_1.0.28.bb
+++ b/meta/recipes-multimedia/libsndfile/libsndfile1_1.0.28.bb
@@ -1,7 +1,7 @@
SUMMARY = "Audio format Conversion library"
HOMEPAGE = "http://www.mega-nerd.com/libsndfile;
AUTHOR = "Erik de Castro Lopo"
-DEPENDS = "flac libogg libvorbis sqlite3"
+DEPENDS = "flac libogg libvorbis"
SECTION = "libs/multimedia"
LICENSE = "LGPLv2.1"
@@ -30,6 +30,7 @@ S = "${WORKDIR}/libsndfile-${PV}"
PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'alsa', d)}"
PACKAGECONFIG[alsa] = "--enable-alsa,--disable-alsa,alsa-lib"
+PACKAGECONFIG[regtest] = "--enable-sqlite,--disable-sqlite,sqlite3"
inherit autotools lib_package pkgconfig
--
2.20.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/2] libsndfile1: remove redundant autoconf seeding
Twelve years ago libsndfile was badly detecting large file handling and
generating bad code[1]. The detection code in libsndfile has had many fixes
since then and this isn't needed anymore (verified by comparing config.h when
built for qemuarm).
[1]
https://git.openembedded.org/openembedded/commit/?id=875cfc6f23ae68c6215bf32eb01a486f0387cb92
Signed-off-by: Ross Burton
---
meta/recipes-multimedia/libsndfile/libsndfile1_1.0.28.bb | 6 --
1 file changed, 6 deletions(-)
diff --git a/meta/recipes-multimedia/libsndfile/libsndfile1_1.0.28.bb
b/meta/recipes-multimedia/libsndfile/libsndfile1_1.0.28.bb
index 7dfee4e96fa..ffb45855a4b 100644
--- a/meta/recipes-multimedia/libsndfile/libsndfile1_1.0.28.bb
+++ b/meta/recipes-multimedia/libsndfile/libsndfile1_1.0.28.bb
@@ -33,9 +33,3 @@ PACKAGECONFIG[alsa] = "--enable-alsa,--disable-alsa,alsa-lib"
PACKAGECONFIG[regtest] = "--enable-sqlite,--disable-sqlite,sqlite3"
inherit autotools lib_package pkgconfig
-
-do_configure_prepend_arm() {
- export ac_cv_sys_largefile_source=1
- export ac_cv_sys_file_offset_bits=64
-}
-
--
2.20.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH] Add gnu testsuite execution for OEQA
On Sat, 6 Jul 2019 at 22:52, Richard Purdie wrote: > > On Sat, 2019-07-06 at 11:39 +, Nathan Rossi wrote: > > This patch is an RFC for adding support to execute the gnu test suites for > > binutils, gcc and glibc. With the intention for enabling automated test > > running > > of these test suites within the OEQA framework such that they can be > > executed by > > the Yocto Autobuilder. > > > > Please note that this patch is not a complete implementation and needs > > additional work as well as changes based on comments and feedback from this > > RFC. > > This is rather cool, thanks! > > Looking at this was on my todo list once we got the existing OEQA, > ptest and ltp setups working well. I'm very happy to have been beaten > to it though. > > > The test suites covered need significant resources or build artifacts such > > that running them on the target is undesirable which rules out the use of > > ptest. > > Because of this the test suites can be run on the build host and if > > necessary > > call out to the target. > > > > The following implementation creates a number of recipes that are used to > > build/execute the test suites for the different components. The reason for > > creating separate recipes is primarily due to dependencies and the need for > > components in the sysroot. For example binutils has tests that use the C > > compiler however binutils is a dependency for the C compiler and thus would > > cause a dependency loop. The issue with sysroots occurs with dependence on > > `*-initial` recipes and the test suites needing the non-initial version. > > I think this means you're working with something pre-warrior as we got > rid of most of the *-initial recipes apart from libgcc-initial. I have been working against master (maybe a few days old). However I hit the sysroot collision in gcc-cross with what I thought was a -initial recipe. So I split it out and kept moving ahead. Turns out it was just one file, specifically an empty limits.h that is created by the gcc-cross recipe itself. (http://git.openembedded.org/openembedded-core/tree/meta/recipes-devtools/gcc/gcc-cross.inc#n49) > > > Some issues with splitting the recipes: > > - Rebuilds the recipe > >- Like gcc-cross-testsuite in this patch, could use a stashed builddir > > - Source is duplicated > >- gcc gets around this with shared source > > - Requires having the recipe files and maintaining them > >- Multiple versions of recipes > >- Multiple variants of recipes (-cross, -crosssdk, -native if desired) > > It might be possible to have multiple tasks in these recipes and have > the later tasks depend on other pieces of the system like the C > compiler, thereby avoiding the need for splitting if only the later > tasks have the dependencies. Not sure if it would work or not but may > be worth exploring. Initially I had started out with binutils having the do_check task which depended on the populate_sysroot task of the associated dependencies and this was working well for binutils at least. The only concern I had with this was whether tainting the recipe sysroots would be problematic? Given the sysroot/-initial issue with gcc was not a dependency problem I have tried with the check tasks in gcc-cross and gcc-runtime and there does not appear to have any issues. So splitting the recipes for binutils, gcc-cross and gcc-runtime is not necessary. For glibc the sysroot has libgcc-initial, so the sysroot collision is still a problem for it. > > > Target execution is another issue with the test suites. Note that binutils > > however does not require any target execution. In this patch both > > qemu-linux-user and ssh target execution solutions are provided. For the > > purposes of OE, qemu-linux-user may suffice as it has great success at > > executing > > gcc and gcc-runtime tests with acceptable success at executing the glibc > > tests. > > I feel fairly strongly that we probably want to execute these kinds of > tests under qemu system mode, not the user mode. The reason is that we > want to be as close to the target environment as we can be and that > qemu-user testing is at least as much of a test of qemu's emulation > that it is the behaviour of the compiler or libc (libc in particular). > I was thinking this and then later read you confirmed my suspicions > below... > > > The glibc test suite can be problematic to execute for a few reasons: > > - Requires access to the exact same filesystem as the build host > >- On physical targets and QEMU this requires NFS mounts > > We do have unfs support already under qemu which might make this > possible. unfs works great and I was using it for testing out the ssh support. However I did notice that is does rely on the host having rpcbind installed. This does prevent running the tests without root (even if using slirp for qemu). > > > - Relies on exact syscall behaviour > >- Causes some issues where there are differences between qemu-linux-user > > and
Re: [OE-core] [PATCH 1/1] buildtools-tarball: add nativesdk-libxml2-utils
On Tue, 2019-07-09 at 17:36 +0800, ChenQi wrote:
> On 07/09/2019 09:38 AM, ChenQi wrote:
> > On 07/09/2019 12:47 AM, Richard Purdie wrote:
> > > On Mon, 2019-07-08 at 15:37 +0800, Chen Qi wrote:
> > > > For build-sysroots.bb, the xmlcatalog would not be in its
> > > > staging directory. Causing the following error for eSDK.
> > > >
> > > > ERROR: build-sysroots-1.0-r0 do_build_native_sysroot: Command
> > > > '/PATH/TO/IMAGE/testsdkext/tmp/sysroots/x86_64/usr/bin/postinst
> > > > -
> > > > docbook-xml-dtd4-native-xmlcatalog' returned non-zero exit
> > > > status
> > > > 127.
> > > > ERROR: build-sysroots-1.0-r0 do_build_native_sysroot: Function
> > > > failed: do_build_native_sysroot
> > > >
> > > > The problem could be reproduced by the following steps.
> > > > 1. Add in local.conf:
> > > > IMAGE_INSTALL_append = " btrfs-tools"
> > > > DISTRO_FEATURES_append = " api-documentation"
> > > > INHERIT += "testsdk"
> > > > 2. bitbake core-image-minimal -c populate_sdk_ext
> > > > 3. bitbake core-image-minimal -c testsdkext
> > > >
> > > > So we add nativesdk-libxml2-utils to buildtools-tarball
> > > > to ensure the existence of xmlcatalog. Also add it
> > > > to HOSTTOOLS_NONFATAL so it could be seen by bitbake.
> > > >
> > > > Signed-off-by: Chen Qi
> > > > ---
> > > > meta/conf/bitbake.conf | 3 +++
> > > > meta/recipes-core/meta/buildtools-tarball.bb | 1 +
> > > > 2 files changed, 4 insertions(+)
> > > >
> > > > diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
> > > > index 5e93f5c..2f64eae 100644
> > > > --- a/meta/conf/bitbake.conf
> > > > +++ b/meta/conf/bitbake.conf
> > > > @@ -517,6 +517,9 @@ HOSTTOOLS_NONFATAL += "scp"
> > > > # Link to git-lfs if present
> > > > HOSTTOOLS_NONFATAL += "git-lfs"
> > > > +# build-sysroot needs xmlcatalog in order for eSDK
> > > > installation
> > > > +HOSTTOOLS_NONFATAL += "xmlcatalog"
> > > I don't mind the buildtools-tarball change but HOSTTOOLS is
> > > starting to
> > > grow to contain far too much random stuff which could impact
> > > reproduciblity.
> > >
> > > Is there some other way we could fix this? It still feels like a
> > > dependency problem which we chould fix by adding a missing
> > > dependency
> > > although I appreciate its far from being that simple.
> > >
> > > I wonder if there is a way we could teach build-sysroots to be
> > > cleverer
> > > about dependencies?
> >
> > I'll try to implement it and send out a new patch.
>
> Unfortunately I cannot figure out a good way to implement this.
> Could you please help giving me some hints?
What happens if we add:
${@bb.utils.contains('DISTRO_FEATURES', 'api-documentation',
'nativesdk-libxml2', '', d)} \
to
`
meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb
?
Cheers,
Richard
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] buildtools-tarball: add nativesdk-libxml2-utils
On 07/09/2019 09:38 AM, ChenQi wrote: On 07/09/2019 12:47 AM, Richard Purdie wrote: On Mon, 2019-07-08 at 15:37 +0800, Chen Qi wrote: For build-sysroots.bb, the xmlcatalog would not be in its staging directory. Causing the following error for eSDK. ERROR: build-sysroots-1.0-r0 do_build_native_sysroot: Command '/PATH/TO/IMAGE/testsdkext/tmp/sysroots/x86_64/usr/bin/postinst- docbook-xml-dtd4-native-xmlcatalog' returned non-zero exit status 127. ERROR: build-sysroots-1.0-r0 do_build_native_sysroot: Function failed: do_build_native_sysroot The problem could be reproduced by the following steps. 1. Add in local.conf: IMAGE_INSTALL_append = " btrfs-tools" DISTRO_FEATURES_append = " api-documentation" INHERIT += "testsdk" 2. bitbake core-image-minimal -c populate_sdk_ext 3. bitbake core-image-minimal -c testsdkext So we add nativesdk-libxml2-utils to buildtools-tarball to ensure the existence of xmlcatalog. Also add it to HOSTTOOLS_NONFATAL so it could be seen by bitbake. Signed-off-by: Chen Qi --- meta/conf/bitbake.conf | 3 +++ meta/recipes-core/meta/buildtools-tarball.bb | 1 + 2 files changed, 4 insertions(+) diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf index 5e93f5c..2f64eae 100644 --- a/meta/conf/bitbake.conf +++ b/meta/conf/bitbake.conf @@ -517,6 +517,9 @@ HOSTTOOLS_NONFATAL += "scp" # Link to git-lfs if present HOSTTOOLS_NONFATAL += "git-lfs" +# build-sysroot needs xmlcatalog in order for eSDK installation +HOSTTOOLS_NONFATAL += "xmlcatalog" I don't mind the buildtools-tarball change but HOSTTOOLS is starting to grow to contain far too much random stuff which could impact reproduciblity. Is there some other way we could fix this? It still feels like a dependency problem which we chould fix by adding a missing dependency although I appreciate its far from being that simple. I wonder if there is a way we could teach build-sysroots to be cleverer about dependencies? I'll try to implement it and send out a new patch. Hi Richard and Ross, Unfortunately I cannot figure out a good way to implement this. Could you please help giving me some hints? Best Regards, Chen Qi Regards, Chen Qi Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] buildhistory: don't output ownership for the sysroot
On Tue, 9 Jul 2019 at 02:11, akuster808 wrote: > On 7/8/19 4:46 PM, Ross Burton wrote: > > As the sysroot isn't ran inside pseudo the ownership is whoever is running > > the > > builds. In a setup where multiple builders all contribute to a shared > > buildhistory writing the ownership data isn't useful, so just replace it > > with "- > > -". > > Should this be backported? No, because the sysroot writing patches are not backported. :) Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] ✗ patchtest: failure for systemd: Fix interface bring-up on kernels >= 5.2
== Series Details == Series: systemd: Fix interface bring-up on kernels >= 5.2 Revision: 1 URL : https://patchwork.openembedded.org/series/18577/ State : failure == Summary == Thank you for submitting this patch series to OpenEmbedded Core. This is an automated response. Several tests have been executed on the proposed series by patchtest resulting in the following failures: * Issue Upstream-Status is in incorrect format [test_upstream_status_presence_format] Suggested fixFix Upstream-Status format in 0001-networkd-fix-link-up.patch Current Upstream-Status: backport https://github.com/systemd/systemd/commit/4eb086a38712ea98faf41e075b84555b11b54362.patch Standard format Upstream-Status: Valid status Pending, Accepted, Backport, Denied, Inappropriate [reason], Submitted [where] If you believe any of these test results are incorrect, please reply to the mailing list (openembedded-core@lists.openembedded.org) raising your concerns. Otherwise we would appreciate you correcting the issues and submitting a new version of the patchset if applicable. Please ensure you add/increment the version number when sending the new version (i.e. [PATCH] -> [PATCH v2] -> [PATCH v3] -> ...). --- Guidelines: https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] systemd: Fix interface bring-up on kernels >= 5.2
With kernels >=5.2 systemd-networkd is unable to bring up the link.
eth0: Could not bring up interface: Invalid argument
This is already reported upstream and fixed on master:
https://github.com/systemd/systemd/issues/12784
They recommend Debian to backport two patches.
Signed-off-by: Ricardo Ribalda Delgado
---
.../systemd/0001-networkd-fix-link-up.patch | 66 +
.../0002-network-do-not-send-ipv6.patch | 96 +++
meta/recipes-core/systemd/systemd_242.bb | 2 +
3 files changed, 164 insertions(+)
create mode 100644
meta/recipes-core/systemd/systemd/0001-networkd-fix-link-up.patch
create mode 100644
meta/recipes-core/systemd/systemd/0002-network-do-not-send-ipv6.patch
diff --git a/meta/recipes-core/systemd/systemd/0001-networkd-fix-link-up.patch
b/meta/recipes-core/systemd/systemd/0001-networkd-fix-link-up.patch
new file mode 100644
index 00..7a3b3f172d
--- /dev/null
+++ b/meta/recipes-core/systemd/systemd/0001-networkd-fix-link-up.patch
@@ -0,0 +1,66 @@
+From 6bd76d2d4ff130decd3aa13e0c2dbfd56ff8d7b7 Mon Sep 17 00:00:00 2001
+From: Susant Sahani
+Date: Thu, 9 May 2019 07:35:35 +0530
+Subject: [PATCH] networkd: fix link_up() (#12505)
+
+Fillup IFLA_INET6_ADDR_GEN_MODE while we do link_up.
+
+Fixes the following error:
+```
+dummy-test: Could not bring up interface: Invalid argument
+```
+
+After reading the kernel code when we do a link up
+```
+net/core/rtnetlink.c
+IFLA_AF_SPEC
+ af_ops->set_link_af(dev, af);
+ inet6_set_link_af
+ if (tb[IFLA_INET6_ADDR_GEN_MODE])
+ Here it looks for IFLA_INET6_ADDR_GEN_MODE
+```
+Since link up we didn't filling up that it's failing.
+
+Closes #12504.
+
+Signed-off-by: Ricardo Ribalda Delgado
+
+Upstream-Status: backport
https://github.com/systemd/systemd/commit/4eb086a38712ea98faf41e075b84555b11b54362.patch
+
+---
+ src/network/networkd-link.c | 15 +++
+ 1 file changed, 15 insertions(+)
+
+diff --git a/src/network/networkd-link.c b/src/network/networkd-link.c
+index e466b96792..042496173c 100644
+--- a/src/network/networkd-link.c
b/src/network/networkd-link.c
+@@ -2034,6 +2034,8 @@ static int link_up(Link *link) {
+ }
+
+ if (link_ipv6_enabled(link)) {
++uint8_t ipv6ll_mode;
++
+ r = sd_netlink_message_open_container(req, IFLA_AF_SPEC);
+ if (r < 0)
+ return log_link_error_errno(link, r, "Could not open
IFLA_AF_SPEC container: %m");
+@@ -2049,6 +2051,19 @@ static int link_up(Link *link) {
+ return log_link_error_errno(link, r, "Could
not append IFLA_INET6_TOKEN: %m");
+ }
+
++if (!link_ipv6ll_enabled(link))
++ipv6ll_mode = IN6_ADDR_GEN_MODE_NONE;
++else if (sysctl_read_ip_property(AF_INET6, link->ifname,
"stable_secret", NULL) < 0)
++/* The file may not exist. And event if it exists,
when stable_secret is unset,
++ * reading the file fails with EIO. */
++ipv6ll_mode = IN6_ADDR_GEN_MODE_EUI64;
++else
++ipv6ll_mode = IN6_ADDR_GEN_MODE_STABLE_PRIVACY;
++
++r = sd_netlink_message_append_u8(req,
IFLA_INET6_ADDR_GEN_MODE, ipv6ll_mode);
++if (r < 0)
++return log_link_error_errno(link, r, "Could not
append IFLA_INET6_ADDR_GEN_MODE: %m");
++
+ r = sd_netlink_message_close_container(req);
+ if (r < 0)
+ return log_link_error_errno(link, r, "Could not close
AF_INET6 container: %m");
diff --git
a/meta/recipes-core/systemd/systemd/0002-network-do-not-send-ipv6.patch
b/meta/recipes-core/systemd/systemd/0002-network-do-not-send-ipv6.patch
new file mode 100644
index 00..6e6ace4c5f
--- /dev/null
+++ b/meta/recipes-core/systemd/systemd/0002-network-do-not-send-ipv6.patch
@@ -0,0 +1,96 @@
+From b5c4eb818101127a606849e822937b15b8497c75 Mon Sep 17 00:00:00 2001
+From: Yu Watanabe
+Date: Thu, 9 May 2019 14:39:46 +0900
+Subject: [PATCH] network: do not send ipv6 token to kernel
+
+We disabled kernel RA support. Then, we should not send
+IFLA_INET6_TOKEN.
+Thus, we do not need to send IFLA_INET6_ADDR_GEN_MODE twice.
+
+Follow-up for 0e2fdb83bb5e22047e0c7cc058b415d0e93f02cf and
+4eb086a38712ea98faf41e075b84555b11b54362.
+
+Signed-off-by: Ricardo Ribalda Delgado
+
+Upstream-Status: backport
https://github.com/systemd/systemd/commit/9f6e82e6eb3b6e73d66d00d1d6eee60691fb702f
+
+---
+ src/network/networkd-link.c | 51 +
+ 1 file changed, 6 insertions(+), 45 deletions(-)
+
+diff --git a/src/network/networkd-link.c b/src/network/networkd-link.c
+index 042496173c..c49dba33da 100644
+--- a/src/network/networkd-link.c
b/src/network/networkd-link.c
+@@ -1940,6 +1940,9 @@ static int link_configure_addrgen_mode(Link *link) {
+
[OE-core] [PATCH] image.bbclass: Only append to IMAGE_LINK_NAME if it was already set
create_symlinks does not create any links if IMAGE_LINK_NAME is empty.
Unfortunately, setup_debugfs_variables unconditionally appends '-dbg' which
results in a previously-empty IMAGE_LINK_NAME containing just '-dbg'. Let's
check that it's not empty before appending.
Signed-off-by: Mike Crowe
---
meta/classes/image.bbclass | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index 7daa97effb..682858dc95 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -328,7 +328,8 @@ addtask do_image_qa_setscene
def setup_debugfs_variables(d):
d.appendVar('IMAGE_ROOTFS', '-dbg')
-d.appendVar('IMAGE_LINK_NAME', '-dbg')
+if d.getVar('IMAGE_LINK_NAME'):
+d.appendVar('IMAGE_LINK_NAME', '-dbg')
d.appendVar('IMAGE_NAME','-dbg')
d.setVar('IMAGE_BUILDING_DEBUGFS', 'true')
debugfs_image_fstypes = d.getVar('IMAGE_FSTYPES_DEBUGFS')
--
2.20.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] systemd-bootconf: Make is machine specific
Hi Richard
Something else that I need to fix on this patch?
Thanks!
On Wed, Jul 3, 2019 at 6:33 PM Ricardo Ribalda Delgado
wrote:
>
> Recipe makes use of the variable APPEND:
>
> do_configure[vardeps] += "APPEND"
>
> APPEND is usually linked to a to a machine and not to a
> cpu architecture, as it describe things like the location
> of the main serial port or tty.
>
> Therefore the recipe should be MACHINE_ARCH.
>
> This patch avoids multiconfig errors such as:
>
> | NOTE: Direct dependencies are
> ['multiconfig:qt5022:/workdir/repo/poky/meta/recipes-core/glibc/glibc_2.29.bb:do_populate_sysroot',
>
> 'multiconfig:qt5022:virtual:native:/workdir/repo/poky/meta/recipes-devtools/pseudo/pseudo_git.bb:do_populate_sysroot',
>
> 'multiconfig:qt5022:/workdir/repo/poky/meta/recipes-devtools/quilt/quilt-native_0.65.bb:do_populate_sysroot',
>
> 'multiconfig:qt5022:/workdir/repo/poky/meta/recipes-devtools/gcc/gcc-cross_8.3.bb:do_populate_sysroot',
>
> 'multiconfig:qt5022:/workdir/repo/poky/meta/recipes-devtools/gcc/gcc-runtime_8.3.bb:do_populate_sysroot']
> | NOTE: Installed into sysroot: []
> | NOTE: Skipping as already exists in sysroot: ['glibc', 'pseudo-native',
> 'quilt-native', 'gcc-cross-x86_64', 'gcc-runtime', 'libgcc',
> 'linux-libc-headers', 'libtool-native', 'texinfo-dummy-native',
> 'libmpc-native', 'flex-native', 'automake-native', 'zlib-native',
> 'mpfr-native', 'gmp-native', 'binutils-cross-x86_64', 'xz-native',
> 'autoconf-native', 'gnu-config-native', 'gettext-minimal-native', 'm4-native']
> | DEBUG: Python function extend_recipe_sysroot finished
> | DEBUG: Executing shell function do_install
> | install: cannot stat 'loader.conf': No such file or directory
> | WARNING: exit code 1 from a shell command.
> | ERROR: Function failed: do_install (log file is located at
> /workdir/build/tmp/work/bobcat-poky-linux/systemd-bootconf/1.00-r0/temp/log.do_install.737)
> NOTE: recipe systemd-bootconf-1.00-r0: task do_install: Failed
> ERROR: Task
> (multiconfig:qt5022:/workdir/repo/poky/meta/recipes-core/systemd/systemd-bootconf_1.00.bb:do_install)
> failed with exit code '1'
>
> Signed-off-by: Ricardo Ribalda Delgado
> ---
> meta/recipes-core/systemd/systemd-bootconf_1.00.bb | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/meta/recipes-core/systemd/systemd-bootconf_1.00.bb
> b/meta/recipes-core/systemd/systemd-bootconf_1.00.bb
> index e9c2466456..d13b8c518f 100644
> --- a/meta/recipes-core/systemd/systemd-bootconf_1.00.bb
> +++ b/meta/recipes-core/systemd/systemd-bootconf_1.00.bb
> @@ -3,6 +3,7 @@ LIC_FILES_CHKSUM =
> "file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384
> SUMMARY = "Basic systemd-boot configuration files"
>
> RPROVIDES_${PN} += "virtual/systemd-bootconf"
> +PACKAGE_ARCH = "${MACHINE_ARCH}"
>
> inherit systemd-boot-cfg
>
> --
> 2.20.1
>
--
Ricardo Ribalda
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
