Monthly Archives: November 2006

gtk+-2.10 stabilization

News from the GNOME stabilization front:

We decided to go back to stabilizing GNOME in at least two steps again.
GTK+ and co in the first step, followed by the whole of GNOME as the second step.
So there is now bug #156572 for stabling gtk+-2.10 and co. It seems that amd64 is done already :)

Note that when going from gtk2.8 to gtk2.10, you need to rebuild packages that provide gtk modules (librsvg, gtk-engines and so on), as the modules ABI was upgraded from 2.4 to 2.10 – the gtk ebuild gives information about this too.
Additionally there might be problems with notification daemon related stuff, as noted in the GNOME 2.16 Upgrade Guide, probably won’t hurt to also do a revdep-rebuild run just to be sure.

Next step is GNOME-2.16 stabling and I hope that will happen soon…

The step after that?
Why are you asking. World domination of course.

GNOME pre-2.14 cleanup

I figure that as I haven’t really blogged much as of late, I could just as well note what my latest commit spree was about (related to that – go beat my todays commit count on cia.navi.cx in a productive way :>).

I cleaned up redundant versions in the GNOME packages, which mostly amounted to removing the versions for earlier than GNOME-2.14, plus some old 2.16 versions that have a newer version in the tree for 30 days already or the ones with bugs while only a newer version has fixes.
In total about 100 different versions/revisions were removed, so I hope that helps a bit to rsync times and mirror server space.

And, no, no gnome1 packages were removed in the process, just a few revisions that had newer ones in the same major.minor version-set available. That cleanup is for when they have sat in p.mask for long enough and for certain someone else.

Many things not officially part of upstream GNOME haven’t been cleaned up yet, as well as some of the most core libraries, just in case (and fear of being reprimanded when removing them :-/) – such as glib, pango and gtk+.
There is also lots of redundant gstreamer/gnome co-maintained versions around. Could someone at home with gst maintenance take a look please?

I hoped to get the redundant gnome herd (co)maintained ebuild revision count down to ~200, but ended up at 325 for now, from around 420ish at the start of my long “day”.

At any rate, the current reason to do the cleanup is more or less fulfilled – easier generation for an GnomeUpstreamDelta wiki page for official GNOME modules, listing patches that we apply on top of upstream tarballs, with an explanation of what it does and if and where it is filed upstream to reduce the delta. This is in line with other distributions doing the same. I believe Luis wanted to start with a proper page of ours very soon :p

PS: pcheck repo -c RedundantVersionReport rocks.

That is all.