Another 5-month update

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

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

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

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

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

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

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

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

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

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

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"

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

bug: python3 becoming system default

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

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