Re: [OE-core] [PATCH] vte: upgrade 0.52.2 -> 0.56.1
On Fri, Apr 26, 2019 at 10:34 PM Richard Purdie wrote: > > Hi, > > On Wed, 2019-04-24 at 11:13 +0200, Andreas Müller wrote: > > * license: COPYING was replaced by > > COPYING.LGPL2/COPYING.LGPL3/COPYING.GPL3 > > * prettify recipe a bit > > > > Signed-off-by: Andreas Müller > > --- > > > > V1 -> V2: Fix build with musl > > I think something with vte-native is not working quite right with one > of these patches and is causing oe-selftest to fail: > > https://autobuilder.yoctoproject.org/typhoon/#/builders/56/builds/433 > > (oe-selftest -r runtime_test.TestImage.test_testimage_virgl_gtk) Will try to reproduce... Andreas -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] gnome-doc-utils: Remove stale patch
The recipe was removed 3 years ago. Signed-off-by: Adrian Bunk --- ...Update-AM_GLIB_GNU_GETTEXT-to-match-.patch | 40 --- 1 file changed, 40 deletions(-) delete mode 100644 meta/recipes-gnome/gnome/gnome-doc-utils/0001-glib-gettext.m4-Update-AM_GLIB_GNU_GETTEXT-to-match-.patch diff --git a/meta/recipes-gnome/gnome/gnome-doc-utils/0001-glib-gettext.m4-Update-AM_GLIB_GNU_GETTEXT-to-match-.patch b/meta/recipes-gnome/gnome/gnome-doc-utils/0001-glib-gettext.m4-Update-AM_GLIB_GNU_GETTEXT-to-match-.patch deleted file mode 100644 index 4cfcabd385..00 --- a/meta/recipes-gnome/gnome/gnome-doc-utils/0001-glib-gettext.m4-Update-AM_GLIB_GNU_GETTEXT-to-match-.patch +++ /dev/null @@ -1,40 +0,0 @@ -From 426e38468463a4abb495cf6a269b9635b2107519 Mon Sep 17 00:00:00 2001 -From: Jussi Kukkonen -Date: Tue, 17 May 2016 13:51:24 +0300 -Subject: [PATCH] glib-gettext.m4: Update AM_GLIB_GNU_GETTEXT to match glib - -This avoids - error: m4_copy: won't overwrite defined macro: glib_DEFUN - -Signed-off-by: Jussi Kukkonen -Upstream-Status: Inappropriate [No upstream] - m4/glib-gettext.m4 | 5 +++-- - 1 file changed, 3 insertions(+), 2 deletions(-) - -diff --git a/m4/glib-gettext.m4 b/m4/glib-gettext.m4 -index 81f8fd2..e2b142b 100644 a/m4/glib-gettext.m4 -+++ b/m4/glib-gettext.m4 -@@ -310,7 +310,7 @@ msgstr "" - # on various variables needed by the Makefile.in.in installed by - # glib-gettextize. - dnl --glib_DEFUN([GLIB_GNU_GETTEXT], -+AU_DEFUN([GLIB_GNU_GETTEXT], - [AC_REQUIRE([AC_PROG_CC])dnl -AC_REQUIRE([AC_HEADER_STDC])dnl - -@@ -381,7 +381,8 @@ glib_DEFUN([GLIB_GNU_GETTEXT], -rm -f po/POTFILES -sed -e "/^#/d" -e "/^\$/d" -e "s,.*, $posrcprefix& ," -e "\$s/\(.*\) /\1/" \ - < $srcdir/po/POTFILES.in > po/POTFILES -- ]) -+ ] -+ [[$0: This macro is deprecated. You should use upstream gettext instead.]]) - - # AX_GLIB_DEFINE_LOCALEDIR(VARIABLE) - # --- --- -2.1.4 - -- 2.17.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] vte: upgrade 0.52.2 -> 0.56.1
Hi, On Wed, 2019-04-24 at 11:13 +0200, Andreas Müller wrote: > * license: COPYING was replaced by > COPYING.LGPL2/COPYING.LGPL3/COPYING.GPL3 > * prettify recipe a bit > > Signed-off-by: Andreas Müller > --- > > V1 -> V2: Fix build with musl I think something with vte-native is not working quite right with one of these patches and is causing oe-selftest to fail: https://autobuilder.yoctoproject.org/typhoon/#/builders/56/builds/433 (oe-selftest -r runtime_test.TestImage.test_testimage_virgl_gtk) Cheers, Richard -- ___ 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 Fri, Apr 26, 2019 at 6:40 AM wrote: > > On Thu, 2019-04-25 at 11:24 -0700, Alistair Francis wrote: > > 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 > > > Thanks, this worked better in testing but showed issues with qemuarm > booting: > > https://autobuilder.yoctoproject.org/typhoon/#/builders/53/builds/535 > > https://autobuilder.yoctoproject.org/typhoon/#/builders/47/builds/549 I can't reproduce this failure to start (build 549) with my QEMU 4.0 patch applied on master. I also can't reproduce the ping test failure in build 535. I do see SSH failures, but I think that's more related to my TAP set-up (which has never seemed to work correctly) more then anything else. Is it possible to get more details from the failures? Alistair > > I took it out of -next again and those passed (but some of the other > build failures also in that build remained) > > 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/26/19 10:50 AM, Adrian Bunk wrote: > On Fri, Apr 26, 2019 at 10:31:03AM -0500, Mark Hatle wrote: >> On 4/26/19 12:12 AM, Adrian Bunk wrote: >>> 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? >> >> -In- OE? I have no idea. >> >> Outside of OE to meet the OpenSSL-FIPS 'you must not modify the sources and >> follow these exact steps', yes people are. >> ... > > Why does this need OpenSSL 1.0 in Yocto? I think you are misunderstanding what I am saying. For the recipes that -use- OpenSSL, we still need support for the legacy API through at least the end of the year. In the past we had added pkgconfigs for a few things to switch them between the old and new OpenSSL API. The OpenSSL10 recipe I don't care about, I have no use for it. > How does this look as OE recipe? > > I would say that an OpenSSL-FIPS recipe might now perhaps need an > openssl_1.1.1%.bbappend re-adding the three openssl-conf lines my > patch removes. You can't.. There is no such thing as OpenSSL-FIPS for 1.1.x. Doesn't exist, never will. OpenSSL 1.0.2* has an OpenSSL-FIPS module.. They have to be compiled -exactly- as stated in the documentation or they are not functionally equivalent.. (reality doesn't matter here -- it's the rules that matter.) So after it's built (usually via an SDK), then it's packaged in a recipe that uses the precompiled binary. OpenSSL 3 (there won't be a 2 from my understanding) is supposed to be compatible with the 1.1.x API (for the most part), but will include FIPS-140-2 support. However, OpenSSL 3 doesn't exist yet. The last blog from the OpenSSL developers indicated end of 2019... but as we all know release dates change. So for users who have an OpenSSL FIPS requirement, the ONLY answer is that their applications (including system) HAVE to use the OpenSSL 1.0.2* + FIPS module. --Mark > Do I miss anything more complicated here? > >> --Mark > > cu > Adrian > -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] systemd: add cgroupv2 PACKAGECONFIG
From: Luca Boccassi Allow users to change the default cgroup mode at build time and use the unified hierarchy mode. Disabled by default - hybrid is the default upstream value. Signed-off-by: Luca Boccassi --- meta/recipes-core/systemd/systemd_242.bb | 1 + 1 file changed, 1 insertion(+) diff --git a/meta/recipes-core/systemd/systemd_242.bb b/meta/recipes-core/systemd/systemd_242.bb index a559fa0d75..33d3e0b000 100644 --- a/meta/recipes-core/systemd/systemd_242.bb +++ b/meta/recipes-core/systemd/systemd_242.bb @@ -115,6 +115,7 @@ PACKAGECONFIG[audit] = "-Daudit=true,-Daudit=false,audit" PACKAGECONFIG[backlight] = "-Dbacklight=true,-Dbacklight=false" PACKAGECONFIG[binfmt] = "-Dbinfmt=true,-Dbinfmt=false" PACKAGECONFIG[bzip2] = "-Dbzip2=true,-Dbzip2=false,bzip2" +PACKAGECONFIG[cgroupv2] = "-Ddefault-hierarchy=unified,-Ddefault-hierarchy=hybrid" PACKAGECONFIG[coredump] = "-Dcoredump=true,-Dcoredump=false" PACKAGECONFIG[cryptsetup] = "-Dlibcryptsetup=true,-Dlibcryptsetup=false,cryptsetup" PACKAGECONFIG[dbus] = "-Ddbus=true,-Ddbus=false,dbus" -- 2.20.1 -- ___ 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 Fri, Apr 26, 2019 at 10:31:03AM -0500, Mark Hatle wrote: > On 4/26/19 12:12 AM, Adrian Bunk wrote: > > 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? > > -In- OE? I have no idea. > > Outside of OE to meet the OpenSSL-FIPS 'you must not modify the sources and > follow these exact steps', yes people are. >... Why does this need OpenSSL 1.0 in Yocto? How does this look as OE recipe? I would say that an OpenSSL-FIPS recipe might now perhaps need an openssl_1.1.1%.bbappend re-adding the three openssl-conf lines my patch removes. Do I miss anything more complicated here? > --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
Re: [OE-core] [PATCH] systemd: upgrade to 242
On Fri, Apr 26, 2019 at 3:45 PM Jonas Bonn wrote: > > Hi Alex, > > On 26/04/2019 16:14, Alex Kiernan wrote: > > On Thu, Apr 18, 2019 at 11:22 AM Andrej Valek > > wrote: > >> > >> PATCH REBASED: > >> == > >> 0001-do-not-disable-buffer-in-writing-files.patch > >> 0002-don-t-use-glibc-specific-qsort_r.patch > >> 0003-missing_type.h-add-__compare_fn_t-and-comparison_fn_.patch > >> 0004-add-fallback-parse_printf_format-implementation.patch > >> 0005-rules-watch-metadata-changes-in-ide-devices.patch > >> 0005-src-basic-missing.h-check-for-missing-strndupa.patch > >> 0007-don-t-fail-if-GLOB_BRACE-and-GLOB_ALTDIRFUNC-is-not.patch > >> 0009-socket-util-don-t-fail-if-libc-doesn-t-support-IDN.patch > >> 0017-Do-not-disable-buffering-when-writing-to-oom_score_a.patch > >> 0021-avoid-redefinition-of-prctl_mm_map-structure.patch > >> 0024-test-json.c-define-M_PIl.patch > >> > >> PATCH DROPPED: > >> == > >> 0001-meson-declare-version.h-as-dep-for-various-targets-t.patch > >> 0001-meson-declare-version.h-as-dependency-for-systemd.patch > >> 0013-test-hexdecoct.c-Include-missing.h-for-strndupa.patch > >> > >> PATCH ADDED: > >> 0025-fs-utilh-add-missing-sys-stat-include.patch > >> > >> Signed-off-by: Andrej Valek > >> --- > > > > This change in 242 means I'm no longer getting network up after > > flashing a new image (I'm flashing the entire eMMC from an image): > > > > * During package installation (with `ninja install`), we would create > > symlinks for systemd-networkd.service, systemd-networkd.socket, > > systemd-resolved.service, remote-cryptsetup.target, remote-fs.target, > > systemd-networkd-wait-online.service, and systemd-timesyncd.service > > in /etc, as if `systemctl enable` was called for those units, to make > > the system usable immediately after installation. Now this is not > > done anymore, and instead calling `systemctl preset-all` is > > recommended after the first installation of systemd. > > > > I don't know if Jonas is still working on this series: > > > > https://patchwork.openembedded.org/series/15497/ > > I haven't given up on it, but I had to put it aside for a bit due to > more pressing matters. > Don't we all end up in those kind of problems! > > > > as that looks like it has the kind of machinery we need (though I > > don't think this problem is specific to read only rootfs now) - I'm > > looking at the series in case he's not. > > If you have a writable root, systemd will automatically do the > preset-all for you; the catch is, systemd only does this if > /etc/machine-id does not exist. Ah... that's useful information that I didn't know. Whilst I do have a writeable /etc, I'm running under OSTree, so I don't want /etc mutated in the normal use case as I want to ensure that changes in /etc are correctly propagated across upgrades (OSTree does a three way merge of /etc using the current /etc and what was shipped as defaults in the previous deployment and the new deployment). > OE forces an empty /etc/machine-id onto > all root images so this doesn't work; as such, you'll need to do the > preset-all magic manually for ALL filesystems irregardless of whether > they are read-only or not. > > A better solution is drop the /etc/machine-id and let systemd create > that automatically; then it will also do the automatic preset-all at > first-boot. The problem here is that the OE build farm detects images > that stall at boot when /etc/machine-id isn't present; I wasn't able to > find the cause of this but that's where you should be looking if you > want to pursue this patch series. Aside from that little glitch, I > think the rest of it is fine. > Thanks, I'll see if I can chase that one down. > And getting this working is also a big step towards making "stateless" > systems (using the systemd terminology) work where /etc may be a tmpfs > and gets populated at boot. > Yeah, that's something I'd like to get to. -- Alex Kiernan -- ___ 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/26/19 12:12 AM, Adrian Bunk wrote: > 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? -In- OE? I have no idea. Outside of OE to meet the OpenSSL-FIPS 'you must not modify the sources and follow these exact steps', yes people are. > 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. Yes, and thats the problem. OpenSSL 1.1 will not have FIPS support before the end of the year (based on the last blog post..) So unless the OpenSSL community is able to get it certified and released before YP 2.8, I believe we still need OpenSSL 10 support through the end of this year. We should evaluate where the community is after that. Again, I'm not talking about the 'OpenSSL10' recipe, but support in the applications for the older APIs. I don't care if the OpenSSL10 recipe goes away. Anyone using FIPS-140-2 support is going to want to use a single OpenSSL library on their system, not both 1.1 and 1.0. --Mark >> --Mark > > cu > Adrian > -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [master][RFC v2] Adding back wrapper and using OEPYTHON3HOME variable for python3
Adding back the python wrapper and adding a patch to use OEPYTHON3HOME
instead of PYTHONHOME if set, for python3.
If we add back the wrapper as is, we would see the following error that
we also see in Thud:
ImportError: No module named site
OpenEmbedded requires 'python' to be python v2 (>= 2.7.3), not python
v3.
Please upgrade your python v2
This is because python3 would've set PYTHONHOME to use nativesdk
python3 libraries but when the oe-buildenv-internal script tries to call
python2 for the py_v27_check, there will be no python2 libraries in the
PYTHONHOME directory.
In other words, bitbake needs host python2 and the env variable set from
the wrapper contaminates the env and host python2 won't be able to find
its libraries
Creating another variable OEPYTHON3HOME and using this in the python3
wrapper to allow for a way to set a different paths for python3 and
python2
[YOCTO #13208]
Signed-off-by: Jaewon Lee
Signed-off-by: Alejandro Enedino Hernandez Samaniego
---
...EPYTHON3HOME-is-set-use-instead-of-PYTHON.patch | 47 ++
meta/recipes-devtools/python/python3_3.7.3.bb | 7
2 files changed, 54 insertions(+)
create mode 100644
meta/recipes-devtools/python/python3/0001-main.c-if-OEPYTHON3HOME-is-set-use-instead-of-PYTHON.patch
diff --git
a/meta/recipes-devtools/python/python3/0001-main.c-if-OEPYTHON3HOME-is-set-use-instead-of-PYTHON.patch
b/meta/recipes-devtools/python/python3/0001-main.c-if-OEPYTHON3HOME-is-set-use-instead-of-PYTHON.patch
new file mode 100644
index 000..5a59a67
--- /dev/null
+++
b/meta/recipes-devtools/python/python3/0001-main.c-if-OEPYTHON3HOME-is-set-use-instead-of-PYTHON.patch
@@ -0,0 +1,47 @@
+From 347e5e080f5bbd2e18562d5f99ec61d706cb1cd8 Mon Sep 17 00:00:00 2001
+From: Jaewon Lee
+Date: Thu, 25 Apr 2019 15:34:26 -0700
+Subject: [PATCH] main.c: if OEPYTHON3HOME is set use instead of PYTHONHOME
+
+There is one variable PYTHONHOME to determine where libraries are coming
+from for both python2 and python3. This becomes an issue if only one has
+libraries in the specified PYTHONHOME path, but they are using the same
+PYTHONHOME. Creating another variable OEPYTHON3HOME to allow for a way
+to set a different path for python3
+
+Signed-off-by: Jaewon Lee
+---
+ Modules/main.c | 17 +
+ 1 file changed, 13 insertions(+), 4 deletions(-)
+
+diff --git a/Modules/main.c b/Modules/main.c
+index a745381..27ce112 100644
+--- a/Modules/main.c
b/Modules/main.c
+@@ -1855,10 +1855,19 @@ config_init_home(_PyCoreConfig *config)
+ }
+ return _Py_INIT_OK();
+ }
+-
+-int res = config_get_env_var_dup(, L"PYTHONHOME", "PYTHONHOME");
+-if (res < 0) {
+-return DECODE_LOCALE_ERR("PYTHONHOME", res);
++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);
++}
+ }
+ config->home = home;
+ return _Py_INIT_OK();
+--
+2.7.4
+
diff --git a/meta/recipes-devtools/python/python3_3.7.3.bb
b/meta/recipes-devtools/python/python3_3.7.3.bb
index ea46b05..af7ede1 100644
--- a/meta/recipes-devtools/python/python3_3.7.3.bb
+++ b/meta/recipes-devtools/python/python3_3.7.3.bb
@@ -28,6 +28,9 @@ SRC_URI_append_class-native = " \
file://0001-distutils-sysconfig-append-STAGING_LIBDIR-python-sys.patch \
file://12-distutils-prefix-is-inside-staging-area.patch \
"
+SRC_URI_append_class-nativesdk = " \
+
file://0001-main.c-if-OEPYTHON3HOME-is-set-use-instead-of-PYTHON.patch \
+ "
SRC_URI[md5sum] = "93df27aec0cd18d6d42173e601ffbbfd"
SRC_URI[sha256sum] =
"da60b54064d4cfcd9c26576f6df2690e62085123826cff2e667e72a91952d318"
@@ -131,6 +134,10 @@ do_install_append() {
${D}${libdir}/python-sysconfigdata/_sysconfigdata.py
}
+do_install_append_class-nativesdk () {
+create_wrapper ${D}${bindir}/python${PYTHON_MAJMIN}
OEPYTHON3HOME='${prefix}'
TERMINFO_DIRS='${sysconfdir}/terminfo:/etc/terminfo:/usr/share/terminfo:/usr/share/misc/terminfo:/lib/terminfo'
PYTHONNOUSERSITE='1'
+}
+
SSTATE_SCAN_FILES += "Makefile _sysconfigdata.py"
PACKAGE_PREPROCESS_FUNCS += "py_package_preprocess"
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/3] linux-yocto/5.0: port RAID configuration tweaks from master
From: Bruce Ashfield
Porting the following three RAID config changes from master to
the 5.0 branch:
ffd8cf5baf8 intel-x86: add Intel VMD support
8edf951a15c cfg/efi.cfg: built-in CONFIG_EFIVAR_FS to support Intel VROC
041a6c04244 intel-x86: built-in nvme driver to support boot from nvme disk
Signed-off-by: Bruce Ashfield
---
meta/recipes-kernel/linux/linux-yocto-rt_5.0.bb | 2 +-
meta/recipes-kernel/linux/linux-yocto-tiny_5.0.bb | 2 +-
meta/recipes-kernel/linux/linux-yocto_5.0.bb | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_5.0.bb
b/meta/recipes-kernel/linux/linux-yocto-rt_5.0.bb
index 842aa5b93f..07fa910ee8 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_5.0.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_5.0.bb
@@ -12,7 +12,7 @@ python () {
}
SRCREV_machine ?= "04585fb29f99725a27acb96fc25efa0a55a62a8a"
-SRCREV_meta ?= "7477b32eaf608884be5664fadd79331b39afaaa6"
+SRCREV_meta ?= "ffd8cf5baf8e741b8987b72c942ce3b9cc7c7f30"
SRC_URI =
"git://git.yoctoproject.org/linux-yocto.git;branch=${KBRANCH};name=machine \
git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-5.0;destsuffix=${KMETA}"
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_5.0.bb
b/meta/recipes-kernel/linux/linux-yocto-tiny_5.0.bb
index eba6cc6f47..c1084f2bb9 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_5.0.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_5.0.bb
@@ -17,7 +17,7 @@ KCONF_BSP_AUDIT_LEVEL = "2"
SRCREV_machine_qemuarm ?= "e265300362d7004e3b57bb5cbcfc65fb469b9ce9"
SRCREV_machine ?= "9c40ed0d86ad87f48659aad4fdead2455e8b5db8"
-SRCREV_meta ?= "7477b32eaf608884be5664fadd79331b39afaaa6"
+SRCREV_meta ?= "ffd8cf5baf8e741b8987b72c942ce3b9cc7c7f30"
PV = "${LINUX_VERSION}+git${SRCPV}"
diff --git a/meta/recipes-kernel/linux/linux-yocto_5.0.bb
b/meta/recipes-kernel/linux/linux-yocto_5.0.bb
index fe773bed98..01269dda27 100644
--- a/meta/recipes-kernel/linux/linux-yocto_5.0.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_5.0.bb
@@ -19,7 +19,7 @@ SRCREV_machine_qemux86 ?=
"9c40ed0d86ad87f48659aad4fdead2455e8b5db8"
SRCREV_machine_qemux86-64 ?= "9c40ed0d86ad87f48659aad4fdead2455e8b5db8"
SRCREV_machine_qemumips64 ?= "437d99225c689f3f192bb834e4d649ea0467ac87"
SRCREV_machine ?= "9c40ed0d86ad87f48659aad4fdead2455e8b5db8"
-SRCREV_meta ?= "7477b32eaf608884be5664fadd79331b39afaaa6"
+SRCREV_meta ?= "ffd8cf5baf8e741b8987b72c942ce3b9cc7c7f30"
# remap qemuarm to qemuarma15 for the 5.0 kernel
# KMACHINE_qemuarm ?= "qemuarma15"
--
2.19.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/3] linux-yocto-rt/4.19: fix merge conflict in lru_drain
From: Bruce Ashfield
Paul Gortmaker sent along the following fixup for 4.19-rt:
[
Author: Paul Gortmaker
Date: Mon Apr 15 12:01:31 2019 -0400
Revert "mm: handle lru_add_drain_all for UP properly"
This reverts commit e6e9d6e290028b0a6b83b563fad9fafa7f1d515e.
It was a 4.19.31 backport of commit 6ea183d60c46 ("mm: handle
lru_add_drain_all for UP properly"). In summary, what that did
was to fix a possible harmless WARN_ON on non-SMP, introduced at
commit 4d43d395fed1 ("workqueue: Try to catch flush_work() without
INIT_WORK().") by adding non-SMP variants of lru functions.
The combination of that, with the -rt commit 473f14a9f234 ("mm:
perform lru_add_drain_all() remotely") at the merge of the two
results in the following build failure:
mm/swap.c:736:2: error: #endif without #if
since the -rt change wants RT specific lru and the stable backport
wants non-SMP specific lru, and a chunk of the backport with
an #ifdef CONFIG_SMP is missing.
However, before we add a four way cluster of ifdeffery to handle all
cases, we note 4d43d395fed1 was added to the v5.1 release, and it
was not (currently) backported to any 4.19.x stable release - so it is
unclear to me why this commit was ever backported to 4.19.31 at all.
Further, we note this change was to mm/swap.c -- and by definition,
any preempt-rt deployment that uses swap for anything other than a
failure contingency mitigation is broken by design.
Given all that, I decided that the best path forward was to revert
the two of the three chunks of the backport that remain in the -rt
branch, and return us to the pre-4.19.31 merge behaviour for -rt.
Signed-off-by: Paul Gortmaker
]
Signed-off-by: Paul Gortmaker
Signed-off-by: Bruce Ashfield
---
meta/recipes-kernel/linux/linux-yocto-rt_4.19.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_4.19.bb
b/meta/recipes-kernel/linux/linux-yocto-rt_4.19.bb
index cdba9d210a..834b8fc03c 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_4.19.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_4.19.bb
@@ -11,7 +11,7 @@ python () {
raise bb.parse.SkipRecipe("Set PREFERRED_PROVIDER_virtual/kernel to
linux-yocto-rt to enable it")
}
-SRCREV_machine ?= "b0ea9ef736c8ab8695bdfba61cd121ce5aa47e49"
+SRCREV_machine ?= "c279a81f1e654023c4cc78afa9f14350ee5f836f"
SRCREV_meta ?= "9bda6190bfc9e7858c2f7588109a0ec966f37a09"
SRC_URI =
"git://git.yoctoproject.org/linux-yocto.git;branch=${KBRANCH};name=machine \
--
2.19.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 3/3] linux-yocto/5.0: integrate TCP timeout / hang fix
From: Bruce Ashfield
Integrating the following fix:
[
tcp: fix issues relaed to implement coalescing on backlog queue
As was discussed on -netdev, there's an issue with TCP timeouts and
hangs due to new features introduced in the 5.0 kernel:
https://www.spinics.net/lists/netdev/msg562928.html
This is a temporary commit to widely test the proposed solution. It
will be dropped when an official patch makes mainline.
]
Signed-off-by: Bruce Ashfield
---
.../recipes-kernel/linux/linux-yocto-rt_5.0.bb | 4 ++--
.../linux/linux-yocto-tiny_5.0.bb | 6 +++---
meta/recipes-kernel/linux/linux-yocto_5.0.bb | 18 +-
3 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_5.0.bb
b/meta/recipes-kernel/linux/linux-yocto-rt_5.0.bb
index 07fa910ee8..ef3f0a0e1b 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_5.0.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_5.0.bb
@@ -11,8 +11,8 @@ python () {
raise bb.parse.SkipRecipe("Set PREFERRED_PROVIDER_virtual/kernel to
linux-yocto-rt to enable it")
}
-SRCREV_machine ?= "04585fb29f99725a27acb96fc25efa0a55a62a8a"
-SRCREV_meta ?= "ffd8cf5baf8e741b8987b72c942ce3b9cc7c7f30"
+SRCREV_machine ?= "a3309af7ab77156bd8d731df3a97126d3d897916"
+SRCREV_meta ?= "2d838e11b084a96dd70e5cc0fec01d2e492f72c3"
SRC_URI =
"git://git.yoctoproject.org/linux-yocto.git;branch=${KBRANCH};name=machine \
git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-5.0;destsuffix=${KMETA}"
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_5.0.bb
b/meta/recipes-kernel/linux/linux-yocto-tiny_5.0.bb
index c1084f2bb9..206e6c348d 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_5.0.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_5.0.bb
@@ -15,9 +15,9 @@ DEPENDS += "openssl-native util-linux-native"
KMETA = "kernel-meta"
KCONF_BSP_AUDIT_LEVEL = "2"
-SRCREV_machine_qemuarm ?= "e265300362d7004e3b57bb5cbcfc65fb469b9ce9"
-SRCREV_machine ?= "9c40ed0d86ad87f48659aad4fdead2455e8b5db8"
-SRCREV_meta ?= "ffd8cf5baf8e741b8987b72c942ce3b9cc7c7f30"
+SRCREV_machine_qemuarm ?= "d905ae925fc4a60d63f45e1922163da683d8a3bc"
+SRCREV_machine ?= "14b6c1fc020fa357245e9ac9c6c69d253bc7ce30"
+SRCREV_meta ?= "2d838e11b084a96dd70e5cc0fec01d2e492f72c3"
PV = "${LINUX_VERSION}+git${SRCPV}"
diff --git a/meta/recipes-kernel/linux/linux-yocto_5.0.bb
b/meta/recipes-kernel/linux/linux-yocto_5.0.bb
index 01269dda27..f34cc7b9db 100644
--- a/meta/recipes-kernel/linux/linux-yocto_5.0.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_5.0.bb
@@ -11,15 +11,15 @@ KBRANCH_qemux86 ?= "v5.0/standard/base"
KBRANCH_qemux86-64 ?= "v5.0/standard/base"
KBRANCH_qemumips64 ?= "v5.0/standard/mti-malta64"
-SRCREV_machine_qemuarm ?= "ed9d11e2c8ebbfe056420cb89c2e5d02836496ce"
-SRCREV_machine_qemuarm64 ?= "9c40ed0d86ad87f48659aad4fdead2455e8b5db8"
-SRCREV_machine_qemumips ?= "40a729c3b0683d0875f8d6ad7353e6e429c7afc2"
-SRCREV_machine_qemuppc ?= "9c40ed0d86ad87f48659aad4fdead2455e8b5db8"
-SRCREV_machine_qemux86 ?= "9c40ed0d86ad87f48659aad4fdead2455e8b5db8"
-SRCREV_machine_qemux86-64 ?= "9c40ed0d86ad87f48659aad4fdead2455e8b5db8"
-SRCREV_machine_qemumips64 ?= "437d99225c689f3f192bb834e4d649ea0467ac87"
-SRCREV_machine ?= "9c40ed0d86ad87f48659aad4fdead2455e8b5db8"
-SRCREV_meta ?= "ffd8cf5baf8e741b8987b72c942ce3b9cc7c7f30"
+SRCREV_machine_qemuarm ?= "17c4b7e9db4d17aa713c85d0c3d2d84af962864a"
+SRCREV_machine_qemuarm64 ?= "14b6c1fc020fa357245e9ac9c6c69d253bc7ce30"
+SRCREV_machine_qemumips ?= "e5c23fb31438dab373a50afc40f6e4ab0c568485"
+SRCREV_machine_qemuppc ?= "14b6c1fc020fa357245e9ac9c6c69d253bc7ce30"
+SRCREV_machine_qemux86 ?= "14b6c1fc020fa357245e9ac9c6c69d253bc7ce30"
+SRCREV_machine_qemux86-64 ?= "14b6c1fc020fa357245e9ac9c6c69d253bc7ce30"
+SRCREV_machine_qemumips64 ?= "743d799797ad6828472087e1da8c67fdab87bf75"
+SRCREV_machine ?= "14b6c1fc020fa357245e9ac9c6c69d253bc7ce30"
+SRCREV_meta ?= "2d838e11b084a96dd70e5cc0fec01d2e492f72c3"
# remap qemuarm to qemuarma15 for the 5.0 kernel
# KMACHINE_qemuarm ?= "qemuarma15"
--
2.19.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/3] linux-yocto: (small) consolidated pull request
From: Bruce Ashfield Richard, This pull request is really about the TCP fix that we need for the ptest timeouts / hangs that you were seeing. I also had one config tweak, and a -rt cleanup that are worth merging as well. Cheers, Bruce The following changes since commit 244cbcce0ecc4691a9ddfb0a44dc487ff7af0670: utils/multiprocess_launch: Improve failing subprocess output (2019-04-26 10:09:08 +0100) are available in the Git repository at: git://git.pokylinux.org/poky-contrib zedd/kernel http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=zedd/kernel Bruce Ashfield (3): linux-yocto-rt/4.19: fix merge conflict in lru_drain linux-yocto/5.0: port RAID configuration tweaks from master linux-yocto/5.0: integrate TCP timeout / hang fix .../linux/linux-yocto-rt_4.19.bb | 2 +- .../recipes-kernel/linux/linux-yocto-rt_5.0.bb | 4 ++-- .../linux/linux-yocto-tiny_5.0.bb | 6 +++--- meta/recipes-kernel/linux/linux-yocto_5.0.bb | 18 +- 4 files changed, 15 insertions(+), 15 deletions(-) -- 2.19.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] systemd: upgrade to 242
Hi Alex,
On 26/04/2019 16:14, Alex Kiernan wrote:
On Thu, Apr 18, 2019 at 11:22 AM Andrej Valek wrote:
PATCH REBASED:
==
0001-do-not-disable-buffer-in-writing-files.patch
0002-don-t-use-glibc-specific-qsort_r.patch
0003-missing_type.h-add-__compare_fn_t-and-comparison_fn_.patch
0004-add-fallback-parse_printf_format-implementation.patch
0005-rules-watch-metadata-changes-in-ide-devices.patch
0005-src-basic-missing.h-check-for-missing-strndupa.patch
0007-don-t-fail-if-GLOB_BRACE-and-GLOB_ALTDIRFUNC-is-not.patch
0009-socket-util-don-t-fail-if-libc-doesn-t-support-IDN.patch
0017-Do-not-disable-buffering-when-writing-to-oom_score_a.patch
0021-avoid-redefinition-of-prctl_mm_map-structure.patch
0024-test-json.c-define-M_PIl.patch
PATCH DROPPED:
==
0001-meson-declare-version.h-as-dep-for-various-targets-t.patch
0001-meson-declare-version.h-as-dependency-for-systemd.patch
0013-test-hexdecoct.c-Include-missing.h-for-strndupa.patch
PATCH ADDED:
0025-fs-utilh-add-missing-sys-stat-include.patch
Signed-off-by: Andrej Valek
---
This change in 242 means I'm no longer getting network up after
flashing a new image (I'm flashing the entire eMMC from an image):
* During package installation (with `ninja install`), we would create
symlinks for systemd-networkd.service, systemd-networkd.socket,
systemd-resolved.service, remote-cryptsetup.target, remote-fs.target,
systemd-networkd-wait-online.service, and systemd-timesyncd.service
in /etc, as if `systemctl enable` was called for those units, to make
the system usable immediately after installation. Now this is not
done anymore, and instead calling `systemctl preset-all` is
recommended after the first installation of systemd.
I don't know if Jonas is still working on this series:
https://patchwork.openembedded.org/series/15497/
I haven't given up on it, but I had to put it aside for a bit due to
more pressing matters.
as that looks like it has the kind of machinery we need (though I
don't think this problem is specific to read only rootfs now) - I'm
looking at the series in case he's not.
If you have a writable root, systemd will automatically do the
preset-all for you; the catch is, systemd only does this if
/etc/machine-id does not exist. OE forces an empty /etc/machine-id onto
all root images so this doesn't work; as such, you'll need to do the
preset-all magic manually for ALL filesystems irregardless of whether
they are read-only or not.
A better solution is drop the /etc/machine-id and let systemd create
that automatically; then it will also do the automatic preset-all at
first-boot. The problem here is that the OE build farm detects images
that stall at boot when /etc/machine-id isn't present; I wasn't able to
find the cause of this but that's where you should be looking if you
want to pursue this patch series. Aside from that little glitch, I
think the rest of it is fine.
And getting this working is also a big step towards making "stateless"
systems (using the systemd terminology) work where /etc may be a tmpfs
and gets populated at boot.
/Jonas
The quick-hack fix is to revert 01d2041e41f4 ("meson: stop creating
enablement symlinks in /etc during installation"), but clearly that's
not sustainable.
--
Alex Kiernan
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] QA cycle report for 2.7 RC2
Sangeeta, On 4/25/19 11:27 PM, Jain, Sangeeta wrote: > > > > QA cycle reportfor 2.7 RC2: > > > > 1. No high milestone defects. > 2. Test results are available at following location: > > · For results of all automated tests, please refer to results > at public AB [1]. > > · For other test results, refer to attachment [2]. > > · For test report for test cases run by Intel and WR team, > refer attachment [3] > Since "compliance-test.compliance-test.LSB_subset_test_suite" was run, can you share the changes made to /opt/lsb-test/session file? || Can I get clarification on how "compliance-test.compliance-test.stress_test_-_ltp_-Beaglebone" was run? Regards, Armin > > · For full test report, refer attachment [4] > > 3. No new defects are found in this cycle. > 4. No existing issues observed in this release > 5. No ptests are failing in this release which were passing in > previous release. No timeout issues. > > > > QA Hint: One failure was observed on public AB: > > > > testseries | result_id : qemuppc | > oeselftest_centos-7_qemuppc_20190414221329 > > runqemu.QemuTest.test_qemu_can_shutdown > > > > No bug filed for this issue, as it appears to be an intermittent > failure and worked on rc1 test run. > > > > === Links > > > > *Link to testresults:* > > > > [1] - https://autobuilder.yocto.io/pub/releases/yocto-2.7.rc2/testresults/ > > > > [2] - 2.7_RC2_results_merged.zip > > > > [3] - 2.7_ rc2_intel_wr_merged_report > > > > [4] – 2.7 _rc2_full_report > > > > Thanks & Regards, > > Sangeeta Jain > > > > -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [sumo][PATCH] Package sha1 and md5 in python3-crypt
---
meta/recipes-devtools/python/python3/python3-manifest.json | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/recipes-devtools/python/python3/python3-manifest.json
b/meta/recipes-devtools/python/python3/python3-manifest.json
index 2491f36..b5a6e4e 100644
--- a/meta/recipes-devtools/python/python3/python3-manifest.json
+++ b/meta/recipes-devtools/python/python3/python3-manifest.json
@@ -312,6 +312,8 @@
"${libdir}/python3.5/hashlib.py",
"${libdir}/python3.5/lib-dynload/_crypt.*.so",
"${libdir}/python3.5/lib-dynload/_hashlib.*.so",
+"${libdir}/python3.5/lib-dynload/_md5.*.so",
+"${libdir}/python3.5/lib-dynload/_sha1.*.so",
"${libdir}/python3.5/lib-dynload/_sha256.*.so",
"${libdir}/python3.5/lib-dynload/_sha512.*.so"
],
--
1.8.3.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] systemd: upgrade to 242
On Thu, Apr 18, 2019 at 11:22 AM Andrej Valek wrote:
>
> PATCH REBASED:
> ==
> 0001-do-not-disable-buffer-in-writing-files.patch
> 0002-don-t-use-glibc-specific-qsort_r.patch
> 0003-missing_type.h-add-__compare_fn_t-and-comparison_fn_.patch
> 0004-add-fallback-parse_printf_format-implementation.patch
> 0005-rules-watch-metadata-changes-in-ide-devices.patch
> 0005-src-basic-missing.h-check-for-missing-strndupa.patch
> 0007-don-t-fail-if-GLOB_BRACE-and-GLOB_ALTDIRFUNC-is-not.patch
> 0009-socket-util-don-t-fail-if-libc-doesn-t-support-IDN.patch
> 0017-Do-not-disable-buffering-when-writing-to-oom_score_a.patch
> 0021-avoid-redefinition-of-prctl_mm_map-structure.patch
> 0024-test-json.c-define-M_PIl.patch
>
> PATCH DROPPED:
> ==
> 0001-meson-declare-version.h-as-dep-for-various-targets-t.patch
> 0001-meson-declare-version.h-as-dependency-for-systemd.patch
> 0013-test-hexdecoct.c-Include-missing.h-for-strndupa.patch
>
> PATCH ADDED:
> 0025-fs-utilh-add-missing-sys-stat-include.patch
>
> Signed-off-by: Andrej Valek
> ---
This change in 242 means I'm no longer getting network up after
flashing a new image (I'm flashing the entire eMMC from an image):
* During package installation (with `ninja install`), we would create
symlinks for systemd-networkd.service, systemd-networkd.socket,
systemd-resolved.service, remote-cryptsetup.target, remote-fs.target,
systemd-networkd-wait-online.service, and systemd-timesyncd.service
in /etc, as if `systemctl enable` was called for those units, to make
the system usable immediately after installation. Now this is not
done anymore, and instead calling `systemctl preset-all` is
recommended after the first installation of systemd.
I don't know if Jonas is still working on this series:
https://patchwork.openembedded.org/series/15497/
as that looks like it has the kind of machinery we need (though I
don't think this problem is specific to read only rootfs now) - I'm
looking at the series in case he's not.
The quick-hack fix is to revert 01d2041e41f4 ("meson: stop creating
enablement symlinks in /etc during installation"), but clearly that's
not sustainable.
--
Alex Kiernan
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC, v5] mesa: Convert recipe to use meson build system
On Fri, 2019-04-26 at 14:55 +0100, Richard Purdie wrote: > On Thu, 2019-04-25 at 10:55 -0300, Fabio Berton wrote: > > - 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 > > I think this breaks musl at runtime: > > https://autobuilder.yoctoproject.org/typhoon/#/builders/64/builds/538/steps/7/logs/step1c > > Specifically: > > [ 5.224] (EE) Failed to load > /usr/lib/xorg/modules/extensions/libglx.so: Error relocating > /usr/lib/libGL.so.1: alphasort: initial-exec TLS resolves to dynamic > definition in /usr/lib/libGL.so.1 and also: https://autobuilder.yoctoproject.org/typhoon/api/v2/logs/457856/raw oe-selftest -r runtime_test.TestImage.test_testimage_virgl_gtk Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC, v5] mesa: Convert recipe to use meson build system
On Thu, 2019-04-25 at 10:55 -0300, Fabio Berton wrote: > - 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 I think this breaks musl at runtime: https://autobuilder.yoctoproject.org/typhoon/#/builders/64/builds/538/steps/7/logs/step1c Specifically: [ 5.224] (EE) Failed to load /usr/lib/xorg/modules/extensions/libglx.so: Error relocating /usr/lib/libGL.so.1: alphasort: initial-exec TLS resolves to dynamic definition in /usr/lib/libGL.so.1 Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/3] pulseaudio: disable PIE flags when hardened flags are enabled
On Fri, 2019-04-26 at 15:53 +0300, Tanu Kaskinen wrote:
> On Mon, 2019-04-22 at 14:28 -0600, Khem Raj wrote:
> > On Mon, Apr 22, 2019 at 6:33 AM Tanu Kaskinen wrote:
> >
> > > On Fri, 2017-06-09 at 10:10 -0700, Khem Raj wrote:
> > > > On Fri, Jun 9, 2017 at 9:38 AM, Tanu Kaskinen
> > > > wrote:
> > > > > On Fri, 2017-06-09 at 13:07 +, Khem Raj wrote:
> > > > > > On Fri, Jun 9, 2017 at 5:56 AM Burton, Ross <
> > > > > > ross.bur...@intel.com>
> > > wrote:
> > > > > > > On 9 June 2017 at 04:41, Khem Raj
> > > > > > > wrote:
> > > > > > >
> > > > > > > > +SECURITY_CFLAGS = "${SECURITY_NO_PIE_CFLAGS}"
> > > > > > > >
> > > > > > >
> > > > > > > These tend to go into security-flags.inc, not the recipe.
> > > > > > >
> > > > > >
> > > > > > I know that's been the case but I think having a global
> > > > > > file is
> > > error prone
> > > > > > its better to have it in recipe context since it can get
> > > > > > attention at
> > > > > > upgrade time to test if this has been fixed in new release
> > > > > > etc
> > > > >
> > > > > Do you mean that there's some bug in pulseaudio, and this is
> > > > > a
> > > > > workaround for it? Is the bug that there are textrels? Ross
> > > > > saw
> > > > > textrels in pulseaudio before (see the discussion starting at
> > > > > [1]), but
> > > > > I was unable to reproduce that. If you give instructions for
> > > > > reproducing the problem, I'll see if I can fix pulseaudio
> > > > > (until then
> > > > > I'm fine with having a workaround).
> > > > >
> > > >
> > > > yes there is a bug lurking when compiling with hardening flags
> > > > are
> > > turned on
> > > > so you can do something like
> > > >
> > > > in local.conf
> > > >
> > > > require conf/distro/include/security_flags.inc
> > > >
> > > > then
> > > >
> > > > MACHINE=qemux86 bitbake pulseaudio
> > > >
> > > > it also happens on arm so qemuarm will reproduce it too.
> > > >
> > > > some assembly code is probably missing using GOT relative
> > > > accesses
> > >
> > > Resurrecting this ancient thread... I finally tried to reproduce
> > > this
> > > problem with the given instructions. No success. Have you still
> > > been
> > > running into this issue?
> >
> > I don’t know for sure if this still exists but we did disable
> > assembly in
> > few packages which addresses this issue since in assembly PIC has
> > to be
> > respected
> > In hand written code
> >
> > You might have to check if we did something similar for pulseaudio
>
> There seem to be no such changes to the pulseaudio recipe. Some
> upstream fix seems unlikely as well. The only possibly relevant
> change
> that I could find was removing a buggy implementation of reading the
> cpuid register (the removed code was replaced with the __get_cpuid()
> macro that compilers provide in cpuid.h).
>
> Oh well, if the problem reappears, let me know.
Shortly after this, Khem submitted:
http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=c91314ec160420a320007d552cec6c7da4d54833
and
http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=6733a7873ca121295a2e309a6915b9816e1ae36b
which I suspect made this other change unnecessary?
Cheers,
Richard
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] QA cycle report for 2.7 RC2
On Fri, 2019-04-26 at 06:27 +, Jain, Sangeeta wrote: > > QA cycle report for 2.7 RC2: > > No high milestone defects. > Test results are available at following location: > ·For results of all automated tests, please refer to results > at public AB [1]. > ·For other test results, refer to attachment [2]. > ·For test report for test cases run by Intel and WR team, > refer attachment [3] > ·For full test report, refer attachment [4] > No new defects are found in this cycle. > No existing issues observed in this release > No ptests are failing in this release which were passing in previous > release. No timeout issues. > > QA Hint: One failure was observed on public AB: > > testseries | result_id : qemuppc | oeselftest_centos- > 7_qemuppc_20190414221329 > runqemu.QemuTest.test_qemu_can_shutdown > > No bug filed for this issue, as it appears to be an intermittent > failure and worked on rc1 test run. Thanks for the testing! FWIW it should have and does have a bug: https://bugzilla.yoctoproject.org/show_bug.cgi?id=13309 also, https://bugzilla.yoctoproject.org/show_bug.cgi?id=12991 is still present in the release according to that bug. I've asked the TSC for a go/nogo decision on the release. Cheers, Richard -- ___ 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, 2019-04-25 at 11:24 -0700, Alistair Francis wrote: > 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 Thanks, this worked better in testing but showed issues with qemuarm booting: https://autobuilder.yoctoproject.org/typhoon/#/builders/53/builds/535 https://autobuilder.yoctoproject.org/typhoon/#/builders/47/builds/549 I took it out of -next again and those passed (but some of the other build failures also in that build remained) Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/3] pulseaudio: disable PIE flags when hardened flags are enabled
On Mon, 2019-04-22 at 14:28 -0600, Khem Raj wrote:
> On Mon, Apr 22, 2019 at 6:33 AM Tanu Kaskinen wrote:
>
> > On Fri, 2017-06-09 at 10:10 -0700, Khem Raj wrote:
> > > On Fri, Jun 9, 2017 at 9:38 AM, Tanu Kaskinen wrote:
> > > > On Fri, 2017-06-09 at 13:07 +, Khem Raj wrote:
> > > > > On Fri, Jun 9, 2017 at 5:56 AM Burton, Ross
> > wrote:
> > > > > > On 9 June 2017 at 04:41, Khem Raj wrote:
> > > > > >
> > > > > > > +SECURITY_CFLAGS = "${SECURITY_NO_PIE_CFLAGS}"
> > > > > > >
> > > > > >
> > > > > > These tend to go into security-flags.inc, not the recipe.
> > > > > >
> > > > >
> > > > > I know that's been the case but I think having a global file is
> > error prone
> > > > > its better to have it in recipe context since it can get attention at
> > > > > upgrade time to test if this has been fixed in new release etc
> > > >
> > > > Do you mean that there's some bug in pulseaudio, and this is a
> > > > workaround for it? Is the bug that there are textrels? Ross saw
> > > > textrels in pulseaudio before (see the discussion starting at [1]), but
> > > > I was unable to reproduce that. If you give instructions for
> > > > reproducing the problem, I'll see if I can fix pulseaudio (until then
> > > > I'm fine with having a workaround).
> > > >
> > >
> > > yes there is a bug lurking when compiling with hardening flags are
> > turned on
> > > so you can do something like
> > >
> > > in local.conf
> > >
> > > require conf/distro/include/security_flags.inc
> > >
> > > then
> > >
> > > MACHINE=qemux86 bitbake pulseaudio
> > >
> > > it also happens on arm so qemuarm will reproduce it too.
> > >
> > > some assembly code is probably missing using GOT relative accesses
> >
> > Resurrecting this ancient thread... I finally tried to reproduce this
> > problem with the given instructions. No success. Have you still been
> > running into this issue?
>
> I don’t know for sure if this still exists but we did disable assembly in
> few packages which addresses this issue since in assembly PIC has to be
> respected
> In hand written code
>
> You might have to check if we did something similar for pulseaudio
There seem to be no such changes to the pulseaudio recipe. Some
upstream fix seems unlikely as well. The only possibly relevant change
that I could find was removing a buggy implementation of reading the
cpuid register (the removed code was replaced with the __get_cpuid()
macro that compilers provide in cpuid.h).
Oh well, if the problem reappears, let me know.
--
Tanu
https://www.patreon.com/tanuk
https://liberapay.com/tanuk
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [master][RFC v3] Adding back wrapper and using OEPYTHON3HOME variable for python3
Adding back the python wrapper and adding a patch to use OEPYTHON3HOME
instead of PYTHONHOME if set, for python3.
If we add back the wrapper as is, we would see the following error that
we also see in Thud:
ImportError: No module named site
OpenEmbedded requires 'python' to be python v2 (>= 2.7.3), not python
v3.
Please upgrade your python v2
This is because python3 would've set PYTHONHOME to use nativesdk
python3 libraries but when the oe-buildenv-internal script tries to call
python2 for the py_v27_check, there will be no python2 libraries in the
PYTHONHOME directory.
In other words, bitbake needs host python2 and the env variable set from
the wrapper contaminates the env and host python2 won't be able to find
its libraries
Creating another variable OEPYTHON3HOME and using this in the python3
wrapper to allow for a way to set a different paths for python3 and
python2
[YOCTO #13208]
Signed-off-by: Jaewon Lee
Signed-off-by: Alejandro Enedino Hernandez Samaniego
---
changelog:
v2: change python3 patch to avoid mem leak
v3: fix tabs and spaces issue
---
...EPYTHON3HOME-is-set-use-instead-of-PYTHON.patch | 47 ++
meta/recipes-devtools/python/python3_3.7.3.bb | 7
2 files changed, 54 insertions(+)
create mode 100644
meta/recipes-devtools/python/python3/0001-main.c-if-OEPYTHON3HOME-is-set-use-instead-of-PYTHON.patch
diff --git
a/meta/recipes-devtools/python/python3/0001-main.c-if-OEPYTHON3HOME-is-set-use-instead-of-PYTHON.patch
b/meta/recipes-devtools/python/python3/0001-main.c-if-OEPYTHON3HOME-is-set-use-instead-of-PYTHON.patch
new file mode 100644
index 000..06eb2bd
--- /dev/null
+++
b/meta/recipes-devtools/python/python3/0001-main.c-if-OEPYTHON3HOME-is-set-use-instead-of-PYTHON.patch
@@ -0,0 +1,47 @@
+From ffe7797637f08cd6ee4c82e2d67462c5e194d30a Mon Sep 17 00:00:00 2001
+From: Jaewon Lee
+Date: Thu, 25 Apr 2019 15:34:26 -0700
+Subject: [PATCH] main.c: if OEPYTHON3HOME is set use instead of PYTHONHOME
+
+There is one variable PYTHONHOME to determine where libraries are coming
+from for both python2 and python3. This becomes an issue if only one has
+libraries in the specified PYTHONHOME path, but they are using the same
+PYTHONHOME. Creating another variable OEPYTHON3HOME to allow for a way
+to set a different path for python3
+
+Signed-off-by: Jaewon Lee
+---
+ Modules/main.c | 17 +
+ 1 file changed, 13 insertions(+), 4 deletions(-)
+
+diff --git a/Modules/main.c b/Modules/main.c
+index a745381..b553e30 100644
+--- a/Modules/main.c
b/Modules/main.c
+@@ -1855,10 +1855,19 @@ config_init_home(_PyCoreConfig *config)
+ }
+ return _Py_INIT_OK();
+ }
+-
+-int res = config_get_env_var_dup(, L"PYTHONHOME", "PYTHONHOME");
+-if (res < 0) {
+-return DECODE_LOCALE_ERR("PYTHONHOME", res);
++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);
++}
+ }
+ config->home = home;
+ return _Py_INIT_OK();
+--
+2.7.4
+
diff --git a/meta/recipes-devtools/python/python3_3.7.3.bb
b/meta/recipes-devtools/python/python3_3.7.3.bb
index ea46b05..af7ede1 100644
--- a/meta/recipes-devtools/python/python3_3.7.3.bb
+++ b/meta/recipes-devtools/python/python3_3.7.3.bb
@@ -28,6 +28,9 @@ SRC_URI_append_class-native = " \
file://0001-distutils-sysconfig-append-STAGING_LIBDIR-python-sys.patch \
file://12-distutils-prefix-is-inside-staging-area.patch \
"
+SRC_URI_append_class-nativesdk = " \
+
file://0001-main.c-if-OEPYTHON3HOME-is-set-use-instead-of-PYTHON.patch \
+ "
SRC_URI[md5sum] = "93df27aec0cd18d6d42173e601ffbbfd"
SRC_URI[sha256sum] =
"da60b54064d4cfcd9c26576f6df2690e62085123826cff2e667e72a91952d318"
@@ -131,6 +134,10 @@ do_install_append() {
${D}${libdir}/python-sysconfigdata/_sysconfigdata.py
}
+do_install_append_class-nativesdk () {
+create_wrapper ${D}${bindir}/python${PYTHON_MAJMIN}
OEPYTHON3HOME='${prefix}'
TERMINFO_DIRS='${sysconfdir}/terminfo:/etc/terminfo:/usr/share/terminfo:/usr/share/misc/terminfo:/lib/terminfo'
PYTHONNOUSERSITE='1'
+}
+
SSTATE_SCAN_FILES += "Makefile _sysconfigdata.py"
PACKAGE_PREPROCESS_FUNCS += "py_package_preprocess"
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [master][RFC] Adding back wrapper and using OEPYTHON3HOME variable for python3
Adding back the python wrapper and adding a patch to use OEPYTHON3HOME
instead of PYTHONHOME if set, for python3.
If we add back the wrapper as is, we would see the following error that
we also see in Thud:
ImportError: No module named site
OpenEmbedded requires 'python' to be python v2 (>= 2.7.3), not python
v3.
Please upgrade your python v2
This is because python3 would've set PYTHONHOME to use nativesdk
python3 libraries but when the oe-buildenv-internal script tries to call
python2 for the py_v27_check, there will be no python2 libraries in the
PYTHONHOME directory.
In other words, bitbake needs host python2 and the env variable set from
the wrapper contaminates the env and host python2 won't be able to find
its libraries
Creating another variable OEPYTHON3HOME and using this in the python3
wrapper to allow for a way to set a different paths for python3 and
python2
[YOCTO #13208]
Signed-off-by: Jaewon Lee
Signed-off-by: Alejandro Enedino Hernandez Samaniego
---
...EPYTHON3HOME-is-set-use-instead-of-PYTHON.patch | 35 ++
meta/recipes-devtools/python/python3_3.7.3.bb | 7 +
2 files changed, 42 insertions(+)
create mode 100644
meta/recipes-devtools/python/python3/0001-main.c-if-OEPYTHON3HOME-is-set-use-instead-of-PYTHON.patch
diff --git
a/meta/recipes-devtools/python/python3/0001-main.c-if-OEPYTHON3HOME-is-set-use-instead-of-PYTHON.patch
b/meta/recipes-devtools/python/python3/0001-main.c-if-OEPYTHON3HOME-is-set-use-instead-of-PYTHON.patch
new file mode 100644
index 000..12aeab9
--- /dev/null
+++
b/meta/recipes-devtools/python/python3/0001-main.c-if-OEPYTHON3HOME-is-set-use-instead-of-PYTHON.patch
@@ -0,0 +1,35 @@
+From e4363ca1d84b4014184a79a847fb2affb3dfe86e Mon Sep 17 00:00:00 2001
+From: Jaewon Lee
+Date: Tue, 23 Apr 2019 17:01:08 -0700
+Subject: [PATCH] main.c: if OEPYTHON3HOME is set use instead of PYTHONHOME
+
+There is one variable PYTHONHOME to determine where libraries are coming
+from for both python2 and python3. This becomes an issue if only one has
+libraries in the specified PYTHONHOME path, but they are using the same
+PYTHONHOME. Creating another variable OEPYTHON3HOME to allow for a way
+to set a different path for python3
+
+Signed-off-by: Jaewon Lee
+---
+ Modules/main.c | 5 +
+ 1 file changed, 5 insertions(+)
+
+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
+
diff --git a/meta/recipes-devtools/python/python3_3.7.3.bb
b/meta/recipes-devtools/python/python3_3.7.3.bb
index ea46b05..af7ede1 100644
--- a/meta/recipes-devtools/python/python3_3.7.3.bb
+++ b/meta/recipes-devtools/python/python3_3.7.3.bb
@@ -28,6 +28,9 @@ SRC_URI_append_class-native = " \
file://0001-distutils-sysconfig-append-STAGING_LIBDIR-python-sys.patch \
file://12-distutils-prefix-is-inside-staging-area.patch \
"
+SRC_URI_append_class-nativesdk = " \
+
file://0001-main.c-if-OEPYTHON3HOME-is-set-use-instead-of-PYTHON.patch \
+ "
SRC_URI[md5sum] = "93df27aec0cd18d6d42173e601ffbbfd"
SRC_URI[sha256sum] =
"da60b54064d4cfcd9c26576f6df2690e62085123826cff2e667e72a91952d318"
@@ -131,6 +134,10 @@ do_install_append() {
${D}${libdir}/python-sysconfigdata/_sysconfigdata.py
}
+do_install_append_class-nativesdk () {
+create_wrapper ${D}${bindir}/python${PYTHON_MAJMIN}
OEPYTHON3HOME='${prefix}'
TERMINFO_DIRS='${sysconfdir}/terminfo:/etc/terminfo:/usr/share/terminfo:/usr/share/misc/terminfo:/lib/terminfo'
PYTHONNOUSERSITE='1'
+}
+
SSTATE_SCAN_FILES += "Makefile _sysconfigdata.py"
PACKAGE_PREPROCESS_FUNCS += "py_package_preprocess"
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [sumo][PATCH] busybox: fix udhcpd not dying on SIGTERM
Signed-off-by: Visser Sander
Signed-off-by: Andrej Valek
---
.../busybox-udhcpd-fix-not-dying-on-SIGTERM.patch | 272 +
meta/recipes-core/busybox/busybox_1.27.2.bb| 1 +
2 files changed, 273 insertions(+)
create mode 100644
meta/recipes-core/busybox/busybox/busybox-udhcpd-fix-not-dying-on-SIGTERM.patch
diff --git
a/meta/recipes-core/busybox/busybox/busybox-udhcpd-fix-not-dying-on-SIGTERM.patch
b/meta/recipes-core/busybox/busybox/busybox-udhcpd-fix-not-dying-on-SIGTERM.patch
new file mode 100644
index 00..96be486c61
--- /dev/null
+++
b/meta/recipes-core/busybox/busybox/busybox-udhcpd-fix-not-dying-on-SIGTERM.patch
@@ -0,0 +1,272 @@
+From 1384459d88cb0f5f47b6a36b8346dcf425a643f5 Mon Sep 17 00:00:00 2001
+From: Denys Vlasenko
+Date: Sat, 10 Mar 2018 19:01:48 +0100
+Subject: [PATCH] udhcpd: fix "not dying on SIGTERM"
+
+Upstream-status: Backport
[https://git.busybox.net/busybox/commit/?id=3293bc146985c56790033409facc0ad64a471084]
+
+Fixes:
+ commit 52a515d18724bbb34e3ccbbb0218efcc4eccc0a8
+ "udhcp: use poll() instead of select()"
+ Feb 16 2017
+
+udhcp_sp_read() is meant to check whether signal pipe indeed has some data to
read.
+In the above commit, it was changed as follows:
+
+- if (!FD_ISSET(signal_pipe.rd, rfds))
++ if (!pfds[0].revents)
+ return 0;
+
+The problem is, the check was working for select() purely by accident.
+Caught signal interrupts select()/poll() syscalls, they return with EINTR
+(regardless of SA_RESTART flag in sigaction). _Then_ signal handler is invoked.
+IOW: they can't see any changes to fd state caused by signal haldler
+(in our case, signal handler makes signal pipe ready to be read).
+
+For select(), it means that rfds[] bit array is unmodified, bit of signal
+pipe's read fd is still set, and the above check "works": it thinks select()
+says there is data to read.
+
+This accident does not work for poll(): .revents stays clear, and we do not
+try reading signal pipe as we should. In udhcpd, we fall through and block
+in socket read. Further SIGTERM signals simply cause socket read to be
+interrupted and then restarted (since SIGTERM handler has SA_RESTART=1).
+
+Fixing this as follows: remove the check altogether. Set signal pipe read fd
+to nonblocking mode. Always read it in udhcp_sp_read().
+If read fails, assume it's EAGAIN and return 0 ("no signal seen").
+
+udhcpd avoids reading signal pipe on every recvd packet by looping if EINTR
+(using safe_poll()) - thus ensuring we have correct .revents for all fds -
+and calling udhcp_sp_read() only if pfds[0].revents!=0.
+
+udhcpc performs much fewer reads (typically it sleeps >99.999% of the time),
+there is no need to optimize it: can call udhcp_sp_read() after each poll
+unconditionally.
+
+To robustify socket reads, unconditionally set pfds[1].revents=0
+in udhcp_sp_fd_set() (which is before poll), and check it before reading
+network socket in udhcpd.
+
+TODO:
+This might still fail: if pfds[1].revents=POLLIN, socket read may still block.
+There are rare cases when select/poll indicates that data can be read,
+but then actual read still blocks (one such case is UDP packets with
+wrong checksum). General advise is, if you use a poll/select loop,
+keep all your fds nonblocking.
+Maybe we should also do that to our network sockets?
+
+function old new delta
+udhcp_sp_setup55 65 +10
+udhcp_sp_fd_set 54 60 +6
+udhcp_sp_read 46 36 -10
+udhcpd_main 14511437 -14
+udhcpc_main 27232708 -15
+--
+(add/remove: 0/0 grow/shrink: 2/3 up/down: 16/-39)Total: -23 bytes
+
+Signed-off-by: Denys Vlasenko
+---
+ examples/var_service/dhcpd_if/run | 4 +--
+ .../dhcpd_if/{udhcpc.conf => udhcpd.conf} | 0
+ networking/udhcp/common.h | 2 +-
+ networking/udhcp/d6_dhcpc.c| 9 +++---
+ networking/udhcp/dhcpc.c | 9 +++---
+ networking/udhcp/dhcpd.c | 34 --
+ networking/udhcp/signalpipe.c | 11 +++
+ 7 files changed, 35 insertions(+), 34 deletions(-)
+ rename examples/var_service/dhcpd_if/{udhcpc.conf => udhcpd.conf} (100%)
+
+diff --git a/examples/var_service/dhcpd_if/run
b/examples/var_service/dhcpd_if/run
+index de85dece0..a603bdc71 100755
+--- a/examples/var_service/dhcpd_if/run
b/examples/var_service/dhcpd_if/run
+@@ -11,13 +11,13 @@ echo "* Upping iface $if"
+ ip link set dev $if up
+
+ >>udhcpd.leases
+-sed 's/^interface.*$/interface '"$if/" -i udhcpc.conf
++sed 's/^interface.*$/interface '"$if/" -i
Re: [OE-core] [PATCH] run-postinsts: Fix full execution of scripts at first boot
On Fri, 2019-04-19 at 14:47 -0700, Alejandro Enedino Hernandez Samaniego wrote: > run-postinsts runs a given set of scripts during the first boot of > the > device, when one of these scripts prints something to stdout (isnt > daemonized correctly), since stdout is not available at that time, > the script execution immediately returns with an error > (exit_group()), > this error causes the script to terminate all threads within the > process, > causing undesired behavior since the script might still had to > execute > some other code. > > Replace eval built-in with $(), since $() executes in a different > shell, > even if one of the scripts exits, all threads of that process will > only > be within that session, this ensures other scripts meant to be run > are > still run afterwards. > > This was only required on the line that actually executes the > scripts: > "eval sh -c $i $append_log", other replacements were put for > consistency, > and generally, it is recommended to use $() instead of eval anyway. > > [YOCTO #13266] > > Signed-off-by: Alejandro Enedino Hernandez Samaniego < > aleja...@xilinx.com> This seems to cause: oe-selftest -r runtime_test.Postinst.test_postinst_rootfs_and_boot to fail: https://autobuilder.yoctoproject.org/typhoon/#/builders/56/builds/429 (both on the autobuilder and locally) Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] QA cycle report for 2.7 RC2
QA cycle report for 2.7 RC2: 1. No high milestone defects. 2. Test results are available at following location: *For results of all automated tests, please refer to results at public AB [1]. *For other test results, refer to attachment [2]. *For test report for test cases run by Intel and WR team, refer attachment [3] *For full test report, refer attachment [4] 1. No new defects are found in this cycle. 2. No existing issues observed in this release 3. No ptests are failing in this release which were passing in previous release. No timeout issues. QA Hint: One failure was observed on public AB: testseries | result_id : qemuppc | oeselftest_centos-7_qemuppc_20190414221329 runqemu.QemuTest.test_qemu_can_shutdown No bug filed for this issue, as it appears to be an intermittent failure and worked on rc1 test run. === Links Link to testresults: [1] - https://autobuilder.yocto.io/pub/releases/yocto-2.7.rc2/testresults/ [2] - 2.7_RC2_results_merged.zip [3] - 2.7_ rc2_intel_wr_merged_report [4] - 2.7 _rc2_full_report Thanks & Regards, Sangeeta Jain <> 2.7_rc2_intel_wr_merged_report Description: 2.7_rc2_intel_wr_merged_report 2.7_rc2_full_report Description: 2.7_rc2_full_report -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
