fidzu : Gentoo

In >=portage-2.2_rc2 there are a few new emerge options that many Gentoo users will probably be interested in:

--jobs JOBS
        Specifies the number of packages to build simultaneously.
        Also see the related --load-average option.

--keep-going
        Continue as much as possible after an error. When an error
        occurs, dependencies are recalculated for remaining packages
        and any with unsatisfied dependencies are automatically
        dropped. Also see the related --skipfirst option.

--load-average LOAD
        Specifies that no new builds should be started if there are
        other builds running and the load average is at least LOAD (a
        floating-point number). This option is recommended for use in
        combination with --jobs in order to avoid excess load. See
        make(1) for information about analogous options that should
        be configured via MAKEOPTS in make.conf(5).

Here is some sample parallel build output from a catalyst stage2 build, with emerge's new --jobs option enabled:

>>> Building (1 of 10) sys-devel/gettext-0.17 for /
>>> Building (2 of 10) sys-libs/zlib-1.2.3-r1 for /
>>> Building (3 of 10) virtual/libintl-0 for /
>>> Building (4 of 10) dev-util/unifdef-1.20 for /
>>> Installing virtual/libintl-0 to /
>>> Installing dev-util/unifdef-1.20 to /
>>> Building (5 of 10) sys-kernel/linux-headers-2.6.23-r3 for /
>>> Installing sys-libs/zlib-1.2.3-r1 to /
>>> Jobs: 3 of 10 complete, 2 running               Load avg: 3.44, 1.46, 0.69

23 Jul 2008 10:57pm GMT

OpenSSH 5.1 is out, and besides a Security issue that does not affect Linux or the BSDs, it includes a new feature labelled VisualHostKey, aka SSH Fingerprint ASCII Visualisation. Using an idea proposed in the 1999 paper Hash visualization: A new technique to improve real-world security by Perrig and Song, an image with 18×9 resolution is generated from the fingerprint of the SSH server, and is displayed to the client.

Since the feature is experimental, and the algorithm to generate the image should not be considered final yet, display is disabled by default. You can see a test-run in the screen capture, and a (just for fun) list of images of my known hosts. I wonder how long it takes to remember that face… doesn't it look like bit like Marge Simpson?

Now why all this, you are asking?

It is deemed that images are easier to compare and remember than the usual 32 hex digits, and I believe everyone has to judge by him/herself if that is true. How many of those SSH/OTR/SSL… fingerprint digits do you check*? All of them? Any, at all? Where did you derive your latest Firefox SSL CA certificates from? At a time where I cannot trust my provider to run a secure DNS server, verifying the authenticity of either the other side of communication, or the data in transit is most crucial. Let's finally get that Tree Signing going!

* If you only check the first 4 digits, and the last 2 - you are riding on a 24 bit fingerprint.

23 Jul 2008 2:56am GMT

After my previous post about preserved-libs feature, I was asked by many users if I was against this feature because it incremented the usability of Gentoo. I sincerely think I shown before that I don't want Gentoo to remain for elitists, and thus I won't be going to say nay to anything to make stuff easier to the users.

On the other hand, I want to make sure that users, excited about being able to upgrade stuff without breaking their system, won't break it even further. For this reason I want to warn again users against trying the unstable Portage version (2.2) on their stable systems just yet.

Thanks to Zac and Marius, the problem I'm going to talk about is already being taken care of, so it won't appear once 2.2 final will arrive. So why am I writing about this anyway? Well the reason is actually quite simple: future memory.

On the topic of linking, loaders, ELF files and all the things related, there isn't a lot of documentation that is available to newcomers. Most of it is very technical and requires good knowledge of many concepts to be useful. I only know of a book that goes in deep of this, Rob Levine's Linkers and Loaders is probably the most interesting reading on the subject ,as far as I can see. Unfortunately I haven't tried converting the downloadable version in LRF to load it on the EBook Reader and I haven't got the printed copy. I should probably get that too, as a reference, I'm just afraid that all the hardcopies I have here will remain at my parents' house once I move out.

Okay, let's return back on topic now. What is the problem I found today with preserved-libs? Well as I updated to Xorg 1.5 pre-releases to check if my RandR problems were fixed (by the way, they are), there was a libGL update. I also took the time to switch back to gcc 4.2 for a short time as I wanted to rebuild VirtualBox without ALSA support (whenever I can I'm using PulseAudio), and I could also rebuild xmlrpc-c (the reason why I couldn't build this with GCC 4.3 is good for a different entry one day). After these builds, Portage told me this:

!!! existing preserved libs:
>>> package: media-libs/mesa-7.1_rc3
 *  - /usr/lib64/libGLU.so.1.3
 *  - /usr/lib64/libGLU.so.1.3.070003
>>> package: dev-libs/xmlrpc-c-1.06.27
 *  - /usr/lib64/libxmlrpc.so.3.6.4

I was surprised because I know libGLU rarely changes interface, and I didn't think xmlrpc-c would have either. And indeed a quick scanelf run over the files confirmed my ideas:

flame@enterprise ~ % scanelf -S /usr/lib64/libGLU.so*
 TYPE   SONAME FILE 
ET_DYN libGLU.so.1 /usr/lib64/libGLU.so 
ET_DYN libGLU.so.1 /usr/lib64/libGLU.so.1 
ET_DYN libGLU.so.1 /usr/lib64/libGLU.so.1.3 
ET_DYN libGLU.so.1 /usr/lib64/libGLU.so.1.3.070003 
ET_DYN libGLU.so.1 /usr/lib64/libGLU.so.1.3.070100 
flame@enterprise ~ % scanelf -S /usr/lib64/libxmlrpc.so*
 TYPE   SONAME FILE 
ET_DYN libxmlrpc.so.3 /usr/lib64/libxmlrpc.so 
ET_DYN libxmlrpc.so.3 /usr/lib64/libxmlrpc.so.3 
ET_DYN libxmlrpc.so.3 /usr/lib64/libxmlrpc.so.3.6.15 
ET_DYN libxmlrpc.so.3 /usr/lib64/libxmlrpc.so.3.6.4 

As you can see the soname for both the versions of libGLU and both the versions of libxmlrpc is the same. So there is no ABI break, and no good reason for the file to disappear, right?

Indeed if we focus solely on the xmlrpc-c case, the result of preserved-libs actions is that there is now an orphaned unused and unusable shared object:

flame@enterprise ~ % ls -l /usr/lib64/libxmlrpc.so*    
lrwxrwxrwx 1 root root    19 2008-07-22 18:04 /usr/lib64/libxmlrpc.so -> libxmlrpc.so.3.6.15
lrwxrwxrwx 1 root root    19 2008-07-22 18:04 /usr/lib64/libxmlrpc.so.3 -> libxmlrpc.so.3.6.15
-rwxr-xr-x 1 root root 56864 2008-07-22 18:04 /usr/lib64/libxmlrpc.so.3.6.15
-rwxr-xr-x 1 root root 56368 2008-02-23 13:36 /usr/lib64/libxmlrpc.so.3.6.4

Let's see, ld.so (the runtime linker) will look for a library with, as filename, the soname listed in a program's NEEDED entry in the dynamic seciton of the ELF file. In this case, the soname of libxmlrpc is libxmlrpc.so.3 so that's what the linker will look for. On my system, that filename is linked to the 3.6.15 version, so the runtime linker will always load the new version of libxmlrpc. The build-time linker (ld) looks instead for the filename with the simple .so prefix (or .a for static libraries). That one is also pointing to 3.6.15.

So who is using the 3.6.4 version that Portage preserved? Well, the only way to use it is to dlopen() it directly and accessing it that way. Which, if anything would be doing that, would be craziness, to the point that I'd rather not see such a software in my system at all. The other option is for an ELF file to have a tweaked NEEDED entry that points explicitly to the full version, but I can tell you I have none of those.

So for now I'll simply remove the two files, and get rid of the problem. But as you can see, it's too soon to expect preserve-libs to work out of the box in a perfect manner.

Anyway, Marius, Zac, please keep up with the good work, it's really needed :) Thanks guys!

22 Jul 2008 5:45pm GMT

Since starting at One Laptop per Child I have been doing some distro work on the OS platform for the XO laptop. The platform is based on Fedora 7 and I have been working on rebasing us onto Fedora 9 for the next release.

Having very little distribution experience outside of developing Gentoo for the last few years, I've found some aspects of Fedora's binary package (RPM) workflow particularly interesting:

1. Automatically detected dependencies: In Gentoo ebuilds, we have to state that package A depends on library B. In Fedora, when building the binary package, the build tools determine many runtime dependencies automatically so there is no need for developers to manually list all dependencies in spec files.
2. Chroot build environments: All packages are built in an otherwise-empty chroot. The build system creates a chroot, quickly installs all of the base binary packages and the build dependencies, then builds/installs a package, produces a package, and throws the chroot away. This allows for predictable build environments and is good for QA.
3. Community access to the build box: All packages are built by Koji. Koji has a nice "scratch-build" system where you can throw a source RPM at it, and it will build it and serve it back to you on a webpage a few minutes later. Great for build testing and handy if you don't have a complete build environment locally. The scratch-build service is open to non-developers assuming they have been through the click-through contributor agreement.
4. Subpackages: It's pretty neat how one spec file (equivalent to an ebuild in some ways - textual build scripts) can actually produce several packages. Your spec file takes one upstream tarball, unpacks/compiles/installs it, and then specifies which of the installed files belong to which subpackage.

Naturally, there are some drawbacks too:

1. Build dependencies: Even though many runtime dependencies are automatically detected, you still need to specify the components required for compilation. Remember, each package is built in a clean chroot. You end up having to specify most of the dependencies anyway (although it is still convenient in that you do not have to specify which subpackage has which dependencies - that is determined automatically).
2. No build customisation: OLPC have to fork a few packages which have wacky dependency chains, just to disable support for a certain feature or whatever. Forking away from upstream is undesirable but sometimes necessary. For example, we had to disable libgnome support in GNOME's Python bindings to avoid libgnome being pulled into the build. libgnome was pulling in the following packages: audiofile bluecurve-icon-theme control-center-filesystem esound-libs fedora-gnome-theme fedora-icon-theme fedora-logos gail gnome-icon-theme gnome-keyring gnome-themes gtk-nodoka-engine libart_lgpl libbonoboui libgnomecanvas libgnomeui libutempter metacity nodoka-metacity-theme pyorbit. Ouch.
3. Convolution/confusion of build tools: To build a package, you can use rpmbuild to do it on your live system, or you can use mock to do the clean chroot thing I described above. Or you can use koji's command-line client to upload it to koji. Not everything can be done through koji/mock, e.g. you still need to use rpmbuild to build OLPC's kernel. Also, rpmbuild is the only tool that can build a source RPM, I think.

I've also been impressed by the Fedora development community. The community recently made the realisation that OLPC is Fedora's biggest deployment (over 400,000 XO laptops worldwide, 55,000 more built and distributed each month, 100% of them running Fedora). Greg Dekoenigsberg recently announced the Fedora OLPC special interest group which sounds promising.

22 Jul 2008 2:37pm GMT

For those of you who'd like to follow Google Summer of Code progress (I'd very much like to have the blogs of the student available on Universe by the way), today (or rather yesterday) can be counted in as a very important date :)

Seraphim prepared a patch for shadow (the package containing all the basic utilities for users management in Linux) to work with OpenPAM, rather than depending strictly on Linux-PAM. I committed it in tree now for 4.1.2.1 and upstream applied it to trunk already, so now it can be built even when using OpenPAM rather than Linux-PAM. Cool, eh?

This patch (and the related bug) are important not only because they fix a very important part of the functionality of a Linux system with OpenPAM, but also because it will act as a base reference to fix other software to use OpenPAM too.

Indeed, one of the most obnoxious problems with OpenPAM is that a lot of packages instead of writing their own conversation functions rely on misc_conv. Seraphim prepared a patch that can be applied to almost any other package relying on that to make it OpenPAM-compatible. It's very good.

Unfortunately, as Seraphim also blogged there is one catch with being able to provide OpenPAM support, especially for the future. The problem is that although mostly API compatible, OpenPAM and Linux-PAM are not ABI compatible. Although in a very subtle way, because, as Seraphim learnt, you can have a system built against Linux-PAM run against OpenPAM just fine, up to a point.

The problem is that ABI does not only refer to the name of the functions, or the type of their parameters, but also to the meaning of flag values. In this case, Linux-PAM and OpenPAM give different flags different meanings, so modules built against OpenPAM will not work properly with software built against Linux-PAM.

This is going to be tricky, especially once we'll allow users to switch from one to the other and vice-versa, because it means all the software will have to be rebuilt to continue functioning as it's supposed to. And no preserved-rebuild will help us there.

Oh well, there's time to think of that!

22 Jul 2008 2:24pm GMT

With my move to Gnome I decided to try out again the graphical login. I used to use standard console login before because KDM lacked too many features, and while for some time I kept using GDM, it just didn't feel right. Unless I was going to just do some system administration, or testing PAM, the only command I was going to type was startx, followed by sudo shutdown -h once I was done.

To do so, I had to give up keychain, at least for inserting the private key's passphrase. Instead of using that, I decided to change my PAM setup to use pam_ssh (and this is also what brought me to plan removal of pam_ssh_agent .. I just remembered I forgot to add that to the Gentoo Calendar!-done!), so that instead of typing my password and my SSH key passphrase, I just have to type in my passphrase at login and I'm done. The nice thing is that the standard Unix password is also accepted, so I can use that to take me out of the lock screen that Gnome applies when I walk away from the system, which is much shorter.

Again, I will probably put up a request for an electronic ID card next september and consider using a smartcard reader (I I wonder if I can use old, invalid, credit cards as smartcards too, once they are formatted).

So okay, I'll write at another time about pam_ssh, it's not what I'd like to write about right now.

With GDM I'm having one problem: my current setup is a dualhead, with a 16:10 monitor (and a 4:3) and using XRandR 1.2 (radeon driver). I have the screen disposition set up in my xorg.conf, but I'm not able to set the proper mode for the 16:10 monitor in the configuration file. If I set PreferredMode in xorg.conf, X11 refuses to start, without any apparent error either.

So for now I'm running at the session manager level two xrandr commands to set up properly the screens, but there is one problem: synergys does not seem to be expecting the geometry of the screens to change, so it still wraps my pointer out on the coordinates where it should have wrapped before the xrandr fixes.

I should probably see to try the latest masked version of xorg, and check if it works there. Although I think Synergy should have considered the case of changing screen layout. Maybe one day it will be rewritten using XCB and it will consider that problem too ;)

Oh yeah I should be writing about XCB too…

21 Jul 2008 4:00pm GMT

As it turns out, I start to dislike the way the KDE project is proceeding, and I don't refer to the Gentoo KDE project, but to the whole of KDE project.

I dislike the way KDE 4 is being developed, with a focus on eyecandy rather than on features. This is easily shown by the Oxygen style; not only it is taking up a amount of screen real estate for widgets that remind me of Keramik (and if you remember, one thing that made happy a huge amount of users was the switch from Keramik to Plastik as default style in KDE 3.3), but it's also tremendously slow. And I'm sure of this, it's not just an impression: as soon as I switch Qt to use Oxygen, it takes five seconds for Quassel to draw the list of buffers; once I use QtCurve, it takes just one second. I don't know if this is because Enterprise is using XAA and not EXA, but it certainly doesn't look like something that the default theme should do.

And no, I'm not expected to use a computer that has less than an year, with a hyper-strength gaming videocard to be able to use KDE.

But this is just one of the issues I have with KDE recently. There are some policies I really, really, dislike in KDE. The first is one I already mentioned quite often and it's the move to CMake. The only "good" reason to move to CMake is to be able to build under Windows using Microsoft's Visual C++ compiler; yet instead of just saying "we needed cmake because it's necessary to build for Windows" I see so many devs saying "cmake is just better than everything else out there". Bullshit.

The other policy that I dislike regards the way KDE is developed and released as a single, huge, monolithic thing. One of the things that made KDE difficult to package in Gentoo (and other source-based distributions) was the fact that by default the source has to be built in those huge amorphous packages. And if the autotools-based build system of KDE sucked so much, it was also because of that.

But even if we leave alone the way the releases are made, it's just not possible for everything to fall into a single release cycle kind of thing. There are projects that are more mature and projects that are less. Forcing all of them in a single release cycle makes it difficult to provide timely bugfixes for the mature projects, and makes it impossible for the not-so-mature projects to be tested incrementally. The last straw I could bear to see because of this stupid way of releasing, was knowing that Konversation in KDE 4 will probably lose the IRC-over-SSL support because KSSL was removed from the base libraries.

And now KDE 4.1 is on the verge of release, and Kopete still segfaults once you connect to Jabber. Yet when I tried (multiple times) to gather information about the possible cause in #kopete (so I could at least try to debug it myself), I had no feedback at all; maybe it's because I run Gentoo, although the same happens on (K)Ubuntu. Yeah not the kind of people I like to deal with.

I'm not saying that I think Gnome is perfect for policies and other things. I dislike the fact that it's always more Linux-/Solaris-centric than cross-platform centric; but I think KDE4 was a set back for that too, for what I read. And their release method does look a lot more sane.

I started using Linux with KDE 2. I moved to Gnome once KDE 3 was being taken care of. I came back to KDE just a bit before 3.3 release. Now I'm going to try Gnome for a while, and if I like it, I'll think more than twice before going back to KDE. Yeah sure I liked KDE 3 better than I liked Gnome before that, but it's just not feasible that I have to switch DE every time they want to make a new release.

Besides, since I last used it, Gnome seems much more mature and nicer to deal with.

20 Jul 2008 3:57pm GMT

- In 2006, I went to MySQL UC, and OSCON.
- In 2007, I went to the Vancouver PHP conference and LWE-SF.
- For 2008, I went to MySQL UC, and I'm going to be at OLS2008 in Ottawa next week, July 21st thru 27th.1

I'll have the entire Sunday free in Ottawa (my flight home is in the evening, and the conference itself ends up Saturday). Anybody that wants to hang out, that would be cool, or sight-seeing.

Additionally, if you're interested in PGP keysigning, or CACert assurances, you should seek me out with some ID. This applies doubly to all Gentoo developers with the upcoming tree-signing work.

While I'm not going to OSCON since it conflicts with OLS, my friend Zak Greant (really I mean it, he lives just up the street from me!) is going to OSCON, and putting on a totally free mini-conference within it: FOSSCoach. If you're just trying to get a start in open source from a beginner's perspective, and would like to be more than just a user, it should be worth checking out. (I meant to hype it a while ago, but was too busy).

19 Jul 2008 9:00pm GMT

Following Donnie's "Early coverage of Gentoo 2008.0" here's a list of German news items on our latest release.

• Golem
• Linux Magazin
• Der Standard
• Heise
• TecChannel
• OSZine

18 Jul 2008 7:09pm GMT

I started using iSCSI a few months ago to be able to extend the capacity of my Windows XP virtual machine and Bootcamp with a shared partition. Using a partition on real hardware on the external Hard Drive was not an option as Parallels broke my Bootcamp more than once, and that is tremendously annoying. After that I started using it to share the external HD I bought for the laptop, so that it's accessible from any place in my house, albeit slowly because it's accessed through wireless.

Unfortunately the road for iSCSI target support on Linux ain't exactly bump free. Updating to glibc 2.8 broke the userland tools of iscsitarget, and it took me a fair day to find a way to fix those. With the latest update to Linux 2.6.26, instead, it was the kernel module to (obviously) break.

This time the subversion repository of iscsitarget was updated already, so I decided to just take a snapshot of the repository, so I could get the actual fix from upstream for the glibc 2.8 issue and the fixes for the new kernel. I suppose I could start maintaining iscsitarget myself now ;) Thanks to Nataniel Copa the snapshot also provides a POSIX-compatible init script, which should make it possible to use it with OpenRC and dash. And guess what my alternatives idea would also make easy to do?

Okay so, the problem with the kernel module has been resolved, everything's fine then? I wish.

The other problem I'm having now is related to another module that failed to build: madwifi-ng. Enterprise is currently connected to the main router through WiFi, using an Atheros 5K-based card (it's a D-Link card). Now, as madwifi failed to build, I checked the kernel to see whether there was already an alternative in-kernel official driver for this card, and it turns out there is one, Ath5k, that seemed promising. It uses the mac80211 framework and does support my chipset. Cool.

Unfortunately after enabling it (and having it working fine at the first glance) it started disconnecting immediately, causing the connection to stall, and requiring a few restarts. After a few tries I can tell for sure that the problem is related to iSCSI. As soon as Time Machine on the Mac starts to kick in (it works on the iSCSI disk), the connection is lost:

wlan0: Initial auth_alg=0
wlan0: authenticate with AP 00:14:7c:ba:a7:2e
wlan0: association frame received from 00:14:7c:ba:a7:2e, but not in associate state - ignored
wlan0: RX authentication from 00:14:7c:ba:a7:2e (alg=0 transaction=2 status=0)
wlan0: authenticated
wlan0: associate with AP 00:14:7c:ba:a7:2e
wlan0: RX AssocResp from 00:14:7c:ba:a7:2e (capab=0x461 status=0 aid=2)
wlan0: associated
wlan0: switched to short barker preamble (BSSID=00:14:7c:ba:a7:2e)
wlan0: No ProbeResp from current AP 00:14:7c:ba:a7:2e - assume out of range
wlan0: Initial auth_alg=0
wlan0: authenticate with AP 00:14:7c:ba:a7:2e
wlan0: RX authentication from 00:14:7c:ba:a7:2e (alg=0 transaction=2 status=0)
wlan0: authenticated
wlan0: associate with AP 00:14:7c:ba:a7:2e
wlan0: RX ReassocResp from 00:14:7c:ba:a7:2e (capab=0x461 status=0 aid=2)
wlan0: associated
wlan0: switched to short barker preamble (BSSID=00:14:7c:ba:a7:2e)

For now I resolved connecting the laptop to Enterprise through the Gigabit interface, so that the iSCSI traffic does not pass through wlan0.

I'll be going out with some friends in less than an hour, so the problem will have to wait till Monday (tomorrow I have friends coming over, and I have different plans for Sunday if I can avoid fixing this for now).

I'm not sure if I should be switching back to madwifi-ng (from SVN unless they release a new version to fix 2.6.26) or if I should report the problem to the kernel developers to see it fixed.

On different notes, yet still related to the kernel, I decided to make some changes to my configuration of the kernel with this release. I switched from the old "good" VesaFB to UVesaFB, even though I didn't want to use an initramfs image, it works fine and it finally let me see the console decently on my 16:10 monitor (I start to wish I could have two of these rather than one being a 4:3 still… they come useful to have double windows in Emacs with source and header). I also removed the V4L subsystem and the support for BTTV as I removed the TV card from Enterprise, after hmmm more than five years of almost uninterrupted service; I'm using satellite (Sky Italia) in my room nowadays, so I don't need the card here, I don't even have the aerial connection in my office anymore.

I want to check if I'm building and loading stupid stuff. I found myself with the nvram driver enabled, yet not loaded at all, I wonder why I had it on at all. I obviously cannot remove the FireWire subsystem (the external HD I talked about before is using FireWire). I hate to have two SATA controllers enabled too, with two different drivers. I hope that, once I get a new box, all four the drives will stay on a single AHCI-enabled controller. I have two ethernet drivers too, the e1000 I use for iSCSI and the skge for the testing/development rig; and two soundcards, the integrated VIA82XX that right now I'm not using at all, and the ICE1712 I actually use. I haven't disabled the VIA because I'd liek to use that for Skype once I get some decent headphones/mic set.

So anyway, I'll better get going or I'll be late again. What happened to me? I was never late before, I've started being quite late in the last weeks..

18 Jul 2008 4:27pm GMT

Here some ideas about alternatives and gentoo possible alternative implementation (refer to Diego's post):

- implemented as an eselect module, possibly with an alternatives interface for those who like it
- will work just on executables you directly run
- it will be backed by an eclass to handle post-inst/post-uninst (registration and removal to the alternatives list)
- it will use the environment, a separate config dir, a C wrapper [pick one or all]
- the wrapper will check his argv[0], look at the config dir for the string to call and run it.

Probably even those 5 lines have conceptual bugs but I guess that's enough for a draft.

lu

18 Jul 2008 2:54am GMT

So, after writing about it I decided to take a look at the actual code of alternatives from Fedora.

The nice thing is that the alternatives code is well tested to work properly. The bad things are that it's a bit of a silly thing to download a source rpm for a single source file and a man page, and that it's not exactly userfriendly.

The first problem I can find is that it's not abstracting much, the basic interface would be asking for this:

# alternatives --set tar /bin/bsdtar

It's not very nice to have to provide the actual symlink.

Okay, so did I waste time? Nope I don't think so. Although alternatives has a nasty interface in my opinion, it has a lot of qualities: it's well tested, it has been designed quite a long time ago, and thus problems were already identified and (hopefully) resolved.

So as Luca said, we need to smooth the wheel a bit.

I think the nastiest problem I have now is with the way alternatives data is written to the library directory. If there is a program that can be invoked by bash to edit configuration files (INI-style), that would be a huge advantage.

In general, what alternatives doesn't provide that we need is:

• full support for $ROOT; as it is alternatives allows you to update the directory data on $ROOT, but it will still change the symlinks in /;
• a way to automatically handle man pages compressed with different algorithms (none, gz, bz2, lzma);
• a nicer user interface, that allows you to just have eselect alternative tar bsdtar instead.

At least, now that I know how RedHat does it, I can shape our tool on the basis of this. Hopefully in a few months we'll have virtual/tar in system rather than app-arch/tar, which would then allow who wanted to, to replace GNU tar and GNU cpio with libarchive's bsdtar and bsdcpio.

On a different note, I don't like the way RedHat handles the choice of editor: they create a /usr/bin/editor symlink to be used. While I admit this solves the issue like the one with fcron about telling the software being built which tool to use, it doesn't solve it entirely. For instance, I have as EDITOR value emacsclient -c. I wouldn't be able to express that with the alternatives approach that RedHat uses.

So yeah not always the code that comes from others is good as it is, but often enough it's a basis to implement something new.

17 Jul 2008 9:06pm GMT

I already maintain, in the tree, an ebuild for the Nimbus GTK+ Engine, that is used by Sun Microsystems on OpenSolaris and Solaris Express. I liek it, it's quite nice and it was a pleasure to package as it worked almost out of the box (I had to patch a few things but it's fine now).

Today I looked at the JDS directory where Sun keep the sources of the pieces of code the use on their modified Gnome environment, for the only reason to find something that might be useful to import in Gentoo.

There are a few things I could probably package in my overlay for the sake of it (Sun's backgrounds and GDM themes-we have RedHat's and Mandrake's artwork packages after all), but my attention was caught by an "ospm" package, which seems to provide an interface to the status of printers.

One thing I love of Free Software is that you can make use of software that has been developed by someone else from a different target without problems. Unfortunately this was not the case. While I hoped for something that could be usable under Linux, ospm itself has a few Solaris dependencies too many (that's why it's called the OpenSolaris Printing Manager, I suppose).

Anyway, this made me think of a couple more issues. I have said before I'd like some eselect tool that could allow to switch different tools on a Gentoo system without having to write one module each, for instance for tar (so that one could choose between libarchive's bsdtar and GNU tar), or whois clients.

Debian already has a software called "alternatives" that does that. I wondered before if it's possible to import that one in Gentoo and make use of that, rather than reinventing the wheel again… but as far as I know it's tightly related to Debian's dpkg (just like eselect is unlikely to be ever used outside Gentoo).

More interesting instead is the fact that Cygwin ships with an "alternatives" package, that is not based on the one from Debian, but rather from the one in Fedora (chkconfig package). We already do import a few things from Fedora and RedHat, and I know Donnie did package a few more things from them before. I really should try that out and see if it works. It certainly makes sense not to have to worry about reinventing the wheel once again if somebody did so again, even if it breaks the "Gentoo way" of using eselect (but one could implement an eselect plugin over alternatives of course).

So to keep it short to have time to do some work, I'll certainly look to see if, rather than having to invent something new, we can reuse something that fellows developers developed and tried already.

17 Jul 2008 5:46pm GMT

Since things are finally starting to settle down (hey, I've had Internet for a week now, cool), I've started getting back to poking at stuff, slowly. Today I cleaned up some mplayer and transcode stuff in the portage tree, and I just thought I'd mention what's new.

First of all, mplayer. The latest revision is 1.0_rc2_p27120. The snapshot itself is about a month old, and I don't know of anything particularly major that's in there (I haven't had time to follow development for the past month anyway). It's been masked for testing, not because upstream has done anything funky, but because there are some new use flags, which have helped me to go back and clean up some stuff that I should have done a long time ago. I haven't heard a peep from anyone on bugzilla so either no one's tried it, or it works great.

The big changes that I can think of off the top of my head are this: first of all, there's an ewarn added if you enable the cpudetection flag. It finally dawned on me that this one might not make sense. Here's what it *doesn't* do - magically make the build detect and build for your CPU architecture. The build system already automatically detects and installs with the correct instruction set by default, using stuff like MMX, SSE, and friends. The only reason (that I can think of) that you would use that, is if you were deploying the binary package on another computer, since it is a runtime feature, not a buildtime one. So, you'll get a little warning if you enable it, because, in general, desktop users don't need it. I also fixed the use.local.desc to be a bit more specific as well.

Secondly, there's a new use flag: custom-cpuopts which should finally solve the long-standing dance of trying to outwit users who always break their system but still allow real tweakers to do exactly what they want. Here's how it works. MPlayer's build system, again, by default, will automatically detect the CPU optimizations that are supportd for your platform (MMX, SSE, again, etc.). That means that, again, if you leave everything by default - it should work fine.

Originally the problem we would have is that people would have their CPU optimization use flags turned off (like mmx), which would normally break the build. The ebuild is written to only disable them if they are turned off, so my solution for a long time was to tell people to just turn them all on and let MPlayer *not* disable them, therefore, revert back to autodetection. This would then cause problems, though, for those few who were building MPlayer for some other box, and they wanted specific CPU opts on or off. This use flag will fix just that.

What custom-cpuopts will do, when enabled, is forcibly enable or disable the actual CPU optimization use flags you set. This will help out those on certain profiles and setups who need to tweak their build for whatever reason. For normal desktop users, you don't need to enable it - if it's turned off, the ebuild will completely ignore the other use flags (for CPU optimizations) and just use the default checks … which work great. It also means that your build will be optimized the best it can, yay!

I know I really went into depth on that one, but it's been an issue with the build and users for a long time and I'm glad I finally got a cleaner solution working. Now everyone has the options to do whatever they want, but by default, everything should build and be optimized wonderfully.

Oh yes, one last thing - if someone wants to fix bug 228799, and submit a patch upstream, I'd be extremely grateful. That would clean up the LINGUAS hack in our ebuild, which I've heard breaks on paludis anyway.

As far as transcode - I've been out of the loop, and the media-video team has been taking things over and cleaning up (I don't even know who, sorry guys, haven't taken the time to look into that either - I know loki_val fixed up some imagemagick / ffmpeg dep crap that I didn't want to touch, thanks man!). 1.0.5 is back in the tree, and should be the next stable candidate. I also added another rc for 1.0.6, and I have to add the 1.10 beta sometime.

That's about it for now. Have fun. Go break your box.

17 Jul 2008 4:28pm GMT

Here's links to a few places that posted announcements for 2008.0. Go there and get involved by voting and commenting!

• Slashdot
• Digg

Gentoo 2008.0 makes the Digg frontpage

• Reddit
• DistroWatch (original announcement)
  
• LWN.net
• TuxMachines
• Phoronix
• OSNews
• OStatic
• Heise
• Linux Format
• Clubic (Warning: French. English translation)
• FOSSWire
• DesktopLinux.com
• Linux Magazine (UK)
• InternetNews.com - The only one to do any real reporting & interviewing
  
• Open Source Pixels
• Techgage
• LinuxNews.pl (English translation)
• Programas Livres (Warning: Portuguese. English translation)
• Linux Journal
• Linux1.no (English translation)
• PettiNix (Warning: Italian. English translation)
• Linux.org.ru (English translation)
• ZDNet.co.uk
• DistroWatch Weekly

There's also a ton of talk about Gentoo 2008.0 happening on Twitter, which I'm following through the Summize search engine with a search for gentoo. I'm also following blogs talking about Gentoo, and I have a news search for Gentoo that I expect to pick up more later once more journalists pick up the news.

Update 1: Added Phoronix, thanks to Denis Dupeyron (Calchan).

Update 2: Added OSNews

Update 3: Added OStatic, Heise, Linux Format, Clubic, FOSSWire, DesktopLinux.com, Linux Magazine (UK)

Update 4: Added InternetNews.com

Update 5: Added Open Source Pixels, Techgage

Update 6: Added LinuxNews.pl, Programas Livres

Update 7: Added Linux Journal, Linux1.no, PettiNix, Linux.org.ru

Update 8: Added ZDNet.co.uk, DistroWatch Weekly

17 Jul 2008 6:05am GMT

I wrote an article discussing Gentoo's new release and new council for this week's LWN.net. If you've read my earlier blog posts and other posts on Planet Gentoo regarding 2008.0, there won't be a whole lot of new information. It's designed as analysis of recent Gentoo events for people who don't already follow Gentoo development.

If you aren't already subscribed to LWN.net, get on it. It's my #1 source for Linux- and open-source-related news, and it saves me huge amounts of time that I would otherwise spend in cesspools like Slashdot. =)

P.S. Anyone going to OSCON, let me know via a comment here or my contact info.

17 Jul 2008 5:47am GMT