#1574 Gnome-1 stack rebuild for F-10 and F-11
Closed: Fixed None Opened 12 years ago by pghmcfc.

I'm in the process of rebuilding much of the Gnome-1 library stack (up to libglade) for F-10, F-11, and Rawhide to address various minor niggles. Rawhide is being done as a chain-build and needs no intervention, but F-10 and F-11 will need the lower-level packages tagging for the buildroots at various times before moving to the next level.

The bottom level packages are now done:[[BR]]
F-10: libxml-1.8.17-22.fc10, glib-1.2.10-32.fc10[[BR]]
F-11: libxml-1.8.17-22.fc11, glib-1.2.10-32.fc11

These need tagging into the F-10 and F-11 buildroots, which will enable me to rebuild gtk+ and ORBit.

I'll then need those builds tagging to build imlib.

I'll then need that tagging to build gnome-libs.

Then I'll need that tagging to build libglade.

Should I raise new tickets for each of these steps or just add an update to this one?

Various minor niggles, which will require churning a ton of packages... is that really the best idea?

Replying to [comment:1 jkeating]:

Various minor niggles, which will require churning a ton of packages... is that really the best idea?

Well it's hardly "a ton" of packages, and they're quite small as packages go these days.

The key points of the rebuild are to fix inefficient library linkage (undefined non-weak symbols, unused direct library dependencies) and to get the %{name}%{_isa} provides on the packages so that dependencies using %{?_isa} can be relied on to work on every release; there's also a missing dependency fixed in the imlib update (http://bugzilla.redhat.com/478357).

Now I could do these builds against the existing packages in most cases but I'd rather "do the right thing" and build them in the right order so that everything's built on the latest package set. I'd also like to do a single update for each release in bodhi.

But how important are these updates to cause the churn in F10? I can buy F11 a bit, and rawhide sure, but F10?

Replying to [comment:3 jkeating]:

But how important are these updates to cause the churn in F10? I can buy F11 a bit, and rawhide sure, but F10?

If the changes aren't done in F-10, dependencies such as:

Requires: libxml-devel%{?_isa}

will work everywhere but F-10. On older releases the macro has an empty expansion, and on newer releases there is an existing build that provides that dependency. So doing the updates (which will affect very few people anyway since these are legacy packages) provides for spec file portability between all releases, which is surely a good thing?

eh, I tend to think that we should only update things on released branches if they have positive effect upon the consumer, and not just so that it makes things easier for the creator. You could queue up the changes in CVS so that they'll be there next time you need to modify the packages for a real end user visible reason.

The imlib fix solves a real problem that's been reported in bugzilla. The updated package is tested (against the updated lower level packages) and ready to commit in cvs (Rawhide is already done). Can we at least go as far up the stack as imlib?

meh, whatever it's your choice. I've tagged them for override.

Thank you. gtk+ and ORBit are now built and need tagging prior to building imlib:

F-11: gtk+-1.2.10-68.fc11, ORBit-0.5.17-26.fc11

F-10: gtk+-1.2.10-68.fc10, ORBit-0.5.17-26.fc10


imlib-1.9.15-11.fc10 and imlib-1.9.15-11.fc11 are now ready for tagging.

Thanks, last one now:

F-10: gnome-libs-1.4.2-14.fc10

F-11: gnome-libs-1.4.2-14.fc11

OK, thanks for that Jesse. Everything is now built and I have created an update for F-10:


(no doubt there will be a nicer URL after the packages are pushed to testing)

The question now is whether to do the same for F-11 as a zero-day update or whether I should request that the F-11 packages be tagged for dist-f11 instead. Clearly there are no show-stopper bugs involved but on the other hand changes are minor and it's unlikely that further updates to any of these packages will happen during the F-11 life cycle notwithstanding any security issues that come to light. Also I suspect that none of these packages are included in any of the official F-11 releases apart from the Everything repo, so impact should be minimal and it'd save a little disk space on the mirrors not having to include these as update packages.


At the moment, probably best as an update.

OK, done:


I'll leave the ticket open until the updates are pushed to stable (I've only requested testing for the time being), so I can add a note about the buildroot overrides no longer being needed.

All of these packages are now pushed to stable, so the buildroot overrides can now be removed.

All done now, thanks for the help.

Login to comment on this ticket.