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