Non-obvious, Unannounced Gentoo Update

I’m not too happy the devicekit-power package has become unsupported but still remains in the tree as stable, with not even a word in elog or similar. This package depends on libusb:0, which has some pretty unfortunate bugs, resulting, at least for me, in power management only half working. I praise the developers of GNOME yet again for solid code writing that chugs along and still recognizes my battery and other things despite crashes like this.

It’s pretty easy to update and move on. Simply run emerge -1v upower and portage will handle the transition.

“I like bug 327809”: Let’s make revdep-rebuild obsolete

That’s a quote from solar. I also like this bug. I really like it. I think it’s one of the best bug reports I’ve ever seen.

(First, a disclaimer: I’m not a Gentoo developer, I’ve only just started any kind of serious portage work, and have had quite a few stupid ideas at this point. Take what I have to say with a healthy pinch of salt.)

First of all, here’s the bug link: https://bugs.gentoo.org/327809

Here’s a highlight of what I think makes this bug so impressive, and my comments on it:

Portage Hooks

Now that school is done for the 2009-2010 year, I’m back at it in Neuvoo again. I’m finishing off a long-planned and fairly major addition to portage I call “portage hooks.” The fun thing is I’ve submitted some patches to zmedico and the response has actually been more positive than previous experiences. solar seemed to be (tentatively?) liking the idea as well.

So, here’s what portage hooks are all about. If you have portage-utils installed, you will have an /etc/portage/postsync.d/ directory. Scripts in this directory are executed after portage syncs the tree. I thought this was a great idea, and I thought it should be expanded so there are other opportunities for unofficial extensions.

The Current State of Gentoo

(Edit: Please read my next blog post after or in stead of reading this one.)

Here we are, with working images, and we’ve begun to look into how to better make our images and the contents within more like (and simultaneously more compatible with) official Gentoo. A lot of that has involved us using tools provided by official Gentoo, such as catalyst and eselect. A lot of things, however, cannot be accomplished with plain Gentoo, such as catching portage before it tries to emerge something to make sure the file-system is set up correctly. It took us over half a year to finally “catch up” with Gentoo Embedded and actually reach the limits of what Gentoo provides officially.

Let’s step back a month or so, and go down another path: Gentoo Prefix. This excellent project gives people like me hope for Gentoo where there is none. I installed this to OSX, and I have had all kinds of fun hacking my programs into existence, as I’m sure my readers know from previous posts about Pidgin. In fact, it is because of Prefix that I have begun to scratch the surface of the ebuild world with many a Prefix bug report which often (I think) ended up in an ebuild/patch submission.

My experience with each project has been somewhat different, and somewhat disturbing too. What I have found with both projects, I believe I can trace straight up into Gentoo, and may be what is driving more than a few users and developers away from the once-very-popular distribution. I will attempt to describe what I have found, but please keep in mind that, as authoritative as I may sound, all of what follows is largely my own opinion based on what I’ve seen.

The Secret to Unmasking in Gentoo (and Prefix too)

If you ever dip your toes into Gentoo Prefix, the first thing you’ll probably notice is that a lot of your software is either missing or masked. If you’re sharp, or have lots of experience already with Gentoo, you’ll also notice that your profile comes with the ~ unstable keyword by default. You see, Gentoo Prefix is a pretty small project in comparison to Gentoo itself, as far as I can tell, so not as much testing goes into every package, and not every package can be and/or is currently handled by Gentoo Prefix.

Let’s assume, however, that you really don’t care, like me. Let’s assume you want to try things and out and, like every other good citizen of Linux, you plan on tracking down and reporting every bug you find to the Gentoo/Alt bug tracker. You will most certainly try to emerge something that hasn’t been reasonably stabilized yet, like Pidgin. (I will go into more length on Pidgin later. For now, a summary would be “not for the faint of heart”.) If you’re running an x64 Prefix, just about anything you try to emerge will be keyworded or masked. Not discouraged, you’ll start adding the appropriate entries to your package.keywords and package.unmask directories. After your fifteenth entry, or third round of emerge’s, it gets pretty tedious.