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?
I am working on bringing in Enlightenment back into Fedora. I am going to
be copying the packages at
as I work on them. This would just be a temporary experimental repo. I
have updated the existing dependencies in the Fedora repo to the latest
versions since yesterday (libeina, evas, eet, ecore, libwebp) and I have
packaged eio and evas-generic-loaders so far. I know a few people have
been working on this earlier. so if anyone is interested, do drop me a mail
offlist and we can collaborate. I would be happy to let anyone else take
over as well if you are so inclined. Thanks