[OE-core] [PATCH] oe-selftest: qemutest: add tests for qemu boot and shutdown
QA team were testing qemu boot image and shutdown on each qemu
architecture manually. Add automated test to test qemu boot on
ext4 and nfs, finally it can shutdown properly.
This tests was not included into existing runqemu.py as runqemu
was dedicated for qemux86-64 where it test various live image
(iso and hddimg) can boot but this live image was not supported
on other qemu architechture.
Signed-off-by: Yeoh Ee Peng
---
meta/lib/oeqa/selftest/cases/qemutest.py | 44
1 file changed, 44 insertions(+)
create mode 100644 meta/lib/oeqa/selftest/cases/qemutest.py
diff --git a/meta/lib/oeqa/selftest/cases/qemutest.py
b/meta/lib/oeqa/selftest/cases/qemutest.py
new file mode 100644
index 000..f06e3fd
--- /dev/null
+++ b/meta/lib/oeqa/selftest/cases/qemutest.py
@@ -0,0 +1,44 @@
+from oeqa.selftest.case import OESelftestTestCase
+from oeqa.utils.commands import bitbake, get_bb_var, runCmd, runqemu
+import os
+import tempfile
+
+class QemuTest(OESelftestTestCase):
+
+@classmethod
+def setUpClass(cls):
+super(QemuTest, cls).setUpClass()
+cls.recipe = 'core-image-minimal'
+cls.machine = get_bb_var('MACHINE')
+cls.deploy_dir_image = get_bb_var('DEPLOY_DIR_IMAGE')
+cls.cmd_common = "runqemu nographic"
+cls.qemuboot_conf = "%s-%s.qemuboot.conf" % (cls.recipe, cls.machine)
+cls.qemuboot_conf = os.path.join(cls.deploy_dir_image,
cls.qemuboot_conf)
+result = bitbake(cls.recipe)
+
+def test_qemu_can_shutdown(self):
+if not os.path.exists(self.qemuboot_conf):
+self.skipTest("%s not found" % self.qemuboot_conf)
+cmd = "%s %s" % (self.cmd_common, self.qemuboot_conf)
+with runqemu(self.recipe, ssh=True, launch_cmd=cmd) as qemu:
+status, output = qemu.run("shutdown -h now")
+self.assertEqual(status, 0, 'Failed: qemu shutdown')
+
+def test_qemu_can_boot_nfs_and_shutdown(self):
+bitbake('meta-ide-support')
+rootfs_tar = "%s-%s.tar.bz2" % (self.recipe, self.machine)
+rootfs_tar = os.path.join(self.deploy_dir_image, rootfs_tar)
+if not os.path.exists(rootfs_tar):
+self.skipTest("%s not found" % rootfs_tar)
+tmpdir = tempfile.mkdtemp(prefix='qemu_nfs')
+tmpdir_nfs = os.path.join(tmpdir, 'nfs')
+cmd_extract_nfs = 'runqemu-extract-sdk %s %s' % (rootfs_tar,
tmpdir_nfs)
+runCmd(cmd_extract_nfs)
+if not os.path.exists(self.qemuboot_conf):
+self.skipTest("%s not found" % self.qemuboot_conf)
+cmd = "%s nfs %s %s" % (self.cmd_common, self.qemuboot_conf,
tmpdir_nfs)
+with runqemu(self.recipe, ssh=True, launch_cmd=cmd) as qemu:
+status, output = qemu.run("shutdown -h now")
+self.assertEqual(status, 0, 'Failed: qemu shutdown')
+runCmd('rm -rf %s' % tmpdir)
+
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] oe-selftest: qemutest: add tests for qemu boot and shutdown
Hi Alex & Paul,
I had developed this selftest testcase to test qemu can boot nfs & ext4 and
finally shutdown for various qemu architecture.
Initially, I was thinking to develop this automated test as part of testimage
but as this test involve shutting down qemu, testimage testcases executed after
this will face lost connection to qemu. Furthermore, when I tried to add this
test to selftest runqemu.py, I realized runqemu was dedicated for
MACHINE=qemux86-64 and it was testing various live image (iso and hddimg) but
live image was not supported by other qemu architecture. Therefore, this test
was developed as independent selftest testcase.
Please let me know your inputs and feedback.
Thanks,
Yeoh Ee Peng
-Original Message-
From: openembedded-core-boun...@lists.openembedded.org
[mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of Yeoh Ee
Peng
Sent: Thursday, April 5, 2018 8:36 AM
To: openembedded-core@lists.openembedded.org
Subject: [OE-core] [PATCH] oe-selftest: qemutest: add tests for qemu boot and
shutdown
QA team were testing qemu boot image and shutdown on each qemu architecture
manually. Add automated test to test qemu boot on
ext4 and nfs, finally it can shutdown properly.
This tests was not included into existing runqemu.py as runqemu was dedicated
for qemux86-64 where it test various live image (iso and hddimg) can boot but
this live image was not supported on other qemu architechture.
Signed-off-by: Yeoh Ee Peng
---
meta/lib/oeqa/selftest/cases/qemutest.py | 44
1 file changed, 44 insertions(+)
create mode 100644 meta/lib/oeqa/selftest/cases/qemutest.py
diff --git a/meta/lib/oeqa/selftest/cases/qemutest.py
b/meta/lib/oeqa/selftest/cases/qemutest.py
new file mode 100644
index 000..f06e3fd
--- /dev/null
+++ b/meta/lib/oeqa/selftest/cases/qemutest.py
@@ -0,0 +1,44 @@
+from oeqa.selftest.case import OESelftestTestCase from
+oeqa.utils.commands import bitbake, get_bb_var, runCmd, runqemu import
+os import tempfile
+
+class QemuTest(OESelftestTestCase):
+
+@classmethod
+def setUpClass(cls):
+super(QemuTest, cls).setUpClass()
+cls.recipe = 'core-image-minimal'
+cls.machine = get_bb_var('MACHINE')
+cls.deploy_dir_image = get_bb_var('DEPLOY_DIR_IMAGE')
+cls.cmd_common = "runqemu nographic"
+cls.qemuboot_conf = "%s-%s.qemuboot.conf" % (cls.recipe, cls.machine)
+cls.qemuboot_conf = os.path.join(cls.deploy_dir_image,
cls.qemuboot_conf)
+result = bitbake(cls.recipe)
+
+def test_qemu_can_shutdown(self):
+if not os.path.exists(self.qemuboot_conf):
+self.skipTest("%s not found" % self.qemuboot_conf)
+cmd = "%s %s" % (self.cmd_common, self.qemuboot_conf)
+with runqemu(self.recipe, ssh=True, launch_cmd=cmd) as qemu:
+status, output = qemu.run("shutdown -h now")
+self.assertEqual(status, 0, 'Failed: qemu shutdown')
+
+def test_qemu_can_boot_nfs_and_shutdown(self):
+bitbake('meta-ide-support')
+rootfs_tar = "%s-%s.tar.bz2" % (self.recipe, self.machine)
+rootfs_tar = os.path.join(self.deploy_dir_image, rootfs_tar)
+if not os.path.exists(rootfs_tar):
+self.skipTest("%s not found" % rootfs_tar)
+tmpdir = tempfile.mkdtemp(prefix='qemu_nfs')
+tmpdir_nfs = os.path.join(tmpdir, 'nfs')
+cmd_extract_nfs = 'runqemu-extract-sdk %s %s' % (rootfs_tar,
tmpdir_nfs)
+runCmd(cmd_extract_nfs)
+if not os.path.exists(self.qemuboot_conf):
+self.skipTest("%s not found" % self.qemuboot_conf)
+cmd = "%s nfs %s %s" % (self.cmd_common, self.qemuboot_conf,
tmpdir_nfs)
+with runqemu(self.recipe, ssh=True, launch_cmd=cmd) as qemu:
+status, output = qemu.run("shutdown -h now")
+self.assertEqual(status, 0, 'Failed: qemu shutdown')
+runCmd('rm -rf %s' % tmpdir)
+
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] rpm: remove dbus dependency for rpm-native
On 04/04/2018 02:32 PM, Alexander Kanavin wrote: +# dbus dependency is deliberately omitted for rpm-native to prevent it from attempting to +# inhibit shutdown via session dbus, even when some layer enables plugins support for rpm-native. +DEPENDS_remove_class-native = "dbus" + inherit autotools gettext pkgconfig python3native export PYTHON_ABI @@ -63,7 +67,7 @@ EXTRA_OECONF_append_libc-musl = " --disable-nls" # # --localstatedir prevents rpm from writing its database to native sysroot when building images # -# Also disable plugins, so that rpm doesn't attempt to inhibit shutdown via session dbus +# Disable plugins for rpm-native. EXTRA_OECONF_append_class-native = " --sysconfdir=/etc --localstatedir=/var --disable-plugins" This should definitely be a PACKAGECONFIG option. Actually, two different options: "plugins" (pulls in dbus) and "plugins-native" (does not pull in dbus). Then both can be enabled for target and native, respectively. Actually, no, neither of these ideas is correct. If dbus is removed from explicit dependencies, that does not guarantee that it will not get pulled into rpm sysroot by something else that rpm depends on. You need to either patch configure.ac in rpm source code to add an explicit enable/disable-dbus switch, or to enable plugins in all cases, and remove the unneeded plugin at do_install tim when building rpm-native. Alex -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] package_manager.py: Skip gpgcheck while using dnf on target
On 04/04/2018 09:27 PM, Manjukumar Harthikote Matha wrote:
diff --git a/meta/lib/oe/package_manager.py b/meta/lib/oe/package_manager.py
index e006dc6..9f22fb0 100644
--- a/meta/lib/oe/package_manager.py
+++ b/meta/lib/oe/package_manager.py
@@ -674,7 +674,7 @@ class RpmPM(PackageManager):
gpg_opts += 'repo_gpgcheck=1\n'
gpg_opts += 'gpgkey=file://%s/pki/packagefeed-gpg/PACKAGEFEED-GPG-
KEY-%s-%s\n' % (self.d.getVar('sysconfdir'), self.d.getVar('DISTRO'),
self.d.getVar('DISTRO_CODENAME'))
-if self.d.getVar('RPM_SIGN_PACKAGES') == '0':
+if self.d.getVar('RPM_SIGN_PACKAGES') != '1':
gpg_opts += 'gpgcheck=0\n'
bb.utils.mkdirhier(oe.path.join(self.target_rootfs, "etc",
"yum.repos.d"))
--
Any feedback/concerns on this patch?
Generally we don't positively acknowledge patches, as it would create
too much traffic on the mailing list. If no one said anything so far,
then no one has concerns. Also, have a little patience please.
Alex
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 08/22] bash-completion: update to 2.8
On 04/05/2018 03:18 AM, Khem Raj wrote: # Delete files already provided by util-linux local i - for i in mount umount rfkill; do + for i in mount umount; do where did rfkill go ? util-linux obviously. bash-completion no longer provides it in 2.8. Alex -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 14/22] icu: update to 61.1
On 04/05/2018 03:20 AM, Khem Raj wrote: On 4/4/18 4:13 AM, Alexander Kanavin wrote: License-Update: copyright years updated, added terms for Google double-conversion should this change to terms reflect in LICENSE filed as well. The LICENSE is set to ICU, which I take means "review manually". It consists of separate terms for different componetns that icu is made of. Alex -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [meta-oe] qemu boot problem
Hi, so i completed the core-image-sato build but while running it on qemu i get the below error. runqemu - INFO - Running MACHINE=qemux86 bitbake -e... ERROR: This recipe does not have the LICENSE field set (defaultpkgname) runqemu - ERROR - bitbake -e Summary: There was 1 ERROR message shown, returning a non-zero exit code. Build Configuration: BB_VERSION = "1.37.0" BUILD_SYS= "x86_64-linux" NATIVELSBSTRING = "universal" TARGET_SYS = "i586-poky-linux" MACHINE = "qemux86" DISTRO = "poky" DISTRO_VERSION = "2.4+snapshot-20180405" TUNE_FEATURES= "m32 i586" TARGET_FPU = "" meta meta-poky meta-yocto-bsp = "master:80c7ca2c28959d08a59d960d318d8360392bd488" meta-oe meta-python = "master:b9d1d8718834f7287e5a65373b952cbfe9ce83fe" -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] oe-selftest: qemutest: add tests for qemu boot and shutdown
On 04/05/2018 11:09 AM, Yeoh, Ee Peng wrote: I had developed this selftest testcase to test qemu can boot nfs & ext4 and finally shutdown for various qemu architecture. Initially, I was thinking to develop this automated test as part of testimage but as this test involve shutting down qemu, testimage testcases executed after this will face lost connection to qemu. Furthermore, when I tried to add this test to selftest runqemu.py, I realized runqemu was dedicated for MACHINE=qemux86-64 and it was testing various live image (iso and hddimg) but live image was not supported by other qemu architecture. Therefore, this test was developed as independent selftest testcase. Please let me know your inputs and feedback. It's totally okay to have several test classes in a single .py file (see for example signing.py). I think this should go to runqemu.py, as otherwise there would be two different files doing roughly same thing and named very similarly (runqemu and qemutest?), which is confusing. You can add comments to both classes to explain what they do and why, and how they are different. (generally, be generous with comments every time there is possibility for confusion, or the code does unusual things etc.) Alex -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [meta-oe] qemu boot problem
as the error specifies about a specific recipe missing the license, i'd like to know which recipe is that what is the pointer to defaultpkgname Thanks Rajath C S, 9964182112, Bangalore - 560060 On Thu, Apr 5, 2018 at 3:30 PM, Rajath C S wrote: > Hi, > > so i completed the core-image-sato build but while running it on qemu i > get the below error. > > runqemu - INFO - Running MACHINE=qemux86 bitbake -e... > ERROR: This recipe does not have the LICENSE field set (defaultpkgname) > runqemu - ERROR - bitbake -e > Summary: There was 1 ERROR message shown, returning a non-zero exit code. > > > Build Configuration: > BB_VERSION = "1.37.0" > BUILD_SYS= "x86_64-linux" > NATIVELSBSTRING = "universal" > TARGET_SYS = "i586-poky-linux" > MACHINE = "qemux86" > DISTRO = "poky" > DISTRO_VERSION = "2.4+snapshot-20180405" > TUNE_FEATURES= "m32 i586" > TARGET_FPU = "" > meta > meta-poky > meta-yocto-bsp = "master:80c7ca2c28959d08a59d960d318d8360392bd488" > meta-oe > meta-python = "master:b9d1d8718834f7287e5a65373b952cbfe9ce83fe" > > > > > -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [RFC PATCH] devicetree.bbclass: User/BSP device tree source compilation class
This bbclass implements the device tree compilation for user provided
device trees. In order to use this class, it should be inherited in a
BSP recipe which provides the sources. The default setup enables
inclusion of kernel device tree sources (though can be disabled by the
recipe by overriding DT_INCLUDE or KERNEL_INCLUDE).
This provides an additional mechanism for BSPs to provide device trees
and device tree overlays for their target machines. Whilst still
enabling access to the kernel device trees for base SoC includes and
headers.
This approach to providing device trees has benefits for certain use
cases over patching the device trees into the kernel source.
* device trees are separated from kernel source, allows for selection of
kernel and or kernel versions without needing to explicitly patch the
kernel (or appending to the kernel recipes).
* providing device trees from separate sources, from the layer,
generated by the recipe or other recipes.
This class also implements some additional features that are not
available in the kernel-devicetree flow. This includes population of
device tree blobs into the sysroot which allows for other recipes to
consume built dtbs (e.g. U-Boot with EXT_DTB compilation), device tree
overlay compilation and customizing DTC compilation args (boot
cpu/padding/etc.).
---
This patch is an RFC for adding devicetree.bbclass to oe-core. With the
plan to submit it for inclusion in the next release.
In addition to these changes it is my intention to also submit
documentation to the Yocto BSP guide that covers both methods (kernel
source patch and this bbclass) for how to provide user device trees for a
BSP layer.
The meta-xilinx layer has a recipe (device-tree.bb) that behaves exactly
like this class for some time. It has been very useful for out-of-kernel
device tree compilation as well as for a mechanism so that users of
Xilinx SoCs can provide their customizations (FPGA devices) and board
specific configuration. This compilation flow also makes sense for other
BSPs, which is the reason for creating this bbclass for common shared
use by other BSPs.
Examples of this classes usage can be seen for meta-xilinx:
https://github.com/nathanrossi/meta-xilinx/blob/nrossi/devicetree-classify/meta-xilinx-bsp/recipes-bsp/device-tree/device-tree.bb
And for a custom BSP:
https://github.com/nathanrossi/gps-clock-project/blob/wip-devicetree-classify/meta-gps-clock/recipes/device-tree/device-tree.bb
---
meta/classes/devicetree.bbclass | 140
1 file changed, 140 insertions(+)
create mode 100644 meta/classes/devicetree.bbclass
diff --git a/meta/classes/devicetree.bbclass b/meta/classes/devicetree.bbclass
new file mode 100644
index 00..dbc83f2a1d
--- /dev/null
+++ b/meta/classes/devicetree.bbclass
@@ -0,0 +1,140 @@
+# This bbclass implements device tree compliation for user provided device tree
+# sources. The compilation of the device tree sources is the same as the kernel
+# device tree compilation process, this includes being able to include sources
+# from the kernel such as soc dtsi files or header files such as gpio.h. In
+# addition to device trees this bbclass also handles compilation of device tree
+# overlays.
+#
+# The output of this class behaves similar to how kernel-devicetree.bbclass
+# operates in that the output files are installed into /boot/devicetree.
+# However this class on purpose separates the deployed device trees into the
+# 'devicetree' subdirectory. This prevents clashes with the kernel-devicetree
+# output. Additionally the device trees are populated into the sysroot for
+# access via the sysroot from within other recipes.
+
+SECTION ?= "bsp"
+
+# The default inclusion of kernel device tree includes and headers means that
+# device trees built with them are at least GPLv2 (and in some cases dual
+# licensed). Default to GPLv2 if the recipe does not specify a license.
+LICENSE ?= "GPLv2"
+LIC_FILES_CHKSUM ?=
"file://${COMMON_LICENSE_DIR}/GPL-2.0;md5=801f80980d171dd6425610833a22dbe6"
+
+INHIBIT_DEFAULT_DEPS = "1"
+DEPENDS += "dtc-native"
+
+inherit deploy kernel-arch
+
+COMPATIBLE_MACHINE ?= "^$"
+
+PACKAGE_ARCH = "${MACHINE_ARCH}"
+
+SYSROOT_DIRS += "/boot/devicetree"
+FILES_${PN} = "/boot/devicetree/*.dtb /boot/devicetree/*.dtbo"
+
+S = "${WORKDIR}"
+B = "${WORKDIR}/build"
+
+# Default kernel includes, these represent what are normally used for in-kernel
+# sources.
+KERNEL_INCLUDE ??= " \
+${STAGING_KERNEL_DIR}/arch/${ARCH}/boot/dts \
+${STAGING_KERNEL_DIR}/arch/${ARCH}/boot/dts/* \
+${STAGING_KERNEL_DIR}/scripts/dtc/include-prefixes \
+"
+
+DT_INCLUDE[doc] = "Search paths to be made available to both the device tree
compiler and preprocessor for inclusion."
+DT_INCLUDE ?= "${DT_FILES_PATH} ${KERNEL_INCLUDE}"
+DT_FILES_PATH[doc] = "Defaults to source directory, can be used to select dts
files that are not in source (e.g. generated)."
+DT_FILES_PATH ?= "${S}"
+
+DT_PADDING_S
[OE-core] [PATCH] curl: DEPENDS on libidn2 (not libidn)
From: André Draszik Since v7.51.0, libidn2 is the only available option, libidn support was dropped. The configure option was renamed as of v7.53.0 Therefore, curl unconditionally tries to build against libidn2, which in particular is a problem for curl-native, as that might or might not build against the build-machine's libidn2 now, which furthermore causes problems when trying to share sstate between multiple build machines. We therefore see the following in the config log: ... checking whether to build with libidn2... (assumed) yes ... checking for libidn2 options with pkg-config... no configure: IDN_LIBS: "-lidn2" configure: IDN_LDFLAGS: "" configure: IDN_CPPFLAGS: "" configure: IDN_DIR: "" checking if idn2_lookup_ul can be linked... yes checking idn2.h usability... yes checking idn2.h presence... yes checking for idn2.h... yes ... IDN support: enabled (libidn2) ... even though this recipe tries to disable that. While libidn2 isn't available in OE, this change at least: * prevents curl-native to silently build against libidn2 if that is installed on build machine, even if not requested * alerts people who use the PACKAGECONFIG option that it's not actually doing what they intend to do Signed-off-by: André Draszik --- meta/recipes-support/curl/curl_7.58.0.bb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-support/curl/curl_7.58.0.bb b/meta/recipes-support/curl/curl_7.58.0.bb index 5535a5609b..d2d0180268 100644 --- a/meta/recipes-support/curl/curl_7.58.0.bb +++ b/meta/recipes-support/curl/curl_7.58.0.bb @@ -34,7 +34,7 @@ PACKAGECONFIG[imap] = "--enable-imap,--disable-imap," PACKAGECONFIG[ipv6] = "--enable-ipv6,--disable-ipv6," PACKAGECONFIG[ldap] = "--enable-ldap,--disable-ldap," PACKAGECONFIG[ldaps] = "--enable-ldaps,--disable-ldaps," -PACKAGECONFIG[libidn] = "--with-libidn,--without-libidn,libidn" +PACKAGECONFIG[libidn] = "--with-libidn2,--without-libidn2,libidn2" PACKAGECONFIG[libssh2] = "--with-libssh2,--without-libssh2,libssh2" PACKAGECONFIG[pop3] = "--enable-pop3,--disable-pop3," PACKAGECONFIG[proxy] = "--enable-proxy,--disable-proxy," -- 2.16.2 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [meta-oe] qemu boot problem
On 04/05/2018 01:43 PM, Rajath C S wrote: as the error specifies about a specific recipe missing the license, i'd like to know which recipe is that what is the pointer to defaultpkgname You need to provide both the command you issue on the command line, and the full output that it prints. Alex -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] python3-native certificate failure
But I am not using an SDK, I'm doing a straight bitbake. Using the native
Python3 urllib.request.urlopen (via inherit python3native) from do_compile I
see the certificate error. My original email duplicated the issue manually
using -c devshell.
Tom
-Original Message-
From: Khem Raj [mailto:raj.k...@gmail.com]
Sent: Wednesday, April 4, 2018 7:29 PM
To: Tom Hochstein ;
openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] python3-native certificate failure
On 4/4/18 1:09 PM, Tom Hochstein wrote:
> I am trying to download a URL from a source package using
> python3-native, but it is failing with a certificate failure. I added
> DEPENDS on ca-certificates-native and python3-certifi-native, but it
> doesn't seem to help. A colleague with a corresponding SDK took the
> aarch64 sysroot certificates and dropped them in x86_64 sysroot and
> the problem was fixed.
>
>
you might try adding nativesdk-ca-certificates to TOOLCHAIN_HOST_TASK and
regenerate SDK
>
> Tom
>
>
>
> r60874@tx30imx-01:~/rocko/build-xwayland$ bitbake imx-gpu-sdk -c
> devshell
>
> root@tx30imx-01:~/rocko/build-xwayland/tmp/work/aarch64-mx8qm-poky-lin
> ux/imx-gpu-sdk/5.0.2-r0/git#
> python3
>
> Python 3.5.3 (default, Mar 6 2018, 14:15:44)
>
> [GCC 5.4.0 20160609] on linux
>
> Type "help", "copyright", "credits" or "license" for more information.
>
import urllib.request
>
> urllib.request.urlretrieve("https://emea01.safelinks.protection.outloo
> k.com/?url=https%3A%2F%2Fsourceforge.net%2Fprojects%2Ftclap%2Ffiles%2F
> tclap-1.2.2.tar.gz&data=02%7C01%7Ctom.hochstein%40nxp.com%7Ca40b2e05d7
> aa43d50fc108d59a8c3bf6%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63
> 6584849450785202&sdata=2BmKu3tXThT6%2FsHG0CzQJNPvXQ3gq2GJpahu2t8PNCY%3
> D&reserved=0",
> "~")
>
> Traceback (most recent call last):
>
> File
> "/home/r60874/rocko/build-xwayland/tmp/work/aarch64-mx8qm-poky-linux/i
> mx-gpu-sdk/5.0.2-r0/recipe-sysroot-native/usr/lib/python3.5/urllib/req
> uest.py",
> line 1254, in do_open
>
> h.request(req.get_method(), req.selector, req.data, headers)
>
> File
> "/home/r60874/rocko/build-xwayland/tmp/work/aarch64-mx8qm-poky-linux/i
> mx-gpu-sdk/5.0.2-r0/recipe-sysroot-native/usr/lib/python3.5/http/clien
> t.py",
> line 1107, in request
>
> self._send_request(method, url, body, headers)
>
> File
> "/home/r60874/rocko/build-xwayland/tmp/work/aarch64-mx8qm-poky-linux/i
> mx-gpu-sdk/5.0.2-r0/recipe-sysroot-native/usr/lib/python3.5/http/clien
> t.py",
> line 1152, in _send_request
>
> self.endheaders(body)
>
> File
> "/home/r60874/rocko/build-xwayland/tmp/work/aarch64-mx8qm-poky-linux/i
> mx-gpu-sdk/5.0.2-r0/recipe-sysroot-native/usr/lib/python3.5/http/clien
> t.py",
> line 1103, in endheaders
>
> self._send_output(message_body)
>
> File
> "/home/r60874/rocko/build-xwayland/tmp/work/aarch64-mx8qm-poky-linux/i
> mx-gpu-sdk/5.0.2-r0/recipe-sysroot-native/usr/lib/python3.5/http/clien
> t.py",
> line 934, in _send_output
>
> self.send(msg)
>
> File
> "/home/r60874/rocko/build-xwayland/tmp/work/aarch64-mx8qm-poky-linux/i
> mx-gpu-sdk/5.0.2-r0/recipe-sysroot-native/usr/lib/python3.5/http/clien
> t.py",
> line 877, in send
>
> self.connect()
>
> File
> "/home/r60874/rocko/build-xwayland/tmp/work/aarch64-mx8qm-poky-linux/i
> mx-gpu-sdk/5.0.2-r0/recipe-sysroot-native/usr/lib/python3.5/http/clien
> t.py",
> line 1261, in connect
>
> server_hostname=server_hostname)
>
> File
> "/home/r60874/rocko/build-xwayland/tmp/work/aarch64-mx8qm-poky-linux/i
> mx-gpu-sdk/5.0.2-r0/recipe-sysroot-native/usr/lib/python3.5/ssl.py",
> line 385, in wrap_socket
>
> _context=self)
>
> File
> "/home/r60874/rocko/build-xwayland/tmp/work/aarch64-mx8qm-poky-linux/i
> mx-gpu-sdk/5.0.2-r0/recipe-sysroot-native/usr/lib/python3.5/ssl.py",
> line 760, in __init__
>
> self.do_handshake()
>
> File
> "/home/r60874/rocko/build-xwayland/tmp/work/aarch64-mx8qm-poky-linux/i
> mx-gpu-sdk/5.0.2-r0/recipe-sysroot-native/usr/lib/python3.5/ssl.py",
> line 996, in do_handshake
>
> self._sslobj.do_handshake()
>
> File
> "/home/r60874/rocko/build-xwayland/tmp/work/aarch64-mx8qm-poky-linux/i
> mx-gpu-sdk/5.0.2-r0/recipe-sysroot-native/usr/lib/python3.5/ssl.py",
> line 641, in do_handshake
>
> self._sslobj.do_handshake()
>
> ssl.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify
> failed
> (_ssl.c:720)
>
>
>
> During handling of the above exception, another exception occurred:
>
>
>
> Traceback (most recent call last):
>
> File "", line 1, in
>
> File
> "/home/r60874/rocko/build-xwayland/tmp/work/aarch64-mx8qm-poky-linux/i
> mx-gpu-sdk/5.0.2-r0/recipe-sysroot-native/usr/lib/python3.5/urllib/req
> uest.py",
> line 188, in urlretrieve
>
> with contextlib.closing(urlopen(url, data)) as fp:
>
> File
> "/home/r60874/rocko/build-xwayland/tmp/work/aarch64-mx8qm-poky-linux/i
> mx-gpu-sdk/5.0.2-r0/recipe-sysroot-native/usr/lib/python3.5/urllib/re
Re: [OE-core] [meta-oe] qemu boot problem
The above text I have posted itself is the full output it's throwing and with with respect to command - runqemu qemux86 On Thu, 5 Apr 2018, 18:38 Alexander Kanavin, < alexander.kana...@linux.intel.com> wrote: > On 04/05/2018 01:43 PM, Rajath C S wrote: > > as the error specifies about a specific recipe missing the license, i'd > > like to know which recipe is that what is the pointer to defaultpkgname > > You need to provide both the command you issue on the command line, and > the full output that it prints. > > Alex > -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [meta-oe] qemu boot problem
Do have a look at main thread of this topic to know the Machine config and error message On Thu, 5 Apr 2018, 18:50 Rajath C S, wrote: > The above text I have posted itself is the full output it's throwing and > with with respect to command - runqemu qemux86 > > > On Thu, 5 Apr 2018, 18:38 Alexander Kanavin, < > alexander.kana...@linux.intel.com> wrote: > >> On 04/05/2018 01:43 PM, Rajath C S wrote: >> > as the error specifies about a specific recipe missing the license, i'd >> > like to know which recipe is that what is the pointer to defaultpkgname >> >> You need to provide both the command you issue on the command line, and >> the full output that it prints. >> >> Alex >> > -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 00/38] Morty Next pull request
Please consider these changes for Morty. Clean AB build This included sdk locale and host glibc 2.27 fixes. The following changes since commit 34b26ec18450a3bc72f7b8a0f2df0bfaae1140dd: linux-firmware: Add reference to iwlwifi-8000C firmware (2018-03-19 15:58:33 +) are available in the git repository at: git://git.yoctoproject.org/poky-contrib stable/morty-next http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=stable/morty-next Alexander Kanavin (2): selftest/signing: add --batch to gpg invocation when importing keys populate_sdk_base.bbclass: add documentation packages to SDKs if api-documentation is in DISTRO_FEATURES Andreas Oberritter (1): libc-package.bbclass: split binary localedata even more if asked to Armin Kuster (3): lib/oe/terminal.py: use an absolute path to execute oe-gnome-terminal-phonehome distcc: Change SRC_URI package_manager: fix install_glob to use morty sdk pkgdir Christopher Larson (1): buildhistory: fix latest_srcrev in the common case Ed Bartosh (1): toolchain-shar-extract: compare SDK and host gcc versions Gianfranco Costamagna (1): glibc-locale.inc: fix typo in comment Juro Bystricky (1): glibc-locale.inc: avoid duplicate packages Linus Wallgren (1): lib/oe/package_manager: .deb pre/postinst args Martin Jansa (1): package_manager: flush installed_pkgs file before oe-pkgdata-util uses it Maxin B. John (1): grub-efi: fix build failure Richard Purdie (4): lib/oe/package_manager/sdk: Ensure do_populate_sdk_ext and do_populate_sdk repos don't conflict glibc: Separate locale files to their own sstate task image/packagegroup/populate_sdk: Drop do_populate_sysroot task properly glibc-package: Avoid race sstate races with do_stash_locale Ross Burton (15): default-distrovars: don't rename locales for nativesdk glibc: don't use host locales in nativesdk glibc: relocate locale paths in nativesdk lib/oe/package_manager: bail if createrepo can't be found package_manager: don't race on a file when installing complementary packages package_manager: improve install_complementary package-manager: add install_glob() sdk: install specified locales into SDK sdk: only install locales if we're using glibc populate_sdk: install UTF-8 locales in SDKs populate_sdk_base: depend on nativesdk-glibc-locale cross-localedef-native: add way to specify which locale archive to write qemu: fix memfd_create with glibc 2.27 sdk: generate locale archive and remove packages sdk: streamline locale removal Stephano Cetola (1): package_manager: remove strings and migrate to direct arrays Tanu Kaskinen (4): e2fsprogs: fix compatibility with glibc 2.27 libvorbis: CVE-2017-14633 libvorbis: CVE-2017-14632 libvorbis: CVE-2018-5146 Zhenbo Gao (1): archiver: avoid archiving source for glibc-locale meta/classes/archiver.bbclass | 6 + meta/classes/buildhistory.bbclass | 2 +- meta/classes/image.bbclass | 2 +- meta/classes/libc-package.bbclass | 39 ++- meta/classes/packagegroup.bbclass | 2 +- meta/classes/populate_sdk_base.bbclass | 11 +- meta/classes/populate_sdk_ext.bbclass | 3 +- meta/conf/distro/include/default-distrovars.inc| 1 + meta/files/toolchain-shar-extract.sh | 8 + meta/lib/oe/package.py | 13 +- meta/lib/oe/package_manager.py | 328 +++-- meta/lib/oe/sdk.py | 85 +- meta/lib/oe/terminal.py| 2 +- meta/lib/oeqa/selftest/signing.py | 2 +- ...ix-check-for-sys-sysmacros.h-under-glibc-.patch | 48 +++ meta/recipes-bsp/grub/grub-efi_2.00.bb | 1 + .../glibc/cross-localedef-native_2.24.bb | 1 + meta/recipes-core/glibc/glibc-collateral.inc | 2 +- meta/recipes-core/glibc/glibc-initial.inc | 2 +- meta/recipes-core/glibc/glibc-locale.inc | 5 +- meta/recipes-core/glibc/glibc-mtrace.inc | 2 +- meta/recipes-core/glibc/glibc-package.inc | 45 +-- meta/recipes-core/glibc/glibc-scripts.inc | 2 +- meta/recipes-core/glibc/glibc/archive-path.patch | 39 +++ .../glibc/glibc/relocate-locales.patch | 33 +++ meta/recipes-core/glibc/glibc_2.24.bb | 7 +- meta/recipes-core/meta/buildtools-tarball.bb | 1 - meta/recipes-devtools/distcc/distcc_3.2.bb | 2 +- ...rename-copy_file_range-to-copy_file_chunk.patch | 62 meta/recipes-devtools/e2fsprogs/e2fsprogs_1.43.bb | 1 + meta/recipes-devtools/qemu/qemu/memfd.patch| 57 meta/recipes-devtools/qemu/qemu_2.7.0.bb | 1 + .../libvorbis/libvorbis/CVE-2017-14632.patch | 62 .../libvorbis/libvorbis/CVE-2017-14633.patch | 42 +++ .../libvorbis/libvorbis/CVE-201
Re: [OE-core] [PATCH] python3: Add recommended modules to nativesdk install
On Wed, 2018-04-04 at 14:25 -0500, Tom Hochstein wrote:
> The python3 installation in the SDK did not include the minimum set
> of modules.
>
> Signed-off-by: Tom Hochstein
> ---
> meta/recipes-devtools/python/python3_3.5.5.bb | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/meta/recipes-devtools/python/python3_3.5.5.bb
> b/meta/recipes-devtools/python/python3_3.5.5.bb
> index d458d32..f893b84 100644
> --- a/meta/recipes-devtools/python/python3_3.5.5.bb
> +++ b/meta/recipes-devtools/python/python3_3.5.5.bb
> @@ -211,6 +211,7 @@ py_package_preprocess () {
>
> # manual dependency additions
> RPROVIDES_${PN}-modules = "${PN}"
> +RRECOMMENDS_${PN}-core_append_class-nativesdk = " nativesdk-python3-
> modules"
> RRECOMMENDS_${PN}-crypt = "openssl"
> RRECOMMENDS_${PN}-crypt_class-nativesdk = "nativesdk-openssl"
This doesn't look correct, if you want the SDK to contain all python
modules, surely you'd just add nativesdk-python3-modules rather than
forcing this everywhere?
Cheers,
Richard
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 00/38] Morty Next pull request
Ignore this request. - armin On 04/05/2018 06:53 AM, Armin Kuster wrote: > Please consider these changes for Morty. Clean AB build > > This included sdk locale and host glibc 2.27 fixes. > > The following changes since commit 34b26ec18450a3bc72f7b8a0f2df0bfaae1140dd: > > linux-firmware: Add reference to iwlwifi-8000C firmware (2018-03-19 > 15:58:33 +) > > are available in the git repository at: > > git://git.yoctoproject.org/poky-contrib stable/morty-next > http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=stable/morty-next > > Alexander Kanavin (2): > selftest/signing: add --batch to gpg invocation when importing keys > populate_sdk_base.bbclass: add documentation packages to SDKs if > api-documentation is in DISTRO_FEATURES > > Andreas Oberritter (1): > libc-package.bbclass: split binary localedata even more if asked to > > Armin Kuster (3): > lib/oe/terminal.py: use an absolute path to execute > oe-gnome-terminal-phonehome > distcc: Change SRC_URI > package_manager: fix install_glob to use morty sdk pkgdir > > Christopher Larson (1): > buildhistory: fix latest_srcrev in the common case > > Ed Bartosh (1): > toolchain-shar-extract: compare SDK and host gcc versions > > Gianfranco Costamagna (1): > glibc-locale.inc: fix typo in comment > > Juro Bystricky (1): > glibc-locale.inc: avoid duplicate packages > > Linus Wallgren (1): > lib/oe/package_manager: .deb pre/postinst args > > Martin Jansa (1): > package_manager: flush installed_pkgs file before oe-pkgdata-util uses > it > > Maxin B. John (1): > grub-efi: fix build failure > > Richard Purdie (4): > lib/oe/package_manager/sdk: Ensure do_populate_sdk_ext and > do_populate_sdk repos don't conflict > glibc: Separate locale files to their own sstate task > image/packagegroup/populate_sdk: Drop do_populate_sysroot task > properly > glibc-package: Avoid race sstate races with do_stash_locale > > Ross Burton (15): > default-distrovars: don't rename locales for nativesdk > glibc: don't use host locales in nativesdk > glibc: relocate locale paths in nativesdk > lib/oe/package_manager: bail if createrepo can't be found > package_manager: don't race on a file when installing complementary > packages > package_manager: improve install_complementary > package-manager: add install_glob() > sdk: install specified locales into SDK > sdk: only install locales if we're using glibc > populate_sdk: install UTF-8 locales in SDKs > populate_sdk_base: depend on nativesdk-glibc-locale > cross-localedef-native: add way to specify which locale archive to > write > qemu: fix memfd_create with glibc 2.27 > sdk: generate locale archive and remove packages > sdk: streamline locale removal > > Stephano Cetola (1): > package_manager: remove strings and migrate to direct arrays > > Tanu Kaskinen (4): > e2fsprogs: fix compatibility with glibc 2.27 > libvorbis: CVE-2017-14633 > libvorbis: CVE-2017-14632 > libvorbis: CVE-2018-5146 > > Zhenbo Gao (1): > archiver: avoid archiving source for glibc-locale > > meta/classes/archiver.bbclass | 6 + > meta/classes/buildhistory.bbclass | 2 +- > meta/classes/image.bbclass | 2 +- > meta/classes/libc-package.bbclass | 39 ++- > meta/classes/packagegroup.bbclass | 2 +- > meta/classes/populate_sdk_base.bbclass | 11 +- > meta/classes/populate_sdk_ext.bbclass | 3 +- > meta/conf/distro/include/default-distrovars.inc| 1 + > meta/files/toolchain-shar-extract.sh | 8 + > meta/lib/oe/package.py | 13 +- > meta/lib/oe/package_manager.py | 328 > +++-- > meta/lib/oe/sdk.py | 85 +- > meta/lib/oe/terminal.py| 2 +- > meta/lib/oeqa/selftest/signing.py | 2 +- > ...ix-check-for-sys-sysmacros.h-under-glibc-.patch | 48 +++ > meta/recipes-bsp/grub/grub-efi_2.00.bb | 1 + > .../glibc/cross-localedef-native_2.24.bb | 1 + > meta/recipes-core/glibc/glibc-collateral.inc | 2 +- > meta/recipes-core/glibc/glibc-initial.inc | 2 +- > meta/recipes-core/glibc/glibc-locale.inc | 5 +- > meta/recipes-core/glibc/glibc-mtrace.inc | 2 +- > meta/recipes-core/glibc/glibc-package.inc | 45 +-- > meta/recipes-core/glibc/glibc-scripts.inc | 2 +- > meta/recipes-core/glibc/glibc/archive-path.patch | 39 +++ > .../glibc/glibc/relocate-locales.patch | 33 +++ > meta/recipes-core/glibc/glibc_2.24.bb | 7 +- > meta/recipes-core/meta/buildtools-tarball.bb | 1 - > meta/recipes-devtools/distcc/distcc_3.2.bb | 2 +- > ...rename-copy_file_range-to-copy_file_chunk.patch | 62 > meta/recipes-devtools/e2fsprogs/e2fsprogs_
Re: [OE-core] [PATCH] gcc-sanitizers: Update supported architectures
On 4 April 2018 at 18:25, Khem Raj wrote:
> On 4/4/18 9:08 AM, Dan McGregor wrote:
>> From: Dan McGregor
>>
>> aarch64 has been supported since GCC 5.1, sparc has been supported
>> since 4.9, and S390 since 7.1.
>>
>> Also mark as broken entirely with musl.
>>
>
> this change is ok to apply.
I also think it's appropriate for rocko as-is, and for pyro without
the s390 bits.
>
>> Signed-off-by: Dan McGregor
>> ---
>> meta/recipes-devtools/gcc/gcc-sanitizers.inc | 10 +++---
>> 1 file changed, 7 insertions(+), 3 deletions(-)
>>
>> diff --git a/meta/recipes-devtools/gcc/gcc-sanitizers.inc
>> b/meta/recipes-devtools/gcc/gcc-sanitizers.inc
>> index 3183b29dec9..3b7e0028f2b 100644
>> --- a/meta/recipes-devtools/gcc/gcc-sanitizers.inc
>> +++ b/meta/recipes-devtools/gcc/gcc-sanitizers.inc
>> @@ -61,15 +61,19 @@ RDEPENDS_libubsan-dev += "${PN}"
>> RDEPENDS_liblsan-dev += "${PN}"
>> RDEPENDS_libtsan-dev += "${PN}"
>> RRECOMMENDS_${PN} += "libasan libubsan"
>> -RRECOMMENDS_${PN}_append_x86-64 = " liblsan libtsan"
>> RRECOMMENDS_${PN}_append_x86 = " liblsan"
>> +RRECOMMENDS_${PN}_append_x86-64 = " liblsan libtsan"
>> +RRECOMMENDS_${PN}_append_powerpc64 = " liblsan libtsan"
>> +RRECOMMENDS_${PN}_append_aarch64 = " liblsan libtsan"
>>
>> do_package_write_ipk[depends] +=
>> "virtual/${MLPREFIX}${TARGET_PREFIX}compilerlibs:do_packagedata"
>> do_package_write_deb[depends] +=
>> "virtual/${MLPREFIX}${TARGET_PREFIX}compilerlibs:do_packagedata"
>> do_package_write_rpm[depends] +=
>> "virtual/${MLPREFIX}${TARGET_PREFIX}compilerlibs:do_packagedata"
>>
>> -# MIPS, aarch64, and SPARC are broken.
>> -COMPATIBLE_HOST = '(x86_64|i.86|powerpc|arm).*-linux'
>> +# Only x86, powerpc, sparc, s390, arm, and aarch64 are supported
>> +COMPATIBLE_HOST = '(x86_64|i.86|powerpc|sparc|s390|arm|aarch64).*-linux'
>> +# musl is currently broken entirely
>> +COMPATIBLE_HOST_libc-musl = 'null'
>>
>> FILES_libasan += "${libdir}/libasan.so.*"
>> FILES_libasan-dev += "\
>>
>
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 20/22] procps: update to 3.3.13
On Wed, 2018-04-04 at 14:13 +0300, Alexander Kanavin wrote: > Signed-off-by: Alexander Kanavin Does this build on musl? https://autobuilder.yocto.io/builders/nightly-musl-x86-64/builds/389/st eps/BuildImages/logs/stdio or was there some other bad interaction in master-next? Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 00/21] Package updates for Master
On Tue, 2018-04-03 at 18:48 -0700, Armin Kuster wrote: > Please concider these changes for master next. > The X11 changes should not go in sumo. These changes will affect > meta-oe > and possible others > > The following changes since commit > 4cedddb83623c79980b354642dfeaf78218ca4b7: > > libpcre-ptest: skip locale test (2018-03-30 09:40:34 +0100) > > are available in the git repository at: > > git://git.openembedded.org/openembedded-core-contrib > akuster/master-updates > http://cgit.openembedded.org/openembedded-core-contrib/log/?h=akust > er/master-updates https://autobuilder.yocto.io/builders/nightly-musl-x86-64/builds/389/steps/BuildImages/logs/stdio I think we may need to remove libxcalibrate, its probably obsolete now anyway? Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 14/22] icu: update to 61.1
On Thu, Apr 5, 2018 at 2:32 AM, Alexander Kanavin wrote: > On 04/05/2018 03:20 AM, Khem Raj wrote: >> >> On 4/4/18 4:13 AM, Alexander Kanavin wrote: >>> >>> License-Update: copyright years updated, added terms for Google >>> double-conversion >> >> >> should this change to terms reflect in LICENSE filed as well. > > > The LICENSE is set to ICU, which I take means "review manually". It consists > of separate terms for different componetns that icu is made of. > Yes thanks, I guess thats reasonable. > Alex -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 08/22] bash-completion: update to 2.8
On Thu, Apr 5, 2018 at 2:27 AM, Alexander Kanavin wrote: > On 04/05/2018 03:18 AM, Khem Raj wrote: >>> >>> # Delete files already provided by util-linux >>> local i >>> - for i in mount umount rfkill; do >>> + for i in mount umount; do >> >> >> where did rfkill go ? > > > util-linux obviously. bash-completion no longer provides it in 2.8. perhaps should be in commit message. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] curl: DEPENDS on libidn2 (not libidn)
On Thu, Apr 5, 2018 at 4:08 AM, André Draszik wrote: > From: André Draszik > > Since v7.51.0, libidn2 is the only available option, libidn > support was dropped. > The configure option was renamed as of v7.53.0 > > Therefore, curl unconditionally tries to build against libidn2, > which in particular is a problem for curl-native, as that might > or might not build against the build-machine's libidn2 now, > which furthermore causes problems when trying to share sstate > between multiple build machines. > > We therefore see the following in the config log: > ... > checking whether to build with libidn2... (assumed) yes > ... > checking for libidn2 options with pkg-config... no > configure: IDN_LIBS: "-lidn2" > configure: IDN_LDFLAGS: "" > configure: IDN_CPPFLAGS: "" > configure: IDN_DIR: "" > checking if idn2_lookup_ul can be linked... yes > checking idn2.h usability... yes > checking idn2.h presence... yes > checking for idn2.h... yes > ... > IDN support: enabled (libidn2) > ... > even though this recipe tries to disable that. > > While libidn2 isn't available in OE, this change at least: > * prevents curl-native to silently build against libidn2 if > that is installed on build machine, even if not requested > * alerts people who use the PACKAGECONFIG option that it's > not actually doing what they intend to do > this is ok. > Signed-off-by: André Draszik > --- > meta/recipes-support/curl/curl_7.58.0.bb | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/meta/recipes-support/curl/curl_7.58.0.bb > b/meta/recipes-support/curl/curl_7.58.0.bb > index 5535a5609b..d2d0180268 100644 > --- a/meta/recipes-support/curl/curl_7.58.0.bb > +++ b/meta/recipes-support/curl/curl_7.58.0.bb > @@ -34,7 +34,7 @@ PACKAGECONFIG[imap] = "--enable-imap,--disable-imap," > PACKAGECONFIG[ipv6] = "--enable-ipv6,--disable-ipv6," > PACKAGECONFIG[ldap] = "--enable-ldap,--disable-ldap," > PACKAGECONFIG[ldaps] = "--enable-ldaps,--disable-ldaps," > -PACKAGECONFIG[libidn] = "--with-libidn,--without-libidn,libidn" > +PACKAGECONFIG[libidn] = "--with-libidn2,--without-libidn2,libidn2" > PACKAGECONFIG[libssh2] = "--with-libssh2,--without-libssh2,libssh2" > PACKAGECONFIG[pop3] = "--enable-pop3,--disable-pop3," > PACKAGECONFIG[proxy] = "--enable-proxy,--disable-proxy," > -- > 2.16.2 > > -- > ___ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] master branch and stabilisation
We're trying to focus on getting a good 2.5 release. We've had around 80 upgrades to recipes on the list after the freeze and basically the maintainers like Ross and myself are damned if we do and damned if we don't. I usually try and ignore them at this point in a release. This then upsets people as they don't get feedback and makes my life horrible when I eventually try and round them up. Instead I've tried pulling them into master-next. So far so good but I thought I'd better see how much of a mess the branch is in. Conclusion is at least 3 different failures, some of which I can't even easily figure out the patch causing it. So I now get to spend my time trying to figure out which patch broke what so I can report back on it and make the branch build again by dropping the broken patches. This means I'm trying to do full on day to day development as usual as well as trying to sort release issues like the imminent fedora28 issue I should be paying attention to instead. So, a question, what do people want me to do? Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v3 0/5] systemtap adding sysroot, cross compiling of user land related scripts
Hi, This is third version of patch series of SystemTap supporting sysroot and SystemTap script cross compilation, integrated with OE workflow. Version 3 Changes: * Simplified and cleaned image-combined-dbg class, as per Richard's neat suggestion * Rebased to latest tree to resolve merge conflict with systemtap and gcc-8 recent change Version 2 Patches, since first, RFC, version [1] the following changes were done: image: add image-combined-dbg helper class Needed to create rootfs-dbg that contains both target binaries and debug symbols. Instead of IMAGE_GEN_COMBINED_DEBUGFS build option as in RFC patches [2], small additional class is introduced that allows adding target symbols back into rootfs-dbg. The approach was suggested by Khem, as response on first RFC patches. Revert "systemtap: Cross compilation fix" Remove previous OE specific patch. It superseded by --sysroot support patch series systemtap: support --sysroot option in variety of situations in cross build Backport of SystemTap patches required to support --sysroot. Since my first post I worked with SystemTap maintainers and now all needed fixes for sysroot support got accepted. systemtap: create translator packageconfig Creates new PACKAGECONFIG, translator, which is on by default, but if dropped resulting systemtap package would contain only minimal run-time utilities required to activate/run host cross compiled SystemTap modules. It is implemented in such way instead of separate systemtap-utils recipe based on team's feedback. crosstap: replace script with new python based implementation Full backward compatible replacement of original crosstap shell script, written in python with extended functionality to support SystemTap scripts for user-land using --sysroot option. Compared to RFC version new script invocation wise is fully backward compatible with orginal crosstap shell script. Full setup with patch series and examples that were used for testing is available at [3]. [1] http://lists.openembedded.org/pipermail/openembedded-core/2018-March/148387.html [2] http://lists.openembedded.org/pipermail/openembedded-core/2018-March/148392.html [3] https://github.com/victorkamensky/systemtap-oe-sysroot-manifest Victor Kamensky (5): image: add image-combined-dbg helper class Revert "systemtap: Cross compilation fix" systemtap: support --sysroot option in variety of situations in cross build systemtap: create translator packageconfig crosstap: replace script with new python based implementation meta/classes/image-combined-dbg.bbclass| 9 + ...001-Added-a-couple-of-small-sysroot-fixes.patch | 42 ++ ...g-sysroot-path-to-module-name-in-case-of-.patch | 61 +++ ...sure-sysroot-paths-don-t-end-with-a-slash.patch | 128 + ...root-when-looking-for-the-System.map-file.patch | 29 + ...e_relocate-needs-target-file-path-not-hos.patch | 39 ++ ...ookup-with-sysroot-case-do-not-remove-sys.patch | 42 ++ ...-short-release-r-option-handling-follow-u.patch | 40 ++ ...sroot-fix-short-release-r-option-handling.patch | 53 ++ ...dle-symbolic-links-with-absolute-name-rel.patch | 117 .../systemtap/systemtap/system_map_location.patch | 23 - meta/recipes-kernel/systemtap/systemtap_git.bb | 15 +- meta/recipes-kernel/systemtap/systemtap_git.inc| 10 +- scripts/crosstap | 586 - 14 files changed, 1030 insertions(+), 164 deletions(-) create mode 100644 meta/classes/image-combined-dbg.bbclass create mode 100644 meta/recipes-kernel/systemtap/systemtap/0001-Added-a-couple-of-small-sysroot-fixes.patch create mode 100644 meta/recipes-kernel/systemtap/systemtap/0001-Delay-adding-sysroot-path-to-module-name-in-case-of-.patch create mode 100644 meta/recipes-kernel/systemtap/systemtap/0001-Make-sure-sysroot-paths-don-t-end-with-a-slash.patch create mode 100644 meta/recipes-kernel/systemtap/systemtap/0001-Use-sysroot-when-looking-for-the-System.map-file.patch create mode 100644 meta/recipes-kernel/systemtap/systemtap/0001-_stp_umodule_relocate-needs-target-file-path-not-hos.patch create mode 100644 meta/recipes-kernel/systemtap/systemtap/0001-debuginfo-lookup-with-sysroot-case-do-not-remove-sys.patch create mode 100644 meta/recipes-kernel/systemtap/systemtap/0001-sysroot-fix-short-release-r-option-handling-follow-u.patch create mode 100644 meta/recipes-kernel/systemtap/systemtap/0001-sysroot-fix-short-release-r-option-handling.patch create mode 100644 meta/recipes-kernel/systemtap/systemtap/0001-sysroot-handle-symbolic-links-with-absolute-name-rel.patch delete mode 100644 meta/recipes-kernel/systemtap/systemtap/system_map_location.patch -- 2.7.4 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org
[OE-core] [PATCH v3 1/5] image: add image-combined-dbg helper class
There is IMAGE_GEN_DEBUGFS="1" variable that enables build of
additional rootfs-dbg and additional archive that contains
complimentary symbols files for a given image. But the issue
with this resulting directory and tarball that before use it
has to be combined with original image content. It is required
since all cross debugging tools like gdb, perf, and systemtap
need file system that contains both target executables/libraries
and their symbols. Those tools need to find executable/library
first and through it debuglink note find corresponding symbols
file.
image-combined-dbg when added to USER_CLASSES just copies
final resulting rootfs back into rootfs-dbg creating combined
target and debug symbols rootfs that can be used for debugging
directly.
Signed-off-by: Victor Kamensky
---
meta/classes/image-combined-dbg.bbclass | 9 +
1 file changed, 9 insertions(+)
create mode 100644 meta/classes/image-combined-dbg.bbclass
diff --git a/meta/classes/image-combined-dbg.bbclass
b/meta/classes/image-combined-dbg.bbclass
new file mode 100644
index 000..f4772f7
--- /dev/null
+++ b/meta/classes/image-combined-dbg.bbclass
@@ -0,0 +1,9 @@
+IMAGE_PREPROCESS_COMMAND_append = " combine_dbg_image; "
+
+combine_dbg_image () {
+if [ "${IMAGE_GEN_DEBUGFS}" = "1" -a -e ${IMAGE_ROOTFS}-dbg ]; then
+# copy target files into -dbg rootfs, so it can be used for
+# debug purposes directly
+tar -C ${IMAGE_ROOTFS} -cf - . | tar -C ${IMAGE_ROOTFS}-dbg
-xf -
+fi
+}
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v3 3/5] systemtap: support --sysroot option in variety of situations in cross build
For details on issues fixed please look at commit message of individual
patches.
Upstream-Status: Backport [system...@sourceware.org]
Signed-off-by: Victor Kamensky
---
...001-Added-a-couple-of-small-sysroot-fixes.patch | 42 +++
...g-sysroot-path-to-module-name-in-case-of-.patch | 61 ++
...sure-sysroot-paths-don-t-end-with-a-slash.patch | 128 +
...root-when-looking-for-the-System.map-file.patch | 29 +
...e_relocate-needs-target-file-path-not-hos.patch | 39 +++
...ookup-with-sysroot-case-do-not-remove-sys.patch | 42 +++
...-short-release-r-option-handling-follow-u.patch | 40 +++
...sroot-fix-short-release-r-option-handling.patch | 53 +
...dle-symbolic-links-with-absolute-name-rel.patch | 117 +++
meta/recipes-kernel/systemtap/systemtap_git.inc| 9 ++
10 files changed, 560 insertions(+)
create mode 100644
meta/recipes-kernel/systemtap/systemtap/0001-Added-a-couple-of-small-sysroot-fixes.patch
create mode 100644
meta/recipes-kernel/systemtap/systemtap/0001-Delay-adding-sysroot-path-to-module-name-in-case-of-.patch
create mode 100644
meta/recipes-kernel/systemtap/systemtap/0001-Make-sure-sysroot-paths-don-t-end-with-a-slash.patch
create mode 100644
meta/recipes-kernel/systemtap/systemtap/0001-Use-sysroot-when-looking-for-the-System.map-file.patch
create mode 100644
meta/recipes-kernel/systemtap/systemtap/0001-_stp_umodule_relocate-needs-target-file-path-not-hos.patch
create mode 100644
meta/recipes-kernel/systemtap/systemtap/0001-debuginfo-lookup-with-sysroot-case-do-not-remove-sys.patch
create mode 100644
meta/recipes-kernel/systemtap/systemtap/0001-sysroot-fix-short-release-r-option-handling-follow-u.patch
create mode 100644
meta/recipes-kernel/systemtap/systemtap/0001-sysroot-fix-short-release-r-option-handling.patch
create mode 100644
meta/recipes-kernel/systemtap/systemtap/0001-sysroot-handle-symbolic-links-with-absolute-name-rel.patch
diff --git
a/meta/recipes-kernel/systemtap/systemtap/0001-Added-a-couple-of-small-sysroot-fixes.patch
b/meta/recipes-kernel/systemtap/systemtap/0001-Added-a-couple-of-small-sysroot-fixes.patch
new file mode 100644
index 000..c0ceb5a
--- /dev/null
+++
b/meta/recipes-kernel/systemtap/systemtap/0001-Added-a-couple-of-small-sysroot-fixes.patch
@@ -0,0 +1,42 @@
+From a714658727206d2a98a7194b7e6d29dbd3e27b8d Mon Sep 17 00:00:00 2001
+From: David Smith
+Date: Mon, 19 Mar 2018 16:50:05 -0500
+Subject: [PATCH] Added a couple of small sysroot fixes.
+
+* tapsets.cxx (dwarf_builder::build): Fix commit 4ffecddf5.
+ (path_remove_sysroot): Fix extra '/' present at start of paths.
+
+Upstream-Status: Backport
+Signed-off-by: Victor Kamensky
+---
+ tapsets.cxx | 10 +++---
+ 1 file changed, 7 insertions(+), 3 deletions(-)
+
+Index: git/tapsets.cxx
+===
+--- git.orig/tapsets.cxx
git/tapsets.cxx
+@@ -1395,7 +1395,8 @@ string path_remove_sysroot(const systemt
+ string retval = path;
+ if (!sess.sysroot.empty() &&
+ (pos = retval.find(sess.sysroot)) != string::npos)
+-retval.replace(pos, sess.sysroot.length(), "/");
++retval.replace(pos, sess.sysroot.length(),
++ (sess.sysroot.back() == '/' ? "/": ""));
+ return retval;
+ }
+
+@@ -8412,8 +8413,11 @@ dwarf_builder::build(systemtap_session &
+
+ // PR13338: unquote glob results
+ module_name = unescape_glob_chars (module_name);
+- user_path = find_executable (module_name, "", sess.sysenv); //
canonicalize it
+- if (!is_fully_resolved(user_path, sess.sysroot, sess.sysenv))
++ user_path = find_executable (module_name, sess.sysroot, sess.sysenv);
// canonicalize it
++ // Note we don't need to pass the sysroot to
++ // is_fully_resolved(), since we just passed it to
++ // find_executable().
++ if (!is_fully_resolved(user_path, "", sess.sysenv))
+ throw SEMANTIC_ERROR(_F("cannot find executable '%s'",
+ user_path.to_string().c_str()));
+
diff --git
a/meta/recipes-kernel/systemtap/systemtap/0001-Delay-adding-sysroot-path-to-module-name-in-case-of-.patch
b/meta/recipes-kernel/systemtap/systemtap/0001-Delay-adding-sysroot-path-to-module-name-in-case-of-.patch
new file mode 100644
index 000..89951a2
--- /dev/null
+++
b/meta/recipes-kernel/systemtap/systemtap/0001-Delay-adding-sysroot-path-to-module-name-in-case-of-.patch
@@ -0,0 +1,61 @@
+From 4ffecddf5433d65a6f01241990c9d516586b1c79 Mon Sep 17 00:00:00 2001
+From: Victor Kamensky
+Date: Mon, 19 Mar 2018 08:53:51 -0500
+Subject: [PATCH] Delay adding sysroot path to module name in case of non
+ absolute executable
+
+Current stap code adds sysroot prematurely for probes that specify non
+absolute path name, i.e like "foo", so when find_executable called it
+receives full path as /foo and find_executable does not search
+PATH while applying sysroot.
+
+Fix delays adding sysroot
[OE-core] [PATCH v3 2/5] Revert "systemtap: Cross compilation fix"
This reverts commit 787bed708676fc04aee2850825e803273152f657.
Signed-off-by: Victor Kamensky
---
.../systemtap/systemtap/system_map_location.patch | 23 --
meta/recipes-kernel/systemtap/systemtap_git.inc| 1 -
2 files changed, 24 deletions(-)
delete mode 100644
meta/recipes-kernel/systemtap/systemtap/system_map_location.patch
diff --git a/meta/recipes-kernel/systemtap/systemtap/system_map_location.patch
b/meta/recipes-kernel/systemtap/systemtap/system_map_location.patch
deleted file mode 100644
index 013af5c..000
--- a/meta/recipes-kernel/systemtap/systemtap/system_map_location.patch
+++ /dev/null
@@ -1,23 +0,0 @@
-systemtap: Cross compilation fix
-
-This is a cross compilation fix. It allows systemtap to find
-the kernel map file in the right place, i.e. in the kernel build tree.
-Without this fix it takes a map file from the build host, if available.
-
-Upstream-Status: Pending
-
-Signed-off-by: Mikhail Durnev
-
-Index: git/session.cxx
-===
git.orig/session.cxx
-+++ git/session.cxx
-@@ -1634,7 +1634,7 @@ systemtap_session::parse_kernel_function
- clog << _F("Kernel symbol table %s unavailable, (%s)",
- system_map_path.c_str(), strerror(errno)) << endl;
-
-- system_map_path = "/boot/System.map-" + kernel_release;
-+ system_map_path = kernel_build_tree + "/System.map-" + kernel_release;
- system_map.clear();
- system_map.open(system_map_path.c_str(), ifstream::in);
- if (! system_map.is_open())
diff --git a/meta/recipes-kernel/systemtap/systemtap_git.inc
b/meta/recipes-kernel/systemtap/systemtap_git.inc
index 4d887ed..eef0c9c 100644
--- a/meta/recipes-kernel/systemtap/systemtap_git.inc
+++ b/meta/recipes-kernel/systemtap/systemtap_git.inc
@@ -4,7 +4,6 @@ SRCREV = "4051c70c9318c837981384cbb23f3e9eb1bd0892"
PV = "3.2"
SRC_URI = "git://sourceware.org/git/systemtap.git \
- file://system_map_location.patch \
file://configure-allow-to-disable-libvirt.patch \
file://x32_abi_time.patch \
file://monitor-option.patch \
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v3 4/5] systemtap: create translator packageconfig
For cases when systemap module compilation happens on host in
cross-compilation mode, and it is desirable to minimize systemtap
presense on target we need to have just smallest possible set of
utilties that are required to run compiled modules.
Introduce new "translator" PACKAGECONFIG, if it is not set
it would mean that just minimal set of run-time utilities will
be included in the package.
For run-time only systemtap build variant use
PACKAGECONFIG_pn-systemtap = "" or
PACKAGECONFIG_pn-systemtap = "monitor"
Suggested-by: Taras Kondratiuk
Signed-off-by: Victor Kamensky
---
meta/recipes-kernel/systemtap/systemtap_git.bb | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/meta/recipes-kernel/systemtap/systemtap_git.bb
b/meta/recipes-kernel/systemtap/systemtap_git.bb
index 475b207..b280f58 100644
--- a/meta/recipes-kernel/systemtap/systemtap_git.bb
+++ b/meta/recipes-kernel/systemtap/systemtap_git.bb
@@ -3,9 +3,7 @@ HOMEPAGE = "https://sourceware.org/systemtap/";
require systemtap_git.inc
-DEPENDS = "boost elfutils"
-
-RDEPENDS_${PN} += "python3-core bash perl"
+DEPENDS = "elfutils"
EXTRA_OECONF += "--with-libelf=${STAGING_DIR_TARGET} --without-rpm \
--without-nss --without-avahi --without-dyninst \
@@ -18,7 +16,8 @@ STAP_DOCS ?= "--disable-docs --disable-publican
--disable-refdocs"
EXTRA_OECONF += "${STAP_DOCS} "
-PACKAGECONFIG ??= "sqlite monitor python3-probes"
+PACKAGECONFIG ??= "translator sqlite monitor python3-probes"
+PACKAGECONFIG[translator] =
"--enable-translator,--disable-translator,boost,python3-core bash perl"
PACKAGECONFIG[libvirt] = "--enable-libvirt,--disable-libvirt,libvirt"
PACKAGECONFIG[sqlite] = "--enable-sqlite,--disable-sqlite,sqlite3"
PACKAGECONFIG[monitor] = "--enable-monitor,--disable-monitor,ncurses json-c"
@@ -26,4 +25,12 @@ PACKAGECONFIG[python3-probes] =
"--with-python3-probes,--without-python3-probes,
inherit autotools gettext pkgconfig distutils3-base
+do_install_append () {
+ if [ ! -f ${D}${bindir}/stap ]; then
+ # translator disabled case, need to leave only minimal runtime
+ rm -rf ${D}${datadir}/${PN}
+ rm ${D}${libexecdir}/${PN}/stap-env
+ fi
+}
+
BBCLASSEXTEND = "nativesdk"
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v3 5/5] crosstap: replace script with new python based implementation
New crosstap python implementation is total replacement for
crosstap shell script, that has superseding capabilities.
New script support cross compiling of SystemTap scripts
for user-land, by using supplied image rootfs. Whereas old
script could only deal with scripts against kernel. New script
has more complex logic and additional capabilities.
As invocation interface new script support old "legacy"
mode and provides alternative new regular options interface
to access additional functionality.
Signed-off-by: Victor Kamensky
---
scripts/crosstap | 586 ++-
1 file changed, 450 insertions(+), 136 deletions(-)
diff --git a/scripts/crosstap b/scripts/crosstap
index 39739bb..e33fa4a 100755
--- a/scripts/crosstap
+++ b/scripts/crosstap
@@ -1,15 +1,22 @@
-#!/bin/bash
+#!/usr/bin/env python3
#
-# Run a systemtap script on remote target
+# Build a systemtap script for a given image, kernel
#
-# Examples (run on build host, target is 192.168.1.xxx):
-# $ source oe-init-build-env"
-# $ cd ~/my/systemtap/scripts"
+# Effectively script extracts needed information from set of
+# 'bitbake -e' commands and contructs proper invocation of stap on
+# host to build systemtap script for a given target.
#
-# $ crosstap r...@192.168.1.xxx myscript.stp"
-# $ crosstap r...@192.168.1.xxx myscript-with-args.stp 99 ninetynine"
+# By default script will compile scriptname.ko that could be copied
+# to taget and activated with 'staprun scriptname.ko' command. Or if
+# --remote user@hostname option is specified script will build, load
+# execute script on target.
#
-# Copyright (c) 2012, Intel Corporation.
+# This script is very similar and inspired by crosstap shell script.
+# The major difference that this script supports user-land related
+# systemtap script, whereas crosstap could deal only with scripts
+# related to kernel.
+#
+# Copyright (c) 2018, Cisco Systems.
# All rights reserved.
#
# This program is free software; you can redistribute it and/or modify
@@ -25,131 +32,438 @@
# along with this program; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
-function usage() {
-echo "Usage: $0 [additional
systemtap-script args]"
-}
-
-function setup_usage() {
-echo ""
-echo "'crosstap' requires a local sdk build of the target system"
-echo "(or a build that includes 'tools-profile') in order to build"
-echo "kernel modules that can probe the target system."
-echo ""
-echo "Practically speaking, that means you need to do the following:"
-echo " - If you're running a pre-built image, download the release"
-echo "and/or BSP tarballs used to build the image."
-echo " - If you're working from git sources, just clone the metadata"
-echo "and BSP layers needed to build the image you'll be booting."
-echo " - Make sure you're properly set up to build a new image (see"
-echo "the BSP README and/or the widely available basic documentation"
-echo "that discusses how to build images)."
-echo " - Build an -sdk version of the image e.g.:"
-echo " $ bitbake core-image-sato-sdk"
-echo " OR"
-echo " - Build a non-sdk image but include the profiling tools:"
-echo " [ edit local.conf and add 'tools-profile' to the end of"
-echo "the EXTRA_IMAGE_FEATURES variable ]"
-echo " $ bitbake core-image-sato"
-echo ""
-echo " [ NOTE that 'crosstap' needs to be able to ssh into the target"
-echo "system, which isn't enabled by default in -minimal images. ]"
-echo ""
-echo "Once you've build the image on the host system, you're ready to"
-echo "boot it (or the equivalent pre-built image) and use 'crosstap'"
-echo "to probe it (you need to source the environment as usual first):"
-echo ""
-echo "$ source oe-init-build-env"
-echo "$ cd ~/my/systemtap/scripts"
-echo "$ crosstap r...@192.168.1.xxx myscript.stp"
-echo ""
-}
-
-function systemtap_target_arch() {
-SYSTEMTAP_TARGET_ARCH=$1
-case $SYSTEMTAP_TARGET_ARCH in
-i?86)
-SYSTEMTAP_TARGET_ARCH="i386"
-;;
-x86?64*)
-SYSTEMTAP_TARGET_ARCH="x86_64"
-;;
-arm*)
-SYSTEMTAP_TARGET_ARCH="arm"
-;;
-powerpc*)
-SYSTEMTAP_TARGET_ARCH="powerpc"
-;;
-*)
-;;
-esac
-}
-
-if [ $# -lt 2 ]; then
- usage
- exit 1
-fi
-
-if [ -z "$BUILDDIR" ]; then
-echo "Error: Unable to find the BUILDDIR environment variable."
-echo "Did you forget to source your build system environment setup script?"
-exit 1
-fi
-
-pushd $PWD
-cd $BUILDDIR
-BITBAKE_VARS=`bitbake -e virtual/kernel`
-popd
-
-STAGING_BINDIR_TOOLCHAIN=$(echo "$BITBAKE_VARS" | grep
^STAGING_BINDIR_TOOLCHAIN \
- | cut -d '=' -f2 | cut -d '"' -f2)
-STAGING_BINDIR_TOOLPREFIX=$(echo
Re: [OE-core] master branch and stabilisation
On 04/05/2018 10:05 AM, Richard Purdie wrote: > We're trying to focus on getting a good 2.5 release. We've had around > 80 upgrades to recipes on the list after the freeze and basically the > maintainers like Ross and myself are damned if we do and damned if we > don't. > > I usually try and ignore them at this point in a release. This then > upsets people as they don't get feedback and makes my life horrible > when I eventually try and round them up. > > Instead I've tried pulling them into master-next. So far so good but I > thought I'd better see how much of a mess the branch is in. Conclusion > is at least 3 different failures, some of which I can't even easily > figure out the patch causing it. > > So I now get to spend my time trying to figure out which patch broke > what so I can report back on it and make the branch build again by > dropping the broken patches. I will take a look as I have a large set in there. > > This means I'm trying to do full on day to day development as usual as > well as trying to sort release issues like the imminent fedora28 issue > I should be paying attention to instead. > > So, a question, what do people want me to do? I would rather see you focus on the release. - Armin > > Cheers, > > Richard > -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] master branch and stabilisation
On 04/05/2018 08:05 PM, Richard Purdie wrote: So I now get to spend my time trying to figure out which patch broke what so I can report back on it and make the branch build again by dropping the broken patches. This means I'm trying to do full on day to day development as usual as well as trying to sort release issues like the imminent fedora28 issue I should be paying attention to instead. So, a question, what do people want me to do? You can file bugs with master-next failures and assign them to me, without looking at the failed logs at all. Multitasking is stressful for the brain, much better to do things one after the other than switch context. And I'm not particularly time crunched now. We should probably more strictly enforce the freeze - just reject the patches and ask to rebase and re-send after a specific date. Alex -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] master branch and stabilisation
On Thu, 2018-04-05 at 18:05 +0100, Richard Purdie wrote: > We're trying to focus on getting a good 2.5 release. We've had around > 80 upgrades to recipes on the list after the freeze and basically the > maintainers like Ross and myself are damned if we do and damned if we > don't. > > I usually try and ignore them at this point in a release. This then > upsets people as they don't get feedback and makes my life horrible > when I eventually try and round them up. > > Instead I've tried pulling them into master-next. So far so good but > I > thought I'd better see how much of a mess the branch is in. > Conclusion > is at least 3 different failures, some of which I can't even easily > figure out the patch causing it. > > So I now get to spend my time trying to figure out which patch broke > what so I can report back on it and make the branch build again by > dropping the broken patches. > > This means I'm trying to do full on day to day development as usual > as > well as trying to sort release issues like the imminent fedora28 > issue > I should be paying attention to instead. I've got a build running on in a Ubuntu 16.04 container to try and reproduce the bug you were seeing with the new uninative. I'll see if I can get anywhere on that. If nothing else, it will get more data points and extra testing on the change > > So, a question, what do people want me to do? > > Cheers, > > Richard > -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [pyro 0/1] Backport debugedit fixes for pyro
This is intended for 2.3.4. The following changes since commit f3e674cb654d4dab3e4ba5b2ae1fac72ef8363da: distcc: Change SRC_URI (2018-04-05 16:26:20 +0100) are available in the git repository at: git://git.yoctoproject.org/poky-contrib abrindle/backport http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=abrindle/backport Alexander Kanavin (1): package.bbclass: replace rpm/debugedit with dwarfsrcfiles meta/classes/package.bbclass | 29 -- .../dwarfsrcfiles/dwarfsrcfiles.bb | 22 .../dwarfsrcfiles/files/dwarfsrcfiles.c| 111 + 3 files changed, 156 insertions(+), 6 deletions(-) create mode 100644 meta/recipes-devtools/dwarfsrcfiles/dwarfsrcfiles.bb create mode 100644 meta/recipes-devtools/dwarfsrcfiles/files/dwarfsrcfiles.c -- 2.7.4 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [pyro 1/1] package.bbclass: replace rpm/debugedit with dwarfsrcfiles
From: Alexander Kanavin
Debugedit provided by rpm 4.14 is rewriting binaries in-place, and was
found to produce broken output at least for grub:
http://lists.openembedded.org/pipermail/openembedded-core/2017-November/143989.html
A replacement utility was suggested via private mail:
https://lists.fedorahosted.org/archives/list/elfutils-de...@lists.fedorahosted.org/message/VZP4G5N2ELYZEDAB3QYLXYHDGX4WMCUF/
(From OE-Core rev: f2e6e1d3bfd4c92ef0f5ed4721fd9050c59dafca)
Signed-off-by: Alexander Kanavin
Signed-off-by: Richard Purdie
(cherry picked from commit 0d5475a3b28d9e2c9273967a03726bb6c427bd11)
---
meta/classes/package.bbclass | 29 --
.../dwarfsrcfiles/dwarfsrcfiles.bb | 22
.../dwarfsrcfiles/files/dwarfsrcfiles.c| 111 +
3 files changed, 156 insertions(+), 6 deletions(-)
create mode 100644 meta/recipes-devtools/dwarfsrcfiles/dwarfsrcfiles.bb
create mode 100644 meta/recipes-devtools/dwarfsrcfiles/files/dwarfsrcfiles.c
diff --git a/meta/classes/package.bbclass b/meta/classes/package.bbclass
index a03c05b..69c470c 100644
--- a/meta/classes/package.bbclass
+++ b/meta/classes/package.bbclass
@@ -52,7 +52,8 @@ LOCALE_SECTION ?= ''
ALL_MULTILIB_PACKAGE_ARCHS = "${@all_multilib_tune_values(d, 'PACKAGE_ARCHS')}"
# rpm is used for the per-file dependency identification
-PACKAGE_DEPENDS += "rpm-native"
+# dwarfsrcfiles is used to determine the list of debug source files
+PACKAGE_DEPENDS += "rpm-native dwarfsrcfiles-native"
# If your postinstall can execute at rootfs creation time rather than on
@@ -334,6 +335,16 @@ def checkbuildpath(file, d):
return False
+def parse_debugsources_from_dwarfsrcfiles_output(dwarfsrcfiles_output):
+debugfiles = {}
+
+for line in dwarfsrcfiles_output.splitlines():
+if line.startswith("\t"):
+debugfiles[os.path.normpath(line.split()[0])] = ""
+
+return debugfiles.keys()
+
+
def splitdebuginfo(file, debugfile, debugsrcdir, sourcefile, d):
# Function to split a single file into two components, one is the stripped
# target system binary, the other contains any debugging information. The
@@ -345,7 +356,6 @@ def splitdebuginfo(file, debugfile, debugsrcdir,
sourcefile, d):
dvar = d.getVar('PKGD')
objcopy = d.getVar("OBJCOPY")
-debugedit = d.expand("${STAGING_LIBDIR_NATIVE}/rpm/debugedit")
# We ignore kernel modules, we don't generate debug info files.
if file.find("/lib/modules/") != -1 and file.endswith(".ko"):
@@ -359,10 +369,18 @@ def splitdebuginfo(file, debugfile, debugsrcdir,
sourcefile, d):
# We need to extract the debug src information here...
if debugsrcdir:
-cmd = "'%s' -i -l '%s' '%s'" % (debugedit, sourcefile, file)
+cmd = "'dwarfsrcfiles' '%s'" % (file)
(retval, output) = oe.utils.getstatusoutput(cmd)
-if retval:
-bb.fatal("debugedit failed with exit code %s (cmd was %s)%s" %
(retval, cmd, ":\n%s" % output if output else ""))
+# 255 means a specific file wasn't fully parsed to get the debug file
list, which is not a fatal failure
+if retval != 0 and retval != 255:
+bb.fatal("dwarfsrcfiles failed with exit code %s (cmd was %s)%s" %
(retval, cmd, ":\n%s" % output if output else ""))
+
+debugsources = parse_debugsources_from_dwarfsrcfiles_output(output)
+# filenames are null-separated - this is an artefact of the previous
use
+# of rpm's debugedit, which was writing them out that way, and the
code elsewhere
+# is still assuming that.
+debuglistoutput = '\0'.join(debugsources) + '\0'
+open(sourcefile, 'a').write(debuglistoutput)
bb.utils.mkdirhier(os.path.dirname(debugfile))
@@ -393,7 +411,6 @@ def copydebugsources(debugsrcdir, d):
dvar = d.getVar('PKGD')
strip = d.getVar("STRIP")
objcopy = d.getVar("OBJCOPY")
-debugedit = d.expand("${STAGING_LIBDIR_NATIVE}/rpm/bin/debugedit")
workdir = d.getVar("WORKDIR")
workparentdir = os.path.dirname(os.path.dirname(workdir))
workbasedir = os.path.basename(os.path.dirname(workdir)) + "/" +
os.path.basename(workdir)
diff --git a/meta/recipes-devtools/dwarfsrcfiles/dwarfsrcfiles.bb
b/meta/recipes-devtools/dwarfsrcfiles/dwarfsrcfiles.bb
new file mode 100644
index 000..c59a006
--- /dev/null
+++ b/meta/recipes-devtools/dwarfsrcfiles/dwarfsrcfiles.bb
@@ -0,0 +1,22 @@
+SUMMARY = "A small utility for printing debig source file locations embedded
in binaries"
+LICENSE = "GPLv2+"
+LIC_FILES_CHKSUM =
"file://../dwarfsrcfiles.c;md5=31483894e453a77acbb67847565f1b5c;beginline=1;endline=8"
+
+SRC_URI = "file://dwarfsrcfiles.c"
+BBCLASSEXTEND = "native"
+DEPENDS = "elfutils"
+DEPENDS_append_libc-musl = " argp-standalone"
+
+do_compile () {
+ ${CC} ${CFLAGS} ${LDFLAGS} -o dwarfsrcfiles ../dwarfsrcfiles.c -lelf
-ldw
+}
+
+do_compile_libc-musl () {
+ ${CC} ${CF
[OE-core] [rocko 1/1] package.bbclass: replace rpm/debugedit with dwarfsrcfiles
From: Alexander Kanavin
Debugedit provided by rpm 4.14 is rewriting binaries in-place, and was
found to produce broken output at least for grub:
http://lists.openembedded.org/pipermail/openembedded-core/2017-November/143989.html
A replacement utility was suggested via private mail:
https://lists.fedorahosted.org/archives/list/elfutils-de...@lists.fedorahosted.org/message/VZP4G5N2ELYZEDAB3QYLXYHDGX4WMCUF/
(From OE-Core rev: f2e6e1d3bfd4c92ef0f5ed4721fd9050c59dafca)
Signed-off-by: Alexander Kanavin
Signed-off-by: Richard Purdie
(cherry picked from commit 0d5475a3b28d9e2c9273967a03726bb6c427bd11)
---
meta/classes/package.bbclass | 29 --
.../dwarfsrcfiles/dwarfsrcfiles.bb | 22
.../dwarfsrcfiles/files/dwarfsrcfiles.c| 111 +
3 files changed, 156 insertions(+), 6 deletions(-)
create mode 100644 meta/recipes-devtools/dwarfsrcfiles/dwarfsrcfiles.bb
create mode 100644 meta/recipes-devtools/dwarfsrcfiles/files/dwarfsrcfiles.c
diff --git a/meta/classes/package.bbclass b/meta/classes/package.bbclass
index 2053d46..7dc7596 100644
--- a/meta/classes/package.bbclass
+++ b/meta/classes/package.bbclass
@@ -52,7 +52,8 @@ LOCALE_SECTION ?= ''
ALL_MULTILIB_PACKAGE_ARCHS = "${@all_multilib_tune_values(d, 'PACKAGE_ARCHS')}"
# rpm is used for the per-file dependency identification
-PACKAGE_DEPENDS += "rpm-native"
+# dwarfsrcfiles is used to determine the list of debug source files
+PACKAGE_DEPENDS += "rpm-native dwarfsrcfiles-native"
# If your postinstall can execute at rootfs creation time rather than on
@@ -334,6 +335,16 @@ def checkbuildpath(file, d):
return False
+def parse_debugsources_from_dwarfsrcfiles_output(dwarfsrcfiles_output):
+debugfiles = {}
+
+for line in dwarfsrcfiles_output.splitlines():
+if line.startswith("\t"):
+debugfiles[os.path.normpath(line.split()[0])] = ""
+
+return debugfiles.keys()
+
+
def splitdebuginfo(file, debugfile, debugsrcdir, sourcefile, d):
# Function to split a single file into two components, one is the stripped
# target system binary, the other contains any debugging information. The
@@ -345,7 +356,6 @@ def splitdebuginfo(file, debugfile, debugsrcdir,
sourcefile, d):
dvar = d.getVar('PKGD')
objcopy = d.getVar("OBJCOPY")
-debugedit = d.expand("${STAGING_LIBDIR_NATIVE}/rpm/debugedit")
# We ignore kernel modules, we don't generate debug info files.
if file.find("/lib/modules/") != -1 and file.endswith(".ko"):
@@ -359,10 +369,18 @@ def splitdebuginfo(file, debugfile, debugsrcdir,
sourcefile, d):
# We need to extract the debug src information here...
if debugsrcdir:
-cmd = "'%s' -i -l '%s' '%s'" % (debugedit, sourcefile, file)
+cmd = "'dwarfsrcfiles' '%s'" % (file)
(retval, output) = oe.utils.getstatusoutput(cmd)
-if retval:
-bb.fatal("debugedit failed with exit code %s (cmd was %s)%s" %
(retval, cmd, ":\n%s" % output if output else ""))
+# 255 means a specific file wasn't fully parsed to get the debug file
list, which is not a fatal failure
+if retval != 0 and retval != 255:
+bb.fatal("dwarfsrcfiles failed with exit code %s (cmd was %s)%s" %
(retval, cmd, ":\n%s" % output if output else ""))
+
+debugsources = parse_debugsources_from_dwarfsrcfiles_output(output)
+# filenames are null-separated - this is an artefact of the previous
use
+# of rpm's debugedit, which was writing them out that way, and the
code elsewhere
+# is still assuming that.
+debuglistoutput = '\0'.join(debugsources) + '\0'
+open(sourcefile, 'a').write(debuglistoutput)
bb.utils.mkdirhier(os.path.dirname(debugfile))
@@ -393,7 +411,6 @@ def copydebugsources(debugsrcdir, d):
dvar = d.getVar('PKGD')
strip = d.getVar("STRIP")
objcopy = d.getVar("OBJCOPY")
-debugedit = d.expand("${STAGING_LIBDIR_NATIVE}/rpm/bin/debugedit")
workdir = d.getVar("WORKDIR")
workparentdir = os.path.dirname(os.path.dirname(workdir))
workbasedir = os.path.basename(os.path.dirname(workdir)) + "/" +
os.path.basename(workdir)
diff --git a/meta/recipes-devtools/dwarfsrcfiles/dwarfsrcfiles.bb
b/meta/recipes-devtools/dwarfsrcfiles/dwarfsrcfiles.bb
new file mode 100644
index 000..c59a006
--- /dev/null
+++ b/meta/recipes-devtools/dwarfsrcfiles/dwarfsrcfiles.bb
@@ -0,0 +1,22 @@
+SUMMARY = "A small utility for printing debig source file locations embedded
in binaries"
+LICENSE = "GPLv2+"
+LIC_FILES_CHKSUM =
"file://../dwarfsrcfiles.c;md5=31483894e453a77acbb67847565f1b5c;beginline=1;endline=8"
+
+SRC_URI = "file://dwarfsrcfiles.c"
+BBCLASSEXTEND = "native"
+DEPENDS = "elfutils"
+DEPENDS_append_libc-musl = " argp-standalone"
+
+do_compile () {
+ ${CC} ${CFLAGS} ${LDFLAGS} -o dwarfsrcfiles ../dwarfsrcfiles.c -lelf
-ldw
+}
+
+do_compile_libc-musl () {
+ ${CC} ${CF
[OE-core] [rocko 0/1] Backport debugedit fixes for Rocko
This is for 2.4.3 The following changes since commit fdeecc901196bbccd7c5b1ea4268a2cf56764a62: libvorbis: CVE-2018-5146 (2018-04-02 17:06:40 +0100) are available in the git repository at: git://git.yoctoproject.org/poky-contrib abrindle/rocko_backport http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=abrindle/rocko_backport Alexander Kanavin (1): package.bbclass: replace rpm/debugedit with dwarfsrcfiles meta/classes/package.bbclass | 29 -- .../dwarfsrcfiles/dwarfsrcfiles.bb | 22 .../dwarfsrcfiles/files/dwarfsrcfiles.c| 111 + 3 files changed, 156 insertions(+), 6 deletions(-) create mode 100644 meta/recipes-devtools/dwarfsrcfiles/dwarfsrcfiles.bb create mode 100644 meta/recipes-devtools/dwarfsrcfiles/files/dwarfsrcfiles.c -- 2.7.4 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 00/38] Morty Next pull request
On Thu, Apr 5, 2018 at 6:53 AM, Armin Kuster wrote: > Please consider these changes for Morty. Clean AB build > > This included sdk locale and host glibc 2.27 fixes. > > The following changes since commit 34b26ec18450a3bc72f7b8a0f2df0bfaae1140dd: > > linux-firmware: Add reference to iwlwifi-8000C firmware (2018-03-19 > 15:58:33 +) > > are available in the git repository at: > > git://git.yoctoproject.org/poky-contrib stable/morty-next > http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=stable/morty-next > > Richard Purdie (4): > lib/oe/package_manager/sdk: Ensure do_populate_sdk_ext and > do_populate_sdk repos don't conflict > glibc: Separate locale files to their own sstate task This commit comes with the comment: Putting the locale and script files into the sysroot for use by their specific recipes used to be a simple way to share the files. With RSS, we don't want to copy these into many different recipes so put these files in their own sstate task. Is it safe to backport to morty, which doesn't have RSS? > image/packagegroup/populate_sdk: Drop do_populate_sysroot task > properly > glibc-package: Avoid race sstate races with do_stash_locale -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] hello-mod_0.1.bb: add RPROVIDES
Although the package will get an automatic prefix "kernel-module", so
the package kernel-module-hello does exist, populating rootfs can
generate an error:
- nothing provides kernel-module-hello ...
This is quite unfortunate, as this recipe is used as a sample.
Adding RPROVIDES_${PN} += "kernel-module-hello" to the recipe fixes
the problem.
[YOCTO #12641]
Signed-off-by: Juro Bystricky
---
meta-skeleton/recipes-kernel/hello-mod/hello-mod_0.1.bb | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta-skeleton/recipes-kernel/hello-mod/hello-mod_0.1.bb
b/meta-skeleton/recipes-kernel/hello-mod/hello-mod_0.1.bb
index b140b0a..3d33446 100644
--- a/meta-skeleton/recipes-kernel/hello-mod/hello-mod_0.1.bb
+++ b/meta-skeleton/recipes-kernel/hello-mod/hello-mod_0.1.bb
@@ -13,3 +13,5 @@ S = "${WORKDIR}"
# The inherit of module.bbclass will automatically name module packages with
# "kernel-module-" prefix as required by the oe-core build environment.
+
+RPROVIDES_${PN} += "kernel-module-hello"
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] oe-selftest: qemutest: add tests for qemu boot and shutdown
Noted, let me rework on this. Thank you for your feedback! -Original Message- From: Alexander Kanavin [mailto:alexander.kana...@linux.intel.com] Sent: Thursday, April 5, 2018 5:56 PM To: Yeoh, Ee Peng ; openembedded-core@lists.openembedded.org Cc: Eggleton, Paul Subject: Re: [OE-core] [PATCH] oe-selftest: qemutest: add tests for qemu boot and shutdown On 04/05/2018 11:09 AM, Yeoh, Ee Peng wrote: > I had developed this selftest testcase to test qemu can boot nfs & > ext4 and finally shutdown for various qemu architecture. > > Initially, I was thinking to develop this automated test as part of > testimage but as this test involve shutting down qemu, testimage > testcases executed after this will face lost connection to qemu. > Furthermore, when I tried to add this test to selftest runqemu.py, I > realized runqemu was dedicated for MACHINE=qemux86-64 and it was > testing various live image (iso and hddimg) but live image was not > supported by other qemu architecture. Therefore, this test was > developed as independent selftest testcase. > > Please let me know your inputs and feedback. It's totally okay to have several test classes in a single .py file (see for example signing.py). I think this should go to runqemu.py, as otherwise there would be two different files doing roughly same thing and named very similarly (runqemu and qemutest?), which is confusing. You can add comments to both classes to explain what they do and why, and how they are different. (generally, be generous with comments every time there is possibility for confusion, or the code does unusual things etc.) Alex -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] atk: make sure that introspection is enabled
Fix the meson flags to make sure that introspection files are built
when it is enabled.
Signed-off-by: Anuj Mittal
---
...ld-enable-introspection-for-cross-compile.patch | 28 ++
meta/recipes-support/atk/atk_2.28.1.bb | 3 +++
2 files changed, 31 insertions(+)
create mode 100644
meta/recipes-support/atk/atk/0001-meson.build-enable-introspection-for-cross-compile.patch
diff --git
a/meta/recipes-support/atk/atk/0001-meson.build-enable-introspection-for-cross-compile.patch
b/meta/recipes-support/atk/atk/0001-meson.build-enable-introspection-for-cross-compile.patch
new file mode 100644
index 000..c604a98
--- /dev/null
+++
b/meta/recipes-support/atk/atk/0001-meson.build-enable-introspection-for-cross-compile.patch
@@ -0,0 +1,28 @@
+From 3838757d29590cc1ef99c97f7268377322fc17e9 Mon Sep 17 00:00:00 2001
+From: Anuj Mittal
+Date: Fri, 6 Apr 2018 12:04:00 +0800
+Subject: [PATCH] meson.build: enable introspection for cross-compile
+
+It works fine in OE-core and doesn't need to be disabled. Let the user decide
+if it should be disabled or not.
+
+Upstream-Status: Pending
+
+Signed-off-by: Anuj Mittal
+---
+ atk/meson.build | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/atk/meson.build b/atk/meson.build
+index 7b5a683..855e28f 100644
+--- a/atk/meson.build
b/atk/meson.build
+@@ -139,7 +139,7 @@ libatk_dep = declare_dependency(link_with: libatk,
+
+ disable_introspection = get_option('disable_introspection')
+
+-if not meson.is_cross_build() and not disable_introspection
++if not disable_introspection
+ gnome.generate_gir(libatk,
+ sources: atk_sources + atk_headers + [ atk_enum_h ] + [
atk_version_h ],
+ namespace: 'Atk',
diff --git a/meta/recipes-support/atk/atk_2.28.1.bb
b/meta/recipes-support/atk/atk_2.28.1.bb
index bb47916..8107df9 100644
--- a/meta/recipes-support/atk/atk_2.28.1.bb
+++ b/meta/recipes-support/atk/atk_2.28.1.bb
@@ -13,6 +13,9 @@ DEPENDS = "glib-2.0"
GNOMEBASEBUILDCLASS = "meson"
inherit gnomebase gtk-doc gettext upstream-version-is-even
gobject-introspection
+SRC_URI_append = " \
+
file://0001-meson.build-enable-introspection-for-cross-compile.patch \
+ "
SRC_URI[archive.md5sum] = "dfb5e7474220afa3f4ca7e45af9f3a11"
SRC_URI[archive.sha256sum] =
"cd3a1ea6ecc268a2497f0cd018e970860de24a6d42086919d6bf6c8e8d53f4fc"
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] ✗ patchtest: failure for atk: make sure that introspection is enabled
== Series Details == Series: atk: make sure that introspection is enabled Revision: 1 URL : https://patchwork.openembedded.org/series/11694/ State : failure == Summary == Thank you for submitting this patch series to OpenEmbedded Core. This is an automated response. Several tests have been executed on the proposed series by patchtest resulting in the following failures: * Issue Series does not apply on top of target branch [test_series_merge_on_head] Suggested fixRebase your series on top of targeted branch Targeted branch master (currently at dc52f9cf34) If you believe any of these test results are incorrect, please reply to the mailing list (openembedded-core@lists.openembedded.org) raising your concerns. Otherwise we would appreciate you correcting the issues and submitting a new version of the patchset if applicable. Please ensure you add/increment the version number when sending the new version (i.e. [PATCH] -> [PATCH v2] -> [PATCH v3] -> ...). --- Guidelines: https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
