Re: [OE-core] [PATCH] systemd: enable portabled by default and install utilities in systemd-container
Hi Luca,
On 09/05/2019 23.40, luca.bocca...@gmail.com wrote:
From: Luca Boccassi
portable services have been declared production ready with v241, so enable
by default and install the files in the container package.
The systemd portables feature is not really related to containers/VM's,
so I think it should stay in the primary package; or alternatively in a
separate package.
// Martin
Signed-off-by: Luca Boccassi
---
meta/recipes-core/systemd/systemd_242.bb | 10 ++
1 file changed, 10 insertions(+)
diff --git a/meta/recipes-core/systemd/systemd_242.bb
b/meta/recipes-core/systemd/systemd_242.bb
index 73e03c7a77..83b00ba785 100644
--- a/meta/recipes-core/systemd/systemd_242.bb
+++ b/meta/recipes-core/systemd/systemd_242.bb
@@ -81,6 +81,7 @@ PACKAGECONFIG ??= " \
nss \
nss-mymachines \
nss-resolve \
+portabled \
quotacheck \
randomseed \
resolved \
@@ -403,8 +404,10 @@ SYSTEMD_SERVICE_${PN}-remote =
"systemd-journal-remote.socket"
FILES_${PN}-container = "${sysconfdir}/dbus-1/system.d/org.freedesktop.import1.conf \
${sysconfdir}/dbus-1/system.d/org.freedesktop.machine1.conf \
+
${sysconfdir}/dbus-1/system.d/org.freedesktop.portable1.conf \
${sysconfdir}/systemd/system/multi-user.target.wants/machines.target \
${base_bindir}/machinectl \
+ ${base_bindir}/portablectl \
${bindir}/systemd-nspawn \
${nonarch_libdir}/systemd/import-pubring.gpg \
${systemd_system_unitdir}/busnames.target.wants/org.freedesktop.import1.busname
\
@@ -418,21 +421,28 @@ FILES_${PN}-container =
"${sysconfdir}/dbus-1/system.d/org.freedesktop.import1.c
${systemd_system_unitdir}/org.freedesktop.machine1.busname \
${systemd_system_unitdir}/systemd-importd.service \
${systemd_system_unitdir}/systemd-machined.service \
+ ${systemd_system_unitdir}/systemd-portabled.service \
${systemd_system_unitdir}/dbus-org.freedesktop.machine1.service \
+
${systemd_system_unitdir}/dbus-org.freedesktop.portable1.service \
${systemd_system_unitdir}/var-lib-machines.mount \
${rootlibexecdir}/systemd/systemd-import \
${rootlibexecdir}/systemd/systemd-importd \
${rootlibexecdir}/systemd/systemd-machined \
+ ${rootlibexecdir}/systemd/systemd-portabled \
${rootlibexecdir}/systemd/systemd-pull \
+ ${exec_prefix}/lib/tmpfiles.d/portables.conf \
${exec_prefix}/lib/tmpfiles.d/systemd-nspawn.conf \
${systemd_system_unitdir}/systemd-nspawn@.service \
${libdir}/libnss_mymachines.so.2 \
${datadir}/dbus-1/system-services/org.freedesktop.import1.service \
${datadir}/dbus-1/system-services/org.freedesktop.machine1.service \
+
${datadir}/dbus-1/system-services/org.freedesktop.portable1.service \
${datadir}/dbus-1/system.d/org.freedesktop.import1.conf \
${datadir}/dbus-1/system.d/org.freedesktop.machine1.conf \
+
${datadir}/dbus-1/system.d/org.freedesktop.portable1.conf \
${datadir}/polkit-1/actions/org.freedesktop.import1.policy \
${datadir}/polkit-1/actions/org.freedesktop.machine1.policy \
+
${datadir}/polkit-1/actions/org.freedesktop.portable1.policy \
"
RRECOMMENDS_${PN}-container += "\
--
Kind regards,
Martin Hundebøll
Embedded Linux Consultant
+45 61 65 54 61
mar...@geanix.com
Geanix ApS
https://geanix.com
DK39600706
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] wic/bootimg-efi: replace hardcoded volume name with label
From: Chee Yang Lee volume name should refer to --label in .wks. Replace the hardcoded volume name with label. Keep "efi" as default name when no lable specified. Signed-off-by: Chee Yang Lee --- scripts/lib/wic/plugins/source/bootimg-efi.py | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/scripts/lib/wic/plugins/source/bootimg-efi.py b/scripts/lib/wic/plugins/source/bootimg-efi.py index 0a0c5bd..55202a8 100644 --- a/scripts/lib/wic/plugins/source/bootimg-efi.py +++ b/scripts/lib/wic/plugins/source/bootimg-efi.py @@ -268,8 +268,10 @@ class BootimgEFIPlugin(SourcePlugin): # dosfs image, created by mkdosfs bootimg = "%s/boot.img" % cr_workdir -dosfs_cmd = "mkdosfs -n efi -i %s -C %s %d" % \ -(part.fsuuid, bootimg, blocks) +label = part.label if part.label else "efi" + +dosfs_cmd = "mkdosfs -n %s -i %s -C %s %d" % \ +(label, part.fsuuid, bootimg, blocks) exec_native_cmd(dosfs_cmd, native_sysroot) mcopy_cmd = "mcopy -i %s -s %s/* ::/" % (bootimg, hdddir) -- 2.7.4 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] oeqa/selftest: Automate manual pybootchart tests
On 5/9/19 9:58 AM, Richard Purdie wrote:
> Automate the current manual pybootchart tests. This includes a check
> for the cairo dependency, skipping the test if appropriate.
>
> Based on original patch from Armin Kuster
>
> Signed-off-by: Richard Purdie
Thanks.
- armin
> ---
> meta/lib/oeqa/manual/oe-core.json | 26 -
> meta/lib/oeqa/selftest/cases/oescripts.py | 34 +++
> 2 files changed, 34 insertions(+), 26 deletions(-)
>
> diff --git a/meta/lib/oeqa/manual/oe-core.json
> b/meta/lib/oeqa/manual/oe-core.json
> index d893d849fb3..3ee0aa95f93 100644
> --- a/meta/lib/oeqa/manual/oe-core.json
> +++ b/meta/lib/oeqa/manual/oe-core.json
> @@ -1,30 +1,4 @@
> [
> - {
> -"test": {
> - "@alias":
> "oe-core.scripts.Use_scripts/pybootchartgui/pybootchartgui.py_to_generate_build_profiles",
> - "author": [
> -{
> - "email": "alexandru.c.george...@intel.com",
> - "name": "alexandru.c.george...@intel.com"
> -}
> - ],
> - "execution": {
> -"1": {
> - "action": "Run a build for a recipe (e.g. core-image-minimal)",
> - "expected_results": ""
> -},
> -"2": {
> - "action": "Run the profiling script,
> ../scripts/pybootchartgui/pybootchartgui.py tmp/buildstats/\n\n",
> - "expected_results": ""
> -},
> -"3": {
> - "action": "Verify the results ",
> - "expected_results": "The scripts generates svg files with the
> profiling results . "
> -}
> - },
> - "summary":
> "Use_scripts/pybootchartgui/pybootchartgui.py_to_generate_build_profiles"
> -}
> - },
>{
> "test": {
>"@alias": "oe-core.scripts.Crosstap_script_check",
> diff --git a/meta/lib/oeqa/selftest/cases/oescripts.py
> b/meta/lib/oeqa/selftest/cases/oescripts.py
> index 56b35b59eb8..217afe3775b 100644
> --- a/meta/lib/oeqa/selftest/cases/oescripts.py
> +++ b/meta/lib/oeqa/selftest/cases/oescripts.py
> @@ -2,6 +2,7 @@
> # SPDX-License-Identifier: MIT
> #
>
> +import os
> from oeqa.selftest.case import OESelftestTestCase
> from oeqa.selftest.cases.buildhistory import BuildhistoryBase
> from oeqa.utils.commands import Command, runCmd, bitbake, get_bb_var,
> get_test_layer
> @@ -28,3 +29,36 @@ class BuildhistoryDiffTests(BuildhistoryBase):
> self.fail('Unexpected line:\n%s\nExpected line endings:\n
> %s' % (line, '\n '.join(expected_endlines)))
> if expected_endlines:
> self.fail('Missing expected line endings:\n %s' % '\n
> '.join(expected_endlines))
> +
> +class OEScriptTests(OESelftestTestCase):
> +
> +@classmethod
> +def setUpClass(cls):
> +super(OEScriptTests, cls).setUpClass()
> +try:
> +import cairo
> +except ImportError:
> +cls.skipTest('Python module cairo is not present')
> +bitbake("core-image-minimal -c rootfs -f")
> +cls.tmpdir = get_bb_var('TMPDIR')
> +cls.buildstats = cls.tmpdir + "/buildstats/" +
> sorted(os.listdir(cls.tmpdir + "/buildstats"))[-1]
> +
> +scripts_dir = os.path.join(get_bb_var('COREBASE'), 'scripts')
> +
> +class OEPybootchartguyTests(OEScriptTests):
> +
> +def test_pybootchartguy_help(self):
> +runCmd('%s/pybootchartgui/pybootchartgui.py --help' %
> self.scripts_dir)
> +
> +def test_pybootchartguy_to_generate_build_png_output(self):
> +runCmd('%s/pybootchartgui/pybootchartgui.py %s -o %s/charts -f png'
> % (self.scripts_dir, self.buildstats, self.tmpdir))
> +self.assertTrue(os.path.exists(self.tmpdir + "/charts.png"))
> +
> +def test_pybootchartguy_to_generate_build_svg_output(self):
> +runCmd('%s/pybootchartgui/pybootchartgui.py %s -o %s/charts -f svg'
> % (self.scripts_dir, self.buildstats, self.tmpdir))
> +self.assertTrue(os.path.exists(self.tmpdir + "/charts.svg"))
> +
> +def test_pybootchartguy_to_generate_build_pdf_output(self):
> +runCmd('%s/pybootchartgui/pybootchartgui.py %s -o %s/charts -f pdf'
> % (self.scripts_dir, self.buildstats, self.tmpdir))
> +self.assertTrue(os.path.exists(self.tmpdir + "/charts.pdf"))
> +
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] bitbake.conf: fix XORG_MIRROR URL
Signed-off-by: Oleksandr Kravchuk --- meta/conf/bitbake.conf | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf index c13e4f3f71..4466f41d75 100644 --- a/meta/conf/bitbake.conf +++ b/meta/conf/bitbake.conf @@ -649,7 +649,7 @@ GPE_MIRROR = "http://gpe.linuxtogo.org/download/source; KERNELORG_MIRROR = "https://cdn.kernel.org/pub; SOURCEFORGE_MIRROR = "https://downloads.sourceforge.net; XLIBS_MIRROR = "https://xlibs.freedesktop.org/release; -XORG_MIRROR = "http://xorg.freedesktop.org/releases; +XORG_MIRROR = "https://www.x.org/releases/; SAVANNAH_GNU_MIRROR = "https://download.savannah.gnu.org/releases; SAVANNAH_NONGNU_MIRROR = "https://download.savannah.nongnu.org/releases; CPAN_MIRROR = "https://search.cpan.org/CPAN; -- 2.17.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [thud] Backport "package_manager.py: Use data.tar.xz for ipkg too"
Please cherry-pick c09a22c421a57701f6b943eb50b9bae1545e5b39 onto thud release branch. (Note warrior already has this commit) The fix should also be applied to sumo, if we're still making changes there. (Any branch that includes b95b6ba1a2959e2294a8848fa35f20163388eb06) -- Thanks, - Gus -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] systemd: enable portabled by default and install utilities in systemd-container
From: Luca Boccassi
portable services have been declared production ready with v241, so enable
by default and install the files in the container package.
Signed-off-by: Luca Boccassi
---
meta/recipes-core/systemd/systemd_242.bb | 10 ++
1 file changed, 10 insertions(+)
diff --git a/meta/recipes-core/systemd/systemd_242.bb
b/meta/recipes-core/systemd/systemd_242.bb
index 73e03c7a77..83b00ba785 100644
--- a/meta/recipes-core/systemd/systemd_242.bb
+++ b/meta/recipes-core/systemd/systemd_242.bb
@@ -81,6 +81,7 @@ PACKAGECONFIG ??= " \
nss \
nss-mymachines \
nss-resolve \
+portabled \
quotacheck \
randomseed \
resolved \
@@ -403,8 +404,10 @@ SYSTEMD_SERVICE_${PN}-remote =
"systemd-journal-remote.socket"
FILES_${PN}-container =
"${sysconfdir}/dbus-1/system.d/org.freedesktop.import1.conf \
${sysconfdir}/dbus-1/system.d/org.freedesktop.machine1.conf \
+
${sysconfdir}/dbus-1/system.d/org.freedesktop.portable1.conf \
${sysconfdir}/systemd/system/multi-user.target.wants/machines.target \
${base_bindir}/machinectl \
+ ${base_bindir}/portablectl \
${bindir}/systemd-nspawn \
${nonarch_libdir}/systemd/import-pubring.gpg \
${systemd_system_unitdir}/busnames.target.wants/org.freedesktop.import1.busname
\
@@ -418,21 +421,28 @@ FILES_${PN}-container =
"${sysconfdir}/dbus-1/system.d/org.freedesktop.import1.c
${systemd_system_unitdir}/org.freedesktop.machine1.busname \
${systemd_system_unitdir}/systemd-importd.service \
${systemd_system_unitdir}/systemd-machined.service \
+ ${systemd_system_unitdir}/systemd-portabled.service \
${systemd_system_unitdir}/dbus-org.freedesktop.machine1.service \
+
${systemd_system_unitdir}/dbus-org.freedesktop.portable1.service \
${systemd_system_unitdir}/var-lib-machines.mount \
${rootlibexecdir}/systemd/systemd-import \
${rootlibexecdir}/systemd/systemd-importd \
${rootlibexecdir}/systemd/systemd-machined \
+ ${rootlibexecdir}/systemd/systemd-portabled \
${rootlibexecdir}/systemd/systemd-pull \
+ ${exec_prefix}/lib/tmpfiles.d/portables.conf \
${exec_prefix}/lib/tmpfiles.d/systemd-nspawn.conf \
${systemd_system_unitdir}/systemd-nspawn@.service \
${libdir}/libnss_mymachines.so.2 \
${datadir}/dbus-1/system-services/org.freedesktop.import1.service \
${datadir}/dbus-1/system-services/org.freedesktop.machine1.service \
+
${datadir}/dbus-1/system-services/org.freedesktop.portable1.service \
${datadir}/dbus-1/system.d/org.freedesktop.import1.conf \
${datadir}/dbus-1/system.d/org.freedesktop.machine1.conf \
+
${datadir}/dbus-1/system.d/org.freedesktop.portable1.conf \
${datadir}/polkit-1/actions/org.freedesktop.import1.policy \
${datadir}/polkit-1/actions/org.freedesktop.machine1.policy \
+
${datadir}/polkit-1/actions/org.freedesktop.portable1.policy \
"
RRECOMMENDS_${PN}-container += "\
--
2.20.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] gcc-9: Add recipes for gcc 9.1 release
On Thu, May 9, 2019 at 1:19 PM Richard Purdie < richard.pur...@linuxfoundation.org> wrote: > On Thu, 2019-05-09 at 11:05 -0700, Khem Raj wrote: > > On Wed, May 8, 2019 at 11:55 PM Mittal, Anuj > > wrote: > > > This is probably causing selftest failure for fortran > > > (test_toolchain_fortran): > > > > > > ERROR: libgfortran-9.1.0-r0 do_package: QA Issue: libgfortran: > > > Files/directories were installed but not shipped in any package: > > > /usr/lib/gcc/x86_64-poky-linux/9.1.0/include > > > /usr/lib/gcc/x86_64-poky- > > > linux/9.1.0/include/ISO_Fortran_binding.h > > > > > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/79/builds/162/steps/7/logs/step2d > > > > > > > fortran is not in default set of languages to build so sent a > > separate > > patch for this here. > > https://patchwork.openembedded.org/patch/161101/ > > > There is a second issue which is why was this mixing gcc 8 and 9 in the > same build. I've sent a patch to add a missing PREFERRED_VERSION. > > We've not run another gcc 9 test, I'll likely merge the gcc 9 version > as non-default and then we can keep testing until it works and we can > make it the default. Yes I have left switching the default for another day intentionally Doing that as a separate patch is right approach I think here and we can push it once all is good > > Cheers, > > Richard > > -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] gcc-9: Add recipes for gcc 9.1 release
On Thu, 2019-05-09 at 11:05 -0700, Khem Raj wrote: > On Wed, May 8, 2019 at 11:55 PM Mittal, Anuj > wrote: > > This is probably causing selftest failure for fortran > > (test_toolchain_fortran): > > > > ERROR: libgfortran-9.1.0-r0 do_package: QA Issue: libgfortran: > > Files/directories were installed but not shipped in any package: > > /usr/lib/gcc/x86_64-poky-linux/9.1.0/include > > /usr/lib/gcc/x86_64-poky- > > linux/9.1.0/include/ISO_Fortran_binding.h > > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/79/builds/162/steps/7/logs/step2d > > > > fortran is not in default set of languages to build so sent a > separate > patch for this here. > https://patchwork.openembedded.org/patch/161101/ There is a second issue which is why was this mixing gcc 8 and 9 in the same build. I've sent a patch to add a missing PREFERRED_VERSION. We've not run another gcc 9 test, I'll likely merge the gcc 9 version as non-default and then we can keep testing until it works and we can make it the default. Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] tcmode-default: Add PREFERRED_VERSION for libgfortran
With the addition of gcc 9 recipes it highlighted there is no PREFERRED_VERSION
set for libgfortran and it should match the rest of gcc. Add this missing
PREFERRED_VERSION line to avoid mixing gcc versions in inadvisable ways.
Signed-off-by: Richard Purdie
---
meta/conf/distro/include/tcmode-default.inc | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/conf/distro/include/tcmode-default.inc
b/meta/conf/distro/include/tcmode-default.inc
index 02e9ddde24a..daacfe28c45 100644
--- a/meta/conf/distro/include/tcmode-default.inc
+++ b/meta/conf/distro/include/tcmode-default.inc
@@ -39,6 +39,7 @@ PREFERRED_VERSION_nativesdk-gcc-runtime ?= "${SDKGCCVERSION}"
PREFERRED_VERSION_nativesdk-gcc-sanitizers ?= "${SDKGCCVERSION}"
PREFERRED_VERSION_libgcc ?= "${GCCVERSION}"
PREFERRED_VERSION_libgcc-initial ?= "${GCCVERSION}"
+PREFERRED_VERSION_libgfortran ?= "${GCCVERSION}"
PREFERRED_VERSION_nativesdk-gcc ?= "${SDKGCCVERSION}"
PREFERRED_VERSION_nativesdk-libgcc ?= "${SDKGCCVERSION}"
PREFERRED_VERSION_nativesdk-libgcc-initial ?= "${SDKGCCVERSION}"
--
2.20.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2] run-postinsts: Fix full execution of scripts at first boot
From: Alejandro Enedino Hernandez Samaniego
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 subshell,
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.
[YOCTO #13266]
Signed-off-by: Alejandro Enedino Hernandez Samaniego
---
meta/recipes-devtools/run-postinsts/run-postinsts/run-postinsts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-devtools/run-postinsts/run-postinsts/run-postinsts
b/meta/recipes-devtools/run-postinsts/run-postinsts/run-postinsts
index 95eff04..f84a7e1 100755
--- a/meta/recipes-devtools/run-postinsts/run-postinsts/run-postinsts
+++ b/meta/recipes-devtools/run-postinsts/run-postinsts/run-postinsts
@@ -67,7 +67,7 @@ exec_postinst_scriptlets() {
echo "Running postinst $i..."
[ "$POSTINST_LOGGING" = "1" ] && eval echo "Running postinst
$i..." $append_log
if [ -x $i ]; then
- eval sh -c $i $append_log
+ (sh -c $i $append_log)
rm $i
else
echo "ERROR: postinst $i failed."
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] procps: update legacy sysctl.conf to fix rp_filter sysctl issue
The sysctl.conf file for procps is very outdated: https://git.openembedded.org/openembedded-core/commit/?id=8a9b9a323f4363e27138077e3e3dce8139a36708 (circa 2014) The origin of this file is hard to determine and due to it's age is causing a routing issue when both wifi and ethernet are enabled. This manifested during an update from thud -> warrior due to the following: - upstream change in NetworkManager during 1.16 cycle removes the dynamic setting of rp_filter sysctl when more than one interface is enabled: https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=b1082aa9a711deb96652e5b2fcaefcf399d127b8 - open-embedded updated to NetworkManager 1.16 in March 2019: https://git.openembedded.org/meta-openembedded/commit/meta-networking/recipes-connectivity/networkmanager?id=5509328af9e4fab267251456f4d6e7bd51df779a - setting in legacy sysctl.conf sets rp_filter to 1 which blocks packets with different inbound and outbound addresses. Documentation of rp_filter setting from kernel.org: rp_filter - INTEGER 0 - No source validation. 1 - Strict mode as defined in RFC3704 Strict Reverse Path Each incoming packet is tested against the FIB and if the interface is not the best reverse path the packet check will fail. By default failed packets are discarded. 2 - Loose mode as defined in RFC3704 Loose Reverse Path Each incoming packet's source address is also tested against the FIB and if the source address is not reachable via any interface the packet check will fail. This patch updates the sysctl.conf file to current which doesn't set the rp_filter mode explicity (2 is the default). NOTE: The kernel/pid_max=1 setting has been commented out as this may not be desired by default. Signed-off-by: Michael Scott --- .../procps/procps/sysctl.conf | 105 +- 1 file changed, 54 insertions(+), 51 deletions(-) diff --git a/meta/recipes-extended/procps/procps/sysctl.conf b/meta/recipes-extended/procps/procps/sysctl.conf index 34e7488bf7..253f3701bd 100644 --- a/meta/recipes-extended/procps/procps/sysctl.conf +++ b/meta/recipes-extended/procps/procps/sysctl.conf @@ -1,64 +1,67 @@ -# This configuration file is taken from Debian. +# This configuration taken from procps v3.3.15 +# Commented out kernel/pid_max=1 line # # /etc/sysctl.conf - Configuration file for setting system variables # See sysctl.conf (5) for information. -# -#kernel.domainname = example.com +# you can have the CD-ROM close when you use it, and open +# when you are done. +#dev.cdrom.autoeject = 1 +#dev.cdrom.autoclose = 1 -# Uncomment the following to stop low-level messages on console -#kernel.printk = 4 4 1 7 +# protection from the SYN flood attack +net/ipv4/tcp_syncookies=1 -##3 -# Functions previously found in netbase -# +# see the evil packets in your log files +net/ipv4/conf/all/log_martians=1 -# Uncomment the next two lines to enable Spoof protection (reverse-path filter) -# Turn on Source Address Verification in all interfaces to -# prevent some spoofing attacks -net.ipv4.conf.default.rp_filter=1 -net.ipv4.conf.all.rp_filter=1 +# makes you vulnerable or not :-) +net/ipv4/conf/all/accept_redirects=0 +net/ipv4/conf/all/accept_source_route=0 +net/ipv4/icmp_echo_ignore_broadcasts =1 -# Uncomment the next line to enable TCP/IP SYN cookies -#net.ipv4.tcp_syncookies=1 +# needed for routing, including masquerading or NAT +#net/ipv4/ip_forward=1 -# Uncomment the next line to enable packet forwarding for IPv4 -#net.ipv4.ip_forward=1 +# sets the port range used for outgoing connections +#net.ipv4.ip_local_port_range = 3276861000 -# Uncomment the next line to enable packet forwarding for IPv6 -#net.ipv6.conf.all.forwarding=1 +# Broken routers and obsolete firewalls will corrupt the window scaling +# and ECN. Set these values to 0 to disable window scaling and ECN. +# This may, rarely, cause some performance loss when running high-speed +# TCP/IP over huge distances or running TCP/IP over connections with high +# packet loss and modern routers. This sure beats dropped connections. +#net.ipv4.tcp_ecn = 0 +# Swapping too much or not enough? Disks spinning up when you'd +# rather they didn't? Tweak these. +#vm.vfs_cache_pressure = 100 +#vm.laptop_mode = 0 +#vm.swappiness = 60 -### -# Additional settings - these settings can improve the network -# security of the host and prevent against some network attacks -# including spoofing attacks and man in the middle attacks through -# redirection. Some network environments, however, require that these -# settings are disabled so review and enable them as needed. -# -# Ignore ICMP broadcasts -#net.ipv4.icmp_echo_ignore_broadcasts = 1 -# -# Ignore bogus ICMP errors -#net.ipv4.icmp_ignore_bogus_error_responses = 1 -# -# Do not accept ICMP redirects (prevent MITM attacks)
[OE-core] [PATCH] libgfortan: Package target gcc include directory to fix
ERROR: libgfortran-9.1.0-r0 do_package: QA Issue: libgfortran:
Files/directories were installed but not shipped in any package:
/usr/lib/gcc/x86_64-poky-linux/9.1.0/include
/usr/lib/gcc/x86_64-poky-linux/9.1.0/include/ISO_Fortran_binding.h
Signed-off-by: Khem Raj
---
meta/recipes-devtools/gcc/libgfortran.inc | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/recipes-devtools/gcc/libgfortran.inc
b/meta/recipes-devtools/gcc/libgfortran.inc
index 4b7b7b2aca..7543585e6e 100644
--- a/meta/recipes-devtools/gcc/libgfortran.inc
+++ b/meta/recipes-devtools/gcc/libgfortran.inc
@@ -66,6 +66,7 @@ FILES_${PN}-dev = "\
${libdir}/gcc/${TARGET_SYS}/${BINV}/libgfortranbegin.* \
${libdir}/gcc/${TARGET_SYS}/${BINV}/libcaf_single* \
${libdir}/gcc/${TARGET_SYS}/${BINV}/finclude/ \
+${libdir}/gcc/${TARGET_SYS}/${BINV}/include/ \
"
FILES_${PN}-staticdev = "${libdir}/libgfortran.a"
--
2.21.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] oeqa/selftest: Automate manual pybootchart tests
Automate the current manual pybootchart tests. This includes a check
for the cairo dependency, skipping the test if appropriate.
Based on original patch from Armin Kuster
Signed-off-by: Richard Purdie
---
meta/lib/oeqa/manual/oe-core.json | 26 -
meta/lib/oeqa/selftest/cases/oescripts.py | 34 +++
2 files changed, 34 insertions(+), 26 deletions(-)
diff --git a/meta/lib/oeqa/manual/oe-core.json
b/meta/lib/oeqa/manual/oe-core.json
index d893d849fb3..3ee0aa95f93 100644
--- a/meta/lib/oeqa/manual/oe-core.json
+++ b/meta/lib/oeqa/manual/oe-core.json
@@ -1,30 +1,4 @@
[
- {
-"test": {
- "@alias":
"oe-core.scripts.Use_scripts/pybootchartgui/pybootchartgui.py_to_generate_build_profiles",
- "author": [
-{
- "email": "alexandru.c.george...@intel.com",
- "name": "alexandru.c.george...@intel.com"
-}
- ],
- "execution": {
-"1": {
- "action": "Run a build for a recipe (e.g. core-image-minimal)",
- "expected_results": ""
-},
-"2": {
- "action": "Run the profiling script,
../scripts/pybootchartgui/pybootchartgui.py tmp/buildstats/\n\n",
- "expected_results": ""
-},
-"3": {
- "action": "Verify the results ",
- "expected_results": "The scripts generates svg files with the
profiling results . "
-}
- },
- "summary":
"Use_scripts/pybootchartgui/pybootchartgui.py_to_generate_build_profiles"
-}
- },
{
"test": {
"@alias": "oe-core.scripts.Crosstap_script_check",
diff --git a/meta/lib/oeqa/selftest/cases/oescripts.py
b/meta/lib/oeqa/selftest/cases/oescripts.py
index 56b35b59eb8..217afe3775b 100644
--- a/meta/lib/oeqa/selftest/cases/oescripts.py
+++ b/meta/lib/oeqa/selftest/cases/oescripts.py
@@ -2,6 +2,7 @@
# SPDX-License-Identifier: MIT
#
+import os
from oeqa.selftest.case import OESelftestTestCase
from oeqa.selftest.cases.buildhistory import BuildhistoryBase
from oeqa.utils.commands import Command, runCmd, bitbake, get_bb_var,
get_test_layer
@@ -28,3 +29,36 @@ class BuildhistoryDiffTests(BuildhistoryBase):
self.fail('Unexpected line:\n%s\nExpected line endings:\n %s'
% (line, '\n '.join(expected_endlines)))
if expected_endlines:
self.fail('Missing expected line endings:\n %s' % '\n
'.join(expected_endlines))
+
+class OEScriptTests(OESelftestTestCase):
+
+@classmethod
+def setUpClass(cls):
+super(OEScriptTests, cls).setUpClass()
+try:
+import cairo
+except ImportError:
+cls.skipTest('Python module cairo is not present')
+bitbake("core-image-minimal -c rootfs -f")
+cls.tmpdir = get_bb_var('TMPDIR')
+cls.buildstats = cls.tmpdir + "/buildstats/" +
sorted(os.listdir(cls.tmpdir + "/buildstats"))[-1]
+
+scripts_dir = os.path.join(get_bb_var('COREBASE'), 'scripts')
+
+class OEPybootchartguyTests(OEScriptTests):
+
+def test_pybootchartguy_help(self):
+runCmd('%s/pybootchartgui/pybootchartgui.py --help' %
self.scripts_dir)
+
+def test_pybootchartguy_to_generate_build_png_output(self):
+runCmd('%s/pybootchartgui/pybootchartgui.py %s -o %s/charts -f png' %
(self.scripts_dir, self.buildstats, self.tmpdir))
+self.assertTrue(os.path.exists(self.tmpdir + "/charts.png"))
+
+def test_pybootchartguy_to_generate_build_svg_output(self):
+runCmd('%s/pybootchartgui/pybootchartgui.py %s -o %s/charts -f svg' %
(self.scripts_dir, self.buildstats, self.tmpdir))
+self.assertTrue(os.path.exists(self.tmpdir + "/charts.svg"))
+
+def test_pybootchartguy_to_generate_build_pdf_output(self):
+runCmd('%s/pybootchartgui/pybootchartgui.py %s -o %s/charts -f pdf' %
(self.scripts_dir, self.buildstats, self.tmpdir))
+self.assertTrue(os.path.exists(self.tmpdir + "/charts.pdf"))
+
--
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] sip/sip3
Thank you, Philip. Yes, that worked fine. It's the solution I preferred.
:rjs
On 5/8/19 8:22 AM, Philip Balister wrote:
On 05/07/2019 08:19 PM, Rudolf J Streif wrote:
With the recent update of sip/sip3 from 4.19.13 to 4.19.16 FILES has
changed:
4.19.13:
|
FILES_python3-sip3 =
"${libdir}/${PYTHON_DIR}${PYTHON_ABI}/site-packages/"
FILES_${PN}-dbg +=
"${libdir}/${PYTHON_DIR}${PYTHON_ABI}/site-packages/.debug"|
4.19.16 (meta-openembedded @ 50108c18):
|
FILES_python-sip = "${libdir}/${PYTHON_DIR}/site-packages/"
FILES_${PN}-dbg += "${libdir}/${PYTHON_DIR}/site-packages/.debug"|
|
|
|
|
That causes an issue with PyQt5 which is installed in (python-pyqt5.inc,
meta-qt5 @ f4531ec8):
echo "py_pylib_dir =
%(sysroot)/${libdir}/python${PYTHON_BASEVERSION}${PYTHON_ABI}" >> pyqt.cfg
PYTHON_BASEVERSION = "3.7"
PYTHON_ABI = "m"
This can obviously be fixed on either end, but I am not quite sure what
the right approach is.
Does this help?
https://github.com/meta-qt5/meta-qt5/pull/202
Thanks for seeing this. Having these tools across two layers is tricky.
The problem is the pyqt can be either in a qt4 layer or a qt 5 later.
And python 2/3 versions.
And the sip recipe really needs to spit out the module used for pyqt.
Philip
Thanks,
Rudi
-
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3396 x700
--
-
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3396 x700
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/2] strace: Fix aarch64 build with musl
On Thu, May 09, 2019 at 02:43:54PM +0100, Richard Purdie wrote: > On Thu, 2019-05-09 at 08:08 -0400, Paul Barker wrote: >... > > So alpine fixes this by patching the linux headers: > > https://git.alpinelinux.org/aports/tree/main/linux-headers/fix-aarch64-asm-ptrace.patch > > > > I think that should be acceptable here if we just do it when building > > with musl libc. > > > > Any thoughts on that before I work up a v2 patch? > > This really needs to get fixed upstream. I don't mind a patch but only > if its gone upstream, we don't want to be carrying patches to libc- > headers. The root problem is that musl upstream has the opinion that the kernel headers are unfixably broken, and therefore the musl headers contain own definitions of structs that are part of the kernel<->userspace ABI: https://wiki.musl-libc.org/faq.html#Q:-Why-am-I-getting- The kernel headers were in a bad state 20 years ago, but are pretty usable today - which doesn't help since musl won't even try to be cooperative and work towards using everything from the kernel headers that belongs there. And the lack of a __MUSL__ define makes it impossible to work around all this musl-specific breakage in an upstreamable way in the kernel headers. There are actually workarounds for musl in the upstream kernel headers, but they can break depending on the #include order. The FAQ above suggests using the patched headers from sabotage linux, but they are from kernel 3.12. > Cheers, > > Richard 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 2/2] strace: Fix aarch64 build with musl
On Thu, 9 May 2019, at 15:07, Bruce Ashfield wrote:
>
>
> On Thu, May 9, 2019 at 10:00 AM Paul Barker wrote:
> > On Thu, 9 May 2019, at 14:48, Bruce Ashfield wrote:
> > >
> > >
> > > On Thu, May 9, 2019 at 9:43 AM Richard Purdie
> > > wrote:
> > > > On Thu, 2019-05-09 at 08:08 -0400, Paul Barker wrote:
> > > > > On Thu, 9 May 2019, at 11:13, Paul Barker wrote:
> > > > > > On Wed, 8 May 2019, at 14:02, Adrian Bunk wrote:
> > > > > > > On Wed, May 08, 2019 at 11:58:36AM +, p...@betafive.co.uk
> > > > > > > wrote:
> > > > > > > > ...
> > > > > > > > +--- strace-4.26.orig/strace.c
> > > > > > > > strace-4.26/strace.c
> > > > > > > > +@@ -26,7 +26,7 @@
> > > > > > > > + #include
> > > > > > > > + #include
> > > > > > > > + #ifdef HAVE_PRCTL
> > > > > > > > +-# include
> > > > > > > > ++# include
> > > > > > > > + #endif
> > > > > > > > + #include
> > > > > > > > diff --git a/meta/recipes-devtools/strace/strace_4.26.bb
> > > > > > > > b/meta/recipes-devtools/strace/strace_4.26.bb
> > > > > > > > index 24f92c99e5..b71122babf 100644
> > > > > > > > --- a/meta/recipes-devtools/strace/strace_4.26.bb
> > > > > > > > +++ b/meta/recipes-devtools/strace/strace_4.26.bb
> > > > > > > > @@ -15,6 +15,7 @@ SRC_URI = "
> > > > > > > > https://strace.io/files/${PV}/strace-${PV}.tar.xz
> >
> > \
> > > > > > > > file://0001-caps-abbrev.awk-fix-gawk-s-path.patch \
> > > > > > > > file://0001-tests-sigaction-Check-for-mips-and-
> > > > > > > > alpha-before-usin.patch \
> > > > > > > > file://0001-mips-o32-fix-build.patch \
> > > > > > > > + file://musl-fixes-armv8.patch \
> > > > > > > > "
> > > > > > > > ...
> > > > > > >
> > > > > > > #include is the documented way for getting the
> > > > > > > prototype
> > > > > > > of prctl(), which cannot be in linux/prctl.h for obvious reasons.
> > > > > > >
> > > > > > > This patch creates the following problem:
> > > > > > >
> > > > > > > ../strace-4.26/strace.c: In function 'startup_child':
> > > > > > > ../strace-4.26/strace.c:1355:3: warning: implicit declaration of
> > > > > > > function 'prctl' [-Wimplicit-function-declaration]
> > > > > > > prctl(PR_SET_PTRACER, PR_SET_PTRACER_ANY);
> > > > > > > ^
> > > > > > >
> > > > > >
> > > > > > Ah that's definitely not a solution then. I'll have to look into
> > > > > > this
> > > > > > further and see if I can come up with a v2 patch that doesn't
> > > > > > cause
> > > > > > this warning.
> > > > > >
> > > > >
> > > > > So alpine fixes this by patching the linux headers:
> > > > >
> > https://git.alpinelinux.org/aports/tree/main/linux-headers/fix-aarch64-asm-ptrace.patch
> > > > >
> > > > > I think that should be acceptable here if we just do it when building
> > > > > with musl libc.
> > > > >
> > > > > Any thoughts on that before I work up a v2 patch?
> > > >
> > > > This really needs to get fixed upstream. I don't mind a patch but only
> > > > if its gone upstream, we don't want to be carrying patches to libc-
> > > > headers.
> > >
> > > I can live with that as well, we have carried them just for musl in the
> > > past, but yes, we should at least know that someone is trying to
> > > upstream it. I can't get the alpine linux git to come in right now, so
> > > I can't check the referenced change to see how it looks.
> > >
> > > I'm going to do new libc-headers when I get the -dev kernel up and
> > > running with the 5.2-rc kernels, so I can watch to see that it
> > > continues to apply. I can also do some extra build testing here, if you
> > > want the headers change to come through my next pull request.
> > >
> >
> > There's a lot of redefinition between musl and the kernel headers that
> > hasn't been reconciled yet (see
> > https://www.spinics.net/lists/y2038/msg03836.html for some discussion) so I
> > think there's much more to be done upstream than just fixing this one
> > instance.
>
> Agreed. There's a long, bikeshedding, philosophical debate about musl
> and headers that is always ongoing (not this discussion, that is not my
> comment). But if this one instance is a small change, I think it is
> worth carrying, the amount of musl patches to libc-headers has
> fluctuated over time, so this is no different. We can only deal with
> the problems we are seeing in our builds (I state the obvious).
>
> >
> > I'm now dropping the `#include ` line in
> > arch/arm64/include/uapi/asm/ptrace.h
> > (https://github.com/torvalds/linux/blob/v5.1/arch/arm64/include/uapi/asm/ptrace.h#L68)
> > in linux-libc-headers and that's giving working builds for me but I'm not
> > sure how universally it can be applied. I'm happy to carry that as a
> > bbappend in our distro layer for now but that will leave strace broke on
> > aarch64 when using musl for others.
> >
>
> I'm still ok with
Re: [OE-core] [PATCH 2/2] strace: Fix aarch64 build with musl
On Thu, May 9, 2019 at 10:00 AM Paul Barker wrote:
> On Thu, 9 May 2019, at 14:48, Bruce Ashfield wrote:
> >
> >
> > On Thu, May 9, 2019 at 9:43 AM Richard Purdie
> > wrote:
> > > On Thu, 2019-05-09 at 08:08 -0400, Paul Barker wrote:
> > > > On Thu, 9 May 2019, at 11:13, Paul Barker wrote:
> > > > > On Wed, 8 May 2019, at 14:02, Adrian Bunk wrote:
> > > > > > On Wed, May 08, 2019 at 11:58:36AM +, p...@betafive.co.uk
> > > > > > wrote:
> > > > > > > ...
> > > > > > > +--- strace-4.26.orig/strace.c
> > > > > > > strace-4.26/strace.c
> > > > > > > +@@ -26,7 +26,7 @@
> > > > > > > + #include
> > > > > > > + #include
> > > > > > > + #ifdef HAVE_PRCTL
> > > > > > > +-# include
> > > > > > > ++# include
> > > > > > > + #endif
> > > > > > > + #include
> > > > > > > diff --git a/meta/recipes-devtools/strace/strace_4.26.bb
> > > > > > > b/meta/recipes-devtools/strace/strace_4.26.bb
> > > > > > > index 24f92c99e5..b71122babf 100644
> > > > > > > --- a/meta/recipes-devtools/strace/strace_4.26.bb
> > > > > > > +++ b/meta/recipes-devtools/strace/strace_4.26.bb
> > > > > > > @@ -15,6 +15,7 @@ SRC_URI = "
> > > > > > > https://strace.io/files/${PV}/strace-${PV}.tar.xz <
> https://strace.io/files/$%7BPV%7D/strace-$%7BPV%7D.tar.xz> \
> > > > > > > file://0001-caps-abbrev.awk-fix-gawk-s-path.patch \
> > > > > > > file://0001-tests-sigaction-Check-for-mips-and-
> > > > > > > alpha-before-usin.patch \
> > > > > > > file://0001-mips-o32-fix-build.patch \
> > > > > > > + file://musl-fixes-armv8.patch \
> > > > > > > "
> > > > > > > ...
> > > > > >
> > > > > > #include is the documented way for getting the
> > > > > > prototype
> > > > > > of prctl(), which cannot be in linux/prctl.h for obvious
> reasons.
> > > > > >
> > > > > > This patch creates the following problem:
> > > > > >
> > > > > > ../strace-4.26/strace.c: In function 'startup_child':
> > > > > > ../strace-4.26/strace.c:1355:3: warning: implicit declaration
> of
> > > > > > function 'prctl' [-Wimplicit-function-declaration]
> > > > > > prctl(PR_SET_PTRACER, PR_SET_PTRACER_ANY);
> > > > > > ^
> > > > > >
> > > > >
> > > > > Ah that's definitely not a solution then. I'll have to look into
> > > > > this
> > > > > further and see if I can come up with a v2 patch that doesn't
> > > > > cause
> > > > > this warning.
> > > > >
> > > >
> > > > So alpine fixes this by patching the linux headers:
> > > >
> https://git.alpinelinux.org/aports/tree/main/linux-headers/fix-aarch64-asm-ptrace.patch
> > > >
> > > > I think that should be acceptable here if we just do it when
> building
> > > > with musl libc.
> > > >
> > > > Any thoughts on that before I work up a v2 patch?
> > >
> > > This really needs to get fixed upstream. I don't mind a patch but only
> > > if its gone upstream, we don't want to be carrying patches to libc-
> > > headers.
> >
> > I can live with that as well, we have carried them just for musl in the
> > past, but yes, we should at least know that someone is trying to
> > upstream it. I can't get the alpine linux git to come in right now, so
> > I can't check the referenced change to see how it looks.
> >
> > I'm going to do new libc-headers when I get the -dev kernel up and
> > running with the 5.2-rc kernels, so I can watch to see that it
> > continues to apply. I can also do some extra build testing here, if you
> > want the headers change to come through my next pull request.
> >
>
> There's a lot of redefinition between musl and the kernel headers that
> hasn't been reconciled yet (see
> https://www.spinics.net/lists/y2038/msg03836.html for some discussion) so
> I think there's much more to be done upstream than just fixing this one
> instance.
>
Agreed. There's a long, bikeshedding, philosophical debate about musl and
headers that is always ongoing (not this discussion, that is not my
comment). But if this one instance is a small change, I think it is worth
carrying, the amount of musl patches to libc-headers has fluctuated over
time, so this is no different. We can only deal with the problems we are
seeing in our builds (I state the obvious).
>
> I'm now dropping the `#include ` line in
> arch/arm64/include/uapi/asm/ptrace.h (
> https://github.com/torvalds/linux/blob/v5.1/arch/arm64/include/uapi/asm/ptrace.h#L68)
> in linux-libc-headers and that's giving working builds for me but I'm not
> sure how universally it can be applied. I'm happy to carry that as a
> bbappend in our distro layer for now but that will leave strace broke on
> aarch64 when using musl for others.
>
>
I'm still ok with patching it out of the headers, build tests would shake
any issues out, but I can't see there being too many.
Bruce
> Thanks,
>
> --
> Paul Barker
> Managing Director & Principal Engineer
> Beta Five Ltd
>
--
- Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end
- "Use the force Harry" - Gandalf, Star Trek II
--
[OE-core] [PATCH 2/2] oeqa/concurrenttest: Patch subunit module to handle classSetup failures
Currently setupClass errors were not being mapped back to the failing tests
and they were hence being marked as UNKNOWN and the test statistics were
inaccurate.
This is because whilst the errors were being encoded into the test results
stream, the decoder doesn't cope with an error outside a testStart event.
We patch in an addError handler to the outsideTest parser so that this
does get handled in a way similar to the non-concurrent case.
It would be nice if we didn't have to do this but there doesn't seem
to be any other way to fix this other than forking subunit.
We also make a minor change so another of our changes can cope with
tests without a start time.
Signed-off-by: Richard Purdie
---
meta/lib/oeqa/core/utils/concurrencytest.py | 27 ++---
1 file changed, 23 insertions(+), 4 deletions(-)
diff --git a/meta/lib/oeqa/core/utils/concurrencytest.py
b/meta/lib/oeqa/core/utils/concurrencytest.py
index 535b11e2d95..6bf7718863f 100644
--- a/meta/lib/oeqa/core/utils/concurrencytest.py
+++ b/meta/lib/oeqa/core/utils/concurrencytest.py
@@ -21,6 +21,7 @@ import testtools
import threading
import time
import io
+import subunit
from queue import Queue
from itertools import cycle
@@ -53,10 +54,11 @@ class
BBThreadsafeForwardingResult(ThreadsafeForwardingResult):
def _add_result_with_semaphore(self, method, test, *args, **kwargs):
self.semaphore.acquire()
try:
-self.result.starttime[test.id()] = self._test_start.timestamp()
-self.result.threadprogress[self.threadnum].append(test.id())
-totalprogress = sum(len(x) for x in
self.result.threadprogress.values())
-self.result.progressinfo[test.id()] = "%s: %s/%s %s/%s (%ss) (%s)"
% (
+if self._test_start:
+self.result.starttime[test.id()] = self._test_start.timestamp()
+self.result.threadprogress[self.threadnum].append(test.id())
+totalprogress = sum(len(x) for x in
self.result.threadprogress.values())
+self.result.progressinfo[test.id()] = "%s: %s/%s %s/%s (%ss)
(%s)" % (
self.threadnum,
len(self.result.threadprogress[self.threadnum]),
self.totalinprocess,
@@ -68,6 +70,23 @@ class
BBThreadsafeForwardingResult(ThreadsafeForwardingResult):
self.semaphore.release()
super(BBThreadsafeForwardingResult,
self)._add_result_with_semaphore(method, test, *args, **kwargs)
+#
+# We have to patch subunit since it doesn't understand how to handle addError
+# outside of a running test case. This can happen if classSetUp() fails
+# for a class of tests. This unfortunately has horrible internal knowledge.
+#
+def outSideTestaddError(self, offset, line):
+"""An 'error:' directive has been read."""
+test_name = line[offset:-1].decode('utf8')
+self.parser._current_test = subunit.RemotedTestCase(test_name)
+self.parser.current_test_description = test_name
+self.parser._state = self.parser._reading_error_details
+self.parser._reading_error_details.set_simple()
+self.parser.subunitLineReceived(line)
+
+subunit._OutSideTest.addError = outSideTestaddError
+
+
#
# A dummy structure to add to io.StringIO so that the .buffer object
# is available and accepts writes. This allows unittest with buffer=True
--
2.20.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] meson.bbclass: add MESON_CROSS_EXTRA_PROPS to inject properties into meson.cross
On Thu, May 9, 2019 at 1:04 PM Burton, Ross wrote:
>
> On Wed, 8 May 2019 at 21:14, Andreas Müller wrote:
> > Some projects rely on (cross)specific properties e.g [1]. By setting
> >
> > MESON_CROSS_EXTRA_PROPS="var1='value1' var2=true"
> >
> > the required properties can be passed to meson.build. The contents of
> > MESON_CROSS_EXTRA_PROPS behave same as known by e.g EXTRA_OEMESON.
> >
> > [1] https://gitlab.gnome.org/GNOME/tracker/blob/master/meson.build#L91
>
> Or see
> https://git.openembedded.org/openembedded-core/commit/?id=e04e0a20cab04966698c50dc79195a8f159248d3
> for an example of how this is done already.
>
> Ross
I have to get back to this.
For the gnome tracker case I have in the recipe
| # full text search requires sqlite3 build with PACKAGECONFIG[fts5] set
| PACKAGECONFIG[fts] = "-Dfts=true,-Dfts=false"
and was happy to handle it correctly the OE way
| MESON_CROSS_EXTRA_PROPS =
"sqlite3_has_fts5='${@bb.utils.contains('PACKAGECONFIG', 'fts',
'true', 'false', d)}'"
Andreas
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/2] oeqa/runner: Fix subunit setupClass/setupModule failure handling
The string format for subunit setupClass/setupModule failures is slightly
different, tweak the regex to correctly handle both cases.
Signed-off-by: Richard Purdie
---
meta/lib/oeqa/core/runner.py | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/lib/oeqa/core/runner.py b/meta/lib/oeqa/core/runner.py
index ca61de8cc0a..930620ea19f 100644
--- a/meta/lib/oeqa/core/runner.py
+++ b/meta/lib/oeqa/core/runner.py
@@ -109,13 +109,13 @@ class OETestResult(_TestResult):
# When fails at module or class level the class name is passed
as string
# so figure out to see if match
-m = re.search(r"^setUpModule \((?P.*)\)$",
scase_str)
+m = re.search(r"^setUpModule \((?P.*)\).*$",
scase_str)
if m:
if case.__class__.__module__ == m.group('module_name'):
found = True
break
-m = re.search(r"^setUpClass \((?P.*)\)$",
scase_str)
+m = re.search(r"^setUpClass \((?P.*)\).*$",
scase_str)
if m:
class_name = "%s.%s" % (case.__class__.__module__,
case.__class__.__name__)
--
2.20.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/2] strace: Fix aarch64 build with musl
On Thu, 9 May 2019, at 14:48, Bruce Ashfield wrote:
>
>
> On Thu, May 9, 2019 at 9:43 AM Richard Purdie
> wrote:
> > On Thu, 2019-05-09 at 08:08 -0400, Paul Barker wrote:
> > > On Thu, 9 May 2019, at 11:13, Paul Barker wrote:
> > > > On Wed, 8 May 2019, at 14:02, Adrian Bunk wrote:
> > > > > On Wed, May 08, 2019 at 11:58:36AM +, p...@betafive.co.uk
> > > > > wrote:
> > > > > > ...
> > > > > > +--- strace-4.26.orig/strace.c
> > > > > > strace-4.26/strace.c
> > > > > > +@@ -26,7 +26,7 @@
> > > > > > + #include
> > > > > > + #include
> > > > > > + #ifdef HAVE_PRCTL
> > > > > > +-# include
> > > > > > ++# include
> > > > > > + #endif
> > > > > > + #include
> > > > > > diff --git a/meta/recipes-devtools/strace/strace_4.26.bb
> > > > > > b/meta/recipes-devtools/strace/strace_4.26.bb
> > > > > > index 24f92c99e5..b71122babf 100644
> > > > > > --- a/meta/recipes-devtools/strace/strace_4.26.bb
> > > > > > +++ b/meta/recipes-devtools/strace/strace_4.26.bb
> > > > > > @@ -15,6 +15,7 @@ SRC_URI = "
> > > > > > https://strace.io/files/${PV}/strace-${PV}.tar.xz
> > \
> > > > > > file://0001-caps-abbrev.awk-fix-gawk-s-path.patch \
> > > > > > file://0001-tests-sigaction-Check-for-mips-and-
> > > > > > alpha-before-usin.patch \
> > > > > > file://0001-mips-o32-fix-build.patch \
> > > > > > + file://musl-fixes-armv8.patch \
> > > > > > "
> > > > > > ...
> > > > >
> > > > > #include is the documented way for getting the
> > > > > prototype
> > > > > of prctl(), which cannot be in linux/prctl.h for obvious reasons.
> > > > >
> > > > > This patch creates the following problem:
> > > > >
> > > > > ../strace-4.26/strace.c: In function 'startup_child':
> > > > > ../strace-4.26/strace.c:1355:3: warning: implicit declaration of
> > > > > function 'prctl' [-Wimplicit-function-declaration]
> > > > > prctl(PR_SET_PTRACER, PR_SET_PTRACER_ANY);
> > > > > ^
> > > > >
> > > >
> > > > Ah that's definitely not a solution then. I'll have to look into
> > > > this
> > > > further and see if I can come up with a v2 patch that doesn't
> > > > cause
> > > > this warning.
> > > >
> > >
> > > So alpine fixes this by patching the linux headers:
> > >
> > https://git.alpinelinux.org/aports/tree/main/linux-headers/fix-aarch64-asm-ptrace.patch
> > >
> > > I think that should be acceptable here if we just do it when building
> > > with musl libc.
> > >
> > > Any thoughts on that before I work up a v2 patch?
> >
> > This really needs to get fixed upstream. I don't mind a patch but only
> > if its gone upstream, we don't want to be carrying patches to libc-
> > headers.
>
> I can live with that as well, we have carried them just for musl in the
> past, but yes, we should at least know that someone is trying to
> upstream it. I can't get the alpine linux git to come in right now, so
> I can't check the referenced change to see how it looks.
>
> I'm going to do new libc-headers when I get the -dev kernel up and
> running with the 5.2-rc kernels, so I can watch to see that it
> continues to apply. I can also do some extra build testing here, if you
> want the headers change to come through my next pull request.
>
There's a lot of redefinition between musl and the kernel headers that hasn't
been reconciled yet (see https://www.spinics.net/lists/y2038/msg03836.html for
some discussion) so I think there's much more to be done upstream than just
fixing this one instance.
I'm now dropping the `#include ` line in
arch/arm64/include/uapi/asm/ptrace.h
(https://github.com/torvalds/linux/blob/v5.1/arch/arm64/include/uapi/asm/ptrace.h#L68)
in linux-libc-headers and that's giving working builds for me but I'm not sure
how universally it can be applied. I'm happy to carry that as a bbappend in our
distro layer for now but that will leave strace broke on aarch64 when using
musl for others.
Thanks,
--
Paul Barker
Managing Director & Principal Engineer
Beta Five Ltd
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2 3/4] mesa: make gallium swrast target optional
Hi there,
On Thu, May 02 2019 at 20:09 +0200, Marco Felsch
wrote:
> Most the time we are compiling for embedded targets which have dedicated
> hardware combinations. Setting swrast default on isn't a good solution
> for such devices because if the hardware render node have an issue or
> don't support a special format/request mesa will fallback to the
> software renderer. This will make it harder to debug performace issues.
>
> A better way is to let the user deciced if a software renderer is
> needed e.g. if the system has no hardware renderer or to have such a
> fallback device. This way the user knows that the software renderer is
> enabled.
>
> Upstream-Status: Submitted [openembedded-core@lists.openembedded.org]
>
> Signed-off-by: Marco Felsch
> ---
> Changelog:
>
> v2:
> - added Upstream-Status line
> - fix leading comma
>
> meta/recipes-graphics/mesa/mesa.inc | 21 -
> 1 file changed, 12 insertions(+), 9 deletions(-)
>
> diff --git a/meta/recipes-graphics/mesa/mesa.inc
> b/meta/recipes-graphics/mesa/mesa.inc
> index 7516a06639..b41d3054c3 100644
> --- a/meta/recipes-graphics/mesa/mesa.inc
> +++ b/meta/recipes-graphics/mesa/mesa.inc
> @@ -86,24 +86,27 @@ PACKAGECONFIG[egl] = "-Degl=true, -Degl=false"
>
> PACKAGECONFIG[etnaviv] = ""
> PACKAGECONFIG[kmsro] = ""
> +PACKAGECONFIG[swrast] = ""
>
> -GALLIUMDRIVERS = "swrast"
> -GALLIUMDRIVERS_append ="${@bb.utils.contains('PACKAGECONFIG', 'etnaviv',
> ',etnaviv', '', d)}"
> -GALLIUMDRIVERS_append ="${@bb.utils.contains('PACKAGECONFIG', 'kmsro',
> ',kmsro', '', d)}"
> +GALLIUMDRIVERS = ""
> +GALLIUMDRIVERS +="${@bb.utils.contains('PACKAGECONFIG', 'swrast', 'swrast',
> '', d)}"
> +GALLIUMDRIVERS +="${@bb.utils.contains('PACKAGECONFIG', 'etnaviv',
> 'etnaviv', '', d)}"
> +GALLIUMDRIVERS +="${@bb.utils.contains('PACKAGECONFIG', 'kmsro', 'kmsro',
> '', d)}"
>
> # radeonsi requires LLVM
> -GALLIUMDRIVERS_LLVM33 = "${@bb.utils.contains('PACKAGECONFIG', 'r600',
> ',radeonsi', '', d)}"
> +GALLIUMDRIVERS_LLVM33 = "${@bb.utils.contains('PACKAGECONFIG', 'r600',
> 'radeonsi', '', d)}"
> GALLIUMDRIVERS_LLVM33_ENABLED =
> "${@oe.utils.version_less_or_equal('MESA_LLVM_RELEASE', '3.2', False,
> len('${GALLIUMDRIVERS_LLVM33}') > 0, d)}"
> -GALLIUMDRIVERS_LLVM = "r300,svga,nouveau${@',${GALLIUMDRIVERS_LLVM33}' if
> ${GALLIUMDRIVERS_LLVM33_ENABLED} else ''}"
> +GALLIUMDRIVERS_LLVM = "r300 svga nouveau ${@'${GALLIUMDRIVERS_LLVM33}' if
> ${GALLIUMDRIVERS_LLVM33_ENABLED} else ''}"
>
> PACKAGECONFIG[r600] = ""
>
> -GALLIUMDRIVERS_append = "${@bb.utils.contains('PACKAGECONFIG',
> 'gallium-llvm', ',${GALLIUMDRIVERS_LLVM}', '', d)}"
> -GALLIUMDRIVERS_append = "${@bb.utils.contains('PACKAGECONFIG', 'r600',
> ',r600', '', d)}"
> -GALLIUMDRIVERS_append = ",virgl"
> +GALLIUMDRIVERS += "${@bb.utils.contains('PACKAGECONFIG', 'gallium-llvm',
> '${GALLIUMDRIVERS_LLVM}', '', d)}"
> +GALLIUMDRIVERS += "${@bb.utils.contains('PACKAGECONFIG', 'r600', 'r600', '',
> d)}"
> +GALLIUMDRIVERS += "virgl"
> +GALLIUMDRIVERS_MESON = "${@",".join("${GALLIUMDRIVERS}".split())}"
how does it have to look like if I want to go without this auxiliary
variable GALLIUMDRIVERS_MESON and instead insert the Python expression
that generates its content directly into ...
> # keep --with-gallium-drivers separate, because when only one of gallium
> versions is enabled, other 2 were adding --without-gallium-drivers
> -PACKAGECONFIG[gallium] = "-Dgallium-drivers=${GALLIUMDRIVERS},
> -Dgallium-drivers=''"
> +PACKAGECONFIG[gallium] = "-Dgallium-drivers=${GALLIUMDRIVERS_MESON},
> -Dgallium-drivers=''"
... the above assignment of PACKAGECONFIG[gallium]?
I can't get it to work - perhaps it is a problem with escaping things?
Best regards
Ulrich
> MESA_LLVM_RELEASE ?= "8.0.0"
> PACKAGECONFIG[gallium-llvm] = "-Dllvm=true -Dshared-llvm=true, -Dllvm=false,
> llvm${MESA_LLVM_RELEASE} llvm-native \
> ${@'elfutils' if
> ${GALLIUMDRIVERS_LLVM33_ENABLED} else ''}"
--
Pengutronix e.K. | Ulrich Ölmann |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/2] strace: Fix aarch64 build with musl
On Thu, 2019-05-09 at 08:08 -0400, Paul Barker wrote:
> On Thu, 9 May 2019, at 11:13, Paul Barker wrote:
> > On Wed, 8 May 2019, at 14:02, Adrian Bunk wrote:
> > > On Wed, May 08, 2019 at 11:58:36AM +, p...@betafive.co.uk
> > > wrote:
> > > > ...
> > > > +--- strace-4.26.orig/strace.c
> > > > strace-4.26/strace.c
> > > > +@@ -26,7 +26,7 @@
> > > > + #include
> > > > + #include
> > > > + #ifdef HAVE_PRCTL
> > > > +-# include
> > > > ++# include
> > > > + #endif
> > > > + #include
> > > > diff --git a/meta/recipes-devtools/strace/strace_4.26.bb
> > > > b/meta/recipes-devtools/strace/strace_4.26.bb
> > > > index 24f92c99e5..b71122babf 100644
> > > > --- a/meta/recipes-devtools/strace/strace_4.26.bb
> > > > +++ b/meta/recipes-devtools/strace/strace_4.26.bb
> > > > @@ -15,6 +15,7 @@ SRC_URI = "
> > > > https://strace.io/files/${PV}/strace-${PV}.tar.xz \
> > > > file://0001-caps-abbrev.awk-fix-gawk-s-path.patch \
> > > > file://0001-tests-sigaction-Check-for-mips-and-
> > > > alpha-before-usin.patch \
> > > > file://0001-mips-o32-fix-build.patch \
> > > > + file://musl-fixes-armv8.patch \
> > > > "
> > > > ...
> > >
> > > #include is the documented way for getting the
> > > prototype
> > > of prctl(), which cannot be in linux/prctl.h for obvious reasons.
> > >
> > > This patch creates the following problem:
> > >
> > > ../strace-4.26/strace.c: In function 'startup_child':
> > > ../strace-4.26/strace.c:1355:3: warning: implicit declaration of
> > > function 'prctl' [-Wimplicit-function-declaration]
> > >prctl(PR_SET_PTRACER, PR_SET_PTRACER_ANY);
> > >^
> > >
> >
> > Ah that's definitely not a solution then. I'll have to look into
> > this
> > further and see if I can come up with a v2 patch that doesn't
> > cause
> > this warning.
> >
>
> So alpine fixes this by patching the linux headers:
> https://git.alpinelinux.org/aports/tree/main/linux-headers/fix-aarch64-asm-ptrace.patch
>
> I think that should be acceptable here if we just do it when building
> with musl libc.
>
> Any thoughts on that before I work up a v2 patch?
This really needs to get fixed upstream. I don't mind a patch but only
if its gone upstream, we don't want to be carrying patches to libc-
headers.
Cheers,
Richard
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/2] strace: Fix aarch64 build with musl
On Thu, May 9, 2019 at 9:43 AM Richard Purdie <
richard.pur...@linuxfoundation.org> wrote:
> On Thu, 2019-05-09 at 08:08 -0400, Paul Barker wrote:
> > On Thu, 9 May 2019, at 11:13, Paul Barker wrote:
> > > On Wed, 8 May 2019, at 14:02, Adrian Bunk wrote:
> > > > On Wed, May 08, 2019 at 11:58:36AM +, p...@betafive.co.uk
> > > > wrote:
> > > > > ...
> > > > > +--- strace-4.26.orig/strace.c
> > > > > strace-4.26/strace.c
> > > > > +@@ -26,7 +26,7 @@
> > > > > + #include
> > > > > + #include
> > > > > + #ifdef HAVE_PRCTL
> > > > > +-# include
> > > > > ++# include
> > > > > + #endif
> > > > > + #include
> > > > > diff --git a/meta/recipes-devtools/strace/strace_4.26.bb
> > > > > b/meta/recipes-devtools/strace/strace_4.26.bb
> > > > > index 24f92c99e5..b71122babf 100644
> > > > > --- a/meta/recipes-devtools/strace/strace_4.26.bb
> > > > > +++ b/meta/recipes-devtools/strace/strace_4.26.bb
> > > > > @@ -15,6 +15,7 @@ SRC_URI = "
> > > > > https://strace.io/files/${PV}/strace-${PV}.tar.xz \
> > > > > file://0001-caps-abbrev.awk-fix-gawk-s-path.patch \
> > > > > file://0001-tests-sigaction-Check-for-mips-and-
> > > > > alpha-before-usin.patch \
> > > > > file://0001-mips-o32-fix-build.patch \
> > > > > + file://musl-fixes-armv8.patch \
> > > > > "
> > > > > ...
> > > >
> > > > #include is the documented way for getting the
> > > > prototype
> > > > of prctl(), which cannot be in linux/prctl.h for obvious reasons.
> > > >
> > > > This patch creates the following problem:
> > > >
> > > > ../strace-4.26/strace.c: In function 'startup_child':
> > > > ../strace-4.26/strace.c:1355:3: warning: implicit declaration of
> > > > function 'prctl' [-Wimplicit-function-declaration]
> > > >prctl(PR_SET_PTRACER, PR_SET_PTRACER_ANY);
> > > >^
> > > >
> > >
> > > Ah that's definitely not a solution then. I'll have to look into
> > > this
> > > further and see if I can come up with a v2 patch that doesn't
> > > cause
> > > this warning.
> > >
> >
> > So alpine fixes this by patching the linux headers:
> >
> https://git.alpinelinux.org/aports/tree/main/linux-headers/fix-aarch64-asm-ptrace.patch
> >
> > I think that should be acceptable here if we just do it when building
> > with musl libc.
> >
> > Any thoughts on that before I work up a v2 patch?
>
> This really needs to get fixed upstream. I don't mind a patch but only
> if its gone upstream, we don't want to be carrying patches to libc-
> headers.
>
I can live with that as well, we have carried them just for musl in the
past, but yes, we should at least know that someone is trying to upstream
it. I can't get the alpine linux git to come in right now, so I can't check
the referenced change to see how it looks.
I'm going to do new libc-headers when I get the -dev kernel up and running
with the 5.2-rc kernels, so I can watch to see that it continues to apply.
I can also do some extra build testing here, if you want the headers change
to come through my next pull request.
Bruce
>
> Cheers,
>
> Richard
>
>
--
- Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end
- "Use the force Harry" - Gandalf, Star Trek II
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] lttng-modules: upgrade 2.10.8 -> 2.10.9
On Thu, May 09, 2019 at 08:09:54PM +0800, Kevin Hao wrote: > > I just sent out a patch to bump the kernel version for these BSPs. Thanks a lot! > Thanks, > Kevin 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] meson.bbclass: add MESON_CROSS_EXTRA_PROPS to inject properties into meson.cross
On Thu, May 9, 2019 at 2:03 PM Andreas Müller wrote: > So for me to understand it correctly: adding multiple '--cross-file' > entries in commandline accumulates the contents of the files and it is > not the last that wins? > > I am asking because help says 'File describing cross compilation > environment.' so I wouldn't expect this behaviour. > Answer myself - and guess who did it :)) https://github.com/mesonbuild/meson/blob/master/docs/markdown/snippets/multiple-cross-files.md Andreas -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] lttng-modules: upgrade 2.10.8 -> 2.10.9
On Wed, May 08, 2019 at 09:38:50PM +0100, richard.pur...@linuxfoundation.org wrote: > On Wed, 2019-05-08 at 23:30 +0300, Adrian Bunk wrote: > > On Wed, May 08, 2019 at 09:06:19PM +0100, Richard Purdie wrote: > > > On Tue, 2019-05-07 at 16:11 +0300, Adrian Bunk wrote: > > > > Remove the backported patches. > > > > > > > > Signed-off-by: Adrian Bunk > > > > > > Unfortunately this seemed to cause: > > > > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/46/builds/574 > > > > ... > > recipe linux-yocto-4.19.14+gitAUTOINC+9bda6190bf_eebb51300a-r0: task > > do_compile: Succeeded > > ... > > In file included from > > /home/pokybuild/yocto-worker/beaglebone-lsb/build/build/tmp/work/beaglebone_yocto-poky-linux-gnueabi/lttng-modules/2.10.9-r0/lttng-modules-2.10.9/probes/lttng-kprobes.c:31: > > > /home/pokybuild/yocto-worker/beaglebone-lsb/build/build/tmp/work/beaglebone_yocto-poky-linux-gnueabi/lttng-modules/2.10.9-r0/lttng-modules-2.10.9/probes/../blacklist/kprobes.h:19:4: > > > error: #error "Your kernel is known to have buggy optimized kprobes > > > implementation. Fixed by commit 0ac569bf6a7983c0c5747d6df8db9dc05bc92b6c > > > \"ARM: 8834/1: Fix: kprobes: optimized kprobes illegal instruction\" in > > > Linux. Disable CONFIG_OPTPROBES or upgrade your kernel." > > > # error "Your kernel is known to have buggy optimized kprobes > > > implementation. Fixed by commit 0ac569bf6a7983c0c5747d6df8db9dc05bc92b6c > > > \"ARM: 8834/1: Fix: kprobes: optimized kprobes illegal instruction\" in > > > Linux. Disable CONFIG_OPTPROBES or upgrade your kernel." > > > ^ > > > make[4]: *** > > [/home/pokybuild/yocto-worker/beaglebone-lsb/build/build/tmp/work/beaglebone_yocto-poky-linux-gnueabi/lttng-modules/2.10.9-r0/lttng-modules-2.10.9/probes/lttng-kprobes.o] > > Error 1 > > ... > > > > > > Upstream turned a runtime breakage into a build failure: > > http://git.lttng.org/?p=lttng-modules.git;a=commit;h=2d16de12b197aed57212826187bcb0ab24ad071e > > > > IOW, this needs an update of beaglebone-yocto in > > meta-yocto-bsp/recipes-kernel/linux/linux-yocto_4.19.bbappend > > (4.19.34 already seems to be in the git tree). > > Right, sorry, I hadn't actually read the error :/. > > CCing Kevin/Bruce. I just sent out a patch to bump the kernel version for these BSPs. Thanks, Kevin > > Cheers, > > Richard > > > signature.asc Description: PGP signature -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/2] strace: Fix aarch64 build with musl
On Thu, 9 May 2019, at 11:13, Paul Barker wrote:
> On Wed, 8 May 2019, at 14:02, Adrian Bunk wrote:
> > On Wed, May 08, 2019 at 11:58:36AM +, p...@betafive.co.uk wrote:
> > >...
> > > +--- strace-4.26.orig/strace.c
> > > strace-4.26/strace.c
> > > +@@ -26,7 +26,7 @@
> > > + #include
> > > + #include
> > > + #ifdef HAVE_PRCTL
> > > +-# include
> > > ++# include
> > > + #endif
> > > + #include
> > > diff --git a/meta/recipes-devtools/strace/strace_4.26.bb
> > > b/meta/recipes-devtools/strace/strace_4.26.bb
> > > index 24f92c99e5..b71122babf 100644
> > > --- a/meta/recipes-devtools/strace/strace_4.26.bb
> > > +++ b/meta/recipes-devtools/strace/strace_4.26.bb
> > > @@ -15,6 +15,7 @@ SRC_URI =
> > > "https://strace.io/files/${PV}/strace-${PV}.tar.xz \
> > > file://0001-caps-abbrev.awk-fix-gawk-s-path.patch \
> > >
> > > file://0001-tests-sigaction-Check-for-mips-and-alpha-before-usin.patch \
> > > file://0001-mips-o32-fix-build.patch \
> > > + file://musl-fixes-armv8.patch \
> > > "
> > >...
> >
> > #include is the documented way for getting the prototype
> > of prctl(), which cannot be in linux/prctl.h for obvious reasons.
> >
> > This patch creates the following problem:
> >
> > ../strace-4.26/strace.c: In function 'startup_child':
> > ../strace-4.26/strace.c:1355:3: warning: implicit declaration of
> > function 'prctl' [-Wimplicit-function-declaration]
> >prctl(PR_SET_PTRACER, PR_SET_PTRACER_ANY);
> >^
> >
>
> Ah that's definitely not a solution then. I'll have to look into this
> further and see if I can come up with a v2 patch that doesn't cause
> this warning.
>
So alpine fixes this by patching the linux headers:
https://git.alpinelinux.org/aports/tree/main/linux-headers/fix-aarch64-asm-ptrace.patch
I think that should be acceptable here if we just do it when building with musl
libc.
Any thoughts on that before I work up a v2 patch?
Thanks,
--
Paul Barker
Managing Director & Principal Engineer
Beta Five Ltd
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] meson.bbclass: add MESON_CROSS_EXTRA_PROPS to inject properties into meson.cross
On Thu, May 9, 2019 at 1:41 PM Andreas Müller wrote: > > On Thu, May 9, 2019 at 1:04 PM Burton, Ross wrote: > > > > On Wed, 8 May 2019 at 21:14, Andreas Müller wrote: > > > Some projects rely on (cross)specific properties e.g [1]. By setting > > > > > > MESON_CROSS_EXTRA_PROPS="var1='value1' var2=true" > > > > > > the required properties can be passed to meson.build. The contents of > > > MESON_CROSS_EXTRA_PROPS behave same as known by e.g EXTRA_OEMESON. > > > > > > [1] https://gitlab.gnome.org/GNOME/tracker/blob/master/meson.build#L91 > > > > Or see > > https://git.openembedded.org/openembedded-core/commit/?id=e04e0a20cab04966698c50dc79195a8f159248d3 > > for an example of how this is done already. > > > Sometimes the sending of patches is the secret attempt to gather information > :) > > Thanks > So for me to understand it correctly: adding multiple '--cross-file' entries in commandline accumulates the contents of the files and it is not the last that wins? I am asking because help says 'File describing cross compilation environment.' so I wouldn't expect this behaviour. Andreas -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] meson.bbclass: add MESON_CROSS_EXTRA_PROPS to inject properties into meson.cross
On Thu, May 9, 2019 at 1:04 PM Burton, Ross wrote: > > On Wed, 8 May 2019 at 21:14, Andreas Müller wrote: > > Some projects rely on (cross)specific properties e.g [1]. By setting > > > > MESON_CROSS_EXTRA_PROPS="var1='value1' var2=true" > > > > the required properties can be passed to meson.build. The contents of > > MESON_CROSS_EXTRA_PROPS behave same as known by e.g EXTRA_OEMESON. > > > > [1] https://gitlab.gnome.org/GNOME/tracker/blob/master/meson.build#L91 > > Or see > https://git.openembedded.org/openembedded-core/commit/?id=e04e0a20cab04966698c50dc79195a8f159248d3 > for an example of how this is done already. > Sometimes the sending of patches is the secret attempt to gather information :) Thanks Andreas -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] meson.bbclass: add MESON_CROSS_EXTRA_PROPS to inject properties into meson.cross
On Wed, 8 May 2019 at 21:14, Andreas Müller wrote: > Some projects rely on (cross)specific properties e.g [1]. By setting > > MESON_CROSS_EXTRA_PROPS="var1='value1' var2=true" > > the required properties can be passed to meson.build. The contents of > MESON_CROSS_EXTRA_PROPS behave same as known by e.g EXTRA_OEMESON. > > [1] https://gitlab.gnome.org/GNOME/tracker/blob/master/meson.build#L91 Or see https://git.openembedded.org/openembedded-core/commit/?id=e04e0a20cab04966698c50dc79195a8f159248d3 for an example of how this is done already. Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v3] ccache: upgrade 3.6 -> 3.7.1
Remove backported patches.
Switch to new download location.
Signed-off-by: Adrian Bunk
---
meta/recipes-devtools/ccache/ccache.inc | 2 +-
meta/recipes-devtools/ccache/ccache_3.6.bb| 12 ---
meta/recipes-devtools/ccache/ccache_3.7.1.bb | 7 ++
...002-dev.mk.in-fix-file-name-too-long.patch | 30 ---
...tion-fault-error-when-gcc-o-dev-null.patch | 79 ---
5 files changed, 8 insertions(+), 122 deletions(-)
delete mode 100644 meta/recipes-devtools/ccache/ccache_3.6.bb
create mode 100644 meta/recipes-devtools/ccache/ccache_3.7.1.bb
delete mode 100644
meta/recipes-devtools/ccache/files/0002-dev.mk.in-fix-file-name-too-long.patch
delete mode 100644
meta/recipes-devtools/ccache/files/0003-Fix-Segmentation-fault-error-when-gcc-o-dev-null.patch
diff --git a/meta/recipes-devtools/ccache/ccache.inc
b/meta/recipes-devtools/ccache/ccache.inc
index 7f800659a3..a31acada57 100644
--- a/meta/recipes-devtools/ccache/ccache.inc
+++ b/meta/recipes-devtools/ccache/ccache.inc
@@ -9,7 +9,7 @@ LICENSE = "GPLv3+"
DEPENDS = "zlib"
-SRC_URI = "https://download.samba.org/pub/${BPN}/${BP}.tar.gz;
+SRC_URI =
"https://github.com/ccache/ccache/releases/download/v${PV}/${BP}.tar.gz;
inherit autotools
diff --git a/meta/recipes-devtools/ccache/ccache_3.6.bb
b/meta/recipes-devtools/ccache/ccache_3.6.bb
deleted file mode 100644
index 60807be0ae..00
--- a/meta/recipes-devtools/ccache/ccache_3.6.bb
+++ /dev/null
@@ -1,12 +0,0 @@
-require ccache.inc
-
-LICENSE = "GPLv3+"
-LIC_FILES_CHKSUM = "file://LICENSE.adoc;md5=70762511f9c509cc2a4e4ba2ef687ae3"
-
-SRC_URI[md5sum] = "bd6fd69db28426baf22ec0acdd5c4b2a"
-SRC_URI[sha256sum] =
"a3f2b91a2353b65a863c5901251efe48060ecdebec46b5eaec8ea8e092b9e871"
-
-SRC_URI += " \
-file://0002-dev.mk.in-fix-file-name-too-long.patch \
-file://0003-Fix-Segmentation-fault-error-when-gcc-o-dev-null.patch
\
-"
diff --git a/meta/recipes-devtools/ccache/ccache_3.7.1.bb
b/meta/recipes-devtools/ccache/ccache_3.7.1.bb
new file mode 100644
index 00..1db7094b73
--- /dev/null
+++ b/meta/recipes-devtools/ccache/ccache_3.7.1.bb
@@ -0,0 +1,7 @@
+require ccache.inc
+
+LICENSE = "GPLv3+"
+LIC_FILES_CHKSUM = "file://LICENSE.adoc;md5=0094c59039cec66b8a4c905204333514"
+
+SRC_URI[md5sum] = "74339465ab87e0b406985ed69515f19b"
+SRC_URI[sha256sum] =
"e562fcdbe766406b6fe4bf97ce5c001d2be8a17465f33bcddefc9499bbb057d8"
diff --git
a/meta/recipes-devtools/ccache/files/0002-dev.mk.in-fix-file-name-too-long.patch
b/meta/recipes-devtools/ccache/files/0002-dev.mk.in-fix-file-name-too-long.patch
deleted file mode 100644
index 16a6e9d80f..00
---
a/meta/recipes-devtools/ccache/files/0002-dev.mk.in-fix-file-name-too-long.patch
+++ /dev/null
@@ -1,30 +0,0 @@
-From 7dab2995ed8eeccd7b0acd79668bc28f3a2427d5 Mon Sep 17 00:00:00 2001
-From: Robert Yang
-Date: Wed, 16 Sep 2015 19:45:40 -0700
-Subject: [PATCH] dev.mk.in: fix file name too long error
-
-The all_cppflags changes path to filename which causes file name too long
-error when the path is longer than NAME_MAX (usually 255). Strip srcdir
-to fix the problem.
-
-Upstream-Status: Backport
[https://github.com/ccache/ccache/commit/4d86e884d07ba1853a0c70507cc4d04107f57c29]
-
-Signed-off-by: Robert Yang
-
- dev.mk.in | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/dev.mk.in b/dev.mk.in
-index 91b0a57..583ade0 100644
a/dev.mk.in
-+++ b/dev.mk.in
-@@ -1,7 +1,7 @@
- # GNU make syntax reigns in this file.
-
- all_cflags += -Werror @more_warnings@
--all_cppflags += -MD -MP -MF .deps/$(subst .._,,$(subst /,_,$<)).d
-+all_cppflags += -MD -MP -MF .deps/$(subst .._,,$(subst /,_,$(subst
$(srcdir)/,,$<))).d
-
- A2X = a2x
- ASCIIDOC = asciidoc
diff --git
a/meta/recipes-devtools/ccache/files/0003-Fix-Segmentation-fault-error-when-gcc-o-dev-null.patch
b/meta/recipes-devtools/ccache/files/0003-Fix-Segmentation-fault-error-when-gcc-o-dev-null.patch
deleted file mode 100644
index b3012b7e89..00
---
a/meta/recipes-devtools/ccache/files/0003-Fix-Segmentation-fault-error-when-gcc-o-dev-null.patch
+++ /dev/null
@@ -1,79 +0,0 @@
-From c51b63758e95247e3c1e2f06e5f5bfb49849e66d Mon Sep 17 00:00:00 2001
-From: Robert Yang
-Date: Tue, 22 Jan 2019 16:30:52 +0800
-Subject: [PATCH] Fix Segmentation fault error when gcc -o /dev/null
-
-Fixed:
-$ export CCACHE_DEBUG=1
-$ ccache gcc -c hello.c -o /dev/null
-
-Segmentation fault (core dumped)
-
-This is because failed to open /dev/null.foo (Permission denied), check file
-stream before write to it can fix the problem.
-
-Upstream-Status: Backport
[https://github.com/ccache/ccache/commit/4d86e884d07ba1853a0c70507cc4d04107f57c29]
-
-Signed-off-by: Robert Yang
- src/ccache.c | 15 ---
- src/util.c | 8 ++--
- 2 files changed, 18 insertions(+), 5 deletions(-)
-
-diff --git a/src/ccache.c b/src/ccache.c
-index b4cdb86..8c227df 100644
a/src/ccache.c
-+++ b/src/ccache.c
-@@ -521,9 +521,13 @@
Re: [OE-core] [PATCH] ccache: upgrade 3.6 -> 3.7.1
On Wed, May 08, 2019 at 10:47:38PM +0100, Richard Purdie wrote: > On Tue, 2019-05-07 at 16:11 +0300, Adrian Bunk wrote: > > Remove backported patches. > > Switch to new download location. > > > > Signed-off-by: Adrian Bunk > > This patch caused an unintended side effect which you can reproduce > with: > > oe-selftest -r buildoptions.ImageOptionsTests.test_ccache_tool > > Its the change from .gz to .xz which introduces circular dependencies > for ccache-native. >... OK, I'm sending v3 using .gz. > Cheers, > > Richard 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 2/2] strace: Fix aarch64 build with musl
On Wed, 8 May 2019, at 14:02, Adrian Bunk wrote:
> On Wed, May 08, 2019 at 11:58:36AM +, p...@betafive.co.uk wrote:
> >...
> > +--- strace-4.26.orig/strace.c
> > strace-4.26/strace.c
> > +@@ -26,7 +26,7 @@
> > + #include
> > + #include
> > + #ifdef HAVE_PRCTL
> > +-# include
> > ++# include
> > + #endif
> > + #include
> > diff --git a/meta/recipes-devtools/strace/strace_4.26.bb
> > b/meta/recipes-devtools/strace/strace_4.26.bb
> > index 24f92c99e5..b71122babf 100644
> > --- a/meta/recipes-devtools/strace/strace_4.26.bb
> > +++ b/meta/recipes-devtools/strace/strace_4.26.bb
> > @@ -15,6 +15,7 @@ SRC_URI =
> > "https://strace.io/files/${PV}/strace-${PV}.tar.xz \
> > file://0001-caps-abbrev.awk-fix-gawk-s-path.patch \
> >
> > file://0001-tests-sigaction-Check-for-mips-and-alpha-before-usin.patch \
> > file://0001-mips-o32-fix-build.patch \
> > + file://musl-fixes-armv8.patch \
> > "
> >...
>
> #include is the documented way for getting the prototype
> of prctl(), which cannot be in linux/prctl.h for obvious reasons.
>
> This patch creates the following problem:
>
> ../strace-4.26/strace.c: In function 'startup_child':
> ../strace-4.26/strace.c:1355:3: warning: implicit declaration of
> function 'prctl' [-Wimplicit-function-declaration]
>prctl(PR_SET_PTRACER, PR_SET_PTRACER_ANY);
>^
>
Ah that's definitely not a solution then. I'll have to look into this further
and see if I can come up with a v2 patch that doesn't cause this warning.
--
Paul Barker
Managing Director & Principal Engineer
Beta Five Ltd
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/2] weston-init: Add support for non-root start
From: Breno Leitao
This commit adds support for two variables (WESTON_USER and WESTON_TTY) that
would be passed to weston_launch. It allows starting weston as a non-root user.
Signed-off-by: Breno Leitao
---
.../wayland/weston-init/weston-start| 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-graphics/wayland/weston-init/weston-start
b/meta/recipes-graphics/wayland/weston-init/weston-start
index 0c4fee23d5..86c68fc533 100755
--- a/meta/recipes-graphics/wayland/weston-init/weston-start
+++ b/meta/recipes-graphics/wayland/weston-init/weston-start
@@ -27,10 +27,19 @@ if [ -n "$WAYLAND_DISPLAY" ]; then
echo "ERROR: A Wayland compositor is already running, nested Weston
instance is not supported yet."
exit 1
fi
+
+if [ -n "$WESTON_USER" ]; then
+ if [ -z "$WESTON_TTY" ]; then
+ echo "ERROR: If you have WESTON_USER variable set, you also
need WESTON_TTY."
+ exit 1
+ fi
+ weston_args_user="-u $WESTON_USER -t $WESTON_TTY"
+fi
+
if [ -n "$DISPLAY" ]; then
launcher="weston"
else
- launcher="weston-launch --"
+ launcher="weston-launch $weston_args_user --"
fi
openvt_args="-s"
@@ -59,11 +68,15 @@ if [ -d "$modules_dir" ]; then
fi
if test -z "$XDG_RUNTIME_DIR"; then
- export XDG_RUNTIME_DIR=/run/user/`id -u`
+ export XDG_RUNTIME_DIR=/run/user/`id -u ${WESTON_USER}`
if ! test -d "$XDG_RUNTIME_DIR"; then
mkdir --parents $XDG_RUNTIME_DIR
chmod 0700 $XDG_RUNTIME_DIR
fi
+ if [ -n "$WESTON_USER" ]
+ then
+ chown $WEST_USER:$WESTON_USER $XDG_RUNTIME_DIR
+ fi
fi
exec openvt $openvt_args -- $launcher $weston_args
--log=@LOCALSTATEDIR@/log/weston.log
--
2.17.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/2] weston-init: Fix tab indentation
From: Breno Leitao
This patch simply fixes space and tab mixes. It converts space to tabs. This is
being done since I am going to change the code in the next commit and I do not
want to change more lines than it is required, thus, I am creating a commit
just to fix indentation, so I can create a cleaner patch later.
Signed-off-by: Breno Leitao
---
.../wayland/weston-init/weston-start | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/meta/recipes-graphics/wayland/weston-init/weston-start
b/meta/recipes-graphics/wayland/weston-init/weston-start
index e72fbaaac4..0c4fee23d5 100755
--- a/meta/recipes-graphics/wayland/weston-init/weston-start
+++ b/meta/recipes-graphics/wayland/weston-init/weston-start
@@ -5,8 +5,8 @@
export PATH="/sbin:/usr/sbin:/bin:/usr/bin"
usage() {
-cat <] [-- ]
+ cat <] [-- ]
EOF
}
@@ -59,11 +59,11 @@ if [ -d "$modules_dir" ]; then
fi
if test -z "$XDG_RUNTIME_DIR"; then
-export XDG_RUNTIME_DIR=/run/user/`id -u`
-if ! test -d "$XDG_RUNTIME_DIR"; then
-mkdir --parents $XDG_RUNTIME_DIR
-chmod 0700 $XDG_RUNTIME_DIR
-fi
+ export XDG_RUNTIME_DIR=/run/user/`id -u`
+ if ! test -d "$XDG_RUNTIME_DIR"; then
+ mkdir --parents $XDG_RUNTIME_DIR
+ chmod 0700 $XDG_RUNTIME_DIR
+ fi
fi
exec openvt $openvt_args -- $launcher $weston_args
--log=@LOCALSTATEDIR@/log/weston.log
--
2.17.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Review request 0/1: LIN1019-1252 run 'shutdown -P now' on vm and shutdown failed
Please ignore.
Thanks,
Zhe
On 5/9/19 5:49 PM, zhe...@windriver.com wrote:
> From: zhe...@windriver.com Mon Sep 17 00:00:00 2001
>
> Summary: LIN1019-1252 run 'shutdown -P now' on vm and shutdown failed
> Tech Review: Qi Chen
> Gatekeeper: Robert
> Lockdown Approval (if needed):
> Branch Tag: wr-10.19-20190505
>
> IP Statement (form link or license statement, usually automated):
> Crypto URL(s) (if needed): see
> http://wiki.wrs.com/PBUeng/LinuxProductDivisionExportProcess
> Parent Template (where applicable):
>
>
> == Sanity Issues: (DO NOT EDIT this section) ==
>
>
>
> == Impacted area Impact y/n ==
> docs/tech-pubs n
> tests n
> build systemn
> host dependencies n
> RPM/packaging n
> toolchain n
> kernel code n
> user code y
> configuration files n
> target configurationn
> Applicable to Yocto/upstreamn
> New Kernel Warnings n
> Other n
>
>
> == Comments (indicate scope for each "y" above) ==
> * Conditions of submission
>
> * Documentation Changes/Release Notes
> = Doc changes
>
> = Release notes
>
> * Git logs
>
>
> == Testing ==
> * Commands
> setup.sh --machine qemux86-64 --distro wrlinux --dl-layers
> . ./oe-init-build-env
> bitbake wrlinux-image-glibc-std
> runqemu qemux86-64 nographic
> root
> shutdown now
>
> * Expected Results
> shut down successfully
>
> * Applicable to
>
> * Tested configurations
>
> Archbuilt boot boardname
> -
> MIPS n n
> MIPS64n n
> MIPS64n32 n n
> ARM32 n n
> ARM64 n n
> x86 n n
> x86_64n y 22015
> PPC n n
> PPC64 n n
> SPARC64 n n
>
>
> == Reviewer Checklist ==
> [Submitters: make sure that your review doesn't trigger any checkmarks!]
> http://lxgit.wrs.com/cgit/bin.git/tree/etc/review.txt
>
>
> == PULLs ==
> * The branch is made of: __
> git://128.224.158.51/git/oe-core zhe/wr-10.19-20190505__1__20190509174633
>
> * WRH-PULLs ("wrh -m" can merge it):
>
> git://128.224.158.51/git/oe-core__s__zhe/wr-10.19-20190505__1__20190509174633
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] webkitgtk: fix compile error for arm64
On 2019/4/23 下午6:12, kai.k...@windriver.com wrote: From: Kai Kang It removes function JSC::AssemblerBuffer::data() for ARM64 in commit https://trac.webkit.org/changeset/236589/webkit. But it is required by Cortex A53 from https://trac.webkit.org/changeset/175514/webkit and fails to compile for arm64: | .../tmp/work/aarch64-poky-linux/webkitgtk/2.24.0-r0/webkitgtk-2.24.0/Source/JavaScriptCore/assembler/ARM64Assembler.h:3769:100: error: 'class JSC::AssemblerBuffer' has no member named 'data' | if (UNLIKELY((*reinterpret_cast_ptr(reinterpret_cast_ptr(m_buffer.data()) + m_buffer.codeSize() - sizeof(int32_t)) & 0x0a00) == 0x0800)) Not set WTF_CPU_ARM64_CORTEXA53 for arm64 to fix the failure. Any comment please? It still fails even apply the patch to update to 2.24.1 for qemuarm64. Regards, Kai Signed-off-by: Kai Kang --- meta/recipes-sato/webkit/webkitgtk_2.24.0.bb | 2 -- 1 file changed, 2 deletions(-) diff --git a/meta/recipes-sato/webkit/webkitgtk_2.24.0.bb b/meta/recipes-sato/webkit/webkitgtk_2.24.0.bb index 4a82dae9ef..54daa217bb 100644 --- a/meta/recipes-sato/webkit/webkitgtk_2.24.0.bb +++ b/meta/recipes-sato/webkit/webkitgtk_2.24.0.bb @@ -92,8 +92,6 @@ EXTRA_OECMAKE_append_aarch64 = " -DUSE_LD_GOLD=OFF " EXTRA_OECMAKE_append_mipsarch = " -DUSE_LD_GOLD=OFF " EXTRA_OECMAKE_append_powerpc = " -DUSE_LD_GOLD=OFF " -EXTRA_OECMAKE_append_aarch64 = " -DWTF_CPU_ARM64_CORTEXA53=ON" - # JIT not supported on MIPS either EXTRA_OECMAKE_append_mipsarch = " -DENABLE_JIT=OFF " -- Kai Kang -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] systemd: Bump up SRCREV to systemd-stable top to include the fix for shutdown now hang
From: He Zhe
"shutdown now" makes systemd hang at the following line.
[ OK ] Stopped Session c1 of user root.
It's already been fixed by 03cb25525423 ("socket-util: make sure flush_accept()
doesn't hang on unexpected EOPNOTSUPP")
Signed-off-by: He Zhe
---
meta/recipes-core/systemd/systemd.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-core/systemd/systemd.inc
b/meta/recipes-core/systemd/systemd.inc
index 193087a..3a353b0 100644
--- a/meta/recipes-core/systemd/systemd.inc
+++ b/meta/recipes-core/systemd/systemd.inc
@@ -14,7 +14,7 @@ LICENSE = "GPLv2 & LGPLv2.1"
LIC_FILES_CHKSUM = "file://LICENSE.GPL2;md5=751419260aa954499f7abaabaa882bbe \
file://LICENSE.LGPL2.1;md5=4fbd65380cdd255951079008b364516c"
-SRCREV = "1e5d2d656420d0e755dbcf72aeba3c3aba54e956"
+SRCREV = "db2e367bfc3b119609f837eb973d915f6c550b2f"
SRCBRANCH = "v242-stable"
SRC_URI =
"git://github.com/systemd/systemd-stable.git;protocol=git;branch=${SRCBRANCH}"
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] Review request 0/1: LIN1019-1252 run 'shutdown -P now' on vm and shutdown failed
From: zhe...@windriver.com Mon Sep 17 00:00:00 2001
Summary: LIN1019-1252 run 'shutdown -P now' on vm and shutdown failed
Tech Review: Qi Chen
Gatekeeper: Robert
Lockdown Approval (if needed):
Branch Tag: wr-10.19-20190505
IP Statement (form link or license statement, usually automated):
Crypto URL(s) (if needed): see
http://wiki.wrs.com/PBUeng/LinuxProductDivisionExportProcess
Parent Template (where applicable):
== Sanity Issues: (DO NOT EDIT this section) ==
== Impacted area Impact y/n ==
docs/tech-pubs n
tests n
build systemn
host dependencies n
RPM/packaging n
toolchain n
kernel code n
user code y
configuration files n
target configurationn
Applicable to Yocto/upstreamn
New Kernel Warnings n
Other n
== Comments (indicate scope for each "y" above) ==
* Conditions of submission
* Documentation Changes/Release Notes
= Doc changes
= Release notes
* Git logs
== Testing ==
* Commands
setup.sh --machine qemux86-64 --distro wrlinux --dl-layers
. ./oe-init-build-env
bitbake wrlinux-image-glibc-std
runqemu qemux86-64 nographic
root
shutdown now
* Expected Results
shut down successfully
* Applicable to
* Tested configurations
Archbuilt boot boardname
-
MIPS n n
MIPS64n n
MIPS64n32 n n
ARM32 n n
ARM64 n n
x86 n n
x86_64n y 22015
PPC n n
PPC64 n n
SPARC64 n n
== Reviewer Checklist ==
[Submitters: make sure that your review doesn't trigger any checkmarks!]
http://lxgit.wrs.com/cgit/bin.git/tree/etc/review.txt
== PULLs ==
* The branch is made of: __
git://128.224.158.51/git/oe-core zhe/wr-10.19-20190505__1__20190509174633
* WRH-PULLs ("wrh -m" can merge it):
git://128.224.158.51/git/oe-core__s__zhe/wr-10.19-20190505__1__20190509174633
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/2] openssh: usable sshd depends on rngd from rng-tools
On 08/05/2019 16.22, mikko.rap...@bmw.de wrote:
> On Wed, May 08, 2019 at 05:07:08PM +0300, Adrian Bunk wrote:
>> On Wed, May 08, 2019 at 04:26:09PM +0300, Mikko Rapeli wrote:
>>> Since openssl 1.1.1 and openssh which uses it, sshd
>>> startup is delayed. The delays range from few seconds
>>> to minutes and even to hours. The delays are visible
>>> in host keys generation and when sshd process is started
>>> in response to incoming TCP connection but is failing
>>> to provide SSH version string and clients or tests time out.
>>>
>>> In all cases traces show that sshd is waiting for getentropy()
>>> system call to return from Linux kernel, which returns only
>>> after kernel side random number pool is initialized. The pool
>>> is initialized via various entropy source which may be
>>> missing on embedded development boards or via rngd from
>>> rng-tools package from userspace. HW random number generation
>>> and kernel support help but rngd is till needed to feed that data
>>> back to the Linux kernel.
>>>
>>> Example from an NXP imx8 board shows that kernel random number pool
>>> initialization can take over 400 seconds without rngd,
>>> and with rngd it is initialized at around 4 seconds after boot.
>>> The completion of initialization is visible in kernel dmesg with line
>>> "random: crng init done".
>>> ...
>>> --- a/meta/recipes-connectivity/openssh/openssh_7.9p1.bb
>>> +++ b/meta/recipes-connectivity/openssh/openssh_7.9p1.bb
>>> @@ -148,6 +148,7 @@ FILES_${PN}-keygen = "${bindir}/ssh-keygen"
>>>
>>> RDEPENDS_${PN} += "${PN}-scp ${PN}-ssh ${PN}-sshd ${PN}-keygen"
>>> RDEPENDS_${PN}-sshd += "${PN}-keygen
>>> ${@bb.utils.contains('DISTRO_FEATURES', 'pam', 'pam-plugin-keyinit
>>> pam-plugin-loginuid', '', d)}"
>>> +RDEPENDS_${PN}-sshd += "rng-tools"
>>> ...
>>
>> This should only be an RRECOMMENDS so that people can opt out of it.
>>
>> E.g. CONFIG_RANDOM_TRUST_CPU in the kernel can solve the same
>> problem without using rng-tools on some platforms.
>
> I think this is a stronger dependency than just RRECOMMENDS. We build
> images and disable recommends but we care that sshd starts as fast as in
> sumo and earlier yocto releases for testing etc purposes.
But why should boards without a hwrng be forced to spend disk space and
run-time resources on a daemon which they don't benefit from at all?
I don't think RANDOM_TRUST_CPU works, though. That's just for stuff like
rdrand(), i.e. instructions built into the CPU - not for some other
on-chip hwrng. Whether those are used for seeding early on (i.e.,
without rngd doing its thing) depends on the ->quality parameter set by
the individual hwrng drivers. Very few set one, so they get assigned the
default_quality, which is a module parameter that defaults to 0.
IOW, I think (but I haven't got around to testing this) one should set
rng_core.default_quality=512 (or something) on the kernel command line
to make the kernel start the hwrng_fill thread that will seed the
entropy pool from the hwrng. At least if I'm reading
drivers/char/hw_random/core.c correctly.
Rasmus
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] ofono: upgrade 1.25 -> 1.29
On Thu, May 09, 2019 at 06:48:38AM +, Mittal, Anuj wrote: > This is failing with error: > > | In file included from ../ofono-1.29/ell/random.c:34: > | ../ofono-1.29/ell/missing.h:59:20: error: static declaration of > 'explicit_bzero' follows non-static declaration > | static inline void explicit_bzero(void *s, size_t n) > | ^~ > | In file included from ../ofono-1.29/ell/util.h:26, > | from ../ofono-1.29/ell/private.h:26, > | from ../ofono-1.29/ell/random.c:33: > | /home/pokybuild/yocto-worker/musl-qemux86- > 64/build/build/tmp/work/core2-64-poky-linux-musl/ofono/1.29-r0/recipe- > sysroot/usr/include/string.h:85:6: note: previous declaration of > 'explicit_bzero' was here > | void explicit_bzero (void *, size_t); > | ^~ > | make[1]: *** [ell/random.lo] Error 1 > | make[1]: *** Waiting for unfinished jobs > > Logs here: > > https://autobuilder.yoctoproject.org/typhoon/#/builders/45/builds/578/steps/7/logs/step1b Thanks, got a fix for that one now. The next problem is that musl does not currently provide TEMP_FAILURE_RETRY, and the correct fix for that will be that I'll try to get this fixed in musl instead of creating yet another copy of the glibc macro. I'll come back to ofono after that. > Thanks, > > Anuj cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2] openssh: recommend rng-tools with sshd
Since openssl 1.1.1 and openssh which uses it, sshd
startup is delayed. The delays range from few seconds
to minutes and even to hours. The delays are visible
in host keys generation and when sshd process is started
in response to incoming TCP connection but is failing
to provide SSH version string and clients or tests time out.
In all cases traces show that sshd is waiting for getentropy()
system call to return from Linux kernel, which returns only
after kernel side random number pool is initialized. The pool
is initialized via various entropy source which may be
missing on embedded development boards or via rngd from
rng-tools package from userspace. HW random number generation
and kernel support help but rngd is till needed to feed that data
back to the Linux kernel.
Example from an NXP imx8 board shows that kernel random number pool
initialization can take over 400 seconds without rngd,
and with rngd it is initialized at around 4 seconds after boot.
The completion of initialization is visible in kernel dmesg with line
"random: crng init done".
More details are available from:
* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912087
* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897572
*
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=43838a23a05fbd13e47d750d3dfd77001536dd33
* http://www.man7.org/linux/man-pages/man2/getrandom.2.html
Signed-off-by: Mikko Rapeli
Cc: Mark Hatle
Cc: Rasmus Villemoes
Cc: Adrian Bunk
---
v2: switch from RDEPENDS to RRECOMMENDS based on review comments
v1:
http://lists.openembedded.org/pipermail/openembedded-core/2019-May/282021.html
meta/recipes-connectivity/openssh/openssh_7.9p1.bb | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/recipes-connectivity/openssh/openssh_7.9p1.bb
b/meta/recipes-connectivity/openssh/openssh_7.9p1.bb
index b971b2b..976bcc5 100644
--- a/meta/recipes-connectivity/openssh/openssh_7.9p1.bb
+++ b/meta/recipes-connectivity/openssh/openssh_7.9p1.bb
@@ -148,6 +148,7 @@ FILES_${PN}-keygen = "${bindir}/ssh-keygen"
RDEPENDS_${PN} += "${PN}-scp ${PN}-ssh ${PN}-sshd ${PN}-keygen"
RDEPENDS_${PN}-sshd += "${PN}-keygen ${@bb.utils.contains('DISTRO_FEATURES',
'pam', 'pam-plugin-keyinit pam-plugin-loginuid', '', d)}"
+RRECOMMENDS_${PN}-sshd += "rng-tools"
RDEPENDS_${PN}-ptest += "${PN}-sftp ${PN}-misc ${PN}-sftp-server make sed"
RPROVIDES_${PN}-ssh = "ssh"
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/2] openssh: usable sshd depends on rngd from rng-tools
On Wed, May 08, 2019 at 06:50:54PM +0300, Mark Hatle wrote:
> On 5/8/19 5:22 PM, mikko.rap...@bmw.de wrote:
> > On Wed, May 08, 2019 at 05:07:08PM +0300, Adrian Bunk wrote:
> >> On Wed, May 08, 2019 at 04:26:09PM +0300, Mikko Rapeli wrote:
> >>> Since openssl 1.1.1 and openssh which uses it, sshd
> >>> startup is delayed. The delays range from few seconds
> >>> to minutes and even to hours. The delays are visible
> >>> in host keys generation and when sshd process is started
> >>> in response to incoming TCP connection but is failing
> >>> to provide SSH version string and clients or tests time out.
> >>>
> >>> In all cases traces show that sshd is waiting for getentropy()
> >>> system call to return from Linux kernel, which returns only
> >>> after kernel side random number pool is initialized. The pool
> >>> is initialized via various entropy source which may be
> >>> missing on embedded development boards or via rngd from
> >>> rng-tools package from userspace. HW random number generation
> >>> and kernel support help but rngd is till needed to feed that data
> >>> back to the Linux kernel.
> >>>
> >>> Example from an NXP imx8 board shows that kernel random number pool
> >>> initialization can take over 400 seconds without rngd,
> >>> and with rngd it is initialized at around 4 seconds after boot.
> >>> The completion of initialization is visible in kernel dmesg with line
> >>> "random: crng init done".
> >>> ...
> >>> --- a/meta/recipes-connectivity/openssh/openssh_7.9p1.bb
> >>> +++ b/meta/recipes-connectivity/openssh/openssh_7.9p1.bb
> >>> @@ -148,6 +148,7 @@ FILES_${PN}-keygen = "${bindir}/ssh-keygen"
> >>>
> >>> RDEPENDS_${PN} += "${PN}-scp ${PN}-ssh ${PN}-sshd ${PN}-keygen"
> >>> RDEPENDS_${PN}-sshd += "${PN}-keygen
> >>> ${@bb.utils.contains('DISTRO_FEATURES', 'pam', 'pam-plugin-keyinit
> >>> pam-plugin-loginuid', '', d)}"
> >>> +RDEPENDS_${PN}-sshd += "rng-tools"
> >>> ...
> >>
> >> This should only be an RRECOMMENDS so that people can opt out of it.
> >>
> >> E.g. CONFIG_RANDOM_TRUST_CPU in the kernel can solve the same
> >> problem without using rng-tools on some platforms.
> >
> > I think this is a stronger dependency than just RRECOMMENDS. We build
> > images and disable recommends but we care that sshd starts as fast as in
> > sumo and earlier yocto releases for testing etc purposes.
>
> I agree with Adrian here. It should be a recommend. The system works without
> this, and there are valid use-cases without rngd existing on the system. (In
> fact I have a couple of customers that would rather the system stall waiting
> for
> 'real' entropy then use the values from rngd.)
Ok, at least I tried.
I can send a v2 with RRECOMMENDS instead though it is useless for me
since enabling recommends causes images to explode in size, complexity,
licensing with GPLv3 components etc.
> Note the warning on this page: https://wiki.archlinux.org/index.php/Rng-tools
>
> In a lot of cases, this dependency on urandom on an embedded target without
> even
> a clock or entropy sources results in the system having effectively the same
> entropy each time it starts up -- even with rngd. So you get a false sense of
> security.
>
> Once you have a hardware (or other) rng source, the tool can be useful to
> increase the amount of entropy available however... but it all starts with
> having a reasonable starting source.
>
> In your case, if using rngd has the entropy your device requires, based on
> your
> system configuration (and you do not want recommends), then I think it's
> reasonable that you need to manually include it as an image dependency.
Yes, this lack of entropy on embedded devices is understood but in my case
rngd is the one reading /dev/hwrnd and pushing that back to kernel...
-Mikko
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] ofono: upgrade 1.25 -> 1.29
This is failing with error:
| In file included from ../ofono-1.29/ell/random.c:34:
| ../ofono-1.29/ell/missing.h:59:20: error: static declaration of
'explicit_bzero' follows non-static declaration
| static inline void explicit_bzero(void *s, size_t n)
| ^~
| In file included from ../ofono-1.29/ell/util.h:26,
| from ../ofono-1.29/ell/private.h:26,
| from ../ofono-1.29/ell/random.c:33:
| /home/pokybuild/yocto-worker/musl-qemux86-
64/build/build/tmp/work/core2-64-poky-linux-musl/ofono/1.29-r0/recipe-
sysroot/usr/include/string.h:85:6: note: previous declaration of
'explicit_bzero' was here
| void explicit_bzero (void *, size_t);
| ^~
| make[1]: *** [ell/random.lo] Error 1
| make[1]: *** Waiting for unfinished jobs
Logs here:
https://autobuilder.yoctoproject.org/typhoon/#/builders/45/builds/578/steps/7/logs/step1b
Thanks,
Anuj
On Wed, 2019-05-08 at 23:01 +0300, Adrian Bunk wrote:
> Remove patch applied upstream.
> Fix a new parallel build failure.
>
> Signed-off-by: Adrian Bunk
> ---
> ...a-race-condition-where-ell-ell.h-was.patch | 28
> +++
> .../ofono/ofono/use-python3.patch | 27 ---
> ---
> meta/recipes-connectivity/ofono/ofono_1.25.bb | 9 --
> meta/recipes-connectivity/ofono/ofono_1.29.bb | 9 ++
> 4 files changed, 37 insertions(+), 36 deletions(-)
> create mode 100644 meta/recipes-connectivity/ofono/ofono/0001-
> Makefile.am-Fix-a-race-condition-where-ell-ell.h-was.patch
> delete mode 100644 meta/recipes-connectivity/ofono/ofono/use-
> python3.patch
> delete mode 100644 meta/recipes-connectivity/ofono/ofono_1.25.bb
> create mode 100644 meta/recipes-connectivity/ofono/ofono_1.29.bb
>
> diff --git a/meta/recipes-connectivity/ofono/ofono/0001-Makefile.am-
> Fix-a-race-condition-where-ell-ell.h-was.patch b/meta/recipes-
> connectivity/ofono/ofono/0001-Makefile.am-Fix-a-race-condition-where-
> ell-ell.h-was.patch
> new file mode 100644
> index 00..1dfc977add
> --- /dev/null
> +++ b/meta/recipes-connectivity/ofono/ofono/0001-Makefile.am-Fix-a-
> race-condition-where-ell-ell.h-was.patch
> @@ -0,0 +1,28 @@
> +From 61c78979eab39ead47a91aeacad43ad72d162052 Mon Sep 17 00:00:00
> 2001
> +From: Adrian Bunk
> +Date: Wed, 8 May 2019 21:58:44 +0300
> +Subject: Makefile.am: Fix a race condition where ell/ell.h was
> written before
> + ell/ existed
> +
> +Signed-off-by: Adrian Bunk
> +Upstream-Status: Pending
> +
> +---
> + Makefile.am | 1 +
> + 1 file changed, 1 insertion(+)
> +
> +diff --git a/Makefile.am b/Makefile.am
> +index a569c4a3..d2e310d5 100644
> +--- a/Makefile.am
> b/Makefile.am
> +@@ -1107,6 +1107,7 @@ ell/internal: Makefile
> + done > $@
> +
> + ell/ell.h: Makefile
> ++$(AM_V_at)$(MKDIR_P) ell
> + $(AM_V_at)echo -n > $@
> + $(AM_V_GEN)for f in $(ell_headers) ; do \
> + echo "#include <$$f>" >> $@ ; \
> +--
> +2.20.1
> +
> diff --git a/meta/recipes-connectivity/ofono/ofono/use-python3.patch
> b/meta/recipes-connectivity/ofono/ofono/use-python3.patch
> deleted file mode 100644
> index 7b84075257..00
> --- a/meta/recipes-connectivity/ofono/ofono/use-python3.patch
> +++ /dev/null
> @@ -1,27 +0,0 @@
> -set-ddr should use Python3 like all the other tests.
> -
> -Upstream-Status: Submitted
> -Signed-off-by: Ross Burton
> -
> -From 17b69cd1da4c5c5f732acb38ca1602446c567ee7 Mon Sep 17 00:00:00
> 2001
> -From: Ross Burton
> -Date: Mon, 29 Jan 2018 11:31:25 +
> -Subject: [PATCH] test/setddr: use Python 3
> -
> -All the other tests use Python 3, so this should to.
>
> - test/set-ddr | 2 +-
> - 1 file changed, 1 insertion(+), 1 deletion(-)
> -
> -diff --git a/test/set-ddr b/test/set-ddr
> -index 5d061b95..33631f31 100755
> a/test/set-ddr
> -+++ b/test/set-ddr
> -@@ -1,4 +1,4 @@
> --#!/usr/bin/python
> -+#!/usr/bin/python3
> -
> - import sys
> - import dbus
> ---
> -2.11.0
> diff --git a/meta/recipes-connectivity/ofono/ofono_1.25.bb
> b/meta/recipes-connectivity/ofono/ofono_1.25.bb
> deleted file mode 100644
> index 3688b9d2fc..00
> --- a/meta/recipes-connectivity/ofono/ofono_1.25.bb
> +++ /dev/null
> @@ -1,9 +0,0 @@
> -require ofono.inc
> -
> -SRC_URI = "\
> - ${KERNELORG_MIRROR}/linux/network/${BPN}/${BP}.tar.xz \
> - file://ofono \
> - file://use-python3.patch \
> -"
> -SRC_URI[md5sum] = "31450cabdd8dbbf3f808ea2f2f066863"
> -SRC_URI[sha256sum] =
> "eb011fcd3080e93f3a56f96be60350b6595a8b5f36b61646312ba41b0bcb0d75"
> diff --git a/meta/recipes-connectivity/ofono/ofono_1.29.bb
> b/meta/recipes-connectivity/ofono/ofono_1.29.bb
> new file mode 100644
> index 00..8539aa1372
> --- /dev/null
> +++ b/meta/recipes-connectivity/ofono/ofono_1.29.bb
> @@ -0,0 +1,9 @@
> +require ofono.inc
> +
> +SRC_URI = "\
> + ${KERNELORG_MIRROR}/linux/network/${BPN}/${BP}.tar.xz \
> + file://ofono \
> + file://0001-Makefile.am-Fix-a-race-condition-where-ell-ell.h-
> was.patch \
> +"
>
Re: [OE-core] "shutdown now" Hangs Since 1d453c9087f9 ("systemd: upgrade to 242")
Hi,
Which version did you use? From the OE, or the last one from upstream
"v242-stable" repo? I am not sure, how long it will take, but... Isn't
possible to test it with master from dev repo?
Regards,
Andrej
On 5/9/19 8:19 AM, ChenQi wrote:
> I also just did a simple test, v242 without any oe patches has the same
> problem.
> It seems that it's a change in systemd upstream.
> I'm wondering why oe-selftest did not discover this problem.
>
> Best Regards,
> Chen Qi
>
> On 05/09/2019 01:18 PM, He Zhe wrote:
>> Hi,
>>
>>
>> Since 1d453c9087f9 ("systemd: upgrade to 242"), "shutdown now" hangs like
>> below where I enable systemd debug information print.
>>
>> Any idea? Thanks.
>>
>>
>> [ OK ] Stopped NFS status monitor for NFSv2/3 locking..
>> Sent message type=signal sender=n/a destination=n/a
>> path=/org/freedesktop/systemd1/unit/nfs_2dstatd_2eservice
>> interface=org.freedesktop.DBusa
>> Sent message type=signal sender=n/a destination=n/a
>> path=/org/freedesktop/systemd1/unit/nfs_2dstatd_2eservice
>> interface=org.freedesktop.DBusa
>> Sent message type=signal sender=n/a destination=n/a
>> path=/org/freedesktop/systemd1 interface=org.freedesktop.systemd1.Manager
>> member=JobRemoa
>> Sent message type=signal sender=n/a destination=n/a
>> path=/org/freedesktop/systemd1/unit/nfs_2dstatd_2eservice
>> interface=org.freedesktop.DBusa
>> Sent message type=signal sender=n/a destination=n/a
>> path=/org/freedesktop/systemd1/unit/nfs_2dstatd_2eservice
>> interface=org.freedesktop.DBusa
>> Child 410 (sh) died (code=killed, status=1/HUP)
>> session-c1.scope: Child 410 belongs to session-c1.scope.
>> Child 299 (avahi-daemon) died (code=killed, status=15/TERM)
>> system.slice: Child 299 belongs to system.slice.
>> session-c1.scope: cgroup is empty
>> session-c1.scope: Succeeded.
>> session-c1.scope changed stop-sigterm -> dead
>> session-c1.scope: Job 277 session-c1.scope/stop finished, result=done
>> [ OK ] Stopped Session c1 of user root.
>> Sent message type=signal sender=n/a destination=n/a
>> path=/org/freedesktop/systemd1/unit/session_2dc1_2escope
>> interface=org.freedesktop.DBus.a
>> Sent message type=signal sender=n/a destination=n/a
>> path=/org/freedesktop/systemd1/unit/session_2dc1_2escope
>> interface=org.freedesktop.DBus.a
>> Sent message type=signal sender=n/a destination=n/a
>> path=/org/freedesktop/systemd1 interface=org.freedesktop.systemd1.Manager
>> member=JobRemoa
>> session-c1.scope: Collecting.
>> Sent message type=signal sender=n/a destination=n/a
>> path=/org/freedesktop/systemd1/unit/session_2dc1_2escope
>> interface=org.freedesktop.DBus.a
>> Sent message type=signal sender=n/a destination=n/a
>> path=/org/freedesktop/systemd1/unit/session_2dc1_2escope
>> interface=org.freedesktop.DBus.a
>> Sent message type=signal sender=n/a destination=n/a
>> path=/org/freedesktop/systemd1 interface=org.freedesktop.systemd1.Manager
>> member=UnitRema
>> systemd-journald.service: Received EPOLLHUP on stored fd 56 (stored),
>> closing.
>> systemd-journald.service: Received EPOLLHUP on stored fd 58 (stored),
>> closing.
>> systemd-journald.service: Received EPOLLHUP on stored fd 65 (stored),
>> closing.
>> Got message type=signal sender=org.freedesktop.DBus destination=n/a
>> path=/org/freedesktop/DBus interface=org.freedesktop.DBus member=NameOwna
>> avahi-daemon.service: D-Bus name org.freedesktop.Avahi no longer registered
>> by :1.1
>> systemd-journald.service: Received EPOLLHUP on stored fd 55 (stored),
>> closing.
>> syslog.socket: Incoming traffic
>> syslog.socket: Suppressing connection request since unit stop is scheduled.
>>
>>
>>
>> Zhe
>
>
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] "shutdown now" Hangs Since 1d453c9087f9 ("systemd: upgrade to 242")
I also just did a simple test, v242 without any oe patches has the same
problem.
It seems that it's a change in systemd upstream.
I'm wondering why oe-selftest did not discover this problem.
Best Regards,
Chen Qi
On 05/09/2019 01:18 PM, He Zhe wrote:
Hi,
Since 1d453c9087f9 ("systemd: upgrade to 242"), "shutdown now" hangs like below
where I enable systemd debug information print.
Any idea? Thanks.
[ OK ] Stopped NFS status monitor for NFSv2/3 locking..
Sent message type=signal sender=n/a destination=n/a
path=/org/freedesktop/systemd1/unit/nfs_2dstatd_2eservice
interface=org.freedesktop.DBusa
Sent message type=signal sender=n/a destination=n/a
path=/org/freedesktop/systemd1/unit/nfs_2dstatd_2eservice
interface=org.freedesktop.DBusa
Sent message type=signal sender=n/a destination=n/a
path=/org/freedesktop/systemd1 interface=org.freedesktop.systemd1.Manager
member=JobRemoa
Sent message type=signal sender=n/a destination=n/a
path=/org/freedesktop/systemd1/unit/nfs_2dstatd_2eservice
interface=org.freedesktop.DBusa
Sent message type=signal sender=n/a destination=n/a
path=/org/freedesktop/systemd1/unit/nfs_2dstatd_2eservice
interface=org.freedesktop.DBusa
Child 410 (sh) died (code=killed, status=1/HUP)
session-c1.scope: Child 410 belongs to session-c1.scope.
Child 299 (avahi-daemon) died (code=killed, status=15/TERM)
system.slice: Child 299 belongs to system.slice.
session-c1.scope: cgroup is empty
session-c1.scope: Succeeded.
session-c1.scope changed stop-sigterm -> dead
session-c1.scope: Job 277 session-c1.scope/stop finished, result=done
[ OK ] Stopped Session c1 of user root.
Sent message type=signal sender=n/a destination=n/a
path=/org/freedesktop/systemd1/unit/session_2dc1_2escope
interface=org.freedesktop.DBus.a
Sent message type=signal sender=n/a destination=n/a
path=/org/freedesktop/systemd1/unit/session_2dc1_2escope
interface=org.freedesktop.DBus.a
Sent message type=signal sender=n/a destination=n/a
path=/org/freedesktop/systemd1 interface=org.freedesktop.systemd1.Manager
member=JobRemoa
session-c1.scope: Collecting.
Sent message type=signal sender=n/a destination=n/a
path=/org/freedesktop/systemd1/unit/session_2dc1_2escope
interface=org.freedesktop.DBus.a
Sent message type=signal sender=n/a destination=n/a
path=/org/freedesktop/systemd1/unit/session_2dc1_2escope
interface=org.freedesktop.DBus.a
Sent message type=signal sender=n/a destination=n/a
path=/org/freedesktop/systemd1 interface=org.freedesktop.systemd1.Manager
member=UnitRema
systemd-journald.service: Received EPOLLHUP on stored fd 56 (stored), closing.
systemd-journald.service: Received EPOLLHUP on stored fd 58 (stored), closing.
systemd-journald.service: Received EPOLLHUP on stored fd 65 (stored), closing.
Got message type=signal sender=org.freedesktop.DBus destination=n/a
path=/org/freedesktop/DBus interface=org.freedesktop.DBus member=NameOwna
avahi-daemon.service: D-Bus name org.freedesktop.Avahi no longer registered by
:1.1
systemd-journald.service: Received EPOLLHUP on stored fd 55 (stored), closing.
syslog.socket: Incoming traffic
syslog.socket: Suppressing connection request since unit stop is scheduled.
Zhe
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
