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

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

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):

1. Remember to use screen or tmux to avoid problems when the network connection breaks temporarily.
2. 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.
3. Read the OpenRC migration guide. Don't glance over it, make sure to read every sentence carefully.
4. 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

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