Patrick's playground

With the latest libpng bump (1.2 -> 1.4) there was a change in the libname. Most apps were easily rebuilt, but a few naughty ones were really fighting it. The usual symptoms were "random" failures while running revdep-rebuild. For some people lafilefixer did it, for others the rebuild of cairo or pango seemed to do the trick.

What bothered me was that these packages were consistently hiding from revdep-rebuild and somehow convincing it that they were fine ... and on my notebook I managed to hit this exact issue.
I haven't tried to reproduce it to see how this goes wrong, but here's some of the output of lddtree on /usr/bin/nm-applet where I noticed the failure:

libnotify.so.1 => /usr/lib/libnotify.so.1
        libpng14.so.14 => /usr/lib/libpng14.so.14
...
libpng12.so.0 => /usr/lib32/libpng12.so.0

Obviously this is pretty fu.... funny. There's a mix of both versions involved because at that time not all libs had been rebuilt. But ... here's the thing that tripped me. How the BLEEP does it manage to confuse the paths so badly that a 64bit lib tries to integrate 32bit libs?
This makes ldd assume that the dependency is satisfied while linking will fail. Can't work. It's wrong. And because it appears to not be missing a lib it's a real pain to figure out.

Maybe this is enough of a hint to permanently fix the problem - the next .so bump could explode in the same way, and that's something we really don't want to happen. I don't know how this sneaks in, so any debugging to track it down is appreciated.

Travelling and meeting new people is usually great fun. Meeting geeks even more if you are a geek yourself. The last few years I've been at FOSDEM and FROSCON every year (which usually turns into a sleepless weekend of sensory overkill). And there are smaller events like the Gulaschprogrammiernacht ("gulash and programming night", if you want) which are also pretty awesome. Plus the LUGs you find in most cities ...

So here's an offer:
I'll come to your event (be it LUG, exhibition, or just an afternoon barbeque with a few friends) and discuss Gentoo, Open Source, performance-tweaking linux or whatever topics you want (optionally a shiny presentation, if there's a good topic). All I ask in return are the travel costs from Frankfurt Airport (FRA) and food and shelter.

If that sounds like the perfect rent-a-geek opportunity to you ... Contact me and we'll figure it out. And if you ask nicely you can even get a realtime Gentoo bugfixing session out of it!

As you might have noticed there's been quite a bit of movement in the postgres ebuilds in the last weeks.
With the new dev-db/postgresql-{base,server} ebuilds stable on all (relevant) arches we've reached the point where users finally get something newer than 8.2 by default. That was a pretty annoying situation to fix.

The upgrade process should be the usual dump-and-restore, and thanks to the slotting in the new ebuilds (which have been there for a long time!) you can run all versions in parallel at the same time. The 9.0 beta looks pretty neat, and since you don't *have* to use the newest version there's a good chance we'll unmask it soon. Upstream considers it pretty solid already.

And with the new ebuilds in place, the old ones masked at last, the virtuals (virtual/postgresql-base, virtual/postgresql-server) serve no purpose. I've fixed all dependencies in the tree yesterday and masked them, if you have any ebuilds make them use dev-db/postgresql-* instead.

A big thanks goes to Aaron W. Swenson, who has done a lot of work to get the ebuilds into the rather good shape they're in now. And if all goes well he'll be a full Gentoo dev soon and can then directly work on the postgres ecosystem in Gentoo. Which is a pretty good thing to happen :)