[OE-core] [PATCH] python3-misc: add python3-audio to RDEPENDS
Import issues are encountered for the python3 aifc module,
on images with python3-misc installed:
|>>> import aifc
|Traceback (most recent call last):
|File "", line 1, in
|File "/usr/lib64/python3.7/aifc.py", line 254, in
|from chunk import Chunk
|ModuleNotFoundError: No module named 'chunk'
|>>>
The chunk module is part of python3-audio. Add python3-audio
to RDEPENDS for python3-misc to fix the error.
Signed-off-by: Trevor Gamblin
---
meta/recipes-devtools/python/python3_3.7.5.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-devtools/python/python3_3.7.5.bb
b/meta/recipes-devtools/python/python3_3.7.5.bb
index 0338fa4ba8..90914f9053 100644
--- a/meta/recipes-devtools/python/python3_3.7.5.bb
+++ b/meta/recipes-devtools/python/python3_3.7.5.bb
@@ -324,7 +324,7 @@ INSANE_SKIP_${PN}-dev += "dev-elf"
# catch all the rest (unsorted)
PACKAGES += "${PN}-misc"
-RDEPENDS_${PN}-misc += "python3-core python3-email python3-codecs
python3-pydoc python3-pickle"
+RDEPENDS_${PN}-misc += "python3-core python3-email python3-codecs
python3-pydoc python3-pickle python3-audio"
RDEPENDS_${PN}-modules_append_class-target = " python3-misc"
RDEPENDS_${PN}-modules_append_class-nativesdk = " python3-misc"
FILES_${PN}-misc = "${libdir}/python${PYTHON_MAJMIN}
${libdir}/python${PYTHON_MAJMIN}/lib-dynload"
--
2.23.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/2] tune-riscv: Add support for hard and soft float
On Fri, Nov 8, 2019 at 3:07 PM Richard Purdie wrote: > > On Fri, 2019-11-08 at 22:24 +0200, Adrian Bunk wrote: > > Especially when looking at the arm64 situation I am wondering > > whether the best option might be to throw away the tunes mess and let > > the user write the compiler options directly. > > OE once did that. I think anyone who lived through it would say that > the current situation *is* an improvement over a free-for-all. > > This is mainly as at least we're now consistent whereas before the same > thing had different names in each BSP. > > I don't know what the answer is but I don't want to go back to that! Ha ok. I won't argue with that. I can just carry the patch locally, so I'm not in a rush to get this in. I have reached out to Rich (musl maintainer) to see if he has any ideas. Alistair > > Cheers, > > Richard > > > -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/2] tune-riscv: Add support for hard and soft float
On Fri, 2019-11-08 at 22:24 +0200, Adrian Bunk wrote: > Especially when looking at the arm64 situation I am wondering > whether the best option might be to throw away the tunes mess and let > the user write the compiler options directly. OE once did that. I think anyone who lived through it would say that the current situation *is* an improvement over a free-for-all. This is mainly as at least we're now consistent whereas before the same thing had different names in each BSP. I don't know what the answer is but I don't want to go back to that! Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v6] mesa: Upgrade to 19.2.1
On Fri, Nov 8, 2019 at 10:13 AM Khem Raj wrote: > > On Fri, Nov 8, 2019 at 2:32 AM Ross Burton wrote: > > > > On 04/11/2019 22:48, Alistair Francis wrote: > > > From: Alistair Francis > > > > > > Upgrade mesa and mesa-gl to 19.2.1. > > > > > > The license hash change was a trivial new line removal. > > > > > > The glx-tls option was removed as it isn't included in the meson.build > > > file. It has been replaced with 'use-elf-tls' instead. > > > > I think this has regressed something, this is a new warning on musl builds: > > > > do_package_qa: QA Issue: ELF binary > > '[...]libgles2-mesa/usr/lib/libGLESv2.so.2.0.0' has relocations in .text > > [textrel] > > > > (ditto for libGLESv1_CM.so.1.1.0 libGL.so.1.2.0 libglapi.so.0.0.0) > > > > right this means glx-tls is not working anymore, and it will fail on > musl at runtime > see > https://gitlab.freedesktop.org/mesa/mesa/issues/966 So what do we do here? There are some patches in that issue, but they don't cleanly apply and seem hacky anyway. Can we have two versions of mesa? One for musl and one for others until this is fixed upstream? Alistair > > > Ross > > -- > > ___ > > 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 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2] dhcp: Workaround busybox limitation in Linux dhclient-script
Busybox's implementation of chown and chmod doesn't provide a
"--reference" option used in the latest version of dhclient-script.
This change works around that limitation by using stat to read
ownership and permissions flags and simple chown/chmod calls
supported in both coreutils and busybox.
Patch submitted upstream to ISC, tracked as bug 48771.
Signed-off-by: Haris Okanovic
---
...-limitation-in-linux-dhclient-script.patch | 65 +++
meta/recipes-connectivity/dhcp/dhcp_4.4.1.bb | 1 +
2 files changed, 66 insertions(+)
create mode 100644
meta/recipes-connectivity/dhcp/dhcp/0001-workaround-busybox-limitation-in-linux-dhclient-script.patch
diff --git
a/meta/recipes-connectivity/dhcp/dhcp/0001-workaround-busybox-limitation-in-linux-dhclient-script.patch
b/meta/recipes-connectivity/dhcp/dhcp/0001-workaround-busybox-limitation-in-linux-dhclient-script.patch
new file mode 100644
index 00..2359381b93
--- /dev/null
+++
b/meta/recipes-connectivity/dhcp/dhcp/0001-workaround-busybox-limitation-in-linux-dhclient-script.patch
@@ -0,0 +1,65 @@
+From eec0503cfc36f63d777f5cb3f2719cecedcb8468 Mon Sep 17 00:00:00 2001
+From: Haris Okanovic
+Date: Mon, 7 Jan 2019 13:22:09 -0600
+Subject: [PATCH] Workaround busybox limitation in Linux dhclient-script
+
+Busybox is a lightweight implementation of coreutils commonly used on
+space-constrained embedded Linux distributions. It's implementation of
+chown and chmod doesn't provide a "--reference" option added to
+client/scripts/linux as of commit 9261cb14. This change works around
+that limitation by using stat to read ownership and permissions flags
+and simple chown/chmod calls supported in both coreutils and busybox.
+
+modified: client/scripts/linux
+
+Signed-off-by: Haris Okanovic
+Upstream-Status: Pending [ISC-Bugs #48771]
+---
+ client/scripts/linux | 17 +
+ 1 file changed, 13 insertions(+), 4 deletions(-)
+
+diff --git a/client/scripts/linux b/client/scripts/linux
+index 0c429697..2435a44b 100755
+--- a/client/scripts/linux
b/client/scripts/linux
+@@ -32,6 +32,17 @@
+ # if your system holds ip tool in a non-standard location.
+ ip=/sbin/ip
+
++chown_chmod_by_reference() {
++local reference_file="$1"
++local target_file="$2"
++
++local owner=$(stat -c "%u:%g" "$reference_file")
++local perm=$(stat -c "%a" "$reference_file")
++
++chown "$owner" "$target_file"
++chmod "$perm" "$target_file"
++}
++
+ # update /etc/resolv.conf based on received values
+ # This updated version mostly follows Debian script by Andrew Pollock et al.
+ make_resolv_conf() {
+@@ -74,8 +85,7 @@ make_resolv_conf() {
+ fi
+
+ if [ -f /etc/resolv.conf ]; then
+- chown --reference=/etc/resolv.conf $new_resolv_conf
+- chmod --reference=/etc/resolv.conf $new_resolv_conf
++ chown_chmod_by_reference /etc/resolv.conf $new_resolv_conf
+ fi
+ mv -f $new_resolv_conf /etc/resolv.conf
+ # DHCPv6
+@@ -101,8 +111,7 @@ make_resolv_conf() {
+ fi
+
+ if [ -f /etc/resolv.conf ]; then
+-chown --reference=/etc/resolv.conf $new_resolv_conf
+-chmod --reference=/etc/resolv.conf $new_resolv_conf
++ chown_chmod_by_reference /etc/resolv.conf $new_resolv_conf
+ fi
+ mv -f $new_resolv_conf /etc/resolv.conf
+ fi
+--
+2.20.0
+
diff --git a/meta/recipes-connectivity/dhcp/dhcp_4.4.1.bb
b/meta/recipes-connectivity/dhcp/dhcp_4.4.1.bb
index 275961a603..020777b8f2 100644
--- a/meta/recipes-connectivity/dhcp/dhcp_4.4.1.bb
+++ b/meta/recipes-connectivity/dhcp/dhcp_4.4.1.bb
@@ -11,6 +11,7 @@ SRC_URI +=
"file://0001-define-macro-_PATH_DHCPD_CONF-and-_PATH_DHCLIENT_CON.pat
file://0013-fixup_use_libbind.patch \
file://0001-master-Added-includes-of-new-BIND9-compatibility-hea.patch \
file://0001-Fix-a-NSUPDATE-compiling-issue.patch \
+
file://0001-workaround-busybox-limitation-in-linux-dhclient-script.patch \
"
SRC_URI[md5sum] = "18c7f4dcbb0a63df25098216d47b1ede"
--
2.24.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2] buildhistory: fix "version went backwards" QA error message
From: Denys Dmytriyenko
Fix parentheses placement in the message from:
Package version for package X went backwards which would break package feeds
from (Y to Z)
to this one:
Package version for package X went backwards which would break package feeds
(from Y to Z)
Signed-off-by: Denys Dmytriyenko
---
v2 - escape parentheses in the regular expression of the selftest case, as
those are part of the text and not regex itself, otherwise it won't match.
meta/classes/buildhistory.bbclass| 2 +-
meta/lib/oeqa/selftest/cases/buildoptions.py | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/classes/buildhistory.bbclass
b/meta/classes/buildhistory.bbclass
index f986f7c..affdf27 100644
--- a/meta/classes/buildhistory.bbclass
+++ b/meta/classes/buildhistory.bbclass
@@ -280,7 +280,7 @@ python buildhistory_emit_pkghistory() {
last_pkgr = lastversion.pkgr
r = bb.utils.vercmp((pkge, pkgv, pkgr), (last_pkge, last_pkgv,
last_pkgr))
if r < 0:
-msg = "Package version for package %s went backwards which
would break package feeds from (%s:%s-%s to %s:%s-%s)" % (pkg, last_pkge,
last_pkgv, last_pkgr, pkge, pkgv, pkgr)
+msg = "Package version for package %s went backwards which
would break package feeds (from %s:%s-%s to %s:%s-%s)" % (pkg, last_pkge,
last_pkgv, last_pkgr, pkge, pkgv, pkgr)
package_qa_handle_error("version-going-backwards", msg, d)
pkginfo = PackageInfo(pkg)
diff --git a/meta/lib/oeqa/selftest/cases/buildoptions.py
b/meta/lib/oeqa/selftest/cases/buildoptions.py
index 6a5378d..e91f0bd 100644
--- a/meta/lib/oeqa/selftest/cases/buildoptions.py
+++ b/meta/lib/oeqa/selftest/cases/buildoptions.py
@@ -143,7 +143,7 @@ class BuildhistoryTests(BuildhistoryBase):
def test_buildhistory_buildtime_pr_backwards(self):
target = 'xcursor-transparent-theme'
-error = "ERROR:.*QA Issue: Package version for package %s went
backwards which would break package feeds from (.*-r1.* to .*-r0.*)" % target
+error = "ERROR:.*QA Issue: Package version for package %s went
backwards which would break package feeds \(from .*-r1.* to .*-r0.*\)" % target
self.run_buildhistory_operation(target, target_config="PR = \"r1\"",
change_bh_location=True)
self.run_buildhistory_operation(target, target_config="PR = \"r0\"",
change_bh_location=False, expect_error=True, error_regex=error)
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] How to enable x11 with intel-corei7-64 machine in meta-intel layer
Hello,
I've been trying to figure out how to get x11 enabled with my intel-corei7-64
machine.
If I have in my local.conf file MACHINE set to intel-corei7-64 and I run
"bitbake core-image-x11", bitbake fails. The error message I get in the
.../tmp-glibc/work/corei7-64-oe-linux/xf86-video-intel/2_2.99.917+gitAUTOINC+e4fe79cf0d-r0/build/config.log
file is as follows:
=== Start config.log excerpt ===
configure:22309: checking whether to include XvMC support
configure:22311: result: yes
configure:22345: checking which acceleration method to use by default
configure:22356: error: No default acceleration option
=== End config.log excerpt ===
I've tried different things I've found doing Google searches. None of them
have worked.
This is a bare bone setup. I am using the thud branch. My bblayers.conf file
is as follows:
=== Start bblayers.conf ===
# LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf
# changes incompatibly
LCONF_VERSION = "7"
BBPATH = "${TOPDIR}"
BBFILES ?= ""
BBLAYERS ?= " \
${HOME}/oe-core/meta \
${HOME}/meta-openembedded/meta-python \
${HOME}/meta-openembedded/meta-gnome \
${HOME}/meta-openembedded/meta-filesystems \
${HOME}/meta-openembedded/meta-oe \
${HOME}/meta-openembedded/meta-networking \
${HOME}/meta-openembedded/meta-initramfs \
${HOME}/meta-openembedded/meta-webserver \
${HOME}/meta-intel \
${HOME}/meta-virtualization \
${HOME}/meta-cloud-services \
${HOME}/meta-cloud-services/meta-openstack \
${HOME}/meta-iot-cloud \
${HOME}/meta-secure-core/meta-tpm \
"
=== End bblayers.conf ===
The only change I made to the local.conf file was to set MACHINE to
intel-corei7-64.
I then ran "bitbake core-image-x11" and get the error.
I'm guessing I need to add something more to my local.conf, but all of the
different things I've tried have failed.
Any and all help would be appreciated.
Thank you
Lewis Muhlenkamp
Follow this link to read our Privacy
Statement
Re: [OE-core] [PATCH 1/2] tune-riscv: Add support for hard and soft float
On Thu, Nov 07, 2019 at 04:39:22PM -0800, Alistair Francis wrote:
> On Wed, Nov 6, 2019 at 11:33 PM Nathan Rossi wrote:
> >
> > On Thu, 7 Nov 2019 at 09:34, Adrian Bunk wrote:
> > >
> > > On Wed, Nov 06, 2019 at 10:18:18AM -0800, Alistair Francis wrote:
> > > >...
> > > > +TUNE_CCARGS_riscv64 .= "${@bb.utils.contains('TUNE_FEATURES',
> > > > 'riscv64-f', ' -mabi=lp64d', ' -mabi=lp64', d)}"
> > > > +TUNE_CCARGS_riscv32 .= "${@bb.utils.contains('TUNE_FEATURES',
> > > > 'riscv32-f', ' -mabi=ilp32f', ' -mabi=ilp32', d)}"
> > > >...
> > >
> > > That looks wrong, what would you put in TUNE_FEATURES
> > > for -mabi=lp64f when -mabi=lp64d is called riscv64-f?
> > >
> > > Also note that this is only the floating point calling convention,
> > > whether the compiler emits floating point instructions is defined
> > > by -march.
> > >
> > > It would be good if this would start with a plan how to handle
> > > all possible combination of RISC-V ISA extensions, ideally better
> > > than the arm mess.
> >
> > I am keen to see this as well, since I am currently directly
> > hardcoding -march/-mabi in the machine conf.
> >
> > It would be nice to see the ISA tunes available in oe-core, even if
> > that is just the tune features and not predefined tunes (e.g. like
> > microblaze).
>
> I think this idea as well. Some generic way of generating tunes from
> ISA stings would be great!
>
> Does anyone have any ideas on the best way to do this?
Especially when looking at the arm64 situation I am wondering whether
the best option might be to throw away the tunes mess and let the user
write the compiler options directly.
If OE needs information about a specific feature, it would be easier to
ask the compiler[1] than duplicating all the target knowledge.
> Alistair
cu
Adrian
[1] $CC -dM -E - < /dev/null
--
"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] oeqa: Fix subTest result reporting
Fixes the way that subTest results are reported so that each subTest is
reported independently, with it's own status. The base test case is also
reported, but only if it actually had a status.
Signed-off-by: Joshua Watt
---
meta/lib/oeqa/core/runner.py| 44 +
meta/lib/oeqa/core/utils/concurrencytest.py | 3 ++
2 files changed, 39 insertions(+), 8 deletions(-)
diff --git a/meta/lib/oeqa/core/runner.py b/meta/lib/oeqa/core/runner.py
index f656e1a9c5f..ee9db6f7951 100644
--- a/meta/lib/oeqa/core/runner.py
+++ b/meta/lib/oeqa/core/runner.py
@@ -40,6 +40,7 @@ class OETestResult(_TestResult):
super(OETestResult, self).__init__(*args, **kwargs)
self.successes = []
+self.subtests = {}
self.starttime = {}
self.endtime = {}
self.progressinfo = {}
@@ -145,6 +146,13 @@ class OETestResult(_TestResult):
else:
self.extraresults[k] = v
+def addSubTest(self, test, subtest, err, details=None):
+self.extractExtraResults(test, details=details)
+self.subtests.setdefault(test, list()).append(subtest)
+if err is None:
+self.successes.append((subtest, None))
+return super(OETestResult, self).addSubTest(test, subtest, err)
+
def addError(self, test, *args, details = None):
self.extractExtraResults(test, details = details)
return super(OETestResult, self).addError(test, *args)
@@ -169,18 +177,18 @@ class OETestResult(_TestResult):
def logDetails(self, json_file_dir=None, configuration=None,
result_id=None,
dump_streams=False):
-self.tc.logger.info("RESULTS:")
-
-result = self.extraresults
-logs = {}
-if hasattr(self.tc, "extraresults"):
-result.update(self.tc.extraresults)
-for case_name in self.tc._registry['cases']:
-case = self.tc._registry['cases'][case_name]
+def logCaseDetails(case, required):
+nonlocal self
+nonlocal result
+nonlocal dump_streams
+nonlocal logs
(status, log) = self._getTestResultDetails(case)
+if status == "UNKNOWN" and not required:
+return
+
t = ""
if case.id() in self.starttime and case.id() in self.endtime:
t = " (" + "{0:.2f}".format(self.endtime[case.id()] -
self.starttime[case.id()]) + "s)"
@@ -197,6 +205,26 @@ class OETestResult(_TestResult):
report['stderr'] = stderr
result[case.id()] = report
+self.tc.logger.info("RESULTS:")
+
+result = self.extraresults
+logs = {}
+if hasattr(self.tc, "extraresults"):
+result.update(self.tc.extraresults)
+
+for case_name in self.tc._registry['cases']:
+case = self.tc._registry['cases'][case_name]
+
+if case in self.subtests:
+for subtest in self.subtests[case]:
+logCaseDetails(subtest, True)
+
+# The base case may not have any reported details. If it comes
+# up as unknown, don't report anything.
+logCaseDetails(case, False)
+else:
+logCaseDetails(case, True)
+
for i in ['PASSED', 'SKIPPED', 'EXPECTEDFAIL', 'ERROR', 'FAILED',
'UNKNOWN']:
if i not in logs:
continue
diff --git a/meta/lib/oeqa/core/utils/concurrencytest.py
b/meta/lib/oeqa/core/utils/concurrencytest.py
index 0f7b3dcc113..ae68fd50902 100644
--- a/meta/lib/oeqa/core/utils/concurrencytest.py
+++ b/meta/lib/oeqa/core/utils/concurrencytest.py
@@ -81,6 +81,9 @@ class ProxyTestResult:
def _addResult(self, method, test, *args, exception = False, **kwargs):
return method(test, *args, **kwargs)
+def addSubTest(self, test, subtest, outcome, **kwargs):
+self._addResult(self.result.addSubTest, test, subtest, outcome,
exception = (outcome is not None), **kwargs)
+
def addError(self, test, err = None, **kwargs):
self._addResult(self.result.addError, test, err, exception = True,
**kwargs)
--
2.23.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/6] oe-selftest: extend virgl gtk test to also check the SDL option
On Fri, 8 Nov 2019 at 19:01, Michael Halstead wrote: > >> Thanks a lot! There are two things to check: >> 1. Old instances of vnc may still be running and should be shut down (via >> 'vncserver -kill :1') >> 2. vncserver executable should point to tigervnc (if both tigervnc and >> tightvnc are installed - I don't know if you removed the tightvnc packages). >> > > I removed tightvnc and all workers have been rebooted so we are good to go. > > Any comment on using packages from outside of the distro's official > packaging? > A vnc server is entirely optional when working with yocto, it's used on the autobuilder (machines without a physical screen) for the purpose of running qemu with graphical frontends, but is not mentioned in the manuals as something that users have to install or use. I'd say it's fine. Alex -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v6] mesa: Upgrade to 19.2.1
On Fri, Nov 8, 2019 at 2:32 AM Ross Burton wrote: > > On 04/11/2019 22:48, Alistair Francis wrote: > > From: Alistair Francis > > > > Upgrade mesa and mesa-gl to 19.2.1. > > > > The license hash change was a trivial new line removal. > > > > The glx-tls option was removed as it isn't included in the meson.build > > file. It has been replaced with 'use-elf-tls' instead. > > I think this has regressed something, this is a new warning on musl builds: > > do_package_qa: QA Issue: ELF binary > '[...]libgles2-mesa/usr/lib/libGLESv2.so.2.0.0' has relocations in .text > [textrel] > > (ditto for libGLESv1_CM.so.1.1.0 libGL.so.1.2.0 libglapi.so.0.0.0) > right this means glx-tls is not working anymore, and it will fail on musl at runtime see https://gitlab.freedesktop.org/mesa/mesa/issues/966 > Ross > -- > ___ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] ✗ patchtest: failure for oeqa: reproducible: Fix extra data reporting
== Series Details == Series: oeqa: reproducible: Fix extra data reporting Revision: 1 URL : https://patchwork.openembedded.org/series/21061/ 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 11694eb59b) If you believe any of these test results are incorrect, please reply to the mailing list (openembedded-core@lists.openembedded.org) raising your concerns. Otherwise we would appreciate you correcting the issues and submitting a new version of the patchset if applicable. Please ensure you add/increment the version number when sending the new version (i.e. [PATCH] -> [PATCH v2] -> [PATCH v3] -> ...). --- Guidelines: https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/6] oe-selftest: extend virgl gtk test to also check the SDL option
On Fri, Nov 8, 2019 at 9:56 AM Alexander Kanavin wrote: > On Fri, 8 Nov 2019 at 18:20, Michael Halstead < > mhalst...@linuxfoundation.org> wrote: > >> > If you replace that with tigervnc (a modern, supported fork of >> tightvnc), then the tests pass fine. >> > https://tigervnc.org/ >> > >> >> TigerVNC is now installed from the standard repos where available. >> >> > >> > As Fedora has already obsoleted tightvnc in favor of tigervnc, I think >> we should do the same on all debian machines (debian provides both tightvnc >> and tigervnc, but treats them as equal). >> > https://src.fedoraproject.org/rpms/tightvnc/blob/master/f/dead.package >> > I also checked that tightvnc is not available for opensuse either. >> >> >> Server components of TigerVNC are in xorg-x11-Xvnc package which is >> installed on all the openSUSE workers so I expect the VNC server there to >> work. Please let me know if they do not. >> >> >> On Ubuntu 16.04 and Debian 8 workers I've installed from >> https://bintray.com/tigervnc/stable/tigervnc/1.9.0. This should allow >> tests to complete. Installing packages outside of the distribution's >> package manager might invalidate these as sanity tested distros. I'd >> appreciate feedback about this. >> > > Thanks a lot! There are two things to check: > 1. Old instances of vnc may still be running and should be shut down (via > 'vncserver -kill :1') > 2. vncserver executable should point to tigervnc (if both tigervnc and > tightvnc are installed - I don't know if you removed the tightvnc packages). > I removed tightvnc and all workers have been rebooted so we are good to go. Any comment on using packages from outside of the distro's official packaging? > > Otherwise everything should be ready for re-testing the patches. I can > resend them if needed. > > Alex > -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/6] oe-selftest: extend virgl gtk test to also check the SDL option
On Fri, 8 Nov 2019 at 18:20, Michael Halstead wrote: > > If you replace that with tigervnc (a modern, supported fork of > tightvnc), then the tests pass fine. > > https://tigervnc.org/ > > > > TigerVNC is now installed from the standard repos where available. > > > > > As Fedora has already obsoleted tightvnc in favor of tigervnc, I think > we should do the same on all debian machines (debian provides both tightvnc > and tigervnc, but treats them as equal). > > https://src.fedoraproject.org/rpms/tightvnc/blob/master/f/dead.package > > I also checked that tightvnc is not available for opensuse either. > > > Server components of TigerVNC are in xorg-x11-Xvnc package which is > installed on all the openSUSE workers so I expect the VNC server there to > work. Please let me know if they do not. > > > On Ubuntu 16.04 and Debian 8 workers I've installed from > https://bintray.com/tigervnc/stable/tigervnc/1.9.0. This should allow > tests to complete. Installing packages outside of the distribution's > package manager might invalidate these as sanity tested distros. I'd > appreciate feedback about this. > Thanks a lot! There are two things to check: 1. Old instances of vnc may still be running and should be shut down (via 'vncserver -kill :1') 2. vncserver executable should point to tigervnc (if both tigervnc and tightvnc are installed - I don't know if you removed the tightvnc packages). Otherwise everything should be ready for re-testing the patches. I can resend them if needed. Alex -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] oeqa: reproducible: Fix extra data reporting
A typo was preventing the extra data about the reproducible build from
being reported in the test results
Signed-off-by: Joshua Watt
---
meta/lib/oeqa/selftest/cases/reproducible.py | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/meta/lib/oeqa/selftest/cases/reproducible.py
b/meta/lib/oeqa/selftest/cases/reproducible.py
index 0b3c02ab450..7e26eead5c3 100644
--- a/meta/lib/oeqa/selftest/cases/reproducible.py
+++ b/meta/lib/oeqa/selftest/cases/reproducible.py
@@ -89,12 +89,12 @@ class ReproducibleTests(OESelftestTestCase):
for v in needed_vars:
setattr(self, v.lower(), bb_vars[v])
-self.extrasresults = {}
-self.extrasresults.setdefault('reproducible.rawlogs', {})['log'] = ''
-self.extrasresults.setdefault('reproducible', {}).setdefault('files',
{})
+self.extraresults = {}
+self.extraresults.setdefault('reproducible.rawlogs', {})['log'] = ''
+self.extraresults.setdefault('reproducible', {}).setdefault('files',
{})
def append_to_log(self, msg):
-self.extrasresults['reproducible.rawlogs']['log'] += msg
+self.extraresults['reproducible.rawlogs']['log'] += msg
def compare_packages(self, reference_dir, test_dir, diffutils_sysroot):
result = PackageCompareResults()
@@ -121,7 +121,7 @@ class ReproducibleTests(OESelftestTestCase):
return result
def write_package_list(self, package_class, name, packages):
-self.extrasresults['reproducible']['files'].setdefault(package_class,
{})[name] = [
+self.extraresults['reproducible']['files'].setdefault(package_class,
{})[name] = [
{'reference': p.reference, 'test': p.test} for p in packages]
def do_test_build(self, name, use_sstate):
--
2.23.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/6] oe-selftest: extend virgl gtk test to also check the SDL option
On Mon, Nov 4, 2019 at 1:11 PM Alexander Kanavin wrote: > > On Sat, 2 Nov 2019 at 23:29, Alexander Kanavin wrote: >> >> Same failures on the Debian 10 worker: https://autobuilder.yoctoproject.org/typhoon/#/builders/56/builds/778 >>> >>> >>> runqemu - ERROR - Failed to run qemu: Xlib: extension "RANDR" missing on display ":1". >>> qemu-system-x86_64: ../libepoxy-1.5.3/src/dispatch_common.c:863: epoxy_get_proc_address: Assertion `0 && "Couldn't find current GLX or EGL context.\n"' failed. >>> >>> Thanks - the Gtk part is passing fine, so it's something SDL does that upsets the X/GL stack on the Debian 10 host. >>> I am reluctant to disable the SDL part of the virgl tests on Debian 10, as it is a new distro (unlike centos 7). >>> >>> I'll try to see if I can run Debian 10 in a VM here and try to reproduce. Or is it possible to debug directly on a Debian 10 worker? >> >> >> So I actually went ahead, and installed Debian 10 into a qemu image, then transferred a pre-populated build directory into it, and ran runqemu there against tigervnc (hurray for the nested kvm feature!). >> >> Both 'runqemu kvm sdl gl' and 'runqemu kvm gtk gl' work fine, including running kmscube! >> >> So I'd like to see what packages are installed on the Debian 10 worker vs. my Debian 10 installation. >> >> Can you issue 'dpkg -l' on the worker, and send me the output, please? Maybe something is missing? > > > After additional digging I reproduced this. The culprit is the outdated VNC server implementation that runs on the Debian 10 autobuilder (and maybe others as well). > > Specifically, it's tightvncserver, where all Linux development has ceased 10 years ago (!). > https://www.tightvnc.com/ > > If you replace that with tigervnc (a modern, supported fork of tightvnc), then the tests pass fine. > https://tigervnc.org/ > TigerVNC is now installed from the standard repos where available. > > As Fedora has already obsoleted tightvnc in favor of tigervnc, I think we should do the same on all debian machines (debian provides both tightvnc and tigervnc, but treats them as equal). > https://src.fedoraproject.org/rpms/tightvnc/blob/master/f/dead.package > I also checked that tightvnc is not available for opensuse either. Server components of TigerVNC are in xorg-x11-Xvnc package which is installed on all the openSUSE workers so I expect the VNC server there to work. Please let me know if they do not. On Ubuntu 16.04 and Debian 8 workers I've installed from https://bintray.com/tigervnc/stable/tigervnc/1.9.0. This should allow tests to complete. Installing packages outside of the distribution's package manager might invalidate these as sanity tested distros. I'd appreciate feedback about this. -- Michael Halstead Yocto Project / SysAdmin > > Alex -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v4 1/4] go: Refactor patches for 1.13.3
This looks good to me now.
On Fri, Oct 25, 2019 at 6:58 AM Alexander Kube
wrote:
>
> From: Alex Kube
>
> Signed-off-by: Alex Kube
> ---
> ...ow-CC-and-CXX-to-have-multiple-words.patch | 38 +++
> ...ent-based-hash-generation-less-pedan.patch | 226 ++
> ...-to-be-overridden-in-the-environment.patch | 54
> ...4-ld-add-soname-to-shareable-objects.patch | 50
> ...de-CC-when-building-dist-and-go_boot.patch | 44 +++
> ...dist-separate-host-and-target-builds.patch | 279 ++
> ...d-go-make-GOROOT-precious-by-default.patch | 113 +++
> ...008-use-GOBUILDMODE-to-set-buildmode.patch | 47 +++
> ...place-glibc-dynamic-linker-with-musl.patch | 134 +
> 9 files changed, 985 insertions(+)
> create mode 100644
> meta/recipes-devtools/go/go-1.13/0001-allow-CC-and-CXX-to-have-multiple-words.patch
> create mode 100644
> meta/recipes-devtools/go/go-1.13/0002-cmd-go-make-content-based-hash-generation-less-pedan.patch
> create mode 100644
> meta/recipes-devtools/go/go-1.13/0003-allow-GOTOOLDIR-to-be-overridden-in-the-environment.patch
> create mode 100644
> meta/recipes-devtools/go/go-1.13/0004-ld-add-soname-to-shareable-objects.patch
> create mode 100644
> meta/recipes-devtools/go/go-1.13/0005-make.bash-override-CC-when-building-dist-and-go_boot.patch
> create mode 100644
> meta/recipes-devtools/go/go-1.13/0006-cmd-dist-separate-host-and-target-builds.patch
> create mode 100644
> meta/recipes-devtools/go/go-1.13/0007-cmd-go-make-GOROOT-precious-by-default.patch
> create mode 100644
> meta/recipes-devtools/go/go-1.13/0008-use-GOBUILDMODE-to-set-buildmode.patch
> create mode 100644
> meta/recipes-devtools/go/go-1.13/0009-ld-replace-glibc-dynamic-linker-with-musl.patch
>
> diff --git
> a/meta/recipes-devtools/go/go-1.13/0001-allow-CC-and-CXX-to-have-multiple-words.patch
>
> b/meta/recipes-devtools/go/go-1.13/0001-allow-CC-and-CXX-to-have-multiple-words.patch
> new file mode 100644
> index 00..ddfd5e41d1
> --- /dev/null
> +++
> b/meta/recipes-devtools/go/go-1.13/0001-allow-CC-and-CXX-to-have-multiple-words.patch
> @@ -0,0 +1,38 @@
> +From 9e3dc44cdfa58d96504d0a789dc82617dd5bef55 Mon Sep 17 00:00:00 2001
> +From: Alex Kube
> +Date: Wed, 23 Oct 2019 21:01:13 +0430
> +Subject: [PATCH 1/9] cmd/go: Allow CC and CXX to have multiple words
> +
> +Upstream-Status: Inappropriate [OE specific]
> +
> +Adapted to Go 1.13 from patches originally submitted to
> +the meta/recipes-devtools/go tree by
> +Matt Madison .
> +
> +Signed-off-by: Alexander J Kube
> +
> +---
> + src/cmd/go/internal/envcmd/env.go | 4 ++--
> + 1 file changed, 2 insertions(+), 2 deletions(-)
> +
> +diff --git a/src/cmd/go/internal/envcmd/env.go
> b/src/cmd/go/internal/envcmd/env.go
> +index 17852de..7b5ec5e 100644
> +--- a/src/cmd/go/internal/envcmd/env.go
> b/src/cmd/go/internal/envcmd/env.go
> +@@ -100,11 +100,11 @@ func MkEnv() []cfg.EnvVar {
> +
> + cc := cfg.DefaultCC(cfg.Goos, cfg.Goarch)
> + if env := strings.Fields(cfg.Getenv("CC")); len(env) > 0 {
> +- cc = env[0]
> ++ cc = strings.Join(env, " ")
> + }
> + cxx := cfg.DefaultCXX(cfg.Goos, cfg.Goarch)
> + if env := strings.Fields(cfg.Getenv("CXX")); len(env) > 0 {
> +- cxx = env[0]
> ++ cxx = strings.Join(env, " ")
> + }
> + env = append(env, cfg.EnvVar{Name: "AR", Value: envOr("AR", "ar")})
> + env = append(env, cfg.EnvVar{Name: "CC", Value: cc})
> +--
> +2.17.1 (Apple Git-112)
> +
> diff --git
> a/meta/recipes-devtools/go/go-1.13/0002-cmd-go-make-content-based-hash-generation-less-pedan.patch
>
> b/meta/recipes-devtools/go/go-1.13/0002-cmd-go-make-content-based-hash-generation-less-pedan.patch
> new file mode 100644
> index 00..4eddd39809
> --- /dev/null
> +++
> b/meta/recipes-devtools/go/go-1.13/0002-cmd-go-make-content-based-hash-generation-less-pedan.patch
> @@ -0,0 +1,226 @@
> +From a13ae484e41139094505d2834437e9262a5315f7 Mon Sep 17 00:00:00 2001
> +From: Alex Kube
> +Date: Wed, 23 Oct 2019 21:14:22 +0430
> +Subject: [PATCH 2/9] cmd/go: make content-based hash generation less pedantic
> +
> +Upstream-Status: Inappropriate [OE specific]
> +
> +Go 1.10's build tool now uses content-based hashes to
> +determine when something should be built or re-built.
> +This same mechanism is used to maintain a built-artifact
> +cache for speeding up builds.
> +
> +However, the hashes it generates include information that
> +doesn't work well with OE, nor with using a shared runtime
> +library.
> +
> +First, it embeds path names to source files, unless
> +building within GOROOT. This prevents the building
> +of a package in GOPATH for later staging into GOROOT.
> +
> +This patch adds support for the environment variable
> +GOPATH_OMIT_IN_ACTIONID. If present, path name
> +embedding is disabled.
> +
> +Second, if cgo is enabled, the build ID for cgo-related
> +packages will include the current value of the
Re: [OE-core] [PATCH v6] mesa: Upgrade to 19.2.1
On 04/11/2019 22:48, Alistair Francis wrote: From: Alistair Francis Upgrade mesa and mesa-gl to 19.2.1. The license hash change was a trivial new line removal. The glx-tls option was removed as it isn't included in the meson.build file. It has been replaced with 'use-elf-tls' instead. I think this has regressed something, this is a new warning on musl builds: do_package_qa: QA Issue: ELF binary '[...]libgles2-mesa/usr/lib/libGLESv2.so.2.0.0' has relocations in .text [textrel] (ditto for libGLESv1_CM.so.1.1.0 libGL.so.1.2.0 libglapi.so.0.0.0) Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/3] systemd: Add runtime dependency on new ldconfig package
On Thu, 7 Nov 2019 16:58:57 -0800 Andre McCurdy wrote: > On Thu, Nov 7, 2019 at 12:55 PM Andreas Oberritter > wrote: > > > > Signed-off-by: Andreas Oberritter > > --- > > meta/recipes-core/systemd/systemd_243.bb | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/meta/recipes-core/systemd/systemd_243.bb > > b/meta/recipes-core/systemd/systemd_243.bb > > index 6e7f95693b..54fcc6a5d1 100644 > > --- a/meta/recipes-core/systemd/systemd_243.bb > > +++ b/meta/recipes-core/systemd/systemd_243.bb > > @@ -139,7 +139,7 @@ PACKAGECONFIG[importd] = > > "-Dimportd=true,-Dimportd=false" > > PACKAGECONFIG[iptc] = "-Dlibiptc=true,-Dlibiptc=false,iptables" > > PACKAGECONFIG[journal-upload] = "-Dlibcurl=true,-Dlibcurl=false,curl" > > PACKAGECONFIG[kmod] = "-Dkmod=true,-Dkmod=false,kmod" > > -PACKAGECONFIG[ldconfig] = "-Dldconfig=true,-Dldconfig=false" > > +PACKAGECONFIG[ldconfig] = "-Dldconfig=true,-Dldconfig=false,,ldconfig" > > Is this necessary? The implication of adding it is that you want to > support situations where ldconfig is disabled in DISTRO_FEATURES (ie > the new ldconfig package is not pulled in via a runtime dependency > from glibc) but then manually added to systemd PACKAGECONFIG (ie > ignoring DISTRO_FEATURES). That just seems like a misconfiguration and > not something we should try to support. If you enable ldconfig in systemd, then you clearly always want to install ldconfig with systemd. That's what this patch makes sure. You can still build other images without systemd (i.e. with sysvinit) and without ldconfig. That's what I do. Regards, Andreas -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] buildtools-tarball: export OPENSSL_CONF for openssl
export OPENSSL_CONF to aviod SDK openssl can not find openssl.cnf.
Signed-off-by: Liwei Song
---
meta/recipes-core/meta/buildtools-tarball.bb | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/recipes-core/meta/buildtools-tarball.bb
b/meta/recipes-core/meta/buildtools-tarball.bb
index 91df6f1ae9f6..9c5c2cc8d6e7 100644
--- a/meta/recipes-core/meta/buildtools-tarball.bb
+++ b/meta/recipes-core/meta/buildtools-tarball.bb
@@ -72,6 +72,7 @@ create_sdk_files_append () {
toolchain_create_sdk_version ${SDK_OUTPUT}/${SDKPATH}/version-${SDK_SYS}
echo 'export
GIT_SSL_CAINFO="${SDKPATHNATIVE}${sysconfdir}/ssl/certs/ca-certificates.crt"'
>>$script
+ echo 'export
OPENSSL_CONF="${SDKPATHNATIVE}${sysconfdir}/ssl/openssl.cnf"' >>$script
if [ "${SDKMACHINE}" = "i686" ]; then
echo 'export NO32LIBS="0"' >>$script
--
2.17.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v3 2/2] image_types: add Zstandard conversion support
From: Stefan Agner
Add Zstandard (or just Zstd) compression support. This allows to
create Zstd compressed tarballs by using tar.zst as IMAGE_FSTYPES.
Signed-off-by: Stefan Agner
---
meta/classes/image_types.bbclass | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/meta/classes/image_types.bbclass b/meta/classes/image_types.bbclass
index 2eeffbb366..d29b9c5787 100644
--- a/meta/classes/image_types.bbclass
+++ b/meta/classes/image_types.bbclass
@@ -59,6 +59,8 @@ XZ_INTEGRITY_CHECK ?= "crc32"
ZIP_COMPRESSION_LEVEL ?= "-9"
+ZSTD_COMPRESSION_LEVEL ?= "-3"
+
JFFS2_SUM_EXTRA_ARGS ?= ""
IMAGE_CMD_jffs2 = "mkfs.jffs2 --root=${IMAGE_ROOTFS} --faketime
--output=${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.jffs2
${EXTRA_IMAGECMD}"
@@ -269,7 +271,7 @@ IMAGE_TYPES = " \
hddimg \
squashfs squashfs-xz squashfs-lzo squashfs-lz4 \
ubi ubifs multiubi \
-tar tar.gz tar.bz2 tar.xz tar.lz4 \
+tar tar.gz tar.bz2 tar.xz tar.lz4 tar.zst \
cpio cpio.gz cpio.xz cpio.lzma cpio.lz4 \
wic wic.gz wic.bz2 wic.lzma \
container \
@@ -282,7 +284,7 @@ IMAGE_TYPES = " \
# CONVERSION_CMD/DEPENDS.
COMPRESSIONTYPES ?= ""
-CONVERSIONTYPES = "gz bz2 lzma xz lz4 lzo zip sum md5sum sha1sum sha224sum
sha256sum sha384sum sha512sum bmap u-boot vmdk vdi qcow2 base64
${COMPRESSIONTYPES}"
+CONVERSIONTYPES = "gz bz2 lzma xz lz4 lzo zip zst sum md5sum sha1sum sha224sum
sha256sum sha384sum sha512sum bmap u-boot vmdk vdi qcow2 base64
${COMPRESSIONTYPES}"
CONVERSION_CMD_lzma = "lzma -k -f -7 ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"
CONVERSION_CMD_gz = "gzip -f -9 -n -c --rsyncable
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} >
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.gz"
CONVERSION_CMD_bz2 = "pbzip2 -f -k ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"
@@ -290,6 +292,7 @@ CONVERSION_CMD_xz = "xz -f -k -c ${XZ_COMPRESSION_LEVEL}
${XZ_DEFAULTS} --check=
CONVERSION_CMD_lz4 = "lz4 -9 -z -l ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.lz4"
CONVERSION_CMD_lzo = "lzop -9 ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"
CONVERSION_CMD_zip = "zip ${ZIP_COMPRESSION_LEVEL}
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.zip
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"
+CONVERSION_CMD_zst = "zstd -f -k -c ${ZSTD_COMPRESSION_LEVEL}
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} >
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.zst"
CONVERSION_CMD_sum = "sumtool -i ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} -o
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.sum ${JFFS2_SUM_EXTRA_ARGS}"
CONVERSION_CMD_md5sum = "md5sum ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} >
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.md5sum"
CONVERSION_CMD_sha1sum = "sha1sum ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} >
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.sha1sum"
@@ -310,6 +313,7 @@ CONVERSION_DEPENDS_xz = "xz-native"
CONVERSION_DEPENDS_lz4 = "lz4-native"
CONVERSION_DEPENDS_lzo = "lzop-native"
CONVERSION_DEPENDS_zip = "zip-native"
+CONVERSION_DEPENDS_zst = "zstd-native"
CONVERSION_DEPENDS_sum = "mtd-utils-native"
CONVERSION_DEPENDS_bmap = "bmap-tools-native"
CONVERSION_DEPENDS_u-boot = "u-boot-tools-native"
--
2.17.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v3 1/2] zstd: move recipe to oe-core from meta-oe
From: Stefan Agner
Zstd is a very fast compression algorithm and has gained quite some
popularity recently. An upcoming patch allows to compress rootfs
using Zstd. Moving Zstd to oe-core allows this new conversion formats
to be automatically tested by the oe-selftest
imagefeatures.ImageFeatures.test_image_fstypes test.
Furthermore there are three packages in oe-core which allow to enable
Zstd support through packageconfig currently.
Signed-off-by: Stefan Agner
---
meta/recipes-extended/zstd/zstd_1.4.4.bb | 35
1 file changed, 35 insertions(+)
create mode 100644 meta/recipes-extended/zstd/zstd_1.4.4.bb
diff --git a/meta/recipes-extended/zstd/zstd_1.4.4.bb
b/meta/recipes-extended/zstd/zstd_1.4.4.bb
new file mode 100644
index 00..eb201f4139
--- /dev/null
+++ b/meta/recipes-extended/zstd/zstd_1.4.4.bb
@@ -0,0 +1,35 @@
+SUMMARY = "Zstandard - Fast real-time compression algorithm"
+DESCRIPTION = "Zstandard is a fast lossless compression algorithm, targeting \
+real-time compression scenarios at zlib-level and better compression ratios. \
+It's backed by a very fast entropy stage, provided by Huff0 and FSE library."
+HOMEPAGE = "http://www.zstd.net/;
+SECTION = "console/utils"
+
+LICENSE = "BSD-3-Clause & GPLv2"
+LIC_FILES_CHKSUM = "file://LICENSE;md5=c7f0b161edbe52f5f345a3d1311d0b32 \
+file://COPYING;md5=39bba7d2cf0ba1036f2a6e2be52fe3f0"
+
+SRC_URI = "git://github.com/facebook/zstd.git;nobranch=1"
+
+SRCREV = "10f0e6993f9d2f682da6d04aa2385b7d53cbb4ee"
+UPSTREAM_CHECK_GITTAGREGEX = "v(?P\d+(\.\d+)+)"
+
+S = "${WORKDIR}/git"
+
+PACKAGECONFIG ??= ""
+PACKAGECONFIG[lz4] = "HAVE_LZ4=1,HAVE_LZ4=0,lz4"
+PACKAGECONFIG[lzma] = "HAVE_LZMA=1,HAVE_LZMA=0,xz"
+PACKAGECONFIG[zlib] = "HAVE_ZLIB=1,HAVE_ZLIB=0,zlib"
+
+# See programs/README.md for how to use this
+ZSTD_LEGACY_SUPPORT ??= "4"
+
+do_compile () {
+oe_runmake ${PACKAGECONFIG_CONFARGS}
ZSTD_LEGACY_SUPPORT=${ZSTD_LEGACY_SUPPORT}
+}
+
+do_install () {
+oe_runmake install 'DESTDIR=${D}'
+}
+
+BBCLASSEXTEND = "native nativesdk"
--
2.17.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] archiver: avoid empty incfile in ar_recipe
ping
From: Grygorii Tertychnyi (gtertych)
Sent: Monday, November 4, 2019 17:09
To: Andrei Gherzan; openembedded-core@lists.openembedded.org
Cc: xe-linux-external(mailer list)
Subject: Re: [OE-core] [PATCH] archiver: avoid empty incfile in ar_recipe
Andrei,
From: Andrei Gherzan
Sent: Friday, November 1, 2019 13:28
To: Grygorii Tertychnyi (gtertych); openembedded-core@lists.openembedded.org
Cc: xe-linux-external(mailer list)
Subject: Re: [OE-core] [PATCH] archiver: avoid empty incfile in ar_recipe
>> do_ar_recipe fails on perf recipe on line:
>>
>> include ${@bb.utils.contains('PACKAGECONFIG', 'scripting', 'perf-perl.inc',
>> '', d)}
>>
>> 1. "${...}" part expands into empty string
>> 2. bb.utils.which() takes empty string and returns first directory name from
>> bbpath
> This doesn't sound sane. If the include directive has no argument,
> incfile should end up None. That's what the code "assumes" at this
I agree.
> point. I would fix it either at the regex expression level or
> stripping the matched string. I reckon the former makes more sense
> (.*).
Not sure I understand. Archiver class does not interpret "include" directive.
It just parses text files. The regular expression looks correct:
These lines:
440 elif include_re.match(line):
441 incfile = include_re.match(line).group(1)
put "${...}" _string_ into "incfile" variable. So, "incfile" is not None at
this stage.
Then,
443 incfile = d.expand(incfile)
Now "incfile" is empty and nobody checks it.
444 incfile = bb.utils.which(bbpath, incfile)
Now "incfile" is set to first directory name in BBPATH (wrong behavour?)
445 if incfile:
446 shutil.copy(incfile, outdir)
Exception here: "incfile" is directory, not a file.
--
Grygorii
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
