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

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.

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.

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!