» openSUSE @ FOSDEM Call for Papers

Christoph Thiel sent the announcement on the openSUSE mailing-lists today: openSUSE @ FOSDEM 2007 call for papers/speakers/participants Being one of the FOSDEM organizers, I can only objectively ^^ confirm that FOSDEM is a great event for anyone interested in Free and Opensource Software. High quality, very technical talks, around 16 talks held at the same time throughout all the week-end in our main tracks and the developer rooms. To learn more about the event, have a look at the FOSDEM website: http://fosdem.org/2007/ See you in 24+25 February in Brussels ;)

» openSUSE 10.2 vs Dell Optiplex GX270

And another annoyance after upgrading to 10.2, again with my workstation @work. It's a Dell Optiplex GX270 and it definitely seems to have a borked SATA controller. When booting, it takes around 2 minutes for the ata_piix module to notice there's no disk on the SATA controllers (note that the SATA controllers are even disabled in the BIOS). It comes up with this:

libata version 2.00 loaded.
ata_piix 0000:00:1f.2: version 2.00ac7
ata_piix 0000:00:1f.2: MAP [ P0 -- P1 -- ]
ACPI: PCI Interrupt 0000:00:1f.2[A] -> GSI 18 (level, low) -> IRQ 169
PCI: Setting latency timer of device 0000:00:1f.2 to 64
ata1: SATA max UDMA/133 cmd 0xFE00 ctl 0xFE12 bmdma 0xFEA0 irq 169
ata2: SATA max UDMA/133 cmd 0xFE20 ctl 0xFE32 bmdma 0xFEA8 irq 169
scsi0 : ata_piix
ata1: port is slow to respond, please be patient (Status 0xff)
ata1: port failed to respond (30 secs, Status 0xff)
ata1: SRST failed (status 0xFF)
ata1: SRST failed (err_mask=0x100)
ata1: softreset failed, retrying in 5 secs
ata1: SRST failed (status 0xFF)
ata1: SRST failed (err_mask=0x100)
ata1: softreset failed, retrying in 5 secs
ata1: SRST failed (status 0xFF)
ata1: SRST failed (err_mask=0x100)
ata1: reset failed, giving up

Ok, not that much of a problem, it just takes a little longer to boot (that's when I go grab a cup of coffee anyway). Unfortunately, this workaround didn't help. Here's the LKML thread about it and it seems the patch has been approved and merged upstream. And with some luck it will be included in the next kernel upgrade patch ;)

» Novell Client on openSUSE 10.2

Upgraded my workstation @work to 10.2 today and noticed something really, really annoying. We use some OES boxes as file servers in our LAN (yeah, don't ask me ;)) and the Novell Client for Linux worked fine on 10.0 and 10.1. It did stop working on 10.2 though, because of two issues:

binutils

Novell doesn't provide packages for openSUSE 10.2 (*doh*). I tried to use the packages for SLE10 (novell-client-1.2-SLE10.tar.gz) but couldn't install them because they are linked against the binutils of SLE10/SUSE10.1 -- namely, libbfd-2.16.91.0.5.so). So I decided to do a backport/compatibility package for openSUSE 10.2 that includes libbfd-2.16.91.0.5.so. After all, the SONAME contains the complete version up to the last dot and hence, it can be installed side-by-side with the binutils package of 10.2 without causing any issues. I hacked the spec file of SUSE 10.0's binutils and just kept libbfd-2.16.91.0.5.so and libopcodes-2.16.91.0.5.so in the package. RPMs for 32bit and x86_64 are available in my repository (or will be in a few hours, after the next sync).

novfs kernel module

The novfs kernel module (provided on 10.2 through the package novfs-kmp-default) doesn't work. It hasn't been ported to 2.6.18 and still uses the deprecated tasklist_lock. I managed to hack a patch against novfs-2.0.0-3.src.rpm and it seems to work fine -- at least for me.

Update

added 2006-12-26 20:15: Currently waiting for a fix (and possibly an Online Update). In the mean time, you can upgrade to the novfs-kmp package that is available in my repository. The following command should do the trick:

rpm --freshen -vh ftp://ftp.skynet.be/pub/suser-guru/rpm/packages/System/novfs/*.rpm

» smart-beta-0.50rc1 (r839) is now smart-0.49.1

With the channel modifications needed to support SUSE 10.2 (the repository layout changed yet again, but this time for the better), I decided to package the current 0.50rc1 beta version of smart as stable (smart-0.49.1-10). Point is, 0.50rc1 is way better than 0.42 ;) If you have smart-beta installed, an upgrade to smart-0.49.1 should be easy (smart install smart, which should uninstall smart-beta). If you run into your favorite package manager not wanting to upgrade because it would break dependencies, just uninstall any of smart-beta-gui, smart-beta-addons, smart-beta-ksmarttray and smart-beta-debuginfo (if they're installed). The following shell snippet should do the trick:

REMOVE=""
for pkg in gui addons ksmarttray debuginfo; do
   rpm -q "$pkg" && REMOVE="$REMOVE $pkg"
done
[ -n "${REMOVE# }" ] && su -c "rpm -e $REMOVE"

Once you've done that, upgrade smart-beta to smart:

smart update && smart install smart

And finally, install additional subpackages as you wish, e.g.:

smart update --yes
smart install smart-{gui,addons,ksmarttray}

» libmtp gets this week's OSS project WTF award

What a mess... Having to hack around upstream version numbers involving "rc", "alpha" or "beta" isn't fun but this one tops everything I've seen up to now: libmtp They released a new version today, 0.1.0. Of course, it breaks backwards compatibility and installs itself as libmtp.so.4. Their previous releases, 0.0.18 to 0.0.21 installed as libmtp.so.2. Now you might wonder why they went from .so.2 to .so.3 - in fact, their even older releases, up to 0.0.17 installed as libmtp.so.3. Let's summarize:

0.0.17 ......: libmtp.so.3
0.0.18-0.0.21: libmtp.so.2
0.1.0 .......: libmtp.so.4

Go figure. To fix all that upstream mess, my libmtp-0.1.0 package builds and ships libmtp.so.2 (from upstream 0.0.21), libmtp.so.3 (from upstream 0.0.17) and libmtp.so.4 (from upstream 0.1.0), in order to avoid breaking compatibility with existing packages. I've also rebuilt gnomad2 to compile and link against libmtp-0.1.0 (libmtp.so.4, that is). Packages will be on the mirrors in a few hours. Please let me know whether upgrading libmtp to 0.1.0 breaks something or whether it works for you. At least it seems to work fine with my latest amarok packages.

» Groklaw FUD machine

Sad... their motto is "digging for the truth" but this time they got it all wrong. "Novell "Forking" OpenOffice.org" "There will be a Novell edition of OpenOffice.org and it will support Microsoft OpenXML." Well, fact is that it's been quite some time there's a "Novell edition" of OpenOffice.org. Nothing new. Point is, Sun employs around 70-80% of the developers working on OpenOffice.org, Novell having more or less all the others on their payroll. Patches, fixes, enhancements written by Novell employees (such as KDE integration) are sent upstream to Sun and Sun decides whether it makes it into the OpenOffice.org code base or not. Until Sun decides (which can sometimes take a lot of time) or if Sun rejects, Novell can still include those patches into their own builds of OpenOffice.org (i.e. those that are shipped as part of SUSE Linux and SLED). And if they doubt about Novell's commitment to ODF: read this. Also make sure to read this part: "Our Source: all JCA / LGPL". Nothing special, all Linux distributions do that, with various parts of the system (including the kernel). Paranoia and willfully twisting facts into flaming headlines won't help us -- none of us, that is. Groklaw has now officially matched the level of Slashdot: down the gutter.