January 12, 2011

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.

January 5, 2011

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

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!