I'm planning a libsigsegv-2.9 (rawhide) update relatively soon which
includes an abi change. According to repquery, only the following
packages should be affected:
(I'll help take care of these requisite rebuilds)
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:
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
machine. So here's what might happen and which might need fixing over
the next weeks in various packages:
- Not all packages might be able to create their directory in /var/run
on start-up. Since SUSE and Ubuntu have already been shipping systems
with tmpfs on /var/run and /var/lock for quite a while I expect the
number of packages that are incapable of doing this to be very
small. If your software nonetheless fails witht this issue, then
there are two options to fix this: a) patch the program in
question, so that it is able to recreate the directories in
/var/run, or b) ship a simple drop-in file for /etc/tmpfiles.d/ which
recreates these directories on boot. (see below)
- There might be permission problems, since the rpms might have set
different perms on the subdirs of /var/run than the software itself
might apply when starting up. In this case, a drop-in file in
/etc/tmpfiles.d/ might help. (see below)
- The SELinux policy might trigger AVCs and disallow creation of the
dirs in question. In this case Dan will be of help of course, so make
sure to file a bug. And I guess I don't need to mention this but
temporarily falling back to permissive mode is a short-term workaround
- In some cases daemons might want to create more than one file/dir
below /var/run which are supposed to be labelled differently. In this
case the daemon can either be modified to fix its labels up itself, or
a drop-in file in /etc/tmpfiles.d/ might help (see below).
- Many .spec files currently own subdirs of /var/run. These need to be
updated to %ghost those dirs only, so that the automatic removal of
these files/dirs on boot doesnt cause rpm to complain. The list of packages
which own such files/subdir you find on the aforementioned feature
page. I will mass-file bugs against these packages later tonight,
requesting the %ghosting of these entries. For more information on the
%ghost directive in .spec files see this page:
a) Lennart will mass-file bugs regarding %ghost usage tonight
b) Lennart will switch on /var/run and /var/lock on tmpfs either
tomorrow or the day after tomorrow
c) YOU need to edit your .spec file and place a %ghost where
c) YOU need to test if you package still works, and if necessary file
AVC bugs, add an /etc/tmpfiles.d drop-in file to your program, or patch
it so that it is able to recreate these directories beneath /var/run on
This is a new feature of systemd, but which is apparently very much
liked by people outside of systemd, so this might actually find adoption
even on systems which will not adopt systemd any time soon, since it
actually is not specific at all to systemd. By dropping a simple
configuration file in /etc/tmpfiles.d you can ensure that volatile files
and directories are: a) created, deleted or emptied at boot b) their
permissions/ownership fixed c) its directory contents cleaned up in
regular intervals (a la tmpwatch) and d) it is properly relabeled at
As an example, here's how such a file might look like for the screen package
(name it /etc/tmpfiles.d/screen.conf):
d /var/run/screens 1777 root root 10d
d /var/run/uscreens 0755 root root 10d12h
This encodes that two directories are created under the listed names, with
automatic clean up after 10 days resp. 10 days and 12h.
For more details consult the man page:
Thank you for your attention!
Lennart Poettering - Red Hat, Inc.
Just announcing that there'll be an IRC town hall with the FESCo
election candidates on Thursday, October 18th, at 1500UTC (1000
You can join #fedora-townhall-public to ask questions of the moderators,
which will be posed and answered by the candidates in #fedora-townhall.
More information is available here:
A summary and the irc log will be posted and linked from the wiki after
the discussion, if you're unable to watch it live.
Thanks in advance for your interest,
PS: I'd like a volunteer to help me moderate the questions, or at least,
help pick out the really good ones for our limited time (1 hr.) If you'd
like to help out, please let me know.
Jared Smith made an announcement in his blog  about some upcoming
personnel changes in Fedora. I wanted to make a specific announcement
to the Fedora lists as well.
Through the end of 2010 and a little bit beyond, I will be working along
side Robyn Bergeron to transition my official Fedora responsibilities to
her. This will include getting the Fedora 15 team schedules into shape,
feature wrangling, bugzilla maintenance, and any number of other things.
Robyn and I are committed to making this transition as smooth,
complete and timely as we can, and expect the transition to be completed
before the Fedora 15 feature submission deadline. Said a different way,
if you've already been working with me on something, I'll continue to
help you with it. For all new topics, please contact Robyn directly and
we will work together as necessary to get them done.
One of the luxuries of my position was keeping tabs on most of the teams
in Fedora via their mailing lists. I won't have as much time for this
going forward so I'll be scaling back the number of mailing lists I
watch and contribute to. If I posted to a list in the past, please
don't assume I'll automatically see your message there in the future.
Also please don't hesitate to contact me directly if you feel the need
to do so.
Fedora, it's been a great ride. We've made great progress in the past
three years and I'm thankful you let me be a part of it. Here's to
wishing only the best to Robyn in her new role serving the Fedora community!
p.s. I'm still looking forward to and rooting for an on time Fedora 15
This is a reminder email about the end of life process for Fedora 12.
Fedora 12 will reach end of life on 2010-12-02, and no further updates
will be pushed out after that time. Additionally, with the recent
release of Fedora 14, no new packages will be added to the Fedora 12
Please see http://fedoraproject.org/wiki/DistributionUpgrades for more
information on upgrading from Fedora 12 to a newer release.