December 31, 2010

Don't break the tree

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.

December 19, 2010

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

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.

December 14, 2010

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

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!

December 9, 2010

New Herd Tester: Mike Gilbert

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

November 29, 2010

Tools for Chromium development in Gentoo

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!

November 9, 2010

www-client/chromium: gconf no longer required

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!

November 3, 2010

www-client/chromium experimental support for system-v8

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!

October 16, 2010

What your distro can do for you that upstream cannot

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!

October 10, 2010

Try www-client/chromium-bin

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.

October 4, 2010

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

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!

September 10, 2010

Is your distro fast enough for Chromium?

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?

August 28, 2010

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

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.

August 21, 2010

Portage migration to git tracker bug

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.

August 12, 2010

www-client/chromium beta channel update (6.0.472.33)

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!

August 1, 2010

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

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.

July 22, 2010

Why having short bug queues is good

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.

June 25, 2010

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

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.

June 21, 2010

www-client/chromium and nvidia-drivers compile issues should be now solved

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.

June 20, 2010

www-client/chromium is now stable on amd64 and x86

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!

June 11, 2010

www-client/chromium dev channel bump to 6.0.427.0

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

June 3, 2010

www-client/chromium dev channel unexpected delays

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.

May 26, 2010

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

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.

May 19, 2010

Upgrading to samba-3.4.6

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.

May 3, 2010

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

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.

April 15, 2010

Updating x11-base/xorg-server to 1.7.6

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.

April 14, 2010

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

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!

April 12, 2010

Fixing www-client/chromium bugs

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

April 6, 2010

Solving Qt blocker issues

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.

March 27, 2010

Follow Chromium-related blogs on planet.chromium.org

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.

March 14, 2010

www-client/chromium plugin incompatibilities

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.

March 1, 2010

Stabilizing a package is a serious thing

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?

February 16, 2010

How to get useful backtraces almost for free?

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.

February 12, 2010

How Chromium ebuilds are masked

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