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"

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/] dlopen failed
when trying to open /usr/lib64/chromium-browser/
/usr/lib64/chromium-browser/ 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...