PaulHowarth/Blog/2009-04-21

Tuesday 21st April 2009

Fedora Project

Started updating the Gnome-1 stack (libxml, glib, gtk+, ORBit, imlib, gnome-libs, libglade) to fix up a bunch of minor niggles:

  • Libraries not linked against all of their requirements, leading to "undefined non-weak symbol" issues
  • Libraries unnecessarily linked against other libraries, leading to "unused direct shared library dependency" issues
  • Rebuilds needed to add %{_isa} provides

  • Missing libXt-devel dependency in imlib-devel (Bug #478357)

I'd updated and built all of the packages locally and didn't envisage any problems.

Firstly, I updated all packages in Rawhide, which went OK until I got to gnome-libs, where the ppc64 build failed. This turned out to be because of the old config.sub and config.guess files shipped in that release, a problem I'd come across earlier when updating libxml. After adding an almost identical patch to the one for libxml, gnome-libs built successfully, as did libglade (which didn't need patching).

Next up were the updates for Fedora 10 and 11. These couldn't be done as regular builds because updated packages don't automatically get pulled into the buildroots, and I wanted the lower level packages to be used in the rebuilds of the upper level packages for consistency, and also because some of the upper level packages require the new %{name}%{_isa} provides from the rebuilt lower level packages. So I built the leaf packages libxml and glib and raised an infrastructure ticket to get them added into the buildroots. It turned out that the ticket needed to be raised in the separate rel-eng trac instance, which I did. After quite a bit of discussion on the merits of these updates I managed to get libxml and glib tagged for override and built gtk+ and ORBit.

The imlib dependency bug I was fixing had been raised for EPEL-5, so I also started updating the packages there, by building glib, gtk+, and imlib. However, it turned out that glib and gtk+ are in RHEL 5 and should never have been branched for EPEL-5 (it wasn't me that did that - I just recently took over maintenance of the packages) so the new builds for those packages were removed and I marked those branches "dead" in CVS to prevent a repeat of that incident.


Recent