Some bugs detected during arch testing

Just wanted to share some list of bugs I've recently hit during arch testing / stabilization. Especially useful for that is testing of reverse dependencies.

bug #387789 - app-office/passepartout-0.6_p1 failed (compile phase)
bug #390805 - dev-embedded/ftdi_eeprom-0.2 fails to compile
bug #397513 - dev-util/netbeans-6.8-r1 fails to compile (JavacTask.java:107: package CheckForCleanBuilds does not exist)
bug #398881 - media-libs/libxspf-1.2.0 fails to install (/usr/bin/install: cannot stat `html/*.gif': No such file or directory)
bug #398887 - dev-db/pgadmin3-1.14.1 pre-merge check failed (postgresql-config: command not found)
bug #399469 - dev-python/matplotlib-1.0.1-r1 fails to build with USE=doc
bug #403851 - dev-java/xmlunit-1.3 uses network during src_compile
bug #403859 - dev-db/slony1-1.2.10 fails to compile (error: 'SerializableSnapshot' undeclared)

And bugs that are fixed now:

bug #385403 - dev-php5/pecl-http-{1.7.0-r1,1.7.1} sandbox violation
bug #385423 - games-simulation/crashtest-1.1 fails to build (fltk-config misuse?)
bug #387785 - dev-cpp/gtksourceviewmm-2.10.1 failed (glibmm missing shared doc utilities?)
bug #390831 - media-sound/amarok-2.4.3 fails to compile (config-amarok.h: No such file or directory)
bug #394995 - emerge: InvalidDependString: USE flag 'birdstep' is not in IUSE (REQUIRED_USE contains flag not in IUSE)
bug #399513 - dev-lang/xsb-3.3.2 fails to compile
bug #399621 - media-plugins/vdr-dvd-0.3.7_pre20071113-r1 fails to compile against media-libs/libdvdnav-4.2.0
bug #401137 - dev-java/mx4j-tools-3.0.2 fails to unpack with jython

Help wanted with www-client/chromium bugs

Recently some new bugs have been filed against www-client/chromium, mostly related to HTML5 video issues. More feedback on those bugs would help fixing them faster and preventing possible regressions for Gentoo stable users.

By the way, helping with those bugs may be one step for you towards becoming a Herd Tester, and getting a cool badge on Gentoo Bugzilla like this one:

Back to the bugs then:

bug #402787 - html5 video loading progression bar issue
bug #402995 - html5 video loading but not playing
bug #402997 - html5 video sound playback issue

I have not yet tried reproducing above bugs, but the steps to reproduce are not specific enough. Any help with making the bugs more specific and reproducible is welcome, as well as reports of success (i.e. no bug + version of the browser) or failure (i.e. bug reproduced + details).

bug #403449 - doesn't release memory if sandboxed and swap is used

This is a weird bug, and may be kernel-related. I have not yet tried to reproduce, but help is very welcome there, and remember to post the version number of your kernel (uname -r). Always remember to post the version number of www-client/chromium as well.

If you like this post, please use the +1 button or one of the other ways to share. I appreciate your feedback.

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

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

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

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