Postings by Lennart Poettering

Can we maybe reduce the set of packages we install by default a bit?


today I installed the current Fedora 30 Workstation beta on my new
laptop. It was a bumpy ride, I must say (the partitioner (blivet?)
crashed five times or so on me, always kicking me out of anaconda
again, just because I wanted to undo something). But I don't really
want to discuss that. What I do want to discuss is this:

Can we maybe reduce the default set of packages a bit? In particular
the following ones I really don't think should be in our default

1. multipathd. On a workstation, uh?? I obviously have no multipath
devices configured on my laptop, how would I even?

RFC: Fixing the "nobody" user?


I'd like to start a discussion regarding the "nobody" user on Fedora,
and propose that we change its definition sooner or later. I am not
proposing a feature according to the feature process for this yet, but
my hope is that these discussions will lead to one eventually.

Most distributions (in particular Debian/Ubuntu-based ones) map the
user "nobody" to UID 65534. I think we should change Fedora to do the
same. Background:

On Linux two UIDs are special: that's UID 0 for root, which is the
privileged user we all know. And then there's UID 65534

Please test kdbus in Rawhide!


I'd like to ask everybody to test kdbus on Rawhide. Josh thankfully
added it to the Rawhide kernel packages, and our systemd RPMs come
with built-in support, too now. If you are running an up-to-date
Rawhide system adding "kdbus=1" to your kernel command line is hence
everything you need to run kdbus instead of dbus-daemon. (No
additional RPMs need to be installed.) If you do, things should just
work the same way as before, if we did everything right.

Prefixing system users with an underscore?


Many other distributions and Unixes have adopted (or are at least
discussing) to prefix system users and groups with an underscore to
avoid namespace clashes between vendor supplied and user created

To me this sounds like something we really should adopt in Fedora as
well. At least for new system/group users we should mandate this nameing

Maybe it's time to get rid of tcpwrappers/tcpd?


I wonder whether it wouldn't be time to say goodbye to tcpwrappers in
Fedora. There has been a request in systemd upstream to disable support
for it by default, but I am not sure I want to do that unless we can
maybe say goodbye to it for the big picture too.

Why would we get rid of them?

Well, to make things simpler, primarily.


I noticed this:

$ rpm -qf /usr/etc

$ repoquery --whatprovides '/usr/etc/*'

Since when do we have /usr/etc, and what is it for?

Maybe I am the only one but I see very little benefit in introducing a
new Fedoraism like this...


Getting rid of systemd-sysv-convert?


When systemd was first adopted by Fedora a requirement mandated by FESCO
(or was it FPC?) was that the script "systemd-sysv-convert" (which I
wrote) should be added which is supposed to save the old runlevel
configuration of sysv scripts before we replace them with systemd units.

Now we are starting work on F20, I do wonder if we can get rid of this

ConsoleKit and esound retirement


since a while now logind has replaced CK in Fedora. I'd like to retire
it entirely from the distribution now.

Most deps on CK are gone. Holdouts are "cdm", "lightdm", "lxsession", "lxdm".

<a href="" title=""></a>

This page doesn't say anything about retiring packages other still
depend on...

I am tempted to just retire CK ignoring the remaining dependencies, in
the hope this will put the pressure on the folks involved to update
their stuff...

Getting rid of CK in those packages is dead simple BTW.

comps' "standard" group spring cleaning?


I noticed that comps' "standard" group includes a lot of packages that
were all the hotness in 1990s but aren't really that much anymore. For
example, irda-tools, pcmciautils, finger, rsh, rdist, pinfo have
probably had their best times behind them, and probably shouldn't be
installed by default anymore.

I'd like to propose that maybe it is time to remove these from
"standard" for F19. Note sure how to proceed on that. Propose a feature?
File a bug? Is there even a comps "maintainer"?

(Oh, and to clarify this: it's just about what to install by default,
not about what to ship.

Rawhide: /tmp is now on tmpfs


Please be aware that since the most recent systemd uploads /tmp is now
in tmpfs by default in Rawhide/F18.

For details please see this feature page:

<a href="" title=""></a>

If you have an explicit /tmp entry in fstab things should continue to
work the same as before. If you don't then you will now get a tmpfs on
/tmp by default.

This will most likely lead to a problem or two with software that isn't
happy about /tmp being small.

What's this /run directory doing on my system and where does it come from?


I just uploaded a new version of systemd into F15, which establishes a
directory /run in the root directory. Most likely you'll sooner or later
stumble over it, so here's an explanation what this is and why this is.

It's a fairly minor technical change, though presumably people consider
this a bigger political change, so I guess this deserves an

For quite a while programs involved with early boot used to place
runtime data in /dev under numerous hidden dot directories.

Moving /var/run and /var/lock to tmpfs in Rawhide


I hereby want to let everybody know that in the next days I will turn on
/var/run and /var/lock on tmpfs on Rawhide/F15. This is in accordance
with the following accepted F15 feature:

<a href="" title=""></a>

My current tests indicate that we will not run into too much trouble
with this and most things should continue to work just fine. However, of
course I run only a small subset of packages of the fedora archive on my

If you cannot boot after installing systemd v8...


We shifted a few files around and most likely your
/etc/systemd/system/ link will now point into the void, in
case anaconda wrote it.

adding missing systemd links in rawhide upgrades


just a little heads up for when you upgrade a rawhide system that is a
few weeks old to current rawhide: since we changed the way how some of
the default symlinks of systemd are created you will end up with an
installation that lacks many of the necessary symlinks -- but only if
you upgrade from a systemd version from older rawhide to current
rawhide. It's really only a problem in this case. It is not a problem
with fresh F14 installations, and it is not a problem with upgrades from

systemd is now the default init system in rawhide


I have just uploaded a new systemd and a new upstart package which make
systemd the default init system for Rawhide. The scheme I followed makes
sure that in case systemd actually breaks systems there is an easy path
back to upstart. And here's how it works:

- "upstart" and "systemd" are now parallel installable. When you upgrade
rawhide you will get both installed.

The systemd unit files I'll post


I have uploaded preliminary versions of the unit files I put together
for the various services of our default install. I think they give an
indication how simple these files actually are:

<a href="" title=""></a>

Please have a look and if you have any questions just ask!

Expect final versions of these files in rhbz soon.

If you are missing a service file for a particular package, then say
something, as I might be able to cook something up for you.


systemd for F14 - the next steps


as many of you probably know systemd got accepted as feature for F-14 by
FESCO a few weeks back.

<a href="" title=""></a>

And in case you want to read up what systemd actually is, here's the
blog post that introduced it (only slightly out-of-date, we have however
advanced a bit since then):

<a href="" title=""></a>

Since the acceptance by FESCO it has been added to Rawhide together with
patched or updated versions of a few related packages. However, what has
not been done so far is making it the default in Rawhide.

systemd (Was Re: tmpfs for strategic directories)

Well, I am certainly planning to have a package for it in F14. But
whether we can have it as default is to be seen.

ATM everything looks rosy. I just finished porting over all F13
installed-by-default daemons to socket activation, and a few more (and
the patches are good enough to be upstreamable). I'll publish the
numbers of a 100% socket-activated boot soon.

Heads-Up: Beware of xmlCleanupParser() when your package links against libxml2


if you have code that links against libxml2 and calls
xmlCleanupParser() please verify that your project does that at the
appropriate place (i.e. immediately before exiting, and only once).

That function might delete TLS fields that belong to other libraries
(such as PA's client libs) if called twice. To the effect that PA
might look bad.

New Mixer Handling in PA 0.9.16/F12


I'd like to draw your attention to the new mixer handling logic in PA
0.9.16/F12. It includes a number of improvements:

- We now support input and output "ports". i.e. switching between
Mic/Line-In resp. Speaker/Headphones. Only one of those ports can be
active per sink at a time.

- we merge a number of low-level mixer controls into a single

Heads-Up: rtkit


Just a little heads-up: I am about do add a dependency on a new
package "rtkit" to PA, effectively meaning rtkit will be installed by

rtkit is "RealtimeKit", it's a tiny bus activated service that hands
out supervised RT scheduling to clients that ask for it.

If you maintain a desktop application that uses rt, it might or might
not be a good idea to modify it to make use of this.

If you want to know what all this is about and for the reasons for it,
please read the README:

<a href=";a=blob;f=README" title=";a=blob;f=README">;a=blob;f=README</a>

and this announcement on LAD:

<a href="http://linuxaudio.or" title="http://linuxaudio.or">http://linuxaudio.or</a>

Getting rid of /usr for F12?


there's one topic that keeps popping up in various discussions: can't
we get rid of /usr? The seperation of / and /usr doesn't make much
sense anymore. We could make /usr a symlink to / for an interims phase
and everything would be good for conservative folks who think the FHS
is the holy bible.

In the past more and more stuff has been moved from /usr to /. It's
unlikely that it's going to become less.