Log

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-ose-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