Let me start with a general tip: if you're using Gentoo and hit a bug, please make sure there is a bug filed on Gentoo Bugzilla. Feel free to also report bugs upstream (this is great; remember to paste the link to the upstream bug in the Gentoo bug), but having a bug on the Gentoo side allows us to work around or at least be aware of issues for example when stabilizing new versions.
For example, see bug #371931: the upstream issue 78644 has been reported in April, but I only became aware of it late June, about 2 months of delay! Note that upstream generally prioritizes fixes that affect Google Chrome users, and not distro users. The bug does not affect Google Chrome, because it uses bundled ffmpeg. Upstream still wants to fix it (at some point they'll have to update ffmpeg), but it's just not a priority.
Okay, so let's review remaining bugs. If you want to help, this is a good opportunity.
bug #348841 - www-client/chromium: webgl not working: does http://bodybrowser.googlelabs.com/ work for you? Please post both success and failure reports, including emerge --info, www-client/chromium version and USE flags, media-libs/mesa version and USE flags. We may be able to correlate the reports and see what triggers problems.
bug #350250 - www-client/chromium-9.0.597.19 uses bundled protobuf: we still use bundled protobuf, and I'm afraid the version bundled with chromium may be patched in an incompatible way; I'll take a more detailed look when I find some time, but if you're interested in tinkering with the browser internals, it may be an interesting project; feel free to share your findings on that bug
bug #355181, bug #365841: we have some build issues with libpng-1.5; if you'd like to help fix them, please test with www-client/chromium-9999 and see if there are some not yet reported compile errors; if in doubt, just file a new bug; if you find upstream bugs or patches about this, please also report them
bug #361461 - www-client/chromium-11.0.696.25: fails to build with gcc 4.6; similar to the above: if you want to test, please use chromium-9999 and report any not yet reported issues, ideally both on the Gentoo and upstream side
bug #365187 - =www-client/chromium-11.0.696.57 and other version does not respect CFLAGS; this is a minor issue but it would be nice to fix it; if you're interested in modifying the upstream's custom build system, patches are welcome
bug #366695 - www-plugins/gecko-mediaplayer-1.0.3-r1 causes www-client/chromium to hang; this is sad - it seems many people would like to use gecko-mediaplayer, but we keep hitting various issues with it and Chromium; I'm not sure what's going on, so comments are welcome
bug #372495 - www-client/chromium fails to build with glibc-2.14 (tcmalloc); I think I'll just backport the upstream patch after some testing
That's it! Short bug queues are good for everyone, if you're interested feel free to read my earlier post.
June 22, 2011
June 8, 2011
net-print/foo2zjs: removed broken versions
Earlier this year I added a foo2zjs ebuild that works. However, the older, broken versions were still in the tree, frustrating people. Today I removed those ancient versions (from 2008), and closed a lot of bugs: bug #321967, bug #323087, bug #340215, bug #353302, bug #367339.
If you encounter some problems with the 99999999 ebuild, please file a bug and CC me (phajdan.jr).
If you wonder how to emerge the ebuild now (it has no KEYWORDS), just do the following:
# echo "=net-print/foo2zjs-99999999 **" >> /etc/portage/package.keywords
# emerge -av net-print/foo2zjs
I hope you like it!
If you encounter some problems with the 99999999 ebuild, please file a bug and CC me (phajdan.jr).
If you wonder how to emerge the ebuild now (it has no KEYWORDS), just do the following:
# echo "=net-print/foo2zjs-99999999 **" >> /etc/portage/package.keywords
# emerge -av net-print/foo2zjs
May 27, 2011
www-client/chromium frequent updates, a possible "solution"
I noticed that people get annoyed by frequent updates of www-client/chromium (it takes a lot of time to compile), and someone even said something like "don't inflict those updates on me", which makes it sound like an update is something negative.
In my opinion a very active upstream is a good thing. Usually we don't need to keep local patches too long, because they just get included in the next dev channel release. We don't need to wait too long to see whether a particular bug was fixed, and so on. Also, most updates in the stable channel are security fixes.
On the other hand, I understand the frustrations caused by long compile times. There are various theories about bundled libraries in Chromium causing that, but I don't think they're accurate. We use system versions of most libraries, and there is a work in progress to remove few remaining ones. The largest pieces are WebKit (open-source HTML rendering engine, also used by e.g. Safari) and the browser itself. You can try compiling qt-webkit or webkit-gtk to see how long they take to build.
Okay, so what's the solution?
I tried to support a www-client/chromium-bin package in Gentoo, but it had quite a lot of problems, and is now masked for removal (and should get removed in just few days). Just to give you a few examples: bug #304527, bug #335101, bug #347175, bug #349249, bug #356609.
I think that a solution that may work for many people is using a Google Chrome package from some overlay. There's nothing to compile, and the download is about 20-30 MB. Why an overlay and not portage tree? See bug #272805, comment 170 for a pretty good explanation.
I tested www-client/google-chrome from belak overlay, and it seems to work (please remember that unofficial overlays are not supported by Gentoo in any way, and any problems should be reported directly to the overlay owners; the overlay may contain more ebuilds than just google-chrome, so don't be surprised by that). It's easy to install with layman. Make sure you have "mercurial" USE flag enabled, and then:
emerge -av layman
layman -a belak
echo "source /var/lib/layman/make.conf" >> /etc/make.conf
emerge -av google-chrome
In my opinion a very active upstream is a good thing. Usually we don't need to keep local patches too long, because they just get included in the next dev channel release. We don't need to wait too long to see whether a particular bug was fixed, and so on. Also, most updates in the stable channel are security fixes.
On the other hand, I understand the frustrations caused by long compile times. There are various theories about bundled libraries in Chromium causing that, but I don't think they're accurate. We use system versions of most libraries, and there is a work in progress to remove few remaining ones. The largest pieces are WebKit (open-source HTML rendering engine, also used by e.g. Safari) and the browser itself. You can try compiling qt-webkit or webkit-gtk to see how long they take to build.
Okay, so what's the solution?
I tried to support a www-client/chromium-bin package in Gentoo, but it had quite a lot of problems, and is now masked for removal (and should get removed in just few days). Just to give you a few examples: bug #304527, bug #335101, bug #347175, bug #349249, bug #356609.
I think that a solution that may work for many people is using a Google Chrome package from some overlay. There's nothing to compile, and the download is about 20-30 MB. Why an overlay and not portage tree? See bug #272805, comment 170 for a pretty good explanation.
I tested www-client/google-chrome from belak overlay, and it seems to work (please remember that unofficial overlays are not supported by Gentoo in any way, and any problems should be reported directly to the overlay owners; the overlay may contain more ebuilds than just google-chrome, so don't be surprised by that). It's easy to install with layman. Make sure you have "mercurial" USE flag enabled, and then:
emerge -av layman
layman -a belak
echo "source /var/lib/layman/make.conf" >> /etc/make.conf
emerge -av google-chrome
May 18, 2011
Successfully migrated to OpenRC
I just migrated all of my systems to OpenRC, one of them entirely remotely (ssh). It works, and here are my tips for successful migration (mostly basic):
- Remember to use screen or tmux to avoid problems when the network connection breaks temporarily.
- Make sure to run dispatch-conf (recommended) or etc-config (only if you're still using it) carefully and completely (update all files). If in doubt, just run it again, it will exit immediately if there's nothing to update.
- Read the OpenRC migration guide. Don't glance over it, make sure to read every sentence carefully.
- Before doing the update in production, make sure to test the upgrade procedure in a non-production environment.
Now here's one thing that may be easy to miss: your /etc/conf.d/net file will most likely require a manual update. Everything is described in the migration guide, the change is trivial. I'd rather not experiment what happens if you don't do that, but there is a real chance the system will just not bring up the network interfaces. Similarly, make sure that your net.eth0 etc services exist (ls -l /etc/init.d/net*) and will be started on boot (rc-status).
That should be it. Please report any problems to the Gentoo Bugzilla.
May 4, 2011
Chromium: Linux kernel configuration options needed for SUID sandbox
If you're using Linux, it's a good idea to check the about:sandbox page to verify that the sandbox is working. For example, according to Differences between Google Chrome and Linux distro Chromium, some Chromium packages may lack support for sandboxing.
But it's more complex than that. About a week ago a slightly mysterious bug for the Gentoo package was filed claiming the browser is not adequately sandboxed. Initially I couldn't reproduce, but after a while, after updating another system, I confirmed this behavior. It turned out that to make the SUID sandbox fully effective, the kernel must support PID (process id) and network namespaces. Adding to the confusion, when the kernel supports them, about:sandbox displays entries for "PID namespaces" and "network namespaces" and a green "yes" next to them. But if the kernel doesn't support those features, nothing is displayed, which makes it difficult to diagnose what's wrong with the sandbox.
In case you need to update your kernel configuration, here's where to find the options (using make menuconfig), for your convenience:
General setup --->
-*- Namespaces support --->
[*] PID Namespaces
[*] Network namespace
March 27, 2011
Signing Manifests is easy
There is a discussion about unsigned Manifest commits, and I decided to finally start signing the commits. It was indeed ridiculously easy, and there is even a Manifest Signing Guide.
No separate GPG key is needed, you can (and probably should) just use your developer GPG key.
If you are not sure what value to use for PORTAGE_GPG_KEY, here is an example how to extract it:
$ gpg --list-public-keys
/home/%%%%%/.gnupg/pubring.gpg
---------------------------
pub 1024D/30427902 20%%-%%-%% [expires: 20%%-%%-%%]
uid Pawel Hajdan Jr <%%%@%%%>
Now the value you want in this example is 30427902. They key ID is also present on the roll-call page.
I've put those PORTAGE_GPG_ configuration values just in /etc/make.conf. Here's how it all looks like:
FEATURES="... sign ..."
PORTAGE_GPG_DIR="/home/%%%%%/.gnupg"
PORTAGE_GPG_KEY="30427902"
By the way, if you are using the developer profile (and I'd encourage you to do so), FEATURES="sign" is already enabled there by default.
About 40% of the Manifests in the portage tree are signed. I think this is pretty good, and in fact I was expecting a much lower value before I've seen the stats.
It's really really easy to get this to work. What are you waiting for? Start signing Manifests!
No separate GPG key is needed, you can (and probably should) just use your developer GPG key.
If you are not sure what value to use for PORTAGE_GPG_KEY, here is an example how to extract it:
$ gpg --list-public-keys
/home/%%%%%/.gnupg/pubring.gpg
---------------------------
pub 1024D/30427902 20%%-%%-%% [expires: 20%%-%%-%%]
uid Pawel Hajdan Jr <%%%@%%%>
Now the value you want in this example is 30427902. They key ID is also present on the roll-call page.
I've put those PORTAGE_GPG_ configuration values just in /etc/make.conf. Here's how it all looks like:
FEATURES="... sign ..."
PORTAGE_GPG_DIR="/home/%%%%%/.gnupg"
PORTAGE_GPG_KEY="30427902"
By the way, if you are using the developer profile (and I'd encourage you to do so), FEATURES="sign" is already enabled there by default.
About 40% of the Manifests in the portage tree are signed. I think this is pretty good, and in fact I was expecting a much lower value before I've seen the stats.
It's really really easy to get this to work. What are you waiting for? Start signing Manifests!
March 17, 2011
Unbreaking net-print/foo2zjs
If you happen to be using a printer that requires foo2zjs drivers (or foo2xqx, foo2hp, foo2lava, foo2qpdl, foo2slx, foo2hiperc, foo2oak - they are all part of net-print/foo2zjs package), you may be frustrated about numerous issues with broken digests for Gentoo's foo2zjs package.
Well, I also have a printer that requires one of those drivers, and decided to add a working ebuild to the tree. The upstream changes the tarball in place and requires downloading additional files from the network, so I decided to make a live ebuild. You can see bug #356695 and [gentoo-dev] unbreaking net-print/foo2zjs for the full story.
The end result is that there is a working net-print/foo2zjs solution on Gentoo now. The live ebuild requires one step to enable it:
# echo "=net-print/foo2zjs-99999999 **" >> /etc/portage/package.keywords
Then you should be able to just install it:
# emerge -av net-print/foo2zjs
Enjoy!
Well, I also have a printer that requires one of those drivers, and decided to add a working ebuild to the tree. The upstream changes the tarball in place and requires downloading additional files from the network, so I decided to make a live ebuild. You can see bug #356695 and [gentoo-dev] unbreaking net-print/foo2zjs for the full story.
The end result is that there is a working net-print/foo2zjs solution on Gentoo now. The live ebuild requires one step to enable it:
# echo "=net-print/foo2zjs-99999999 **" >> /etc/portage/package.keywords
Then you should be able to just install it:
# emerge -av net-print/foo2zjs
Enjoy!
Subscribe to:
Posts (Atom)