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

Signing Manifests is easy

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

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

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

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