Re: [OE-core] [PATCHv2 03/11] rpm: Add dependencies on bash, perl and python3-core
On 15 June 2017 at 16:37, Peter Kjellerstedt
wrote:
> +RDEPENDS_${PN} = "bash perl python3-core"
>
That's quite a collection. Are they all needed for basic RPM to work?
(this results in core-image-sato pulling in bash when previously it didn't)
Ross
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] linux-libc-headers: fix duplicate IFF_LOWER_UP DORMANT ECHO on musl
connman is not doing anything wrong here.
The kernel is redefining IFF_LOWER_UP, because it thinks the libc doesn't
define it yet (and glibc doesn't).
libc-compat.h is the way to solve these kind of issues. There also is https:
//lkml.org/lkml/2017/3/12/238 which is very similar. I'll pick that instead.
Cheers,
Andre'
On Thu, 2017-06-22 at 22:26 +, Khem Raj wrote:
> I would rather fix the package instead of kernel headers unless kernel
> community accepts this patch
>
> On Thu, Jun 22, 2017 at 11:14 AM André Draszik wrote:
>
> > From: André Draszik
> >
> > musl _does_ define IFF_LOWER_UP DORMANT ECHO so we should
> > prevent redefinition of these when on musl.
> >
> > As per the included patch, this can be triggered by
> > (from connman 6to4.c):
> > include
> > include
> > include
> > include
> > include
> > include
> > include
> > include
> > include
> > include
> > include
> > include
> > include
> > include
> >
> > In file included from ../git/src/6to4.c:34:0:
> > .../usr/include/linux/if.h:97:2: error: expected identifier before
> > numeric
> > constant
> > IFF_LOWER_UP = 1<<16, /* __volatile__ */
> > ^
> >
> > This is because at that time, IFF_LOWER_UP has been converted
> > to 0x1 already:
> > enum net_device_flags {
> > 0x1 = 1<<16,
> > 0x2 = 1<<17,
> > 0x4 = 1<<18,
> >
> > };
> >
> > By defining __UAPI_DEF_IF_NET_DEVICE_FLAGS_LOWER_UP_DORMANT_ECHO
> > to 0, we avoid the duplicated definition.
> >
> > Signed-off-by: André Draszik
> > ---
> > h-musl-_does_-define-IFF_LOWER_UP-DORMAN.patch | 62
> > ++
> > .../linux-libc-headers/linux-libc-headers_4.10.bb | 1 +
> > 2 files changed, 63 insertions(+)
> > create mode 100644
> > meta/recipes-kernel/linux-libc-headers/linux-libc-headers/0001-libc-
> > compat.h-musl-_does_-define-IFF_LOWER_UP-DORMAN.patch
> >
> > diff --git
> > a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers/0001-libc-
> > compat.h-musl-_does_-define-IFF_LOWER_UP-DORMAN.patch
> > b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers/0001-libc-
> > compat.h-musl-_does_-define-IFF_LOWER_UP-DORMAN.patch
> > new file mode 100644
> > index 00..fd1bb9edb8
> > --- /dev/null
> > +++
> > b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers/0001-libc-
> > compat.h-musl-_does_-define-IFF_LOWER_UP-DORMAN.patch
> > @@ -0,0 +1,62 @@
> > +From 08a04c025395b0580913285045f2af36ee0985db Mon Sep 17 00:00:00 2001
> > +From: =?UTF-8?q?Andr=C3=A9=20Draszik?=
> > +Date: Thu, 15 Jun 2017 16:55:33 +0100
> > +Subject: [PATCH] libc-compat.h: musl _does_ define IFF_LOWER_UP DORMANT
> > ECHO
> > +MIME-Version: 1.0
> > +Content-Type: text/plain; charset=UTF-8
> > +Content-Transfer-Encoding: 8bit
> > +
> > +To trigger this (from connman 6to4.c):
> > +include
> > +include
> > +include
> > +include
> > +include
> > +include
> > +include
> > +include
> > +include
> > +include
> > +include
> > +include
> > +include
> > +include
> > +
> > +In file included from ../git/src/6to4.c:34:0:
> > +/scratch/yocto/build-tgm-r3-poky-fpp-tgm.pyro/tmp/work/tgm_r3-poky-
> > linux-musl/connman/1.33-git4+AUTOINC+aa5b3dc12b-r0/recipe-
> > sysroot/usr/include/linux/if.h:97:2:
> > error: expected identifier before numeric constant
> > + IFF_LOWER_UP = 1<<16, /* __volatile__ */
> > + ^
> > +
> > +This is because at that time, IFF_LOWER_UP has been converted
> > +to 0x1 already:
> > +enum net_device_flags {
> > + 0x1 = 1<<16,
> > + 0x2 = 1<<17,
> > + 0x4 = 1<<18,
> > +
> > +};
> > +
> > +Upstream-Status: Pending
> > +Signed-off-by: André Draszik
> > +Acked-by: Stephane Ayotte
> > +---
> > + include/uapi/linux/libc-compat.h | 3 ++-
> > + 1 file changed, 2 insertions(+), 1 deletion(-)
> > +
> > +diff --git a/include/uapi/linux/libc-compat.h
> > b/include/uapi/linux/libc-compat.h
> > +index f11ec0e..2003ae4 100644
> > +--- a/include/uapi/linux/libc-compat.h
> > b/include/uapi/linux/libc-compat.h
> > +@@ -70,7 +70,8 @@
> > + #define __UAPI_DEF_IF_NET_DEVICE_FLAGS 0
> > + /* For the future if glibc adds IFF_LOWER_UP, IFF_DORMANT and IFF_ECHO
> > */
> > + #ifndef __UAPI_DEF_IF_NET_DEVICE_FLAGS_LOWER_UP_DORMANT_ECHO
> > +-#define __UAPI_DEF_IF_NET_DEVICE_FLAGS_LOWER_UP_DORMANT_ECHO 1
> > ++/* musl has these defined */
> > ++#define __UAPI_DEF_IF_NET_DEVICE_FLAGS_LOWER_UP_DORMANT_ECHO 0
> > + #endif /* __UAPI_DEF_IF_NET_DEVICE_FLAGS_LOWER_UP_DORMANT_ECHO */
> > +
> > + #else /* _NET_IF_H */
> > +--
> > +2.11.0
> > +
> > diff --git a/meta/recipes-kernel/linux-libc-headers/
> > linux-libc-headers_4.10.bb b/meta/recipes-kernel/linux-libc-headers/
> > linux-libc-headers_4.10.bb
> > index 108446aa34..29262789a8 100644
> > --- a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_4.10.bb
> > +++ b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_4.10.bb
> > @@ -4,6 +4,7 @@ S
[OE-core] [PATCH] tzcode-native: quote ${CC}
build fails else with
| + make -j 8 -l 6 cc=ccache gcc
| make: *** No rule to make target 'gcc'. Stop.
Signed-off-by: Enrico Scholz
---
meta/recipes-extended/tzcode/tzcode-native_2017b.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-extended/tzcode/tzcode-native_2017b.bb
b/meta/recipes-extended/tzcode/tzcode-native_2017b.bb
index 2084f79..165d2c6 100644
--- a/meta/recipes-extended/tzcode/tzcode-native_2017b.bb
+++ b/meta/recipes-extended/tzcode/tzcode-native_2017b.bb
@@ -18,7 +18,7 @@ S = "${WORKDIR}"
inherit native
-EXTRA_OEMAKE += "cc=${CC}"
+EXTRA_OEMAKE += "cc='${CC}'"
do_install () {
install -d ${D}${bindir}/
--
2.9.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2] linux-libc-headers: fix duplicate IFF_LOWER_UP DORMANT ECHO on musl
From: André Draszik
musl _does_ define IFF_LOWER_UP DORMANT ECHO so we should
prevent redefinition of these when on musl.
As per the included patch, this can be triggered by
(from connman 6to4.c):
include
include
include
include
include
include
include
include
include
include
include
include
include
include
In file included from ../git/src/6to4.c:34:0:
.../usr/include/linux/if.h:97:2: error: expected identifier before numeric
constant
IFF_LOWER_UP = 1<<16, /* __volatile__ */
^
This is because at that time, IFF_LOWER_UP has been converted
to 0x1 already:
enum net_device_flags {
0x1 = 1<<16,
0x2 = 1<<17,
0x4 = 1<<18,
};
Backport a patch that addresses this.
Signed-off-by: André Draszik
---
h-musl-_does_-define-IFF_LOWER_UP-DORMAN.patch | 46 ++
.../linux-libc-headers/linux-libc-headers_4.10.bb | 1 +
2 files changed, 47 insertions(+)
create mode 100644
meta/recipes-kernel/linux-libc-headers/linux-libc-headers/0001-libc-compat.h-musl-_does_-define-IFF_LOWER_UP-DORMAN.patch
diff --git
a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers/0001-libc-compat.h-musl-_does_-define-IFF_LOWER_UP-DORMAN.patch
b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers/0001-libc-compat.h-musl-_does_-define-IFF_LOWER_UP-DORMAN.patch
new file mode 100644
index 00..bde2132ebf
--- /dev/null
+++
b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers/0001-libc-compat.h-musl-_does_-define-IFF_LOWER_UP-DORMAN.patch
@@ -0,0 +1,46 @@
+Content-Type: text/plain; charset="utf-8"
+MIME-Version: 1.0
+Content-Transfer-Encoding: 7bit
+Subject: [v2,2/3] uapi glibc compat: fix build if libc defines IFF_ECHO
+From: Hauke Mehrtens
+X-Patchwork-Id: 9686293
+Message-Id: <20170418210036.26039-3-ha...@hauke-m.de>
+To: da...@davemloft.net, net...@vger.kernel.org
+Cc: linux-ker...@vger.kernel.org, ja...@redhat.com, j...@openwrt.org,
+ david.heidelber...@ixit.cz, maillist-li...@barfooze.de,
+ mikko.rap...@iki.fi, dw...@infradead.org, Hauke Mehrtens
+Date: Tue, 18 Apr 2017 23:00:35 +0200
+
+musl 1.1.15 defines IFF_ECHO and the other net_device_flags options.
+When a user application includes linux/if.h and net/if.h the compile
+will fail.
+
+Activate __UAPI_DEF_IF_NET_DEVICE_FLAGS_LOWER_UP_DORMANT_ECHO only when
+it is needed. This should also make this work in case glibc will add
+these defines.
+
+Acked-by: Mikko Rapeli
+Signed-off-by: Hauke Mehrtens
+---
+Upstream-Status: Submitted [https://patchwork.kernel.org/patch/9686293/]
+Signed-off-by: André Draszik
+Acked-by: Stephane Ayotte
+ include/uapi/linux/libc-compat.h | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/include/uapi/linux/libc-compat.h
b/include/uapi/linux/libc-compat.h
+index 43a81136ea6e..ce2fa8a4ced6 100644
+--- a/include/uapi/linux/libc-compat.h
b/include/uapi/linux/libc-compat.h
+@@ -64,9 +64,11 @@
+ /* Everything up to IFF_DYNAMIC, matches net/if.h until glibc 2.23 */
+ #define __UAPI_DEF_IF_NET_DEVICE_FLAGS 0
+ /* For the future if glibc adds IFF_LOWER_UP, IFF_DORMANT and IFF_ECHO */
++#ifndef IFF_ECHO
+ #ifndef __UAPI_DEF_IF_NET_DEVICE_FLAGS_LOWER_UP_DORMANT_ECHO
+ #define __UAPI_DEF_IF_NET_DEVICE_FLAGS_LOWER_UP_DORMANT_ECHO 1
+ #endif /* __UAPI_DEF_IF_NET_DEVICE_FLAGS_LOWER_UP_DORMANT_ECHO */
++#endif /* IFF_ECHO */
+
+ #else /* _NET_IF_H */
+
diff --git a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_4.10.bb
b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_4.10.bb
index 108446aa34..29262789a8 100644
--- a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_4.10.bb
+++ b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_4.10.bb
@@ -4,6 +4,7 @@ SRC_URI_append_libc-musl = "\
file://0001-libc-compat.h-fix-some-issues-arising-from-in6.h.patch \
file://0002-libc-compat.h-prevent-redefinition-of-struct-ethhdr.patch \
file://0003-remove-inclusion-of-sysinfo.h-in-kernel.h.patch \
+file://0001-libc-compat.h-musl-_does_-define-IFF_LOWER_UP-DORMAN.patch \
"
SRC_URI[md5sum] = "b5e7f6b9b2fe1b6cc7bc56a3a0bfc090"
--
2.11.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] how to load cmake args from git?
On Thu, 22 Jun 2017 22:51:26 +0100
"Burton, Ross" wrote:
> On 22 June 2017 at 09:42, Adam Trhon wrote:
>
> > but I am not very happy about using PACKAGECONFIG_CONFARGS - it feels
> > hacky, the
> > arguments are not shown in cmake fail log and it cannot handle argumetns
> > containing
> > spaces. Is there a cleaner way to achieve this?
> >
>
> Definitely don't use PACKAGECONFIG_CONFARGS: that has a well defined
> meaning and use, and that isn't it.
>
> I don't see why as you control the repository why can't you just set the
> arguments in cmakelists, or the recipe itself? Either they're useful
> everywhere (cmakelists) or in OE builds (recipe).
The CMake options are maintained and used by upstream project developers
(I am one of them). Sometimes they change the options between
revisions, so it is difficult to maintain the argument list in the
recipe.
I also want to let the upstream project developers change some arguments
without touching the recipe (for automated builds).
>
> Anyway, you could do something like this:
>
> python() {
> d.appendVar("EXTRA_OECMAKE", " " +
> open(d.expand("${S}/oe_arguments.txt")).read()
> }
According to documentation, this is expanded during recipe parsing. At
that time ${S}/oe_arguments.txt does not yet exits (it exists only after
do_unpack). I tried it and the build failed with python Exception:
FileNotFound.
I tried
python do_setup_extra_oecmake() {
d.appendVar("EXTRA_OECMAKE", " " +
open(d.expand("${S}/oe_arguments.txt")).read())
print("adding "+d.expand("${S}/oe_arguments.txt"))
}
addtask do_setup_extra_oecmake after do_unpack before do_configure
but it did not work as well. The "adding " line is printed
correctly in log.do_setup_extra_oecmake, the file exists, but the
arguments in it are not used (I checked run.do_configure).
Thank you
Adam
>
> Ross
--
Ing. Adam Trhoň, Software Engineer
Touchless Biometric Systems s.r.o. |
Palackého třída 180/44 | 61200 Brno | CZECH REPUBLIC |
Mobile: +42(0) 721 565 113 | tbs-biometrics.cz
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] how to load cmake args from git?
On 23 June 2017 at 11:57, Adam Trhon wrote:
> According to documentation, this is expanded during recipe parsing. At
> that time ${S}/oe_arguments.txt does not yet exits (it exists only after
> do_unpack). I tried it and the build failed with python Exception:
> FileNotFound.
>
Yes, good point. In m defence it was late. :)
> I tried
>
> python do_setup_extra_oecmake() {
> d.appendVar("EXTRA_OECMAKE", " " + open(d.expand("${S}/oe_
> arguments.txt")).read())
> print("adding "+d.expand("${S}/oe_arguments.txt"))
> }
>
> addtask do_setup_extra_oecmake after do_unpack before do_configure
>
> but it did not work as well. The "adding " line is printed
> correctly in log.do_setup_extra_oecmake, the file exists, but the
> arguments in it are not used (I checked run.do_configure).
>
Have a look at log.do_configure and verify what options are being passed.
I'm also assuming that you're using the cmake class here.
Ross
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/2] enhance and test runCmd()
This is mostly motivated by some long-running build tests triggered in refkit where better output handling would be very desirable. I had this idea already before Leonardo proposed to change the runCmd() defaults, but as that's now a hot topic, it seemed like a good time to actually implement it. The result.error encoding fix is something that Leonardo also had in his "[OE-core] [PATCH 2/2] selftest/cases: use stderr data when querying for errors" patch. Beware that this patch series conflicts with those patches because that same code is changed and because the current default semantic (joined stdout/stderr) gets explicitly tested. Patrick Ohly (2): commands.py: live output logging + result.error encoding fix runcmd.py: unit testing for runCmd() meta/lib/oeqa/selftest/cases/runcmd.py | 117 ++- meta/lib/oeqa/utils/commands.py| 103 ++- 2 files changed, 199 insertions(+), 21 deletions(-) create mode 100644 meta/lib/oeqa/selftest/cases/runcmd.py base-commit: 1d9a88f635549e68562de681e297b9270ad02d4e -- git-series 0.9.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/2] runcmd.py: unit testing for runCmd()
This covers the traditional API as well as the new output_log feature.
While testing, it was noticed that killing hanging commands does not
work when a shell is used to run the command(s). This might be worth
fixing.
Signed-off-by: Patrick Ohly
---
meta/lib/oeqa/selftest/cases/runcmd.py | 117 ++-
1 file changed, 117 insertions(+)
create mode 100644 meta/lib/oeqa/selftest/cases/runcmd.py
diff --git a/meta/lib/oeqa/selftest/cases/runcmd.py
b/meta/lib/oeqa/selftest/cases/runcmd.py
new file mode 100644
index 000..6c785ca
--- /dev/null
+++ b/meta/lib/oeqa/selftest/cases/runcmd.py
@@ -0,0 +1,117 @@
+from oeqa.selftest.case import OESelftestTestCase
+from oeqa.utils.commands import runCmd
+from oeqa.utils import CommandError
+
+import subprocess
+import threading
+import time
+import signal
+
+class MemLogger(object):
+def __init__(self):
+self.info_msgs = []
+self.error_msgs = []
+
+def info(self, msg):
+self.info_msgs.append(msg)
+
+def error(self, msg):
+self.error_msgs.append(msg)
+
+class RunCmdTests(OESelftestTestCase):
+""" Basic tests for runCmd() utility function """
+
+# The delta is intentionally smaller than the timeout, to detect cases
where
+# we incorrectly apply the timeout more than once.
+TIMEOUT = 2
+DELTA = 1
+
+def test_result_okay(self):
+result = runCmd("true")
+self.assertEqual(result.status, 0)
+
+def test_result_false(self):
+result = runCmd("false", ignore_status=True)
+self.assertEqual(result.status, 1)
+
+def test_shell(self):
+# A shell is used for all string commands.
+result = runCmd("false; true", ignore_status=True)
+self.assertEqual(result.status, 0)
+
+def test_no_shell(self):
+self.assertRaises(FileNotFoundError,
+ runCmd, "false; true", shell=False)
+
+def test_list_not_found(self):
+self.assertRaises(FileNotFoundError,
+ runCmd, ["false; true"])
+
+def test_list_okay(self):
+result = runCmd(["true"])
+self.assertEqual(result.status, 0)
+
+def test_result_assertion(self):
+self.assertRaisesRegexp(AssertionError, "Command 'echo .* false'
returned non-zero exit status 1:\nfoobar",
+runCmd, "echo foobar >&2; false", shell=True)
+
+def test_result_exception(self):
+self.assertRaisesRegexp(CommandError, "Command 'echo .* false'
returned non-zero exit status 1 with output: foobar",
+runCmd, "echo foobar >&2; false", shell=True,
assert_error=False)
+
+def test_output(self):
+result = runCmd("echo stdout; echo stderr >&2", shell=True)
+self.assertEqual("stdout\nstderr", result.output)
+self.assertEqual("", result.error)
+
+def test_output_split(self):
+result = runCmd("echo stdout; echo stderr >&2", shell=True,
stderr=subprocess.PIPE)
+self.assertEqual("stdout", result.output)
+self.assertEqual("stderr", result.error)
+
+def test_timeout(self):
+numthreads = threading.active_count()
+start = time.time()
+# Killing a hanging process only works when not using a shell?!
+result = runCmd(['sleep', '60'], timeout=self.TIMEOUT,
ignore_status=True)
+self.assertEqual(result.status, -signal.SIGTERM)
+end = time.time()
+self.assertLess(end - start, self.TIMEOUT + self.DELTA)
+self.assertEqual(numthreads, threading.active_count())
+
+def test_timeout_split(self):
+numthreads = threading.active_count()
+start = time.time()
+# Killing a hanging process only works when not using a shell?!
+result = runCmd(['sleep', '60'], timeout=self.TIMEOUT,
ignore_status=True, stderr=subprocess.PIPE)
+self.assertEqual(result.status, -signal.SIGTERM)
+end = time.time()
+self.assertLess(end - start, self.TIMEOUT + self.DELTA)
+self.assertEqual(numthreads, threading.active_count())
+
+def test_stdin(self):
+numthreads = threading.active_count()
+result = runCmd("cat", data=b"hello world", timeout=self.TIMEOUT)
+self.assertEqual("hello world", result.output)
+self.assertEqual(numthreads, threading.active_count())
+
+def test_stdin_timeout(self):
+numthreads = threading.active_count()
+start = time.time()
+result = runCmd(['sleep', '60'], data=b"hello world",
timeout=self.TIMEOUT, ignore_status=True)
+self.assertEqual(result.status, -signal.SIGTERM)
+end = time.time()
+self.assertLess(end - start, self.TIMEOUT + self.DELTA)
+self.assertEqual(numthreads, threading.active_count())
+
+def test_log(self):
+log = MemLogger()
+result = runCmd("echo stdout; echo stderr >&2", shell=True,
output_log=log)
+self.assertEqual(["Running: echo stdout; echo stderr >&2",
[OE-core] [PATCH 1/2] commands.py: live output logging + result.error encoding fix
Tests that use bitbake("my-test-image") can run for a long time
without any indication to the user of oe-selftest about what's going
on. The test author has to log the bitbake output explicitly,
otherwise it is lost in case of test failures.
Now it is possible to use bitbake("my-test-image",
output_log=self.logger) to get more output both on the console and in
the XML output (when xmlrunner is installed). Example output:
2017-06-23 12:23:14,144 - oe-selftest - INFO - Running tests...
2017-06-23 12:23:14,145 - oe-selftest - INFO -
--
2017-06-23 12:23:14,151 - oe-selftest - INFO - Running: bitbake my-test-image
2017-06-23 12:23:16,363 - oe-selftest - INFO - Loading cache...done.
2017-06-23 12:23:17,575 - oe-selftest - INFO - Loaded 3529 entries from
dependency cache.
2017-06-23 12:23:18,811 - oe-selftest - INFO - Parsing recipes...done.
2017-06-23 12:23:19,659 - oe-selftest - INFO - Parsing of 2617 .bb files
complete (2612 cached, 5 parsed). 3533 targets, 460 skipped, 0 masked, 0 errors.
2017-06-23 12:23:19,659 - oe-selftest - INFO - NOTE: Resolving any missing task
queue dependencies
Because the implementation was already using threading, the same is
done to decouple reading and writing the different pipes instead of
trying to multiplex IO in a single thread.
The most common case (no input data, joined stdout/stderr) still uses
one extra thread and a single read(), so performance should be roughly
the same as before.
Probably unintentionally, result.error was left as byte string when
migrating to Python3. OE-core doesn't seem to use runCmd() with split
output at the moment, so changing result.error to be treated the same
as result.output (i.e. decoded to a normal strings) seems like a
relatively safe API change (or rather, implementation fix).
Signed-off-by: Patrick Ohly
---
meta/lib/oeqa/utils/commands.py | 103 ++---
1 file changed, 82 insertions(+), 21 deletions(-)
diff --git a/meta/lib/oeqa/utils/commands.py b/meta/lib/oeqa/utils/commands.py
index 57286fc..cc93448 100644
--- a/meta/lib/oeqa/utils/commands.py
+++ b/meta/lib/oeqa/utils/commands.py
@@ -13,6 +13,7 @@ import sys
import signal
import subprocess
import threading
+import time
import logging
from oeqa.utils import CommandError
from oeqa.utils import ftools
@@ -25,7 +26,7 @@ except ImportError:
pass
class Command(object):
-def __init__(self, command, bg=False, timeout=None, data=None, **options):
+def __init__(self, command, bg=False, timeout=None, data=None,
output_log=None, **options):
self.defaultopts = {
"stdout": subprocess.PIPE,
@@ -48,40 +49,100 @@ class Command(object):
self.options.update(options)
self.status = None
+# We collect chunks of output before joining them at the end.
+self._output_chunks = []
+self._error_chunks = []
self.output = None
self.error = None
-self.thread = None
+self.threads = []
+self.output_log = output_log
self.log = logging.getLogger("utils.commands")
def run(self):
self.process = subprocess.Popen(self.cmd, **self.options)
-def commThread():
-self.output, self.error = self.process.communicate(self.data)
-
-self.thread = threading.Thread(target=commThread)
-self.thread.start()
+def readThread(output, stream, logfunc):
+if logfunc:
+for line in stream:
+output.append(line)
+logfunc(line.decode("utf-8", errors='replace').rstrip())
+else:
+output.append(stream.read())
+
+def readStderrThread():
+readThread(self._error_chunks, self.process.stderr,
self.output_log.error if self.output_log else None)
+
+def readStdoutThread():
+readThread(self._output_chunks, self.process.stdout,
self.output_log.info if self.output_log else None)
+
+def writeThread():
+try:
+self.process.stdin.write(self.data)
+self.process.stdin.close()
+except OSError as ex:
+# It's not an error when the command does not consume all
+# of our data. subprocess.communicate() also ignores that.
+if ex.errno != EPIPE:
+raise
+
+# We write in a separate thread because then we can read
+# without worrying about deadlocks. The additional thread is
+# expected to terminate by itself and we mark it as a daemon,
+# so even it should happen to not terminate for whatever
+# reason, the main process will still exit, which will then
+# kill the write thread.
+if self.data:
+threading.Thread(target=writeThread, daemon=True).start()
+if self.process.stderr:
+thread = threading.Thread(target=readStderrThre
Re: [OE-core] [PATCHv3] oe-pkgdata-util: package-info: Allow extra variables to be displayed
On 19 June 2017 at 15:31, Peter Kjellerstedt wrote: > +if args.extra: > +for val in args.extra: > +src_uri = mappings[pkg][val].strip() > +src_uri = re.sub(r'\s+', ' ', src_uri) > +line += ' "%s"' % src_uri > I don't think you meant src_uri here. :) Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] ARC arch support: uClibc status ?
Hello everyone, We are currently adding to Yocto project the Synopsys ARC CPU architecture, which is only available with uClibc library. We currently have a layer which adds the support of this architecture and uClibc support as it is, now, removed from OE-core. Many configurations/fixes are needed in OpenEmbedded-core's recipes to build successfully with this C library (library's dependencies, autotools configuration, etc). We wanted to send patches to fix them but it seems that all uClibc's references are now removed from OE-core, even in recipes: https://patchwork.openembedded.org/patch/140943/ https://patches.openembedded.org/patch/140906/ What is the status of it? Remove entirely uClibc from OE-core? Could you give us advice on how to handle uClibc? Should we create a "meta-uclibc" layer which adds support of it + bbappend for all the OE-core's recipes that currently fail because of uClibc's misconfiguration? I guess that there is no plan to add uClibc's configuration in OE-core's recipes (even without uClibc itself), right? Thank you in advance, Best regards, -- Mylène Josserand, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] how to load cmake args from git?
On Fri, 23 Jun 2017 13:53:05 +0100
"Burton, Ross" wrote:
> On 23 June 2017 at 11:57, Adam Trhon wrote:
>
> > According to documentation, this is expanded during recipe parsing. At
> > that time ${S}/oe_arguments.txt does not yet exits (it exists only after
> > do_unpack). I tried it and the build failed with python Exception:
> > FileNotFound.
> >
>
> Yes, good point. In m defence it was late. :)
>
>
> > I tried
> >
> > python do_setup_extra_oecmake() {
> > d.appendVar("EXTRA_OECMAKE", " " + open(d.expand("${S}/oe_
> > arguments.txt")).read())
> > print("adding "+d.expand("${S}/oe_arguments.txt"))
> > }
> >
> > addtask do_setup_extra_oecmake after do_unpack before do_configure
> >
> > but it did not work as well. The "adding " line is printed
> > correctly in log.do_setup_extra_oecmake, the file exists, but the
> > arguments in it are not used (I checked run.do_configure).
> >
>
> Have a look at log.do_configure and verify what options are being passed.
I still have EXTRA_OECMAKE="..." in the recipe, the arguments from here
are being passed. But the arguments from oe_arguments.txt are not.
> I'm also assuming that you're using the cmake class here.
To be precise, I inherit cmake_qt5 class, which inherits cmake class.
Adam
>
> Ross
--
Ing. Adam Trhoň, Software Engineer
Touchless Biometric Systems s.r.o. |
Palackého třída 180/44 | 61200 Brno | CZECH REPUBLIC |
Mobile: +42(0) 721 565 113 | tbs-biometrics.cz
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] linux-libc-headers: fix duplicate IFF_LOWER_UP DORMANT ECHO on musl
On Fri, Jun 23, 2017 at 3:46 AM, André Draszik wrote:
> connman is not doing anything wrong here.
>
yes I am aware of this
> The kernel is redefining IFF_LOWER_UP, because it thinks the libc doesn't
> define it yet (and glibc doesn't).
>
> libc-compat.h is the way to solve these kind of issues. There also is https:
> //lkml.org/lkml/2017/3/12/238 which is very similar. I'll pick that instead.
>
see the comment https://lkml.org/lkml/2017/3/16/121
that worries me for this patch
I am not questioning the correctness of patch too. But
it would be better to get this patch accepted into kernel
before applying to OE since these are kind of patches which
you can get stuck with for life if upstream is not accepting it.
> Cheers,
> Andre'
>
> On Thu, 2017-06-22 at 22:26 +, Khem Raj wrote:
>> I would rather fix the package instead of kernel headers unless kernel
>> community accepts this patch
>>
>> On Thu, Jun 22, 2017 at 11:14 AM André Draszik wrote:
>>
>> > From: André Draszik
>> >
>> > musl _does_ define IFF_LOWER_UP DORMANT ECHO so we should
>> > prevent redefinition of these when on musl.
>> >
>> > As per the included patch, this can be triggered by
>> > (from connman 6to4.c):
>> > include
>> > include
>> > include
>> > include
>> > include
>> > include
>> > include
>> > include
>> > include
>> > include
>> > include
>> > include
>> > include
>> > include
>> >
>> > In file included from ../git/src/6to4.c:34:0:
>> > .../usr/include/linux/if.h:97:2: error: expected identifier before
>> > numeric
>> > constant
>> > IFF_LOWER_UP = 1<<16, /* __volatile__ */
>> > ^
>> >
>> > This is because at that time, IFF_LOWER_UP has been converted
>> > to 0x1 already:
>> > enum net_device_flags {
>> > 0x1 = 1<<16,
>> > 0x2 = 1<<17,
>> > 0x4 = 1<<18,
>> >
>> > };
>> >
>> > By defining __UAPI_DEF_IF_NET_DEVICE_FLAGS_LOWER_UP_DORMANT_ECHO
>> > to 0, we avoid the duplicated definition.
>> >
>> > Signed-off-by: André Draszik
>> > ---
>> > h-musl-_does_-define-IFF_LOWER_UP-DORMAN.patch | 62
>> > ++
>> > .../linux-libc-headers/linux-libc-headers_4.10.bb | 1 +
>> > 2 files changed, 63 insertions(+)
>> > create mode 100644
>> > meta/recipes-kernel/linux-libc-headers/linux-libc-headers/0001-libc-
>> > compat.h-musl-_does_-define-IFF_LOWER_UP-DORMAN.patch
>> >
>> > diff --git
>> > a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers/0001-libc-
>> > compat.h-musl-_does_-define-IFF_LOWER_UP-DORMAN.patch
>> > b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers/0001-libc-
>> > compat.h-musl-_does_-define-IFF_LOWER_UP-DORMAN.patch
>> > new file mode 100644
>> > index 00..fd1bb9edb8
>> > --- /dev/null
>> > +++
>> > b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers/0001-libc-
>> > compat.h-musl-_does_-define-IFF_LOWER_UP-DORMAN.patch
>> > @@ -0,0 +1,62 @@
>> > +From 08a04c025395b0580913285045f2af36ee0985db Mon Sep 17 00:00:00 2001
>> > +From: =?UTF-8?q?Andr=C3=A9=20Draszik?=
>> > +Date: Thu, 15 Jun 2017 16:55:33 +0100
>> > +Subject: [PATCH] libc-compat.h: musl _does_ define IFF_LOWER_UP DORMANT
>> > ECHO
>> > +MIME-Version: 1.0
>> > +Content-Type: text/plain; charset=UTF-8
>> > +Content-Transfer-Encoding: 8bit
>> > +
>> > +To trigger this (from connman 6to4.c):
>> > +include
>> > +include
>> > +include
>> > +include
>> > +include
>> > +include
>> > +include
>> > +include
>> > +include
>> > +include
>> > +include
>> > +include
>> > +include
>> > +include
>> > +
>> > +In file included from ../git/src/6to4.c:34:0:
>> > +/scratch/yocto/build-tgm-r3-poky-fpp-tgm.pyro/tmp/work/tgm_r3-poky-
>> > linux-musl/connman/1.33-git4+AUTOINC+aa5b3dc12b-r0/recipe-
>> > sysroot/usr/include/linux/if.h:97:2:
>> > error: expected identifier before numeric constant
>> > + IFF_LOWER_UP = 1<<16, /* __volatile__ */
>> > + ^
>> > +
>> > +This is because at that time, IFF_LOWER_UP has been converted
>> > +to 0x1 already:
>> > +enum net_device_flags {
>> > + 0x1 = 1<<16,
>> > + 0x2 = 1<<17,
>> > + 0x4 = 1<<18,
>> > +
>> > +};
>> > +
>> > +Upstream-Status: Pending
>> > +Signed-off-by: André Draszik
>> > +Acked-by: Stephane Ayotte
>> > +---
>> > + include/uapi/linux/libc-compat.h | 3 ++-
>> > + 1 file changed, 2 insertions(+), 1 deletion(-)
>> > +
>> > +diff --git a/include/uapi/linux/libc-compat.h
>> > b/include/uapi/linux/libc-compat.h
>> > +index f11ec0e..2003ae4 100644
>> > +--- a/include/uapi/linux/libc-compat.h
>> > b/include/uapi/linux/libc-compat.h
>> > +@@ -70,7 +70,8 @@
>> > + #define __UAPI_DEF_IF_NET_DEVICE_FLAGS 0
>> > + /* For the future if glibc adds IFF_LOWER_UP, IFF_DORMANT and IFF_ECHO
>> > */
>> > + #ifndef __UAPI_DEF_IF_NET_DEVICE_FLAGS_LOWER_UP_DORMANT_ECHO
>> > +-#define __UAPI_DEF_IF_NET_DEVICE_FLAGS_LOWER_UP_DORMANT_ECHO 1
>> > ++/* musl has these defined */
>> > ++#define __UAPI_DEF_IF_NET_
Re: [OE-core] ARC arch support: uClibc status ?
Hi, On Fri, 2017-06-23 at 15:23 +0200, Mylene Josserand wrote: > We are currently adding to Yocto project the Synopsys ARC CPU > architecture, which is only available with uClibc library. > > We currently have a layer which adds the support of this > architecture > and uClibc support as it is, now, removed from OE-core. > > Many configurations/fixes are needed in OpenEmbedded-core's recipes > to > build successfully with this C library (library's dependencies, > autotools configuration, etc). > > We wanted to send patches to fix them but it seems that all uClibc's > references are now removed from OE-core, even in recipes: > > https://patchwork.openembedded.org/patch/140943/ > https://patches.openembedded.org/patch/140906/ > > What is the status of it? Remove entirely uClibc from OE-core? > Could you give us advice on how to handle uClibc? Should we create > a > "meta-uclibc" layer which adds support of it + bbappend for all the > OE-core's recipes that currently fail because of uClibc's > misconfiguration? > > I guess that there is no plan to add uClibc's configuration in OE- > core's > recipes (even without uClibc itself), right? We dropped uclibc from OE-Core around a year ago in favour of musl since it seems to work for all the use cases we've been aware of from our users and nobody was willing to maintain it. Since then the uclibc overrides and other pieces in core have bitrotted to the point it was clear nobody was actively using or maintaining them. I therefore proposed some patches removing them, those were agreed by several developers and no objections were seen. We therefore cleaned up the remaining pieces. I believe that we have enhanced the extension mechanisms within the core such that a meta-uclibc layer would be possible now, even for the site files and insane.bbclass mappings and so on. It would need to add some of the extensions removed from the core and then it should be buildable again. If you can't make anything work from the layer let us know and we can try and figure out a way to solve that. I don't think the uclibc pieces would be coming back into OE-Core any time soon though as whilst it does have some niche markets left (e.g. arc), I can't see it being widely used by the majority of OE users/arches. (As an aside I haven't looked at it at all but does musl support arc?) Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] ARC arch support: uClibc status ?
On Fri, Jun 23, 2017 at 6:40 AM, Richard Purdie wrote: > Hi, > > On Fri, 2017-06-23 at 15:23 +0200, Mylene Josserand wrote: >> We are currently adding to Yocto project the Synopsys ARC CPU >> architecture, which is only available with uClibc library. >> >> We currently have a layer which adds the support of this >> architecture >> and uClibc support as it is, now, removed from OE-core. >> >> Many configurations/fixes are needed in OpenEmbedded-core's recipes >> to >> build successfully with this C library (library's dependencies, >> autotools configuration, etc). >> >> We wanted to send patches to fix them but it seems that all uClibc's >> references are now removed from OE-core, even in recipes: >> >> https://patchwork.openembedded.org/patch/140943/ >> https://patches.openembedded.org/patch/140906/ >> >> What is the status of it? Remove entirely uClibc from OE-core? >> Could you give us advice on how to handle uClibc? Should we create >> a >> "meta-uclibc" layer which adds support of it + bbappend for all the >> OE-core's recipes that currently fail because of uClibc's >> misconfiguration? >> >> I guess that there is no plan to add uClibc's configuration in OE- >> core's >> recipes (even without uClibc itself), right? > > We dropped uclibc from OE-Core around a year ago in favour of musl > since it seems to work for all the use cases we've been aware of from > our users and nobody was willing to maintain it. > > Since then the uclibc overrides and other pieces in core have bitrotted > to the point it was clear nobody was actively using or maintaining > them. I therefore proposed some patches removing them, those were > agreed by several developers and no objections were seen. We therefore > cleaned up the remaining pieces. > > I believe that we have enhanced the extension mechanisms within the > core such that a meta-uclibc layer would be possible now, even for the > site files and insane.bbclass mappings and so on. It would need to add > some of the extensions removed from the core and then it should be > buildable again. > > If you can't make anything work from the layer let us know and we can > try and figure out a way to solve that. I don't think the uclibc pieces > would be coming back into OE-Core any time soon though as whilst it > does have some niche markets left (e.g. arc), I can't see it being > widely used by the majority of OE users/arches. > > (As an aside I haven't looked at it at all but does musl support arc?) > I dont see arc support in upstream musl, It could good if it was there since that could unleash whole OE on arc architecture. We can do successful world builds on musl much like glibc now a days. > Cheers, > > Richard > > -- > ___ > 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] ARC arch support: uClibc status ?
On Fri, Jun 23, 2017 at 6:50 AM, Alexey Brodkin wrote: > Hi Khem, > > On Fri, 2017-06-23 at 06:46 -0700, Khem Raj wrote: >> On Fri, Jun 23, 2017 at 6:40 AM, Richard Purdie >> wrote: >> > >> > Hi, >> > >> > On Fri, 2017-06-23 at 15:23 +0200, Mylene Josserand wrote: >> > > >> > > We are currently adding to Yocto project the Synopsys ARC CPU >> > > architecture, which is only available with uClibc library. >> > > >> > > We currently have a layer which adds the support of this >> > > architecture >> > > and uClibc support as it is, now, removed from OE-core. >> > > >> > > Many configurations/fixes are needed in OpenEmbedded-core's recipes >> > > to >> > > build successfully with this C library (library's dependencies, >> > > autotools configuration, etc). >> > > >> > > We wanted to send patches to fix them but it seems that all uClibc's >> > > references are now removed from OE-core, even in recipes: >> > > >> > > https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.openembedded.org_patch_140943_&d=DwIBaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=lqdeeSSEes0GFD >> > > Dl656eViXO7breS55ytWkhpk5R81I&m=vXM6W0k4FOex1pzJnHfSDtrgw08G-uIiKgZJinDWFtI&s=wd0w1NqlVaNUjpgkDUqxfK2izS-a-XotxpeCqt3Mcro&e= >> > > https://urldefense.proofpoint.com/v2/url?u=https-3A__patches.openembedded.org_patch_140906_&d=DwIBaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=lqdeeSSEes0GFDDl >> > > 656eViXO7breS55ytWkhpk5R81I&m=vXM6W0k4FOex1pzJnHfSDtrgw08G-uIiKgZJinDWFtI&s=4Y1JNumo1mAFnPDzX2CaFZw9gfkSF2TJa_vIGO8A9yA&e= >> > > >> > > What is the status of it? Remove entirely uClibc from OE-core? >> > > Could you give us advice on how to handle uClibc? Should we create >> > > a >> > > "meta-uclibc" layer which adds support of it + bbappend for all the >> > > OE-core's recipes that currently fail because of uClibc's >> > > misconfiguration? >> > > >> > > I guess that there is no plan to add uClibc's configuration in OE- >> > > core's >> > > recipes (even without uClibc itself), right? >> > >> > We dropped uclibc from OE-Core around a year ago in favour of musl >> > since it seems to work for all the use cases we've been aware of from >> > our users and nobody was willing to maintain it. >> > >> > Since then the uclibc overrides and other pieces in core have bitrotted >> > to the point it was clear nobody was actively using or maintaining >> > them. I therefore proposed some patches removing them, those were >> > agreed by several developers and no objections were seen. We therefore >> > cleaned up the remaining pieces. >> > >> > I believe that we have enhanced the extension mechanisms within the >> > core such that a meta-uclibc layer would be possible now, even for the >> > site files and insane.bbclass mappings and so on. It would need to add >> > some of the extensions removed from the core and then it should be >> > buildable again. >> > >> > If you can't make anything work from the layer let us know and we can >> > try and figure out a way to solve that. I don't think the uclibc pieces >> > would be coming back into OE-Core any time soon though as whilst it >> > does have some niche markets left (e.g. arc), I can't see it being >> > widely used by the majority of OE users/arches. >> > >> > (As an aside I haven't looked at it at all but does musl support arc?) >> > >> >> I dont see arc support in upstream musl, It could good if it was there >> since that could unleash whole OE on arc architecture. We can do >> successful world builds on musl much like glibc now a days. > > Indeed there's no musl port for ARC [yet]. > But we're almost done with glibc port and it looks like we'll need to switch > to glibc for OE/Yocto which I believe is doable. > > I guess glibc is still the first class-citizen in OE, right? > yes that is right. > -Alexey -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] context: allow test execution with buildhistory unless version-going-backwards is present
The proposed approach is not the best one as discussed by RP [1]:
""Just as another note,
ERROR_QA_remove = "version-going-backwards"
WARN_QA_remove = "version-going-backwards"
doesn't work since we can't then enable this check and the test cases
test_buildhistory_buildtime_pr_backwards and test_buildhistory_diff then
fail."
[1] https://bugzilla.yoctoproject.org/show_bug.cgi?id=11580#c7
On Thu, 2017-06-08 at 13:40 -0700,
leonardo.sandoval.gonza...@linux.intel.com wrote:
> From: Leonardo Sandoval
>
> Users constantly running oe-selftest find annoying to disable buildhistory
> before running
> 'oe-selftest' then enabling after it. To lessen the buildhistory restriction,
> allow buildhistory
> unless 'version-going-backwards' is present on ERROR_QA bitbake variable.
>
> [YOCTO #11580]
>
> Signed-off-by: Leonardo Sandoval
> ---
> meta/lib/oeqa/selftest/context.py | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/meta/lib/oeqa/selftest/context.py
> b/meta/lib/oeqa/selftest/context.py
> index ca73070c0b..f061b987b0 100644
> --- a/meta/lib/oeqa/selftest/context.py
> +++ b/meta/lib/oeqa/selftest/context.py
> @@ -150,7 +150,8 @@ class
> OESelftestTestContextExecutor(OETestContextExecutor):
> _check_required_env_variables(["BUILDDIR"])
> _check_presence_meta_selftest()
>
> -if "buildhistory.bbclass" in self.tc.td["BBINCLUDED"]:
> +# buildhistory introduce QA 'version-going-backwards' errors so stop
> if the latter are enabled
> +if "buildhistory.bbclass" in self.tc.td["BBINCLUDED"] and
> 'version-going-backwards' in self.tc.td['ERROR_QA']:
> self.tc.logger.error("You have buildhistory enabled already and
> this isn't recommended for selftest, please disable it first.")
> raise OEQAPreRun
>
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] ✗ patchtest: failure for (morty) rpm: Fix the Bug of SRPM String error (rev2)
On Fri, 2017-06-23 at 02:01 +, Patchwork wrote: > == Series Details == > > Series: (morty) rpm: Fix the Bug of SRPM String error (rev2) > Revision: 2 > URL : https://patchwork.openembedded.org/series/7416/ > 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 7c36b4316a) For the moment, incoming patches are tested based on master, so non-master patches may fail when apply/am to master. So this is a false positive result. I will fix it. Leo > > > > 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] -> ...). > > --- > 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] linux-libc-headers: fix duplicate IFF_LOWER_UP DORMANT ECHO on musl
Hi, I'm chipping in since I've been messing with these things a bit in upstream Linux kernel. On Fri, Jun 23, 2017 at 06:37:52AM -0700, Khem Raj wrote: > On Fri, Jun 23, 2017 at 3:46 AM, André Draszik wrote: > > connman is not doing anything wrong here. > > > > yes I am aware of this > > > The kernel is redefining IFF_LOWER_UP, because it thinks the libc doesn't > > define it yet (and glibc doesn't). > > > > libc-compat.h is the way to solve these kind of issues. There also is https: > > //lkml.org/lkml/2017/3/12/238 which is very similar. I'll pick that instead. > > > see the comment https://lkml.org/lkml/2017/3/16/121 > that worries me for this patch I'm aware of those review comments but I have not seen any patches posted which fix the problem in some other way. Thus I would propose to apply these patches as a workaround until upstream fixes the issues. These header files do not change that often either. > I am not questioning the correctness of patch too. But > it would be better to get this patch accepted into kernel > before applying to OE since these are kind of patches which > you can get stuck with for life if upstream is not accepting it. Upstream-Status: Denied would be a correct marker for now I guess. Hope this helps, -Mikko -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] pkg-config: allow kernel to be build with esdk
On Wed, 2017-06-14 at 07:03 -0700, Saul Wold wrote: > When the kernel's menuconfig target is called while using the esdk or > an esdk-based container, the pkg-config info that is found is not > correct. > The pkg-config info is for the target, but we need the eSDK's > information in order to build the host based menuconfig. > > The new pkg-config script checks both that it's in SDK and being > called from the check-lxdialog script in order to limit the scope of > when the pkg-config automagically switches to pkg-config-native. > > This script also replaces the default pkg-config-native script. > > [YOCTO #11155] > > Signed-off-by: Saul Wold > --- To be honest, I'm scared of adding this kind of complexity to the system. I appreciate the problem you're trying to solve but I worry adding this kind of change is complex, invasive and introduces too much risk. I have some specific worries with this implementation too, in particular that it changes on target pkg-config, it really should only change nativesdk-pkgconfig? If we have risk, we want to minimise that risk and adding this wrapper everywhere doesn't seem to do that... Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/3] selftest/archiver: add tests for recipe type filtering
From: André Draszik
The archiver used to be able to filter based on COPYLEFT_RECIPE_TYPES.
Unfortunately, this got broken with the fix for
https://bugzilla.yoctoproject.org/show_bug.cgi?id=6929
in commit ae9102bda398 ("copyleft_filter.bbclass: Allow to filter on name")
Add two tests to prevent that from happening again.
Signed-off-by: André Draszik
---
meta/lib/oeqa/selftest/cases/archiver.py | 78
1 file changed, 78 insertions(+)
diff --git a/meta/lib/oeqa/selftest/cases/archiver.py
b/meta/lib/oeqa/selftest/cases/archiver.py
index 70c7282f22..9f686debe6 100644
--- a/meta/lib/oeqa/selftest/cases/archiver.py
+++ b/meta/lib/oeqa/selftest/cases/archiver.py
@@ -39,3 +39,81 @@ class Archiver(OESelftestTestCase):
# Check that exclude_recipe was excluded
excluded_present = len(glob.glob(src_path + '/%s-*' % exclude_recipe))
self.assertFalse(excluded_present, 'Recipe %s was not excluded.' %
exclude_recipe)
+
+
+@testcase(2012)
+def test_archiver_filters_by_type(self):
+"""
+Summary: The archiver is documented to filter on the recipe type.
+Expected:1. included recipe type (target) should be included
+ 2. other types should be excluded
+Product: oe-core
+Author: André Draszik
+"""
+
+target_recipe = 'initscripts'
+native_recipe = 'zlib-native'
+
+features = 'INHERIT += "archiver"\n'
+features += 'ARCHIVER_MODE[src] = "original"\n'
+features += 'COPYLEFT_RECIPE_TYPES = "target"\n'
+self.write_config(features)
+
+bitbake('-c clean %s %s' % (target_recipe, native_recipe))
+bitbake("%s -c deploy_archives %s" % (target_recipe, native_recipe))
+
+bb_vars = get_bb_vars(['DEPLOY_DIR_SRC', 'TARGET_SYS', 'BUILD_SYS'])
+src_path_target = os.path.join(bb_vars['DEPLOY_DIR_SRC'],
bb_vars['TARGET_SYS'])
+src_path_native = os.path.join(bb_vars['DEPLOY_DIR_SRC'],
bb_vars['BUILD_SYS'])
+
+# Check that target_recipe was included
+included_present = len(glob.glob(src_path_target + '/%s-*' %
target_recipe))
+self.assertTrue(included_present, 'Recipe %s was not included.' %
target_recipe)
+
+# Check that native_recipe was excluded
+excluded_present = len(glob.glob(src_path_native + '/%s-*' %
native_recipe))
+self.assertFalse(excluded_present, 'Recipe %s was not excluded.' %
native_recipe)
+
+@testcase(2013)
+def test_archiver_filters_by_type_and_name(self):
+"""
+Summary: Test that the archiver archives by recipe type, taking the
+ recipe name into account.
+Expected:1. included recipe type (target) should be included
+ 2. other types should be excluded
+ 3. recipe by name should be included / excluded,
+overriding previous decision by type
+Product: oe-core
+Author: André Draszik
+"""
+
+target_recipes = [ 'initscripts', 'zlib' ]
+native_recipes = [ 'update-rc.d-native', 'zlib-native' ]
+
+features = 'INHERIT += "archiver"\n'
+features += 'ARCHIVER_MODE[src] = "original"\n'
+features += 'COPYLEFT_RECIPE_TYPES = "target"\n'
+features += 'COPYLEFT_PN_INCLUDE = "%s"\n' % native_recipes[1]
+features += 'COPYLEFT_PN_EXCLUDE = "%s"\n' % target_recipes[1]
+self.write_config(features)
+
+bitbake('-c clean %s %s' % (' '.join(target_recipes), '
'.join(native_recipes)))
+bitbake('-c deploy_archives %s %s' % (' '.join(target_recipes), '
'.join(native_recipes)))
+
+bb_vars = get_bb_vars(['DEPLOY_DIR_SRC', 'TARGET_SYS', 'BUILD_SYS'])
+src_path_target = os.path.join(bb_vars['DEPLOY_DIR_SRC'],
bb_vars['TARGET_SYS'])
+src_path_native = os.path.join(bb_vars['DEPLOY_DIR_SRC'],
bb_vars['BUILD_SYS'])
+
+# Check that target_recipe[0] and native_recipes[1] were included
+included_present = len(glob.glob(src_path_target + '/%s-*' %
target_recipes[0]))
+self.assertTrue(included_present, 'Recipe %s was not included.' %
target_recipes[0])
+
+included_present = len(glob.glob(src_path_native + '/%s-*' %
native_recipes[1]))
+self.assertTrue(included_present, 'Recipe %s was not included.' %
native_recipes[1])
+
+# Check that native_recipes[0] and target_recipes[1] were excluded
+excluded_present = len(glob.glob(src_path_native + '/%s-*' %
native_recipes[0]))
+self.assertFalse(excluded_present, 'Recipe %s was not excluded.' %
native_recipes[0])
+
+excluded_present = len(glob.glob(src_path_target + '/%s-*' %
target_recipes[1]))
+self.assertFalse(excluded_present, 'Recipe %s was not excluded.' %
target_recipes[1])
--
2.11.0
--
___
Openembedded-core mailing list
Openembedded
[OE-core] [PATCH 2/3] selftest/archiver: only execute deploy_archives task
From: André Draszik
There should be no reason to execute a full build, as we're
just interested in the deployment of the archives.
The newly added tests already do the same.
Signed-off-by: André Draszik
---
meta/lib/oeqa/selftest/cases/archiver.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/lib/oeqa/selftest/cases/archiver.py
b/meta/lib/oeqa/selftest/cases/archiver.py
index 9f686debe6..ca9dad0643 100644
--- a/meta/lib/oeqa/selftest/cases/archiver.py
+++ b/meta/lib/oeqa/selftest/cases/archiver.py
@@ -27,7 +27,7 @@ class Archiver(OESelftestTestCase):
self.write_config(features)
bitbake('-c clean %s %s' % (include_recipe, exclude_recipe))
-bitbake("%s %s" % (include_recipe, exclude_recipe))
+bitbake("-c deploy_archives %s %s" % (include_recipe, exclude_recipe))
bb_vars = get_bb_vars(['DEPLOY_DIR_SRC', 'TARGET_SYS'])
src_path = os.path.join(bb_vars['DEPLOY_DIR_SRC'],
bb_vars['TARGET_SYS'])
--
2.11.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 3/3] copyleft_filter.bbclass: restore possiblity to filter on type
From: André Draszik
Since the changes introduced in ae9102bda398
("copyleft_filter.bbclass: Allow to filter on name"), it is
impossible to filter on the recipe type, all recipes are
treated as though they should be included if the license
matches, irrespective of the COPYLEFT_RECIPE_TYPES
variable.
Fix this.
Signed-off-by: André Draszik
---
meta/classes/copyleft_filter.bbclass | 32
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/meta/classes/copyleft_filter.bbclass
b/meta/classes/copyleft_filter.bbclass
index 5867bb9f7e..c36bce431a 100644
--- a/meta/classes/copyleft_filter.bbclass
+++ b/meta/classes/copyleft_filter.bbclass
@@ -47,27 +47,27 @@ def copyleft_should_include(d):
import oe.license
from fnmatch import fnmatchcase as fnmatch
-included, motive = False, 'recipe did not match anything'
-
recipe_type = d.getVar('COPYLEFT_RECIPE_TYPE')
if recipe_type not in oe.data.typed_value('COPYLEFT_RECIPE_TYPES', d):
-include, motive = False, 'recipe type "%s" is excluded' % recipe_type
+included, motive = False, 'recipe type "%s" is excluded' % recipe_type
+else:
+included, motive = False, 'recipe did not match anything'
-include = oe.data.typed_value('COPYLEFT_LICENSE_INCLUDE', d)
-exclude = oe.data.typed_value('COPYLEFT_LICENSE_EXCLUDE', d)
+include = oe.data.typed_value('COPYLEFT_LICENSE_INCLUDE', d)
+exclude = oe.data.typed_value('COPYLEFT_LICENSE_EXCLUDE', d)
-try:
-is_included, reason = oe.license.is_included(d.getVar('LICENSE'),
include, exclude)
-except oe.license.LicenseError as exc:
-bb.fatal('%s: %s' % (d.getVar('PF'), exc))
-else:
-if is_included:
-if reason:
-included, motive = True, 'recipe has included licenses: %s' %
', '.join(reason)
-else:
-included, motive = False, 'recipe does not include a copyleft
license'
+try:
+is_included, reason = oe.license.is_included(d.getVar('LICENSE'),
include, exclude)
+except oe.license.LicenseError as exc:
+bb.fatal('%s: %s' % (d.getVar('PF'), exc))
else:
-included, motive = False, 'recipe has excluded licenses: %s' % ',
'.join(reason)
+if is_included:
+if reason:
+included, motive = True, 'recipe has included licenses:
%s' % ', '.join(reason)
+else:
+included, motive = False, 'recipe does not include a
copyleft license'
+else:
+included, motive = False, 'recipe has excluded licenses: %s' %
', '.join(reason)
if any(fnmatch(d.getVar('PN'), name) \
for name in oe.data.typed_value('COPYLEFT_PN_INCLUDE', d)):
--
2.11.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/3] selftest/archiver: add tests for recipe type filtering
On Fri, 2017-06-23 at 15:59 +0100, André Draszik wrote:
> From: André Draszik
>
> The archiver used to be able to filter based on COPYLEFT_RECIPE_TYPES.
>
> Unfortunately, this got broken with the fix for
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=6929
> in commit ae9102bda398 ("copyleft_filter.bbclass: Allow to filter on name")
>
> Add two tests to prevent that from happening again.
>
> Signed-off-by: André Draszik
> ---
> meta/lib/oeqa/selftest/cases/archiver.py | 78
>
> 1 file changed, 78 insertions(+)
>
> diff --git a/meta/lib/oeqa/selftest/cases/archiver.py
> b/meta/lib/oeqa/selftest/cases/archiver.py
> index 70c7282f22..9f686debe6 100644
> --- a/meta/lib/oeqa/selftest/cases/archiver.py
> +++ b/meta/lib/oeqa/selftest/cases/archiver.py
> @@ -39,3 +39,81 @@ class Archiver(OESelftestTestCase):
> # Check that exclude_recipe was excluded
> excluded_present = len(glob.glob(src_path + '/%s-*' %
> exclude_recipe))
> self.assertFalse(excluded_present, 'Recipe %s was not excluded.' %
> exclude_recipe)
> +
> +
> +@testcase(2012)
I believe the testcase ID is related to testopia, not sure if you
consider this. Usually, the QA team is the one assigning these numbers.
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/3] selftest/archiver: add tests for recipe type filtering
On Fri, 2017-06-23 at 10:15 -0500, Leonardo Sandoval wrote:
> On Fri, 2017-06-23 at 15:59 +0100, André Draszik wrote:
> > From: André Draszik
> >
> > The archiver used to be able to filter based on COPYLEFT_RECIPE_TYPES.
> >
> > Unfortunately, this got broken with the fix for
> > https://bugzilla.yoctoproject.org/show_bug.cgi?id=6929
> > in commit ae9102bda398 ("copyleft_filter.bbclass: Allow to filter on
> > name")
> >
> > Add two tests to prevent that from happening again.
> >
> > Signed-off-by: André Draszik
> > ---
> > meta/lib/oeqa/selftest/cases/archiver.py | 78
> >
> > 1 file changed, 78 insertions(+)
> >
> > diff --git a/meta/lib/oeqa/selftest/cases/archiver.py
> > b/meta/lib/oeqa/selftest/cases/archiver.py
> > index 70c7282f22..9f686debe6 100644
> > --- a/meta/lib/oeqa/selftest/cases/archiver.py
> > +++ b/meta/lib/oeqa/selftest/cases/archiver.py
> > @@ -39,3 +39,81 @@ class Archiver(OESelftestTestCase):
> > # Check that exclude_recipe was excluded
> > excluded_present = len(glob.glob(src_path + '/%s-*' %
> > exclude_recipe))
> > self.assertFalse(excluded_present, 'Recipe %s was not
> > excluded.' % exclude_recipe)
> > +
> > +
> > +@testcase(2012)
>
> I believe the testcase ID is related to testopia, not sure if you
> consider this. Usually, the QA team is the one assigning these numbers.
No, I just picked the next available number :-)
A.
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/3] selftest/archiver: add tests for recipe type filtering
On Fri, 2017-06-23 at 16:07 +0100, André Draszik wrote:
> On Fri, 2017-06-23 at 10:15 -0500, Leonardo Sandoval wrote:
> > On Fri, 2017-06-23 at 15:59 +0100, André Draszik wrote:
> > > From: André Draszik
> > >
> > > The archiver used to be able to filter based on COPYLEFT_RECIPE_TYPES.
> > >
> > > Unfortunately, this got broken with the fix for
> > > https://bugzilla.yoctoproject.org/show_bug.cgi?id=6929
> > > in commit ae9102bda398 ("copyleft_filter.bbclass: Allow to filter on
> > > name")
> > >
> > > Add two tests to prevent that from happening again.
> > >
> > > Signed-off-by: André Draszik
> > > ---
> > > meta/lib/oeqa/selftest/cases/archiver.py | 78
> > >
> > > 1 file changed, 78 insertions(+)
> > >
> > > diff --git a/meta/lib/oeqa/selftest/cases/archiver.py
> > > b/meta/lib/oeqa/selftest/cases/archiver.py
> > > index 70c7282f22..9f686debe6 100644
> > > --- a/meta/lib/oeqa/selftest/cases/archiver.py
> > > +++ b/meta/lib/oeqa/selftest/cases/archiver.py
> > > @@ -39,3 +39,81 @@ class Archiver(OESelftestTestCase):
> > > # Check that exclude_recipe was excluded
> > > excluded_present = len(glob.glob(src_path + '/%s-*' %
> > > exclude_recipe))
> > > self.assertFalse(excluded_present, 'Recipe %s was not
> > > excluded.' % exclude_recipe)
> > > +
> > > +
> > > +@testcase(2012)
> >
> > I believe the testcase ID is related to testopia, not sure if you
> > consider this. Usually, the QA team is the one assigning these numbers.
>
> No, I just picked the next available number :-)
so please send a v2 removing these. archive tests are welcome!
>
> A.
>
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] meta: Fix malformed Upstream-Status tags
Fix a variety of spelling and format mistakes to improve the ease of reading the tags programatically. Signed-off-by: Ross Burton --- .../openssh/fix-potential-signed-overflow-in-pointer-arithmatic.patch | 2 +- .../glibc/glibc/0027-locale-fix-hard-coded-reference-to-gcc-E.patch | 2 +- meta/recipes-core/libxml/libxml2/libxml2-CVE-2016-4658.patch | 2 +- .../recipes-core/libxml/libxml2/libxml2-fix_NULL_pointer_derefs.patch | 3 +-- meta/recipes-core/libxml/libxml2/libxml2-fix_node_comparison.patch| 4 ++-- meta/recipes-devtools/apt/apt/0001-apt-1.2.12-Fix-musl-build.patch| 2 +- .../0047-libgcc_s-Use-alias-for-__cpu_indicator_init-instead-.patch | 2 +- .../0001-Configure-Remove-fstack-protector-strong-for-native-.patch | 2 +- meta/recipes-extended/acpica/acpitests/aapits-linux.patch | 2 +- meta/recipes-extended/acpica/acpitests/aapits-makefile.patch | 2 +- .../Makefile-Do-not-fail-if-CONFIG_TRACEPOINTS-is-not-en.patch| 2 +- .../0001-correct-error-which-appeared-when-compiling-non-c-co.patch | 2 +- .../rng-tools/rng-tools/rng-tools-5-fix-textrels-on-PIC-x86.patch | 1 - 13 files changed, 13 insertions(+), 15 deletions(-) diff --git a/meta/recipes-connectivity/openssh/openssh/fix-potential-signed-overflow-in-pointer-arithmatic.patch b/meta/recipes-connectivity/openssh/openssh/fix-potential-signed-overflow-in-pointer-arithmatic.patch index df64a140d32..7e043a2db19 100644 --- a/meta/recipes-connectivity/openssh/openssh/fix-potential-signed-overflow-in-pointer-arithmatic.patch +++ b/meta/recipes-connectivity/openssh/openssh/fix-potential-signed-overflow-in-pointer-arithmatic.patch @@ -8,7 +8,7 @@ type, so that 's - src' in strlcpy and others may trigger signed overflow. In case of compilation by gcc or clang with -ftrapv option, the overflow would lead to program abort. -Upstream-status: Submitted [http://bugzilla.mindrot.org/show_bug.cgi?id=2608] +Upstream-Status: Submitted [http://bugzilla.mindrot.org/show_bug.cgi?id=2608] Signed-off-by: Yuanjie Huang --- diff --git a/meta/recipes-core/glibc/glibc/0027-locale-fix-hard-coded-reference-to-gcc-E.patch b/meta/recipes-core/glibc/glibc/0027-locale-fix-hard-coded-reference-to-gcc-E.patch index 71c0bdcaea5..bce90557cfb 100644 --- a/meta/recipes-core/glibc/glibc/0027-locale-fix-hard-coded-reference-to-gcc-E.patch +++ b/meta/recipes-core/glibc/glibc/0027-locale-fix-hard-coded-reference-to-gcc-E.patch @@ -17,7 +17,7 @@ environment. This patch replaces the hard-coded reference to the gcc binary with the proper environment variable, thus allowing a user to override it. -Upstream-Status : Submitted [https://sourceware.org/ml/libc-alpha/2016-08/msg00746.html] +Upstream-Status: Submitted [https://sourceware.org/ml/libc-alpha/2016-08/msg00746.html] --- locale/gen-translit.pl | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-core/libxml/libxml2/libxml2-CVE-2016-4658.patch b/meta/recipes-core/libxml/libxml2/libxml2-CVE-2016-4658.patch index 5412e8c02ab..bb55eed171f 100644 --- a/meta/recipes-core/libxml/libxml2/libxml2-CVE-2016-4658.patch +++ b/meta/recipes-core/libxml/libxml2/libxml2-CVE-2016-4658.patch @@ -8,7 +8,7 @@ Namespace nodes must be copied to avoid use-after-free errors. But they don't necessarily have a physical representation in a document, so simply disallow them in XPointer ranges. -Upstream-Status: Backported +Upstream-Status: Backport - [https://git.gnome.org/browse/libxml2/commit/?id=c1d1f7121194036608bf555f08d3062a36fd344b] - [https://git.gnome.org/browse/libxml2/commit/?id=3f8a91036d338e51c059d54397a42d645f019c65] CVE: CVE-2016-4658 diff --git a/meta/recipes-core/libxml/libxml2/libxml2-fix_NULL_pointer_derefs.patch b/meta/recipes-core/libxml/libxml2/libxml2-fix_NULL_pointer_derefs.patch index 83552ca3ecf..c60e32f6561 100644 --- a/meta/recipes-core/libxml/libxml2/libxml2-fix_NULL_pointer_derefs.patch +++ b/meta/recipes-core/libxml/libxml2/libxml2-fix_NULL_pointer_derefs.patch @@ -2,8 +2,7 @@ libxml2-2.9.4: Fix more NULL pointer derefs xpointer: Fix more NULL pointer derefs -Upstream-Status: Backported [https://git.gnome.org/browse/libxml2/commit/?id=e905f08123e4a6e7731549e6f09dadff4cab65bd] -CVE: - +Upstream-Status: Backport [https://git.gnome.org/browse/libxml2/commit/?id=e905f08123e4a6e7731549e6f09dadff4cab65bd] Signed-off-by: Andrej Valek Signed-off-by: Pascal Bach diff --git a/meta/recipes-core/libxml/libxml2/libxml2-fix_node_comparison.patch b/meta/recipes-core/libxml/libxml2/libxml2-fix_node_comparison.patch index 11718bb2bdf..65f6bef1e69 100644 --- a/meta/recipes-core/libxml/libxml2/libxml2-fix_node_comparison.patch +++ b/meta/recipes-core/libxml/libxml2/libxml2-fix_node_comparison.patch @@ -5,10 +5,10 @@ xpath: - Add sanity check for empty stack. - Include comparation in changes from xmlXPathCmpNodesExt to xmlXPathCmpNodes -Upstream-Status: Backported +Upstream-Status: Backport - [https://
Re: [OE-core] [PATCH] meta: Fix malformed Upstream-Status tags
On Fri, Jun 23, 2017 at 04:45:44PM +0100, Ross Burton wrote: > Fix a variety of spelling and format mistakes to improve the ease of reading > the > tags programatically. > > Signed-off-by: Ross Burton > --- > .../openssh/fix-potential-signed-overflow-in-pointer-arithmatic.patch | 2 +- > .../glibc/glibc/0027-locale-fix-hard-coded-reference-to-gcc-E.patch | 2 +- > meta/recipes-core/libxml/libxml2/libxml2-CVE-2016-4658.patch | 2 +- > .../recipes-core/libxml/libxml2/libxml2-fix_NULL_pointer_derefs.patch | 3 +-- > meta/recipes-core/libxml/libxml2/libxml2-fix_node_comparison.patch| 4 > ++-- > meta/recipes-devtools/apt/apt/0001-apt-1.2.12-Fix-musl-build.patch| 2 +- > .../0047-libgcc_s-Use-alias-for-__cpu_indicator_init-instead-.patch | 2 +- > .../0001-Configure-Remove-fstack-protector-strong-for-native-.patch | 2 +- > meta/recipes-extended/acpica/acpitests/aapits-linux.patch | 2 +- > meta/recipes-extended/acpica/acpitests/aapits-makefile.patch | 2 +- > .../Makefile-Do-not-fail-if-CONFIG_TRACEPOINTS-is-not-en.patch| 2 +- > .../0001-correct-error-which-appeared-when-compiling-non-c-co.patch | 2 +- > .../rng-tools/rng-tools/rng-tools-5-fix-textrels-on-PIC-x86.patch | 1 - > 13 files changed, 13 insertions(+), 15 deletions(-) > > diff --git > a/meta/recipes-connectivity/openssh/openssh/fix-potential-signed-overflow-in-pointer-arithmatic.patch > > b/meta/recipes-connectivity/openssh/openssh/fix-potential-signed-overflow-in-pointer-arithmatic.patch > index df64a140d32..7e043a2db19 100644 > --- > a/meta/recipes-connectivity/openssh/openssh/fix-potential-signed-overflow-in-pointer-arithmatic.patch > +++ > b/meta/recipes-connectivity/openssh/openssh/fix-potential-signed-overflow-in-pointer-arithmatic.patch > @@ -8,7 +8,7 @@ type, so that 's - src' in strlcpy and others may trigger > signed overflow. > In case of compilation by gcc or clang with -ftrapv option, the overflow > would lead to program abort. > > -Upstream-status: Submitted [http://bugzilla.mindrot.org/show_bug.cgi?id=2608] > +Upstream-Status: Submitted [http://bugzilla.mindrot.org/show_bug.cgi?id=2608] > > Signed-off-by: Yuanjie Huang > --- > diff --git > a/meta/recipes-core/glibc/glibc/0027-locale-fix-hard-coded-reference-to-gcc-E.patch > > b/meta/recipes-core/glibc/glibc/0027-locale-fix-hard-coded-reference-to-gcc-E.patch > index 71c0bdcaea5..bce90557cfb 100644 > --- > a/meta/recipes-core/glibc/glibc/0027-locale-fix-hard-coded-reference-to-gcc-E.patch > +++ > b/meta/recipes-core/glibc/glibc/0027-locale-fix-hard-coded-reference-to-gcc-E.patch > @@ -17,7 +17,7 @@ environment. > This patch replaces the hard-coded reference to the gcc binary with the > proper > environment variable, thus allowing a user to override it. > > -Upstream-Status : Submitted > [https://sourceware.org/ml/libc-alpha/2016-08/msg00746.html] > +Upstream-Status: Submitted > [https://sourceware.org/ml/libc-alpha/2016-08/msg00746.html] > --- > locale/gen-translit.pl | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > diff --git a/meta/recipes-core/libxml/libxml2/libxml2-CVE-2016-4658.patch > b/meta/recipes-core/libxml/libxml2/libxml2-CVE-2016-4658.patch > index 5412e8c02ab..bb55eed171f 100644 > --- a/meta/recipes-core/libxml/libxml2/libxml2-CVE-2016-4658.patch > +++ b/meta/recipes-core/libxml/libxml2/libxml2-CVE-2016-4658.patch > @@ -8,7 +8,7 @@ Namespace nodes must be copied to avoid use-after-free errors. > But they don't necessarily have a physical representation in a > document, so simply disallow them in XPointer ranges. > > -Upstream-Status: Backported > +Upstream-Status: Backport > - > [https://git.gnome.org/browse/libxml2/commit/?id=c1d1f7121194036608bf555f08d3062a36fd344b] > - > [https://git.gnome.org/browse/libxml2/commit/?id=3f8a91036d338e51c059d54397a42d645f019c65] > CVE: CVE-2016-4658 > diff --git > a/meta/recipes-core/libxml/libxml2/libxml2-fix_NULL_pointer_derefs.patch > b/meta/recipes-core/libxml/libxml2/libxml2-fix_NULL_pointer_derefs.patch > index 83552ca3ecf..c60e32f6561 100644 > --- a/meta/recipes-core/libxml/libxml2/libxml2-fix_NULL_pointer_derefs.patch > +++ b/meta/recipes-core/libxml/libxml2/libxml2-fix_NULL_pointer_derefs.patch > @@ -2,8 +2,7 @@ libxml2-2.9.4: Fix more NULL pointer derefs > > xpointer: Fix more NULL pointer derefs > > -Upstream-Status: Backported > [https://git.gnome.org/browse/libxml2/commit/?id=e905f08123e4a6e7731549e6f09dadff4cab65bd] > -CVE: - > +Upstream-Status: Backport > [https://git.gnome.org/browse/libxml2/commit/?id=e905f08123e4a6e7731549e6f09dadff4cab65bd] > Signed-off-by: Andrej Valek > Signed-off-by: Pascal Bach > > diff --git > a/meta/recipes-core/libxml/libxml2/libxml2-fix_node_comparison.patch > b/meta/recipes-core/libxml/libxml2/libxml2-fix_node_comparison.patch > index 11718bb2bdf..65f6bef1e69 100644 > --- a/meta/recipes-core/libxml/libxml2/libxml2-fix_node_comparison.patch > +++ b/meta/recipes-
Re: [OE-core] [PATCH] meta: Fix malformed Upstream-Status tags
On 23 June 2017 at 17:19, Denys Dmytriyenko wrote: > > -Upstream-status: Not sent yet > > Should this one be "Pending" instead? > There's another upstream-status tag in that patch, this was deleting the duplicate. Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] libinput: upgrade to 1.7.3
Ping.
On Mon, Jun 19, 2017 at 01:30:08PM -0400, Denys Dmytriyenko wrote:
> From: Denys Dmytriyenko
>
> Signed-off-by: Denys Dmytriyenko
> ---
> .../recipes-graphics/wayland/{libinput_1.6.1.bb => libinput_1.7.3.bb} | 4
> ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
> rename meta/recipes-graphics/wayland/{libinput_1.6.1.bb =>
> libinput_1.7.3.bb} (85%)
>
> diff --git a/meta/recipes-graphics/wayland/libinput_1.6.1.bb
> b/meta/recipes-graphics/wayland/libinput_1.7.3.bb
> similarity index 85%
> rename from meta/recipes-graphics/wayland/libinput_1.6.1.bb
> rename to meta/recipes-graphics/wayland/libinput_1.7.3.bb
> index c8714f2..6194fba 100644
> --- a/meta/recipes-graphics/wayland/libinput_1.6.1.bb
> +++ b/meta/recipes-graphics/wayland/libinput_1.7.3.bb
> @@ -10,8 +10,8 @@ DEPENDS = "libevdev udev mtdev"
> SRC_URI = "http://www.freedesktop.org/software/${BPN}/${BP}.tar.xz \
>
> file://touchpad-serial-synaptics-need-to-fake-new-touches-on-TRIPLETAP.patch \
> "
> -SRC_URI[md5sum] = "7e282344f8ed7ec5cf87ca9fc22674fb"
> -SRC_URI[sha256sum] =
> "9d816f13eee63bcca0e9c3bb652c52ab55f39be4d1b90b54e4bfd1dc92ef55a8"
> +SRC_URI[md5sum] = "f2993b477db8d7ec0e785ce04ffecb03"
> +SRC_URI[sha256sum] =
> "096d612d2711f0caa2de544976ff3729e6233511ab373808644cc2dd5affcb1d"
>
> inherit autotools pkgconfig
>
> --
> 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] toolchain-scripts: add check for LD_LIBRARY_PATH in the SDK env setup script
Ping.
On Thu, Jun 15, 2017 at 03:09:49PM -0400, Denys Dmytriyenko wrote:
> From: Denys Dmytriyenko
>
> Provide a descriptive error message and exit the environment-setup script,
> when LD_LIBRARY_PATH is set on the host system.
>
> Signed-off-by: Denys Dmytriyenko
> ---
> meta/classes/toolchain-scripts.bbclass | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/meta/classes/toolchain-scripts.bbclass
> b/meta/classes/toolchain-scripts.bbclass
> index 260ece9..ef7b26f 100644
> --- a/meta/classes/toolchain-scripts.bbclass
> +++ b/meta/classes/toolchain-scripts.bbclass
> @@ -25,6 +25,21 @@ toolchain_create_sdk_env_script () {
>
> script=${1:-${SDK_OUTPUT}/${SDKPATH}/environment-setup-$multimach_target_sys}
> rm -f $script
> touch $script
> +
> + echo '# Check for LD_LIBRARY_PATH being set, which can break SDK and
> generally is a bad practice' >> $script
> + echo '#
> http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html#AEN80' >>
> $script
> + echo '# http://xahlee.info/UnixResource_dir/_/ldpath.html' >> $script
> + echo '# Only disable this check if you are absolutely know what you are
> doing!' >> $script
> + echo 'if [ ! -z "$LD_LIBRARY_PATH" ]; then' >> $script
> + echo "echo \"Your environment is misconfigured, you probably need
> to 'unset LD_LIBRARY_PATH'\"" >> $script
> + echo "echo \"but please check why this was set in the first place
> and that it's safe to unset.\"" >> $script
> + echo 'echo "The SDK will not operate correctly in most cases when
> LD_LIBRARY_PATH is set."' >> $script
> + echo 'echo "For more references see:"' >> $script
> + echo 'echo "
> http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html#AEN80";' >>
> $script
> + echo 'echo " http://xahlee.info/UnixResource_dir/_/ldpath.html";'
> >> $script
> + echo 'return 1' >> $script
> + echo 'fi' >> $script
> +
> echo 'export SDKTARGETSYSROOT='"$sysroot" >> $script
> EXTRAPATH=""
> for i in ${CANADIANEXTRAOS}; do
> --
> 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] v86d, qemuboot-x86.inc: use KERNEL_MODULE_AUTOLOAD+KERNEL_MODULE_PROBECONF for uvesafb instead of fbsetup init script
ping
On Thu, Apr 27, 2017 at 11:49 PM, Martin Jansa
wrote:
> * also add UVESA_MODE variable for easier change of resolution and respect
> it in QB_KERNEL_CMDLINE_APPEND
> as well
> * don't use init script just to call modprobe
> * I wasn't able to test this all the way with runqemu, because runqemu
> doesn't work on my system, but I've verified that the right params
> appear there and that I can easily change UVESA_MODE from
> conf/local.conf, the modules.d and modprobe.d files look OK:
> OE qemux86@ ~/build/oe-core/tmp-glibc/deploy/images/qemux86/core-
> image-sato-qemux86-20170427212613.rootfs
> $ cat etc/modules-load.d/uvesafb.conf
> uvesafb
>
> OE qemux86@ ~/build/oe-core/tmp-glibc/deploy/images/qemux86/core-
> image-sato-qemux86-20170427212613.rootfs
> $ cat etc/modprobe.d/uvesafb.conf
> options uvesafb mode_option=1600x1200-32
>
> so I'll be able to drop this KERNEL_MODULE_AUTOLOAD +
> KERNEL_MODULE_PROBECONF from my DISTRO conf.
>
> Signed-off-by: Martin Jansa
> ---
> meta/conf/machine/include/qemuboot-x86.inc | 7 +-
> meta/recipes-bsp/v86d/v86d/fbsetup | 3 ---
> meta/recipes-bsp/v86d/v86d/uvesafb.conf| 2 --
> meta/recipes-bsp/v86d/v86d_0.1.10.bb | 36
> --
> 4 files changed, 6 insertions(+), 42 deletions(-)
> delete mode 100755 meta/recipes-bsp/v86d/v86d/fbsetup
> delete mode 100644 meta/recipes-bsp/v86d/v86d/uvesafb.conf
>
> diff --git a/meta/conf/machine/include/qemuboot-x86.inc
> b/meta/conf/machine/include/qemuboot-x86.inc
> index 06ac983d4d..18f755a5d0 100644
> --- a/meta/conf/machine/include/qemuboot-x86.inc
> +++ b/meta/conf/machine/include/qemuboot-x86.inc
> @@ -10,6 +10,11 @@ QB_CPU_KVM_x86-64 = "-cpu kvm64"
>
> QB_AUDIO_DRV = "alsa"
> QB_AUDIO_OPT = "-soundhw ac97,es1370"
> -QB_KERNEL_CMDLINE_APPEND = "vga=0 uvesafb.mode_option=640x480-32
> oprofile.timer=1 uvesafb.task_timeout=-1"
> +QB_KERNEL_CMDLINE_APPEND = "vga=0 uvesafb.mode_option=${UVESA_MODE}
> oprofile.timer=1 uvesafb.task_timeout=-1"
> # Add the 'virtio-rng-pci' device otherwise the guest may run out of
> entropy
> QB_OPT_APPEND = "-vga vmware -show-cursor -usb -usbdevice tablet -device
> virtio-rng-pci"
> +
> +KERNEL_MODULE_AUTOLOAD += "uvesafb"
> +KERNEL_MODULE_PROBECONF += "uvesafb"
> +UVESA_MODE ?= "640x480-32"
> +module_conf_uvesafb = "options uvesafb mode_option=${UVESA_MODE}"
> diff --git a/meta/recipes-bsp/v86d/v86d/fbsetup
> b/meta/recipes-bsp/v86d/v86d/fbsetup
> deleted file mode 100755
> index 2a409cc529..00
> --- a/meta/recipes-bsp/v86d/v86d/fbsetup
> +++ /dev/null
> @@ -1,3 +0,0 @@
> -#!/bin/sh
> -
> -/sbin/modprobe uvesafb
> diff --git a/meta/recipes-bsp/v86d/v86d/uvesafb.conf
> b/meta/recipes-bsp/v86d/v86d/uvesafb.conf
> deleted file mode 100644
> index 43789755d3..00
> --- a/meta/recipes-bsp/v86d/v86d/uvesafb.conf
> +++ /dev/null
> @@ -1,2 +0,0 @@
> -# Load uvesafb.ko at boot
> -uvesafb
> diff --git a/meta/recipes-bsp/v86d/v86d_0.1.10.bb b/meta/recipes-bsp/v86d/
> v86d_0.1.10.bb
> index eab466d30d..579a0a27eb 100644
> --- a/meta/recipes-bsp/v86d/v86d_0.1.10.bb
> +++ b/meta/recipes-bsp/v86d/v86d_0.1.10.bb
> @@ -11,8 +11,6 @@ PR = "r2"
>
> SRC_URI = "http://distfiles.gentoo.org/distfiles/${BP}.tar.bz2 \
> file://Update-x86emu-from-X.org.patch \
> - file://fbsetup \
> - file://uvesafb.conf \
> file://ar-from-env.patch \
> file://aarch64-host.patch \
> "
> @@ -23,9 +21,6 @@ SRC_URI[sha256sum] = "634964ae18ef68c8493add2ce150e3
> b4502badeb0d9194b4bd81241d25
> PACKAGE_ARCH = "${MACHINE_ARCH}"
> COMPATIBLE_HOST = '(i.86|x86_64).*-linux'
>
> -INITSCRIPT_NAME = "fbsetup"
> -INITSCRIPT_PARAMS = "start 0 S ."
> -
> do_configure () {
> ./configure --with-x86emu
> }
> @@ -37,35 +32,4 @@ do_compile () {
> do_install () {
> install -d ${D}${base_sbindir}
> install v86d ${D}${base_sbindir}/
> -
> -# Only install fbsetup script if 'sysvinit' is in DISTRO_FEATURES
> -if
> ${@bb.utils.contains('DISTRO_FEATURES','sysvinit','true','false',d)};
> then
> -install -d ${D}${sysconfdir}/init.d/
> -install -m 0755 ${WORKDIR}/fbsetup ${D}${sysconfdir}/init.d/
> fbsetup
> -fi
> -
> -# Install systemd related configuration file
> -if
> ${@bb.utils.contains('DISTRO_FEATURES','systemd','true','false',d)};
> then
> -install -d ${D}${sysconfdir}/modules-load.d
> -install -m 0644 ${WORKDIR}/uvesafb.conf
> ${D}${sysconfdir}/modules-load.d
> -fi
> -}
> -
> -# As the recipe doesn't inherit systemd.bbclass, we need to set this
> variable
> -# manually to avoid unnecessary postinst/preinst generated.
> -python __anonymous() {
> -if not bb.utils.contains('DISTRO_FEATURES', 'sysvinit', True, False,
> d):
> -d.setVar("INHIBIT_UPDATERCD_BBCLASS", "1")
> -}
> -
> -inherit update-rc.d
> -
> -PACKAGE_WRITE_DEPS_append = " ${@bb.utils.contains('DISTRO_
> FEATUR
Re: [OE-core] [PATCH] libinput: upgrade to 1.7.3
This has been in staging for a few days, will be merged soon.
Ross
On 23 June 2017 at 18:31, Denys Dmytriyenko wrote:
> Ping.
>
> On Mon, Jun 19, 2017 at 01:30:08PM -0400, Denys Dmytriyenko wrote:
> > From: Denys Dmytriyenko
> >
> > Signed-off-by: Denys Dmytriyenko
> > ---
> > .../recipes-graphics/wayland/{libinput_1.6.1.bb => libinput_1.7.3.bb}
> | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> > rename meta/recipes-graphics/wayland/{libinput_1.6.1.bb =>
> libinput_1.7.3.bb} (85%)
> >
> > diff --git a/meta/recipes-graphics/wayland/libinput_1.6.1.bb
> b/meta/recipes-graphics/wayland/libinput_1.7.3.bb
> > similarity index 85%
> > rename from meta/recipes-graphics/wayland/libinput_1.6.1.bb
> > rename to meta/recipes-graphics/wayland/libinput_1.7.3.bb
> > index c8714f2..6194fba 100644
> > --- a/meta/recipes-graphics/wayland/libinput_1.6.1.bb
> > +++ b/meta/recipes-graphics/wayland/libinput_1.7.3.bb
> > @@ -10,8 +10,8 @@ DEPENDS = "libevdev udev mtdev"
> > SRC_URI = "http://www.freedesktop.org/software/${BPN}/${BP}.tar.xz \
> >
> > file://touchpad-serial-synaptics-need-to-fake-new-touches-on-TRIPLETAP.patch
> \
> > "
> > -SRC_URI[md5sum] = "7e282344f8ed7ec5cf87ca9fc22674fb"
> > -SRC_URI[sha256sum] = "9d816f13eee63bcca0e9c3bb652c52
> ab55f39be4d1b90b54e4bfd1dc92ef55a8"
> > +SRC_URI[md5sum] = "f2993b477db8d7ec0e785ce04ffecb03"
> > +SRC_URI[sha256sum] = "096d612d2711f0caa2de544976ff37
> 29e6233511ab373808644cc2dd5affcb1d"
> >
> > inherit autotools pkgconfig
> >
> > --
> > 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
>
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] wic: remove extra double-quote on documentation string
Signed-off-by: Jean-Francois Dagenais --- scripts/lib/wic/ksparser.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/lib/wic/ksparser.py b/scripts/lib/wic/ksparser.py index d026caa..47afda4 100644 --- a/scripts/lib/wic/ksparser.py +++ b/scripts/lib/wic/ksparser.py @@ -114,7 +114,7 @@ def systemidtype(arg): return arg class KickStart(): -Kickstart parser implementation.""" +"""Kickstart parser implementation.""" DEFAULT_EXTRA_SPACE = 10*1024 DEFAULT_OVERHEAD_FACTOR = 1.3 -- 2.1.4 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] devtool: Adds the kernel-menuconfig plugin to devtool
From: Juan M Cruz Alcaraz
The kernel-menuconfig target allows devtool to checkout the linux kernel
configured in
the extensible SDK environment, to apply the required patches and the kernel
configuration
snippets.
After that it executes the menuconfig make target to allow the user to
configure the
kernel as needed. The .config configuration file is stored in the eSDK
workspace along
with the linux kernel source.
This commit was based in this original implementation:
https://github.com/ostroproject/meta-ostro/blob/master/meta-ostro/lib/devtool/kconfig.py
https://bugzilla.yoctoproject.org/show_bug.cgi?id=10416
[YOCTO #10416]
Signed-off-by: Juan M Cruz Alcaraz
---
scripts/lib/devtool/kconfig.py | 188
scripts/lib/devtool/standard.py | 45 +-
2 files changed, 211 insertions(+), 22 deletions(-)
create mode 100644 scripts/lib/devtool/kconfig.py
diff --git a/scripts/lib/devtool/kconfig.py b/scripts/lib/devtool/kconfig.py
new file mode 100644
index 00..e8e0a38527
--- /dev/null
+++ b/scripts/lib/devtool/kconfig.py
@@ -0,0 +1,188 @@
+# Development tool - kernel command plugin
+#
+# Copyright (C) 2017 Intel Corporation
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License version 2 as
+# published by the Free Software Foundation.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License along
+# with this program; if not, write to the Free Software Foundation, Inc.,
+# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+
+"""Devtool plugin containing the kernel subcommands"""
+
+import os
+import logging
+import glob
+import scriptutils
+import shutil
+from devtool import standard
+from devtool import exec_build_env_command
+from devtool import setup_git_repo, recipe_to_append
+from devtool import setup_tinfoil, parse_recipe, DevtoolError
+from bb.process import ExecutionError
+
+logger = logging.getLogger('devtool')
+
+def kernel_menuconfig(args, config, basepath, workspace):
+"""Entry point for the devtool 'kernel-menuconfig' subcommand"""
+
+tinfoil = setup_tinfoil(basepath=basepath)
+pn = None
+bpath = None
+
+try:
+rd = parse_recipe(config, tinfoil, 'virtual/kernel', appends=True,
filter_workspace=False)
+if not rd:
+return 1
+
+pn = rd.getVar('PN', True)
+bpath = rd.getVar('B', True)
+pntree = os.path.join(config.get('General',
'default_source_parent_dir',
+ config.workspace_path), 'sources', pn)
+
+if pn not in workspace:
+fn = tinfoil.get_recipe_file(pn)
+# We need to do this carefully as the version will change as a
result of do_menuconfig
+ver = rd.expand('${EXTENDPE}${PV}-${PR}')
+taintfn = (rd.getVar('STAMP', True) +
'.do_compile.taint').replace(ver, '*')
+
+tmptree = os.path.join(config.get('General',
'default_source_parent_dir',
+ config.workspace_path), '.temp')
+srctree = os.path.join(tmptree, pn)
+
+crd = rd.createCopy()
+crd.setVar('WORKDIR', srctree)
+crd.setVar('S', '${WORKDIR}/source')
+crd.setVar('B', '${WORKDIR}/${PN}')
+crd.setVar('STAGING_KERNEL_DIR', '${S}')
+crd.setVar('PATCHTOOL', 'git')
+crd.setVar('PATCH_COMMIT_FUNCTIONS', '1')
+
+# Apply our changes to the datastore to the server's datastore
+tinfoil.logger.setLevel(logging.WARNING)
+for key in crd.localkeys():
+tinfoil.config_data.setVar('%s_pn-%s' % (key, pn),
crd.getVar(key, False))
+
+tinfoil.config_data.setVar('STAMPS_DIR', os.path.join(srctree,
'stamps'))
+tinfoil.config_data.setVar('T', os.path.join(srctree, 'temp'))
+tinfoil.config_data.setVar('BUILDCFG_FUNCS', '')
+tinfoil.config_data.setVar('BUILDCFG_HEADER', '')
+tinfoil.config_data.setVar('BB_HASH_IGNORE_MISMATCH', '1')
+tinfoil.set_event_mask(['bb.event.BuildStarted',
+'bb.event.BuildCompleted',
+'logging.LogRecord',
+'bb.command.CommandCompleted',
+'bb.command.CommandFailed',
+'bb.build.TaskStarted',
+'bb.build.TaskSucceeded',
+'bb.build.TaskFailed',
+'bb.build.TaskFailedSilent'])
+
+recipeFile = None
+recipef
[OE-core] ✗ patchtest: failure for wic: remove extra double-quote on documentation string
== Series Details == Series: wic: remove extra double-quote on documentation string Revision: 1 URL : https://patchwork.openembedded.org/series/7446/ 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 cannot be parsed correctly due to malformed diff lines [test_mbox_format] Suggested fixCreate the series again using git-format-patch and ensure it can be applied using git am Diff line * 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 20b3574749) 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] -> ...). --- 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] linux-libc-headers: fix duplicate IFF_LOWER_UP DORMANT ECHO on musl
On Fri, Jun 23, 2017 at 7:17 AM, wrote: > Hi, > > I'm chipping in since I've been messing with these things a bit in upstream > Linux kernel. > > On Fri, Jun 23, 2017 at 06:37:52AM -0700, Khem Raj wrote: >> On Fri, Jun 23, 2017 at 3:46 AM, André Draszik wrote: >> > connman is not doing anything wrong here. >> > >> >> yes I am aware of this >> >> > The kernel is redefining IFF_LOWER_UP, because it thinks the libc doesn't >> > define it yet (and glibc doesn't). >> > >> > libc-compat.h is the way to solve these kind of issues. There also is >> > https: >> > //lkml.org/lkml/2017/3/12/238 which is very similar. I'll pick that >> > instead. >> > >> see the comment https://lkml.org/lkml/2017/3/16/121 >> that worries me for this patch > > I'm aware of those review comments but I have not seen any patches posted > which > fix the problem in some other way. Thus I would propose to apply these patches > as a workaround until upstream fixes the issues. > > These header files do not change that often either. problem is you become incompatible ABI forever that worries me. However if bruce is fine to carry this patch as part of linux-yocto I might relent. It still will be hassle where folks will have to apply this patch to there kernels if they are building musl based systems. > >> I am not questioning the correctness of patch too. But >> it would be better to get this patch accepted into kernel >> before applying to OE since these are kind of patches which >> you can get stuck with for life if upstream is not accepting it. > > Upstream-Status: Denied > > would be a correct marker for now I guess. I would rather see some progress made to get it resolved :) we need to actually remove glibc'ness completely from kernel. and this will fix itself. > > Hope this helps, > > -Mikko -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] pkg-config: allow kernel to be build with esdk
On Fri, 2017-06-23 at 15:47 +0100, Richard Purdie wrote: > On Wed, 2017-06-14 at 07:03 -0700, Saul Wold wrote: > > > > When the kernel's menuconfig target is called while using the esdk > > or > > an esdk-based container, the pkg-config info that is found is not > > correct. > > The pkg-config info is for the target, but we need the eSDK's > > information in order to build the host based menuconfig. > > > > The new pkg-config script checks both that it's in SDK and being > > called from the check-lxdialog script in order to limit the scope > > of > > when the pkg-config automagically switches to pkg-config-native. > > > > This script also replaces the default pkg-config-native script. > > > > [YOCTO #11155] > > > > Signed-off-by: Saul Wold > > --- > > To be honest, I'm scared of adding this kind of complexity to the > system. I appreciate the problem you're trying to solve but I worry > adding this kind of change is complex, invasive and introduces too > much > risk. > > I have some specific worries with this implementation too, in > particular that it changes on target pkg-config, it really should > only > change nativesdk-pkgconfig? If we have risk, we want to minimise that > risk and adding this wrapper everywhere doesn't seem to do that... > There is no nativesdk-pkgconfig, but I had some confusion around the pkg-config-native and it's usage of a pkg-config binary. I was getting some recursion initially and my feeble brain thought it was the target version :-(. I have rebuilt this patch and will send a V2 that ONLY affects the pkg- config-native, basically expands the script to check if it's being called as -native or from the Kernel's check-lxdialog. I am also going to change the script such that it checks it's base name of pkg-config and only then add the parent pid name checking. I hope that will mitigate the risk. Sau! > Cheers, > > Richard > > -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] linux-libc-headers: fix duplicate IFF_LOWER_UP DORMANT ECHO on musl
On Fri, Jun 23, 2017 at 04:20:41PM -0700, Khem Raj wrote: > On Fri, Jun 23, 2017 at 7:17 AM, wrote: > > Hi, > > > > I'm chipping in since I've been messing with these things a bit in upstream > > Linux kernel. > > > > On Fri, Jun 23, 2017 at 06:37:52AM -0700, Khem Raj wrote: > >> On Fri, Jun 23, 2017 at 3:46 AM, André Draszik wrote: > >> > connman is not doing anything wrong here. > >> > > >> > >> yes I am aware of this > >> > >> > The kernel is redefining IFF_LOWER_UP, because it thinks the libc doesn't > >> > define it yet (and glibc doesn't). > >> > > >> > libc-compat.h is the way to solve these kind of issues. There also is > >> > https: > >> > //lkml.org/lkml/2017/3/12/238 which is very similar. I'll pick that > >> > instead. > >> > > >> see the comment https://lkml.org/lkml/2017/3/16/121 > >> that worries me for this patch > > > > I'm aware of those review comments but I have not seen any patches posted > > which > > fix the problem in some other way. Thus I would propose to apply these > > patches > > as a workaround until upstream fixes the issues. > > > > These header files do not change that often either. > > problem is you become incompatible ABI forever that worries me. +1 > However if bruce is fine to carry this patch as part of linux-yocto > I might relent. It still will be hassle where folks will have to apply > this patch to there kernels if they are building musl based systems. Don't forget that not everyone is using linux-yocto kernel! > >> I am not questioning the correctness of patch too. But > >> it would be better to get this patch accepted into kernel > >> before applying to OE since these are kind of patches which > >> you can get stuck with for life if upstream is not accepting it. > > > > Upstream-Status: Denied > > > > would be a correct marker for now I guess. > > I would rather see some progress made to get it resolved :) > we need to actually remove glibc'ness completely from kernel. > and this will fix itself. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] wic: remove extra double-quote on documentation string
Signed-off-by: Jean-Francois Dagenais --- scripts/lib/wic/ksparser.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/lib/wic/ksparser.py b/scripts/lib/wic/ksparser.py index d026caa..47afda4 100644 --- a/scripts/lib/wic/ksparser.py +++ b/scripts/lib/wic/ksparser.py @@ -114,7 +114,7 @@ def systemidtype(arg): return arg class KickStart(): -Kickstart parser implementation.""" +"""Kickstart parser implementation.""" DEFAULT_EXTRA_SPACE = 10*1024 DEFAULT_OVERHEAD_FACTOR = 1.3 -- 2.1.4 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] ✗ patchtest: failure for wic: remove extra double-quote on documentation string (rev2)
== Series Details == Series: wic: remove extra double-quote on documentation string (rev2) Revision: 2 URL : https://patchwork.openembedded.org/series/7446/ 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 20b3574749) 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] -> ...). --- Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2] pkg-config-native: allow kernel to be build with esdk
When the kernel's menuconfig target is called while using the esdk or an
esdk-based container, the pkg-config info that is found is not correct.
The pkg-config info is for the target, but we need the eSDK's information
in order to build the host based menuconfig.
The new pkg-config-native script checks both that it's in SDK and being
called from the check-lxdialog script in order to limit the scope of when
the pkg-config automagically switches to pkg-config-native.
[YOCTO #11155]
Signed-off-by: Saul Wold
---
.../pkgconfig/pkgconfig/pkg-config-native.in | 25 ++
meta/recipes-devtools/pkgconfig/pkgconfig_git.bb | 10 +
2 files changed, 27 insertions(+), 8 deletions(-)
diff --git a/meta/recipes-devtools/pkgconfig/pkgconfig/pkg-config-native.in
b/meta/recipes-devtools/pkgconfig/pkgconfig/pkg-config-native.in
index 5e44bb4..26da5b6 100644
--- a/meta/recipes-devtools/pkgconfig/pkgconfig/pkg-config-native.in
+++ b/meta/recipes-devtools/pkgconfig/pkgconfig/pkg-config-native.in
@@ -1,7 +1,24 @@
#! /bin/sh
-PKG_CONFIG_PATH="@PATH_NATIVE@"
-PKG_CONFIG_LIBDIR="@LIBDIR_NATIVE@"
-unset PKG_CONFIG_SYSROOT_DIR
+# Orignal pkg-config-native action when called as pkg-config-native
+# NO Change here
+if [ "pkg-config-native" = "`basename $0`" ] ; then
+ PKG_CONFIG_PATH="@PATH_NATIVE@"
+ PKG_CONFIG_LIBDIR="@LIBDIR_NATIVE@"
+ unset PKG_CONFIG_SYSROOT_DIR
+else
+ # in this case we are in the esdk
+ if [ "$OE_SKIP_SDK_CHECK" = "1" ] ; then
+ parentpid=`ps -o ppid= -p $$`
+ parentpid_info=`ps -wo comm= -o args= -p $parentpid`
-pkg-config "$@"
+ # check if we are being called from the kernel's make
menuconfig
+ if ( echo $parentpid_info | grep -q check-lxdialog ) ; then
+ PKG_CONFIG_PATH="@PATH_NATIVE@"
+ PKG_CONFIG_LIBDIR="@LIBDIR_NATIVE@"
+ unset PKG_CONFIG_SYSROOT_DIR
+ fi
+ fi
+fi
+
+pkg-config.real "$@"
diff --git a/meta/recipes-devtools/pkgconfig/pkgconfig_git.bb
b/meta/recipes-devtools/pkgconfig/pkgconfig_git.bb
index e634021..37f1f74 100644
--- a/meta/recipes-devtools/pkgconfig/pkgconfig_git.bb
+++ b/meta/recipes-devtools/pkgconfig/pkgconfig_git.bb
@@ -50,8 +50,10 @@ RPROVIDES_${PN} += "pkgconfig(pkg-config)"
# Install a pkg-config-native wrapper that will use the native sysroot instead
# of the MACHINE sysroot, for using pkg-config when building native tools.
do_install_append_class-native () {
-sed -e "s|@PATH_NATIVE@|${PKG_CONFIG_PATH}|" \
--e "s|@LIBDIR_NATIVE@|${PKG_CONFIG_LIBDIR}|" \
-< ${WORKDIR}/pkg-config-native.in > ${B}/pkg-config-native
-install -m755 ${B}/pkg-config-native ${D}${bindir}/pkg-config-native
+ mv ${D}${bindir}/pkg-config ${D}${bindir}/pkg-config.real
+ sed -e "s|@PATH_NATIVE@|${PKG_CONFIG_PATH}|" \
+ -e "s|@LIBDIR_NATIVE@|${PKG_CONFIG_LIBDIR}|" \
+ < ${WORKDIR}/pkg-config-native.in > ${B}/pkg-config-native
+ install -m755 ${B}/pkg-config-native ${D}${bindir}/pkg-config-native
+ ln -s pkg-config-native ${D}${bindir}/pkg-config
}
--
2.7.5
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] linux-libc-headers: fix duplicate IFF_LOWER_UP DORMANT ECHO on musl
On Fri, Jun 23, 2017 at 4:41 PM, Denys Dmytriyenko wrote: > On Fri, Jun 23, 2017 at 04:20:41PM -0700, Khem Raj wrote: >> On Fri, Jun 23, 2017 at 7:17 AM, wrote: >> > Hi, >> > >> > I'm chipping in since I've been messing with these things a bit in upstream >> > Linux kernel. >> > >> > On Fri, Jun 23, 2017 at 06:37:52AM -0700, Khem Raj wrote: >> >> On Fri, Jun 23, 2017 at 3:46 AM, André Draszik wrote: >> >> > connman is not doing anything wrong here. >> >> > >> >> >> >> yes I am aware of this >> >> >> >> > The kernel is redefining IFF_LOWER_UP, because it thinks the libc >> >> > doesn't >> >> > define it yet (and glibc doesn't). >> >> > >> >> > libc-compat.h is the way to solve these kind of issues. There also is >> >> > https: >> >> > //lkml.org/lkml/2017/3/12/238 which is very similar. I'll pick that >> >> > instead. >> >> > >> >> see the comment https://lkml.org/lkml/2017/3/16/121 >> >> that worries me for this patch >> > >> > I'm aware of those review comments but I have not seen any patches posted >> > which >> > fix the problem in some other way. Thus I would propose to apply these >> > patches >> > as a workaround until upstream fixes the issues. >> > >> > These header files do not change that often either. >> >> problem is you become incompatible ABI forever that worries me. > > +1 > >> However if bruce is fine to carry this patch as part of linux-yocto >> I might relent. It still will be hassle where folks will have to apply >> this patch to there kernels if they are building musl based systems. > > Don't forget that not everyone is using linux-yocto kernel! Neither is linux-libc-headers, so getting these musl patches into the linux-yocto kernel isn't going to change much... >> >> I am not questioning the correctness of patch too. But >> >> it would be better to get this patch accepted into kernel >> >> before applying to OE since these are kind of patches which >> >> you can get stuck with for life if upstream is not accepting it. >> > >> > Upstream-Status: Denied >> > >> > would be a correct marker for now I guess. >> >> I would rather see some progress made to get it resolved :) >> we need to actually remove glibc'ness completely from kernel. >> and this will fix itself. > -- > ___ > 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
