Today I experienced segfaults when I try starting opera (yeah it's unfree, closed-source, but better than firefox ; )

If you experience something like this:
zsh: segmentation fault opera

Then this might be interesting for you. Opera stopped working with new X libs (I had my dist-upgrade today, but this problem is not Debian specific) and starts coredumping.
The opera desktop team released a hotfix for this which works (at least for me).

You can grab it on: http://my.opera.com/desktopteam/blog/2007/04/06/hotfix.
See http://bugs.debian.org/417816 for more information.

UPDATE:
There is a hotfix2 now. The Opera team writes "A few users reported some sideeffects". I don't know what sideeffect is exactly here but I noticed random crashes with the hotfix. I guess that's what they wanted to say
Get it on http://my.opera.com/desktopteam/blog/2007/04/07/hotfix-2

UPDATE: the hotfix2 also randomly crashes Another workaround should be to set the color depth in xorg.conf to 16 but that also sucks. From what I know so far is some kind of unicode issue. So yeah it's unfree, closed-source and you have to wait a bit for a fix

UPDATE: The issue should be fixed with: http://my.opera.com/desktopteam/blog/2007/04/08/all-good-things

Today is the second day in which I find that my laptop does not resume properly from sleep and I start to wonder why. None of he old problems, blank screen, no reponse...

This time it just looses the GNOME session. I saw two segfaults on the console, on resume: one from iceweasel and one from another app. Then gdm comes up.

I think is xorg's fault or gnome-core. Why? Well, it didn't happened 4
days ago and I have these in the dpkg.log (grepped for upgrades only):

2007-03-12 00:19:04 upgrade xorg 1:7.1.0-13 1:7.1.0-15
2007-03-12 00:19:04 upgrade xvnc4viewer 4.1.1+X4.3.0-20 4.1.1+X4.3.0-21
2007-03-13 03:10:34 upgrade libeel2-data 2.14.3-3 2.14.3-4
2007-03-13 03:10:35 upgrade libnautilus-burn3 2.14.3-8 2.14.3-8+b1
2007-03-13 03:10:35 upgrade libnautilus-extension1 2.14.3-9 2.14.3-11+b1
2007-03-13 03:10:36 upgrade nautilus 2.14.3-9 2.14.3-11+b1
2007-03-13 03:10:37 upgrade nautilus-data 2.14.3-9 2.14.3-11
2007-03-13 03:10:51 upgrade nautilus-cd-burner 2.14.3-8 2.14.3-8+b1
2007-03-13 03:11:00 upgrade gnome-mount 0.5-2 0.5-3
2007-03-13 03:11:24 upgrade libxine1 1.1.2+dfsg-2 1.1.2+dfsg-3
2007-03-13 03:11:25 upgrade lintian 1.23.27 1.23.28
2007-03-13 03:11:26 upgrade unionfs-tools 1.4+debian-3 1.4+debian-4
2007-03-14 09:46:32 upgrade foomatic-filters 3.0.2-20061031-1.1 3.0.2-20061031-1.2
2007-03-14 09:46:32 upgrade libntfs-3g0 1:0.0.0+20061031-6 1:0.0.0+20061031-6+b1
2007-03-14 09:46:33 upgrade ntfs-3g 1:0.0.0+20061031-6 1:0.0.0+20061031-6+b1
2007-03-14 09:46:33 upgrade ekiga 2.0.3-4 2.0.3-5
2007-03-14 09:46:48 upgrade gnome-desktop-environment 1:2.14.3.5 1:2.14.3.6
2007-03-14 09:46:48 upgrade gnome-core 1:2.14.3.5 1:2.14.3.6
2007-03-14 09:46:48 upgrade gnomemeeting 2.0.3-4 2.0.3-5
2007-03-14 09:46:48 upgrade libgraphicsmagick1 1.1.7-12 1.1.7-13
2007-03-14 09:46:49 upgrade graphicsmagick 1.1.7-12 1.1.7-13
2007-03-14 09:46:50 upgrade obexfs 0.10-3 0.10-3+b1
2007-03-14 09:46:51 upgrade graphicsmagick-imagemagick-compat 1.1.7-12 1.1.7-13


I'll turn back time with snapshot.debian.net and see if I get back my resume ...


Notes:

• I use Etch, almost no packages from Sid or Experimental...
• no, I didn't submit a bug yet; although this is not RC from Debian's PoV, it sure feels like this kind of regression shouldn't happen...
  

I've made a tiny update to DBus inspector, which works around the Tracker issue causing a segfault for many users (especially Ubuntu users, where Tracker seems to be part of a default install now?) Anyway, it should be working with the Python DBus bindings from GIT, but since they aren't released yet (or in Debian), I've added a workaround. If any service containes "Tracker" and your python dbus version is at most 0.80.2, it will just skip this service. I don't know if it's also Trackers fault that dbus-python segfaults. Download DBus Inspector Sorry, no homepage yet. Still waiting for repository and account creation on Gnome.org, which seems like a good home for it.

... or why PHP sucks so much?

It is quite common (at least for me) finding abused web applications on shared hosts around. The most typical case is finding some kind of IRC bot running as www-data and a few unauthorized files around used for phishing, cross-site scripting or what else. That motivated me to try playing with mod_chroot in order to minimize the possibility of webapps abuse from our friendly kiddies^Wcrackers. Mod_chroot is a nice tiny Apache module whose purpose is the confinment of webapps within a limited tree, where nothing but a few files and dirs are available to try exploits and abuse badly written code.

Unfortunately, I found that mod_chroot poses one major problem (among others, see its CAVEATS doc): the sucking mail() function is not working out of the box, because PHP folks - God knows why - decided to implement that stuff by calling a local /usr/sbin/sendmail program within a shell call. The most sane option is simply ignoring the issue and living happy with a disabled local mail() function. A nice solution in that case is using a PEAR Mail module, which is able to send mails via SMTP in much more elegant way. Unfortunately, there are quite a good number of morons out there, and that could be not a viable option if you are the system administrator of a bounce of shared hosts which are exposed to those morons, who absolutely need a working mail() function.

After a few googling around, I did find that many people had the same problem, but none found (or explained) a working and neat solution for a working mail() implementation, so I'm writing some notes about that. My implementation is based on a nice tiny program (mini_sendmail) which has the great advantage of not requiring a configuration file or a spool directory to work. It also works without suid bit on, which is a good thing as well. It is statically compiled by default, so it simplifies things a lot. In order to have mail() working you need also to install a (statically compiled) shell, e.g. bash-static as sh under the /bin directory of your chroot tree (a more tiny shell would be appropriate). I commented out the silly username autodetection code in the mini_sendmail.c source, because it creates some problem within an empty chroot tree (it failed with a "can't determine username" message with or without the /etc/passwd file available).

Now, the next step is using an entry like

sendmail_path = /usr/sbin/sendmail -t -fwww-data@your.domain -s127.0.0.1

in your php.ini file. You can also use another IP address if your SMTP server is not your localhost or you used some more exotic routing setup. Having a suitable /etc/hosts is also useful. A final trick is adding a var/lib/php4 or what ever directory is required to store PHP session files. No other files should be required in order to have all working. Of course, you have also to use inet sockets for any required connection (e.g. mysql) but this is typically the default in etch. I would also suggest to add only ad hoc statically-compiled binaries within the chroot tree when required, else you will need to store all required shared libs: in that case you will need to find binaries requirement by using ldd and chroot to find loading/running errors by means of an usual trial-and-error cycle.

Until recently I was a quite happy user of the mail client mutt. I used to receive mails on my own mail server, check them for spam, and at home I used fetchmail to pull them all down, where they where sorted in different folders via procmail. Not very elegant, but working. Sometime I read the mails directly on my server, which wasn't as comfortable as possible, since the mails where all in one big pile. So I needed to change something to sort them on the server and sync them home. Not a big problem, you might think? Well... Sorting mails on my server wasn't a big problem (beside the fact that I needed to tweak my procmailrc a bit; I used real folders at home, but dovecot wants to have the folder hierarchy separated by dots in the names of the physical folders). First I tried to use mbsync, from the isync package. First problem was, that mbsync doesn't like subfolders (which I didn't found out via the documentation, but from a friend using it, too). So I needed to rename all my folders (nearly 100) again to something mbsync would understand. I worked quite well and did, what I wanted to do: Syncing mails from my home computer to my mail server and the other way around. It was nearly perfect, and I would be able to read mails even without net connection. Perfect for boring train rides! But after only one week something went wrong. mbsync started to segfault. Beside receiving new mails and doing the usual stuff (reading them, moving them to other folders) I changed nothing. But it kept on segfaulting; I didn't found out why (see #411120). Obviously I need a working mail setup, so I searched something new... like my old mutt! Why not use mutt to access the imap server directly? Okay, I wouldn't be able to read mails while traveling around in a train... but hopefully mbsync would be fixed in the meantime. But using mutt with imap sucks, too. While it is perfectly possible to read my mails, it seems impossible for mutt to check, which folder has new mails. No, that won't work. Thanks, I'll have a look at something else... Perhaps I should try something new? My girlfriend likes thunderbird icedove. Nice user interface... no problem accessing my imap server... and it has some kind of offline mode. But... NO! It seems it's impossible to make system wide folder settings! Like... displaying new mails on the top instead of the bottom... or using the thread view... or setting this damn "check this folder for new messages" flag, so the folder will be checked for new mails. Damn! I won't click through every single one of my nearly 100 mail folders to set the settings I want. Sigh... isn't there a mail setup which doesn't suck? It isn't that complicate: I want to use gpg, I want to have threading, I want my folders to be displayed properly (preferably in some kind of tree), I want to see which folders have new mails and it shouldn't be that huge (which kicks out kmail and gnus); bonus points if I can continue using my favourite editor and for some kind of offline mode. Update: icedoves threading sucks, too. It seems to be based on the subject of the mails, not mail headers. Leading to quite iritating views on a mailfolder containing a lot of auto generated messages with similar subject. PS: No, I haven't tried offlineimap, yet. Some people warned me to not use it. Well... perhaps I'll give it a try.

As of 1.0.27-2, the GtkHTML rendering backend for liferea is disabled. It simply caused too much trouble, randomly segfaulting on every architecture and reliably segfaulting on 64bit ones. So I ended up deciding to just disable it and leave only the xulrunner engine. Please, if you use liferea, help test the transition to the new version, I’d really like to get this change into etch. You can get it right now from incoming, or wait till the next install run for it to get into sid.

The server that this site is running on is a Debian sarge machine with some backports.org packages for things that I just have to have up-to-date. This has been a pretty successful strategy for me for running servers... except for one thing. If you're running any PHP code, you really need to have an opcode cache like eAccelerator running on your server, too. Otherwise, every single hit to a PHP app loads and compiles every single PHP page it uses before executing. For any kind of load, and any kind of non-trivial app, it's just not a question. But there's not an eaccelerator package in sarge or in backports.org, so I built my own, which I have to keep up-to-date with PHP packages coming down the line from backports. Today, I upgraded from PHP 5.1.x to PHP 5.2.x, and I rebuilt eaccelerator, and... blammo. Segfaults all over the place with MediaWiki, and Drupal decided it wasn't going to save sessions any more. Turning off eaccelerator was enough to solve the problems with MW, but I had to track down this Drupal-PHP-5.2 bug and apply the patch to make Drupal work again. Of course, performance is sucking because there's no opcode cache. I kind of hate that kind of day. tags: php drupal php 5.2 eaccelerator mediawiki

xcache Update to that: I tried out xcache, and it seems to be working fine. So, y'know, hopefully that project keeps working in the future. tags: php xcache

Pirates So, probably the most interesting thing about getafirstlife.com is that the image chosen to represent analog reality is a bunch of kids dressed like pirates. That is one of the selling points of First Life, I guess. tags: getafirstlife kids pirates

Goethe I had a really good class at the Montreal Goethe Institute yesterday. I'm continually impressed by the facilities there. My class did a little tour of the building, including the half-size movie theatre, the huge reading room (with the day's German newspapers), and the big library. They even have a TV going with the Deutsche Welle satellite feed coming in. It's a pretty cool thing to have this kind of resource in Montreal. tags: montreal goethe german

Mon pays Speaking of great resources in Montreal, Amita June and I went for a walk through Parc LaFontaine today. It was a balmy -8C (18 F) and the sun was shining on the snow. They've opened up the pond for skating, and there were about a dozen people lazily twirling around on the ice. Well... they looked lazy. They were probably working pretty hard. Our stated purpose for the walk was to get to the Biblioth que centrale-jeunes on the other side of the parc. The main Biblioth que Centrale shut down about a year ago when the new Grande Biblioth que opened down by UQAM. But they've kept the children's library open, and Amita June's just at the age where she can actually enjoy it. It was really a very nice library. There were a ton of books in good shape, lots of open tables, and a couple of billion toys, blocks, and games to play with. Amita and I both got library cards, which should be pretty fun to use, and we played around with the different books and such. They also have story-time hours at 10AM each weekday, so we'll be going back soon. Amita's favourite part of the library, though, was a big rock dove they had. It had a nice cage with water and toys and mirrors and stuff, but it seemed to like walking around on the shelves better. Amita followed it around making dove noises -- coo ca coo! Our trip back across the parc was pretty nice, too. The kids in the school there were out for recess, and they had built some epic-scale snow forts and were involved in an 18-sided snowball fight as we passed. There was also a passel of kids from a nearby garderie (daycare) who were making Inukshuks out of hardened snow. By the time we got home, we were pretty exhausted, but glad to have gotten some winter outdoor time. tags: winter montreal library parc lafontaine

Welcome to this 6th issue of the DeFuBu contest, the monthly (even if I'm late) championship of the funniest bug reported to the Debian BTS. The challengers

• G rkan Seng n with #270877 (wmaker: I can't swallow windows)
• Christoph Berg with #402976 (espdiff: useless manpage)
• Cyril Brulebois with #403379 (mplayer: segfault while reading an mpeg file)
• Sune Vuorela with #405464 (qt3-dev-tools: QMAKE_INCDIR_QT is wrong in qmake.conf files)

How the vote has been done Three Debian related people voted for these bugs, Mohammed Adn ne Trojette, Pierre Habouzit and Florent Bayle Full ranking Bugs

• #403379 (mplayer: segfault while reading an mpeg file) (6 points)
• #402976 (espdiff: useless manpage) (5 points)
• #405464 (qt3-dev-tools: QMAKE_INCDIR_QT is wrong in qmake.conf files) (4 points)
• #270877 (wmaker: I can't swallow windows) (3 points)

Challengers

• Cyril Brulebois (6 points with 1 bug)
• Christoph Berg (5 points with 1 bug)
• Sune Vuorela (4 points with 1 bug)
• G rkan Seng n (3 points with 1 bug)

The winners

• Bug: #403379 (mplayer: segfault while reading an mpeg file) (6 points)
• Challenger: Cyril Brulebois
• Bug reporter: Aurelien Jarno
• Voter: Florent Bayle with the full good order !

Notes To participate, simply drop me an email with a bug number. About DeFuBu

After my post from yesterday, I’ve been able to find out what my problem with usplash is about, although I’m stiill working in a proper solution to it. It seems that when the root filesystem is changed, programs must react accordingly. The proposed sequence for the usage of pivot_root is something like the following:

• Create the new directory in which the new to-be-root filesystem will be created: mkdir /new-root
• Mount the proper partition, that will end being the root filesystem, in that directory: mount /dev/hdxx /new-root
• Create the directory in which the current root filesystem will be mounted after the change. That directory shall be inside the new root directory: mkdir /new-root/old-root
• Change directory to where the new root partition will be mounted: cd /new-root
• Move the root filesystem of the current process to the directory /new-root/old-root and make /new-root the new root filesystem: pivot_root . old_root
• Change the reference to the root node of the current process to be able to get a shell that runs inside the new system. Care must be taken in cleaning the shell’s input and output channels to be able to read and write: exec chroot . sh dev/console 2>&1
• Unmount the device that was previously mounted as root: umount /old-root

To be able to analyze the exact starting sequence of the system stored in the initrd.img, we must expand its contents to a directory using cpio. Some time ago, initrd.img used to be a filesystem that used cramfs, minix or ext2 filesystems, but not anymore for the newer Debian systems.

• We create a temporary directory to store the contents of the initrd.img file: mkdir tmp_initrd
• We change to that directory: cd tmp_initrd
• We copy the desired initrd.img file to the current directory, and rename it to reflect the fact that it is compressed with gzip: cp /boot/initrd.img-xxx initrd.img.gz
• Uncompress it: gunzip initrd.img.gz
• Expand its contents: cpio -i initrd.img
• Delete the image file: rm initrd.img

The script that is responsible for setting up the system at start is called init and is currently a shell program. Having a look at it, I found out that a temporarily environment variable is set, designing the place in which the real root filesystem will be temporarily mounted before switching it to the root filesystem: rootmnt=/root At some point later, /sys and /proc filesystems, that were mounted in their respective directories at the beginning, are moved to $ rootmnt /sys and $ rootmnt /proc to be set in their final destination directories: mount -n -o move /sys $ rootmnt /sys, and later mount -n -o move /proc $ rootmnt /proc At the end of the script, the system switches to the real root filesystem: exec run-init $ rootmnt $ init “$@” $ rootmnt /dev/console >$ rootmnt /dev/console I’ve changed my code so that /proc/… files I used are open from the very beginning, and kept open until the end of the execution of usplash, and it seems to work. I’ve also been able to write a debug log for it, storing it in /dev/.initramfs/, which is a directory that is kept in that place all the time, so that whatever is stored there is available after the soot switch. That is the directory that usplash uses to store its FIFO nodes: usplash_fifo and usplash_outfifo. Maybe I can find a way to store core files there after a SEGFAULT error, setting the proper parameters with ulimit and /proc/sys/kernel/core_pattern. All I need to find out now is how to be able to reach the contents of /etc/… after the final rootsystem is mounted. I’ll tell you when I’ve solved that.

I’ve been doing some usplash-related stuff these days, but I’ve come across some problems. First of all, I want to be able to track some hardware information from within the experimental theme I’m working on, and that means reading some stuff from /proc and /etc (and maybe from /sys in the future, I don’t know yet) if it is available. It seems to work OK if I open the file handler from the beginning and keep it open, rewinding to the start of the file when I need to read its contents but never closing it until the end of execution. If I instead open the file, read from it and close it again, it seems to work properly for the beginning, but after a while it stops retrieving data. I guess that when the real root is mounted i lose the capacity to interact with the filesystem from my code, like opening new files. The second problem is somehow related. I want to be able to save a log file of the execution of the program, but I don’t seem to be able to open a file for writing, at any moment in the execution of the program. I guess it’s the same problem, accessing the filesystem from a program that is started from initrd.img instead of from the real disk. Is there any way to connect the program with gdb during real execution? I seem to be getting SEGFAULT errors with some things I try, but it’s hard to debug without any data (not even logs, as I cannot open a file for writing at any moment). Maybe being able to dump a core when a SIGSEGV signal is received would do. More on this, in future posts.

Following a bug report earlier today, Jeff committed a quick fix to our svn archive. A few minutes ago, I wrapped it up as version 0.0.9 of r (pronounced littler), put it into the local directory and page here and sent it to Debian's incoming queue. It should also hit Jeff's littler page at Vanderbilt in due course. The principal change is an added initialization to prevent the reported segfault, as well as a small improvement to the update.r script (which makes it easy to keep your CRAN packages up-to-date). I use littler all-day-long at work, and have found it rather reliable and easy, including during upgrades of the underlying R version.

I’ve been asked to keep my blog up to date with regard to Linux support of the MacBook Pro, so here are my latest findings. For more background, see the previous post on the same subject. Anything that I don’t mention here or in another post can be assumed to work (or I just haven’t tested that particular thing yet, though I’m doing some extensive tests).

• Sound: still nothing, none of the various patches floating are good enough
• Battery life: no news here, 1h30 is the max you’ll get. You need to suspend to disk if you want to swap the battery, it’s not possible to do that in suspend to ram like it was on the PowerBook (G4 500, at least). Sad.
• Heat/fan noise: catastrophic. Fans running at 4000-4200 rpm on a typical desktop or on my laps, down to 3000 rpm on a glass desktop. More on the SMC below.
• ATI drivers: still suck. No PowerPLAY support on amd64, which means the GPU is running at the highest clock rate, consuming a lot of power and generating a lot of heat. XVideo makes the X server segfault, watching a short movie using vlc’s OpenGL output managed to crash the box hard, corrupting part of the kernel memory. fglrx kills the machine on resume.

In a previous post, I was reporting a lot of timeouts from the applesmc “driver”. After a (very) quick look at the AppleSMC kext for OS X, I know why this happens. It looks like the OS X driver uses an interrupt and configures the SMC for that. So it probably doesn’t poll the SMC 20 times per second like the applesmc “driver” does. It also looks like the OS X driver uses SMC keys we know nothing about. I could also confirm that the SMC has access to temperature sensors for the CPU, GPU and memory, but it looks like we have no idea of the corresponding SMC keys. With this information, it’d be possible to switch the SMC to manual mode with a userspace governor. What probably happens when we run Linux on this machine is that the SMC stays in automatic mode, and it’s very conservative in this mode. It won’t hesitate to run the fans at high speed to keep the machine safe. It is highly probable that the OS X driver is taking over the fan control to keep the machine both cool and quiet. This is mostly speculation, as the better device power management in OS X plays a role too, and the SMC could very well still be in automatic mode under OS X keeping the fans at low speed just because the machine generates way less heat. Unfortunately, the AppleSMC kext isn’t released as part of Darwin, so we’ll have to wait until it is. Could be a long wait, though. The SMC handles a lot of things. I don’t feel safe running an OS without a proper driver for the SMC on this machine. The fans probably aren’t designed to run at 4000+ rpm for 3 years and will probably fail early or something.

The first step is to configure the CRM114 files, and these are now in pretty good shape as shipped with Debian. All that I needed to do was set a password, say that I'd use openssl base64 -d, and stick with the less verbose defaults (so no munging subjects, no saving all mail, no saving rejects, etc, since I have other mechanisms that do all that). The comments in the configuration files are plenty good enough. This part went off like a breeze; the results can be found here (most of the values are still the upstream default). The next step was to create new, empty .css files. I have noticed that creating more buckets makes crm114 perform better, so I go with larger than norm crm114 .css files. I have no idea if this is the right thing to do, but I make like Nike and just do it. At some point I'll ask on the crm114-general mailing list.

    % cssutil -b -r -S 4194000 spam.css
    % cssutil -b -r -S 4194000 nonspam.css

Now we have a blank slate; at this time the filter knows nothing, and is equally likely to call something Spam or non-Spam. We are now ready to learn. So, I girded my loins, and set about feeding my whole mail corpus to the filter:

 /usr/share/crm114/mailtrainer.crm               \
   --spam=/backup/classify/Done/Spam/           \
   --good=/backup/classify/Done/Ham/            \
   --repeat=100 --streak=35000                  \
         egrep -i '^ + train Excell Running'

And this failed spectacularly (see bug #399306). Faced with unexpected segment violations, and not being proficient in crm114's rather arcane syntax, I was forced to speculation: I assumed (as it turns out, incorrectly) that if if you throw too many changes at the crm114 database, things rapidly escalate out of control. I went o to postulate that as my mail corpus was gathered over a period of errors, the characteristic of Spam drifted over time, and what I consider Spam has also evolved. So, some parts of the early corpus are at variance with the more recent bits. Based on this assumption, I created a wrapper script which did what Clint has called training to exhaustion -- it iterated over the corpus several times, starting with a small and geometrically increasing chunk size. Given the premise I was working under, it does a good job of training crm114 on a localized window of Spam: it feeds chunks of the corpus to the trainer, with each successive chunk overlapping the previous and succeeding chunks, and ensuring that crm114 is happy at any given chunk of the corpus. Then it doubles the chunk size, and tries goes at it again. All very clever, and all pretty wrong. I also created another script to retrain crm114, which was less exhaustive than the previous one, but did incorporate any further drift in the nature of Spam. I no longer use these scripts; but I would like to record them for posterity as an indication of how far one can take an hypothesis. What it did to was have crm114 learn without segfaulting -- and show me that there was a problem in the corpus. I noticed that in some cases the trainer would find a pair of mail messages, classify them wrongly, and retrain and refute -- iteration after iteration, back and forth. I noticed this when I added the egrep filter above, and was not drowning in the needless chatter from the trainer. It turns out, I had very similar emails (sometimes, even the same email) in the Ham and the Spam corpus, and no wonder crm114 was throwing hissy fits. Having small chunks ensured that I had not too many such errors in any chunk;and crm114 did try to forget a mail differently classified in an older chunk and learn whatever this chunk was trying to teach it. The downside was that the count of the differences between ham nd Spam went down, and the similarities increased -- which meant that the filter was not as good at separating ham and Spam as it could have been. So my much vaunted mail corpus was far from clean -- over the years, I had misclassified mails, been wishy-washy and changed my mind about what was and was not Spam. I have a script that uses md5sums to find duplicate files in a directory, and found, to my horror, that there were scores of duplicates in the corpus. After eliminating outright duplicates, I started examining anything that showed up with an ER (error, refute) tag in the trainer output; on the second iteration of the training script these were likely to be misclassification. I spent days examining my corpus and cleaning it out; and was gratified to see the ratio of differences to similarities between ham and Spam css files climb from a shade under 3 to around 7.35. Next post we'll talk about lessons learned about training, and how a nominal work flow of training on errors and training when classifiers disagree can be set up.

Debian Etch on Asus U5F Model Asus U5F, with Intel Core 2 Duo T5500 Distribution Debian Etch amd64. Summary Video: works, with 3D and everything. Audio: works, with a little config change. Wireless LAN: works, with drivers from non-free. Bluetooth: works. Ethernet: works. SD card reader: works. DVD reader/burner: works. ACPI features: various problems. Suspend: broken. Installation and wireless card To have the wireless card working you need some package from non-free that is not provided with the standard installer. I installed using the binary 1 CD, then I fetched the following packages from unstable:

firmware-ipw3945_0.3_all.deb
ipw3945d_1.7.22-2_amd64.deb
ipw3945-modules-2.6.18-3-amd64_2.6.18+1.1.2-2_amd64.deb
linux-headers-2.6.18-3_2.6.18-8_amd64.deb
linux-image-2.6.18-3-amd64_2.6.18-8_amd64.deb

Once those packages are installed, wireless just works. Video Intel 945GM/GMS/940GML It just works, with 3D and everything. To turn on AIGLX and Compiz, just follow the HOWTO in the Debian wiki. Audio Intel 82801G To make it work add:

options snd-hda-intel model=laptop-eapd

to /etc/modprobe.d/alsa-base. Rationale: this link gives the quick solution. Note: no need to reboot:

/etc/init.d/alsa unload
modprobe snd-hda-intel

The list of models available for the driver is in /usr/share/doc/alsa-base/driver/ALSA-Configuration.txt.gz A hint about the model to use can be found at the beginning of /proc/asound/card0/codec#0. CPU speed scaling Just modprobe speedstep-centrino. Then the cpufreq_ondemand module works fine. I'm a bit disappointed that it doesn't want to go below 996Mhz (60%) and it has only 3 scaling modes: 1.66 GHz, 1.33 GHz, 996 MHz. It used to display available scaling modes weirdly (it would repeat 1.66Ghz 6 times), then I updated the BIOS to version 304 and now it shows just those 3. The laptop tends to get warm, this disappoints me. I hope things will improve with newer kernels. USB Just works. SD card reader Just works. I put an SD card in and it gets mounted automatically. In the old Asus M2 the card reader was just some unsupported obscure thing. Ethernet RTL8111/8168B Gigabit Ethernet. I'm not sure it was working in the installer, but in the installed system it works out of the box. Very pleasant thing: it can cross the cable if needed. DVD reader/writer Just works. I haven't tried burning CDs or DVDs, but k3b sees it and correctly detects the writing speed. Bluetooth Just works. I connected to the bluetooth GPS just fine. ACPI Still quirky. Brightness control buttons don't work: before updating the BIOS I would get this reaction on syslog:

Dec 17 23:57:35 viaza kernel: ACPI Error (psparse-0537): Method parse/execution failed [\_SB_.PCI0.SBRG.EC0_._Q0E] (Node ffff81003e98bd90), AE_NOT_FOUND
Dec 17 23:57:35 viaza kernel: ACPI Error (psargs-0355): [\_SB_.PCI0.P0P2.VGA_.LCDD] Namespace lookup failure, AE_NOT_FOUND

After updating the BIOS I get this reaction instead:

Dec 21 21:17:38 viaza kernel: video device notify
Dec 21 21:17:38 viaza kernel: set_level status: 0
Dec 21 21:17:38 viaza kernel: compiz.real[4013]: segfault at 0000000000000060 rip 000000000040b3b0 rsp 00007fff6c47f4e0 error 4

compiz segfaults and I'm back to gdm, with the brightness unchanged. The LCD on/off button works. Controlling the LCD via software does not work:

# echo 1 > /proc/acpi/asus/lcd
Dec 21 22:22:45 viaza kernel: Asus ACPI: Error switching LCD
# cat /proc/acpi/asus/lcd
Dec 21 22:22:49 viaza kernel: Asus ACPI: Error reading LCD status
0

In fact, asus-acpi complains:

Dec 21 17:08:29 viaza kernel: Asus Laptop ACPI Extras version 0.30
Dec 21 17:08:29 viaza kernel:   unsupported model U5F, trying default values
Dec 21 17:08:29 viaza kernel:   send /proc/acpi/dsdt to the developers

Therefore, I sent the dsdt to the developers. The wireless on/off button turns on and off the wlan and bluetooth leds, and apparently also the wireless hardware. I still don't know how to turn off bluetooth and leave wlan on. Suspend Suspend to ram works, but on resume it does not turn on the LCD display. The LCD on/off button has no effect. Other things work fine, so I can blind-type a shutdown command. I have vbetool installed, but it doesn't seem to help. So far, suspend is still not usable. Modem Not tried.

I am really upset by the way the ARM build daemons are managed. The packages are not uploaded regularly, with sometimes three days between two uploads. Well it should not be a problem, if packages that have failed to build due to some packages not uploaded fast enough (see for example python-gnome, or rkward) were requeued, but that’s actually not the case. Also last week, the build daemon named “cats” stopped to upload packages, despite it continued to build them. 11 days later, nothing has changed even after a mail to arm@buildd.debian.org. And I do not speak about build daemons building nothing. All of that resulted in ARM being the slowest architecture to build packages. It looks like the ARM build daemon maintainer does not know the excellent page made by Jeroen. As arm@buildd.debian.org is everything but responsive (well if you can assign a level of responsiveness to /dev/null), I have decided to act. I have installed QEMU on an 8-way Opteron machine, and created 8 emulated ARM machines, which 256MB of RAM and 10GB of disk for each, all running buildd + sbuild. Altogether those 8 emulated ARM machines should be faster than all the Debian ARM build daemons. I have setup a wanna-build database on my server. During the day it has built around 100 packages. Yes I agree that real machines would be better, but I don’t have a stack of fast ARM machines at home. Anyway when you see random segfaults on the build daemons, or strange failures (that happen for weeks) on the build daemon named “netwinder“, you may think to that again. Unfortunately the machine I use for that is only available for a few months, and I will have to stop the emulated machine then. I just hope that the situation with respect to the build daemons will improve, so that I can stop them even before.

I am still trying to get the ATI drivers to work properly with my X1600 Mobility card. And things are only getting worse. I still cannot get the crt1 output to work, although the driver detects the VGA monitor connected to it. Enabling both lvds and crt1 doesn’t cut it. No, really, it doesn’t fucking work. No signal, no nothing. But now I am getting segfaults every time I try to use a multimedia player, be it vlc or xine, even when explicitely using a good old x11 video output (ie, no XVideo), and the machine won’t resume anymore after a suspend to ram when fglrx is loaded. Gee, instead of releasing such crappy drivers, can’t you just release the specs ? Moreover they won’t accept bug reports from me because the machine is a laptop. Morons.

Yesterday I put my laptop to sleep (on AC power) while I went to the christmas party of a company I worked for. After returning, I couldn't read my email any more; dovecot would segfault after login. Restarting dovecot didn't help, but a reboot helped. Sounds to me as if during sleep, some kernel cache of the dovecot application was corrupted (read only memory; cached by the kernel, which is why it survived the restart of dovecot). Whoa, this is like Windows. Rebooting the computer actually fixed something!

Edit: to be fair to the GCC crew, it seems the guy who closed me the bug to the face was not very representative of'em. Thanks to them to their very good compilation suite btw ! a bit of history I've been bitten today by a problem due to the fact that I use the gcc __attribute__((nonull(...))) as a hint in my C headers to say to the programmer that it's up to him to check if what it pass to my function is NULL, or not. I had written (erouneously) that bit of code:

/* in the .h */
__attribute__((nonnull(1)))
char *m_strrtrim(char *s);
/* in the .c */
char *m_strrtrim(char *s)
 
    ssize_t len = s ? strlen(s) : 0;
    while (len > 1 && isspace((unsigned char)s[len - 1]))
        len--;
    return s + len;
 

I've added the __attribute__((nonnull)) by mistake, and indeed sometimes used m_strrtrim on strings that I knew to be NULL. The point is, gcc is able to use the nonnull attribute to optimize code, and that's very legitimate. In my case, it optimized the s ? strlen(s) : 0 into strlen(s). And without surprise, it caused segfaults. I had a hard time finding that bug, because I've never thought that it could come from the header. As it could not come from the m_strrtrim function, I've looked very hard for stack overwrite and so on in the caller, but even valgrind did not catched anything interesting (except an invalid read size of 1 in strlen). It's when (in order to see if it was a gcc optimization bug) I've generated the preprocessed source that I saw the damn prototype in the preprocessor output, and that was suddently obvious to me why it segfaulted. the wishlist bug Since it was quite an unusual problem, that can make you loose a lot of time, because the bug lies very far from where it's revealed, I've opened a wishlist bug in gcc to ask for a warning when you test some pointer against NULL that you should already know to be non-NULL. like the warning about always true (or always false) comparisons for e.g.:

size_t len;
// ...
if (len >= 0)   ... // always true
if (len < 0)   ... // always false

That's gcc bug#30043. Or I should say was. My bugreport has indeed be closed a first time as INVALID, because the reader thought I said the gcc optimization was not legitimate (*sigh*). I reopened it explaining more precisely that I only begged for a warning, not for anything else, and that YES I DID READ THE DOC. The bug has just been closed as WONTFIX this time, with an explanation that still makes me stare at it with a blank look:

I don't think a warning is the right thing in this case because the developer should have read the documention [ ]

WTF !? If reading the documentation can make you a perfect programmer that never do any mistake, then god, I must be a super-mega-coder that always write perfect code ! Sadly, reading the doc do not prevent you to avoid cuts (aka segfaults) when you juggle with razorblades (aka code in C). I can understand that it's hard to do in the present state of GCC, and that's it's not an urgent feature, given how peculiar that request is. But I'm completely stunned to see that a guy that is in the compiler business just consider that a warning is useless, and that the documentation is the key answer. I use an over-long compilation line in my projects ^{[1] [2]} especially because a compiler is really better than me to catch many kind of errors. And it's vital to do so. I've seen too many people that only compile with gcc -g -O2 and optionnally with -Wall when they don't forget it. But from a guy in the compiler business, well, that's just yet-another-illusion that collapses.

On sunday, I was looking around at the /proc/cpuinfo on one of my last server. I saw that this Pentium 4 had a lot more of cpu flags that the one on my workstation. I discovered the nx flags and its purpose some days before, but I did not know what the lm flags was for... Oh my god, that's the 64 bits support. This box is an amd64 and it was installed as an i386. That's like using a knife to kill a kitten when you have an axe! So, even if the box was 800 km away from me, I decided to reinstall it from scratch, with the help of a serial cable connected on it. That was so easy. I just love Debian for such things.

• Step one: recompile linux-2.6-2.6.18 with support for 64 bits processors, that was easy, Goswin Brederlow made a patch I used and adapted in #379090.
• Step two: scratch your swap and debootstrap an amd64 sarge in it. Copy blindly your /lib/modules/2.6.18-1-amd64 inside.
• Step three: reboot with your 64 bits kernel on your brand new 64 bits Debian system and launch sshd.
• Step four: ask everyone on IRC WHY THE HELL you get sshd killed with a fucking kernel backtrace on your serial console each time you try to ssh to your box
• Step five: listen everyone advices and dist-upgrade to etch
• Step six: backup all the old data and scratch all your partitions, because you want LVM now. And migrating to 64 bits and LVM at the same time is more dangerous, so more exciting, so more fun.
• Step seven: move your brand new amd64 etch into your old root partition. Believe in you and that you did not forget anything to backup.
• Step eight: create your logical volumes and move your stuff in here, like /var, /usr and then blindly reboot. Thanks god you have a serial console.
• Step nine: apt-get install everything back and upgrade your old sarge conffiles to etch.
• Step ten: wonder why slapd is segfaulting again and again, and then yell after this fucking Berkeley DB files that are not architecture independant. Flame yourself because you don't have a LDIF backup of your LDAP tree.
• Step eleven: install a i386 sarge with LDAP to slapcat your old LDAP tree and restore it.
• Step twelve: Take a break. Have a Kit^Wbeer.

In the end, I'm happy, even if everyone is wondering why I killed a server during 10 hours just because it's better.