Re: [OE-core] Should systemd be marked as incompatible with musl?

[Andre McCurdy]

On Fri, May 24, 2019 at 1:28 PM Adrian Bunk  wrote:
> On Fri, May 24, 2019 at 12:34:23PM -0700, Andre McCurdy wrote:
> > On Fri, May 24, 2019 at 11:46 AM Adrian Bunk  wrote:
> > > On Fri, May 24, 2019 at 11:04:50AM -0700, Khem Raj wrote:
> >...
> > > > I think we should put in plan for 2.8 and define the scope, since we
> > > > are switching
> > > > poky defaults to systemd,
> > >
> > > Switching glibc builds to systemd as default is a reasonable decision.
> > >
> > > Switching musl builds to systemd as default would be very bad.
> > >
> > > Combining a tiny C library with a huge init system completely misses
> > > the configurations where the tiny C library actually makes sense for
> > > users.
> >
> > For new projects yes. However I know of a project (a big project,
> > shipping millions of devices) which picked systemd and glibc long ago
> > and is now running out of space. They already have various solutions
> > to free up Flash (some apps switched to being runtime downloadable,
> > etc) but if/when more savings need to be found then switching from
> > glibc to musl might be a less invasive change than switching from
> > systemd to some other init system. We obviously shouldn't make
> > decisions for OE today based on the historical decisions of one
> > project, but I just want to make the point that real world projects
> > have a lifetime and may end up with a combination of systemd + musl
> > due on past decisions that may not make sense for a new project
> > starting today.
>
> I am feeling guilty that there are two only partially related
> topics mixed in this discussion.
>
> In this part of the discussion the topic was what the default
> (and CI-tested) init system for musl should be - it seems obvious
> to me that systemd is not what users will usually want to use with musl.

It would be great to have an alternative init system option for
smaller devices in oe-core. I don't think collectively we have the
development capacity to support it though (it's probably far more work
than properly fixing all the currently known issues with systemd on
musl...).

> But there is also the topic whether systemd on musl is
> in a state that it should be made available at all.

I think it's wrong to remove stuff from oe-core just because it isn't
perfect or isn't CI tested. Having something in oe-core means there's
a common version to collaborate on. If it gets kicked out then
development efforts inevitably fragment. Users are generally smart
enough to understand the concept of an experimental feature - although
we could perhaps do a better job of identifying them. Maybe one day
when users can create a custom distro config by running "make
menuconfig" there will be an option to enable experimental features
and the combination of musl and systemd would be hidden behind that.
Until then, perhaps we could add a sanity check warning if musl and
systemd are enabled together?

> Does any of these millions of devices have untrusted
> users or an internet connection?

No local users (if I remember right, everything runs as root) but they
do all have broadband internet connections.

> At that point my email that started this thread becomes relevant,
> the fact that the systemd/musl patches in OE add new security
> vulnerabilities and other bugs - and none of the systemd-on-musl
> proponents seems to consider this a problem they have to fix ASAP.

It's certainly a problem and we should try to fix it. It's not at all
uncommon that patches to fix build issues with musl, clang, a new
version of gcc, etc have a life cycle... a first pass just to fix the
build and then updates as issues are found or better solutions get
merged upstream. It's the normal process. You could argue that we are
sometimes too quick to merge the first pass hacks and too slow to
review and update them, but unfortunately that's just a consequence of
limited developer resources (and it's always more fun to try to get
the latest version of something working than review and cleanup old
patches...).
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Should systemd be marked as incompatible with musl?

[Adrian Bunk]

On Fri, May 24, 2019 at 12:34:23PM -0700, Andre McCurdy wrote:
> On Fri, May 24, 2019 at 11:46 AM Adrian Bunk  wrote:
> > On Fri, May 24, 2019 at 11:04:50AM -0700, Khem Raj wrote:
>...
> > > I think we should put in plan for 2.8 and define the scope, since we
> > > are switching
> > > poky defaults to systemd,
> > 
> > Switching glibc builds to systemd as default is a reasonable decision.
> >
> > Switching musl builds to systemd as default would be very bad.
> >
> > Combining a tiny C library with a huge init system completely misses
> > the configurations where the tiny C library actually makes sense for
> > users.
> 
> For new projects yes. However I know of a project (a big project,
> shipping millions of devices) which picked systemd and glibc long ago
> and is now running out of space. They already have various solutions
> to free up Flash (some apps switched to being runtime downloadable,
> etc) but if/when more savings need to be found then switching from
> glibc to musl might be a less invasive change than switching from
> systemd to some other init system. We obviously shouldn't make
> decisions for OE today based on the historical decisions of one
> project, but I just want to make the point that real world projects
> have a lifetime and may end up with a combination of systemd + musl
> due on past decisions that may not make sense for a new project
> starting today.

I am feeling guilty that there are two only partially related
topics mixed in this discussion.

In this part of the discussion the topic was what the default 
(and CI-tested) init system for musl should be - it seems obvious
to me that systemd is not what users will usually want to use with musl.

But there is also the topic whether systemd on musl is
in a state that it should be made available at all.

Does any of these millions of devices have untrusted
users or an internet connection?

At that point my email that started this thread becomes relevant,
the fact that the systemd/musl patches in OE add new security 
vulnerabilities and other bugs - and none of the systemd-on-musl
proponents seems to consider this a problem they have to fix ASAP.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Should systemd be marked as incompatible with musl?

[Khem Raj]

On Fri, May 24, 2019 at 12:34 PM Andre McCurdy  wrote:
>
> On Fri, May 24, 2019 at 11:46 AM Adrian Bunk  wrote:
> >
> > On Fri, May 24, 2019 at 11:04:50AM -0700, Khem Raj wrote:
> > > On Fri, May 24, 2019 at 10:59 AM Adrian Bunk  wrote:
> > > >
> > > > On Fri, May 24, 2019 at 10:31:25AM -0700, Khem Raj wrote:
> > > > > On Fri, May 24, 2019 at 10:27 AM Adrian Bunk  wrote:
> > > > > > On Fri, May 24, 2019 at 09:13:08AM -0700, Khem Raj wrote:
> > > > > > > On 5/24/19 3:12 AM, Adrian Bunk wrote:
> > > > > > > > On Thu, May 23, 2019 at 07:16:53PM -0700, Khem Raj wrote:
> > > > > > > > > ...
> > > > > > > > > but I think dropping
> > > > > > > > > systemd support completely from musl is not an option I would 
> > > > > > > > > like to go
> > > > > > > > > with, there are cases where this makes sense. Especially when 
> > > > > > > > > you have to
> > > > > > > > > cater to different set of devices from small to big, 
> > > > > > > > > userspace remaining
> > > > > > > > > same is big advantage atleast in the world I am in.
> > > > > > > > > ...
> > > > > > > >
> > > > > > > > That's a good point - when arguing against systemd as default 
> > > > > > > > init system.
> > > > > > > >
> > > > > > > > systemd is bigger than glibc, therefore on very small systems 
> > > > > > > > where the
> > > > > > > > size of the C library matters using systemd is usually not an 
> > > > > > > > option.
> > > > > > >
> > > > > > > Yes, design-wise I concur, in practice, desktop distros rule the 
> > > > > > > linux world
> > > > > > > and systemd is quite prevalent there,
> > > > > >
> > > > > > Desktop distros don't use musl - it wouldn't make sense.
> > > > >
> > > > > Yes,  what I was saying is that decisions on init systems and like 
> > > > > that are
> > > > > influenced by desktops too. Since the apps are being written for 
> > > > > across the
> > > > > board portfolio where some platforms are desktop/server driven some 
> > > > > are
> > > > > more embedded
> > > >
> > > > The point is that most of the time using musl doesn't make sense.
> > > >
> > > > Definitely not on a desktop, and also not with systemd as init system.
> > > >
> > > > I haven't done exact measurements and it would also depend on the
> > > > architecture, but the only real-world benefit of using musl instead
> > > > of glibc for an OE user is something like "3 MB smaller in an -Os 
> > > > build".
> > > >
> > > > On many of todays embedded systems such a small size difference is
> > > > irrelevant. In these cases the correct solution that stays compatible
> > > > with everything else is to use glibc.
> > >
> > > No, there is DRAM use difference too.
> >
> > I didn't limit the size difference to the filesystem.
> >
> > (But in practice RAM is usually a smaller problem than the filesystem.)
> >
> > > > And on really tiny systems where every single MB counts,
> > > > all other design choices also have a high emphasis on size.
> > > >
> > > > Using systemd instead of busybox init (or some other small init system)
> > > > would cost you much more space than what the C library choice gave.
> > > >
> > > > And the current sad state of the systemd musl patching that makes it
> > > > compile but creates misbehaving functions and security vulnerabilities
> > > > makes it an even worse idea to use systemd with musl.
> > > >
> > >
> > > I think we should put in plan for 2.8 and define the scope, since we
> > > are switching
> > > poky defaults to systemd,
> >
> > Switching glibc builds to systemd as default is a reasonable decision.
> >
> > Switching musl builds to systemd as default would be very bad.
> >
> > Combining a tiny C library with a huge init system completely misses
> > the configurations where the tiny C library actually makes sense for
> > users.
>
> For new projects yes. However I know of a project (a big project,
> shipping millions of devices) which picked systemd and glibc long ago
> and is now running out of space. They already have various solutions
> to free up Flash (some apps switched to being runtime downloadable,
> etc) but if/when more savings need to be found then switching from
> glibc to musl might be a less invasive change than switching from
> systemd to some other init system. We obviously shouldn't make
> decisions for OE today based on the historical decisions of one
> project, but I just want to make the point that real world projects
> have a lifetime and may end up with a combination of systemd + musl
> due on past decisions that may not make sense for a new project
> starting today.

rightly so, and it can also mean that project moves away from OE if headwind
is too strong.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v3 1/2] local.conf.sample: make systemd as default init manager

[Khem Raj]

On Fri, May 24, 2019 at 12:23 PM Peter Kjellerstedt
 wrote:
>
> > -Original Message-
> > From: Khem Raj 
> > Sent: den 23 maj 2019 22:59
> > To: Peter Kjellerstedt 
> > Cc: kai.k...@windriver.com; openembedded-core@lists.openembedded.org; 
> > richard.pur...@linuxfoundation.org
> > Subject: Re: [OE-core] [PATCH v3 1/2] local.conf.sample: make systemd as 
> > default init manager
> >
> > On Thu, May 23, 2019 at 1:41 PM Peter Kjellerstedt 
> >  wrote:
> > > -Original Message-
> > > From: mailto:openembedded-core-boun...@lists.openembedded.org 
> > >  > > mailto:core-boun...@lists.openembedded.org> On Behalf Of
> > > mailto:kai.k...@windriver.com
> > > Sent: den 23 maj 2019 10:26
> > > To: mailto:richard.pur...@linuxfoundation.org
> > > Cc: mailto:openembedded-core@lists.openembedded.org
> > > Subject: [OE-core] [PATCH v3 1/2] local.conf.sample: make systemd as
> > > default init manager
> > >
> > > From: Kai Kang 
> > >
> > > Move configurations from local.conf.sample.extended to local.conf.sample
> > > to make systemd as default init manager for poky.
> >
> > If we're going to change the default init manager to be systemd, wouldn't
> > it be more appropriate to change the real default values in bitbake.conf
> > and http://packagegroup-core-boot.bb? And then include an example in
> > local.conf.sample.extended to show how to configure sysvinit as init
> > manager?
> >
> > That would change it for Oe-core and other distributions as well which
> > is not the intention
>
> Ok, then I'd say the change belongs in poky.conf. Doing this kind of changes
> in local.conf.sample seems very wrong to me. Why? Because if I have an
> existing build tree it will not be affected, but if I setup a new tree with
> oe-init-build-env it will all of a sudden behave differently from the old
> tree. In my mind, local.conf.sample should only be used for things the user
> are likely to want to configure to adapt the build for his/her environment,
> not to define the distribution (that's what poky.conf is for).

yes distro config is right place.

>
> //Peter
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/1] systemd: avoid musl specific patches affect glibc systems

[Khem Raj]

On Fri, May 24, 2019 at 12:14 PM Martin Jansa  wrote:
>
> It's still nicer to have
> SRC_URI_append_libc-musl = " ${SRC_URI_MUSL}"
> if the intermediate SRC_URI_MUSL variable is useful.

yeah we can do away with this one variable here.

>
> On Fri, May 24, 2019 at 7:59 PM Khem Raj  wrote:
>>
>> On Fri, May 24, 2019 at 10:31 AM Richard Purdie
>>  wrote:
>> >
>> > On Fri, 2019-05-24 at 10:17 +0800, Chen Qi wrote:
>> > > systemd upstream only care about glibc. We made musl specific
>> > > patches so that systemd could work. But currently these patches
>> > > contain potential security issues.
>> > >
>> > > So apply these patches only when the libc is musl.
>> > >
>> > > Signed-off-by: Chen Qi 
>> > > ---
>> > >  meta/recipes-core/systemd/systemd_242.bb | 2 +-
>> > >  1 file changed, 1 insertion(+), 1 deletion(-)
>> > >
>> > > diff --git a/meta/recipes-core/systemd/systemd_242.bb b/meta/recipes-
>> > > core/systemd/systemd_242.bb
>> > > index 2dda0d0..adb592f 100644
>> > > --- a/meta/recipes-core/systemd/systemd_242.bb
>> > > +++ b/meta/recipes-core/systemd/systemd_242.bb
>> > > @@ -27,7 +27,7 @@ SRC_URI += "file://touchscreen.rules \
>> > > "
>> > >
>> > >  # patches needed by musl
>> > > -SRC_URI += "${SRC_URI_MUSL}"
>> > > +SRC_URI += "${@d.getVar('SRC_URI_MUSL') if d.getVar('TCLIBC') ==
>> > > 'musl' else ''}"
>> > >  SRC_URI_MUSL = "file://0001-Use-getenv-when-secure-versions-are-not-
>> > > available.patch \
>> > > file://0002-don-t-use-glibc-specific-qsort_r.patch \
>> > > file://0003-missing_type.h-add-__compare_fn_t-and-
>> > > comparison_fn_.patch \
>> >
>> > Doesn't the usual SRC_URI_append_libc-musl = "X" work?
>> >
>>
>> yes this should be better, SRC_URI_MUSL was introduced so someone
>> could override it
>> but if we make it optional then using override is better I think
>>
>> > Cheers,
>> >
>> > Richard
>> >
>> > --
>> > ___
>> > Openembedded-core mailing list
>> > Openembedded-core@lists.openembedded.org
>> > http://lists.openembedded.org/mailman/listinfo/openembedded-core
>> --
>> ___
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Should systemd be marked as incompatible with musl?

[Andre McCurdy]

On Fri, May 24, 2019 at 11:46 AM Adrian Bunk  wrote:
>
> On Fri, May 24, 2019 at 11:04:50AM -0700, Khem Raj wrote:
> > On Fri, May 24, 2019 at 10:59 AM Adrian Bunk  wrote:
> > >
> > > On Fri, May 24, 2019 at 10:31:25AM -0700, Khem Raj wrote:
> > > > On Fri, May 24, 2019 at 10:27 AM Adrian Bunk  wrote:
> > > > > On Fri, May 24, 2019 at 09:13:08AM -0700, Khem Raj wrote:
> > > > > > On 5/24/19 3:12 AM, Adrian Bunk wrote:
> > > > > > > On Thu, May 23, 2019 at 07:16:53PM -0700, Khem Raj wrote:
> > > > > > > > ...
> > > > > > > > but I think dropping
> > > > > > > > systemd support completely from musl is not an option I would 
> > > > > > > > like to go
> > > > > > > > with, there are cases where this makes sense. Especially when 
> > > > > > > > you have to
> > > > > > > > cater to different set of devices from small to big, userspace 
> > > > > > > > remaining
> > > > > > > > same is big advantage atleast in the world I am in.
> > > > > > > > ...
> > > > > > >
> > > > > > > That's a good point - when arguing against systemd as default 
> > > > > > > init system.
> > > > > > >
> > > > > > > systemd is bigger than glibc, therefore on very small systems 
> > > > > > > where the
> > > > > > > size of the C library matters using systemd is usually not an 
> > > > > > > option.
> > > > > >
> > > > > > Yes, design-wise I concur, in practice, desktop distros rule the 
> > > > > > linux world
> > > > > > and systemd is quite prevalent there,
> > > > >
> > > > > Desktop distros don't use musl - it wouldn't make sense.
> > > >
> > > > Yes,  what I was saying is that decisions on init systems and like that 
> > > > are
> > > > influenced by desktops too. Since the apps are being written for across 
> > > > the
> > > > board portfolio where some platforms are desktop/server driven some are
> > > > more embedded
> > >
> > > The point is that most of the time using musl doesn't make sense.
> > >
> > > Definitely not on a desktop, and also not with systemd as init system.
> > >
> > > I haven't done exact measurements and it would also depend on the
> > > architecture, but the only real-world benefit of using musl instead
> > > of glibc for an OE user is something like "3 MB smaller in an -Os build".
> > >
> > > On many of todays embedded systems such a small size difference is
> > > irrelevant. In these cases the correct solution that stays compatible
> > > with everything else is to use glibc.
> >
> > No, there is DRAM use difference too.
>
> I didn't limit the size difference to the filesystem.
>
> (But in practice RAM is usually a smaller problem than the filesystem.)
>
> > > And on really tiny systems where every single MB counts,
> > > all other design choices also have a high emphasis on size.
> > >
> > > Using systemd instead of busybox init (or some other small init system)
> > > would cost you much more space than what the C library choice gave.
> > >
> > > And the current sad state of the systemd musl patching that makes it
> > > compile but creates misbehaving functions and security vulnerabilities
> > > makes it an even worse idea to use systemd with musl.
> > >
> >
> > I think we should put in plan for 2.8 and define the scope, since we
> > are switching
> > poky defaults to systemd,
>
> Switching glibc builds to systemd as default is a reasonable decision.
>
> Switching musl builds to systemd as default would be very bad.
>
> Combining a tiny C library with a huge init system completely misses
> the configurations where the tiny C library actually makes sense for
> users.

For new projects yes. However I know of a project (a big project,
shipping millions of devices) which picked systemd and glibc long ago
and is now running out of space. They already have various solutions
to free up Flash (some apps switched to being runtime downloadable,
etc) but if/when more savings need to be found then switching from
glibc to musl might be a less invasive change than switching from
systemd to some other init system. We obviously shouldn't make
decisions for OE today based on the historical decisions of one
project, but I just want to make the point that real world projects
have a lifetime and may end up with a combination of systemd + musl
due on past decisions that may not make sense for a new project
starting today.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v3 1/2] local.conf.sample: make systemd as default init manager

[Peter Kjellerstedt]

> -Original Message-
> From: Khem Raj  
> Sent: den 23 maj 2019 22:59
> To: Peter Kjellerstedt 
> Cc: kai.k...@windriver.com; openembedded-core@lists.openembedded.org; 
> richard.pur...@linuxfoundation.org
> Subject: Re: [OE-core] [PATCH v3 1/2] local.conf.sample: make systemd as 
> default init manager
> 
> On Thu, May 23, 2019 at 1:41 PM Peter Kjellerstedt 
>  wrote:
> > -Original Message-
> > From: mailto:openembedded-core-boun...@lists.openembedded.org  > mailto:core-boun...@lists.openembedded.org> On Behalf Of
> > mailto:kai.k...@windriver.com
> > Sent: den 23 maj 2019 10:26
> > To: mailto:richard.pur...@linuxfoundation.org
> > Cc: mailto:openembedded-core@lists.openembedded.org
> > Subject: [OE-core] [PATCH v3 1/2] local.conf.sample: make systemd as
> > default init manager
> > 
> > From: Kai Kang 
> > 
> > Move configurations from local.conf.sample.extended to local.conf.sample
> > to make systemd as default init manager for poky.
> 
> If we're going to change the default init manager to be systemd, wouldn't 
> it be more appropriate to change the real default values in bitbake.conf 
> and http://packagegroup-core-boot.bb? And then include an example in 
> local.conf.sample.extended to show how to configure sysvinit as init 
> manager?
> 
> That would change it for Oe-core and other distributions as well which 
> is not the intention 

Ok, then I'd say the change belongs in poky.conf. Doing this kind of changes 
in local.conf.sample seems very wrong to me. Why? Because if I have an 
existing build tree it will not be affected, but if I setup a new tree with 
oe-init-build-env it will all of a sudden behave differently from the old 
tree. In my mind, local.conf.sample should only be used for things the user 
are likely to want to configure to adapt the build for his/her environment, 
not to define the distribution (that's what poky.conf is for).

//Peter

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/1] systemd: avoid musl specific patches affect glibc systems

[Martin Jansa]

It's still nicer to have
SRC_URI_append_libc-musl = " ${SRC_URI_MUSL}"
if the intermediate SRC_URI_MUSL variable is useful.

On Fri, May 24, 2019 at 7:59 PM Khem Raj  wrote:

> On Fri, May 24, 2019 at 10:31 AM Richard Purdie
>  wrote:
> >
> > On Fri, 2019-05-24 at 10:17 +0800, Chen Qi wrote:
> > > systemd upstream only care about glibc. We made musl specific
> > > patches so that systemd could work. But currently these patches
> > > contain potential security issues.
> > >
> > > So apply these patches only when the libc is musl.
> > >
> > > Signed-off-by: Chen Qi 
> > > ---
> > >  meta/recipes-core/systemd/systemd_242.bb | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/meta/recipes-core/systemd/systemd_242.bb b/meta/recipes-
> > > core/systemd/systemd_242.bb
> > > index 2dda0d0..adb592f 100644
> > > --- a/meta/recipes-core/systemd/systemd_242.bb
> > > +++ b/meta/recipes-core/systemd/systemd_242.bb
> > > @@ -27,7 +27,7 @@ SRC_URI += "file://touchscreen.rules \
> > > "
> > >
> > >  # patches needed by musl
> > > -SRC_URI += "${SRC_URI_MUSL}"
> > > +SRC_URI += "${@d.getVar('SRC_URI_MUSL') if d.getVar('TCLIBC') ==
> > > 'musl' else ''}"
> > >  SRC_URI_MUSL = "file://0001-Use-getenv-when-secure-versions-are-not-
> > > available.patch \
> > > file://0002-don-t-use-glibc-specific-qsort_r.patch \
> > > file://0003-missing_type.h-add-__compare_fn_t-and-
> > > comparison_fn_.patch \
> >
> > Doesn't the usual SRC_URI_append_libc-musl = "X" work?
> >
>
> yes this should be better, SRC_URI_MUSL was introduced so someone
> could override it
> but if we make it optional then using override is better I think
>
> > Cheers,
> >
> > Richard
> >
> > --
> > ___
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-core
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH V2] alsa-utils: fix multilib names

[Tanu Kaskinen]

On Fri, 2019-05-24 at 18:18 +0100, Richard Purdie wrote:
> On Fri, 2019-05-24 at 15:19 +0200, Ming Liu wrote:
> > Wouldn't that break the alsa-utils-scripts? Since ALSA_UTILS_PKGS is
> > being depended by both alsa-utils and alsa-utils-scripts.
> > 
> > I did that in V1, but as Richard Purdie pointed out, it will break
> > the alsa-utils-scripts build.
> 
> I was about to say we should refactor these recipes and create a common
> inc file.
> 
> Looking at the justification in alsa-utils (avoid a bash dependency),
> that is a runtime issue, not a build time one. We should merge these
> recipes and ensure the packaging remains the same.
> 
> We can then avoid some of these problems, use PN and have a simpler
> recipe. These changes should be done in multiple commits, one per
> change as usual.
> 
> Is there any reason I'm missing not to do this?

I'm not sure if you already found the original commit[1] that
introduced this split. The commit message is:

alsa-utils: Move alsaconf to its own recipe

18575b082a4042376fd1575465e69562dea04ddc added bash as a dependency of
alsa-utils-alsaconf so that the script interpreter will be available at
run time.  However, this has the undesirable side effect of making bash
be a build dependency for alsa-utils and, for those folks who don't need
alsaconf but do want some other part of alsa-utils, this cure is worse
than the original disease.

Fix this by moving alsaconf to a separate recipe so that the bash
dependency only applies when alsaconf is specifically requested.

Signed-off-by: Phil Blundell 
Signed-off-by: Saul Wold 

I can't really judge if that justification makes sense. If the
justification is valid, maybe there's a better solution for avoiding
the build dependency on bash for those people who don't need the
scripts?

[1] 
http://cgit.openembedded.org/openembedded-core/commit/?id=7317c8055cf3af8912a66badb3074f0a60f75ec2

-- 
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Should systemd be marked as incompatible with musl?

[Adrian Bunk]

On Fri, May 24, 2019 at 11:04:50AM -0700, Khem Raj wrote:
> On Fri, May 24, 2019 at 10:59 AM Adrian Bunk  wrote:
> >
> > On Fri, May 24, 2019 at 10:31:25AM -0700, Khem Raj wrote:
> > > On Fri, May 24, 2019 at 10:27 AM Adrian Bunk  wrote:
> > > > On Fri, May 24, 2019 at 09:13:08AM -0700, Khem Raj wrote:
> > > > > On 5/24/19 3:12 AM, Adrian Bunk wrote:
> > > > > > On Thu, May 23, 2019 at 07:16:53PM -0700, Khem Raj wrote:
> > > > > > > ...
> > > > > > > but I think dropping
> > > > > > > systemd support completely from musl is not an option I would 
> > > > > > > like to go
> > > > > > > with, there are cases where this makes sense. Especially when you 
> > > > > > > have to
> > > > > > > cater to different set of devices from small to big, userspace 
> > > > > > > remaining
> > > > > > > same is big advantage atleast in the world I am in.
> > > > > > > ...
> > > > > >
> > > > > > That's a good point - when arguing against systemd as default init 
> > > > > > system.
> > > > > >
> > > > > > systemd is bigger than glibc, therefore on very small systems where 
> > > > > > the
> > > > > > size of the C library matters using systemd is usually not an 
> > > > > > option.
> > > > >
> > > > > Yes, design-wise I concur, in practice, desktop distros rule the 
> > > > > linux world
> > > > > and systemd is quite prevalent there,
> > > >
> > > > Desktop distros don't use musl - it wouldn't make sense.
> > >
> > > Yes,  what I was saying is that decisions on init systems and like that 
> > > are
> > > influenced by desktops too. Since the apps are being written for across 
> > > the
> > > board portfolio where some platforms are desktop/server driven some are
> > > more embedded
> >
> > The point is that most of the time using musl doesn't make sense.
> >
> > Definitely not on a desktop, and also not with systemd as init system.
> >
> > I haven't done exact measurements and it would also depend on the
> > architecture, but the only real-world benefit of using musl instead
> > of glibc for an OE user is something like "3 MB smaller in an -Os build".
> >
> > On many of todays embedded systems such a small size difference is
> > irrelevant. In these cases the correct solution that stays compatible
> > with everything else is to use glibc.
> 
> No, there is DRAM use difference too.

I didn't limit the size difference to the filesystem.

(But in practice RAM is usually a smaller problem than the filesystem.)

> > And on really tiny systems where every single MB counts,
> > all other design choices also have a high emphasis on size.
> >
> > Using systemd instead of busybox init (or some other small init system)
> > would cost you much more space than what the C library choice gave.
> >
> > And the current sad state of the systemd musl patching that makes it
> > compile but creates misbehaving functions and security vulnerabilities
> > makes it an even worse idea to use systemd with musl.
> >
> 
> I think we should put in plan for 2.8 and define the scope, since we
> are switching
> poky defaults to systemd,

Switching glibc builds to systemd as default is a reasonable decision.

Switching musl builds to systemd as default would be very bad.

Combining a tiny C library with a huge init system completely misses
the configurations where the tiny C library actually makes sense for 
users.

> this might have testing implications for
> musl especially from
> CI perpective

The CI should aim at testing what makes sense for users.

Offering musl becomes pointless if there is no small init system that 
is properly supported and tested with musl builds.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Should systemd be marked as incompatible with musl?

[Khem Raj]

On Fri, May 24, 2019 at 10:59 AM Adrian Bunk  wrote:
>
> On Fri, May 24, 2019 at 10:31:25AM -0700, Khem Raj wrote:
> > On Fri, May 24, 2019 at 10:27 AM Adrian Bunk  wrote:
> > > On Fri, May 24, 2019 at 09:13:08AM -0700, Khem Raj wrote:
> > > > On 5/24/19 3:12 AM, Adrian Bunk wrote:
> > > > > On Thu, May 23, 2019 at 07:16:53PM -0700, Khem Raj wrote:
> > > > > > ...
> > > > > > but I think dropping
> > > > > > systemd support completely from musl is not an option I would like 
> > > > > > to go
> > > > > > with, there are cases where this makes sense. Especially when you 
> > > > > > have to
> > > > > > cater to different set of devices from small to big, userspace 
> > > > > > remaining
> > > > > > same is big advantage atleast in the world I am in.
> > > > > > ...
> > > > >
> > > > > That's a good point - when arguing against systemd as default init 
> > > > > system.
> > > > >
> > > > > systemd is bigger than glibc, therefore on very small systems where 
> > > > > the
> > > > > size of the C library matters using systemd is usually not an option.
> > > >
> > > > Yes, design-wise I concur, in practice, desktop distros rule the linux 
> > > > world
> > > > and systemd is quite prevalent there,
> > >
> > > Desktop distros don't use musl - it wouldn't make sense.
> >
> > Yes,  what I was saying is that decisions on init systems and like that are
> > influenced by desktops too. Since the apps are being written for across the
> > board portfolio where some platforms are desktop/server driven some are
> > more embedded
>
> The point is that most of the time using musl doesn't make sense.
>
> Definitely not on a desktop, and also not with systemd as init system.
>
> I haven't done exact measurements and it would also depend on the
> architecture, but the only real-world benefit of using musl instead
> of glibc for an OE user is something like "3 MB smaller in an -Os build".
>
> On many of todays embedded systems such a small size difference is
> irrelevant. In these cases the correct solution that stays compatible
> with everything else is to use glibc.

No, there is DRAM use difference too.

>
> And on really tiny systems where every single MB counts,
> all other design choices also have a high emphasis on size.
>
> Using systemd instead of busybox init (or some other small init system)
> would cost you much more space than what the C library choice gave.
>
> And the current sad state of the systemd musl patching that makes it
> compile but creates misbehaving functions and security vulnerabilities
> makes it an even worse idea to use systemd with musl.
>

I think we should put in plan for 2.8 and define the scope, since we
are switching
poky defaults to systemd, this might have testing implications for
musl especially from
CI perpective

> cu
> Adrian
>
> --
>
>"Is there not promise of rain?" Ling Tan asked suddenly out
> of the darkness. There had been need of rain for many days.
>"Only a promise," Lao Er said.
>Pearl S. Buck - Dragon Seed
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Should systemd be marked as incompatible with musl?

[Adrian Bunk]

On Fri, May 24, 2019 at 10:31:25AM -0700, Khem Raj wrote:
> On Fri, May 24, 2019 at 10:27 AM Adrian Bunk  wrote:
> > On Fri, May 24, 2019 at 09:13:08AM -0700, Khem Raj wrote:
> > > On 5/24/19 3:12 AM, Adrian Bunk wrote:
> > > > On Thu, May 23, 2019 at 07:16:53PM -0700, Khem Raj wrote:
> > > > > ...
> > > > > but I think dropping
> > > > > systemd support completely from musl is not an option I would like to 
> > > > > go
> > > > > with, there are cases where this makes sense. Especially when you 
> > > > > have to
> > > > > cater to different set of devices from small to big, userspace 
> > > > > remaining
> > > > > same is big advantage atleast in the world I am in.
> > > > > ...
> > > >
> > > > That's a good point - when arguing against systemd as default init 
> > > > system.
> > > >
> > > > systemd is bigger than glibc, therefore on very small systems where the
> > > > size of the C library matters using systemd is usually not an option.
> > >
> > > Yes, design-wise I concur, in practice, desktop distros rule the linux 
> > > world
> > > and systemd is quite prevalent there,
> >
> > Desktop distros don't use musl - it wouldn't make sense.
> 
> Yes,  what I was saying is that decisions on init systems and like that are
> influenced by desktops too. Since the apps are being written for across the
> board portfolio where some platforms are desktop/server driven some are
> more embedded

The point is that most of the time using musl doesn't make sense.

Definitely not on a desktop, and also not with systemd as init system.

I haven't done exact measurements and it would also depend on the 
architecture, but the only real-world benefit of using musl instead
of glibc for an OE user is something like "3 MB smaller in an -Os build".

On many of todays embedded systems such a small size difference is 
irrelevant. In these cases the correct solution that stays compatible
with everything else is to use glibc.

And on really tiny systems where every single MB counts,
all other design choices also have a high emphasis on size.

Using systemd instead of busybox init (or some other small init system) 
would cost you much more space than what the C library choice gave.

And the current sad state of the systemd musl patching that makes it
compile but creates misbehaving functions and security vulnerabilities
makes it an even worse idea to use systemd with musl.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/1] systemd: avoid musl specific patches affect glibc systems

[Khem Raj]

On Fri, May 24, 2019 at 10:31 AM Richard Purdie
 wrote:
>
> On Fri, 2019-05-24 at 10:17 +0800, Chen Qi wrote:
> > systemd upstream only care about glibc. We made musl specific
> > patches so that systemd could work. But currently these patches
> > contain potential security issues.
> >
> > So apply these patches only when the libc is musl.
> >
> > Signed-off-by: Chen Qi 
> > ---
> >  meta/recipes-core/systemd/systemd_242.bb | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/meta/recipes-core/systemd/systemd_242.bb b/meta/recipes-
> > core/systemd/systemd_242.bb
> > index 2dda0d0..adb592f 100644
> > --- a/meta/recipes-core/systemd/systemd_242.bb
> > +++ b/meta/recipes-core/systemd/systemd_242.bb
> > @@ -27,7 +27,7 @@ SRC_URI += "file://touchscreen.rules \
> > "
> >
> >  # patches needed by musl
> > -SRC_URI += "${SRC_URI_MUSL}"
> > +SRC_URI += "${@d.getVar('SRC_URI_MUSL') if d.getVar('TCLIBC') ==
> > 'musl' else ''}"
> >  SRC_URI_MUSL = "file://0001-Use-getenv-when-secure-versions-are-not-
> > available.patch \
> > file://0002-don-t-use-glibc-specific-qsort_r.patch \
> > file://0003-missing_type.h-add-__compare_fn_t-and-
> > comparison_fn_.patch \
>
> Doesn't the usual SRC_URI_append_libc-musl = "X" work?
>

yes this should be better, SRC_URI_MUSL was introduced so someone
could override it
but if we make it optional then using override is better I think

> Cheers,
>
> Richard
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/1] systemd: avoid musl specific patches affect glibc systems

[Richard Purdie]

On Fri, 2019-05-24 at 10:17 +0800, Chen Qi wrote:
> systemd upstream only care about glibc. We made musl specific
> patches so that systemd could work. But currently these patches
> contain potential security issues.
> 
> So apply these patches only when the libc is musl.
> 
> Signed-off-by: Chen Qi 
> ---
>  meta/recipes-core/systemd/systemd_242.bb | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meta/recipes-core/systemd/systemd_242.bb b/meta/recipes-
> core/systemd/systemd_242.bb
> index 2dda0d0..adb592f 100644
> --- a/meta/recipes-core/systemd/systemd_242.bb
> +++ b/meta/recipes-core/systemd/systemd_242.bb
> @@ -27,7 +27,7 @@ SRC_URI += "file://touchscreen.rules \
> "
>  
>  # patches needed by musl
> -SRC_URI += "${SRC_URI_MUSL}"
> +SRC_URI += "${@d.getVar('SRC_URI_MUSL') if d.getVar('TCLIBC') ==
> 'musl' else ''}"
>  SRC_URI_MUSL = "file://0001-Use-getenv-when-secure-versions-are-not-
> available.patch \
> file://0002-don-t-use-glibc-specific-qsort_r.patch \
> file://0003-missing_type.h-add-__compare_fn_t-and-
> comparison_fn_.patch \

Doesn't the usual SRC_URI_append_libc-musl = "X" work?

Cheers,

Richard

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Should systemd be marked as incompatible with musl?

[Khem Raj]

On Fri, May 24, 2019 at 10:27 AM Adrian Bunk  wrote:
>
> On Fri, May 24, 2019 at 09:13:08AM -0700, Khem Raj wrote:
> >
> >
> > On 5/24/19 3:12 AM, Adrian Bunk wrote:
> > > On Thu, May 23, 2019 at 07:16:53PM -0700, Khem Raj wrote:
> > > > ...
> > > > but I think dropping
> > > > systemd support completely from musl is not an option I would like to go
> > > > with, there are cases where this makes sense. Especially when you have 
> > > > to
> > > > cater to different set of devices from small to big, userspace remaining
> > > > same is big advantage atleast in the world I am in.
> > > > ...
> > >
> > > That's a good point - when arguing against systemd as default init system.
> > >
> > > systemd is bigger than glibc, therefore on very small systems where the
> > > size of the C library matters using systemd is usually not an option.
> >
> > Yes, design-wise I concur, in practice, desktop distros rule the linux world
> > and systemd is quite prevalent there,
>
> Desktop distros don't use musl - it wouldn't make sense.
>

Yes,  what I was saying is that decisions on init systems and like that are
influenced by desktops too. Since the apps are being written for across the
board portfolio where some platforms are desktop/server driven some are
more embedded

> > so sometimes you have to wear the
> > shoes of same color, atleast thats what I see.
>
> Is any musl-using distribution supporting it with systemd?
>
> After a cursory look around it doesn't seem that trying to support the
> weird combination of systemd and musl brings compatibility with anyone
> else.
>
> > apps want to run uniformly on both OE and non-OE systems
>
> This implies using glibc, which is the correct choice in most cases.
>
> cu
> Adrian
>
> --
>
>"Is there not promise of rain?" Ling Tan asked suddenly out
> of the darkness. There had been need of rain for many days.
>"Only a promise," Lao Er said.
>Pearl S. Buck - Dragon Seed
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v4] python*-setuptools: add separate packages for pkg_resources module

[Khem Raj]

On Wed, May 22, 2019 at 3:58 AM Luca Boccassi  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

> 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] make-mod-scripts: Add nostamp flag on configure task

[Richard Purdie]

On Fri, 2019-05-24 at 13:49 +0800, Haiqing Bai wrote:
> Error appears while building out of tree kernel module
> after recompiling the kernel:
> bitbake -c cleanall/cleansstate virtual/kernel
> bitbake -c cleanall/cleansstate hello-mod
> bitbake virtual/kernel
> bitbake hello-mod
> 
> ERROR: Kernel configuration is invalid.
>include/generated/autoconf.h or include/config/auto.conf are
> missing.
>Run 'make oldconfig && make prepare' on kernel src to fix it.
> error: 'struct pt_regs' has no member named 'ds'; did you mean 'dx'?
> 
> make-mod-scripts must be forced to rebuild in this case to generate
> config data in 'kernel-build-artifacts/include/config'
> 
> Signed-off-by: Haiqing Bai 
> ---
>  meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/meta/recipes-kernel/make-mod-scripts/make-mod-
> scripts_1.0.bb b/meta/recipes-kernel/make-mod-scripts/make-mod-
> scripts_1.0.bb
> index 97c58c5233..f55104070d 100644
> --- a/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb
> +++ b/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb
> @@ -12,6 +12,8 @@ S = "${WORKDIR}"
>  do_configure[depends] += "virtual/kernel:do_shared_workdir openssl-
> native:do_populate_sysroot"
>  do_compile[depends] += "virtual/kernel:do_compile_kernelmodules"
>  
> +do_configure[nostamp] = "1"
> +
>  DEPENDS += "bc-native"
>  
>  EXTRA_OEMAKE = " HOSTCC="${BUILD_CC} ${BUILD_CFLAGS}
> ${BUILD_LDFLAGS}" HOSTCPP="${BUILD_CPP}""

This sounds like a really bad idea and will make anything depending on
it rebuild in every build.

We need to ensure that these clean commands are not cleaning things out
of the shared kernel directory that they don't own.

Cheers,

Richard

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Should systemd be marked as incompatible with musl?

[Adrian Bunk]

On Fri, May 24, 2019 at 09:13:08AM -0700, Khem Raj wrote:
> 
> 
> On 5/24/19 3:12 AM, Adrian Bunk wrote:
> > On Thu, May 23, 2019 at 07:16:53PM -0700, Khem Raj wrote:
> > > ...
> > > but I think dropping
> > > systemd support completely from musl is not an option I would like to go
> > > with, there are cases where this makes sense. Especially when you have to
> > > cater to different set of devices from small to big, userspace remaining
> > > same is big advantage atleast in the world I am in.
> > > ...
> > 
> > That's a good point - when arguing against systemd as default init system.
> > 
> > systemd is bigger than glibc, therefore on very small systems where the
> > size of the C library matters using systemd is usually not an option.
> 
> Yes, design-wise I concur, in practice, desktop distros rule the linux world
> and systemd is quite prevalent there,

Desktop distros don't use musl - it wouldn't make sense.

> so sometimes you have to wear the
> shoes of same color, atleast thats what I see.

Is any musl-using distribution supporting it with systemd?

After a cursory look around it doesn't seem that trying to support the 
weird combination of systemd and musl brings compatibility with anyone 
else.

> apps want to run uniformly on both OE and non-OE systems

This implies using glibc, which is the correct choice in most cases.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH V2] alsa-utils: fix multilib names

[Richard Purdie]

On Fri, 2019-05-24 at 15:19 +0200, Ming Liu wrote:
> Wouldn't that break the alsa-utils-scripts? Since ALSA_UTILS_PKGS is
> being depended by both alsa-utils and alsa-utils-scripts.
> 
> I did that in V1, but as Richard Purdie pointed out, it will break
> the alsa-utils-scripts build.

I was about to say we should refactor these recipes and create a common
inc file.

Looking at the justification in alsa-utils (avoid a bash dependency),
that is a runtime issue, not a build time one. We should merge these
recipes and ensure the packaging remains the same.

We can then avoid some of these problems, use PN and have a simpler
recipe. These changes should be done in multiple commits, one per
change as usual.

Is there any reason I'm missing not to do this?

Cheers,

Richard

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] qemu: Backport the arm segfault fix

[Alistair Francis]

When we updated to QEMU 4.0 we saw a segfault when running tests on the
qemuarm machine. At the time we just reverted the offending patch from
QEMU. Now that the fix has been merged into upstream let's remove that
revert patch and replace it with the correct backport.

Signed-off-by: Alistair Francis 
---
 meta/recipes-devtools/qemu/qemu.inc   |   2 +-
 ...m-Use-vector-operations-for-saturati.patch | 493 --
 ...et-arm-Fix-vector-operation-segfault.patch |  66 +++
 3 files changed, 67 insertions(+), 494 deletions(-)
 delete mode 100644 
meta/recipes-devtools/qemu/qemu/0013-Revert-target-arm-Use-vector-operations-for-saturati.patch
 create mode 100644 
meta/recipes-devtools/qemu/qemu/0013-target-arm-Fix-vector-operation-segfault.patch

diff --git a/meta/recipes-devtools/qemu/qemu.inc 
b/meta/recipes-devtools/qemu/qemu.inc
index f7b41412ad..e44e351129 100644
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtools/qemu/qemu.inc
@@ -20,7 +20,7 @@ SRC_URI = "https://download.qemu.org/${BPN}-${PV}.tar.xz \
file://0008-apic-fixup-fallthrough-to-PIC.patch \

file://0009-linux-user-Fix-webkitgtk-hangs-on-32-bit-x86-target.patch \

file://0010-Revert-linux-user-fix-mmap-munmap-mprotect-mremap-sh.patch \
-   
file://0013-Revert-target-arm-Use-vector-operations-for-saturati.patch \
+   file://0013-target-arm-Fix-vector-operation-segfault.patch \
"
 UPSTREAM_CHECK_REGEX = "qemu-(?P\d+(\.\d+)+)\.tar"
 
diff --git 
a/meta/recipes-devtools/qemu/qemu/0013-Revert-target-arm-Use-vector-operations-for-saturati.patch
 
b/meta/recipes-devtools/qemu/qemu/0013-Revert-target-arm-Use-vector-operations-for-saturati.patch
deleted file mode 100644
index 3d018a74d9..00
--- 
a/meta/recipes-devtools/qemu/qemu/0013-Revert-target-arm-Use-vector-operations-for-saturati.patch
+++ /dev/null
@@ -1,493 +0,0 @@
-From b46cdcdeb762c1f0eef68dc4a7d90f8176152e07 Mon Sep 17 00:00:00 2001
-From: Alistair Francis 
-Date: Wed, 1 May 2019 19:51:27 -0700
-Subject: [PATCH] Revert "target/arm: Use vector operations for saturation"
-
-This reverts commit 89e68b575e138d0af1435f11a8ffcd8779c237bd.
-
-This fixes QEMU aborts when running the qemuarm machine.
-
-Signed-off-by: Alistair Francis 
-Upstream-Status: Pending

- target/arm/helper.h|  33 ---
- target/arm/translate-a64.c |  36 
- target/arm/translate.c | 172 ++---
- target/arm/translate.h |   4 -
- target/arm/vec_helper.c| 130 
- 5 files changed, 44 insertions(+), 331 deletions(-)
-
-diff --git a/target/arm/helper.h b/target/arm/helper.h
-index 50cb036378..b2669f140f 100644
 a/target/arm/helper.h
-+++ b/target/arm/helper.h
-@@ -646,39 +646,6 @@ DEF_HELPER_FLAGS_6(gvec_fmla_idx_s, TCG_CALL_NO_RWG,
- DEF_HELPER_FLAGS_6(gvec_fmla_idx_d, TCG_CALL_NO_RWG,
-void, ptr, ptr, ptr, ptr, ptr, i32)
- 
--DEF_HELPER_FLAGS_5(gvec_uqadd_b, TCG_CALL_NO_RWG,
--   void, ptr, ptr, ptr, ptr, i32)
--DEF_HELPER_FLAGS_5(gvec_uqadd_h, TCG_CALL_NO_RWG,
--   void, ptr, ptr, ptr, ptr, i32)
--DEF_HELPER_FLAGS_5(gvec_uqadd_s, TCG_CALL_NO_RWG,
--   void, ptr, ptr, ptr, ptr, i32)
--DEF_HELPER_FLAGS_5(gvec_uqadd_d, TCG_CALL_NO_RWG,
--   void, ptr, ptr, ptr, ptr, i32)
--DEF_HELPER_FLAGS_5(gvec_sqadd_b, TCG_CALL_NO_RWG,
--   void, ptr, ptr, ptr, ptr, i32)
--DEF_HELPER_FLAGS_5(gvec_sqadd_h, TCG_CALL_NO_RWG,
--   void, ptr, ptr, ptr, ptr, i32)
--DEF_HELPER_FLAGS_5(gvec_sqadd_s, TCG_CALL_NO_RWG,
--   void, ptr, ptr, ptr, ptr, i32)
--DEF_HELPER_FLAGS_5(gvec_sqadd_d, TCG_CALL_NO_RWG,
--   void, ptr, ptr, ptr, ptr, i32)
--DEF_HELPER_FLAGS_5(gvec_uqsub_b, TCG_CALL_NO_RWG,
--   void, ptr, ptr, ptr, ptr, i32)
--DEF_HELPER_FLAGS_5(gvec_uqsub_h, TCG_CALL_NO_RWG,
--   void, ptr, ptr, ptr, ptr, i32)
--DEF_HELPER_FLAGS_5(gvec_uqsub_s, TCG_CALL_NO_RWG,
--   void, ptr, ptr, ptr, ptr, i32)
--DEF_HELPER_FLAGS_5(gvec_uqsub_d, TCG_CALL_NO_RWG,
--   void, ptr, ptr, ptr, ptr, i32)
--DEF_HELPER_FLAGS_5(gvec_sqsub_b, TCG_CALL_NO_RWG,
--   void, ptr, ptr, ptr, ptr, i32)
--DEF_HELPER_FLAGS_5(gvec_sqsub_h, TCG_CALL_NO_RWG,
--   void, ptr, ptr, ptr, ptr, i32)
--DEF_HELPER_FLAGS_5(gvec_sqsub_s, TCG_CALL_NO_RWG,
--   void, ptr, ptr, ptr, ptr, i32)
--DEF_HELPER_FLAGS_5(gvec_sqsub_d, TCG_CALL_NO_RWG,
--   void, ptr, ptr, ptr, ptr, i32)
--
- DEF_HELPER_FLAGS_5(gvec_fmlal_a32, TCG_CALL_NO_RWG,
-void, ptr, ptr, ptr, ptr, i32)
- DEF_HELPER_FLAGS_5(gvec_fmlal_a64, TCG_CALL_NO_RWG,
-diff --git a/target/arm/translate-a64.c b/target/arm/translate-a64.c
-index 9dcc5ff3a3..428211f92f 100644
 a/target/arm/translate-a64.c
-+++ b/target/arm/translate-a64.c
-@@ -11230,22 +11230,6 @@ 

Re: [OE-core] [PATCH] nginx: fix kill path in nginx systemd unit file

[akuster808]

On 5/24/19 7:36 AM, Nicola Lunghi wrote:
> Signed-off-by: Nicola Lunghi 
> ---
>  meta-webserver/recipes-httpd/nginx/files/nginx.service | 2 +-
>  meta-webserver/recipes-httpd/nginx/nginx.inc   | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)

Wrong mailing list.

please send to openembedded-de...@lists.openembedded.org

>
> diff --git a/meta-webserver/recipes-httpd/nginx/files/nginx.service 
> b/meta-webserver/recipes-httpd/nginx/files/nginx.service
> index c6fc0495f..9a6ca9651 100644
> --- a/meta-webserver/recipes-httpd/nginx/files/nginx.service
> +++ b/meta-webserver/recipes-httpd/nginx/files/nginx.service
> @@ -8,7 +8,7 @@ PIDFile=/run/nginx/nginx.pid
>  ExecStartPre=@SBINDIR@/nginx -t
>  ExecStart=@SBINDIR@/nginx
>  ExecReload=@SBINDIR@/nginx -s reload
> -ExecStop=@BINDIR@/kill -s QUIT $MAINPID
> +ExecStop=@BASE_BINDIR@/kill -s QUIT $MAINPID
>  PrivateTmp=true
>  
>  [Install]
> diff --git a/meta-webserver/recipes-httpd/nginx/nginx.inc 
> b/meta-webserver/recipes-httpd/nginx/nginx.inc
> index 29e7efc14..c4c776e37 100644
> --- a/meta-webserver/recipes-httpd/nginx/nginx.inc
> +++ b/meta-webserver/recipes-httpd/nginx/nginx.inc
> @@ -134,7 +134,7 @@ do_install () {
>  sed -i -e 's,@SYSCONFDIR@,${sysconfdir},g' \
>  -e 's,@LOCALSTATEDIR@,${localstatedir},g' \
>  -e 's,@SBINDIR@,${sbindir},g' \
> --e 's,@BINDIR@,${bindir},g' \
> +-e 's,@BASE_BINDIR@,${base_bindir},g' \
>  ${D}${systemd_unitdir}/system/nginx.service
>  fi
>  }

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [oe][meta-webserver][PATCH 1/2] nginx: update to version 1.17.0

[Randy MacLeod]

Nicola,

Please re-send to:
   openembedded-de...@lists.openembedded.org
rather than:
   openembedded-core@lists.openembedded.org

Did you read:
 https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded
If so maybe we need to improve the howto.

Thanks.
../Randy

On 5/24/19 10:44 AM, Nicola Lunghi wrote:

Signed-off-by: Nicola Lunghi 
---
  meta-webserver/recipes-httpd/nginx/nginx_1.15.7.bb | 6 --
  meta-webserver/recipes-httpd/nginx/nginx_1.17.0.bb | 6 ++
  2 files changed, 6 insertions(+), 6 deletions(-)
  delete mode 100644 meta-webserver/recipes-httpd/nginx/nginx_1.15.7.bb
  create mode 100644 meta-webserver/recipes-httpd/nginx/nginx_1.17.0.bb

diff --git a/meta-webserver/recipes-httpd/nginx/nginx_1.15.7.bb 
b/meta-webserver/recipes-httpd/nginx/nginx_1.15.7.bb
deleted file mode 100644
index 5e6dc33e9..0
--- a/meta-webserver/recipes-httpd/nginx/nginx_1.15.7.bb
+++ /dev/null
@@ -1,6 +0,0 @@
-require nginx.inc
-
-LIC_FILES_CHKSUM = "file://LICENSE;md5=3691402cc54ce09f800ca348634a2dfe"
-
-SRC_URI[md5sum] = "719b2e3d416f111fecc9db6625553658"
-SRC_URI[sha256sum] = 
"8f22ea2f6c0e0a221b6ddc02b6428a3ff708e2ad55f9361102b1c9f4142bdf93"
diff --git a/meta-webserver/recipes-httpd/nginx/nginx_1.17.0.bb 
b/meta-webserver/recipes-httpd/nginx/nginx_1.17.0.bb
new file mode 100644
index 0..8774a87ff
--- /dev/null
+++ b/meta-webserver/recipes-httpd/nginx/nginx_1.17.0.bb
@@ -0,0 +1,6 @@
+require nginx.inc
+
+LIC_FILES_CHKSUM = "file://LICENSE;md5=52e384aaac868b755b93ad5535e2d075"
+
+SRC_URI[md5sum] = "56767fd62302508295b31adc48b99a59"
+SRC_URI[sha256sum] = 
"e21b5d06cd53e86afb94f0b3678e0abb0c0f011433471fa3d895cefa65ae0fab"




--
# Randy MacLeod
# Wind River Linux
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Should systemd be marked as incompatible with musl?

[Khem Raj]

On 5/24/19 3:12 AM, Adrian Bunk wrote:

On Thu, May 23, 2019 at 07:16:53PM -0700, Khem Raj wrote:

...
but I think dropping
systemd support completely from musl is not an option I would like to go
with, there are cases where this makes sense. Especially when you have to
cater to different set of devices from small to big, userspace remaining
same is big advantage atleast in the world I am in.
...


That's a good point - when arguing against systemd as default init system.

systemd is bigger than glibc, therefore on very small systems where the
size of the C library matters using systemd is usually not an option.



Yes, design-wise I concur, in practice, desktop distros rule the linux 
world and systemd is quite prevalent there, so sometimes you have to 
wear the shoes of same color, atleast thats what I see. apps want to run 
uniformly on both OE and non-OE systems



cu
Adrian


--
___
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

[luca . boccassi]

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

[OE-core] [oe][meta-webserver][PATCH 1/2] nginx: update to version 1.17.0

[Nicola Lunghi]

Signed-off-by: Nicola Lunghi 
---
 meta-webserver/recipes-httpd/nginx/nginx_1.15.7.bb | 6 --
 meta-webserver/recipes-httpd/nginx/nginx_1.17.0.bb | 6 ++
 2 files changed, 6 insertions(+), 6 deletions(-)
 delete mode 100644 meta-webserver/recipes-httpd/nginx/nginx_1.15.7.bb
 create mode 100644 meta-webserver/recipes-httpd/nginx/nginx_1.17.0.bb

diff --git a/meta-webserver/recipes-httpd/nginx/nginx_1.15.7.bb 
b/meta-webserver/recipes-httpd/nginx/nginx_1.15.7.bb
deleted file mode 100644
index 5e6dc33e9..0
--- a/meta-webserver/recipes-httpd/nginx/nginx_1.15.7.bb
+++ /dev/null
@@ -1,6 +0,0 @@
-require nginx.inc
-
-LIC_FILES_CHKSUM = "file://LICENSE;md5=3691402cc54ce09f800ca348634a2dfe"
-
-SRC_URI[md5sum] = "719b2e3d416f111fecc9db6625553658"
-SRC_URI[sha256sum] = 
"8f22ea2f6c0e0a221b6ddc02b6428a3ff708e2ad55f9361102b1c9f4142bdf93"
diff --git a/meta-webserver/recipes-httpd/nginx/nginx_1.17.0.bb 
b/meta-webserver/recipes-httpd/nginx/nginx_1.17.0.bb
new file mode 100644
index 0..8774a87ff
--- /dev/null
+++ b/meta-webserver/recipes-httpd/nginx/nginx_1.17.0.bb
@@ -0,0 +1,6 @@
+require nginx.inc
+
+LIC_FILES_CHKSUM = "file://LICENSE;md5=52e384aaac868b755b93ad5535e2d075"
+
+SRC_URI[md5sum] = "56767fd62302508295b31adc48b99a59"
+SRC_URI[sha256sum] = 
"e21b5d06cd53e86afb94f0b3678e0abb0c0f011433471fa3d895cefa65ae0fab"
-- 
2.20.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [oe][meta-webserver][PATCH 2/2] nginx: update stable version to 1.16.0

[Nicola Lunghi]

Signed-off-by: Nicola Lunghi 
---
 meta-webserver/recipes-httpd/nginx/nginx_1.14.2.bb | 10 --
 meta-webserver/recipes-httpd/nginx/nginx_1.16.0.bb | 10 ++
 2 files changed, 10 insertions(+), 10 deletions(-)
 delete mode 100644 meta-webserver/recipes-httpd/nginx/nginx_1.14.2.bb
 create mode 100644 meta-webserver/recipes-httpd/nginx/nginx_1.16.0.bb

diff --git a/meta-webserver/recipes-httpd/nginx/nginx_1.14.2.bb 
b/meta-webserver/recipes-httpd/nginx/nginx_1.14.2.bb
deleted file mode 100644
index d0613ffeb..0
--- a/meta-webserver/recipes-httpd/nginx/nginx_1.14.2.bb
+++ /dev/null
@@ -1,10 +0,0 @@
-require nginx.inc
-
-# 1.14.x branch is the current stable branch, the recommended default
-# 1.15.x is the current mainline branches containing all new features
-DEFAULT_PREFERENCE = "-1"
-
-LIC_FILES_CHKSUM = "file://LICENSE;md5=3691402cc54ce09f800ca348634a2dfe"
-
-SRC_URI[md5sum] = "239b829a13cea1d244c1044e830bd9c2"
-SRC_URI[sha256sum] = 
"002d9f6154e331886a2dd4e6065863c9c1cf8291ae97a1255308572c02be9797"
diff --git a/meta-webserver/recipes-httpd/nginx/nginx_1.16.0.bb 
b/meta-webserver/recipes-httpd/nginx/nginx_1.16.0.bb
new file mode 100644
index 0..cad0db6fc
--- /dev/null
+++ b/meta-webserver/recipes-httpd/nginx/nginx_1.16.0.bb
@@ -0,0 +1,10 @@
+require nginx.inc
+
+# 1.16.x branch is the current stable branch, the recommended default
+# 1.17.x is the current mainline branches containing all new features
+DEFAULT_PREFERENCE = "-1"
+
+LIC_FILES_CHKSUM = "file://LICENSE;md5=52e384aaac868b755b93ad5535e2d075"
+
+SRC_URI[md5sum] = "97207283f30cd90cdba638c3ea30323a"
+SRC_URI[sha256sum] = 
"4fd376bad78797e7f18094a00f0f1088259326436b537eb5af69b01be2ca1345"
-- 
2.20.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] pinentry: Switch pinentry-qt from Qt4 to Qt5

[Adrian Bunk]

Signed-off-by: Adrian Bunk 
---
 meta/recipes-support/pinentry/pinentry_1.1.0.bb | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/meta/recipes-support/pinentry/pinentry_1.1.0.bb 
b/meta/recipes-support/pinentry/pinentry_1.1.0.bb
index 4116efc76f..fb529d25d6 100644
--- a/meta/recipes-support/pinentry/pinentry_1.1.0.bb
+++ b/meta/recipes-support/pinentry/pinentry_1.1.0.bb
@@ -25,7 +25,7 @@ PACKAGECONFIG ??= "ncurses libcap"
 
 PACKAGECONFIG[ncurses] = "--enable-ncurses  
--with-ncurses-include-dir=${STAGING_INCDIR}, --disable-ncurses, ncurses"
 PACKAGECONFIG[libcap] = "--with-libcap, --without-libcap, libcap"
-PACKAGECONFIG[qt] = "--enable-pinentry-qt, --disable-pinentry-qt, qt4-x11"
+PACKAGECONFIG[qt] = "--enable-pinentry-qt, --disable-pinentry-qt, 
qtbase-native qtbase"
 PACKAGECONFIG[gtk2] = "--enable-pinentry-gtk2, --disable-pinentry-gtk2, gtk+ 
glib-2.0"
 
 #To use libsecret, add meta-gnome
@@ -33,7 +33,6 @@ PACKAGECONFIG[secret] = "--enable-libsecret, 
--disable-libsecret, libsecret"
 
 EXTRA_OECONF = " \
 --disable-rpath \
---disable-pinentry-qt5 \
 "
 
 BBCLASSEXTEND = "native"
-- 
2.17.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [oe][meta-webserver][PATCH] nginx: fix kill path in nginx systemd unit file

[Nicola Lunghi]

Signed-off-by: Nicola Lunghi 
---
 meta-webserver/recipes-httpd/nginx/files/nginx.service | 2 +-
 meta-webserver/recipes-httpd/nginx/nginx.inc   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta-webserver/recipes-httpd/nginx/files/nginx.service 
b/meta-webserver/recipes-httpd/nginx/files/nginx.service
index c6fc0495f..9a6ca9651 100644
--- a/meta-webserver/recipes-httpd/nginx/files/nginx.service
+++ b/meta-webserver/recipes-httpd/nginx/files/nginx.service
@@ -8,7 +8,7 @@ PIDFile=/run/nginx/nginx.pid
 ExecStartPre=@SBINDIR@/nginx -t
 ExecStart=@SBINDIR@/nginx
 ExecReload=@SBINDIR@/nginx -s reload
-ExecStop=@BINDIR@/kill -s QUIT $MAINPID
+ExecStop=@BASE_BINDIR@/kill -s QUIT $MAINPID
 PrivateTmp=true
 
 [Install]
diff --git a/meta-webserver/recipes-httpd/nginx/nginx.inc 
b/meta-webserver/recipes-httpd/nginx/nginx.inc
index 29e7efc14..c4c776e37 100644
--- a/meta-webserver/recipes-httpd/nginx/nginx.inc
+++ b/meta-webserver/recipes-httpd/nginx/nginx.inc
@@ -134,7 +134,7 @@ do_install () {
 sed -i -e 's,@SYSCONFDIR@,${sysconfdir},g' \
 -e 's,@LOCALSTATEDIR@,${localstatedir},g' \
 -e 's,@SBINDIR@,${sbindir},g' \
--e 's,@BINDIR@,${bindir},g' \
+-e 's,@BASE_BINDIR@,${base_bindir},g' \
 ${D}${systemd_unitdir}/system/nginx.service
 fi
 }
-- 
2.20.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] nginx: fix kill path in nginx systemd unit file

[Nicola Lunghi]

Signed-off-by: Nicola Lunghi 
---
 meta-webserver/recipes-httpd/nginx/files/nginx.service | 2 +-
 meta-webserver/recipes-httpd/nginx/nginx.inc   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta-webserver/recipes-httpd/nginx/files/nginx.service 
b/meta-webserver/recipes-httpd/nginx/files/nginx.service
index c6fc0495f..9a6ca9651 100644
--- a/meta-webserver/recipes-httpd/nginx/files/nginx.service
+++ b/meta-webserver/recipes-httpd/nginx/files/nginx.service
@@ -8,7 +8,7 @@ PIDFile=/run/nginx/nginx.pid
 ExecStartPre=@SBINDIR@/nginx -t
 ExecStart=@SBINDIR@/nginx
 ExecReload=@SBINDIR@/nginx -s reload
-ExecStop=@BINDIR@/kill -s QUIT $MAINPID
+ExecStop=@BASE_BINDIR@/kill -s QUIT $MAINPID
 PrivateTmp=true
 
 [Install]
diff --git a/meta-webserver/recipes-httpd/nginx/nginx.inc 
b/meta-webserver/recipes-httpd/nginx/nginx.inc
index 29e7efc14..c4c776e37 100644
--- a/meta-webserver/recipes-httpd/nginx/nginx.inc
+++ b/meta-webserver/recipes-httpd/nginx/nginx.inc
@@ -134,7 +134,7 @@ do_install () {
 sed -i -e 's,@SYSCONFDIR@,${sysconfdir},g' \
 -e 's,@LOCALSTATEDIR@,${localstatedir},g' \
 -e 's,@SBINDIR@,${sbindir},g' \
--e 's,@BINDIR@,${bindir},g' \
+-e 's,@BASE_BINDIR@,${base_bindir},g' \
 ${D}${systemd_unitdir}/system/nginx.service
 fi
 }
-- 
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] alsa-utils: fix multilib names

[Ming Liu]

Wouldn't that break the alsa-utils-scripts? Since ALSA_UTILS_PKGS is being
depended by both alsa-utils and alsa-utils-scripts.

I did that in V1, but as Richard Purdie pointed out, it will break the
alsa-utils-scripts build.

//Ming Liu

Burton, Ross  於 2019年5月24日 週五 下午2:42寫道：

> On Fri, 24 May 2019 at 07:38,  wrote:
> > -SUMMARY_alsa-utils-alsabat  = "Command-line sound tester for ALSA
> sound card driver"
> > +SUMMARY_${MLPREFIX}alsa-utils-alsabat  = "Command-line sound tester
> for ALSA sound card driver"
>
> Why not replace alsa-utils-alsabat with ${PN}-alsabat?
>
> Ross
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH V2] alsa-utils: fix multilib names

[Burton, Ross]

On Fri, 24 May 2019 at 07:38,  wrote:
> -SUMMARY_alsa-utils-alsabat  = "Command-line sound tester for ALSA sound 
> card driver"
> +SUMMARY_${MLPREFIX}alsa-utils-alsabat  = "Command-line sound tester for 
> ALSA sound card driver"

Why not replace alsa-utils-alsabat with ${PN}-alsabat?

Ross
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Switching GStreamer recipes from autotools to meson

[Carlos Rafael Giani]

Yes, I am preparing recipes for that, based on the work from Philippe 
Normand .


On 20.05.19 19:49, Khem Raj wrote:



On 5/14/19 1:19 AM, Carlos Rafael Giani wrote:

 From what I have seen, meson support is stable now.

Also, in GStreamer, autotools is now considered a legacy build 
system, and will be removed in future released. From 
https://gstreamer.freedesktop.org/releases/1.16/ :


 > The Meson build system build is now feature-complete (*) and it is 
now the recommended build system on all platforms and also used by 
Cerbero to build GStreamer on all platforms. The Autotools build is 
scheduled to be removed in the next cycle. Developers who currently 
use gst-uninstalled should move to gst-build. The build option naming 
has been cleaned up and made consistent and there are now feature 
options to enable/disable plugins and various other features on a 
case-by-case basis. (*) with the exception of plugin docs which will 
be handled differently in future


GStreamer recipe upgrades to 1.16.0 have been sent in as a pull 
request to meta-gstreamer1.0 . Once these are in, I'm considering to 
switch the recipes to meson. Are there any potential issues with 
that? For example, anything special about meson and GObject 
introspection I should know about?




are you doing the 1.16 upgrade to OE-Core as well ?

--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Should systemd be marked as incompatible with musl?

[Adrian Bunk]

On Thu, May 23, 2019 at 07:16:53PM -0700, Khem Raj wrote:
>...
> but I think dropping
> systemd support completely from musl is not an option I would like to go
> with, there are cases where this makes sense. Especially when you have to
> cater to different set of devices from small to big, userspace remaining
> same is big advantage atleast in the world I am in.
>...

That's a good point - when arguing against systemd as default init system.

systemd is bigger than glibc, therefore on very small systems where the 
size of the C library matters using systemd is usually not an option.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH V2] alsa-utils: fix multilib names

[liu . ming50]

From: Ming Liu 

Append ${MLPREFIX} to the 'alsa-utils' names, or else it would fail
with multilib build.

Signed-off-by: Ming Liu 
---
 meta/recipes-multimedia/alsa/alsa-utils_1.1.9.bb | 66 
 1 file changed, 33 insertions(+), 33 deletions(-)

diff --git a/meta/recipes-multimedia/alsa/alsa-utils_1.1.9.bb 
b/meta/recipes-multimedia/alsa/alsa-utils_1.1.9.bb
index 03b5c8d..5976914 100644
--- a/meta/recipes-multimedia/alsa/alsa-utils_1.1.9.bb
+++ b/meta/recipes-multimedia/alsa/alsa-utils_1.1.9.bb
@@ -56,39 +56,39 @@ PACKAGES += "${ALSA_UTILS_PKGS}"
 RDEPENDS_${PN} += "${ALSA_UTILS_PKGS}"
 
 FILES_${PN} = ""
-FILES_alsa-utils-alsabat = "${bindir}/alsabat"
-FILES_alsa-utils-alsatplg= "${bindir}/alsatplg"
-FILES_alsa-utils-aplay   = "${bindir}/aplay ${bindir}/arecord 
${bindir}/axfer"
-FILES_alsa-utils-amixer  = "${bindir}/amixer"
-FILES_alsa-utils-alsamixer   = "${bindir}/alsamixer"
-FILES_alsa-utils-speakertest = "${bindir}/speaker-test ${datadir}/sounds/alsa/ 
${datadir}/alsa/speaker-test/"
-FILES_alsa-utils-midi= "${bindir}/aplaymidi ${bindir}/arecordmidi 
${bindir}/amidi"
-FILES_alsa-utils-aconnect= "${bindir}/aconnect"
-FILES_alsa-utils-aseqnet = "${bindir}/aseqnet"
-FILES_alsa-utils-iecset  = "${bindir}/iecset"
-FILES_alsa-utils-alsactl = "${sbindir}/alsactl 
*/udev/rules.d/90-alsa-restore.rules */*/udev/rules.d/90-alsa-restore.rules 
${systemd_unitdir} ${localstatedir}/lib/alsa ${datadir}/alsa/init/"
-FILES_alsa-utils-aseqdump= "${bindir}/aseqdump"
-FILES_alsa-utils-alsaloop= "${bindir}/alsaloop"
-FILES_alsa-utils-alsaucm = "${bindir}/alsaucm 
*/udev/rules.d/89-alsa-ucm.rules */*/udev/rules.d/89-alsa-ucm.rules"
-
-SUMMARY_alsa-utils-alsabat  = "Command-line sound tester for ALSA sound 
card driver"
-SUMMARY_alsa-utils-alsatplg = "Converts topology text files into binary 
format for kernel"
-SUMMARY_alsa-utils-aplay= "Play (and record) sound files using ALSA"
-SUMMARY_alsa-utils-amixer   = "Command-line control for ALSA mixer and 
settings"
-SUMMARY_alsa-utils-alsamixer= "ncurses-based control for ALSA mixer and 
settings"
-SUMMARY_alsa-utils-speakertest  = "ALSA surround speaker test utility"
-SUMMARY_alsa-utils-midi = "Miscellaneous MIDI utilities for ALSA"
-SUMMARY_alsa-utils-aconnect = "ALSA sequencer connection manager"
-SUMMARY_alsa-utils-aseqnet  = "Network client/server for ALSA sequencer"
-SUMMARY_alsa-utils-iecset   = "ALSA utility for setting/showing IEC958 
(S/PDIF) status bits"
-SUMMARY_alsa-utils-alsactl  = "Saves/restores ALSA-settings in 
/etc/asound.state"
-SUMMARY_alsa-utils-aseqdump = "Shows the events received at an ALSA 
sequencer port"
-SUMMARY_alsa-utils-alsaloop = "ALSA PCM loopback utility"
-SUMMARY_alsa-utils-alsaucm  = "ALSA Use Case Manager"
-
-RRECOMMENDS_alsa-utils-alsactl = "alsa-states"
-
-ALLOW_EMPTY_alsa-utils = "1"
+FILES_${MLPREFIX}alsa-utils-alsabat = "${bindir}/alsabat"
+FILES_${MLPREFIX}alsa-utils-alsatplg= "${bindir}/alsatplg"
+FILES_${MLPREFIX}alsa-utils-aplay   = "${bindir}/aplay ${bindir}/arecord 
${bindir}/axfer"
+FILES_${MLPREFIX}alsa-utils-amixer  = "${bindir}/amixer"
+FILES_${MLPREFIX}alsa-utils-alsamixer   = "${bindir}/alsamixer"
+FILES_${MLPREFIX}alsa-utils-speakertest = "${bindir}/speaker-test 
${datadir}/sounds/alsa/ ${datadir}/alsa/speaker-test/"
+FILES_${MLPREFIX}alsa-utils-midi= "${bindir}/aplaymidi 
${bindir}/arecordmidi ${bindir}/amidi"
+FILES_${MLPREFIX}alsa-utils-aconnect= "${bindir}/aconnect"
+FILES_${MLPREFIX}alsa-utils-aseqnet = "${bindir}/aseqnet"
+FILES_${MLPREFIX}alsa-utils-iecset  = "${bindir}/iecset"
+FILES_${MLPREFIX}alsa-utils-alsactl = "${sbindir}/alsactl 
*/udev/rules.d/90-alsa-restore.rules */*/udev/rules.d/90-alsa-restore.rules 
${systemd_unitdir} ${localstatedir}/lib/alsa ${datadir}/alsa/init/"
+FILES_${MLPREFIX}alsa-utils-aseqdump= "${bindir}/aseqdump"
+FILES_${MLPREFIX}alsa-utils-alsaloop= "${bindir}/alsaloop"
+FILES_${MLPREFIX}alsa-utils-alsaucm = "${bindir}/alsaucm 
*/udev/rules.d/89-alsa-ucm.rules */*/udev/rules.d/89-alsa-ucm.rules"
+
+SUMMARY_${MLPREFIX}alsa-utils-alsabat  = "Command-line sound tester for 
ALSA sound card driver"
+SUMMARY_${MLPREFIX}alsa-utils-alsatplg = "Converts topology text files 
into binary format for kernel"
+SUMMARY_${MLPREFIX}alsa-utils-aplay= "Play (and record) sound files 
using ALSA"
+SUMMARY_${MLPREFIX}alsa-utils-amixer   = "Command-line control for ALSA 
mixer and settings"
+SUMMARY_${MLPREFIX}alsa-utils-alsamixer= "ncurses-based control for ALSA 
mixer and settings"
+SUMMARY_${MLPREFIX}alsa-utils-speakertest  = "ALSA surround speaker test 
utility"
+SUMMARY_${MLPREFIX}alsa-utils-midi = "Miscellaneous MIDI utilities for 
ALSA"
+SUMMARY_${MLPREFIX}alsa-utils-aconnect = "ALSA sequencer connection 
manager"
+SUMMARY_${MLPREFIX}alsa-utils-aseqnet  = "Network client/server for 

[OE-core] [PATCH] make-mod-scripts: Add nostamp flag on configure task

[Haiqing Bai]

Error appears while building out of tree kernel module
after recompiling the kernel:
bitbake -c cleanall/cleansstate virtual/kernel
bitbake -c cleanall/cleansstate hello-mod
bitbake virtual/kernel
bitbake hello-mod

ERROR: Kernel configuration is invalid.
   include/generated/autoconf.h or include/config/auto.conf are missing.
   Run 'make oldconfig && make prepare' on kernel src to fix it.
error: 'struct pt_regs' has no member named 'ds'; did you mean 'dx'?

make-mod-scripts must be forced to rebuild in this case to generate
config data in 'kernel-build-artifacts/include/config'

Signed-off-by: Haiqing Bai 
---
 meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb 
b/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb
index 97c58c5233..f55104070d 100644
--- a/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb
+++ b/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb
@@ -12,6 +12,8 @@ S = "${WORKDIR}"
 do_configure[depends] += "virtual/kernel:do_shared_workdir 
openssl-native:do_populate_sysroot"
 do_compile[depends] += "virtual/kernel:do_compile_kernelmodules"
 
+do_configure[nostamp] = "1"
+
 DEPENDS += "bc-native"
 
 EXTRA_OEMAKE = " HOSTCC="${BUILD_CC} ${BUILD_CFLAGS} ${BUILD_LDFLAGS}" 
HOSTCPP="${BUILD_CPP}""
-- 
2.13.3

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core