There is a perpetual problem facing all Linux distributions around how fast
to move with software updates. In Fedora, of course, our default speed is
petal-to-the-metal. This is part of who we are and why we are awesome.
However, it also sometimes makes life difficult for us -- for example, our
Puppet packages are broken because Ruby is too new. It also makes life
difficult for people trying to use Fedora seriously. It's especially hard
with Ruby and Java -- not that there's anything _wrong_ with these
languages, but the packaging expectations are different and often in
conflict with the system operator's traditional packaging worldview.
So, some Red Hat folks have developed an idea called Software Collections
which is aimed at this problem -- it lets you install and choose between
different versions of RPM-packaged software in parallel at run-time.
The base tool for enabling this (scl-utils) is included in Fedora, but we
don't allow Software Collections actually as Fedora packages (see
https://fedoraproject.org/wiki/SoftwareCollections). This is for very good
reasons -- there are a number of huge unanswered questions around structure,
infrastructure, maintenance, and security updates.
I think, though, that this tool, integrated well and supported, could really
help us in Fedora (and in EPEL). So, I'd like to
a) enumerate the problems with Software Collections in Fedora,
b) develop a medium-term plan for solving those problems, and
c) develop a longer-term plan for taking full advantage of the functionality
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
Hey, folks. It's that time again - time to start thinking about Test
Days for Fedora 18.
For anyone who isn't aware, a Test Day is an event usually focused
around IRC for interaction and a Wiki page for instructions and results,
with the aim being to get a bunch of interested users and developers
together to test a specific feature or area of the distribution. You can
run a Test Day on just about anything for which it would be useful to do
some fairly focused testing in 'real time' with a group of testers; it
doesn't have to be code, for instance we often run Test Days for
l10n/i18n topics. For more information on Test Days, see
Anyone who wants to can host their own Test Day, or you can request that
the QA group helps you out with organization, or any combination of the
two. To propose a Test Day, just file a ticket in QA trac - full details
are at https://fedoraproject.org/wiki/QA/Test_Days/Create . For
instructions on hosting a Test Day, see
You can see the schedule at
https://fedoraproject.org/wiki/QA/Fedora_18_test_days . There are many
slots open right now, with the earliest on 2012-08-09 and the latest
2012-11-01. Consider the development schedule, though, in deciding when
you want to run your Test Day - for some topics you may want to avoid
the time before the Alpha release or the time after the feature freeze
or the Final freeze.
We normally aim to schedule Test Days on Thursdays; however, if you want
to run a series of related Test Days, it's often a good idea to do
something like Tuesday / Wednesday / Thursday of the same week (this is
how we usually run the X Test Week, for instance). If all the Thursday
slots fill up but more people want to run Test Days, we will open up
Tuesday slots as overflows. And finally, if you really want to run a
Test Day in a specific timeframe due to the development schedule, but
the Thursday slot for that week is full, we can add a slot on another
day. We're flexible! Just put in your ticket the date or timeframe you'd
like, and we'll figure it out from there.
If you have any questions about the Test Day process, please don't
hesitate to contact me or any other member of the QA team on test@ or in
#fedora-qa on IRC. Thanks!
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
test-announce mailing list
Several months ago I attempted to upgrade libffi 3.0.10 to 3.0.11. The change was reverted because the soname change in this version of the library broke the build environment. I would still like to get 3.0.11 in Fedora. I don't anticipate any future ABI-breaking changes, and 3.0.12 will include additional ports like Aarch64, which is likely of interest to some Fedora developers. How do we coordinate a rebuild for dependent packages? Also, I assume this will have to wait 'til F18 is out (fine by me), but I'd like to deal with it early in the F19 cycle.
Now that FESCo accepted http://fedoraproject.org/wiki/Features/RPM4.11
for F19... (in what might well be a record time - less than a minute in
the meeting from proposal to acceptance :)
Rpm 4.11 alpha (or actually post-alpha snapshot to pull in a few
accumulated fixes + enhancements) will be hitting rawhide shortly.
There's no soname bump involved this time, so no rebuilds required.
There's one thing that does affect nearly every package: new warnings
about bogus spec changelog dates. The most common cause is the day name
not matching the given date, such as:
warning: bogus date in %changelog: Tue Jun 03 2009 Panu Matilainen
<pmatilai(a)redhat.com> - 4.7.0-5
Jun 03 2009 was Wednesday, not Tuesday, hence the warning. As rpm hasn't
hasn't previously validated changelog dates make sense as a whole,
nearly every spec has one or more of these mistakes. It's just a warning
though and doesn't cause build failures.
Other than that, chances are you wont notice much anything at all.
Assuming all goes well that is. So its the usual drill: keep your eyes
open on rawhide builds and report any new oddities found ASAP. I'm not
expecting any major issues with this but you never really know.
For further details see the draft release notes at
- Panu -
Some weeks ago libcdio 0.90 has been released. In addition to the
libcdio-0.90 release there have been parts split off into a separate
package called libcdio-paranoia. libcdio-paranoia has been imported and
I will now also update libcdio to 0.90 in rawhide. I will rebuild all
dependencies over the next few days and adjust the depending packages to
require both libraries where necessary.
I'm interested in becoming a Fedora package maintainer, thought I'd throw
out the self-introduction. A bit about me: I currently work as a release
engineer at Puppet Labs in Portland, Oregon, and before that was a Mac
sysadmin for a local college here. Most of my packaging experience has been
gained here at Puppet, packaging our products as rpms, debs, and in various
other forms (my heart has always been with rpm packaging). My goals here
are both to contribute back to Open Source and do my part to help keep the
Fedora platform awesome, and also work with the Fedora maintainers of
puppet to making sure Puppet upstream is a good citizen of the Fedora
community and ease its adoption. In this spirit, I commented on this BZ
https://bugzilla.redhat.com/show_bug.cgi?id=782560 with some help to move
it along as a Puppet dependency, but alas, it hasn't gotten a ton of
traction just yet. Anyway, just thought I'd introduce myself, perhaps in
search of a sponsor.
what is the expected way of handling X11 keyboard layouts in Fedora 18?
I don't use xorg.conf, the configuration was autodetected from
/etc/sysconfig/keyboard (probably) till F17 and it worked just fine. After
upgrading to F18 using yum method, my keyboard layout stopped working.
Should the X11 server (or login managers) autodetect the layout from new
config files? Or is 'localectl set-x11-keymap' the only supported way now?
If 'localectl' is the only supported way, we should add this information to
"Upgrading Fedora using yum" instructions on the wiki. The same with old
kernel options. (I do not know how is this handled in the other upgrade
If the old configuration files are supposed to work, what is the responsible
component I should file bug on?