[systemd-devel] Support for unmerged-usr systems will be REMOVED in the second half of 2023

[Richard Purdie]

On Tue, 2023-06-13 at 18:54 +0200, Lennart Poettering wrote:
> See the positive side of this. Yocto users who will ask for the newest
> upstream systemd to be added to Yocto will be faced with the fact that
> noone did the necessary groundwork in Yocto, and once the pressure is
> high enough certainly someone will materialize who'll fix it for
> you. And in the meantime you can blame systemd upstream.

I'm sure it will get "resolved" as you say but the people shipping
products containing the old layout are going to be upset with us and
Yocto Project will get blamed. The people who "resolve" it are unlikely
to be people interested in documenting the issue or the migration guide
entries for it. I can try and force that but it is work I could do
without and I'll in turn have people upset with me for having to
document something they aren't interested in.

> It's how this usually works: tell people in advance what you'll do in
> a year, and nobody will arrange for it. But once we from upstream make
> this a reality the pressure mounts and somebody will materialize
> who'll fix this I am sure. In the meantime people are stuck with older
> versions of systemd, which is not a total loss, is it?

It is if we try and file bug reports and get told to use a new version!
We do at least try and stay up to date in general and promptly report
issues with new compilers and so on, which does have its uses to other
projects for example.

> BTW, I try to be helpful to yocto from time to time, but you make it
> very hard to do so. From time to time I look at this:
> 
> https://git.openembedded.org/openembedded-core/tree/meta/recipes-core/systemd/systemd
> 
> And then I try to report issues with this, but I don't know where,
> there's no github or gitlab or anything reasonable to report issues
> with. It's like a website straight out of 2003.

There are two choices, bugzilla[1] or the openembedded-core[2] mailing
list. No, we don't use github or gitlab, there are reasons for that,
not least that the project's structure doesn't work so well in those
models.

[1] https://bugzilla.yoctoproject.org
[2] https://lists.openembedded.org/g/openembedded-core

I've been having some discussions on our website and I'll actually use
this email as evidence of something I've been arguing for a while about
links on the project website menus.

> The only thing I can
> do is write a mail to Khem Raj, but often enough nothing happens. For
> example, I reported some weeks ago that this patch is garbage:
> 
> https://git.openembedded.org/openembedded-core/tree/meta/recipes-core/systemd/systemd/0003-errno-util-Make-STRERROR-portable-for-musl.patch
> 
> it turns a stack buffer into TLS, which means printf("%s %s\n",
> STRERROR(ENOMEM), STRERROR(EINTR)); will not work as people might
> expect but just print the same string. What's worse though is that
> it's actually a memory corruption since it returns a buffer allocated
> via compound initialization (i.e. stack buffer) from a function.

FWIW I'm not happy about the situation with musl and systemd in Yocto
Project, it worries me a lot and I've refused to "endorse" it. I did
insist this was added:

https://git.openembedded.org/openembedded-core/tree/meta/recipes-core/systemd/systemd_253.3.bb#n776

which shows a warning of:

"Using systemd with musl is not recommended since it is not supported
upstream and some patches are known to be problematic."

when musl is attempted with systemd. I'd probably like to go further
and expand problematic to mention potential security issues and now
memory corruption.

> I mean, at some points trying to be nice has ends: if yocto can't find
> the maintainance resources for updating CI, for running good reporting
> infra, or for maintaining systemd there's not that much stuff we can
> do, but it doesn't stll doesn't become our upstream problem then. We
> refuse to be held back by that indefinitely.

The issue is that Yocto Project supports combinations that systemd does
not and people are willing to hack it together but not do the work
properly to make it really work (e.g. musl).

On the current topic, from our perspective it is frustrating to see
combinations which worked being removed as it complicates things for us
and breaks existing products. The blame will end up with Yocto Project
for not solving this and I doubt systemd will see the fallout.

Cheers,

Richard