Re: Support for unmerged-usr systems will be REMOVED in the second half of 2023

[Lennart Poettering <lennart@xxxxxxxxxxxxxx>]

On Di, 13.06.23 15:15, Richard Purdie (richard.purdie@xxxxxxxxxxxxxxxxxxx) wrote:

> > > Following this thread started back in April:
> > >
> > > https://lists.freedesktop.org/archives/systemd-devel/2022-April/047673.html
> > >
> > > As far as we understand there are no distributions running or
> > > optionally supporting systemd that have not either completed, or at
> > > least started, the transition to merged-usr systems.
> > >
> > > So, we are planning to drop support for unmerged-usr systems in the
> > > first release that will happen in the second half of next year, I.E.:
> > > any time starting from July 2023 (while we tend to release somewhat
> > > regularly we do not have strict dates and deadlines, so right now it's
> > > not possible to tell the exact version, but it will be of course
> > > communicated once it becomes clear).
> >
> > As previously announced, this is being prepared now and will be part of v254:
> >
> > https://github.com/systemd/systemd/pull/27999
>
> I'd note that nobody did resolve the issues for Yocto Project yet so
> our CI will break if we try and upgrade :(.

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.

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?

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

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.

Lennart

--
Lennart Poettering, Berlin