Re: [OE-core] [PATCH] systemd: Point to target binary paths for loadkeys and setfont
Acked-by: Luca Boccassi
(please don't send to my microsoft email account, it's absolutely rubbish for
mailing lists and can't use plain text mode)
From: Khem Raj
Sent: 03 August 2023 05:39
To: openembedded-core@lists.openembedded.org
Cc: Khem Raj ; Luca Boccassi
Subject: [PATCH] systemd: Point to target binary paths for loadkeys and setfont
[You don't often get email from raj.k...@gmail.com. Learn why this is important
at https://aka.ms/LearnAboutSenderIdentification ]
with newer systemd, if not specified, these paths are searched on build
host /usr dir
log.do_configure.2373278:Program /usr/sbin/loadkeys found: YES
(/usr/sbin/loadkeys)
log.do_configure.2373278:Program /usr/sbin/setfont found: YES
(/usr/sbin/setfont)
and if build host happens to have kbd installed then it
uses those locations, this would work fine if the assumption between OE
distro and host distro matches but fail otherwise e.g. on archlinux
these binaries are in /usr/sbin but in OE they are in ${base_bindir}
This results in
qemux86-64 systemd-vconsole-setup[211]: /usr/sbin/loadkeys failed with exit
status 1.
Signed-off-by: Khem Raj
Cc: Luca Boccassi
---
meta/recipes-core/systemd/systemd_254.bb | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-core/systemd/systemd_254.bb
b/meta/recipes-core/systemd/systemd_254.bb
index a4cfc7b1f44..653fd6910d3 100644
--- a/meta/recipes-core/systemd/systemd_254.bb
+++ b/meta/recipes-core/systemd/systemd_254.bb
@@ -241,7 +241,9 @@ EXTRA_OEMESON += "-Dnobody-user=nobody \
-Dsystem-gid-max=999 \
"
-# Hardcode target binary paths to avoid using paths from sysroot
+# Hardcode target binary paths to avoid using paths from sysroot or worse
+# it pokes for these binaries on build host and encodes that distro assumption
+# into target
EXTRA_OEMESON += "-Dkexec-path=${sbindir}/kexec \
-Dkmod-path=${base_bindir}/kmod \
-Dmount-path=${base_bindir}/mount \
@@ -249,7 +251,9 @@ EXTRA_OEMESON += "-Dkexec-path=${sbindir}/kexec \
-Dquotaon-path=${sbindir}/quotaon \
-Dsulogin-path=${base_sbindir}/sulogin \
-Dnologin-path=${base_sbindir}/nologin \
- -Dumount-path=${base_bindir}/umount"
+ -Dumount-path=${base_bindir}/umount \
+ -Dloadkeys-path=${base_bindir}/loadkeys \
+ -Dsetfont-path=${base_bindir}/setfont"
# The 60 seconds is watchdog's default vaule.
WATCHDOG_TIMEOUT ??= "60"
--
2.41.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#185468):
https://lists.openembedded.org/g/openembedded-core/message/185468
Mute This Topic: https://lists.openembedded.org/mt/100520616/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH v11] util-linux: split uuid in separate recipe to allow bootstrapping
On Wed, 2021-03-24 at 09:52 -0700, Scott Branden wrote:
> I have not debugged yet, but I suspect this change is causing the following
> failure if I merge the latest poky into our builds:
>
> ERROR: mc:host:util-linux-uuid-2.36.2-r0 do_package: QA Issue:
> util-linux-uuid: Files/directories were installed but not shipped in any
> package:
> /usr/lib/debug
> /usr/lib/debug/usr
> /usr/lib/debug/usr/lib
> /usr/lib/debug/usr/lib/libuuid.so.1.3.0.debug
> Please set FILES such that these items are packaged. Alternatively if they
> are unneeded, avoid installing them or delete them within do_install.
> util-linux-uuid: 4 installed and not shipped files. [installed-vs-shipped]
> ERROR: mc:host:util-linux-uuid-2.36.2-r0 do_package: Fatal QA errors found,
> failing task.
> ERROR: Logfile of failure stored in:
> /hdd/yocto/genx/poky/build/tmp/work/core2-64-poky-linux/util-linux-uuid/2.36.2-r0/temp/log.do_package.31753
> ERROR: Task
> (mc:host:/hdd/yocto/genx/poky/build/../meta/recipes-core/util-linux/util-linux-uuid_2.36.2.bb:do_package)
> failed with exit code '1'
It most certainly is - is /usr/lib/debug configurable or supported?
Currently we have:
FILES_util-linux-libuuid-dbg = "/usr/src ${libdir}/.debug"
I'll send a patch to extend it and include /usr/lib/debug too
> On 2021-03-15 2:51 p.m., Richard Purdie wrote:
> > On Mon, 2021-03-15 at 13:57 +, Richard Purdie via
> > lists.openembedded.org wrote:
> > > On Mon, 2021-03-15 at 14:55 +0100, Martin Jansa wrote:
> > > > On Mon, Mar 15, 2021 at 12:21:37PM +, Richard Purdie wrote:
> > > > > On Mon, 2021-03-15 at 11:50 +, Luca Boccassi wrote:
> > > > > > On Mon, 2021-03-15 at 10:49 +, Richard Purdie wrote:
> > > > > > > On Mon, 2021-03-15 at 10:44 +, Luca Boccassi wrote:
> > > > > > > > On Sun, 2021-03-14 at 22:10 +, Richard Purdie wrote:
> > > > > > > > > On Thu, 2021-03-11 at 15:09 +, luca.bocca...@gmail.com
> > > > > > > > > wrote:
> > > > > > > > > > From: Luca Boccassi
> > > > > > > > > >
> > > > > > > > > > Recently util-linux gained an (optional) build dependency
> > > > > > > > > > on libcryptsetup.
> > > > > > > > > > But libcryptsetup build-depends on util-linux for blkid
> > > > > > > > > > (optional, can be disabled)
> > > > > > > > > > and uuid (mandatory).
> > > > > > > > > > Split out util-linux-uuid in a different recipe to break
> > > > > > > > > > the cycle.
> > > > > > > > > >
> > > > > > > > > > https://github.com/karelzak/util-linux/pull/898
> > > > > > > > > >
> > > > > > > > > > Signed-off-by: Luca Boccassi
> > > > > > > > >
> > > > > > > > > Unfortunately I noticed we had a performance regression in
> > > > > > > > > buildtimes in
> > > > > > > > > recent changes. The closest I have this narrowed down to so
> > > > > > > > > far:
> > > > > > > > >
> > > > > > > > > https://autobuilder.yocto.io/pub/non-release/20210314-14/testresults/buildperf-ubuntu1604/perf-ubuntu1604_master_20210314181831_d42487bf52.html
> > > > > > > > >
> > > > > > > > > suggests it may be this change. I have more tests queued to
> > > > > > > > > confirm
> > > > > > > > > that definitively, if so we'll have to figure out why as this
> > > > > > > > > shouldn't
> > > > > > > > > really happen, its an 8% regression :(.
> > > > > > > >
> > > > > > > > Very strange that a single recipe could do that - is there
> > > > > > > > something
> > > > > > > > wrong in the new .bb that I missed and could cause this?
> > > > > > >
> > > > > > > I'm wondering if it is because we're building util-linux twice
> > > > > > > now and
> > > > > > > there is some key choke point in the dependency chain. I have no
> > > > > > > evidence
> > > > > > > for that yet, it is just speculation though.
> > > &g
Re: [OE-core] [PATCH] systemd: dont spew hidepid mount errors for kernels < v5.8
On Fri, 2021-01-15 at 11:59 -0500, Bruce Ashfield wrote: > On Fri, Jan 15, 2021 at 11:31 AM Luca Boccassi > wrote: > > On Fri, 2021-01-15 at 11:07 -0500, Bruce Ashfield wrote: > > > On Fri, Jan 15, 2021 at 10:37 AM Luca Boccassi via > > > lists.openembedded.org > > > wrote: > > > > On Fri, 2021-01-15 at 09:47 -0500, Paul Gortmaker wrote: > > > > > [Re: [PATCH] systemd: dont spew hidepid mount errors for kernels < > > > > > v5.8] On 15/01/2021 (Fri 09:57) Luca Boccassi wrote: > > > > > > > > > > > On Fri, 2021-01-15 at 08:37 +, Richard Purdie wrote: > > > > > > > On Fri, 2021-01-15 at 00:26 -0500, Paul Gortmaker wrote: > > > > > > > > Recent systemd started using ascii args to "hidepid=" mount > > > > > > > > options > > > > > > > > for proc fs - unconditionally -- even though kernels older than > > > > > > > > v5.8 > > > > > > > > emit an error message on each attempt: > > > > > > > > > > > > > > > > root@qemux86-64:~# cat /proc/version > > > > > > > > Linux version 5.4.87-yocto-standard (oe-user@oe-host) (gcc > > > > > > > > version 10.2.0 (GCC)) #1 SMP PREEMPT Fri Jan 8 01:47:13 UTC 2021 > > > > > > > > root@qemux86-64:~# dmesg|grep proc: > > > > > > > > [ 29.487995] proc: Bad value for 'hidepid' > > > > > > > > [ 43.170571] proc: Bad value for 'hidepid' > > > > > > > > [ 44.175615] proc: Bad value for 'hidepid' > > > > > > > > [ 46.213300] proc: Bad value for 'hidepid' > > > > > > > > root@qemux86-64:~# > > > > > > > > > > > > Wouldn't it be better to patch the kernel to downgrade that message > > > > > > to > > > > > > debug level? > > > > > > > > > > The problem is that the breakage is forced upon older kernels, so > > > > > you'd > > > > > have to effectively mainline that kind of "fix" to v5.12 (where there > > > > > is > > > > > no problem) and then you could in theory request it for v5.4 > > > > > linux-stable > > > > > according to "stable rules". > > > > > > > > The patch could be downstream for older kernels, just like this one is. > > > > With the difference that it would be temporary. > > > > > > But the coverage is impossible, since there are so many > > > different kernel trees. So a kernel solution is a non-starter. > > > > IMHO a long term solution can only go through the kernel. There will be > > more instances like this in the future, given the fundamental issue is > > the lack of a clear EOPNOTSUPP-like interface. I realise the mount > > interface is ancient at this point, and difficult to change. We are > > keeping an eye on the evolution of the new interface, but it's not > > there yet (eg: no read-only bind mounts). > > I don't disagree .. but I'm only commenting on this one older kernel > issue, so there's nothing to see in the new kernels where I spend > 99% of my time. The interfaces in the kernel will absolutely evolve > in the newer kernels, and that's a good thing. > > > > > > Besides, if something with root/mount priv. is consistently trying to > > > > > drive a square peg into a round hole - by trying to mount something > > > > > and > > > > > failing -- it should be something that a sysadmin would want to > > > > > investigate. Which is precisely why I am here now. I think burying > > > > > it > > > > > at debug level is counterproductive to that. > > > > > > > > Well the real issue is that there's no way to get a clean "we don't > > > > support this option" out of certain kernel APIs, so one has to guess > > > > and see what happens. Sometimes it's even worse, and flags like > > > > NOSYMFOLLOW get silently ignored if they are not supported, which is > > > > not great for security-related settings... > > > > > > > > Anyway, these warnings only appear if ProtectProc and/or ProcSubset are > > > > set to something other than the default value. Why not simply add a > > > > top-level drop
Re: [OE-core] [PATCH] systemd: dont spew hidepid mount errors for kernels < v5.8
On Fri, 2021-01-15 at 11:07 -0500, Bruce Ashfield wrote: > On Fri, Jan 15, 2021 at 10:37 AM Luca Boccassi via > lists.openembedded.org > wrote: > > On Fri, 2021-01-15 at 09:47 -0500, Paul Gortmaker wrote: > > > [Re: [PATCH] systemd: dont spew hidepid mount errors for kernels < v5.8] > > > On 15/01/2021 (Fri 09:57) Luca Boccassi wrote: > > > > > > > On Fri, 2021-01-15 at 08:37 +, Richard Purdie wrote: > > > > > On Fri, 2021-01-15 at 00:26 -0500, Paul Gortmaker wrote: > > > > > > Recent systemd started using ascii args to "hidepid=" mount options > > > > > > for proc fs - unconditionally -- even though kernels older than v5.8 > > > > > > emit an error message on each attempt: > > > > > > > > > > > > root@qemux86-64:~# cat /proc/version > > > > > > Linux version 5.4.87-yocto-standard (oe-user@oe-host) (gcc version > > > > > > 10.2.0 (GCC)) #1 SMP PREEMPT Fri Jan 8 01:47:13 UTC 2021 > > > > > > root@qemux86-64:~# dmesg|grep proc: > > > > > > [ 29.487995] proc: Bad value for 'hidepid' > > > > > > [ 43.170571] proc: Bad value for 'hidepid' > > > > > > [ 44.175615] proc: Bad value for 'hidepid' > > > > > > [ 46.213300] proc: Bad value for 'hidepid' > > > > > > root@qemux86-64:~# > > > > > > > > Wouldn't it be better to patch the kernel to downgrade that message to > > > > debug level? > > > > > > The problem is that the breakage is forced upon older kernels, so you'd > > > have to effectively mainline that kind of "fix" to v5.12 (where there is > > > no problem) and then you could in theory request it for v5.4 linux-stable > > > according to "stable rules". > > > > The patch could be downstream for older kernels, just like this one is. > > With the difference that it would be temporary. > > But the coverage is impossible, since there are so many > different kernel trees. So a kernel solution is a non-starter. IMHO a long term solution can only go through the kernel. There will be more instances like this in the future, given the fundamental issue is the lack of a clear EOPNOTSUPP-like interface. I realise the mount interface is ancient at this point, and difficult to change. We are keeping an eye on the evolution of the new interface, but it's not there yet (eg: no read-only bind mounts). > > > Besides, if something with root/mount priv. is consistently trying to > > > drive a square peg into a round hole - by trying to mount something and > > > failing -- it should be something that a sysadmin would want to > > > investigate. Which is precisely why I am here now. I think burying it > > > at debug level is counterproductive to that. > > > > Well the real issue is that there's no way to get a clean "we don't > > support this option" out of certain kernel APIs, so one has to guess > > and see what happens. Sometimes it's even worse, and flags like > > NOSYMFOLLOW get silently ignored if they are not supported, which is > > not great for security-related settings... > > > > Anyway, these warnings only appear if ProtectProc and/or ProcSubset are > > set to something other than the default value. Why not simply add a > > top-level drop-in in /etc that forces them to be disabled in all > > services if you have an older kernel? Something like this: > > > > /etc/systemd/system/service.d/10-override-protect-proc.conf > > [Service] > > ProtectProc=default > > ProcSubset=all > > > > And then you can drop it when you upgrade your kernel. Isn't this a > > better option than taking on permanent technical debt? > > That's even more fiddly than Paul's patch. It relies on much more > of someone's distro configuration. But what is the combination of a kernel version + systemd version if not someone's distro configuration? I mean, it could even be added dynamically by the poky recipe at build time, given the kernel version is known at that point. Surely a three lines piece of configuration is better to handle than a downstream patch? > But it is true that you can throw it away eventually, assuming > someone actually knows that it is there. > > I wouldn't call this patch much of a technical debt, but if it starts > gumming up systemd upgrades, it's easy to revisit. It's in a security-critical area that we are constantly improving and expanding. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#146834): https://lists.openembedded.org/g/openembedded-core/message/146834 Mute This Topic: https://lists.openembedded.org/mt/79695930/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] systemd: dont spew hidepid mount errors for kernels < v5.8
On Fri, 2021-01-15 at 09:47 -0500, Paul Gortmaker wrote: > [Re: [PATCH] systemd: dont spew hidepid mount errors for kernels < v5.8] On > 15/01/2021 (Fri 09:57) Luca Boccassi wrote: > > > On Fri, 2021-01-15 at 08:37 +, Richard Purdie wrote: > > > On Fri, 2021-01-15 at 00:26 -0500, Paul Gortmaker wrote: > > > > Recent systemd started using ascii args to "hidepid=" mount options > > > > for proc fs - unconditionally -- even though kernels older than v5.8 > > > > emit an error message on each attempt: > > > > > > > > root@qemux86-64:~# cat /proc/version > > > > Linux version 5.4.87-yocto-standard (oe-user@oe-host) (gcc version > > > > 10.2.0 (GCC)) #1 SMP PREEMPT Fri Jan 8 01:47:13 UTC 2021 > > > > root@qemux86-64:~# dmesg|grep proc: > > > > [ 29.487995] proc: Bad value for 'hidepid' > > > > [ 43.170571] proc: Bad value for 'hidepid' > > > > [ 44.175615] proc: Bad value for 'hidepid' > > > > [ 46.213300] proc: Bad value for 'hidepid' > > > > root@qemux86-64:~# > > > > Wouldn't it be better to patch the kernel to downgrade that message to > > debug level? > > The problem is that the breakage is forced upon older kernels, so you'd > have to effectively mainline that kind of "fix" to v5.12 (where there is > no problem) and then you could in theory request it for v5.4 linux-stable > according to "stable rules". The patch could be downstream for older kernels, just like this one is. With the difference that it would be temporary. > Besides, if something with root/mount priv. is consistently trying to > drive a square peg into a round hole - by trying to mount something and > failing -- it should be something that a sysadmin would want to > investigate. Which is precisely why I am here now. I think burying it > at debug level is counterproductive to that. Well the real issue is that there's no way to get a clean "we don't support this option" out of certain kernel APIs, so one has to guess and see what happens. Sometimes it's even worse, and flags like NOSYMFOLLOW get silently ignored if they are not supported, which is not great for security-related settings... Anyway, these warnings only appear if ProtectProc and/or ProcSubset are set to something other than the default value. Why not simply add a top-level drop-in in /etc that forces them to be disabled in all services if you have an older kernel? Something like this: /etc/systemd/system/service.d/10-override-protect-proc.conf [Service] ProtectProc=default ProcSubset=all And then you can drop it when you upgrade your kernel. Isn't this a better option than taking on permanent technical debt? > > > > +The systemd maintainer has dismissed this as something people should > > > > +simply ignore[1] and has no interest in trying to avoid it by > > > > +proactively checking the kernel version, so people can safely assume > > > > +that they will never see this version check commit upstream. > > > > + > > > > +However, as can be seen above, telling people to just ignore it is not > > > > +an option, as we'll end up answering the same question and dealing with > > > > +the same bug over and over again. > > > > + > > > > +The commit that triggers this is systemd v247-rc1~378^2~3 -- so any > > > > +systemd 247 and above plus kernel v5.7 or older will need this. > > > > + > > > > +[1] > > > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fsystemd%2Fsystemd%2Fissues%2F16896&data=04%7C01%7CLuca.Boccassi%40microsoft.com%7Ce972c325854743b67f0b08d8b9647bf1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637463188548752517%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=r%2FCh5m3ZLautkN1PLg99HqGdfl4VXqiNjJUsJhDPmCI%3D&reserved=0 > > > > + > > > > +Upstream-Status: Actively hostile > > > > > > The status needs to be > > > > > > Upstream-Status: Denied [Actively hostile > > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fsystemd%2Fsystemd%2Fissues%2F16896&data=04%7C01%7CLuca.Boccassi%40microsoft.com%7Ce972c325854743b67f0b08d8b9647bf1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637463188548752517%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=r%2FCh5m3ZLautkN1PLg99HqGdfl4VXqiNjJUsJhDPmCI%3D&reserved=0] > > > > > > (so our tools have an idea of what status patches
Re: [OE-core] [PATCH] systemd: dont spew hidepid mount errors for kernels < v5.8
On Fri, 2021-01-15 at 00:26 -0500, Paul Gortmaker wrote:
> Recent systemd started using ascii args to "hidepid=" mount options
> for proc fs - unconditionally -- even though kernels older than v5.8
> emit an error message on each attempt:
>
> root@qemux86-64:~# cat /proc/version
> Linux version 5.4.87-yocto-standard (oe-user@oe-host) (gcc version 10.2.0
> (GCC)) #1 SMP PREEMPT Fri Jan 8 01:47:13 UTC 2021
> root@qemux86-64:~# dmesg|grep proc:
> [ 29.487995] proc: Bad value for 'hidepid'
> [ 43.170571] proc: Bad value for 'hidepid'
> [ 44.175615] proc: Bad value for 'hidepid'
> [ 46.213300] proc: Bad value for 'hidepid'
> root@qemux86-64:~#
>
> Simply ignoring them as the systemd maintainer unconditionally says
> is the resolution is clearly not acceptable, given the above.
>
> Add a kernel version check to avoid calling mount with invalid args.
> Further details are within the enclosed systemd commit.
>
> Cc: Luca Boccassi
> Cc: Richard Purdie
> Signed-off-by: Paul Gortmaker
>
> diff --git
> a/meta/recipes-core/systemd/systemd/0027-proc-dont-trigger-mount-error-with-invalid-options-o.patch
>
> b/meta/recipes-core/systemd/systemd/0027-proc-dont-trigger-mount-error-with-invalid-options-o.patch
> new file mode 100644
> index ..65e7eca32d05
> --- /dev/null
> +++
> b/meta/recipes-core/systemd/systemd/0027-proc-dont-trigger-mount-error-with-invalid-options-o.patch
> @@ -0,0 +1,126 @@
> +From 297aba739cd689e4dc9f43bb1422ec88d481099a Mon Sep 17 00:00:00 2001
> +From: Paul Gortmaker
> +Date: Wed, 13 Jan 2021 21:09:33 +
> +Subject: [PATCH] proc: dont trigger mount error with invalid options on old
> + kernels
> +
> +As of commit 4e39995371738b04d98d27b0d34ea8fe09ec9fab ("core: introduce
> +ProtectProc= and ProcSubset= to expose hidepid= and subset= procfs
> +mount options") kernels older than v5.8 generate multple warnings at
> +boot, as seen in this Yocto build from today:
> +
> + qemux86-64 login: root
> + [ 65.829009] proc: Bad value for 'hidepid'
> + root@qemux86-64:~# dmesg|grep proc:
> + [ 16.990706] proc: Bad value for 'hidepid'
> + [ 28.060178] proc: Bad value for 'hidepid'
> + [ 28.874229] proc: Bad value for 'hidepid'
> + [ 32.685107] proc: Bad value for 'hidepid'
> + [ 65.829009] proc: Bad value for 'hidepid'
> + root@qemux86-64:~#
> +
> +The systemd maintainer has dismissed this as something people should
> +simply ignore[1] and has no interest in trying to avoid it by
> +proactively checking the kernel version, so people can safely assume
> +that they will never see this version check commit upstream.
> +
> +However, as can be seen above, telling people to just ignore it is not
> +an option, as we'll end up answering the same question and dealing with
> +the same bug over and over again.
> +
> +The commit that triggers this is systemd v247-rc1~378^2~3 -- so any
> +systemd 247 and above plus kernel v5.7 or older will need this.
> +
> +[1] https://github.com/systemd/systemd/issues/16896
> +
> +Upstream-Status: Actively hostile
> +Signed-off-by: Paul Gortmaker
> +
> +diff --git a/src/core/namespace.c b/src/core/namespace.c
> +index cdf427a6ea93..f8fc33a89fc2 100644
> +--- a/src/core/namespace.c
> b/src/core/namespace.c
> +@@ -4,7 +4,9 @@
> + #include
> + #include
> + #include
> ++#include
> + #include
> ++#include
> + #include
> + #include
> +
> +@@ -859,14 +861,34 @@ static int mount_sysfs(const MountEntry *m) {
> + }
> +
> + static int mount_procfs(const MountEntry *m, const NamespaceInfo *ns_info) {
> ++_cleanup_free_ char *opts = NULL;
> + const char *entry_path;
> +-int r;
> ++int r, major, minor;
> ++struct utsname uts;
> ++bool old = false;
> +
> + assert(m);
> + assert(ns_info);
> +
> + entry_path = mount_entry_path(m);
> +
> ++/* If uname says that the system is older than v5.8, then the
> textual hidepid= stuff is not
> ++ * supported by the kernel, and thus the per-instance hidepid=
> neither, which means we
> ++ * really don't want to use it, since it would affect our host's
> /proc * mount. Hence let's
> ++ * gracefully fallback to a classic, unrestricted version. */
> ++
> ++r = uname(&uts);
> ++if (r < 0)
> ++ return errno;
> ++
> ++major = atoi(uts.release);
> ++minor = atoi(strchr(uts.release, '.') + 1);
> ++
> ++if (major <
Re: [OE-core] [PATCH] systemd: dont spew hidepid mount errors for kernels < v5.8
On Fri, 2021-01-15 at 10:14 +, Richard Purdie wrote:
> On Fri, 2021-01-15 at 09:57 +0000, Luca Boccassi wrote:
> > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.yoctoproject.org%2Fwiki%2FBest_Known_Methods%23Patch_Comments&data=04%7C01%7CLuca.Boccassi%40microsoft.com%7Cd96a07e0ec0740e98b9a08d8b93e6409%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637463024985923638%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=aK4%2F8oasYb3NJ84rVUq6ptf0nRnwDKniKj4jIB283EY%3D&reserved=0
> >
> > Richard, FYI this appears to be an empty page.
>
> That wasn't the link in my email, the link was:
>
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.yoctoproject.org%2Fwiki%2FBest_Known_Methods_&data=04%7C01%7CLuca.Boccassi%40microsoft.com%7Cd96a07e0ec0740e98b9a08d8b93e6409%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637463024985933630%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=TOAqow8KyiRT6i3LtpEeS46T0Dq8iixSNc3l6XpDzhk%3D&reserved=0(BKMs)_for_Package_Updating#Patch_Comments
>
> The brackets in there may be causing some kind of issue?
>
> In case it doesn't work, the page in question is titled
> "Best Known Methods (BKMs) for Package Updating"
>
> Cheers,
>
> Richard
Sorry my bad, it looks like the Exchange mail server mangling of the
link ("safelinks" feature) removes the brackets and makes it invalid. I
should really stop using the Microsoft address...
--
Kind regards,
Luca Boccassi
signature.asc
Description: This is a digitally signed message part
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#146734):
https://lists.openembedded.org/g/openembedded-core/message/146734
Mute This Topic: https://lists.openembedded.org/mt/79695930/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] systemd: dont spew hidepid mount errors for kernels < v5.8
On Fri, 2021-01-15 at 08:37 +, Richard Purdie wrote:
> On Fri, 2021-01-15 at 00:26 -0500, Paul Gortmaker wrote:
> > Recent systemd started using ascii args to "hidepid=" mount options
> > for proc fs - unconditionally -- even though kernels older than v5.8
> > emit an error message on each attempt:
> >
> > root@qemux86-64:~# cat /proc/version
> > Linux version 5.4.87-yocto-standard (oe-user@oe-host) (gcc version 10.2.0
> > (GCC)) #1 SMP PREEMPT Fri Jan 8 01:47:13 UTC 2021
> > root@qemux86-64:~# dmesg|grep proc:
> > [ 29.487995] proc: Bad value for 'hidepid'
> > [ 43.170571] proc: Bad value for 'hidepid'
> > [ 44.175615] proc: Bad value for 'hidepid'
> > [ 46.213300] proc: Bad value for 'hidepid'
> > root@qemux86-64:~#
Wouldn't it be better to patch the kernel to downgrade that message to
debug level?
> > Simply ignoring them as the systemd maintainer unconditionally says
> > is the resolution is clearly not acceptable, given the above.
> >
> > Add a kernel version check to avoid calling mount with invalid args.
> > Further details are within the enclosed systemd commit.
> >
> > Cc: Luca Boccassi
> > Cc: Richard Purdie
> > Signed-off-by: Paul Gortmaker
> >
> > diff --git
> > a/meta/recipes-core/systemd/systemd/0027-proc-dont-trigger-mount-error-with-invalid-options-o.patch
> >
> > b/meta/recipes-core/systemd/systemd/0027-proc-dont-trigger-mount-error-with-invalid-options-o.patch
> > new file mode 100644
> > index ..65e7eca32d05
> > --- /dev/null
> > +++
> > b/meta/recipes-core/systemd/systemd/0027-proc-dont-trigger-mount-error-with-invalid-options-o.patch
> > @@ -0,0 +1,126 @@
> > +From 297aba739cd689e4dc9f43bb1422ec88d481099a Mon Sep 17 00:00:00 2001
> > +From: Paul Gortmaker
> > +Date: Wed, 13 Jan 2021 21:09:33 +
> > +Subject: [PATCH] proc: dont trigger mount error with invalid options on old
> > + kernels
> > +
> > +As of commit 4e39995371738b04d98d27b0d34ea8fe09ec9fab ("core: introduce
> > +ProtectProc= and ProcSubset= to expose hidepid= and subset= procfs
> > +mount options") kernels older than v5.8 generate multple warnings at
> > +boot, as seen in this Yocto build from today:
> > +
> > + qemux86-64 login: root
> > + [ 65.829009] proc: Bad value for 'hidepid'
> > + root@qemux86-64:~# dmesg|grep proc:
> > + [ 16.990706] proc: Bad value for 'hidepid'
> > + [ 28.060178] proc: Bad value for 'hidepid'
> > + [ 28.874229] proc: Bad value for 'hidepid'
> > + [ 32.685107] proc: Bad value for 'hidepid'
> > + [ 65.829009] proc: Bad value for 'hidepid'
> > + root@qemux86-64:~#
> > +
> > +The systemd maintainer has dismissed this as something people should
> > +simply ignore[1] and has no interest in trying to avoid it by
> > +proactively checking the kernel version, so people can safely assume
> > +that they will never see this version check commit upstream.
> > +
> > +However, as can be seen above, telling people to just ignore it is not
> > +an option, as we'll end up answering the same question and dealing with
> > +the same bug over and over again.
> > +
> > +The commit that triggers this is systemd v247-rc1~378^2~3 -- so any
> > +systemd 247 and above plus kernel v5.7 or older will need this.
> > +
> > +[1] https://github.com/systemd/systemd/issues/16896
> > +
> > +Upstream-Status: Actively hostile
>
> The status needs to be
>
> Upstream-Status: Denied [Actively hostile
> https://github.com/systemd/systemd/issues/16896]
>
> (so our tools have an idea of what status patches are in)
Paul, please, let's avoid loaded language - Denied is fine by itself
and conveys what it needs to. I understand it can be frustrating when
upstream maintainers do not agree with user assessments, but the linked
discussion was polite and professional and there's no need to call it
"hostile".
Also, speaking as an upstream maintainer, I'd be willing to review a
patch that adds a log_debug notice to advise to ignore the error if the
fallback path is taken. It's low cost and reasonable, so I don't think
it would be a problem to merge it.
> https://wiki.yoctoproject.org/wiki/Best_Known_Methods#Patch_Comments
Richard, FYI this appears to be an empty page.
--
Kind regards,
Luca Boccassi
signature.asc
Description: This is a digitally signed message part
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#146732):
https://lists.openembedded.org/g/openembedded-core/message/146732
Mute This Topic: https://lists.openembedded.org/mt/79695930/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH v3] util-linux: split uuid in separate recipe to allow bootstrapping
On Fri, 2020-12-11 at 16:54 +, Richard Purdie wrote: > On Fri, 2020-12-11 at 09:51 +0000, Luca Boccassi wrote: > > On Thu, 2020-12-10 at 20:04 +, Richard Purdie wrote: > > > On Thu, 2020-12-10 at 18:47 +0000, Luca Boccassi wrote: > > > > On Thu, 2020-12-10 at 15:52 +, Richard Purdie wrote: > > > > > On Mon, 2020-11-23 at 13:28 +, Luca Bocassi wrote: > > > I have to ask why libuuid couldn't be done in a separate repository and > > > avoid the need to do a multi-stage build of a component? To me at > > > least, it would seem to make sense to logically split the library code > > > out, then it avoids all the complexity. Yes, that means a different > > > component to release but that isn't unusual. > > > > Because there's no need for the extra complications - again, it's all > > optional features, so bootstrapping is not an issue when the tooling is > > there to support it. > > I'm not a util-linux maintainer so my opinion on the subject counts for > > precisely nothing, but as a contributor and user I'd not be very happy > > if it was stuck to the lowest common denominator. > > If its all optional and not that important I start to wonder why we > should bother with it. > > My point is there has to be complexity somewhere for this "mutli-stage" > approach to work. How much of it you see depends on the system and how > it handles it but you'd agree that having a simple more linear > dependency tree *is* simpler and easier to work with than something > which has multiple stages (and more efficient on build resources too). Optional doesn't always imply unimportant - for some users it's not needed, for others it is, so it's optional. We are in the latter group, hence the work to implement and support it in a multitude of places. > > > > Yocto could really use multi stage support - this isn't the first and > > > > won't be the last occurrence. Just my 2c... > > > > > > Well, we can do it as you're proving, its just ugly and hard to > > > maintain. I don't think the other distros will be particularly happy > > > about needing to do it either. Outside of libgcc, we've not really > > > found that we need to do this often at all and the compiler/libc > > > interface is a lot more "special" than uuid. > > > > But that's what I'm saying: it doesn't have to be ugly, if the > > infrastructure is there to support it. > > I'm sure we (OE) could "hide" it but regardless of whether the code is > hidden or not, its still ugly, not often used and hard to maintain for > someone. We don't want to encourage this though. > > > On Debian and derivatives, you just mark the dependency with > > - and that's it. When bootstrapping you start from stage1 and the > > resolver skips those. If the package configure/make scripts are done > > well, by default optional dependencies are skipped if not available and > > if not explicitly set - and util-linux does that. > > In the RPM world, the spec has conditional macros and you set the > > appropriate one at the build config level (eg: in the lower ring > > project on OBS). > > It's not perfect of course, and requires attention, and there are > > complications and gotchas, and things do go wrong at times - but such > > is life in the software world. > > Complexity is fine, where it makes sense and is needed. You're failing > to convince me its needed here at all. I believe this does need to be > mentioned to the upstream maintainer as they're probably not aware of > the issues it causes. Obviously someone else will have to do that > though since you believe its "fine". I'm sure it wasn't intentional, but this passage comes across as quite condescending. Everybody involved is perfectly capable of understanding how this works and what it implies. > > > Thanks for updating the patch. I'll put it back into the queue and test > > > the new version. > > > > Thank you - does the approach of adding RDEPENDS look right? The > > interaction between those variables and the native/nativesdk builds > > still confuses me a lot, and I get it wrong all the time. > > I've just looked and to be honest, no, it doesn't look right at all :(. > You're adding dependencies in a recipe where the packages don't exist. Could you please be more specific? Dependencies on packages from other recipes are pretty much normal. In what way is this different? And most importantly, do you have a suggestion
Re: [OE-core] [PATCH v3] util-linux: split uuid in separate recipe to allow bootstrapping
On Thu, 2020-12-10 at 20:04 +, Richard Purdie wrote: > On Thu, 2020-12-10 at 18:47 +0000, Luca Boccassi wrote: > > On Thu, 2020-12-10 at 15:52 +, Richard Purdie wrote: > > > On Mon, 2020-11-23 at 13:28 +, Luca Bocassi wrote: > > > > From: Luca Boccassi > > > > > > > > In v2.35 util-linux gained an (optional) build > > > > dependency on libcryptsetup. But libcryptsetup build-depends on > > > > util-linux for blkid (optional, can be disabled) and uuid > > > > (mandatory). > > > > Split out util-linux-uuid in a different recipe to break the > > > > cycle. > > > > > > > > Add a packageconfig switch (disabled by default) to allow using > > > > the > > > > new dependency. > > > > > > > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fkarelzak%2Futil-linux%2Fpull%2F898&data=04%7C01%7CLuca.Boccassi%40microsoft.com%7Cf1cc5d5a36b94793f16708d89d46dfac%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637432275624402419%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=k69BQ6hOpusjBlcC%2FBo%2BFRLsAc%2FiYd5pLPfh65lcRdQ%3D&reserved=0 > > > > > > > > Signed-off-by: Luca Boccassi > > > > --- > > > > v1: util-linux 2.35 is not out yet, but I'd like to get the > > > > preparatory work > > > > underway as I'm not sure if this is the best approach or if > > > > there are > > > > alternatives. Suggestions and comments very welcome. Thanks! > > > > v2: changed packages names to reflect old ones (eg: libuuid1 -> > > > > util-linux-libuuid) > > > > and leave uuid build enable in main recipe to allow for > > > > uuidgen build to happen, > > > > as it does not have its own autoconf switch. Delete the > > > > library manualy from > > > > the main recipe after build instead, and add dependency. > > > > Might help to break loop python3 -> util-linux -> libselinux > > > > -> python3, as it's > > > > only libuuid that is needed, see > > > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.yoctoproject.org%2Fg%2Fyocto%2Fmessage%2F47570&data=04%7C01%7CLuca.Boccassi%40microsoft.com%7Cf1cc5d5a36b94793f16708d89d46dfac%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637432275624402419%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=poH8DFxARF1Myy%2BRRirbOE3bJzu5uSO%2F%2BLfsalK%2F4ro%3D&reserved=0 > > > > v3: rebased and refactored to have a common util-linux.inc file > > > > > > > > > > I'm afraid this causes do_package_qa errors in basic testing: > > > > > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fautobuilder.yoctoproject.org%2Ftyphoon%2F%23%2Fbuilders%2F83%2Fbuilds%2F1668&data=04%7C01%7CLuca.Boccassi%40microsoft.com%7Cf1cc5d5a36b94793f16708d89d46dfac%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637432275624402419%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=uiLItrvBcoNjjjCFZaUlQfC1%2B26N%2BnV72BUiy%2FuBq0M%3D&reserved=0 > > > > Thanks, added RDEPENDS in v4. Strange that those didn't pop up when > > building poky locally, I usually get QA warnings as expected. > > Anything > > in local.conf to enable to get them? > > No, you should see it in a standard build. It did make me wonder how > this was tested :/. Very weird. Maybe some packageconfig difference? I did not go through all the possible permutations manually. We have been using this recipe change in production for a year now, so it has plenty of builds behind. > > > I am worried about this change as we're starting to see a number of > > > circular dependencies in util-linux (there is a new bug about the > > > pylibmount PACKAGECONFIG option too), maybe we should flag this > > > upstream? > > > > > > Multiple recipes like this usually turn into a maintenance > > > nightmare > > > unfortunately which is part of my reluctance to go in this > > > direction, > > > not sure we have any choice though. > > > > Well I've added the feature, and both the maintainer and myself were > > aware of the implications. It's optional, so on distros with multi- > > stage bootstrapping functionality like Debian/Ubuntu/RHEL/Suse/etc it > > can be automatically disabled for the first stage build. At runtime
Re: [OE-core] [PATCH 1/5] systemd: update 246 -> 247
On Thu, 2020-12-10 at 12:40 -0800, Khem Raj wrote: > On Thu, Dec 10, 2020 at 10:05 AM Luca Boccassi > wrote: > > On Thu, 2020-12-10 at 09:08 -0800, Khem Raj wrote: > > > On 12/10/20 4:53 AM, Luca Bocassi wrote: > > > > From: Luca Boccassi > > > > > > > > Update systemd to v247.1. > > > > Add rule for new oomd dbus conf and for new pam.d > > > > conf directory in /usr/lib. > > > > Drop selinux-hook-handling-to-enumerate-nexthop.patch, > > > > merged upstream. > > > > Backport 0001-meson-set-cxx-variable-before-using-it.patch > > > > from v247-stable to fix builds without C++. > > > > Refresh musl patches. > > > > > > > > > > perhaps we need to update systemd-conf and systemd-boot recipes as well > > > here > > > > systemd-boot is updated to use the new meson patch. systemd-conf didn't > > need it, at least for me? Does it fail to build for you? > > no they dont but I thought they should be reflecting systemd version I > would think Sorry, I don't follow - the patch does rename systemd-boot and systemd-config from _246.x.bb to _247.1.bb together with the main recipe. What is missing? -- Kind regards, Luca Boccassi -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#145468): https://lists.openembedded.org/g/openembedded-core/message/145468 Mute This Topic: https://lists.openembedded.org/mt/78853212/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH v3] util-linux: split uuid in separate recipe to allow bootstrapping
On Thu, 2020-12-10 at 15:52 +, Richard Purdie wrote: > On Mon, 2020-11-23 at 13:28 +, Luca Bocassi wrote: > > From: Luca Boccassi > > > > In v2.35 util-linux gained an (optional) build > > dependency on libcryptsetup. But libcryptsetup build-depends on > > util-linux for blkid (optional, can be disabled) and uuid (mandatory). > > Split out util-linux-uuid in a different recipe to break the cycle. > > > > Add a packageconfig switch (disabled by default) to allow using the > > new dependency. > > > > https://github.com/karelzak/util-linux/pull/898 > > > > Signed-off-by: Luca Boccassi > > --- > > v1: util-linux 2.35 is not out yet, but I'd like to get the preparatory work > > underway as I'm not sure if this is the best approach or if there are > > alternatives. Suggestions and comments very welcome. Thanks! > > v2: changed packages names to reflect old ones (eg: libuuid1 -> > > util-linux-libuuid) > > and leave uuid build enable in main recipe to allow for uuidgen build > > to happen, > > as it does not have its own autoconf switch. Delete the library manualy > > from > > the main recipe after build instead, and add dependency. > > Might help to break loop python3 -> util-linux -> libselinux -> > > python3, as it's > > only libuuid that is needed, see > > https://lists.yoctoproject.org/g/yocto/message/47570 > > v3: rebased and refactored to have a common util-linux.inc file > > > > I'm afraid this causes do_package_qa errors in basic testing: > > https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/1668 Thanks, added RDEPENDS in v4. Strange that those didn't pop up when building poky locally, I usually get QA warnings as expected. Anything in local.conf to enable to get them? > I am worried about this change as we're starting to see a number of > circular dependencies in util-linux (there is a new bug about the > pylibmount PACKAGECONFIG option too), maybe we should flag this > upstream? > > Multiple recipes like this usually turn into a maintenance nightmare > unfortunately which is part of my reluctance to go in this direction, > not sure we have any choice though. Well I've added the feature, and both the maintainer and myself were aware of the implications. It's optional, so on distros with multi- stage bootstrapping functionality like Debian/Ubuntu/RHEL/Suse/etc it can be automatically disabled for the first stage build. At runtime it can also be optional via dlopen, if desired (via --configure flag). Yocto could really use multi stage support - this isn't the first and won't be the last occurrence. Just my 2c... -- Kind regards, Luca Boccassi -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#145457): https://lists.openembedded.org/g/openembedded-core/message/145457 Mute This Topic: https://lists.openembedded.org/mt/78452881/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH 1/5] systemd: update 246 -> 247
On Thu, 2020-12-10 at 09:08 -0800, Khem Raj wrote: > > On 12/10/20 4:53 AM, Luca Bocassi wrote: > > From: Luca Boccassi > > > > Update systemd to v247.1. > > Add rule for new oomd dbus conf and for new pam.d > > conf directory in /usr/lib. > > Drop selinux-hook-handling-to-enumerate-nexthop.patch, > > merged upstream. > > Backport 0001-meson-set-cxx-variable-before-using-it.patch > > from v247-stable to fix builds without C++. > > Refresh musl patches. > > > > perhaps we need to update systemd-conf and systemd-boot recipes as well here systemd-boot is updated to use the new meson patch. systemd-conf didn't need it, at least for me? Does it fail to build for you? -- Kind regards, Luca Boccassi -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#145455): https://lists.openembedded.org/g/openembedded-core/message/145455 Mute This Topic: https://lists.openembedded.org/mt/78853212/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH 2/5] systemd: add package config for systemd-oomd
On Thu, 2020-12-10 at 09:05 -0800, Khem Raj wrote: > > On 12/10/20 4:53 AM, Luca Bocassi wrote: > > From: Luca Boccassi > > > > Disabled by default > > > > Signed-off-by: Luca Boccassi > > --- > > meta/recipes-core/systemd/systemd_247.1.bb | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/meta/recipes-core/systemd/systemd_247.1.bb > > b/meta/recipes-core/systemd/systemd_247.1.bb > > index bf73630569..f20c2cffb7 100644 > > --- a/meta/recipes-core/systemd/systemd_247.1.bb > > +++ b/meta/recipes-core/systemd/systemd_247.1.bb > > @@ -157,6 +157,7 @@ PACKAGECONFIG[networkd] = > > "-Dnetworkd=true,-Dnetworkd=false" > > PACKAGECONFIG[nss] = "-Dnss-systemd=true,-Dnss-systemd=false" > > PACKAGECONFIG[nss-mymachines] = > > "-Dnss-mymachines=true,-Dnss-mymachines=false" > > PACKAGECONFIG[nss-resolve] = "-Dnss-resolve=true,-Dnss-resolve=false" > > +PACKAGECONFIG[oomd] = "-Doomd=true,-Doomd=false" > > I wonder if it should be packaged into its own package and built always > so someone interested can just add it their images instead of modifying > packageconfig if its an independent feature. I don't mind either way. Would you like me to do that change? -- Kind regards, Luca Boccassi -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#145454): https://lists.openembedded.org/g/openembedded-core/message/145454 Mute This Topic: https://lists.openembedded.org/mt/78853210/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH v2] dbus: split -common and -tools out of main package
On Thu, 2020-11-12 at 17:29 +, Richard Purdie wrote:
> On Mon, 2020-11-02 at 19:18 +, Luca Bocassi wrote:
> > From: Luca Boccassi
> >
> > Certain config files and units are shared between dbus-daemon and
> > dbus-broker (available in meta-openembedded), so split them out to
> > allow installing dbus-broker without pulling in dbus-daemon and its
> > dependencies.
> > Stand-alone command line tools can also be used regardless of whether
> > the buses are provided by dbus-daemon or dbus-broker, so split them
> > out into dbus-tools.
> > Finally, move the XML schema files out of the main package and into
> > the development package.
> >
> > All these changes follow the same pattern used by Fedora, which was
> > one of the first distro to switch to dbus-broker by default:
> >
> > https://src.fedoraproject.org/rpms/dbus/blob/master/f/dbus.spec
> >
> > Signed-off-by: Luca Boccassi
> > ---
> > v2: fix FILES_ regex to correctly include all units but the sockets
> > in the main package
>
> I tried putting this through testing on the autobuilder but it fails in
> world builds:
>
> https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/1589/steps/13/logs/stdio
>
> (dbus-native seems to depend upon dbus-native-tools-native)
>
> so I've had to drop the patch.
>
> Cheers,
>
> Richard
Hi,
That's a weird error? Building the basic poky reference didn't show it.
Any suggestion on how to fix it? Do you see anything obviously wrong
with the patch? Is this the correct way to add a runtime dependency in
Yocto:
RDEPENDS_${PN} += "${PN}-common ${PN}-tools"
Should it hard-code the name and drop the ${PN} perhaps?
--
Kind regards,
Luca Boccassi
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#144527):
https://lists.openembedded.org/g/openembedded-core/message/144527
Mute This Topic: https://lists.openembedded.org/mt/77989696/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH v2] dbus: split -common and -tools out of main package
On Mon, 2020-11-02 at 19:18 +, luca.bocca...@gmail.com wrote:
> From: Luca Boccassi
>
> Certain config files and units are shared between dbus-daemon and
> dbus-broker (available in meta-openembedded), so split them out to
> allow installing dbus-broker without pulling in dbus-daemon and its
> dependencies.
> Stand-alone command line tools can also be used regardless of whether
> the buses are provided by dbus-daemon or dbus-broker, so split them
> out into dbus-tools.
> Finally, move the XML schema files out of the main package and into
> the development package.
>
> All these changes follow the same pattern used by Fedora, which was
> one of the first distro to switch to dbus-broker by default:
>
> https://src.fedoraproject.org/rpms/dbus/blob/master/f/dbus.spec
>
> Signed-off-by: Luca Boccassi
> ---
> v2: fix FILES_ regex to correctly include all units but the sockets
> in the main package
>
> meta/recipes-core/dbus/dbus_1.12.20.bb | 35 +++---
> 1 file changed, 21 insertions(+), 14 deletions(-)
>
> diff --git a/meta/recipes-core/dbus/dbus_1.12.20.bb
> b/meta/recipes-core/dbus/dbus_1.12.20.bb
> index cf6f7dc0ef..400c7a1401 100644
> --- a/meta/recipes-core/dbus/dbus_1.12.20.bb
> +++ b/meta/recipes-core/dbus/dbus_1.12.20.bb
> @@ -11,6 +11,7 @@ RDEPENDS_dbus_class-nativesdk = ""
> PACKAGES += "${@bb.utils.contains('DISTRO_FEATURES', 'ptest', '${PN}-ptest',
> '', d)}"
> ALLOW_EMPTY_dbus-ptest = "1"
> RDEPENDS_dbus-ptest_class-target = "dbus-test-ptest"
> +RDEPENDS_${PN} += "${PN}-common ${PN}-tools"
>
> inherit useradd update-rc.d
>
> @@ -31,7 +32,7 @@ CONFFILES_${PN} = "${sysconfdir}/dbus-1/system.conf
> ${sysconfdir}/dbus-1/session
>
> DEBIANNAME_${PN} = "dbus-1"
>
> -PACKAGES =+ "${PN}-lib"
> +PACKAGES =+ "${PN}-lib ${PN}-common ${PN}-tools"
>
> OLDPKGNAME = "dbus-x11"
> OLDPKGNAME_class-nativesdk = ""
> @@ -41,31 +42,37 @@ RPROVIDES_${PN} = "${OLDPKGNAME}"
> RREPLACES_${PN} += "${OLDPKGNAME}"
>
> FILES_${PN} = "${bindir}/dbus-daemon* \
> - ${bindir}/dbus-uuidgen \
> ${bindir}/dbus-cleanup-sockets \
> - ${bindir}/dbus-send \
> - ${bindir}/dbus-monitor \
> ${bindir}/dbus-launch \
> ${bindir}/dbus-run-session \
> - ${bindir}/dbus-update-activation-environment \
> ${libexecdir}/dbus* \
> ${sysconfdir} \
> ${localstatedir} \
> - ${datadir}/dbus-1/services \
> - ${datadir}/dbus-1/system-services \
> - ${datadir}/dbus-1/session.d \
> - ${datadir}/dbus-1/session.conf \
> - ${datadir}/dbus-1/system.d \
> - ${datadir}/dbus-1/system.conf \
> - ${datadir}/xml/dbus-1 \
> ${systemd_system_unitdir} \
> ${systemd_user_unitdir} \
> - ${nonarch_libdir}/sysusers.d/dbus.conf \
> ${nonarch_libdir}/tmpfiles.d/dbus.conf \
> "
> +FILES_${PN}-common = "${sysconfdir}/dbus-1 \
> + ${datadir}/dbus-1/services \
> + ${datadir}/dbus-1/system-services \
> + ${datadir}/dbus-1/session.d \
> + ${datadir}/dbus-1/session.conf \
> + ${datadir}/dbus-1/system.d \
> + ${datadir}/dbus-1/system.conf \
> + ${systemd_system_unitdir}/dbus.socket \
> + ${systemd_system_unitdir}/sockets.target.wants \
> + ${systemd_user_unitdir}/dbus.socket \
> + ${systemd_user_unitdir}/sockets.target.wants \
> + ${nonarch_libdir}/sysusers.d/dbus.conf \
> +"
> +FILES_${PN}-tools = "${bindir}/dbus-uuidgen \
> + ${bindir}/dbus-send \
> + ${bindir}/dbus-monitor \
> + ${bindir}/dbus-update-activation-environment \
> +"
> FILES_${PN}-lib = "${libdir}/lib*.so.*"
> RRECOMMENDS_${PN}-lib = "${PN}"
> -FILES_${PN}-dev += "${libdir}/dbus-1.0/include ${libdir}/cmake/DBus1
> ${bindir}/dbus-test-tool"
> +FILES_${PN}-dev += "${libdir}/dbus-1.0/include ${libdir}/cmake/DBus1
> ${bindir}/dbus-test-tool ${datadir}/xml/dbus-1"
>
> PACKAGE_WRITE_DEPS += "${@bb.utils.contains('DISTRO_FEATURES','systemd
> sysvinit','systemd-systemctl-native','',d)}"
> pkg_postinst_dbus() {
Ping. Any chance for a review? Thanks.
--
Kind regards,
Luca Boccassi
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#144471):
https://lists.openembedded.org/g/openembedded-core/message/144471
Mute This Topic: https://lists.openembedded.org/mt/77989696/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] util-linux: split uuid in separate recipe to allow bootstrapping
> On 05/12/2019 20:13, luca.bocca...@gmail.com wrote: > > From: Luca Boccassi > > > > In the next release util-linux will gain an (optional) build > > dependency on libcryptsetup. But libcryptsetup build-depends on > > util-linux for blkid (optional, can be disabled) and uuid > (mandatory). > > Split out util-linux-uuid in a different recipe to break the cycle. > > > > At least please simply make util-linux-uuid just require util-linux > and > make the configuration changes required (presumably, disabling all > tools > but uuid). > > Ross Hi Ross, (please CC me, I am not receiving mails to the list. Thanks!) I tried that at first, but it was so complex that the recipe turned out to be bigger than it is right now. And it wasn't even working, there were tons of conflicts because of who-knows-what it was picking up due to the dynamic generation. -- Kind regards, Luca Boccassi -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2] util-linux: split uuid in separate recipe to allow bootstrapping
From: Luca Boccassi
In the next release util-linux will gain an (optional) build
dependency on libcryptsetup. But libcryptsetup build-depends on
util-linux for blkid (optional, can be disabled) and uuid (mandatory).
Split out util-linux-uuid in a different recipe to break the cycle.
https://github.com/karelzak/util-linux/pull/898
Signed-off-by: Luca Boccassi
---
v1: util-linux 2.35 is not out yet, but I'd like to get the preparatory work
underway as I'm not sure if this is the best approach or if there are
alternatives. Suggestions and comments very welcome. Thanks!
v2: changed packages names to reflect old ones (eg: libuuid1 ->
util-linux-libuuid)
and leave uuid build enable in main recipe to allow for uuidgen build to
happen,
as it does not have its own autoconf switch. Delete the library manualy from
the main recipe after build instead, and add dependency.
Might help to break loop python3 -> util-linux -> libselinux -> python3, as
it's
only libuuid that is needed, see
https://lists.yoctoproject.org/g/yocto/message/47570
.../util-linux/util-linux-uuid_2.34.bb| 40 +++
meta/recipes-core/util-linux/util-linux.inc | 11 +
meta/recipes-extended/wget/wget.inc | 2 +-
3 files changed, 52 insertions(+), 1 deletion(-)
create mode 100644 meta/recipes-core/util-linux/util-linux-uuid_2.34.bb
diff --git a/meta/recipes-core/util-linux/util-linux-uuid_2.34.bb
b/meta/recipes-core/util-linux/util-linux-uuid_2.34.bb
new file mode 100644
index 00..ec47f9ae62
--- /dev/null
+++ b/meta/recipes-core/util-linux/util-linux-uuid_2.34.bb
@@ -0,0 +1,40 @@
+SUMMARY = "Builds libuuid separately from util-linux for bootstrapping"
+HOMEPAGE = "http://userweb.kernel.org/~kzak/util-linux/";
+
+SECTION = "base"
+
+LICENSE = "GPLv2+ & LGPLv2.1+ & BSD-3-Clause & BSD-4-Clause"
+
+LIC_FILES_CHKSUM =
"file://README.licensing;md5=972a134f1e14b2b060e365df2fab0099 \
+file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263 \
+
file://Documentation/licenses/COPYING.GPL-2.0-or-later;md5=b234ee4d69f5fce4486a80fdaf4a4263
\
+
file://Documentation/licenses/COPYING.LGPL-2.1-or-later;md5=4fbd65380cdd255951079008b364516c
\
+
file://Documentation/licenses/COPYING.BSD-3-Clause;md5=58dcd8452651fc8b07d1f65ce07ca8af
\
+
file://Documentation/licenses/COPYING.BSD-4-Clause-UC;md5=263860f8968d8bafa5392cab74285262
\
+
file://libuuid/COPYING;md5=6d2cafc999feb2c2de84d4d24b23290c \
+
file://libmount/COPYING;md5=7c7e39fb7d70ffe5d693a643e29987c2 \
+
file://libblkid/COPYING;md5=693bcbbe16d3a4a4b37bc906bc01cc04"
+
+MAJOR_VERSION = "${@'.'.join(d.getVar('PV').split('.')[0:2])}"
+SRC_URI =
"${KERNELORG_MIRROR}/linux/utils/util-linux/v${MAJOR_VERSION}/util-linux-${MAJOR_VERSION}.tar.xz
\
+ "
+
+SRC_URI[md5sum] = "a78cbeaed9c39094b96a48ba8f891d50"
+SRC_URI[sha256sum] =
"743f9d0c7252b6db246b659c1e1ce0bd45d8d4508b4dfa427bbb4a3e9b9f62b5"
+
+inherit autotools gettext pkgconfig
+
+S = "${WORKDIR}/util-linux-${PV}"
+EXTRA_OECONF += "--disable-all-programs --enable-libuuid"
+DEBIAN_NOAUTONAME_util-linux-libuuid = "1"
+DEBIAN_NOAUTONAME_util-linux-libuuid-dev = "1"
+DEBIAN_NOAUTONAME_util-linux-libuuid-dbg = "1"
+PACKAGES = "util-linux-libuuid util-linux-libuuid-dev util-linux-libuuid-dbg"
+FILES_util-linux-libuuid = "${libdir}/libuuid.so.*"
+FILES_util-linux-libuuid-dev = "${libdir}/libuuid.so ${includedir}
${libdir}/pkgconfig"
+FILES_util-linux-libuuid-dbg = "/usr/src ${libdir}/.debug"
+
+do_install_append() {
+ rmdir ${D}${bindir} ${D}${sbindir}
+ rm -rf ${D}${datadir}
+}
diff --git a/meta/recipes-core/util-linux/util-linux.inc
b/meta/recipes-core/util-linux/util-linux.inc
index 1fa82363b1..6973670589 100644
--- a/meta/recipes-core/util-linux/util-linux.inc
+++ b/meta/recipes-core/util-linux/util-linux.inc
@@ -288,6 +288,17 @@ ALTERNATIVE_LINK_NAME[utmpdump.1] =
"${mandir}/man1/utmpdump.1"
ALTERNATIVE_LINK_NAME[uuid.3] = "${mandir}/man3/uuid.3"
ALTERNATIVE_LINK_NAME[wall.1] = "${mandir}/man1/wall.1"
+# dm-verity support introduces a circular dependency, so util-linux-uuid is
split out for target builds
+# Need to build libuuid for uuidgen, but then delete it and let the other
recipe ship it
+RPROVIDES_remove_class-target_${PN}-dev = "util-linux-libuuid-dev"
+PACKAGES_remove_class-target = "util-linux-libuuid util-linux-libuuid-dev
util-linux-libuuid-dbg"
+DEPENDS_append_class-target = " util-linux-uuid"
+RDEPENDS_append_class-target_${PN}-dev = " util-linux-libuuid-dev"
+RDEPENDS
[OE-core] [PATCH] util-linux: split uuid in separate recipe to allow bootstrapping
From: Luca Boccassi
In the next release util-linux will gain an (optional) build
dependency on libcryptsetup. But libcryptsetup build-depends on
util-linux for blkid (optional, can be disabled) and uuid (mandatory).
Split out util-linux-uuid in a different recipe to break the cycle.
https://github.com/karelzak/util-linux/pull/898
Signed-off-by: Luca Boccassi
---
util-linux 2.35 is not out yet, but I'd like to get the preparatory work
underway as I'm not sure if this is the best approach or if there are
alternatives. Suggestions and comments very welcome. Thanks!
.../util-linux/util-linux-uuid_2.34.bb| 35 +++
meta/recipes-core/util-linux/util-linux.inc | 6
meta/recipes-extended/wget/wget.inc | 2 +-
3 files changed, 42 insertions(+), 1 deletion(-)
create mode 100644 meta/recipes-core/util-linux/util-linux-uuid_2.34.bb
diff --git a/meta/recipes-core/util-linux/util-linux-uuid_2.34.bb
b/meta/recipes-core/util-linux/util-linux-uuid_2.34.bb
new file mode 100644
index 00..f106c6a18c
--- /dev/null
+++ b/meta/recipes-core/util-linux/util-linux-uuid_2.34.bb
@@ -0,0 +1,35 @@
+SUMMARY = "Builds libuuid separately from util-linux for bootstrapping"
+HOMEPAGE = "http://userweb.kernel.org/~kzak/util-linux/";
+
+SECTION = "base"
+
+LICENSE = "GPLv2+ & LGPLv2.1+ & BSD-3-Clause & BSD-4-Clause"
+
+LIC_FILES_CHKSUM =
"file://README.licensing;md5=972a134f1e14b2b060e365df2fab0099 \
+file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263 \
+
file://Documentation/licenses/COPYING.GPL-2.0-or-later;md5=b234ee4d69f5fce4486a80fdaf4a4263
\
+
file://Documentation/licenses/COPYING.LGPL-2.1-or-later;md5=4fbd65380cdd255951079008b364516c
\
+
file://Documentation/licenses/COPYING.BSD-3-Clause;md5=58dcd8452651fc8b07d1f65ce07ca8af
\
+
file://Documentation/licenses/COPYING.BSD-4-Clause-UC;md5=263860f8968d8bafa5392cab74285262
\
+
file://libuuid/COPYING;md5=6d2cafc999feb2c2de84d4d24b23290c \
+
file://libmount/COPYING;md5=7c7e39fb7d70ffe5d693a643e29987c2 \
+
file://libblkid/COPYING;md5=693bcbbe16d3a4a4b37bc906bc01cc04"
+
+MAJOR_VERSION = "${@'.'.join(d.getVar('PV').split('.')[0:2])}"
+SRC_URI =
"${KERNELORG_MIRROR}/linux/utils/util-linux/v${MAJOR_VERSION}/util-linux-${MAJOR_VERSION}.tar.xz
\
+ "
+
+SRC_URI[md5sum] = "a78cbeaed9c39094b96a48ba8f891d50"
+SRC_URI[sha256sum] =
"743f9d0c7252b6db246b659c1e1ce0bd45d8d4508b4dfa427bbb4a3e9b9f62b5"
+
+inherit autotools gettext pkgconfig
+
+S = "${WORKDIR}/util-linux-${PV}"
+EXTRA_OECONF += "--disable-all-programs --enable-libuuid"
+RPROVIDES_libuuid-dev = "util-linux-libuuid-dev"
+RPROVIDES_libuuid = "util-linux-libuuid"
+
+do_install_append() {
+ rmdir ${D}${bindir} ${D}${sbindir}
+ rm -rf ${D}${datadir}
+}
diff --git a/meta/recipes-core/util-linux/util-linux.inc
b/meta/recipes-core/util-linux/util-linux.inc
index 1fa82363b1..ef6f95776a 100644
--- a/meta/recipes-core/util-linux/util-linux.inc
+++ b/meta/recipes-core/util-linux/util-linux.inc
@@ -288,6 +288,12 @@ ALTERNATIVE_LINK_NAME[utmpdump.1] =
"${mandir}/man1/utmpdump.1"
ALTERNATIVE_LINK_NAME[uuid.3] = "${mandir}/man3/uuid.3"
ALTERNATIVE_LINK_NAME[wall.1] = "${mandir}/man1/wall.1"
+# split uuid out to allow in the near future a build-dependency on packages
depending on it
+RPROVIDES_remove_class-target_${PN}-dev = "util-linux-libuuid-dev"
+PACKAGES_remove_class-target = "libuuid1 util-linux-libuuid1"
+DEPENDS_append_class-target = " util-linux-uuid"
+EXTRA_OECONF_remove_class-target = "--enable-libuuid"
+EXTRA_OECONF_append_class-target = " --disable-libuuid"
BBCLASSEXTEND = "native nativesdk"
diff --git a/meta/recipes-extended/wget/wget.inc
b/meta/recipes-extended/wget/wget.inc
index 2338328216..7b7a3fae7a 100644
--- a/meta/recipes-extended/wget/wget.inc
+++ b/meta/recipes-extended/wget/wget.inc
@@ -32,7 +32,7 @@ PACKAGECONFIG[gnutls] = "--with-ssl=gnutls,,gnutls"
PACKAGECONFIG[ipv6] = "--enable-ipv6,--disable-ipv6,"
PACKAGECONFIG[iri] = "--enable-iri,--disable-iri,libidn2"
PACKAGECONFIG[libpsl] = "--with-libpsl,--without-libpsl,libpsl"
-PACKAGECONFIG[libuuid] = "--with-libuuid,--without-libuuid,util-linux"
+PACKAGECONFIG[libuuid] = "--with-libuuid,--without-libuuid,util-linux-uuid"
PACKAGECONFIG[openssl] = "--with-ssl=openssl,,openssl"
PACKAGECONFIG[pcre] = "--enable-pcre,--disable-pcre,libpcre"
PACKAGECONFIG[zlib] = "--with-zlib,--without-zlib,zlib"
--
2.20.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v3] python3-pygobject: move python3-setuptools from RDEPENDS to DEPENDS
On Thu, 2019-08-08 at 14:03 +, Jacob Kroon wrote: > Hi Luca, > > On 8/8/19 3:58 PM, > luca.bocca...@gmail.com > wrote: > > From: Luca Boccassi < > > luca.bocca...@microsoft.com > > > > > > > python3-setuptools is necessary to build pygobject but not to run > > it, as > > also documented by the upstream packaging guide: > > > > https://gitlab.gnome.org/GNOME/pygobject/blob/master/docs/packagingguide.rst > > > > > > Move it to DEPENDS to shrink the runtime dependency chain, as > > setuptools > > includes scripts to download other packages, which might not be > > desired on > > a minimal image. > > > > This commmit message should be rephrased now. > /Jacob Hi, Yes I realised 0.1 seconds after git send-email completed :-) Already sent v4: https://patchwork.openembedded.org/patch/163798/ -- Kind regards, Luca Boccassi -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v4] python3-pygobject: remove python3-setuptools from RDEPENDS
From: Luca Boccassi
python3-setuptools is an optional build-dependency of pygobject but
it is not necessary to run it, as also documented by the upstream
packaging guide:
https://gitlab.gnome.org/GNOME/pygobject/blob/master/docs/packagingguide.rst
Remove it from RDEPENDS to shrink the runtime dependency chain, as
setuptools includes scripts to download other packages, which might not
be desired on a minimal image.
Signed-off-by: Luca Boccassi
---
v2: use -native suffix as requested during the code review
v3: do not add setuptools to DEPENDS - it is optional and it builds without it
v4: fix commit message to reflect latest changes
meta/recipes-devtools/python/python3-pygobject_3.32.2.bb | 2 --
1 file changed, 2 deletions(-)
diff --git a/meta/recipes-devtools/python/python3-pygobject_3.32.2.bb
b/meta/recipes-devtools/python/python3-pygobject_3.32.2.bb
index 05688be603..453fdac2c8 100644
--- a/meta/recipes-devtools/python/python3-pygobject_3.32.2.bb
+++ b/meta/recipes-devtools/python/python3-pygobject_3.32.2.bb
@@ -27,7 +27,5 @@ PACKAGECONFIG ??=
"${@bb.utils.contains_any('DISTRO_FEATURES', [ 'directfb', 'wa
# we don't link against python3-pycairo -> RDEPENDS
PACKAGECONFIG[cairo] = "-Dpycairo=true,-Dpycairo=false, cairo python3-pycairo,
python3-pycairo"
-RDEPENDS_${PN} += "python3-setuptools"
-
BBCLASSEXTEND = "native"
PACKAGECONFIG_class-native = ""
--
2.20.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v3] python3-pygobject: move python3-setuptools from RDEPENDS to DEPENDS
From: Luca Boccassi
python3-setuptools is necessary to build pygobject but not to run it, as
also documented by the upstream packaging guide:
https://gitlab.gnome.org/GNOME/pygobject/blob/master/docs/packagingguide.rst
Move it to DEPENDS to shrink the runtime dependency chain, as setuptools
includes scripts to download other packages, which might not be desired on
a minimal image.
Signed-off-by: Luca Boccassi
---
v2: use -native suffix as requested during the code review
v3: do not add setuptools to DEPENDS - it is optional and it builds without it
meta/recipes-devtools/python/python3-pygobject_3.32.2.bb | 2 --
1 file changed, 2 deletions(-)
diff --git a/meta/recipes-devtools/python/python3-pygobject_3.32.2.bb
b/meta/recipes-devtools/python/python3-pygobject_3.32.2.bb
index 05688be603..453fdac2c8 100644
--- a/meta/recipes-devtools/python/python3-pygobject_3.32.2.bb
+++ b/meta/recipes-devtools/python/python3-pygobject_3.32.2.bb
@@ -27,7 +27,5 @@ PACKAGECONFIG ??=
"${@bb.utils.contains_any('DISTRO_FEATURES', [ 'directfb', 'wa
# we don't link against python3-pycairo -> RDEPENDS
PACKAGECONFIG[cairo] = "-Dpycairo=true,-Dpycairo=false, cairo python3-pycairo,
python3-pycairo"
-RDEPENDS_${PN} += "python3-setuptools"
-
BBCLASSEXTEND = "native"
PACKAGECONFIG_class-native = ""
--
2.20.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] python3-pygobject: move python3-setuptools from RDEPENDS to DEPENDS
On Thu, 2019-08-08 at 14:03 +0200, Alexander Kanavin wrote: > On Thu, 8 Aug 2019 at 13:47, wrote: > > -DEPENDS += "python3 glib-2.0" > > +DEPENDS += "python3 python3-setuptools-native glib-2.0" > > If this is required, then the build should fail, and it doesn't > (neither on the autobuilder, nor in my local setup). Is this really > needed? Does the build fail for you? > > Alex Hi, You are right, it doesn't fail - upstream lists it as optional. I do not know enough about this package to know how important it is - so I'll send a v3 that just removes the RDEPENDS, which is the one thing I cared about. Thanks! -- Kind regards, Luca Boccassi -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] python3-pygobject: move python3-setuptools from RDEPENDS to DEPENDS
> On 05/08/2019 11:52, luca.bocca...@gmail.com wrote: > > inherit gnomebase distutils3-base gobject-introspection upstream- > version-is-even > > > > -DEPENDS += "python3 glib-2.0" > > +DEPENDS += "python3 python3-setuptools glib-2.0" > > If setuptools is a build dependency then surely you mean > python3-setuptools-native. And if you need python3-setuptools- > native, > then just inherit setuptools3 instead of distutils3-base. > > Ross Hi, inheriting setuptools3 does not seem to work, the build fails: 2019-08-07T20:29:11.4006600Z [INFO] [10443] | /source/build- project/tmp/work/aarch64-project-linux/python3-pygobject/3.28.3- r0/recipe-sysroot-native/usr/bin/python3-native/python3: can't open file 'setup.py': [Errno 2] No such file or directory Using the -native suffix works, so sent a v2 doing that. Thanks! -- Kind regards, Luca Boccassi -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2] python3-pygobject: move python3-setuptools from RDEPENDS to DEPENDS
From: Luca Boccassi
python3-setuptools is necessary to build pygobject but not to run it, as
also documented by the upstream packaging guide:
https://gitlab.gnome.org/GNOME/pygobject/blob/master/docs/packagingguide.rst
Move it to DEPENDS to shrink the runtime dependency chain, as setuptools
includes scripts to download other packages, which might not be desired on
a minimal image.
Signed-off-by: Luca Boccassi
---
v2: use -native suffix as requested during the code review
meta/recipes-devtools/python/python3-pygobject_3.32.2.bb | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/meta/recipes-devtools/python/python3-pygobject_3.32.2.bb
b/meta/recipes-devtools/python/python3-pygobject_3.32.2.bb
index 05688be603..9e4ce31d8c 100644
--- a/meta/recipes-devtools/python/python3-pygobject_3.32.2.bb
+++ b/meta/recipes-devtools/python/python3-pygobject_3.32.2.bb
@@ -6,7 +6,7 @@ LIC_FILES_CHKSUM =
"file://COPYING;md5=a916467b91076e631dd8edb7424769c7"
GNOMEBASEBUILDCLASS = "meson"
inherit gnomebase distutils3-base gobject-introspection
upstream-version-is-even
-DEPENDS += "python3 glib-2.0"
+DEPENDS += "python3 python3-setuptools-native glib-2.0"
SRCNAME="pygobject"
@@ -27,7 +27,5 @@ PACKAGECONFIG ??=
"${@bb.utils.contains_any('DISTRO_FEATURES', [ 'directfb', 'wa
# we don't link against python3-pycairo -> RDEPENDS
PACKAGECONFIG[cairo] = "-Dpycairo=true,-Dpycairo=false, cairo python3-pycairo,
python3-pycairo"
-RDEPENDS_${PN} += "python3-setuptools"
-
BBCLASSEXTEND = "native"
PACKAGECONFIG_class-native = ""
--
2.20.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] python3-pygobject: move python3-setuptools from RDEPENDS to DEPENDS
From: Luca Boccassi
python3-setuptools is necessary to build pygobject but not to run it, as
also documented by the upstream packaging guide:
https://gitlab.gnome.org/GNOME/pygobject/blob/master/docs/packagingguide.rst
Move it to DEPENDS to shrink the runtime dependency chain, as setuptools
includes scripts to download other packages, which might not be desired on
a minimal image.
Signed-off-by: Luca Boccassi
---
meta/recipes-devtools/python/python3-pygobject_3.32.2.bb | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/meta/recipes-devtools/python/python3-pygobject_3.32.2.bb
b/meta/recipes-devtools/python/python3-pygobject_3.32.2.bb
index 05688be603..58a251f8eb 100644
--- a/meta/recipes-devtools/python/python3-pygobject_3.32.2.bb
+++ b/meta/recipes-devtools/python/python3-pygobject_3.32.2.bb
@@ -6,7 +6,7 @@ LIC_FILES_CHKSUM =
"file://COPYING;md5=a916467b91076e631dd8edb7424769c7"
GNOMEBASEBUILDCLASS = "meson"
inherit gnomebase distutils3-base gobject-introspection
upstream-version-is-even
-DEPENDS += "python3 glib-2.0"
+DEPENDS += "python3 python3-setuptools glib-2.0"
SRCNAME="pygobject"
@@ -27,7 +27,5 @@ PACKAGECONFIG ??=
"${@bb.utils.contains_any('DISTRO_FEATURES', [ 'directfb', 'wa
# we don't link against python3-pycairo -> RDEPENDS
PACKAGECONFIG[cairo] = "-Dpycairo=true,-Dpycairo=false, cairo python3-pycairo,
python3-pycairo"
-RDEPENDS_${PN} += "python3-setuptools"
-
BBCLASSEXTEND = "native"
PACKAGECONFIG_class-native = ""
--
2.20.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/2] nativesdk-*-provides-dummy: Fixes to allow correct operation with opkg
On Fri, 2019-06-28 at 17:57 +0100, richard.pur...@linuxfoundation.org wrote: > On Fri, 2019-06-28 at 16:52 +0000, Luca Boccassi wrote: > > 2019-06-27T13:18:54.5592415Z [WARN] [15902] Reading package > > lists... > > 2019-06-27T13:18:54.5592628Z [WARN] [15903] Building dependency > > tree... > > 2019-06-27T13:18:54.5593124Z [WARN] [15904] Some packages could not > > be installed. This may mean that you have > > 2019-06-27T13:18:54.5593526Z [WARN] [15905] requested an impossible > > situation or if you are using the unstable > > 2019-06-27T13:18:54.5593893Z [WARN] [15906] distribution that some > > required packages have not yet been created > > 2019-06-27T13:18:54.5599962Z [WARN] [15907] or been moved out of > > Incoming. > > 2019-06-27T13:18:54.5600415Z [WARN] [15908] The following > > information may help to resolve the situation: > > 2019-06-27T13:18:54.5600834Z [WARN] [15909] The following packages > > have unmet dependencies: > > 2019-06-27T13:18:54.5601383Z [WARN] [15910] target-sdk-provides- > > dummy : Conflicts: bash > > 2019-06-27T13:18:54.5601724Z [WARN] > > [15911] Conflicts: coreutils > > 2019-06-27T13:18:54.5602246Z [WARN] > > [15912] Conflicts: coreutils-dev > > 2019-06-27T13:18:54.5602590Z [WARN] > > [15913] Conflicts: perl > > 2019-06-27T13:18:54.5603147Z [WARN] > > [15914] Conflicts: perl-module-strict > > 2019-06-27T13:18:54.5603989Z [WARN] > > [15915] Conflicts: perl-module-vars > > 2019-06-27T13:18:54.5605346Z [WARN] > > [15916] Conflicts: perl-module- > > warnings > > 2019-06-27T13:18:54.5606090Z [WARN] [15917] E: Unable to correct > > problems, you have held broken packages. > > > > Same config worked fine in sumo. > > > > Any suggestion on how to fix it? Is it possible to enter the > > working > > directory to run apt manually, so that I can dig further into the > > dependency issue? > > Sadly such "enter a shell" functionality has never been implemented > so > that isn't possible. > > The message is basically saying that there are conflicted providers > of > some things the SDK is trying to remove (like bash, perl). Its likely > the dummy recipe isn't providing something which it needs to which > would then stop the other provider being pulled in. > > How to isolate what that is, I'm less sure about, there isn't an easy > way. I've just done it from package inspection in the past. > > Cheers, > > Richard Thanks - I'll try to get the packages out of the build directory and recreate the apt state in a chroot. Is there a test build of the SDK with a packages_deb configuration? The distro conf we use that triggers this failure is not that esoteric - pretty much standard stuff. -- Kind regards, Luca Boccassi -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/2] nativesdk-*-provides-dummy: Fixes to allow correct operation with opkg
4.5593526Z [WARN] [15905] requested an impossible situation or if you are using the unstable 2019-06-27T13:18:54.5593893Z [WARN] [15906] distribution that some required packages have not yet been created 2019-06-27T13:18:54.5599962Z [WARN] [15907] or been moved out of Incoming. 2019-06-27T13:18:54.5600415Z [WARN] [15908] The following information may help to resolve the situation: 2019-06-27T13:18:54.5600834Z [WARN] [15909] The following packages have unmet dependencies: 2019-06-27T13:18:54.5601383Z [WARN] [15910] target-sdk-provides-dummy : Conflicts: bash 2019-06-27T13:18:54.5601724Z [WARN] [15911] Conflicts: coreutils 2019-06-27T13:18:54.5602246Z [WARN] [15912] Conflicts: coreutils-dev 2019-06-27T13:18:54.5602590Z [WARN] [15913] Conflicts: perl 2019-06-27T13:18:54.5603147Z [WARN] [15914] Conflicts: perl-module-strict 2019-06-27T13:18:54.5603989Z [WARN] [15915] Conflicts: perl-module-vars 2019-06-27T13:18:54.5605346Z [WARN] [15916] Conflicts: perl-module-warnings 2019-06-27T13:18:54.5606090Z [WARN] [15917] E: Unable to correct problems, you have held broken packages. Same config worked fine in sumo. Any suggestion on how to fix it? Is it possible to enter the working directory to run apt manually, so that I can dig further into the dependency issue? Thanks! -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [meta-oe,v2] kernel-fitimage: introduce FIT_HASH_ALG
On Wed, 2019-06-19 at 10:06 +0100, Alex Kiernan wrote:
> On Wed, Jun 19, 2019 at 9:48 AM Luca Boccassi <
> luca.bocca...@gmail.com
> > wrote:
> > On Tue, 2019-06-18 at 17:11 +0100, Richard Purdie wrote:
> > > On Tue, 2019-06-18 at 08:53 -0700, Khem Raj wrote:
> > > > On Tue, Jun 18, 2019 at 1:26 AM Luca Boccassi <
> > > > luca.bocca...@gmail.com
> > > >
> > > > > wrote:
> > > > > On Thu, 2017-11-02 at 16:48 +0100, Ayoub Zaki wrote:
> > > > > > sanitize fitImage hash algorithm selection with
> > > > > > FIT_HASH_ALG
> > > > > > switch default hash algorithm from sha1 to sha256
> > > > > >
> > > > > > Signed-off-by: Ayoub Zaki <
> > > > > > ayoub.z...@embexus.com
> > > > > >
> > > > > >
> > > > > > Acked-by: Denys Dmytriyenko <
> > > > > > de...@ti.com
> > > > > >
> > > > > >
> > > > > > ---
> > > > > > meta/classes/kernel-fitimage.bbclass | 13 -
> > > > > > 1 file changed, 8 insertions(+), 5 deletions(-)
> > > > > >
> > > > > > diff --git a/meta/classes/kernel-fitimage.bbclass
> > > > > > b/meta/classes/kernel-fitimage.bbclass
> > > > > > index 179185b..3cc3a33 100644
> > > > > > --- a/meta/classes/kernel-fitimage.bbclass
> > > > > > +++ b/meta/classes/kernel-fitimage.bbclass
> > > > > > @@ -36,6 +36,9 @@ python __anonymous () {
> > > > > > # Options for the device tree compiler passed to mkimage
> > > > > > '-D'
> > > > > > feature:
> > > > > > UBOOT_MKIMAGE_DTCOPTS ??= ""
> > > > > >
> > > > > > +# fitImage Hash Algo
> > > > > > +FIT_HASH_ALG ?= "sha256"
>
> Should this be ??=
>
> > > > > > +
> > > > > > #
> > > > > > # Emit the fitImage ITS header
> > > > > > #
> > > > > > @@ -95,7 +98,7 @@ EOF
> > > > > > # $4 ... Compression type
> > > > > > fitimage_emit_section_kernel() {
> > > > > >
> > > > > > - kernel_csum="sha1"
> > > > > > + kernel_csum="${FIT_HASH_ALG}"
> > > > > >
> > > > > > ENTRYPOINT=${UBOOT_ENTRYPOINT}
> > > > > > if [ -n "${UBOOT_ENTRYSYMBOL}" ]; then
> > > > > > @@ -128,7 +131,7 @@ EOF
> > > > > > # $3 ... Path to DTB image
> > > > > > fitimage_emit_section_dtb() {
> > > > > >
> > > > > > - dtb_csum="sha1"
> > > > > > + dtb_csum="${FIT_HASH_ALG}"
> > > > > >
> > > > > > cat << EOF >> ${1}
> > > > > > fdt@${2} {
> > > > > > @@ -152,7 +155,7 @@ EOF
> > > > > > # $3 ... Path to setup image
> > > > > > fitimage_emit_section_setup() {
> > > > > >
> > > > > > - setup_csum="sha1"
> > > > > > + setup_csum="${FIT_HASH_ALG}"
> > > > > >
> > > > > > cat << EOF >> ${1}
> > > > > > setup@${2} {
> > > > > > @@ -179,7 +182,7 @@ EOF
> > > > > > # $3 ... Path to ramdisk image
> > > > > > fitimage_emit_section_ramdisk() {
> > > > > >
> > > > > > - ramdisk_csum="sha1"
> > > > > > + ramdisk_csum="${FIT_HASH_ALG}"
> > > > > > ramdisk_ctype="none"
> > > > > > ramdisk_loadline=""
> > > > > > ramdisk_entryline=""
> > > > > > @@ -237,7 +240,7 @@ EOF
> > > > > > # $6 ... default flag
> > > > > > fitimage_emit_section_config() {
> > > > > >
> > > > > > - conf_csum="sha1"
> > > > > > + conf_csum="${FIT_HASH_ALG}"
> > > > > > if [ -n "${UBOOT_SIGN_ENABLE}" ] ; then
> > > > > > conf_sign_keyname="${UBOOT_SIGN_KEYNAME}"
> > > > > > fi
> > > > >
> > > > > Hi,
> > > > >
> > > > > Any update on this patch? It was acked almost 2 years ago.
> > > > >
> > > > > It would be great to have a way to change the hashsum
> > > > > algorithm
> > > > > when
> > > > > building signed images.
> > > > >
> > > >
> > > > I agree, but it would be good to resend this patch on top of
> > > > current
> > > > master
> > >
> > > I managed to apply it to master so its in testing now.
> > >
> > > My concerns about the lack of tests for this class are the main
> > > reason
> > > patches here get held up.
> > >
> > > Cheers,
> > >
> > > Richard
> >
> > Thanks Richard - in case it helps, we've been using this patch for
> > a
> > few months at $work (on top of sumo) and it seems to work fine.
> >
>
> I expect that's true for everyone touching stuff in this class - it
> works fine for them... the problem is everyone else, since it's
> terribly fragile and has no tests.
>
> I'd not be at all surprised if changing the default from sha1 to
> sha256 doesn't break someone.
Keeping the default to sha1 would be fine by me, it's the ability to
configure it that is useful.
--
Kind regards,
Luca Boccassi
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [meta-oe,v2] kernel-fitimage: introduce FIT_HASH_ALG
On Tue, 2019-06-18 at 17:11 +0100, Richard Purdie wrote:
> On Tue, 2019-06-18 at 08:53 -0700, Khem Raj wrote:
> > On Tue, Jun 18, 2019 at 1:26 AM Luca Boccassi <
> > luca.bocca...@gmail.com
> > > wrote:
> > > On Thu, 2017-11-02 at 16:48 +0100, Ayoub Zaki wrote:
> > > > sanitize fitImage hash algorithm selection with FIT_HASH_ALG
> > > > switch default hash algorithm from sha1 to sha256
> > > >
> > > > Signed-off-by: Ayoub Zaki <
> > > > ayoub.z...@embexus.com
> > > >
> > > > Acked-by: Denys Dmytriyenko <
> > > > de...@ti.com
> > > >
> > > > ---
> > > > meta/classes/kernel-fitimage.bbclass | 13 -
> > > > 1 file changed, 8 insertions(+), 5 deletions(-)
> > > >
> > > > diff --git a/meta/classes/kernel-fitimage.bbclass
> > > > b/meta/classes/kernel-fitimage.bbclass
> > > > index 179185b..3cc3a33 100644
> > > > --- a/meta/classes/kernel-fitimage.bbclass
> > > > +++ b/meta/classes/kernel-fitimage.bbclass
> > > > @@ -36,6 +36,9 @@ python __anonymous () {
> > > > # Options for the device tree compiler passed to mkimage '-D'
> > > > feature:
> > > > UBOOT_MKIMAGE_DTCOPTS ??= ""
> > > >
> > > > +# fitImage Hash Algo
> > > > +FIT_HASH_ALG ?= "sha256"
> > > > +
> > > > #
> > > > # Emit the fitImage ITS header
> > > > #
> > > > @@ -95,7 +98,7 @@ EOF
> > > > # $4 ... Compression type
> > > > fitimage_emit_section_kernel() {
> > > >
> > > > - kernel_csum="sha1"
> > > > + kernel_csum="${FIT_HASH_ALG}"
> > > >
> > > > ENTRYPOINT=${UBOOT_ENTRYPOINT}
> > > > if [ -n "${UBOOT_ENTRYSYMBOL}" ]; then
> > > > @@ -128,7 +131,7 @@ EOF
> > > > # $3 ... Path to DTB image
> > > > fitimage_emit_section_dtb() {
> > > >
> > > > - dtb_csum="sha1"
> > > > + dtb_csum="${FIT_HASH_ALG}"
> > > >
> > > > cat << EOF >> ${1}
> > > > fdt@${2} {
> > > > @@ -152,7 +155,7 @@ EOF
> > > > # $3 ... Path to setup image
> > > > fitimage_emit_section_setup() {
> > > >
> > > > - setup_csum="sha1"
> > > > + setup_csum="${FIT_HASH_ALG}"
> > > >
> > > > cat << EOF >> ${1}
> > > > setup@${2} {
> > > > @@ -179,7 +182,7 @@ EOF
> > > > # $3 ... Path to ramdisk image
> > > > fitimage_emit_section_ramdisk() {
> > > >
> > > > - ramdisk_csum="sha1"
> > > > + ramdisk_csum="${FIT_HASH_ALG}"
> > > > ramdisk_ctype="none"
> > > > ramdisk_loadline=""
> > > > ramdisk_entryline=""
> > > > @@ -237,7 +240,7 @@ EOF
> > > > # $6 ... default flag
> > > > fitimage_emit_section_config() {
> > > >
> > > > - conf_csum="sha1"
> > > > + conf_csum="${FIT_HASH_ALG}"
> > > > if [ -n "${UBOOT_SIGN_ENABLE}" ] ; then
> > > > conf_sign_keyname="${UBOOT_SIGN_KEYNAME}"
> > > > fi
> > >
> > > Hi,
> > >
> > > Any update on this patch? It was acked almost 2 years ago.
> > >
> > > It would be great to have a way to change the hashsum algorithm
> > > when
> > > building signed images.
> > >
> >
> > I agree, but it would be good to resend this patch on top of
> > current
> > master
>
> I managed to apply it to master so its in testing now.
>
> My concerns about the lack of tests for this class are the main
> reason
> patches here get held up.
>
> Cheers,
>
> Richard
Thanks Richard - in case it helps, we've been using this patch for a
few months at $work (on top of sumo) and it seems to work fine.
--
Kind regards,
Luca Boccassi
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [meta-oe,v2] kernel-fitimage: introduce FIT_HASH_ALG
On Thu, 2017-11-02 at 16:48 +0100, Ayoub Zaki wrote:
> sanitize fitImage hash algorithm selection with FIT_HASH_ALG
> switch default hash algorithm from sha1 to sha256
>
> Signed-off-by: Ayoub Zaki <
> ayoub.z...@embexus.com
> >
> Acked-by: Denys Dmytriyenko <
> de...@ti.com
> >
> ---
> meta/classes/kernel-fitimage.bbclass | 13 -
> 1 file changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/meta/classes/kernel-fitimage.bbclass
> b/meta/classes/kernel-fitimage.bbclass
> index 179185b..3cc3a33 100644
> --- a/meta/classes/kernel-fitimage.bbclass
> +++ b/meta/classes/kernel-fitimage.bbclass
> @@ -36,6 +36,9 @@ python __anonymous () {
> # Options for the device tree compiler passed to mkimage '-D'
> feature:
> UBOOT_MKIMAGE_DTCOPTS ??= ""
>
> +# fitImage Hash Algo
> +FIT_HASH_ALG ?= "sha256"
> +
> #
> # Emit the fitImage ITS header
> #
> @@ -95,7 +98,7 @@ EOF
> # $4 ... Compression type
> fitimage_emit_section_kernel() {
>
> - kernel_csum="sha1"
> + kernel_csum="${FIT_HASH_ALG}"
>
> ENTRYPOINT=${UBOOT_ENTRYPOINT}
> if [ -n "${UBOOT_ENTRYSYMBOL}" ]; then
> @@ -128,7 +131,7 @@ EOF
> # $3 ... Path to DTB image
> fitimage_emit_section_dtb() {
>
> - dtb_csum="sha1"
> + dtb_csum="${FIT_HASH_ALG}"
>
> cat << EOF >> ${1}
> fdt@${2} {
> @@ -152,7 +155,7 @@ EOF
> # $3 ... Path to setup image
> fitimage_emit_section_setup() {
>
> - setup_csum="sha1"
> + setup_csum="${FIT_HASH_ALG}"
>
> cat << EOF >> ${1}
> setup@${2} {
> @@ -179,7 +182,7 @@ EOF
> # $3 ... Path to ramdisk image
> fitimage_emit_section_ramdisk() {
>
> - ramdisk_csum="sha1"
> + ramdisk_csum="${FIT_HASH_ALG}"
> ramdisk_ctype="none"
> ramdisk_loadline=""
> ramdisk_entryline=""
> @@ -237,7 +240,7 @@ EOF
> # $6 ... default flag
> fitimage_emit_section_config() {
>
> - conf_csum="sha1"
> + conf_csum="${FIT_HASH_ALG}"
> if [ -n "${UBOOT_SIGN_ENABLE}" ] ; then
> conf_sign_keyname="${UBOOT_SIGN_KEYNAME}"
> fi
Hi,
Any update on this patch? It was acked almost 2 years ago.
It would be great to have a way to change the hashsum algorithm when
building signed images.
Thanks!
--
Kind regards,
Luca Boccassi
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] volatile-binds: Change cp to use -a instead of -p.
From: Chris PeBenito This is needed on SELinux systems, so the labels (xattrs) are preserved. Signed-off-by: Chris PeBenito --- meta/recipes-core/volatile-binds/files/mount-copybind | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/meta/recipes-core/volatile-binds/files/mount-copybind b/meta/recipes-core/volatile-binds/files/mount-copybind index fddf520053..e32e675308 100755 --- a/meta/recipes-core/volatile-binds/files/mount-copybind +++ b/meta/recipes-core/volatile-binds/files/mount-copybind @@ -42,14 +42,14 @@ if [ -d "$mountpoint" ]; then if ! mount -t overlay overlay -olowerdir="$mountpoint",upperdir="$spec",workdir="$overlay_workdir" "$mountpoint" > /dev/null 2>&1; then if [ "$specdir_existed" != "yes" ]; then -cp -pPR "$mountpoint"/. "$spec/" +cp -aPR "$mountpoint"/. "$spec/" fi mount -o "bind$options" "$spec" "$mountpoint" fi elif [ -f "$mountpoint" ]; then if [ ! -f "$spec" ]; then -cp -pP "$mountpoint" "$spec" +cp -aP "$mountpoint" "$spec" fi mount -o "bind$options" "$spec" "$mountpoint" -- 2.20.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v4] python*-setuptools: add separate packages for pkg_resources module
On Fri, 2019-05-24 at 10:29 -0700, Khem Raj wrote:
> On Wed, May 22, 2019 at 3:58 AM Luca Boccassi m> wrote:
> >
> > On Tue, 2019-05-21 at 19:06 -0700, Khem Raj wrote:
> > > On Tue, May 21, 2019 at 5:36 AM <
> > > luca.bocca...@gmail.com
> > > > wrote:
> > > > From: Luca Boccassi <
> > > > luca.bocca...@microsoft.com
> > > > >
> > > >
> > > > The pkg_resources Python module is useful by itself, for
> > > > example
> > > > for
> > > > automatic loading of resources shipped in a Python package.
> > > > Add separate packages for it, so that users can depend on them
> > > > individually and avoid pulling in the entire setuptools, which
> > > > include scripts to download other packages, which might not be
> > > > desired on minimal images.
> > > >
> > > > Other distributions like Debian and Ubuntu already split
> > > > setuptools
> > > > and pkg-resources in this way.
> > > >
> > > > The setuptools packages now depend on the new pkg-resources
> > > > packages,
> > > > to avoid regressions for other packages that depend on them
> > > > already.
> > > >
> > > > Signed-off-by: Luca Boccassi <
> > > > luca.bocca...@microsoft.com
> > > > >
> > > >
> > > > ---
> > > > v2: restrict new RDEPENDS to class-target. As advised by
> > > > Alexander,
> > > > bitbake
> > > > cannot resolve native rdeps that mention package names
> > > > rather
> > > > than
> > > > recipe names.
> > > > v3: manually add RPROVIDES to the native class instead of
> > > > restricting the
> > > > RDEPENDS to the target class as a better workaround. Also
> > > > document why
> > > > the package is being split.
> > > > v4: re-send to the correct thread, no changes.
> > > >
> > > > Â meta/recipes-devtools/python/python-setuptools.inc | 11
> > > > +++
> > > > Â 1 file changed, 11 insertions(+)
> > > >
> > > > diff --git a/meta/recipes-devtools/python/python-setuptools.inc
> > > > b/meta/recipes-devtools/python/python-setuptools.inc
> > > > index 357aa07086..f49e078697 100644
> > > > --- a/meta/recipes-devtools/python/python-setuptools.inc
> > > > +++ b/meta/recipes-devtools/python/python-setuptools.inc
> > > > @@ -37,3 +37,14 @@ do_install_prepend() {
> > > > Â }
> > > >
> > > > Â BBCLASSEXTEND = "native nativesdk"
> > > > +
> > > > +# The pkg-resources module can be used by itself, without the
> > > > package downloader
> > > > +# and easy_install. Ship it in a separate package so that it
> > > > can
> > > > be used by
> > > > +# minimal distributions.
> > > > +PACKAGES =+ "${PYTHON_PN}-pkg-resources "
> > > > +FILES_${PYTHON_PN}-pkg-resources =
> > > > "${PYTHON_SITEPACKAGES_DIR}/pkg_resources/*"
> > > > +# Due to the way OE-Core implemented native recipes, the
> > > > native
> > > > class cannot
> > > > +# have a dependency on something that is not a recipe name.
> > > > Work
> > > > around that by
> > > > +# manually setting RPROVIDES.
> > > > +RDEPENDS_${PN}_append = " ${PYTHON_PN}-pkg-resources"
> > > > +RPROVIDES_append_class-native = " ${PYTHON_PN}-pkg-resources-
> > > > native"
> > >
> > > do we need to handle nativesdk case ?
> >
> > Hi,
> >
> > The parsing step of "bitbake core-image-minimal -c populate_sdk"
> > works,
> > while without the append_class-native workaround it fails
> > immediately.
> > Is this enough or is there something else I should run to check?
> >
>
> yeah usually to test nativesdk we need to do it with generated SDK
I do have a nativesdk target in the distro at $work, but I realise it
might be different enough. Is there a simple config change/command to
generate it from Poky?
--
Kind regards,
Luca Boccassi
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] mdadm: use ${systemd_unitdir} rather than /lib/systemd
From: Luca Boccassi
Fixes build with usrmerge enabled.
Signed-off-by: Luca Boccassi
---
meta/recipes-extended/mdadm/mdadm_4.1.bb | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-extended/mdadm/mdadm_4.1.bb
b/meta/recipes-extended/mdadm/mdadm_4.1.bb
index 597faf787a..40fe376a79 100644
--- a/meta/recipes-extended/mdadm/mdadm_4.1.bb
+++ b/meta/recipes-extended/mdadm/mdadm_4.1.bb
@@ -45,7 +45,7 @@ DEBUG_OPTIMIZATION_append = " -Wno-error"
do_compile() {
# Point to right sbindir
- sed -i -e "s;BINDIR = /sbin;BINDIR = $base_sbindir;" -e "s;UDEVDIR =
/lib;UDEVDIR = $nonarch_base_libdir;" ${S}/Makefile
+ sed -i -e "s;BINDIR = /sbin;BINDIR = $base_sbindir;" -e "s;UDEVDIR =
/lib;UDEVDIR = $nonarch_base_libdir;" -e
"s;SYSTEMD_DIR=/lib/systemd/system;SYSTEMD_DIR=${systemd_unitdir}/system;"
${S}/Makefile
oe_runmake SYSROOT="${STAGING_DIR_TARGET}"
}
@@ -93,4 +93,4 @@ RRECOMMENDS_${PN}-ptest += " \
kernel-module-raid456 \
"
-FILES_${PN} += "/lib/systemd/*"
+FILES_${PN} += "${systemd_unitdir}/*"
--
2.20.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v4] python*-setuptools: add separate packages for pkg_resources module
On Tue, 2019-05-21 at 19:06 -0700, Khem Raj wrote:
> On Tue, May 21, 2019 at 5:36 AM <
> luca.bocca...@gmail.com
> > wrote:
> > From: Luca Boccassi <
> > luca.bocca...@microsoft.com
> > >
> >
> > The pkg_resources Python module is useful by itself, for example
> > for
> > automatic loading of resources shipped in a Python package.
> > Add separate packages for it, so that users can depend on them
> > individually and avoid pulling in the entire setuptools, which
> > include scripts to download other packages, which might not be
> > desired on minimal images.
> >
> > Other distributions like Debian and Ubuntu already split setuptools
> > and pkg-resources in this way.
> >
> > The setuptools packages now depend on the new pkg-resources
> > packages,
> > to avoid regressions for other packages that depend on them
> > already.
> >
> > Signed-off-by: Luca Boccassi <
> > luca.bocca...@microsoft.com
> > >
> > ---
> > v2: restrict new RDEPENDS to class-target. As advised by Alexander,
> > bitbake
> > cannot resolve native rdeps that mention package names rather
> > than
> > recipe names.
> > v3: manually add RPROVIDES to the native class instead of
> > restricting the
> > RDEPENDS to the target class as a better workaround. Also
> > document why
> > the package is being split.
> > v4: re-send to the correct thread, no changes.
> >
> > meta/recipes-devtools/python/python-setuptools.inc | 11
> > +++
> > 1 file changed, 11 insertions(+)
> >
> > diff --git a/meta/recipes-devtools/python/python-setuptools.inc
> > b/meta/recipes-devtools/python/python-setuptools.inc
> > index 357aa07086..f49e078697 100644
> > --- a/meta/recipes-devtools/python/python-setuptools.inc
> > +++ b/meta/recipes-devtools/python/python-setuptools.inc
> > @@ -37,3 +37,14 @@ do_install_prepend() {
> > }
> >
> > BBCLASSEXTEND = "native nativesdk"
> > +
> > +# The pkg-resources module can be used by itself, without the
> > package downloader
> > +# and easy_install. Ship it in a separate package so that it can
> > be used by
> > +# minimal distributions.
> > +PACKAGES =+ "${PYTHON_PN}-pkg-resources "
> > +FILES_${PYTHON_PN}-pkg-resources =
> > "${PYTHON_SITEPACKAGES_DIR}/pkg_resources/*"
> > +# Due to the way OE-Core implemented native recipes, the native
> > class cannot
> > +# have a dependency on something that is not a recipe name. Work
> > around that by
> > +# manually setting RPROVIDES.
> > +RDEPENDS_${PN}_append = " ${PYTHON_PN}-pkg-resources"
> > +RPROVIDES_append_class-native = " ${PYTHON_PN}-pkg-resources-
> > native"
>
> do we need to handle nativesdk case ?
Hi,
The parsing step of "bitbake core-image-minimal -c populate_sdk" works,
while without the append_class-native workaround it fails immediately.
Is this enough or is there something else I should run to check?
Thanks!
--
Kind regards,
Luca Boccassi
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v4] python*-setuptools: add separate packages for pkg_resources module
From: Luca Boccassi
The pkg_resources Python module is useful by itself, for example for
automatic loading of resources shipped in a Python package.
Add separate packages for it, so that users can depend on them
individually and avoid pulling in the entire setuptools, which
include scripts to download other packages, which might not be
desired on minimal images.
Other distributions like Debian and Ubuntu already split setuptools
and pkg-resources in this way.
The setuptools packages now depend on the new pkg-resources packages,
to avoid regressions for other packages that depend on them
already.
Signed-off-by: Luca Boccassi
---
v2: restrict new RDEPENDS to class-target. As advised by Alexander, bitbake
cannot resolve native rdeps that mention package names rather than
recipe names.
v3: manually add RPROVIDES to the native class instead of restricting the
RDEPENDS to the target class as a better workaround. Also document why
the package is being split.
v4: re-send to the correct thread, no changes.
meta/recipes-devtools/python/python-setuptools.inc | 11 +++
1 file changed, 11 insertions(+)
diff --git a/meta/recipes-devtools/python/python-setuptools.inc
b/meta/recipes-devtools/python/python-setuptools.inc
index 357aa07086..f49e078697 100644
--- a/meta/recipes-devtools/python/python-setuptools.inc
+++ b/meta/recipes-devtools/python/python-setuptools.inc
@@ -37,3 +37,14 @@ do_install_prepend() {
}
BBCLASSEXTEND = "native nativesdk"
+
+# The pkg-resources module can be used by itself, without the package
downloader
+# and easy_install. Ship it in a separate package so that it can be used by
+# minimal distributions.
+PACKAGES =+ "${PYTHON_PN}-pkg-resources "
+FILES_${PYTHON_PN}-pkg-resources = "${PYTHON_SITEPACKAGES_DIR}/pkg_resources/*"
+# Due to the way OE-Core implemented native recipes, the native class cannot
+# have a dependency on something that is not a recipe name. Work around that by
+# manually setting RPROVIDES.
+RDEPENDS_${PN}_append = " ${PYTHON_PN}-pkg-resources"
+RPROVIDES_append_class-native = " ${PYTHON_PN}-pkg-resources-native"
--
2.20.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v3] python*-setuptools: add separate packages for pkg_resources module
On Tue, 2019-05-21 at 13:34 +0100, luca.bocca...@gmail.com wrote:
> From: Luca Boccassi <
> luca.bocca...@microsoft.com
> >
>
> The pkg_resources Python module is useful by itself, for example for
> automatic loading of resources shipped in a Python package.
> Add separate packages for it, so that users can depend on them
> individually and avoid pulling in the entire setuptools, which
> include scripts to download other packages, which might not be
> desired on minimal images.
>
> Other distributions like Debian and Ubuntu already split setuptools
> and pkg-resources in this way.
>
> The setuptools packages now depend on the new pkg-resources packages,
> to avoid regressions for other packages that depend on them
> already.
>
> Signed-off-by: Luca Boccassi <
> luca.bocca...@microsoft.com
> >
> ---
>
> v2: restrict new RDEPENDS to class-target. As advised by Alexander,
> bitbake
> cannot resolve native rdeps that mention package names rather
> than
> recipe names.
> v3: manually add RPROVIDES to the native class instead of restricting
> the
> RDEPENDS to the target class as a better workaround. Also
> document why
> the package is being split.
>
> meta/recipes-devtools/python/python-setuptools.inc | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/meta/recipes-devtools/python/python-setuptools.inc
> b/meta/recipes-devtools/python/python-setuptools.inc
> index 357aa07086..f49e078697 100644
> --- a/meta/recipes-devtools/python/python-setuptools.inc
> +++ b/meta/recipes-devtools/python/python-setuptools.inc
> @@ -37,3 +37,14 @@ do_install_prepend() {
> }
>
> BBCLASSEXTEND = "native nativesdk"
> +
> +# The pkg-resources module can be used by itself, without the
> package downloader
> +# and easy_install. Ship it in a separate package so that it can be
> used by
> +# minimal distributions.
> +PACKAGES =+ "${PYTHON_PN}-pkg-resources "
> +FILES_${PYTHON_PN}-pkg-resources =
> "${PYTHON_SITEPACKAGES_DIR}/pkg_resources/*"
> +# Due to the way OE-Core implemented native recipes, the native
> class cannot
> +# have a dependency on something that is not a recipe name. Work
> around that by
> +# manually setting RPROVIDES.
> +RDEPENDS_${PN}_append = " ${PYTHON_PN}-pkg-resources"
> +RPROVIDES_append_class-native = " ${PYTHON_PN}-pkg-resources-native"
>
Sorry, wrong in-reply-to, resending.
--
Kind regards,
Luca Boccassi
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v3] python*-setuptools: add separate packages for pkg_resources module
From: Luca Boccassi
The pkg_resources Python module is useful by itself, for example for
automatic loading of resources shipped in a Python package.
Add separate packages for it, so that users can depend on them
individually and avoid pulling in the entire setuptools, which
include scripts to download other packages, which might not be
desired on minimal images.
Other distributions like Debian and Ubuntu already split setuptools
and pkg-resources in this way.
The setuptools packages now depend on the new pkg-resources packages,
to avoid regressions for other packages that depend on them
already.
Signed-off-by: Luca Boccassi
---
v2: restrict new RDEPENDS to class-target. As advised by Alexander, bitbake
cannot resolve native rdeps that mention package names rather than
recipe names.
v3: manually add RPROVIDES to the native class instead of restricting the
RDEPENDS to the target class as a better workaround. Also document why
the package is being split.
meta/recipes-devtools/python/python-setuptools.inc | 11 +++
1 file changed, 11 insertions(+)
diff --git a/meta/recipes-devtools/python/python-setuptools.inc
b/meta/recipes-devtools/python/python-setuptools.inc
index 357aa07086..f49e078697 100644
--- a/meta/recipes-devtools/python/python-setuptools.inc
+++ b/meta/recipes-devtools/python/python-setuptools.inc
@@ -37,3 +37,14 @@ do_install_prepend() {
}
BBCLASSEXTEND = "native nativesdk"
+
+# The pkg-resources module can be used by itself, without the package
downloader
+# and easy_install. Ship it in a separate package so that it can be used by
+# minimal distributions.
+PACKAGES =+ "${PYTHON_PN}-pkg-resources "
+FILES_${PYTHON_PN}-pkg-resources = "${PYTHON_SITEPACKAGES_DIR}/pkg_resources/*"
+# Due to the way OE-Core implemented native recipes, the native class cannot
+# have a dependency on something that is not a recipe name. Work around that by
+# manually setting RPROVIDES.
+RDEPENDS_${PN}_append = " ${PYTHON_PN}-pkg-resources"
+RPROVIDES_append_class-native = " ${PYTHON_PN}-pkg-resources-native"
--
2.20.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2] python*-setuptools: add separate packages for pkg_resources module
From: Luca Boccassi
The pkg_resources Python module is useful by itself, for example for
automatic loading of resources shipped in a Python package.
Add separate packages for it, so that users can depend on them
individually and avoid pulling in the entire setuptools, which
include scripts to download other packages, which might not be
desired on minimal images.
Other distributions like Debian and Ubuntu already split setuptools
and pkg-resources in this way.
The setuptools packages now depend on the new pkg-resources packages,
to avoid regressions for other packages that depend on them
already.
Signed-off-by: Luca Boccassi
---
v2: restrict new RDEPENDS to class-target. As advised by Alexander, bitbake
cannot resolve native rdeps that mention package names rather than
recipe names.
meta/recipes-devtools/python/python-setuptools.inc | 6 ++
1 file changed, 6 insertions(+)
diff --git a/meta/recipes-devtools/python/python-setuptools.inc
b/meta/recipes-devtools/python/python-setuptools.inc
index 357aa07086..c5dcee7059 100644
--- a/meta/recipes-devtools/python/python-setuptools.inc
+++ b/meta/recipes-devtools/python/python-setuptools.inc
@@ -37,3 +37,9 @@ do_install_prepend() {
}
BBCLASSEXTEND = "native nativesdk"
+
+PACKAGES =+ "${PYTHON_PN}-pkg-resources "
+FILES_${PYTHON_PN}-pkg-resources = "${PYTHON_SITEPACKAGES_DIR}/pkg_resources/*"
+# Due to a bitbake bug, the native class cannot have a dependency on something
+# that is not a recipe name.
+RDEPENDS_${PN}_append_class-target = " ${PYTHON_PN}-pkg-resources"
--
2.20.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] python*-setuptools: add separate packages for pkg_resources module
On Mon, 2019-05-20 at 15:14 +0100, Richard Purdie wrote:
> On Thu, 2019-05-16 at 22:09 +0100,
> luca.bocca...@gmail.com
> wrote:
> > From: Luca Boccassi <
> > luca.bocca...@microsoft.com
> > >
> >
> > The pkg_resources Python module is useful by itself, for example
> > for
> > automatic loading of resources shipped in a Python package.
> > Add separate packages for it, so that users can depend on them
> > individually and avoid pulling in the entire setuptools, which
> > include scripts to download other packages, which might not be
> > desired on minimal images.
> >
> > Other distributions like Debian and Ubuntu already split setuptools
> > and pkg-resources in this way.
> >
> > The setuptools packages now depend on the new pkg-resources
> > packages,
> > to avoid regressions for other packages that depend on them
> > already.
> >
> > Signed-off-by: Luca Boccassi <
> > luca.bocca...@microsoft.com
> > >
> > ---
> > meta/recipes-devtools/python/python-setuptools.inc | 4
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/meta/recipes-devtools/python/python-setuptools.inc
> > b/meta/recipes-devtools/python/python-setuptools.inc
> > index 357aa07086..ad00cbe0ef 100644
> > --- a/meta/recipes-devtools/python/python-setuptools.inc
> > +++ b/meta/recipes-devtools/python/python-setuptools.inc
> > @@ -24,6 +24,7 @@ RDEPENDS_${PN} = "\
> >${PYTHON_PN}-html \
> >${PYTHON_PN}-netserver \
> >${PYTHON_PN}-numbers \
> > + ${PYTHON_PN}-pkg-resources \
> >${PYTHON_PN}-pkgutil \
> >${PYTHON_PN}-plistlib \
> >${PYTHON_PN}-shell \
> > @@ -37,3 +38,6 @@ do_install_prepend() {
> > }
> >
> > BBCLASSEXTEND = "native nativesdk"
> > +
> > +PACKAGES =+ "${PYTHON_PN}-pkg-resources "
> > +FILES_${PYTHON_PN}-pkg-resources =
> > "${PYTHON_SITEPACKAGES_DIR}/pkg_resources/*"
>
>
> This breaks native builds:
>
> https://autobuilder.yoctoproject.org/typhoon/#/builders/65/builds/614
>
>
> (and many other similar failures)
>
> Cheers,
>
> Richard
Hello Richard,
Thanks for the heads-up, any suggestion as to why the above patch
wouldn't be enough to build both native and target binary packages for
$python-pkg-resources?
--
Kind regards,
Luca Boccassi
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] python*-setuptools: add separate packages for pkg_resources module
From: Luca Boccassi
The pkg_resources Python module is useful by itself, for example for
automatic loading of resources shipped in a Python package.
Add separate packages for it, so that users can depend on them
individually and avoid pulling in the entire setuptools, which
include scripts to download other packages, which might not be
desired on minimal images.
Other distributions like Debian and Ubuntu already split setuptools
and pkg-resources in this way.
The setuptools packages now depend on the new pkg-resources packages,
to avoid regressions for other packages that depend on them
already.
Signed-off-by: Luca Boccassi
---
meta/recipes-devtools/python/python-setuptools.inc | 4
1 file changed, 4 insertions(+)
diff --git a/meta/recipes-devtools/python/python-setuptools.inc
b/meta/recipes-devtools/python/python-setuptools.inc
index 357aa07086..ad00cbe0ef 100644
--- a/meta/recipes-devtools/python/python-setuptools.inc
+++ b/meta/recipes-devtools/python/python-setuptools.inc
@@ -24,6 +24,7 @@ RDEPENDS_${PN} = "\
${PYTHON_PN}-html \
${PYTHON_PN}-netserver \
${PYTHON_PN}-numbers \
+ ${PYTHON_PN}-pkg-resources \
${PYTHON_PN}-pkgutil \
${PYTHON_PN}-plistlib \
${PYTHON_PN}-shell \
@@ -37,3 +38,6 @@ do_install_prepend() {
}
BBCLASSEXTEND = "native nativesdk"
+
+PACKAGES =+ "${PYTHON_PN}-pkg-resources "
+FILES_${PYTHON_PN}-pkg-resources = "${PYTHON_SITEPACKAGES_DIR}/pkg_resources/*"
--
2.20.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] systemd: enable portabled by default
On Mon, 2019-05-13 at 08:24 -0700, Khem Raj wrote: > > > On Mon, May 13, 2019 at 3:10 AM Luca Boccassi < > luca.bocca...@gmail.com> wrote: > > On Fri, 2019-05-10 at 09:45 -0700, Khem Raj wrote: > > > On Fri, May 10, 2019 at 5:10 AM < > > > luca.bocca...@gmail.com > > > > wrote: > > > > From: Luca Boccassi < > > > > luca.bocca...@microsoft.com > > > > > > > > > > > > > portable services have been declared production ready with > > v241, so > > > > enable > > > > by default and install the files in the main package. > > > > > > > > > > what is the rationale to enable it by default ? > > > > Hi, > > > > commit ada8a5d9175b disabled it by default because it was > > experimental: > > "Add a new PACKAGECONFIG item 'portabled'. Default to disable it > > because it's still experimental, according to the announcement > > letter." > > > > Now it's been declared as stable by upstream, and also given > > machined > > and nspawn are enabled by default I don't see a reason why this > > shouldn't be as well, as they all provide the same "kind" of > > feature/functionality, albeit on a different level. > > > > Ok being stable is a good thing I agree but I still fail to > understand why make it default I am for disabling nspawn and machined > as well Simply that as long as nspawn and machined are enabled by default, there's no reason to do something different for portable services, in my opinion. At the moment they are enabled, hence this patch. > > > > Signed-off-by: Luca Boccassi < > > > > luca.bocca...@microsoft.com > > > > > > > > > --- > > > > v2: Just enable by default, and let the files be installed in > > the > > > > main package > > > > as requested by reviewers. > > > > > > > > meta/recipes-core/systemd/systemd_242.bb | 1 + > > > > 1 file changed, 1 insertion(+) > > > > > > > > diff --git a/meta/recipes-core/systemd/systemd_242.bb > > > > b/meta/recipes-core/systemd/systemd_242.bb > > > > index 73e03c7a77..f15d125bf8 100644 > > > > --- a/meta/recipes-core/systemd/systemd_242.bb > > > > +++ b/meta/recipes-core/systemd/systemd_242.bb > > > > @@ -81,6 +81,7 @@ PACKAGECONFIG ??= " \ > > > > nss \ > > > > nss-mymachines \ > > > > nss-resolve \ > > > > +portabled \ > > > > quotacheck \ > > > > randomseed \ > > > > resolved \ > > > > -- > > > > 2.20.1 > > > > > > > > -- > > > > ___ > > > > Openembedded-core mailing list > > > > Openembedded-core@lists.openembedded.org > > > > > > > > > > http://lists.openembedded.org/mailman/listinfo/openembedded-core > > > > > > -- Kind regards, Luca Boccassi -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] systemd: enable portabled by default
On Fri, 2019-05-10 at 09:45 -0700, Khem Raj wrote: > On Fri, May 10, 2019 at 5:10 AM < > luca.bocca...@gmail.com > > wrote: > > From: Luca Boccassi < > > luca.bocca...@microsoft.com > > > > > > > portable services have been declared production ready with v241, so > > enable > > by default and install the files in the main package. > > > > what is the rationale to enable it by default ? Hi, commit ada8a5d9175b disabled it by default because it was experimental: "Add a new PACKAGECONFIG item 'portabled'. Default to disable it because it's still experimental, according to the announcement letter." Now it's been declared as stable by upstream, and also given machined and nspawn are enabled by default I don't see a reason why this shouldn't be as well, as they all provide the same "kind" of feature/functionality, albeit on a different level. > > Signed-off-by: Luca Boccassi < > > luca.bocca...@microsoft.com > > > > > --- > > v2: Just enable by default, and let the files be installed in the > > main package > > as requested by reviewers. > > > > meta/recipes-core/systemd/systemd_242.bb | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/meta/recipes-core/systemd/systemd_242.bb > > b/meta/recipes-core/systemd/systemd_242.bb > > index 73e03c7a77..f15d125bf8 100644 > > --- a/meta/recipes-core/systemd/systemd_242.bb > > +++ b/meta/recipes-core/systemd/systemd_242.bb > > @@ -81,6 +81,7 @@ PACKAGECONFIG ??= " \ > > nss \ > > nss-mymachines \ > > nss-resolve \ > > +portabled \ > > quotacheck \ > > randomseed \ > > resolved \ > > -- > > 2.20.1 > > > > -- > > ___ > > Openembedded-core mailing list > > Openembedded-core@lists.openembedded.org > > > > http://lists.openembedded.org/mailman/listinfo/openembedded-core > > -- Kind regards, Luca Boccassi -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2] systemd: enable portabled by default
From: Luca Boccassi portable services have been declared production ready with v241, so enable by default and install the files in the main package. Signed-off-by: Luca Boccassi --- v2: Just enable by default, and let the files be installed in the main package as requested by reviewers. meta/recipes-core/systemd/systemd_242.bb | 1 + 1 file changed, 1 insertion(+) diff --git a/meta/recipes-core/systemd/systemd_242.bb b/meta/recipes-core/systemd/systemd_242.bb index 73e03c7a77..f15d125bf8 100644 --- a/meta/recipes-core/systemd/systemd_242.bb +++ b/meta/recipes-core/systemd/systemd_242.bb @@ -81,6 +81,7 @@ PACKAGECONFIG ??= " \ nss \ nss-mymachines \ nss-resolve \ +portabled \ quotacheck \ randomseed \ resolved \ -- 2.20.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] systemd: enable portabled by default and install utilities in systemd-container
On Fri, 2019-05-10 at 07:23 +0200, Martin Hundebøll wrote:
> Hi Luca,
>
> On 09/05/2019 23.40,
> luca.bocca...@gmail.com
> wrote:
> > From: Luca Boccassi <
> > luca.bocca...@microsoft.com
> > >
> >
> > portable services have been declared production ready with v241, so
> > enable
> > by default and install the files in the container package.
>
> The systemd portables feature is not really related to
> containers/VM's,
> so I think it should stay in the primary package; or alternatively in
> a
> separate package.
>
> // Martin
Hello Martin,
IMHO if VM tools and containers tool can go together in this package,
then portable services utilities can too - they are at different
positions on the same scale after all :-)
But I've got no strong opinion, so I'll send a v2 with them moved to
the main package.
> > Signed-off-by: Luca Boccassi <
> > luca.bocca...@microsoft.com
> > >
> > ---
> > meta/recipes-core/systemd/systemd_242.bb | 10 ++
> > 1 file changed, 10 insertions(+)
> >
> > diff --git a/meta/recipes-core/systemd/systemd_242.bb
> > b/meta/recipes-core/systemd/systemd_242.bb
> > index 73e03c7a77..83b00ba785 100644
> > --- a/meta/recipes-core/systemd/systemd_242.bb
> > +++ b/meta/recipes-core/systemd/systemd_242.bb
> > @@ -81,6 +81,7 @@ PACKAGECONFIG ??= " \
> > nss \
> > nss-mymachines \
> > nss-resolve \
> > +portabled \
> > quotacheck \
> > randomseed \
> > resolved \
> > @@ -403,8 +404,10 @@ SYSTEMD_SERVICE_${PN}-remote = "systemd-
> > journal-remote.socket"
> >
> > FILES_${PN}-container = "${sysconfdir}/dbus-
> > 1/system.d/org.freedesktop.import1.conf \
> >${sysconfdir}/dbus-
> > 1/system.d/org.freedesktop.machine1.conf \
> > + ${sysconfdir}/dbus-
> > 1/system.d/org.freedesktop.portable1.conf \
> >${sysconfdir}/systemd/system/multi-
> > user.target.wants/machines.target \
> >${base_bindir}/machinectl \
> > + ${base_bindir}/portablectl \
> >${bindir}/systemd-nspawn \
> >${nonarch_libdir}/systemd/import-
> > pubring.gpg \
> >${systemd_system_unitdir}/busnames.targe
> > t.wants/org.freedesktop.import1.busname \
> > @@ -418,21 +421,28 @@ FILES_${PN}-container = "${sysconfdir}/dbus-
> > 1/system.d/org.freedesktop.import1.c
> >${systemd_system_unitdir}/org.freedeskto
> > p.machine1.busname \
> >${systemd_system_unitdir}/systemd-
> > importd.service \
> >${systemd_system_unitdir}/systemd-
> > machined.service \
> > + ${systemd_system_unitdir}/systemd-
> > portabled.service \
> >${systemd_system_unitdir}/dbus-
> > org.freedesktop.machine1.service \
> > + ${systemd_system_unitdir}/dbus-
> > org.freedesktop.portable1.service \
> >${systemd_system_unitdir}/var-lib-
> > machines.mount \
> >${rootlibexecdir}/systemd/systemd-import
> > \
> >${rootlibexecdir}/systemd/systemd-
> > importd \
> >${rootlibexecdir}/systemd/systemd-
> > machined \
> > + ${rootlibexecdir}/systemd/systemd-
> > portabled \
> >${rootlibexecdir}/systemd/systemd-pull \
> > + ${exec_prefix}/lib/tmpfiles.d/portables.c
> > onf \
> >${exec_prefix}/lib/tmpfiles.d/systemd-
> > nspawn.conf \
> >${systemd_system_unitdir}/systemd-
> > nspawn@.service \
> >${libdir}/libnss_mymachines.so.2 \
> >${datadir}/dbus-1/system-
> > services/org.freedesktop.import1.service \
> >${datadir}/dbus-1/system-
> > services/org.freedesktop.machine1.service \
> > + ${datadir}/dbus-1/system-
> > services/org.freedesktop.portable1.service \
> >${datadir}/dbus-
> > 1/system.d/org.freedesktop.import1.conf \
> >${datadir}/dbus-
> > 1/system.d/org.freedesktop.machine1.conf \
> > + ${datadir}/dbus-
> &
[OE-core] [PATCH] systemd: enable portabled by default and install utilities in systemd-container
From: Luca Boccassi
portable services have been declared production ready with v241, so enable
by default and install the files in the container package.
Signed-off-by: Luca Boccassi
---
meta/recipes-core/systemd/systemd_242.bb | 10 ++
1 file changed, 10 insertions(+)
diff --git a/meta/recipes-core/systemd/systemd_242.bb
b/meta/recipes-core/systemd/systemd_242.bb
index 73e03c7a77..83b00ba785 100644
--- a/meta/recipes-core/systemd/systemd_242.bb
+++ b/meta/recipes-core/systemd/systemd_242.bb
@@ -81,6 +81,7 @@ PACKAGECONFIG ??= " \
nss \
nss-mymachines \
nss-resolve \
+portabled \
quotacheck \
randomseed \
resolved \
@@ -403,8 +404,10 @@ SYSTEMD_SERVICE_${PN}-remote =
"systemd-journal-remote.socket"
FILES_${PN}-container =
"${sysconfdir}/dbus-1/system.d/org.freedesktop.import1.conf \
${sysconfdir}/dbus-1/system.d/org.freedesktop.machine1.conf \
+
${sysconfdir}/dbus-1/system.d/org.freedesktop.portable1.conf \
${sysconfdir}/systemd/system/multi-user.target.wants/machines.target \
${base_bindir}/machinectl \
+ ${base_bindir}/portablectl \
${bindir}/systemd-nspawn \
${nonarch_libdir}/systemd/import-pubring.gpg \
${systemd_system_unitdir}/busnames.target.wants/org.freedesktop.import1.busname
\
@@ -418,21 +421,28 @@ FILES_${PN}-container =
"${sysconfdir}/dbus-1/system.d/org.freedesktop.import1.c
${systemd_system_unitdir}/org.freedesktop.machine1.busname \
${systemd_system_unitdir}/systemd-importd.service \
${systemd_system_unitdir}/systemd-machined.service \
+ ${systemd_system_unitdir}/systemd-portabled.service \
${systemd_system_unitdir}/dbus-org.freedesktop.machine1.service \
+
${systemd_system_unitdir}/dbus-org.freedesktop.portable1.service \
${systemd_system_unitdir}/var-lib-machines.mount \
${rootlibexecdir}/systemd/systemd-import \
${rootlibexecdir}/systemd/systemd-importd \
${rootlibexecdir}/systemd/systemd-machined \
+ ${rootlibexecdir}/systemd/systemd-portabled \
${rootlibexecdir}/systemd/systemd-pull \
+ ${exec_prefix}/lib/tmpfiles.d/portables.conf \
${exec_prefix}/lib/tmpfiles.d/systemd-nspawn.conf \
${systemd_system_unitdir}/systemd-nspawn@.service \
${libdir}/libnss_mymachines.so.2 \
${datadir}/dbus-1/system-services/org.freedesktop.import1.service \
${datadir}/dbus-1/system-services/org.freedesktop.machine1.service \
+
${datadir}/dbus-1/system-services/org.freedesktop.portable1.service \
${datadir}/dbus-1/system.d/org.freedesktop.import1.conf \
${datadir}/dbus-1/system.d/org.freedesktop.machine1.conf \
+
${datadir}/dbus-1/system.d/org.freedesktop.portable1.conf \
${datadir}/polkit-1/actions/org.freedesktop.import1.policy \
${datadir}/polkit-1/actions/org.freedesktop.machine1.policy \
+
${datadir}/polkit-1/actions/org.freedesktop.portable1.policy \
"
RRECOMMENDS_${PN}-container += "\
--
2.20.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] systemd: add cgroupv2 PACKAGECONFIG
From: Luca Boccassi Allow users to change the default cgroup mode at build time and use the unified hierarchy mode. Disabled by default - hybrid is the default upstream value. Signed-off-by: Luca Boccassi --- meta/recipes-core/systemd/systemd_242.bb | 1 + 1 file changed, 1 insertion(+) diff --git a/meta/recipes-core/systemd/systemd_242.bb b/meta/recipes-core/systemd/systemd_242.bb index a559fa0d75..33d3e0b000 100644 --- a/meta/recipes-core/systemd/systemd_242.bb +++ b/meta/recipes-core/systemd/systemd_242.bb @@ -115,6 +115,7 @@ PACKAGECONFIG[audit] = "-Daudit=true,-Daudit=false,audit" PACKAGECONFIG[backlight] = "-Dbacklight=true,-Dbacklight=false" PACKAGECONFIG[binfmt] = "-Dbinfmt=true,-Dbinfmt=false" PACKAGECONFIG[bzip2] = "-Dbzip2=true,-Dbzip2=false,bzip2" +PACKAGECONFIG[cgroupv2] = "-Ddefault-hierarchy=unified,-Ddefault-hierarchy=hybrid" PACKAGECONFIG[coredump] = "-Dcoredump=true,-Dcoredump=false" PACKAGECONFIG[cryptsetup] = "-Dlibcryptsetup=true,-Dlibcryptsetup=false,cryptsetup" PACKAGECONFIG[dbus] = "-Ddbus=true,-Ddbus=false,dbus" -- 2.20.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] u-boot: install dumpimage and fit_check_sign in u-boot-tools
On Thu, 2019-03-21 at 19:30 +, Alex Kiernan wrote:
> On Thu, Mar 21, 2019 at 6:36 PM wrote:
> > From: Luca Boccassi
> >
> > Dumpimage and fit_check_sign can be used to extract kernel and
> > ramdisk from
> > a FIT file, verify them and kexec for a faster reboot.
> >
> > Signed-off-by: Luca Boccassi
> > Signed-off-by: Richard Purdie
> > ---
> > v2: add dumpimage and fit_check_sign to FILES_${PN}-mkimage to fix
> > build.
> > Not sure if it's preferable to do this or to add a new package,
> > please
> > advise if the other is better.
> >
> > meta/recipes-bsp/u-boot/u-boot-tools_2019.01.bb | 10 +-
> > 1 file changed, 9 insertions(+), 1 deletion(-)
> >
> > diff --git a/meta/recipes-bsp/u-boot/u-boot-tools_2019.01.bb
> > b/meta/recipes-bsp/u-boot/u-boot-tools_2019.01.bb
> > index ff26e32482..b72033a566 100644
> > --- a/meta/recipes-bsp/u-boot/u-boot-tools_2019.01.bb
> > +++ b/meta/recipes-bsp/u-boot/u-boot-tools_2019.01.bb
> > @@ -45,11 +45,19 @@ do_install () {
> > # mkenvimage
> > install -m 0755 tools/mkenvimage ${D}${bindir}/uboot-
> > mkenvimage
> > ln -sf uboot-mkenvimage ${D}${bindir}/mkenvimage
> > +
> > + # dumpimage
> > + install -m 0755 tools/dumpimage ${D}${bindir}/uboot-
> > dumpimage
> > + ln -sf uboot-dumpimage ${D}${bindir}/dumpimage
> > +
> > + # fit_check_sign
> > + install -m 0755 tools/fit_check_sign ${D}${bindir}/uboot-
> > fit_check_sign
> > + ln -sf uboot-fit_check_sign ${D}${bindir}/fit_check_sign
> > }
> >
> > ALLOW_EMPTY_${PN} = "1"
> > FILES_${PN} = ""
> > -FILES_${PN}-mkimage = "${bindir}/uboot-mkimage ${bindir}/mkimage"
> > +FILES_${PN}-mkimage = "${bindir}/uboot-mkimage ${bindir}/mkimage
> > {bindir}/uboot-dumpimage ${bindir}/dumpimage
>
> There's no $ here
>
> > {bindir}/uboot-fit_check_sign ${bindir}/fit_check_sign"
>
> or here
>
> > FILES_${PN}-mkenvimage = "${bindir}/uboot-mkenvimage
> > ${bindir}/mkenvimage"
> >
> > RDEPENDS_${PN}-mkimage += "dtc"
D'oh, copypasta! Thanks, fixed in v3
--
Kind regards,
Luca Boccassi
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v3] u-boot: install dumpimage and fit_check_sign in u-boot-tools
From: Luca Boccassi
Dumpimage and fit_check_sign can be used to extract kernel and ramdisk from
a FIT file, verify them and kexec for a faster reboot.
Signed-off-by: Luca Boccassi
Signed-off-by: Richard Purdie
---
v2: add dumpimage and fit_check_sign to FILES_${PN}-mkimage to fix build.
Not sure if it's preferable to do this or to add a new package, please
advise if the other is better.
v3: fix copypasta
meta/recipes-bsp/u-boot/u-boot-tools_2019.01.bb | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-bsp/u-boot/u-boot-tools_2019.01.bb
b/meta/recipes-bsp/u-boot/u-boot-tools_2019.01.bb
index ff26e32482..bede984ef7 100644
--- a/meta/recipes-bsp/u-boot/u-boot-tools_2019.01.bb
+++ b/meta/recipes-bsp/u-boot/u-boot-tools_2019.01.bb
@@ -45,11 +45,19 @@ do_install () {
# mkenvimage
install -m 0755 tools/mkenvimage ${D}${bindir}/uboot-mkenvimage
ln -sf uboot-mkenvimage ${D}${bindir}/mkenvimage
+
+ # dumpimage
+ install -m 0755 tools/dumpimage ${D}${bindir}/uboot-dumpimage
+ ln -sf uboot-dumpimage ${D}${bindir}/dumpimage
+
+ # fit_check_sign
+ install -m 0755 tools/fit_check_sign ${D}${bindir}/uboot-fit_check_sign
+ ln -sf uboot-fit_check_sign ${D}${bindir}/fit_check_sign
}
ALLOW_EMPTY_${PN} = "1"
FILES_${PN} = ""
-FILES_${PN}-mkimage = "${bindir}/uboot-mkimage ${bindir}/mkimage"
+FILES_${PN}-mkimage = "${bindir}/uboot-mkimage ${bindir}/mkimage
${bindir}/uboot-dumpimage ${bindir}/dumpimage ${bindir}/uboot-fit_check_sign
${bindir}/fit_check_sign"
FILES_${PN}-mkenvimage = "${bindir}/uboot-mkenvimage ${bindir}/mkenvimage"
RDEPENDS_${PN}-mkimage += "dtc"
--
2.20.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2] u-boot: install dumpimage and fit_check_sign in u-boot-tools
From: Luca Boccassi
Dumpimage and fit_check_sign can be used to extract kernel and ramdisk from
a FIT file, verify them and kexec for a faster reboot.
Signed-off-by: Luca Boccassi
Signed-off-by: Richard Purdie
---
v2: add dumpimage and fit_check_sign to FILES_${PN}-mkimage to fix build.
Not sure if it's preferable to do this or to add a new package, please
advise if the other is better.
meta/recipes-bsp/u-boot/u-boot-tools_2019.01.bb | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-bsp/u-boot/u-boot-tools_2019.01.bb
b/meta/recipes-bsp/u-boot/u-boot-tools_2019.01.bb
index ff26e32482..b72033a566 100644
--- a/meta/recipes-bsp/u-boot/u-boot-tools_2019.01.bb
+++ b/meta/recipes-bsp/u-boot/u-boot-tools_2019.01.bb
@@ -45,11 +45,19 @@ do_install () {
# mkenvimage
install -m 0755 tools/mkenvimage ${D}${bindir}/uboot-mkenvimage
ln -sf uboot-mkenvimage ${D}${bindir}/mkenvimage
+
+ # dumpimage
+ install -m 0755 tools/dumpimage ${D}${bindir}/uboot-dumpimage
+ ln -sf uboot-dumpimage ${D}${bindir}/dumpimage
+
+ # fit_check_sign
+ install -m 0755 tools/fit_check_sign ${D}${bindir}/uboot-fit_check_sign
+ ln -sf uboot-fit_check_sign ${D}${bindir}/fit_check_sign
}
ALLOW_EMPTY_${PN} = "1"
FILES_${PN} = ""
-FILES_${PN}-mkimage = "${bindir}/uboot-mkimage ${bindir}/mkimage"
+FILES_${PN}-mkimage = "${bindir}/uboot-mkimage ${bindir}/mkimage
{bindir}/uboot-dumpimage ${bindir}/dumpimage {bindir}/uboot-fit_check_sign
${bindir}/fit_check_sign"
FILES_${PN}-mkenvimage = "${bindir}/uboot-mkenvimage ${bindir}/mkenvimage"
RDEPENDS_${PN}-mkimage += "dtc"
--
2.20.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] u-boot: install dumpimage and fit_check_sign in u-boot-tools
On Thu, 2019-03-21 at 11:44 +, Richard Purdie wrote:
> On Tue, 2019-03-19 at 18:15 +, luca.bocca...@gmail.com wrote:
> > From: Luca Boccassi
> >
> > Dumpimage and fit_check_sign can be used to extract kernel and
> > ramdisk from
> > a FIT file, verify them and kexec for a faster reboot.
> >
> > Signed-off-by: Luca Boccassi
> > ---
> > meta/recipes-bsp/u-boot/u-boot-tools_2019.01.bb | 8
> > 1 file changed, 8 insertions(+)
> >
> > diff --git a/meta/recipes-bsp/u-boot/u-boot-tools_2019.01.bb
> > b/meta/recipes-bsp/u-boot/u-boot-tools_2019.01.bb
> > index ff26e32482..c487849bb2 100644
> > --- a/meta/recipes-bsp/u-boot/u-boot-tools_2019.01.bb
> > +++ b/meta/recipes-bsp/u-boot/u-boot-tools_2019.01.bb
> > @@ -45,6 +45,14 @@ do_install () {
> > # mkenvimage
> > install -m 0755 tools/mkenvimage ${D}${bindir}/uboot-mkenvimage
> > ln -sf uboot-mkenvimage ${D}${bindir}/mkenvimage
> > +
> > + # dumpimage
> > + install -m 0755 tools/dumpimage ${D}${bindir}/uboot-dumpimage
> > + ln -sf uboot-dumpimage ${D}${bindir}/dumpimage
> > +
> > + # fit_check_sign
> > + install -m 0755 tools/fit_check_sign ${D}${bindir}/uboot-
> > fit_check_sign
> > + ln -sf uboot-fit_check_sign ${D}${bindir}/fit_check_sign
> > }
> >
> > ALLOW_EMPTY_${PN} = "1"
>
> Fails on musl:
> https://autobuilder.yoctoproject.org/typhoon/#/builders/64/builds/420
> https://autobuilder.yoctoproject.org/typhoon/#/builders/45/builds/421
> no-x11:
> https://autobuilder.yoctoproject.org/typhoon/#/builders/40/builds/419
> qemux86-world:
> https://autobuilder.yoctoproject.org/typhoon/#/builders/52/builds/412
>
> so basically it looks like any world build fails with this.
>
> Cheers,
>
> Richard
Hi,
Sorry about that, this recipe has changed a bit since sumo - it seems
the files need to be also listed individually in FILES_${PN}:
ERROR: u-boot-tools-1_2019.01-r0 do_package: QA Issue: u-boot-tools:
Files/directories were installed but not shipped in any package:
/usr/bin/uboot-dumpimage
/usr/bin/fit_check_sign
/usr/bin/dumpimage
/usr/bin/uboot-fit_check_sign
Please set FILES such that these items are packaged. Alternatively if
they are unneeded, avoid installing them or delete them within
do_install.
eg:
-FILES_${PN}-mkimage = "${bindir}/uboot-mkimage ${bindir}/mkimage"
+FILES_${PN}-mkimage = "${bindir}/uboot-mkimage ${bindir}/mkimage
{bindir}/uboot-dumpimage ${bindir}/dumpimage {bindir}/uboot-fit_check_sign
${bindir}/fit_check_sign"
Is this the right solution? Or should it be a new package?
--
Kind regards,
Luca Boccassi
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] u-boot: install dumpimage and fit_check_sign in u-boot-tools
From: Luca Boccassi
Dumpimage and fit_check_sign can be used to extract kernel and ramdisk from
a FIT file, verify them and kexec for a faster reboot.
Signed-off-by: Luca Boccassi
---
meta/recipes-bsp/u-boot/u-boot-tools_2019.01.bb | 8
1 file changed, 8 insertions(+)
diff --git a/meta/recipes-bsp/u-boot/u-boot-tools_2019.01.bb
b/meta/recipes-bsp/u-boot/u-boot-tools_2019.01.bb
index ff26e32482..c487849bb2 100644
--- a/meta/recipes-bsp/u-boot/u-boot-tools_2019.01.bb
+++ b/meta/recipes-bsp/u-boot/u-boot-tools_2019.01.bb
@@ -45,6 +45,14 @@ do_install () {
# mkenvimage
install -m 0755 tools/mkenvimage ${D}${bindir}/uboot-mkenvimage
ln -sf uboot-mkenvimage ${D}${bindir}/mkenvimage
+
+ # dumpimage
+ install -m 0755 tools/dumpimage ${D}${bindir}/uboot-dumpimage
+ ln -sf uboot-dumpimage ${D}${bindir}/dumpimage
+
+ # fit_check_sign
+ install -m 0755 tools/fit_check_sign ${D}${bindir}/uboot-fit_check_sign
+ ln -sf uboot-fit_check_sign ${D}${bindir}/fit_check_sign
}
ALLOW_EMPTY_${PN} = "1"
--
2.20.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] systemd: do not disable SELinux with musl
From: Luca Boccassi Building and running SELinux with musl works fine these days, so don't disable it in the systemd bitbake file. Signed-off-by: Luca Boccassi --- meta/recipes-core/systemd/systemd_241.bb | 1 - 1 file changed, 1 deletion(-) diff --git a/meta/recipes-core/systemd/systemd_241.bb b/meta/recipes-core/systemd/systemd_241.bb index 47492c9512..e4534ab8af 100644 --- a/meta/recipes-core/systemd/systemd_241.bb +++ b/meta/recipes-core/systemd/systemd_241.bb @@ -101,7 +101,6 @@ PACKAGECONFIG_remove_libc-musl = " \ nss-mymachines \ nss-resolve \ resolved \ -selinux \ smack \ sysusers \ utmp \ -- 2.20.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v3] swig: fix build with musl
On Mon, 2019-03-04 at 11:18 +, Burton, Ross wrote:
> On Mon, 4 Mar 2019 at 11:12, wrote:
> > +mkdir -p ${WORKDIR}/build/Source/CParse
>
> Use ${B} instead of ${WORKDIR}/build.
>
> Ross
Thanks, please see v4
--
Kind regards,
Luca Boccassi
signature.asc
Description: This is a digitally signed message part
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v4] swig: fix build with musl
From: Luca Boccassi
Building with musl currently fails. The fix has been committed
upstream, so backport it.
Note that it requires running yacc again to regenerate the parser file,
so a bison-native dependency is needed. Also the upstream's configure
step creates the directory where the parser file is generated at
make-dist time, and for some reason running through bitbake does not
create it, so do it manually. All of this can be reverted once a new
swig version that includes the fix is released and rebased onto.
Signed-off-by: Luca Boccassi
---
v2: fixed patch header
v3: added bison-native dependency and autoconf workaround
v4: switched from ${WORKDIR}/build to ${B}
meta/recipes-devtools/swig/swig.inc | 8 +-
...de-for-constant-expressions-containi.patch | 179 ++
meta/recipes-devtools/swig/swig_3.0.12.bb | 1 +
3 files changed, 187 insertions(+), 1 deletion(-)
create mode 100644
meta/recipes-devtools/swig/swig/0001-Fix-generated-code-for-constant-expressions-containi.patch
diff --git a/meta/recipes-devtools/swig/swig.inc
b/meta/recipes-devtools/swig/swig.inc
index f7de40866a..00b9c5b605 100644
--- a/meta/recipes-devtools/swig/swig.inc
+++ b/meta/recipes-devtools/swig/swig.inc
@@ -7,7 +7,7 @@ LIC_FILES_CHKSUM =
"file://LICENSE;md5=e7807a6282784a7dde4c846626b08fc6 \
SECTION = "devel"
-DEPENDS = "libpcre"
+DEPENDS = "libpcre bison-native"
SRC_URI = "${SOURCEFORGE_MIRROR}/${BPN}/${BPN}-${PV}.tar.gz"
@@ -42,6 +42,12 @@ EXTRA_AUTORECONF += "-I Tools/config"
BBCLASSEXTEND = "native nativesdk"
+# necessary together with bison dependency until a new upstream version after
+# 3.0.12 includes
0001-Fix-generated-code-for-constant-expressions-containi.patch
+do_configure_append() {
+mkdir -p ${B}/Source/CParse
+}
+
do_install_append_class-nativesdk() {
cd ${D}${bindir}
ln -s swig swig2.0
diff --git
a/meta/recipes-devtools/swig/swig/0001-Fix-generated-code-for-constant-expressions-containi.patch
b/meta/recipes-devtools/swig/swig/0001-Fix-generated-code-for-constant-expressions-containi.patch
new file mode 100644
index 00..f4ed782a82
--- /dev/null
+++
b/meta/recipes-devtools/swig/swig/0001-Fix-generated-code-for-constant-expressions-containi.patch
@@ -0,0 +1,179 @@
+From 90ba174fcea1618af57aa594199541d47a89b7f6 Mon Sep 17 00:00:00 2001
+From: William S Fulton
+Date: Sun, 17 Sep 2017 19:02:55 +0100
+Subject: [PATCH 1/2] Fix generated code for constant expressions containing
+ wchar_t L literals.
+
+Such as:
+ # define __WCHAR_MAX(0x7fff + L'\0')
+
+Reported on swig-user mailing list.
+---
+ CHANGES.current | 5 +
+ Examples/test-suite/csharp/preproc_constants_c_runme.cs | 3 ++-
+ Examples/test-suite/csharp/preproc_constants_runme.cs | 2 ++
+ Examples/test-suite/d/preproc_constants_c_runme.1.d | 2 ++
+ Examples/test-suite/d/preproc_constants_c_runme.2.d | 2 ++
+ Examples/test-suite/d/preproc_constants_runme.1.d | 2 ++
+ Examples/test-suite/d/preproc_constants_runme.2.d | 2 ++
+ Examples/test-suite/php/preproc_constants_c_runme.php | 2 ++
+ Examples/test-suite/php/preproc_constants_runme.php | 2 ++
+ Examples/test-suite/php5/preproc_constants_c_runme.php | 2 ++
+ Examples/test-suite/php5/preproc_constants_runme.php| 2 ++
+ Examples/test-suite/preproc_constants.i | 3 +++
+ Source/CParse/parser.y | 2 +-
+ 13 files changed, 29 insertions(+), 2 deletions(-)
+
+Upstream-Status: Backport
+[https://github.com/swig/swig/commit/90ba174fcea1618af57aa594199541d47a89b7f6]
+Signed-off-by: Luca Boccassi
+
+diff --git a/Examples/test-suite/csharp/preproc_constants_c_runme.cs
b/Examples/test-suite/csharp/preproc_constants_c_runme.cs
+index 76c684d..1c28e49 100644
+--- a/Examples/test-suite/csharp/preproc_constants_c_runme.cs
b/Examples/test-suite/csharp/preproc_constants_c_runme.cs
+@@ -61,7 +61,8 @@ public class runme {
+ assert( typeof(int) == preproc_constants_c.EXPR_LAND.GetType() );
+ assert( typeof(int) == preproc_constants_c.EXPR_LOR.GetType() );
+ assert( typeof(double) == preproc_constants_c.EXPR_CONDITIONAL.GetType()
);
+-
++assert( typeof(int) == preproc_constants_c.EXPR_WCHAR_MAX.GetType() );
++assert( typeof(int) == preproc_constants_c.EXPR_WCHAR_MIN.GetType() );
+ }
+ static void assert(bool assertion) {
+ if (!assertion)
+diff --git a/Examples/test-suite/csharp/preproc_constants_runme.cs
b/Examples/test-suite/csharp/preproc_constants_runme.cs
+index 9fae591..6b02e30 100644
+--- a/Examples/test-suite/csharp/preproc_constants_runme.cs
b/Examples/test-suite/csharp/preproc_constants_runme.cs
+@@ -60,6 +60,8 @@ public class runme {
+ assert( typeof(bool) == preproc_constants.EXPR_LAND.GetType() );
+ assert( typeof(bool) == preproc_constants.EXPR_LOR.GetType() );
+ assert
Re: [OE-core] [PATCH v2] swig: fix build with musl
On Sat, 2019-03-02 at 23:03 +, Richard Purdie wrote:
> On Sat, 2019-03-02 at 18:12 +, Richard Purdie wrote:
> > On Fri, 2019-03-01 at 16:36 +, luca.bocca...@gmail.com wrote:
> > > From: Luca Boccassi
> > >
> > > Building with musl currently fails. The fix has been committed
> > > upstream, so backport it.
> > > Note that it requires the recent change to use autoconf's
> > > do_configure
> > > as it modifies a bison file which is used at make-dist time, so
> > > it
> > > triggers an autoconf rerun which was not working previously due
> > > to
> > > the
> > > custom do_configure step that was removed recently by:
> > > a9b1f9eca963 ("swig: Fix configure failure")
> > >
> > > Signed-off-by: Luca Boccassi
> > > ---
> > > v2: fixed upstream metadata format in patch header
> >
> > Fails in testing:
> >
> > https://autobuilder.yoctoproject.org/typhoon/#/builders/15/builds/585
> >
> > May need a bison-native DEPENDS?
It does require bison, and I feel very silly as I have added it to the
internal build and forgot to include it in the patch! Sorry :-)
> I tried that, it fails with other problems :(
>
> For example:
> https://autobuilder.yoctoproject.org/typhoon/#/builders/65/builds/353
>
> Cheers,
>
> Richard
I thought that would have been fixed by:
95c78d2166d3 ("swig: Fix configure failure")
Upstream's configure step creates that directory that is missing and
causes the build failure showed by the logs. I thought avoiding a
custom do_configure would fix that, but evidently it doesn't!
I've sent a v3 with the bison dependency and with a workaround I've
successfully used in our internal build, which creates the directory
manually in a do_configure_append block.
Thanks for the review!
--
Kind regards,
Luca Boccassi
signature.asc
Description: This is a digitally signed message part
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v3] swig: fix build with musl
From: Luca Boccassi
Building with musl currently fails. The fix has been committed
upstream, so backport it.
Note that it requires running yacc again to regenerate the parser file,
so a bison-native dependency is needed. Also the upstream's configure
step creates the directory where the parser file is generated at
make-dist time, and for some reason running through bitbake does not
create it, so do it manually. All of this can be reverted once a new
swig version that includes the fix is released and rebased onto.
Signed-off-by: Luca Boccassi
---
meta/recipes-devtools/swig/swig.inc | 8 +-
...de-for-constant-expressions-containi.patch | 179 ++
meta/recipes-devtools/swig/swig_3.0.12.bb | 1 +
3 files changed, 187 insertions(+), 1 deletion(-)
create mode 100644
meta/recipes-devtools/swig/swig/0001-Fix-generated-code-for-constant-expressions-containi.patch
diff --git a/meta/recipes-devtools/swig/swig.inc
b/meta/recipes-devtools/swig/swig.inc
index f7de40866a..2f33b07c19 100644
--- a/meta/recipes-devtools/swig/swig.inc
+++ b/meta/recipes-devtools/swig/swig.inc
@@ -7,7 +7,7 @@ LIC_FILES_CHKSUM =
"file://LICENSE;md5=e7807a6282784a7dde4c846626b08fc6 \
SECTION = "devel"
-DEPENDS = "libpcre"
+DEPENDS = "libpcre bison-native"
SRC_URI = "${SOURCEFORGE_MIRROR}/${BPN}/${BPN}-${PV}.tar.gz"
@@ -42,6 +42,12 @@ EXTRA_AUTORECONF += "-I Tools/config"
BBCLASSEXTEND = "native nativesdk"
+# necessary together with bison dependency until a new upstream version after
+# 3.0.12 includes
0001-Fix-generated-code-for-constant-expressions-containi.patch
+do_configure_append() {
+mkdir -p ${WORKDIR}/build/Source/CParse
+}
+
do_install_append_class-nativesdk() {
cd ${D}${bindir}
ln -s swig swig2.0
diff --git
a/meta/recipes-devtools/swig/swig/0001-Fix-generated-code-for-constant-expressions-containi.patch
b/meta/recipes-devtools/swig/swig/0001-Fix-generated-code-for-constant-expressions-containi.patch
new file mode 100644
index 00..f4ed782a82
--- /dev/null
+++
b/meta/recipes-devtools/swig/swig/0001-Fix-generated-code-for-constant-expressions-containi.patch
@@ -0,0 +1,179 @@
+From 90ba174fcea1618af57aa594199541d47a89b7f6 Mon Sep 17 00:00:00 2001
+From: William S Fulton
+Date: Sun, 17 Sep 2017 19:02:55 +0100
+Subject: [PATCH 1/2] Fix generated code for constant expressions containing
+ wchar_t L literals.
+
+Such as:
+ # define __WCHAR_MAX(0x7fff + L'\0')
+
+Reported on swig-user mailing list.
+---
+ CHANGES.current | 5 +
+ Examples/test-suite/csharp/preproc_constants_c_runme.cs | 3 ++-
+ Examples/test-suite/csharp/preproc_constants_runme.cs | 2 ++
+ Examples/test-suite/d/preproc_constants_c_runme.1.d | 2 ++
+ Examples/test-suite/d/preproc_constants_c_runme.2.d | 2 ++
+ Examples/test-suite/d/preproc_constants_runme.1.d | 2 ++
+ Examples/test-suite/d/preproc_constants_runme.2.d | 2 ++
+ Examples/test-suite/php/preproc_constants_c_runme.php | 2 ++
+ Examples/test-suite/php/preproc_constants_runme.php | 2 ++
+ Examples/test-suite/php5/preproc_constants_c_runme.php | 2 ++
+ Examples/test-suite/php5/preproc_constants_runme.php| 2 ++
+ Examples/test-suite/preproc_constants.i | 3 +++
+ Source/CParse/parser.y | 2 +-
+ 13 files changed, 29 insertions(+), 2 deletions(-)
+
+Upstream-Status: Backport
+[https://github.com/swig/swig/commit/90ba174fcea1618af57aa594199541d47a89b7f6]
+Signed-off-by: Luca Boccassi
+
+diff --git a/Examples/test-suite/csharp/preproc_constants_c_runme.cs
b/Examples/test-suite/csharp/preproc_constants_c_runme.cs
+index 76c684d..1c28e49 100644
+--- a/Examples/test-suite/csharp/preproc_constants_c_runme.cs
b/Examples/test-suite/csharp/preproc_constants_c_runme.cs
+@@ -61,7 +61,8 @@ public class runme {
+ assert( typeof(int) == preproc_constants_c.EXPR_LAND.GetType() );
+ assert( typeof(int) == preproc_constants_c.EXPR_LOR.GetType() );
+ assert( typeof(double) == preproc_constants_c.EXPR_CONDITIONAL.GetType()
);
+-
++assert( typeof(int) == preproc_constants_c.EXPR_WCHAR_MAX.GetType() );
++assert( typeof(int) == preproc_constants_c.EXPR_WCHAR_MIN.GetType() );
+ }
+ static void assert(bool assertion) {
+ if (!assertion)
+diff --git a/Examples/test-suite/csharp/preproc_constants_runme.cs
b/Examples/test-suite/csharp/preproc_constants_runme.cs
+index 9fae591..6b02e30 100644
+--- a/Examples/test-suite/csharp/preproc_constants_runme.cs
b/Examples/test-suite/csharp/preproc_constants_runme.cs
+@@ -60,6 +60,8 @@ public class runme {
+ assert( typeof(bool) == preproc_constants.EXPR_LAND.GetType() );
+ assert( typeof(bool) == preproc_constants.EXPR_LOR.GetType() );
+ assert( typeof(double) == preproc_constants.EXPR_CONDITIONAL.GetType() );
++assert( typeo
Re: [OE-core] [PATCH] swig: fix build with musl
On Fri, 2019-03-01 at 13:43 +, Burton, Ross wrote: > On Thu, 28 Feb 2019 at 14:28, wrote: > > +Origin: > > https://github.com/swig/swig/commit/90ba174fcea1618af57aa594199541d47a89b7f6 > > +Applied-Upstream: yes > > This should be: > > Upstream-Status: Backport > [ > https://github.com/swig/swig/commit/90ba174fcea1618af57aa594199541d47a89b7f6 > ] > Signed-off-by: Luca Boccassi > > Can you update the patch and repost? > > Ross Certainly, sent v2, thanks for reviewing. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2] swig: fix build with musl
From: Luca Boccassi
Building with musl currently fails. The fix has been committed
upstream, so backport it.
Note that it requires the recent change to use autoconf's do_configure
as it modifies a bison file which is used at make-dist time, so it
triggers an autoconf rerun which was not working previously due to the
custom do_configure step that was removed recently by:
a9b1f9eca963 ("swig: Fix configure failure")
Signed-off-by: Luca Boccassi
---
v2: fixed upstream metadata format in patch header
...de-for-constant-expressions-containi.patch | 179 ++
meta/recipes-devtools/swig/swig_3.0.12.bb | 1 +
2 files changed, 180 insertions(+)
create mode 100644
meta/recipes-devtools/swig/swig/0001-Fix-generated-code-for-constant-expressions-containi.patch
diff --git
a/meta/recipes-devtools/swig/swig/0001-Fix-generated-code-for-constant-expressions-containi.patch
b/meta/recipes-devtools/swig/swig/0001-Fix-generated-code-for-constant-expressions-containi.patch
new file mode 100644
index 00..f4ed782a82
--- /dev/null
+++
b/meta/recipes-devtools/swig/swig/0001-Fix-generated-code-for-constant-expressions-containi.patch
@@ -0,0 +1,179 @@
+From 90ba174fcea1618af57aa594199541d47a89b7f6 Mon Sep 17 00:00:00 2001
+From: William S Fulton
+Date: Sun, 17 Sep 2017 19:02:55 +0100
+Subject: [PATCH 1/2] Fix generated code for constant expressions containing
+ wchar_t L literals.
+
+Such as:
+ # define __WCHAR_MAX(0x7fff + L'\0')
+
+Reported on swig-user mailing list.
+---
+ CHANGES.current | 5 +
+ Examples/test-suite/csharp/preproc_constants_c_runme.cs | 3 ++-
+ Examples/test-suite/csharp/preproc_constants_runme.cs | 2 ++
+ Examples/test-suite/d/preproc_constants_c_runme.1.d | 2 ++
+ Examples/test-suite/d/preproc_constants_c_runme.2.d | 2 ++
+ Examples/test-suite/d/preproc_constants_runme.1.d | 2 ++
+ Examples/test-suite/d/preproc_constants_runme.2.d | 2 ++
+ Examples/test-suite/php/preproc_constants_c_runme.php | 2 ++
+ Examples/test-suite/php/preproc_constants_runme.php | 2 ++
+ Examples/test-suite/php5/preproc_constants_c_runme.php | 2 ++
+ Examples/test-suite/php5/preproc_constants_runme.php| 2 ++
+ Examples/test-suite/preproc_constants.i | 3 +++
+ Source/CParse/parser.y | 2 +-
+ 13 files changed, 29 insertions(+), 2 deletions(-)
+
+Upstream-Status: Backport
+[https://github.com/swig/swig/commit/90ba174fcea1618af57aa594199541d47a89b7f6]
+Signed-off-by: Luca Boccassi
+
+diff --git a/Examples/test-suite/csharp/preproc_constants_c_runme.cs
b/Examples/test-suite/csharp/preproc_constants_c_runme.cs
+index 76c684d..1c28e49 100644
+--- a/Examples/test-suite/csharp/preproc_constants_c_runme.cs
b/Examples/test-suite/csharp/preproc_constants_c_runme.cs
+@@ -61,7 +61,8 @@ public class runme {
+ assert( typeof(int) == preproc_constants_c.EXPR_LAND.GetType() );
+ assert( typeof(int) == preproc_constants_c.EXPR_LOR.GetType() );
+ assert( typeof(double) == preproc_constants_c.EXPR_CONDITIONAL.GetType()
);
+-
++assert( typeof(int) == preproc_constants_c.EXPR_WCHAR_MAX.GetType() );
++assert( typeof(int) == preproc_constants_c.EXPR_WCHAR_MIN.GetType() );
+ }
+ static void assert(bool assertion) {
+ if (!assertion)
+diff --git a/Examples/test-suite/csharp/preproc_constants_runme.cs
b/Examples/test-suite/csharp/preproc_constants_runme.cs
+index 9fae591..6b02e30 100644
+--- a/Examples/test-suite/csharp/preproc_constants_runme.cs
b/Examples/test-suite/csharp/preproc_constants_runme.cs
+@@ -60,6 +60,8 @@ public class runme {
+ assert( typeof(bool) == preproc_constants.EXPR_LAND.GetType() );
+ assert( typeof(bool) == preproc_constants.EXPR_LOR.GetType() );
+ assert( typeof(double) == preproc_constants.EXPR_CONDITIONAL.GetType() );
++assert( typeof(int) == preproc_constants.EXPR_WCHAR_MAX.GetType() );
++assert( typeof(int) == preproc_constants.EXPR_WCHAR_MIN.GetType() );
+
+ }
+ static void assert(bool assertion) {
+diff --git a/Examples/test-suite/d/preproc_constants_c_runme.1.d
b/Examples/test-suite/d/preproc_constants_c_runme.1.d
+index d846c71..2b349af 100644
+--- a/Examples/test-suite/d/preproc_constants_c_runme.1.d
b/Examples/test-suite/d/preproc_constants_c_runme.1.d
+@@ -61,4 +61,6 @@ void main() {
+ static assert(is(int == typeof(EXPR_LAND(;
+ static assert(is(int == typeof(EXPR_LOR(;
+ static assert(is(double == typeof(EXPR_CONDITIONAL(;
++ static assert(is(int == typeof(EXPR_WCHAR_MAX(;
++ static assert(is(int == typeof(EXPR_WCHAR_MIN(;
+ }
+diff --git a/Examples/test-suite/d/preproc_constants_c_runme.2.d
b/Examples/test-suite/d/preproc_constants_c_runme.2.d
+index 9bdbb93..1bac525 100644
+--- a/Examples/test-suite/d/preproc_constants_c_runme.2.d
b/Examples/test-suite/d/preproc_constants_c_runme.2.d
+@@ -61,4 +61,6 @@ void main() {
[OE-core] [PATCH] swig: fix build with musl
From: Luca Boccassi
Building with musl currently fails. The fix has been committed
upstream, so backport it.
Note that it requires the recent change to use autoconf's do_configure
as it modifies a bison file which is used at make-dist time, so it
triggers an autoconf rerun which was not working previously due to the
custom do_configure step that was removed recently by:
a9b1f9eca963 ("swig: Fix configure failure")
Signed-off-by: Luca Boccassi
---
...de-for-constant-expressions-containi.patch | 178 ++
meta/recipes-devtools/swig/swig_3.0.12.bb | 1 +
2 files changed, 179 insertions(+)
create mode 100644
meta/recipes-devtools/swig/swig/0001-Fix-generated-code-for-constant-expressions-containi.patch
diff --git
a/meta/recipes-devtools/swig/swig/0001-Fix-generated-code-for-constant-expressions-containi.patch
b/meta/recipes-devtools/swig/swig/0001-Fix-generated-code-for-constant-expressions-containi.patch
new file mode 100644
index 00..4c2bc99ca0
--- /dev/null
+++
b/meta/recipes-devtools/swig/swig/0001-Fix-generated-code-for-constant-expressions-containi.patch
@@ -0,0 +1,178 @@
+From 90ba174fcea1618af57aa594199541d47a89b7f6 Mon Sep 17 00:00:00 2001
+From: William S Fulton
+Date: Sun, 17 Sep 2017 19:02:55 +0100
+Subject: [PATCH 1/2] Fix generated code for constant expressions containing
+ wchar_t L literals.
+
+Such as:
+ # define __WCHAR_MAX(0x7fff + L'\0')
+
+Reported on swig-user mailing list.
+---
+ Examples/test-suite/csharp/preproc_constants_c_runme.cs | 3 ++-
+ Examples/test-suite/csharp/preproc_constants_runme.cs | 2 ++
+ Examples/test-suite/d/preproc_constants_c_runme.1.d | 2 ++
+ Examples/test-suite/d/preproc_constants_c_runme.2.d | 2 ++
+ Examples/test-suite/d/preproc_constants_runme.1.d | 2 ++
+ Examples/test-suite/d/preproc_constants_runme.2.d | 2 ++
+ Examples/test-suite/php/preproc_constants_c_runme.php | 2 ++
+ Examples/test-suite/php/preproc_constants_runme.php | 2 ++
+ Examples/test-suite/php5/preproc_constants_c_runme.php | 2 ++
+ Examples/test-suite/php5/preproc_constants_runme.php| 2 ++
+ Examples/test-suite/preproc_constants.i | 3 +++
+ Source/CParse/parser.y | 2 +-
+ 13 files changed, 29 insertions(+), 2 deletions(-)
+
+Origin:
https://github.com/swig/swig/commit/90ba174fcea1618af57aa594199541d47a89b7f6
+Applied-Upstream: yes
+
+diff --git a/Examples/test-suite/csharp/preproc_constants_c_runme.cs
b/Examples/test-suite/csharp/preproc_constants_c_runme.cs
+index 76c684d..1c28e49 100644
+--- a/Examples/test-suite/csharp/preproc_constants_c_runme.cs
b/Examples/test-suite/csharp/preproc_constants_c_runme.cs
+@@ -61,7 +61,8 @@ public class runme {
+ assert( typeof(int) == preproc_constants_c.EXPR_LAND.GetType() );
+ assert( typeof(int) == preproc_constants_c.EXPR_LOR.GetType() );
+ assert( typeof(double) == preproc_constants_c.EXPR_CONDITIONAL.GetType()
);
+-
++assert( typeof(int) == preproc_constants_c.EXPR_WCHAR_MAX.GetType() );
++assert( typeof(int) == preproc_constants_c.EXPR_WCHAR_MIN.GetType() );
+ }
+ static void assert(bool assertion) {
+ if (!assertion)
+diff --git a/Examples/test-suite/csharp/preproc_constants_runme.cs
b/Examples/test-suite/csharp/preproc_constants_runme.cs
+index 9fae591..6b02e30 100644
+--- a/Examples/test-suite/csharp/preproc_constants_runme.cs
b/Examples/test-suite/csharp/preproc_constants_runme.cs
+@@ -60,6 +60,8 @@ public class runme {
+ assert( typeof(bool) == preproc_constants.EXPR_LAND.GetType() );
+ assert( typeof(bool) == preproc_constants.EXPR_LOR.GetType() );
+ assert( typeof(double) == preproc_constants.EXPR_CONDITIONAL.GetType() );
++assert( typeof(int) == preproc_constants.EXPR_WCHAR_MAX.GetType() );
++assert( typeof(int) == preproc_constants.EXPR_WCHAR_MIN.GetType() );
+
+ }
+ static void assert(bool assertion) {
+diff --git a/Examples/test-suite/d/preproc_constants_c_runme.1.d
b/Examples/test-suite/d/preproc_constants_c_runme.1.d
+index d846c71..2b349af 100644
+--- a/Examples/test-suite/d/preproc_constants_c_runme.1.d
b/Examples/test-suite/d/preproc_constants_c_runme.1.d
+@@ -61,4 +61,6 @@ void main() {
+ static assert(is(int == typeof(EXPR_LAND(;
+ static assert(is(int == typeof(EXPR_LOR(;
+ static assert(is(double == typeof(EXPR_CONDITIONAL(;
++ static assert(is(int == typeof(EXPR_WCHAR_MAX(;
++ static assert(is(int == typeof(EXPR_WCHAR_MIN(;
+ }
+diff --git a/Examples/test-suite/d/preproc_constants_c_runme.2.d
b/Examples/test-suite/d/preproc_constants_c_runme.2.d
+index 9bdbb93..1bac525 100644
+--- a/Examples/test-suite/d/preproc_constants_c_runme.2.d
b/Examples/test-suite/d/preproc_constants_c_runme.2.d
+@@ -61,4 +61,6 @@ void main() {
+ static assert(is(int == typeof(EXPR_LAND(;
+ static assert(is(int == typeof(EXPR_LOR(;
+ static assert(is(double == typeof(EXPR_CON
