For smooth sys-libs/glibc-2.11.1 upgrade, make sure to use >=gcc-4.3-

If you use too old GCC, you may hit bug #292174 (missing cpuid.h) when upgrading glibc to 2.11.1.

Don't worry - in case things go wrong, the error will be caught before the glibc on your system is replaced. Just make sure you have the latest GCC installed:

emerge -uav sys-devel/gcc

And then make sure it is actually used:

gcc-config -l

On my system the output looks like this (the star shows the currently used version):

 [1] i686-pc-linux-gnu-4.4.3 *

And here's an example how to change the active GCC version (using the number from above list):

# gcc-config 1

 * Switching native-compiler to i686-pc-linux-gnu-4.4.3 ...

For more info, see Gentoo GCC Upgrade Guide.

www-client/chromium and nvidia-drivers compile issues should be now solved

It turns out bug #319331 also appeared on a system with more recent nvidia-drivers. It seems I had to disable gpu rendering, and that's exactly what I have done. After you sync your tree, every www-client/chromium ebuild should contain the fix. Yes, remember to sync the tree. The ebuilds have been modified in-place. This way if you were not affected by this issue, you don't need to waste time to compile chromium again.

Unfortunately, I couldn't test with nvidia-drivers, but by grepping the build log I've verified that the file which caused the build failure is no longer compiled, so things should be fine now.

I'd like to add that I've noticed some reports about the issue on Gentoo Forums. However, the forums case was very ambiguous. The conclusion seemed to be that old nvidia-drivers make it break, but more recent drivers work fine. The problem with forums is that the communication there is unstructured and informal. A bug needs to have much more details, and a clearly set status. It's another bug reported that made me work around the issue on the Gentoo side.

So... if you hit any problems, please report bugs. An unreported bug is an unfixed bug.

www-client/chromium is now stable on amd64 and x86

If you haven't already, I'd like to encourage you to give www-client/chromium a try. It's now stable on amd64 and x86, thanks to our arch teams. It's also quite fast, so I hope you like it!

www-client/chromium dev channel bump to 6.0.427.0

As promised, the www-client/chromium ebuild has been bumped to 6.0.427.0, the most recent dev channel release. What's the extra improvement?

Well, we've been trying to use the system libraries since the beginning. However, if the bundled copies are still there, how can we be sure that they are really not used? Generally by looking at the build scripts we can most often tell that the code won't be compiled, but how about the headers? It wouldn't be nice to get some header mismatch or other bad things.

Anyway, in this bump we completely remove the bundled libraries. The ebuild removes every single file, except a chromium-specific .gyp file which is used to generate the makefiles. It looks like this during emerge:


>>> Preparing source in /var/tmp/portage/www-client/chromium-6.0.427.0/work/chromium-6.0.427.0 ...
 * Applying chromium-disable-vp8-r1.patch ...         [ ok ]
 * Applying chromium-gyp-fixes-r1.patch ...           [ ok ]
 * Removing bundled library third_party/bzip2 ...
 * Removing bundled library third_party/libevent ...
 * Removing bundled library third_party/libjpeg ...
 * Removing bundled library third_party/libpng ...
 * Removing bundled library third_party/libxml ...
 * Removing bundled library third_party/libxslt ...
>>> Source prepared.

As you can see, quite a lot of things gets removed. Unfortunately, some of them are still bundled. For example, we use system-provided zlib, but can't remove third_party/zlib due to bundled (and used) minizip library. We use bundled sqlite, hunspell, and icu. They are modified by upstream, so it's a bit more complicated. I hope that at some point we will use the system-provided versions of these libraries, and I'm going to do some work to make it happen. Please be patient. :)

www-client/chromium dev channel unexpected delays

If you wonder how it's possible that Chromium upstream released 6.0.422.0 dev channel release, but the version in portage is stuck at 6.0.408.1, the answer is simple: at some point the upstream-generated tarballs became broken. They don't contain important bits of WebKit, and the browser can't be compiled. In fact, even the Makefiles can't be generated.

And how is it possible that the tarballs are broken for so long? The normal release process only produces binary packages. Tarballs are produced automatically, and the only people who care about them are Linux distro packagers (that includes me). I'm working to get this fixed in a proper way upstream.

So you'll have to wait a bit for the next dev channel release in Gentoo... However, when we finally have working tarballs, I'm going to make some little improvements to the ebuilds. Just to keep our Chromium package even better.