The joy of updates
13 Jun 08 at 00:47 | 
gcc, gentoo, glibc, libtool, pixman, updates
Glibc-2.8 and gcc-4.3.1 were let loose on ~arch the other day, and this —as expected— caused some fuss. While gcc-4.3.0 had been sitting in p.mask, a lot of packages were tested and patches were applied, so this did not cause too much trouble. You can check bug 198121 to see that many issues are resolved, but a few remain open at this time. (The obpager one reported by me.)
We had no such advance warning for glibc-2.8 though, and this is more troubling because there is no going back after upgrading glibc. Fortunately there were not many issues, as can be seen in the tracker bug, with 12 of the 23 reported now fixed. I myself ran into netkit-rsh, consolekit, acpid and gamin. I got the go-ahead to commit the gamin fix proposed in the bugreport, so that one is taken care of. The other three I mentioned are still unresolved, although fixes do exist. I have therefore committed these fixes to berkano overlay, until the maintainers find the time and inclination to fix these packages properly.
Another, but more troublesome update was pixman-0.11.4. Seems innocent enough on the face of it, but it resulted in Xorg leaking humongous amounts of memory, eventually crashing, because the kernel would kill the out-of-memory process. Luckily I ran into someone on #gentoo who had pinned down pixman as the culprit, so I could do a quick downgrade. In the meantime the bug has been fixed, so the pixman upgrade is now safe.
And then there is also libtool-2.2, which has been let loose on ~arch a couple of times before, but been remasked because of too many bugs cropping up. There are still some packages not working with libtool-2.2, such as evince, proftpd and courier-imap. So if you use any of the apps that have a problem with this version, you would probably want to put =sys-devel/libtool-2.2* in your package.mask. Personally, I have updated, because all the issues that touched me are fixed.
While not strictly necessary, I did an emerge -e system && emerge -e world. And with the issues I ran into fixed, I am now content with a freshly updated and consistent ~x86 desktop system. (I had to “downgrade” my amd64 system earlier because ndiswrapper refused to work with 64-bits drivers, and I need wifi.)
And you? Did you have any interesting adventures with these updates? Is there anything still broken for you, or anything you would have liked advance warning about? Let’s hear it!
Roguelazer on 13 Jun 08 at 01:26:
I did get to enjoy the pixman update and X eating 1.3GiB of RAM. That was fun… So far nothing else has broken. *crosses fingers*
juantxorena on 13 Jun 08 at 06:04:
What about python-2.5? Another core package, rotting in bugzilla since 2006 because of lack of mantainers of some packages (2 or 3) and because being ignored by some arches (s390, sh and the rest) and by everybody else, who doesn’t seem to care/know about that issue.
David Philippi on 13 Jun 08 at 09:59:
Nice to know that pixman was what nearly killed my system. Got to a very slow crawling due to swap but I killed X fast enough.
For GCC, libtool and glibc – I’m happy about those getting unmasked. Did libtool quite some time ago as it’s faster. They don’t cause hard bugs, just a few header includes or a correct call to autotools but have real gains. Having those unmasked creates the required pressure to get things actually fixed, which may take a long time otherwise IMHO.
transacid on 13 Jun 08 at 10:17:
“We had no such advance warning for glibc-2.8 though, and this is more troubling because there is no going back after upgrading glibc.”
Really? Why isn’t it possible to downgrade glibc? wouldn’t an -e system && -e world help?
Ben on 13 Jun 08 at 11:26:
Roguelazer: yeah, that was fun indeed. With htop or conky with mem-usage running, you could see the memory being swallowed. Here it was ~40MB every 30 seconds. That was a real WTF? moment.
juantxorena: python-2.5 has been in ~arch for ages, so that’s not really the issue. Of course it would be nice if it got stabilized before the python3k release. ;-)
David: I agree these packages should be unmasked and belong in ~arch. But especially in the case of core packages like glibc, I would think it would be a smoother transition if the devs had been given advance warning to test their packages against this new version of glibc, before making all ~arch users into testers.
transacid: anything that has been compiled against the new glibc, will most likely refuse to work after a downgrade. While technically it is possible, a glibc downgrade is a lot of hassle.
transacid on 13 Jun 08 at 11:59:
Wouldn’t it be also possible to just downgrade the glibc and remerge all package build after the glibc update (only 4 here)
Ben on 13 Jun 08 at 12:17:
Only if they are non-essential packages.
transacid on 13 Jun 08 at 12:23:
Wed Jun 11 19:31:56 2008 >>> sys-libs/glibc-2.8_p20080602
Wed Jun 11 19:32:40 2008 >>> app-office/openoffice-bin-2.4.1
Wed Jun 11 19:32:45 2008 >>> net-misc/iputils-20071127-r2
Wed Jun 11 19:35:15 2008 >>> media-libs/xine-lib-1.1.12-r1
Wed Jun 11 19:36:25 2008 >>> app-cdr/cdrdao-1.2.2-r2
Wed Jun 11 19:37:39 2008 >>> net-analyzer/nmap-4.65
Wed Jun 11 19:38:09 2008 >>> dev-util/git-1.5.5.4
Thu Jun 12 21:50:47 2008 >>> games-board/pokerth-0.6.2
Fri Jun 13 12:15:35 2008 >>> x11-libs/pixman-0.10.0
Cardoe on 13 Jun 08 at 14:05:
You sound like the exact user that should not be using ~arch. But should stay on a stable system. A lot of the issues you are complaining about are the same issues that anyone using an unstable or testing Debian system would have. Stuff needs some place for users to test it and for it to cook. If it works reasonably well for a developer, we need to push it to a larger audience. Sometimes things break when the larger group gets it.
Ben on 13 Jun 08 at 15:54:
Cardoe, I understand things will break from time to time in ~arch. That is to be expected, and I don’t have a problem with that. But I hold it to be proper procedure to put an update which will very likely lead to breakage in various parts in the tree in p.mask first, and give maintainers some time (even if just one week) to test their packages and come up with fixes. Just like what has been done for gcc-4.3, and what we in video herd are doing with ffmpeg. Of course that won’t catch all issues, but it will catch the most serious ones.
Personally, I can handle such occasional breakage, it’s what you get for living on the (bleeding) edge. But I do care about other ~arch users, and I know there are many, especially because often packages just take ages to become stable in Gentoo.
David Philippi on 13 Jun 08 at 17:43:
I think for glibc some time in package.mask might have been a good idea and for GCC waiting on 4.3.1 propably fixed quite a few really bad problems. The most strange guy is libtool-2.2 for me. It’s speeding up compilation and in the few packages where I had problems with it I found a fix already in bugzilla which was far from invasive…
energyman on 13 Jun 08 at 23:24:
emerge -e system broke pretty hard for me.
Now I get this:
checking for C compiler default output file name… configure: error: C compiler cannot create executables
and this:
ls /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.1/
ls: cannot access /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.1/: No such file or directory
equery says there should be something but there isn’t.
tcpwrappers fails with tons of include errors – all related to glibc – and even man doesn’t even work anymore.
I am not impressed.
kernelOfTruth on 14 Jun 08 at 13:08:
thanks for this information:
xorg had kept on crashing for me for the last 2 or 3 days, now I know it’s due to pixman – not gcc-4.3.1 or glibc-2.8
kernelOfTruth on 15 Jun 08 at 10:14:
update:
nope, it was kind of an regression with gcc-4.3.1 + hardened toolchain:
-march=core2 causes all this weird crashing, -march=nocona and/or -mtune=nocona -msse3 -mssse3 fixes it (already reported on the toolchain thread)
I’m glad however that the memory hunger of X has been fixed ;)