elogind Bug Fix Wednesday: glibc, meson, dbus

Spider Bug Huntress

Yesterday has been “elogind Bug Fix Wednesday” for me, fixing issues on elogind. Originally I planned to work on my front page and my “About Me” page, but these issues needed attention.

Actually this was quite unexpected. I was sure that there was only one tiny thing to fix, and the new version v239 could rolled out. A version, that I already use on my production system for about three weeks without any problems.

glibc-2.28 and statx

The report that building against glibc-2.28 would result in a “redefinition of ‘struct statx_timestamp’” was reported on 2018-09-21 by perfect7gentleman.
On Tuesday Christoph “cwilling” Willing whipped up a PR that I merged after ensuring that it wouldn’t cause trouble when building against glibc-2.27.
I even back-ported the patch to v238-stable and v236-stable. However, this came back yesterday with an embarrassing result. But more on that later…

meson-0.48 and the ‘debug’ keyword

Also on Tuesday, perfect7gentleman reported, that trying to configure elogind-239.9999 resulted in a new error:
ERROR: Option name debug is reserved.
But I couldn’t find a quick solution, because the systemd developers had not dealt with this problem, yet. I didn’t want to come up with a solution that might have to be changed later to not diverge from upstream code.

But as I found out yesterday, the syetemd developers had already dealt with this in august.
What had happened?
Well, I hate to admit it, but in my haste I forgot to “git pull” after having fetched from systemd/master. Yesterday perfect7gentleman posted the patch that fixed the issue in systemd, and I couldn’t find any reference in my systemd tree.

So, dear people, never forget to pull! 😉

Hard-coded paths and /run symlinks

Yesterday cwilling posted an issue about the “Path to system_bus_socket“.
This is about the hard-coded path “/run/dbus/system_bus_socket” that has been changed to that from “/var/run/dbus/system_bus_socket” in systemd-237. (See commit 15ca0a4.)

While the reasoning, to be independent of a set up /var/run, is sound for systemd, this works against the goal of elogind to be a drop-in replacement for systemd-login on systems that do not support the full systemd suite. On these systems the paths /run and /var/run might be individual mounts. In which case dbus’ system_bus_socket will be present in /var/run/dbus and not in /run/dbus.

To remedy this situation cwilling created a Pull Request to deal with this by adding a detection whether /var/run is a symlink to /run or not.

I gave him instructions on how to decorate his changes so my migration tools would be able to handle systemd commits that worked on the same areas. 
He perfectly applied to these instructions, but noted that the glibc-2.28 handling from the day before might be reviewed.

When perception ends on diff boundaries

I actually did review the glibc-2.28 fix, and made a discovery that left me quite embarrassed. The test we so skillfully added, whether “struct statx” was already defined in either sys/stat.h or linux/stat.h, was already there. But these two headers where commented out, so the test always failed.

The only option for me was to revert our “fix” and to uncomment these includes. (See commit 2e0ffb6)

How did this happen?

Well, my migration tools, namely check_tree.pl, handles newly added includes by first commenting them out. This is, at the end of the day, the easiest method to early detect includes that aren’t needed by elogind.

But what I did not realize is, that this tool also covers meson files, and that includes can get added there, too.

So for future migration rounds, I am warned. 🙂

Final result

I am glad that those issues could be dealt with in an appropriate and swift way. And furthermore I am happy that only one issue is left to deal with before v239 can be finally released!

Thank you very much everybody for your constant help and patience!
And considering how little spare time we all have, this was truly an “elogind Bug Fix Wednesday“.

Leave a Reply

Your email address will not be published. Required fields are marked *