Non sequitur: Sunday, Monday, Linux… epic fail?

These are the recent bits of the story on how I couldn’t yet have on my Acer TravelMate a Linux distro (or any other OS) I am satisfied with.

The previous episode ended where I wasn’t happy with the horrendous Intel video performance in Ubuntu Jaunty, nor was the downgrade to the version 2.4 of the driver acceptable — I had a fatal crash once, while version 2.2 of the driver never crashed.

Obviously, the developers of the Intel video drivers should be skinned alive, because they simply ruined newer X.Org distributions:

• They screwed the EXA (and the older XAA) support in newer versions of the driver.
• By moving parts of the driver in the kernel, they made decent performance dependent of the latest commits in the newest kernels, thus severely affecting Ubuntu 9.04, Fedora 11, Mandriva 2009.1, openSUSE Factory.
• They don’t intend to fix EXA, instead they discontinue it by moving exclusively to UXA, which is currently as broken as KDE 4.0.0 was.
• In short, the the developers of the Intel video drivers for X.Org are simply ruining people’s confidence in Linux (or everything non-Windows and non-Mac), especially knowing that business laptops don’t need fancy Nvidia chipsets, but rather cheap Intel ones.

As an interim conclusion, relying on LTS/Enterprise distros should fix the issue, as they feature older (and working!) versions of the Intel video driver.

Now, for practical reasons I won’t recount the things in the exact order they happened.

Ubuntu 8.04 LTS is not a choice for me. It was broken from day 1, and it is still broken with regards to hibernation on my Acer (7.04 and 7.10 were hibernating perfectly). And the microphone is not supported either.

Now, some people might have noticed Caitlyn’s review of Debris Linux 1.7.o in Ladislav’s latest “Arbeit Macht Linux/BSD Frei Weekly”. Debris 1.7.0 is based on Ubuntu 8.04, but it features a newer kernel, so… why not?

First of all, Debris’ own repository is binary-only, which is unacceptable and untrustworthy. Secondly, once I don’t use their extra packages, what I get is still Ubuntu 8.04 LTS, so… why bother?

I’ve however tried Debris 1.7.0 on my old HP Omnibook XE3, which was gloriously running Scientific Linux 5.3 with IceWM, for reasons of modest resources.

The problem with the installed Debris was that I could get no sound for the included ES1988 (Allegro/Maestro3), no matter what packages I’ve added. I am not sure what was that the standard Ubuntu kernel used to make snd-maestro3 work, but I couldn’t find a package to provide the correct ALSA firmware, therefore instead of sound, all I’ve got was this:

Jun  1 14:41:30 odie kernel: Maestro3 0000:00:08.0: PCI INT A -> Link[LNKC] -> GSI 5 (level, low) -> IRQ 5
Jun  1 14:41:30 odie kernel: Maestro3 0000:00:08.0: firmware: requesting ess/maestro3_assp_kernel.fw
Jun  1 14:41:30 odie kernel: Maestro3 0000:00:08.0: PCI INT A disabled
Jun  1 14:41:30 odie kernel: Maestro3: probe of 0000:00:08.0 failed with error -2
Jun  1 14:41:30 odie firmware_helper[5575]: main: error loading '/lib/firmware/ess/maestro3_assp_kernel.fw' for device '/devices/pci0000:00/0000:00:08.0/firmware/0000:00:08.0' with driver '(unknown)'

I then tried with an Ubuntu kernel, to no avail. As it wasn’t a regular Ubuntu install, the required extra packages were not pulled automatically.

So I can’t use Ubuntu in any form of it, not even a nice way to make it lighter for my old laptop. Anyway, Debris 1.7.0 sports quite a good deal of small bugs, however not the one Caytlin mentioned: the USB sticks were not showing two desktop icons instead of one!

As an intermezzo, I wanted to stress that the mere fact that Fedora 11 was delayed with one week for a second time is the best proof that releasing twice a year is not feasible nowadays!

It’s not feasible because a modern distro includes too many interdependent packages. It’s not feasible because nowadays the development teams are affected by ADHD, which means that as soon as something works, they definitely feel the urge to replace it with a half-baked version of a “newer technology”. It’s not feasible because a modern distro can’t just release a better instantiation after 6 months — better as in “fewer bugs, corrected functionality” — they definitely must include important changes with every release (otherwise many kittens would die).

Should I add that, X.Org’s Intel aside, I am afraid of a newer GNOME too? The announced “deprecation of HAL” (that will most likely ruin Ubuntu 9.10) was already the cause for a GNOME Power Manager unstableness! What’s the next “benefit” of the “technical progress”?

I also considered openSUSE 11.1, which is going to be supported through Dec. 31, 2010. Factory and 11.2-M2 are sporting regressions with regards to the Intel video, and several other bugs. Using 11.1 would be possible, and separate repos exist for those who need newer builds of specific packages or metapackages (e.g. GNOME). Otherwise, Packman should be enough for the missing (restricted) packages.

Still, knowing that openSUSE 11.2 would most likely be unsatisfactory for me, this would postpone the “moment of the truth” for release 11.3 (or 12.0, whatever will be the next release). And early-2011, an upgrade or a change of distro is mandatory…

Mono can be removed, yet I have some other uneasiness with openSUSE: they try too hard. Too many package managers, too many configuration tools, too many ways to break the system. OK, maybe I could get used with them.

I was already running out of patience when I installed the openSUSE 11.1 GNOME LiveCD on my Acer. For some unknown reason, after the first reboot, clicking on my name in GDM raised a queer “Unable To Authenticate User” whereas I am not asked for any password!

That was unfixable. And I don’t feel like reinstalling openSUSE. That’s actually the first time when a SuSE install failed on me — heck, even the openSUSE 11.1 KDE LiveCD installed flawlessly! (Ouch, it actually was “Build0050” from Factory!)

Tired of bugs. Too many of them.

As a last casual note: no, I wasn’t considering Mandriva 2009.1 (and stop mentioning Debian!), because it’s not supported for long enough, and it’s always buggy. Tiens, they just say that MDVA-2009:084 fixed some major issues with some Intel video chipsets, but fact is that for other people this update broke their system! (I’ve told you Mandriva is a no-go, eh?)

What was the real purpose of this? The real issue at stake was whether to go for CentOS 5.3 or not! Using a RHEL5 clone/derivative would include some limitations, while guaranteeing (sort of) a decent stability for some years to come (“RHEL, the other XP”).

OK, I was already having Scientific Linux 5.3 (with IceWM) on the old laptop, so I could use it for some “consistency checking”.

If you were not aware of it, not only RPMforge doesn’t mix well with EPEL, but it doesn’t mix well with anything!

Here’s the older exhibit #1:

--> Finished Dependency Resolution
1:xmms-devel-1.2.11-el5.rhc.3.20071117cvs.i386 from installed has depsolving problems
  --> Missing Dependency: xmms-libs = 1:1.2.11-el5.rhc.3.20071117cvs is needed by package 1:xmms-devel-1.2.11-el5.rhc.3.20071117cvs.i386 (installed)
wine-desktop-1.0.1-1.el5.i386 from installed has depsolving problems
  --> Missing Dependency: wine-core = 1.0.1-1.el5 is needed by package wine-desktop-1.0.1-1.el5.i386 (installed)
Beginning Kernel Module Plugin
Finished Kernel Module Plugin
Error: Missing Dependency: xmms-libs = 1:1.2.11-el5.rhc.3.20071117cvs is needed by package 1:xmms-devel-1.2.11-el5.rhc.3.20071117cvs.i386 (installed)
Error: Missing Dependency: wine-core = 1.0.1-1.el5 is needed by package wine-desktop-1.0.1-1.el5.i386 (installed)

Exhibit #2 is a fresh one, albeit somewhat specific to SL:

[root@bra-nb14-008 sluser]# yum install fuse-sshfs
Loaded plugins: kernel-module
Setting up Install Process
Parsing package install arguments
Resolving Dependencies
--> Running transaction check
---> Package fuse-sshfs.i386 0:2.2-1.el5.rf set to be updated
--> Processing Dependency: fuse >= 2.2 for package: fuse-sshfs
--> Processing Dependency: libfuse.so.2(FUSE_2.6) for package: fuse-sshfs
--> Processing Dependency: libfuse.so.2(FUSE_2.2) for package: fuse-sshfs
--> Processing Dependency: libfuse.so.2(FUSE_2.5) for package: fuse-sshfs
--> Processing Dependency: libfuse.so.2 for package: fuse-sshfs
--> Processing Dependency: libfuse.so.2(FUSE_2.7) for package: fuse-sshfs
--> Running transaction check
---> Package fuse.i386 5:2.6.3-1.SL set to be updated
--> Processing Dependency: kernel-module-fuse >= 5:2.6.3-1.SL for package: fuse
---> Package fuse-libs.i386 5:2.6.3-1.SL set to be updated
---> Package fuse-sshfs.i386 0:2.2-1.el5.rf set to be updated
--> Processing Dependency: libfuse.so.2(FUSE_2.7) for package: fuse-sshfs
--> Running transaction check
---> Package kernel-module-fuse-2.6.18-128.1.6.el5.i686 5:2.6.3-1.sl5 set to be updated
---> Package fuse-sshfs.i386 0:2.2-1.el5.rf set to be updated
--> Processing Dependency: libfuse.so.2(FUSE_2.7) for package: fuse-sshfs
--> Finished Dependency Resolution
fuse-sshfs-2.2-1.el5.rf.i386 from rpmforge has depsolving problems
--> Missing Dependency: libfuse.so.2(FUSE_2.7) is needed by package fuse-sshfs-2.2-1.el5.rf.i386 (rpmforge)
Beginning Kernel Module Plugin
---> Package kernel-module-openafs-2.6.18-128.1.1.el5.i686 0:1.4.7-68.2.SL5 set to be installed
---> Package kernel-module-fuse-2.6.18-128.1.1.el5.i686 5:2.6.3-1.sl5 set to be installed
Finished Kernel Module Plugin
--> Running transaction check
---> Package kernel-module-openafs-2.6.18-128.1.1.el5.i686 0:1.4.7-68.2.SL5 set to be updated
---> Package fuse-sshfs.i386 0:2.2-1.el5.rf set to be updated
--> Processing Dependency: libfuse.so.2(FUSE_2.7) for package: fuse-sshfs
---> Package kernel-module-fuse-2.6.18-128.1.1.el5.i686 5:2.6.3-1.sl5 set to be updated
--> Finished Dependency Resolution
fuse-sshfs-2.2-1.el5.rf.i386 from rpmforge has depsolving problems
--> Missing Dependency: libfuse.so.2(FUSE_2.7) is needed by package fuse-sshfs-2.2-1.el5.rf.i386 (rpmforge)
Error: Missing Dependency: libfuse.so.2(FUSE_2.7) is needed by package fuse-sshfs-2.2-1.el5.rf.i386 (rpmforge)

This should have been unnecessary in SL. As opposed to the other RHEL clones, SL already comes with FUSE, so there is no need to get it from RPMforge. For the purpose of the above error, I’ve previously removed the FUSE support from SL 5.3. (Without that, the failure would have been raised by any “yum update”.)

I am completely unaware (and uninterested) of the various ways of adding userland support to Linux. I can’t explain why Scientific Linux adds fuse, fuse-smb, fuse-sshfs and it needs kernel-module-fuse-2.6.18-128.1.1 (that must be rebuilt for each and every kernel minor update!), whereas RPMforge comes with fuse, fuse-ntfs-3g, fuse-smb, fuse-sshfs, and it only needs the fixed-version dkms-fuse (which doesn’t need any rebuild).

Anyway, as you could see, RPMforge is fucking inconsistent, so it’s better to lasciate ogni speranza, voi ch’entrate…

Exhibit #3:

[root@bra-nb14-008 sluser]# yum install audacious
Loaded plugins: kernel-module
Setting up Install Process
Parsing package install arguments
Resolving Dependencies
--> Running transaction check
---> Package audacious.i386 0:1.3.2-5.el5.rf set to be updated
--> Processing Dependency: audacious-plugins >= 1.3.0 for package: audacious
--> Processing Dependency: libaudacious.so.5 for package: audacious
--> Running transaction check
---> Package audacious-libs.i386 0:1.3.2-5.el5.rf set to be updated
--> Processing Dependency: libmowgli.so.1.0.0 for package: audacious-libs
--> Processing Dependency: libmcs.so.1.0.0 for package: audacious-libs
---> Package audacious.i386 0:1.3.2-5.el5.rf set to be updated
--> Processing Dependency: audacious-plugins >= 1.3.0 for package: audacious
--> Running transaction check
---> Package libmcs.i386 0:0.6.0-1.el5.rf set to be updated
---> Package audacious.i386 0:1.3.2-5.el5.rf set to be updated
--> Processing Dependency: audacious-plugins >= 1.3.0 for package: audacious
---> Package libmowgli.i386 0:0.5.0-1.el5.rf set to be updated
--> Finished Dependency Resolution
audacious-1.3.2-5.el5.rf.i386 from rpmforge has depsolving problems
--> Missing Dependency: audacious-plugins >= 1.3.0 is needed by package audacious-1.3.2-5.el5.rf.i386 (rpmforge)
Beginning Kernel Module Plugin
Finished Kernel Module Plugin
Error: Missing Dependency: audacious-plugins >= 1.3.0 is needed by package audacious-1.3.2-5.el5.rf.i386 (rpmforge)

Now what? Missing dependency. What kind of moron is Dag Wieers and How the fuck are we supposed to trust RPMforge, if such a simple integrity check is not performed?! audacious-1.3.2-5.el5.rf.i386 needs audacious-plugins-1.3.0 or newer, but this package doesn’t exist!

Screw RPMforge.

Niki Kovacs mentions in his book on CentOS 5.3 that there is a dependency conflict on RPMforge between VLC and Audacity (and he offers a possible workaround), but now we see that Audacious too is wrongly packaged!

At this point (it was on Sunday) I was telling myself:

No, I won’t install any RHEL5 clone, after all. If one can’t trust not even RPMforge, then there is no way to use CentOS on the desktop!

After having considered all the other options, I have reconsidered the issue. As of today, I’ve came to a different conclusion:

Not a single 3rd-party repo should be enabled with any RHEL5 clone, ever! For RPMforge, as well as for any other possible repo (EPEL?), selected packages should be installed either manually (with rpm, not yum), or based on a temporary enabling of the said repo, but the repository should be disabled immediately afterwards!

There are tools to help you control the damage. They’re some yum plugins present in both CentOS and Scientific Linux:

• yum-allowdowngrade
• yum-priorities
• yum-protectbase
• yum-protect-packages
• yum-versionlock

The same way I had headaches in the past with APT priorities, I don’t want to rely on YUM priorities to fix broken repos. I’d rather protect some packages (or lock their version), so that on the occasional enabling of some screwed repo, no RPM hell shows up!

But I have to learn how to use them, especially those without Wiki entries.

So the next task is to install CentOS 5.3 on the Acer TravelMate, to check that the newest kernel still allows hibernation, and to establish the right source for the extra packages/applications I need.

“News at 11”… but not today!

BONUS TIP: it seems there is a way to use GIMP 2.4 in RHEL5 clones! This is the project (with a screenshot), and here you have the GIMP 2.4.7 packages for EL5!

That’s fabulous, as I actually dislike GIMP 2.6 and its mess of a desktop…

This entry was posted on June 02nd, 2009 and is filed under Software. Tags: Bugs, CentOS, GIMP, GNOME, Red Hat, ScientificLinux, SuSE, Tips, Using Linux (Generic), X.Org sucks, zbuntu.
480 views.
You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.

 Printer-friendly version