Log

Portage rocks, but occasionally it pokes itself in the eye.  Something I recently had the misfortune of witnessing was that it had somehow put a kink into a package in the local package database when attempting to emerge (in this case re-emerge) it.

The symptom was that it threw an exception that looked like the following:

portage.exception.InvalidAtom: dev-python/-MERGING-docutils:0

The key thing to note there is the '-MERGING-' prefix added to the package name, evidently something that occurs when the emerge is in flight, and which is removed when the emerge finishes/succeeds.  Only for whatever reason, that didn't happen, and the package name became corrupted.

Not intuitively knowing how to fix this, I went to the gentoo forums and was rewarded with the suggestion to simply remove the corrupted entry in the pkg database, which is just a directory hierarchy located in /var/db/pkg.

Thus, in this case, I needed to do the following:

emerge -avt --unmerge dev-python/docutils
rm -rf /var/db/pkg/dev-python/-MERGING-docutils-0.6
emerge -avt1 dev-python/docutils

The unmerge step was just for precautionary purposes, I'm not sure it's strictly required.  As mentioned on that forum thread, care should be taken when doing anything manual in the /var/db/pkg area because that is literally portage's record of what's installed on the system.

At any rate, removal of the buggered directory allowed for successful re-emerging of the package, and I was off and running.

I've not been in the habit of using 'emerge --depclean' very often.  Shame on me.  It's good practice to run it often to clean the cruft off of the system.

But a recent attempt exposed a little problem for anyone who needs or desires to keep multiple versions of slotted packages installed on the system.  Like, say, each of the four different slots of Python (2.4, 2.6, 2.7, 3.1).

So I did this:

emerge -avt --noreplace dev-lang/python:2.4 dev-lang/python:2.6 dev-lang/python:2.7 dev-lang/python:3.1

That nicely inserts those slot atoms into the world profile (/var/lib/portage/world), which ensures that --depclean considers them off-limits.

This technique works for explicit versions as well as slots.  For example, I protected a prior kernel version that I wanted to keep around for a while longer:

emerge -avt --noreplace =sys-kernel/gentoo-sources-2.6.37-r4

That's a little more high maintenance, since when I want that version removed from the system, I'll have to unmerge it explicitly.  Which I guess could be considered a good thing.

At any rate, once I'd protected these, I was free to do the depclean dance:

emerge -uDavt --newuse world
emerge -avt --depclean

This is the first part of a 3-part series (of configuration trivia), wherein I describe how to use kdiff3 in a situation where you need to automatically invoke a graphical diff tool.

This part deals with gentoo's etc-update tool, which is used to reconcile changes made by portage to various configuration files (typically located in /etc, hence the name).

etc-update defers to /etc/etc-update.conf for some of its behavioral configuration, including the manner in which it invokes a diff tool.

So to use kdiff3, just edit /etc/etc-update.conf to include the following:

pager=""
using_editor=1
diff_command="sudo kdiff3 %file1 %file2"
merge_command="sudo kdiff3 --merge --output %merged %orig %new"

Be sure to also comment out (with a leading '#') any existing line that has one of the keywords listed in the above assignments.

And that's it!

Note that the 'sudo' part is necessary because kdiff3 is subject to some kind of KDE policy that protects against root use of GUI apps.  Or something... I never quite found a straight answer, but I know it won't launch if you're root without using sudo.

Apparently Gentoo recently enabled a per-package license approval feature for portage.  As with most things Gentoo, the feature was discovered unceremoniously when I tried to do 'emerge -uDavt world' and it complained loudly in new and confusing ways.  But a quick investigation shed light on the issue, and I set about making the small changes necessary to become compliant.

Basically, Gentoo now maintains a (comprehensive) list of licenses with which any given portage package might be associated.  And portage treats the licenses as opt-in, meaning that it doesn't presume that you're willing to accept them.  Also, just like use flags, there is an emerge variable (ACCEPT_LICENSE) that can be set for all packages in make.conf.  It defaults to '* -@EULA', which means all licenses are accepted automatically except any within the 'EULA' group.  A full list of licenses and groups is available in /usr/portage/profiles/license_groups.  Overrides to this variable can be made on a per-package basis using a dedicated file: /etc/portage/package.license.

I elected to leave ACCEPT_LICENSE at its default, and use the package.license file to individually manage non-free licenses.  Thus I needed to create a package.license file with the following contents:

dev-java/sun-jdk dlj-1.1
app-emulation/virtualbox-additions PUEL
net-im/skype skype-eula

Obviously, those were only necessary because I have (or want to have) those packages installed.  Your package.license file might contain completely different entries.  With those exceptions in place, emerge went on its merry way and so did I.  Note that this process doesn't alleviate the need to say 'yes' to certain package licensing verbage at emerge-time. 

Unrelatedly, as of 20100131, the gentoo overlords have removed libGL.la, saying thus:

Eselect-opengl package now strips the libGL.la file. This file was broken and
thus we proceeded with its removal. It brings slight inconvenience on you fellow
users. After emerging the new version =app-admin/eselect-opengl-1.1.1-r2 please
emerge one more package dev-util/lafilefixer and use it for fixing all various
compilation issues by running as root:
# lafilefixer --justfixit
Note that not-running this command will bring you compilation issues so you
should really pay attention to this message and act upon it.

Oh, act upon it I did.  By taking precisely the suggested actions.

Finally fed up with the awful RAM consumption of the firefox 3.0.* branch, I decided to roll up my sleeves and convert to the Amazing New Wonderfabutastical 3.5 branch.

But it's not marked stable yet on gentoo, so I had to get out the ~x86 divining rod and navigate through the minefield of getting a major package and all its dependencies unmasked.

Here, for your viewing pleasure, is the result of that exercise.

/etc/portage/package.use:

media-video/vlc -nsplugin
app-office/openoffice -nsplugin

/etc/portage/package.keywords:

www-client/mozilla-firefox ~x86
x11-libs/cairo ~x86
net-libs/xulrunner ~x86
dev-libs/nspr ~x86
dev-libs/nss ~x86

/etc/portage/package.unmask:

>=www-client/mozilla-firefox-3.5
>=net-libs/xulrunner-1.9.1
>=dev-libs/nspr-4.8
>=dev-libs/nss-3.12.3

Given all of that, a mere 'emerge -uDavt mozilla-firefox' should dutifully install the new browsing nirvana on your system.  At least, it did for me.

And, at least thus far, I'm thrilled.  Firefox runs leaner and meaner and nearly all of my plugins remained usable.

This is all transient minutia, since I imagine it'll only be a few more months perhaps before all of this percolates into the stable tree.

Oops -- apparently a well-known ~x86 dependency 'bug' was allowed to surface in stable gentoo.

Here's a forum post and a bug report.

Here's the recipe I used to get around the recent shenanigans associated with e2fsprogs-libs going stable.

1. emerge -uDavft world

• That ensures that the packages are pre-fetched,which is critical to this recipe working.  The unmerge that happens below temporarily eliminates the ability to fetch portage packages.
  

2. emerge -avt1 --nodeps e2fsprogs-libs

3. emerge -avt --unmerge com_err ss

4. emerge -avt1 --nodeps e2fsprogs-libs

5. emerge -avt1 --nodeps e2fsprogs

6. emerge -avt1 --nodeps mit-krb5

7. emerge -avt1 --nodeps e2fsprogs-libs

8. emerge -avt1 --nodeps e2fsprogs

9. revdep-rebuild -v

Then world updates can proceed, or whatever else you planned on doing.

For reasons that I'm sure involve lawyers, VirtualBox OSE requires some human intervention to correctly install.  The 'additions' iso is flagged as unfetchable by emerge, so it must be downloaded manually and put into /usr/portage/distfiles.

http://download.virtualbox.org/virtualbox/1.6.6/VBoxGuestAdditions_1.6.6.iso

Obviously, '1.6.6' should be changed to the version du jour.

Once you've moved it to /usr/portage/distfiles, be sure to correct the file settings:

• chown portage:portage /usr/portage/distfiles/VBoxGuestAdditions_1.6.6.iso

• chmod 664 /usr/portage/distfiles/VBoxGuestAdditions_1.6.6.iso

The issue only manifests if you've got the 'additions' use flag enabled for app-emulation/virtualbox-ose, which you probably do because it's neato.

Apparently some of my video cards are now officially decrepit.  A recent world emerge broke X for me because my two nvidia geforce FX5500 cards are now on nvidia's 'legacy' list, and no longer supported by the latest (or future) drivers.  It's nothing a quick edit to /etc/portage/package.mask didn't fix:

>=x11-drivers/nvidia-drivers-177.0.0

Then the following steps got me back up and running:

• emerge -avt nvidia-drivers

• update-modules