Paweł Hajdan's Dev Blog

Kernel 3.1.6 - watch out for "Unable to mount root fs" panic

2012-01-13T08:38:00.000+01:00

While testing kernel 3.1.6 for bug #396469 I got the common kernel panic "not syncing: VFS: Unable to mount root fs".

It's easy to fix, here's the grub config before:

title Gentoo Linux
root (hd0,0)
kernel /boot/vmlinuz-3.1.6-gentoo

And fixed one:

title Gentoo Linux
root (hd0,0)
kernel /boot/vmlinuz-3.1.6-gentoo root=/dev/sda1

I had to pass an explicit root= parameter. How to figure it out? mount -l or cat /proc/mounts are not so helpful:

rootfs on / type rootfs (rw)
/dev/root on / type ext3 (rw,noatime,errors=continue,barrier=1,data=writeback)

So I used "fdisk -l" just to make sure whether it's sda or something else...

Device Boot Start End Blocks Id System

/dev/sda1 63 59006744 29503341 83 Linux

/dev/sda2 59006745 62910539 1951897+ 82 Linux swap / Solaris

How to batch-stabilize big things like KDE 4.7.4

2012-01-09T20:01:00.000+01:00

I've just finished stabilizing KDE 4.7.4 on x86, and it was about 300 packages, so it would be very hard to do without good tools. I have some pretty nice scripts, so it took me maybe a few supervision and everything has been done automatically (even then it can take 3-4 hours, so trying to do that manually would be a huge waste of time and take even longer).

Here's how I did that. First I created a ~/kde-stable.txt file with the following contents:

# bug #396359
=app-misc/strigi-0.7.7
=app-office/akonadi-server-1.6.2-r1
=dev-libs/shared-desktop-ontologies-0.8.1
=kde-base/activitymanager-4.7.4
=kde-base/akonadiconsole-4.7.4
=kde-base/akregator-4.7.4

... hundreds of packages omitted ...

And then:

~/arch-tools/batch-stabilize.py --arch x86 -i kde-stable.txt --repo ~/gentoo-x86/

You can do that too! Just clone my arch-tools repo, hosted by the Gentoo Overlays Team.

The tool creates a file batch-stabilize.log in the current directory (if it exists, new entries are appended to it), and the file contains all executed commands, their exit codes and output, so you can figure out what happened if something goes wrong.

It's also easy to create a list of packages in format accepted by batch-stabilize.py from the bug list. The bugzilla viewer is interactive, ncurses-based, and is simple to run:

~/arch-tools/bugzilla-viewer.py --arch x86 --repo ~/gentoo-x86/ --verbose

It's OK to omit --repo and --verbose parameters - it'll run faster and do less checks. You can also append --security parameter to only review security bugs.

I hope you like that, and enjoy either the tools, or they results - more up to date Gentoo!

Another 5-month update

2011-12-06T12:32:00.000+01:00

I have one system that I rarely update (it's not the best idea, but it allows me to write a blog post from time to time), so I wanted to show you again that it's possible to update without re-installing, and that everything is solvable and logical unless you have a very complicated setup.

The commands might seem more complicated than "apt-get dist-upgrade", but remember Gentoo gives you much greater flexibility (USE flags, kernel versions, backporting, etc, etc).

Let me just post a few commented output "dumps":

Timestamp of tree: Tue, 21 Jun 2011 20:45:01 +0000

# emerge -uDNa world

Usually portage updates itself as the first package. This time it was different due to a block (auto-resolved), but to be even safer I decided to start with updating portage explicitly.

x86 testers wanted: tuxonice-sources and freeipmi

2011-11-04T13:49:00.001+01:00

We have at least two bugs that need more testing reports on x86:

bug #373491 - Stabilize =sys-kernel/tuxonice-sources-2.6.38-r1
bug #364485 - sys-libs/freeipmi-0.8.9 de-keywording request

If you're using those packages please comment on the mentioned bugs what are your testing results (both positive and negative; without positive report we don't really know whether anyone has tested those).

By the way, feel free to just do the same (test and report) from time to time with x86 bugs.

If you have an amd64 system, please do the same with amd64 bugs.

It's really worth your effort. If the updates have annoying bugs, it's better to defer stabilization until they're fixed rather than annoying many stable users. Similarly, if the updates work for you, it's better if we can just release them sooner and start working on other packages.

Exhaustive testing of stable reverse dependencies

2011-10-19T09:56:00.001+02:00

tl;dr - Developers, if you fix a problem with a stable package and do a version bump, please make sure to open a stabilization request for the bumped version. Many of problems described here have been fixed in the ~arch tree, just the fix was not pushed to stable.

Recently I started testing stable reverse dependencies in a more organized way. I used to go to sites like http://tinderbox.dev.gentoo.org/misc/dindex/, pick a few entries and random, see if they're stable, and emerge them after installing the unstable packages for testing.

That approach had several problems: some of the failures with reverse dependencies were not actually regressions, and many reverse dependencies listed on tinderbox are not marked as stable, which requires time for manual corrections.

Recently I wrote a tool for finding reverse dependencies. It only returns stable packages, and can even randomly choose a smaller number of packages in case of very large set of reverse dependencies (there are many packages depending on gtk+ for example).

My new workflow is to emerge the reverse dependencies first, and remove from list any packages that already have problems. Then I emerge the stable candidates, and re-emerge the reverse dependencies. Any problems that occurs in the last phase is most likely a regression.

So far I haven't really noticed that many regressions, but there are actually existing breakages in the stable tree, usually for less popular packages (that's why more organized testing is useful). Here are some examples of bugs I've encountered:

bug #351854 - media-libs/libquicktime-1.2.2 poor programming practices lead to failure
bug #380409 - dev-lang/ruby-enterprise-1.8.7.2010.02-r1 collides with dev-lang/ruby-1.8.7_p334-r2
bug #384499 - Please stabilize =dev-lang/tinycobol-0.65.9
bug #384501 - Please stabilize =dev-perl/Term-ReadLine-Gnu-1.200.0-r1
bug #384737 - media-tv/dvbstreamer-1.1-r1 fails to install (/usr/bin/install: will not overwrite just-created `.../types.h' with `types.h')
bug #384863 - sci-chemistry/raster3d-2.7c fails to compile (Error: Expression at (1) must be of INTEGER type, found REAL)
bug #384869 - app-admin/webalizer should not die on USE=nls and no LINGUAS in pkg_setup
bug #385265 - Please stabilize =net-misc/arpd-0.2-r1
bug #385403 - dev-php5/pecl-http-1.7.0-r1 sandbox violation
bug #385423 - games-simulation/crashtest-1.1 fails to build (fltk-config misuse?)
bug #387531 - Please stabilize =app-text/zathura-0.0.8.4 to avoid nasty blocker

Stabilizations: situation stable

2011-09-20T20:41:00.002+02:00

I just checked and x86 and amd64 bug queues are fully under control. I'd even say we're now doing stabilizations faster than maintainers can file new bugs and fix stabilization blockers.

A lot of credit goes to arch team members and arch testers who've been doing a lot of good work in this area. Also, at least for me, the productivity has increased a lot after using better tools from http://git.overlays.gentoo.org/gitweb/?p=proj/arch-tools.git;a=summary

My plans now include better handling of stabilization requests we can't handle yet due to bugs or missing info (I'm going to provide better feedback for the maintainers - just need to adjust my tools a little bit), and then looking for packages that are a little bit behind and should be stabilized.

Arch testers' help is still wanted and very appreciated. Now that bug queues are shorter than they used to be we can do even better testing.

We're on good track towards having a good, stable, and up-to-date tree.

www-client/chromium: Kerberos testers wanted

2011-08-30T21:52:00.000+02:00

I changed the way Kerberos works in >=www-client/chromium-15.0.865.0.

If you're interested in testing, please emerge that version with USE="kerberos" and see if the Kerberos support works as intended. It'd also be nice to test with various Kerberos implementations (MIT vs Heimdal).

Even if you're not using Kerberos, if something is broken in that version please also file bugs.

The changes implemented in that version should make it work better with revdep-rebuild (the browser binary now explicitly links with Kerberos libraries instead of using dlopen, and it uses system headers instead of some modified bundled copy; this way breakages should be fixable by revdep-rebuild and not silent).

www-client/chromium: experimental support for ChromeDriver

2011-08-27T00:31:00.001+02:00

Due to popular demand, I've added experimental support for ChromeDriver to the latest dev channel release of www-client/chromium. It is controlled by USE="chromedriver".

Please report any issues, even minor ones, with this flag. This should work "out of the box", without any additional downloads or setup. If it doesn't, I'd like to fix it.

By the way, that dev channel release also has optional support for PulseAudio. It is controlled by USE="pulseaudio".

And there are only 4 open bug reports assigned to the Gentoo Chromium Team!

How to file a good bug about FTP-related bugs in Chrome

2011-08-10T20:44:00.000+02:00

I have just done a little clean-up of the bugtracker and closed old FTP bugs which don't have enough information to fix them. Of course those bugs can still be re-opened after reporters respond on them.

One of the most important rules for bugs is: please submit information you're asked to submit. If you're unable to follow-up, it's very likely your problem can't be fixed because of missing info.

Generally when filing an FTP-related bug, you should provide:

version number of Chrome
URL that causes the problem
detailed description of the issue (steps to reproduce, expected result, actual result, etc).

Furthermore, if the FTP site is not public, just the URL or description is usually not enough to fix any problem. What's needed is either:

raw directory listing (if you see anything like that in the error message, it should be obvious what to do), or
Wireshark/other sniffer's dump of network traffic.

If you're unable to provide that info, but are able to identify the name of the FTP server software serving the site, there is still a chance that the problem can be reproduced by installing that FTP software on developer's machine.

Finally, when submitting the raw directory listing, please don't just copy-paste it, because that results in implicit character set conversions. Use the browser's "Save As" command to save the raw listing to disk, and then attach that file to your bug report.

www-client/chromium-14.0.835.15 dev channel release

2011-08-06T01:02:00.000+02:00

Last dev channel release of www-client/chromium was really non-trivial to package. Here are the bugs that I had to fix:

bug #375759 by Mathieu Zhang
bug #375827 by fkhp
bug #376301 by Julien Sanchez
bug #376499 and bug #376501 by Mike Gilbert
NaCl didn't work (missing IRT in the tarballs)
system libvpx didn't work, had to switch back to bundled one
WebRTC requires PulseAudio to compile

Now before you start worrying about PulseAudio (which I know many people don't want on their systems), let me remind you that this is still a hard masked ebuild, and I'll ensure that our dependency on PulseAudio becomes optional. I'm working closely with the upstream to make that possible, so please stay tuned. Feel free to add yourself to the CC list of bug #377847.

Enjoy your updates!

More Manifest signing tips and stats

2011-06-28T11:24:00.000+02:00

If you're signing Manifests and wonder how to use a stronger hash than SHA-1, here's a nice ~/.gnupg/gpg.conf snippet:

enable-dsa2
personal-digest-preferences SHA512,SHA256,SHA1

This is a modified version of Justin's snippet.

By the way, since my last signing-related post in March, the number of signed Manifests has increased and now about 56% of Manifests are signed. Here are commands I've used to count the total number of Manifests and signed ones:

find /usr/portage -maxdepth 3 -name Manifest | wc -l
find /usr/portage -maxdepth 3 -name Manifest -exec grep -l 'BEGIN PGP SIGNATURE' {} + | wc -l

www-client/chromium Gentoo bugs review and how you can help

2011-06-22T10:38:00.000+02:00

Let me start with a general tip: if you're using Gentoo and hit a bug, please make sure there is a bug filed on Gentoo Bugzilla. Feel free to also report bugs upstream (this is great; remember to paste the link to the upstream bug in the Gentoo bug), but having a bug on the Gentoo side allows us to work around or at least be aware of issues for example when stabilizing new versions.

For example, see bug #371931: the upstream issue 78644 has been reported in April, but I only became aware of it late June, about 2 months of delay! Note that upstream generally prioritizes fixes that affect Google Chrome users, and not distro users. The bug does not affect Google Chrome, because it uses bundled ffmpeg. Upstream still wants to fix it (at some point they'll have to update ffmpeg), but it's just not a priority.

Okay, so let's review remaining bugs. If you want to help, this is a good opportunity.

bug #348841 - www-client/chromium: webgl not working: does http://bodybrowser.googlelabs.com/ work for you? Please post both success and failure reports, including emerge --info, www-client/chromium version and USE flags, media-libs/mesa version and USE flags. We may be able to correlate the reports and see what triggers problems.

bug #350250 - www-client/chromium-9.0.597.19 uses bundled protobuf: we still use bundled protobuf, and I'm afraid the version bundled with chromium may be patched in an incompatible way; I'll take a more detailed look when I find some time, but if you're interested in tinkering with the browser internals, it may be an interesting project; feel free to share your findings on that bug

bug #355181, bug #365841: we have some build issues with libpng-1.5; if you'd like to help fix them, please test with www-client/chromium-9999 and see if there are some not yet reported compile errors; if in doubt, just file a new bug; if you find upstream bugs or patches about this, please also report them

bug #361461 - www-client/chromium-11.0.696.25: fails to build with gcc 4.6; similar to the above: if you want to test, please use chromium-9999 and report any not yet reported issues, ideally both on the Gentoo and upstream side

bug #365187 - =www-client/chromium-11.0.696.57 and other version does not respect CFLAGS; this is a minor issue but it would be nice to fix it; if you're interested in modifying the upstream's custom build system, patches are welcome

bug #366695 - www-plugins/gecko-mediaplayer-1.0.3-r1 causes www-client/chromium to hang; this is sad - it seems many people would like to use gecko-mediaplayer, but we keep hitting various issues with it and Chromium; I'm not sure what's going on, so comments are welcome

bug #372495 - www-client/chromium fails to build with glibc-2.14 (tcmalloc); I think I'll just backport the upstream patch after some testing

That's it! Short bug queues are good for everyone, if you're interested feel free to read my earlier post.

net-print/foo2zjs: removed broken versions

2011-06-08T16:25:00.000+02:00

Earlier this year I added a foo2zjs ebuild that works. However, the older, broken versions were still in the tree, frustrating people. Today I removed those ancient versions (from 2008), and closed a lot of bugs: bug #321967, bug #323087, bug #340215, bug #353302, bug #367339.

If you encounter some problems with the 99999999 ebuild, please file a bug and CC me (phajdan.jr).

If you wonder how to emerge the ebuild now (it has no KEYWORDS), just do the following:

# echo "=net-print/foo2zjs-99999999 **" >> /etc/portage/package.keywords
# emerge -av net-print/foo2zjs

I hope you like it!

www-client/chromium frequent updates, a possible "solution"

2011-05-27T18:33:00.000+02:00

I noticed that people get annoyed by frequent updates of www-client/chromium (it takes a lot of time to compile), and someone even said something like "don't inflict those updates on me", which makes it sound like an update is something negative.

In my opinion a very active upstream is a good thing. Usually we don't need to keep local patches too long, because they just get included in the next dev channel release. We don't need to wait too long to see whether a particular bug was fixed, and so on. Also, most updates in the stable channel are security fixes.

On the other hand, I understand the frustrations caused by long compile times. There are various theories about bundled libraries in Chromium causing that, but I don't think they're accurate. We use system versions of most libraries, and there is a work in progress to remove few remaining ones. The largest pieces are WebKit (open-source HTML rendering engine, also used by e.g. Safari) and the browser itself. You can try compiling qt-webkit or webkit-gtk to see how long they take to build.

Okay, so what's the solution?

I tried to support a www-client/chromium-bin package in Gentoo, but it had quite a lot of problems, and is now masked for removal (and should get removed in just few days). Just to give you a few examples: bug #304527, bug #335101, bug #347175, bug #349249, bug #356609.

I think that a solution that may work for many people is using a Google Chrome package from some overlay. There's nothing to compile, and the download is about 20-30 MB. Why an overlay and not portage tree? See bug #272805, comment 170 for a pretty good explanation.

I tested www-client/google-chrome from belak overlay, and it seems to work (please remember that unofficial overlays are not supported by Gentoo in any way, and any problems should be reported directly to the overlay owners; the overlay may contain more ebuilds than just google-chrome, so don't be surprised by that). It's easy to install with layman. Make sure you have "mercurial" USE flag enabled, and then:

emerge -av layman
layman -a belak
echo "source /var/lib/layman/make.conf" >> /etc/make.conf
emerge -av google-chrome

Successfully migrated to OpenRC

2011-05-18T17:42:00.000+02:00

I just migrated all of my systems to OpenRC, one of them entirely remotely (ssh). It works, and here are my tips for successful migration (mostly basic):

Remember to use screen or tmux to avoid problems when the network connection breaks temporarily.
Make sure to run dispatch-conf (recommended) or etc-config (only if you're still using it) carefully and completely (update all files). If in doubt, just run it again, it will exit immediately if there's nothing to update.
Read the OpenRC migration guide. Don't glance over it, make sure to read every sentence carefully.
Before doing the update in production, make sure to test the upgrade procedure in a non-production environment.

Now here's one thing that may be easy to miss: your /etc/conf.d/net file will most likely require a manual update. Everything is described in the migration guide, the change is trivial. I'd rather not experiment what happens if you don't do that, but there is a real chance the system will just not bring up the network interfaces. Similarly, make sure that your net.eth0 etc services exist (ls -l /etc/init.d/net*) and will be started on boot (rc-status).

That should be it. Please report any problems to the Gentoo Bugzilla.

Chromium: Linux kernel configuration options needed for SUID sandbox

2011-05-04T10:42:00.000+02:00

If you're using Linux, it's a good idea to check the about:sandbox page to verify that the sandbox is working. For example, according to Differences between Google Chrome and Linux distro Chromium, some Chromium packages may lack support for sandboxing.

But it's more complex than that. About a week ago a slightly mysterious bug for the Gentoo package was filed claiming the browser is not adequately sandboxed. Initially I couldn't reproduce, but after a while, after updating another system, I confirmed this behavior. It turned out that to make the SUID sandbox fully effective, the kernel must support PID (process id) and network namespaces. Adding to the confusion, when the kernel supports them, about:sandbox displays entries for "PID namespaces" and "network namespaces" and a green "yes" next to them. But if the kernel doesn't support those features, nothing is displayed, which makes it difficult to diagnose what's wrong with the sandbox.

In case you need to update your kernel configuration, here's where to find the options (using make menuconfig), for your convenience:

General setup --->

-*- Namespaces support --->

[*] PID Namespaces

[*] Network namespace

Signing Manifests is easy

2011-03-27T13:35:00.000+02:00

There is a discussion about unsigned Manifest commits, and I decided to finally start signing the commits. It was indeed ridiculously easy, and there is even a Manifest Signing Guide.

No separate GPG key is needed, you can (and probably should) just use your developer GPG key.

If you are not sure what value to use for PORTAGE_GPG_KEY, here is an example how to extract it:

$ gpg --list-public-keys
/home/%%%%%/.gnupg/pubring.gpg
---------------------------
pub 1024D/30427902 20%%-%%-%% [expires: 20%%-%%-%%]
uid Pawel Hajdan Jr <%%%@%%%>

Now the value you want in this example is 30427902. They key ID is also present on the roll-call page.

I've put those PORTAGE_GPG_ configuration values just in /etc/make.conf. Here's how it all looks like:

FEATURES="... sign ..."

PORTAGE_GPG_DIR="/home/%%%%%/.gnupg"
PORTAGE_GPG_KEY="30427902"

By the way, if you are using the developer profile (and I'd encourage you to do so), FEATURES="sign" is already enabled there by default.

About 40% of the Manifests in the portage tree are signed. I think this is pretty good, and in fact I was expecting a much lower value before I've seen the stats.

It's really really easy to get this to work. What are you waiting for? Start signing Manifests!

Unbreaking net-print/foo2zjs

2011-03-17T15:39:00.000+01:00

If you happen to be using a printer that requires foo2zjs drivers (or foo2xqx, foo2hp, foo2lava, foo2qpdl, foo2slx, foo2hiperc, foo2oak - they are all part of net-print/foo2zjs package), you may be frustrated about numerous issues with broken digests for Gentoo's foo2zjs package.

Well, I also have a printer that requires one of those drivers, and decided to add a working ebuild to the tree. The upstream changes the tarball in place and requires downloading additional files from the network, so I decided to make a live ebuild. You can see bug #356695 and [gentoo-dev] unbreaking net-print/foo2zjs for the full story.

The end result is that there is a working net-print/foo2zjs solution on Gentoo now. The live ebuild requires one step to enable it:

# echo "=net-print/foo2zjs-99999999 **" >> /etc/portage/package.keywords

Then you should be able to just install it:

# emerge -av net-print/foo2zjs

Enjoy!

More packages supporting V8 JavaScript engine

2011-02-11T15:56:00.000+01:00

www-client/chromium, the web browser, is not the only package using V8 JavaScript engine.

net-libs/nodejs is using system-provided V8, and also dev-db/mongodb can use it instead of SpiderMonkey with USE="v8". I am excited to see more packages in Gentoo using this super-fast JavaScript engine, and hopefully there will be more in the future. Also, it should be very easy to develop your own applications using V8 (just run "emerge v8").

By the way, for now every release of V8 is using a different SONAME, because upstream cannot guarantee binary compatibility even across minor releases. Because of this, all applications using V8 have to be recompiled after updating the shared library.

I am looking for a few solutions to this problem. First, I think it is not realistic to make a few releases share the same SONAME without upstream cooperation (for a few reasons read Diego's Your symbol table is not your ABI). However, generally the releases seem to be compatible: http://linuxtesting.org/upstream-tracker/versions/v8.html. Also, because V8 is now independent from the applications (i.e. not bundled with them), you should not need to update it unless necessary.

It is not obvious how well this is going to work, so any feedback is welcome, especially if you hit bugs.

Watch out for issues with prelink and sys-libs/glibc-2.13

2011-02-07T08:39:00.000+01:00

I am usually only running stable Gentoo systems, so I have not seen the problem myself. However, unstable (~arch) users may be affected and it seems really serious. If you are using prelink and ~arch Gentoo, please read the following before updating and consider undoing the prelinking and removing prelink:

http://bugs.gentoo.org/show_bug.cgi?id=353814
http://forums.gentoo.org/viewtopic-t-863297-start-0-postdays-0-postorder-asc-highlight-.html

bug: python3 becoming system default

2011-01-12T13:05:00.000+01:00

Recently there was a bug in stage3 tarballs resulting in python3 being the default system python (such configuration is not supported yet and may result in various breakages).

If you installed recently, I'd recommend checking the system python version. The correct result should look like this:

# eselect python show
python2.6

For more information see bug #330655. The problem is now fixed, new stages are correct. To fix an existing installation, use "eselect python list" and "eselect python set" to switch to a python2 version.

An example of semi-large update

2011-01-05T21:06:00.000+01:00

It seems that updating outdated systems is a quite common headache, and that often people advise to just reinstall. Recently I was updating a system that was first installed in 2005 (amd64 stable), and last updated in April 2010 (about 8 months before this blog post). Fortunately I didn't hit major problems (like "masked by EAPI" errors when updating portage), but I hit a few minor ones, and I'd like to share the solutions and the overview of such an update with the community.

Note: I update most of my systems much more frequently (monthly or weekly depending on the system). This post is meant to show that while it's not trivial to update rarely, it's not as complicated as one might think.

Note 2: I'm not sure about distributions that have 6-months release cycle, but it's quite possible they have their own problems on updates (I guess most common problems are that X, sound, or wireless network card stop working).

Read more »

Don't break the tree

2010-12-31T18:31:00.000+01:00

Jeremy has described in a nice way three ways one can test Gentoo. I think that indeed we need to have many people doing each of those ways, and it seems we already have.

It is worth noting that mixing stable with unstable requires some knowledge and experience to tell the difference between a real bug, and a problem caused by invalid mix. Those "invalid mix" problems could be considered incomplete package dependencies, but in practice the assumption that the system is fully stable or fully ~arch and that all packages are fully updated makes things a bit simpler.

Now I'm going to try to answer the questions from Jeremy's post.

How should Gentoo make it easier to add packages that break reverse dependencies if ~arch isn’t appropriate and nothing really happens when package.mask’d?

Well, maybe the "nothing really happens" part is the problem? It requires some effort to build a little community testing various packages, but it really pays off. In case of www-client/chromium and related packages, we have an active, growing community, and many of those people are using hard masked, and even 9999 ebuilds. Okay, poppler is a bit different (it's a library, it's not as "interesting" as a web browser), but have we tried getting more people interested in testing it? I think more people follow the Gentoo Planet than read random package.mask entries.

Is ~arch becoming a second stable tree and thus losing value in general?

I'm not using ~arch daily, so I don't really know. However, I consider ~arch not being broken "all the time" a good thing. It has to be useable if we want people using it. It may be worth reading about Debian's experiences with testing.

Related, are overlays hurting Gentoo? The Xfce team subscribes to the theory that ~arch is the place to get useful testing feedback. The Xfce pre releases are in ~arch so the final release is ready for arch asap. This means that we have less work in the long run because we are maintaining less versions sooner and in better quality.

Yes, I think overlays, if overused, may be hurting Gentoo, causing unnecessary fragmentation. I'm really glad to hear that XFCE team keeps things in the main tree. I'm using XFCE daily (stable system), and I like the end result of that.

portage-2.2 has this cool “preserved-libs” feature that wouldn’t help compilation issues in this case but might help runtime issues by keeping the old lib(s) around. I like this feature but it is still masked for majority of the users, even though many devs are using it – is it time to release it to the world with all the bugs it has?

No idea. I trust Zac's and portage team's judgment.

Related, does masking a feature block contributors? I want to say yes simply due to exposure.

I'd say it depends on the contributors and visibility. If it's a random entry in package.mask, don't expect that people will "just" unmask it and start sending bug reports and patches. Similarly, people who can unmask things and are interested in what to unmask, following developers' blogs, etc, are more likely to submit useful bug reports.

Finally, let me quote a very important part of Diego's "Put it there and wait for users to break" isn't a valid QA method:

Simply put, do your own homework: learn about the package you’re maintaining, try hard not to break reverse dependencies; if it happens that you break a package unexpectedly, hey, it’s ~arch, we can deal with it. But do not commit stuff that you know will break a good deal of the packages depending on yours. Especially if you’re not out there to fix them yourself.

www-client/chromium-bin: supporting both arch and ~arch?

2010-12-19T13:35:00.000+01:00

Initially, chromium-bin was just a snapshot compiled by the upstream's buildbot, and it had many problems on Gentoo, like bug #303080.

At some point I converted the package to use a binary built on a Gentoo system, to avoid the libjpeg mismatch. However, because arch (stable) build environment was used, it was incompatible with the ~arch systems, and as a workaround dependencies had to be adjusted in an ugly way (bug #347175).

Because chromium-bin was never stabilized, I thought - why not just switch to ~arch build environment? Well, that also has problems. First, arch (stable) users who unmask chromium-bin hit bug #348738. And, as ~arch is not really stable, I hit bug #348587 when trying to compile a more recent version of chromium.

I'm not sure what the end result will be, but I'm considering going back to stable (arch) build environment, and stabilizing chromium-bin, so that stable users don't need to unmask anything. Of course it's very likely to break chromium-bin on ~arch...

A possible workaround is using more bundled libraries for chromium-bin, like ICU. It would prevent issues like bug #347175, but I'm not sure if I really want to do that.

Oh, and in theory we can have different builds for arch and ~arch. However, to do that we may need more people in the team.

If you're interested in helping with any of the above, please contact the Chromium in Gentoo team.

www-client/chromium and "missing" libffmpegsumo.so

2010-12-14T09:54:00.000+01:00

Gentoo, similarly to other Linux distributions, avoids bundled libraries in its packages. One of www-client/chromium's dependencies is ffmpeg, and in Gentoo it's unbundled when possible (sometimes upstream makes very incompatible changes).

What people see are console errors like these:

[154:154:175949833148:ERROR:base/native_library_linux.cc(28)] dlopen failed
when trying to open /usr/lib64/chromium-browser/libffmpegsumo.so:
/usr/lib64/chromium-browser/libffmpegsumo.so: cannot open shared object file:
Permission denied

Those messages can be safely ignored, and are not symptoms of a bug. They just mean we have removed the bundled libffmegsumo, so it's no longer there.

I hope you like it - less bundled libraries!

New Herd Tester: Mike Gilbert

2010-12-09T13:28:00.000+01:00

I am excited to announce that the first official Herd Tester has joined the Chromium in Gentoo team. Mike Gilbert, also known as floppymaster, has been actively helping with reported bugs, and testing bleeding-edge builds of www-client/chromium.

I have received a lot of questions how people can help the Chromium in Gentoo project, and I think that a few examples would be the best way to explain that:

We also have another great contributor, Julien Sanchez. He is testing the unstable versions of the browser, helping on Bugzilla, and as you can see in the www-client/chromium's ChangeLog, his work is very appreciated.

There are many more people helping the Gentoo team. Based on packages' ChangeLogs, here is our little "Hall of Fame" so far:

Yuri Arabadji
Carlos Augusto
Alex Barker
Patrizio Bassi
Johan Bergström
Anton Bolshakov
Auke Booij
Robert Bradbury
Zeke Connor
cyrillic
Damien
Reimar Döffinger
Vladimir Dolzhenko
Sergey Dulko
Daniel Faucon
ferret
fkhp
Michał Górny
Petr Gregor
Aaron Haviland
Andrew John Hughes
Joel
Constantine D. Kardaris
kernelOfTruth
Bailey Kong
Oleksandr Kovalenko
Priit Laes
Luke-Jr
mcclung
Kevin J Meagher
mjbjr
Nikoli
nixtrian
Doktor Notor
Vicente Olivert
Victor Orozco
Anthony Parsons
Ian Pickworth
Elias Pipping
Tomas Racek
George Reitsma
Richard
Alexandre Rostovtsev
Keith Rusler
sandrain
Daniel Schömer
Evan Teran
Andrey Vihrov
Andy Wilkinson
Sok Ann Yap

As you can see, we get a lot of support and feedback from the community.

It is worth noting that many Gentoo developers who are not members of the project have also contributed their work:

Jory A. Pratt (anarchy)
Diego Elio Pettenò (flameeyes)
Jim Ramsay (lack)
Peter Alfredsen (loki_val)
Pacho Ramos (pacho)
Maciej Mrozowski (reavertm)
Tomáš Chvátal (scarabeus)
Dror Levin (spatz)
Samuli Suominen (ssuominen)
Harald van Dijk (truedfx)

Add to that the work of the arch teams and the security team... It is just awesome!

By the way, don't forget how it all started: Bernard Cafarelli (voyageur) added the first ebuilds to the tree in 2009...

Tools for Chromium development in Gentoo

2010-11-29T08:47:00.000+01:00

Yesterday I added an experimental package dev-util/chromium-tools, that contains wrappers for depot_tools, a set of scripts required to fetch and work with Chromium sources.

If you are interested in working on Chromium (the open source web browser project), chromium-tools may be useful for you. Right after installing, gclient, gcl, and drover will be available in your PATH, and auto-updating of those tools will be handled transparently.

There is a git repository for the project, and patches are welcome!

www-client/chromium: gconf no longer required

2010-11-09T18:49:00.000+01:00

If you're not using GNOME, but you like www-client/chromium, you no longer have to install gconf, which also brings a few other packages people don't want like gnome-base/orbit (it's a high-performance CORBA ORB, if you'd like to know).

Of course that happens with USE="-gnome", and you also need a bleeding edge version of chromium (>=chromium-9.0.570.0-r1, hard masked). Oh, and just in case you ask: dbus-glib is still needed.

I also landed the patch upstream, so now everyone can benefit from it. Enjoy!

www-client/chromium experimental support for system-v8

2010-11-03T19:15:00.000+01:00

I am experimenting with building www-client/chromium with system-provided V8, the super-fast JavaScript engine. If you'd like to try it, emerge >=www-client/chromium-9.0.570.0 with system-v8 USE flag. By the way, this is not just about web browsers. We have patches for other packages too, for example to make mongodb use v8.

The system-v8 USE flag is masked. Here's how to unmask it (remember, it's experimental, may break, etc, etc):

mkdir -p /etc/portage/profile
echo "www-client/chromium -system-v8" >> /etc/portage/profile/package.use.mask

Please report any issues to Gentoo Bugzilla. Thanks!

What your distro can do for you that upstream cannot

2010-10-16T16:27:00.000+02:00

Some time ago a user on Gentoo Forums has pointed out that gecko-mediaplayer plugin does not load in www-client/chromium. It turns out there is a compatibility issue that leads to a browser hang, so upstream just blacklisted the plugin (based on file name). The browser has a hardcoded list of plugins that it will not load at all.

The good part is that the hang only occurs when gecko-mediaplayer is compiled with USE="gnome". With -gnome it doesn't hang the browser. But how can the upstream know? The file name is the same in both cases.

Well, in Gentoo the package manager does know which USE flags were used to compile any package. I decided to add a gecko-mediaplayer USE flag to www-client/chromium. When enabled (that's the default setting), it will make sure gecko-mediaplayer is compiled with -gnome (if installed), and remove it from the hardcoded blacklist.

Moreover, if you're a GNOME user or just happen to have gnome in USE, you can disable the flag just for one package by using /etc/portage/package.use. Or you can choose to compile gecko-mediaplayer with whatever USE flags you want, and disable support for it in www-client/chromium to avoid the blocking dependency.

USE="gecko-mediaplayer" is available for >=www-client/chromium-7.0.544.0-r1. It is hard masked for now, but sooner or later will become stable. Please help with testing, and enjoy your www-client/chromium!

Try www-client/chromium-bin

2010-10-10T12:51:00.000+02:00

If you'd rather not compile www-client/chromium (it takes some time, even on a powerful machine), give www-client/chromium-bin a try.

Now all versions in the tree are compiled on a Gentoo development machine, and synchronized with www-client/chromium releases. Special thanks go here to the Gentoo Infrastructure team for providing the machine for Chromium in Gentoo project.

The -bin version of the package is not stabilized yet, but I plan to start the process soon. Some testing before that happens would be appreciated. Please report all issues to the Gentoo Bugzilla.

www-client/chromium-7.0.536.2 now with system-sqlite support!

2010-10-04T13:13:00.000+02:00

The latest dev channel release of www-client/chromium (hard masked) has optional support for building with the system sqlite package instead of the bundled copy.

We all prefer the system copies of course, so please help testing this new feature. All you have to do is to enable system-sqlite USE flag and recompile chromium.

Please note you might hit some issues with browser features that use sqlite. They may disappear after starting with a clean profile (~/.config/chromium). Remember to back up the old profile, and please report any issues to the Gentoo Bugzilla.

Enjoy your latest www-client/chromium!

Is your distro fast enough for Chromium?

2010-09-10T07:29:00.000+02:00

Recently we got the sad news that chromium-browser has been dropped from Debian Squezze. The problem is that the upstream moves very fast, and that includes WebKit, which makes backporting security patches very hard. Oh, and it's going to move even faster.

Well, Gentoo has hit some problems too, see bug #335750. Hopefully we will manage to stabilize the 6.x series, and prepare for the 7.x.

In case you'd like to help, see the project page. Will Gentoo be fast enough for Chromium?

www-client/chromium now uses system-provided dev-libs/icu

2010-08-28T02:21:00.000+02:00

The latest dev channel release, www-client/chromium-7.0.503.1, builds with use_system_icu=1, which means one less bundled library. It also seems that the binary size of /usr/lib/chromium-browser/chrome is now smaller.

We have still quite a lot of bundled libraries though, but we're really close to building with system sqlite. I'm working on upstream patches (both Chromium and SQLite) to make this possible.

Please note that as www-client/chromium uses more and more system libraries, it will also require more testing on the Gentoo side, because upstream QA only tests the bundled configuration.

Portage migration to git tracker bug

2010-08-21T06:02:00.000+02:00

I'm not sure why it hasn't been posted before, or maybe it has: there's a tracker bug for portage migration from cvs to git. Things start to get more real.

By the way, if you were reading my posts on gentoo-dev, that's the kind of project visibility I like to see.

www-client/chromium beta channel update (6.0.472.33)

2010-08-12T06:08:00.000+02:00

There is a new beta version of Google Chrome, and now portage also has www-client/chromium-6.0.472.33 in ~arch. There are some new exciting features in the 6.x series, like improved UI, autofill, better sync, and more.

If you encounter any problems with the new version, please report the issues to Gentoo Bugzilla. Please also see bugs marked as "Herd Testers' Help Wanted". All helpful bug comments and good bug reports are appreciated.

Oh, and if you have been waiting for WebM support, the updated ebuild now enables it. Enjoy!

Help Gentoo make www-client/chromium and chromium-bin packages better

2010-08-01T07:06:00.000+02:00

I know many of you use the www-client/chromium and chromium-bin packages, even the -9999 version which updates directly from the upstream's svn. I'm sure you'd like them to be the best we can do.

I have created a project page for Chromium packages maintenance for that reason. One of the goals is to build a community of users helping with the packaging efforts and providing valuable feedback.

If you are interested, please take a look at the link above. It contains useful bug queries, especially for ones we need more help with (Herd Testers Help Wanted). Frequently, a comment from another person confirming the same problem (with emerge --info and build log if applicable) would make diagnosing the issues easier and faster. And if you can provide some additional info, or a detailed analysis what is wrong and how to fix it, that's even better.

Why having short bug queues is good

2010-07-22T06:43:00.000+02:00

A lot of Gentoo teams have bug queues. Each herd, the security team, the arch teams, and each individual developer. It's better when these queues are short, but not only because it looks better and solves problems that people have.

Long bug lists tend to grow over time. They're harder to navigate, it's just easier to skip an easy to fix bug, or forget to answer user's question. Even browsing such list takes time. Recently the x86 team has reduced the queue size to 10 bugs or so. It's now much easier to manage, and stabilizations take a lot less time. Also, we can pay more attention to issues that prevent or delay stabilizations.

So the summary is... keep your bug queues short, and don't be afraid to put an entry on staffing needs page if needed.

Oh, and if you're a user looking for a way to contribute, helping shorten someone's bug list is a great way to do so.

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

2010-06-25T09:58:00.000+02:00

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

2010-06-21T11:33:00.000+02:00

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

2010-06-20T21:48:00.000+02:00

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

2010-06-11T11:31:00.000+02:00

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

2010-06-03T22:02:00.000+02:00

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.

www-client/chromium soon to go stable in Gentoo, testing wanted

2010-05-26T09:26:00.000+02:00

Did you notice that we just had a stable release of Chromium? It's a great news, and www-client/chromium-5.0.375.55 is now in portage.

My plan is to start the stabilization process soon, to move it from ~arch to arch. Before that happens though, I'd like to ask you to help testing this new package. Please try emerging it on your system and report any problems you encounter to the Gentoo Bugzilla. Note that the bugs are really getting fixed. For example, here's the list of fixed www-client/chromium issues.

If you're running a stable system, you can keyword-unmask it easily:

echo "=www-client/chromium-5.0.375.55" >> /etc/portage/package.keywords
emerge -av www-client/chromium

For more information about unmasking packages, see the Gentoo Handbook.

Upgrading to samba-3.4.6

2010-05-19T20:02:00.000+02:00

When you upgrade to net-fs/samba-3.4.6, you need to ensure the users will still be able to authenticate against samba. There are various ways to do that, but the simplest one is to add the line below to /etc/samba/smb.conf:

passdb backend = smbpasswd

Of course this is not the best long-term solution (refer to the upstream docs for possible options). However, if you just upgraded, and are wondering why things broke, this line can save you within seconds.

When you hit a strange bug, make sure to rule out ccache

2010-05-03T11:29:00.000+02:00

ccache is a very useful tool, especially on a from-source distro like Gentoo. It may make repeating compilations several times faster. However, when using it, you have to be aware of the cache corruption issues.

Recently I started a thread on gentoo-dev on that topic. If you just want examples of weird behavior, look at https://bugs.gentoo.org/show_bug.cgi?id=316657 and https://forums.gentoo.org/viewtopic.php?p=6262495#6262495.

If you are using ccache and hit a hard-to-reproduce compile failure, try re-running the compile with ccache disabled (FEATURES="-ccache" emerge ... should be fine; if you want to be extra sure unmerge ccache temporarily). If that fixes the problem, you should clean your ccache cache and then you can continue using it... up to the next failure. If you are adventurous and want to get to the root cause of the problem, see robbat2's hints.

I wonder about the idea of adding cache integrity checksums to ccache, so that the corruption can be detected. If you're looking for a way to contribute to Open Source, that may be an interesting project.

Updating x11-base/xorg-server to 1.7.6

2010-04-15T18:35:00.000+02:00

To ensure that the update to x11-base/xorg-server-1.7.6 is problem-free and doesn't result in say, broken drivers, just run this one-liner:

emerge -1av $(eix --only-names -I xf86- -C x11-drivers)

In case you've seen my previous post about rebuilding Qt, you probably recognize the pattern.

HTML5 videos should now work everywhere using www-client/chromium

2010-04-14T15:24:00.000+02:00

It's amazing how fast things can happen. I wrote two days ago that we are looking for good bug reports about HTML5 video support in Chromium/Gentoo. Soon after that, we got bug #314977, and after comparing a working and non-working configuration, and some testing, the fix was made available in the portage tree.

Today, after even more encouraging reports in the forums, I applied the fix to all www-client/chromium ebuilds in the tree.

The one thing I'd like to say now is... thank you, Gentoo community!

Fixing www-client/chromium bugs

2010-04-12T13:35:00.000+02:00

I recently fixed some Chromium bugs on Gentoo, and at the time of this post we are down to just three of them: http://bugs.gentoo.org/buglist.cgi?quicksearch=chromium.

If you have any problems with this great browser on Gentoo, please file a bug. My point is that Gentoo Bugzilla is the place developers look at most frequently (at least I do). We also have forums, and I try to also help there if I can, but things are less organized there. It's frequent that many people comment about unrelated issues, we don't get enough details, and it's sometimes hard to tell whether an issue is really resolved.

I'm sometimes seeing complaints about HTML 5 video not working on Gentoo, and other similar issues. I would be very interested both in bug reports, and also working configurations. Hopefully some pattern will emerge, making it possible to fix the issue. Here's the minimal needed info:

emerge --info
version and USE flags of www-client/chromium (for example emerge -1pv www-client/chromium)
similarly for ffmpeg
steps to reproduce (the web site address - URL - would be great)
a screenshot also helps, to tell whether it's a crash, or the playback UI doesn't load, or some other issue

Solving Qt blocker issues

2010-04-06T15:11:00.000+02:00

I encountered some Qt blocker problems on a system I rarely update (once per three months maybe). I asked Ben de Groot (yngwin) about that, and there's a nice one-liner that worked for me and may be useful for you:

emerge -1av $(eix --only-names -I qt- -C x11-libs)

It seems that all of Qt packages must be at the same version, and for some reason portage only wanted to update some of them when I ran emerge -uDNa world.

Of course before running that command make sure that eix database is up to date with eix-update.

Follow Chromium-related blogs on planet.chromium.org

2010-03-27T10:01:00.000+01:00

If you're interested in development of Chromium, there is one, new, very good place to look for news. It's http://planet.chromium.org/ and it aggregates info about releases, new features, and more.

Read more »

www-client/chromium plugin incompatibilities

2010-03-14T11:22:00.000+01:00

Recently some reports about plugins incompatible with Chromium appeared in the bugzilla, so this is a little explanation what to do in case you hit a problem.

First, Flash works just fine, so you don't have to worry about it. By the way, if you don't like Flash, I recommend this nice FlashBlock extension.

Some plugins are known not to work with Chromium. For example, gecko-mediaplayer may cause you some headaches. If any other plugin is misbehaving, please report it to the Gentoo Bugzilla.

Now you have two choices with plugins. By default Chromium package has USE="plugins-symlink" enabled, which will make it use the system-installed plugins by default, so that things can work out-of-the-box. With more recent versions of the package this USE flag will also prevent installation of known-incompatible plugins. The other choice is to disable "plugins-symlink" USE flag, and manage /usr/lib/chromium-browser/plugins (chromium) or /opt/chromium.org/chrome-linux/plugins (chromium-bin) manually. For the full story see http://bugs.gentoo.org/301911.

Stabilizing a package is a serious thing

2010-03-01T11:51:00.000+01:00

I recently joined the x86 project, and I'm helping with marking packages as stable on that architecture.

Even in this short period of time, I've hit several things that prevented or delayed a package from becoming stable. I think it's a good idea to warn people before rather than after, so if you want your package to become stable, please watch out for any of these:

unstable dependencies; just file bugs for these first
failing tests; you should be running with FEATURES="test" all the time to catch these
upstream considering the version experimental; why should we consider it stable then? There are exceptions to this rule however if older versions are unmaintained.
open bugs for the package
repoman warnings for the package, or QA concerns on manual ebuild inspection (like not calling die on emake failure)
requiring the user to do manual configuration that could be instead performed automatically that if not done prevents the package from working completely

Additional note: if you know any issues about the package that might raise concerns of any of the arch teams, indicate so in the stabilization bug report.

One more note: does every minor version bump need to get stabilized?

How to get useful backtraces almost for free?

2010-02-16T13:33:00.001+01:00

It's not as widely known as I would like, but FEATURES="splitdebug" in /etc/make.conf is a really useful setting. It does not make programs slower, but keeps the debugging info in case you need to report a bug. It's especially useful for packages which take long time to compile, or which use a lot of system libraries.

To save your time recompiling software when someone asks for better backtrace in a bug report, I encourage you to read Gentoo backtrace guide and apply it. Even splitdebug alone will give you noticeable advantage when something crashes. If you don't want to recompile the entire world after that, it's not needed. Over time more and more packages will get recompiled with splitdebug.

How Chromium ebuilds are masked

2010-02-12T13:48:00.000+01:00

As you have probably noticed, www-client/chromium ebuilds are masked in an interesting way. After the latest beta channel release the situation is finally clear. If you want to be on the dev channel, you have to hard unmask the package. If you want to be on the beta channel, just ~keyword unmask it. There are no stable releases yet. For more information please refer to http://dev.gentoo.org/~phajdan.jr/ and http://googlechromereleases.blogspot.com/.