[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 <martin.jansa at gmail.com> 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 <raj.khem at gmail.com> wrote:
>>
>> On Fri, May 24, 2019 at 10:31 AM Richard Purdie
>> <richard.purdie at linuxfoundation.org> 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 <Qi.Chen at windriver.com>
>> > > ---
>> > >  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 at lists.openembedded.org
>> > http://lists.openembedded.org/mailman/listinfo/openembedded-core
>> --
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core at lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core