Some days ago I wanted to create a page that displays your override bugs against the virtual package ftp.debian.org in a way that allows simple copy pasting the dak command from it. The functionality should be similar to the existing removals page. The result of my work can be seen at http://ftp-master.debian.org/~twerner/override.html. I could not find a HTML/CSS template that looks like an official Debian page - what a pity. That is why I have stripped down the existing removal page and tried to make it more appealing. Finding two colors that suit the background color of our title was another challenge. I hope you like it.

Please don't tell me that my page is using Javascript. It is 2010.

It has been some time since I blogged about something. I wanted to write this post for a while, but never got around. Since beginning of february 2010, I have a new job and got a new work notebook: A shiny Dell Latitude E6400. Interestingly, the company usually relies on getting Lenovo Notebooks due to good Linux support, but we were unable to find a notebook without integrated camera and decent specs. We also researched some HP Notebooks. We ended up with a Dell since the website makes it really easy to find a system that fits your requirements. There is still room for improvement though you still have to select between Vostro, Latitude, Precision Mobile and XPS before you are allowed to configure the system. There is a filter on the left side of the shop, but filtering for a Core 2 Duo and 4 GB RAM won t show you the notebook I got. Instead there is some overpriced Latitude (~ 3000) and an XPS system. I just tried the XPS, but was unable to find a Core 2 Duo processor in the options. Anyway, somehow I made it through and got the following configuration:

Processor	Intel(R) Core(TM)2 Duo CPU P8700 @ 2.53GHz
RAM	4 GB 800MHz DDR2
Graphics	Mobile Intel Integrated Graphics Media Accelerator X4500HD
Display	14.1 Widescreen WXGA+ (1440X900), LED backlight, non-glare
Hard Drive	Seagate ST9250410ASG 250GB
Webcam	None, but microphone fitted
Battery	9-cell 85 Wh
WLAN	Intel Wireless WiFi Link 5100 (according to lspci, I did not care too much)
LAN	Intel 82567LM Gigabit Network Connection

I installed Ubuntu karmic (amd64) the day it arrived and I am impressed. I have yet to find a serious problem with hardware support. Everything just worked out of the box, installation was done after half an hour (I needed 10 minutes to find a network cable since the installer did not support the wireless). I wanted to install Debian on it but so far I did not get around to actually do it. But I expect sid to perform just as well with lenny probably lacking some of the needed drivers. So why am I writing this? The main point is that you can buy a notebook today and have it fully supported wrt. Linux. Open Source has come a long way! Second: If I replace my personal notebook (a Sony Vaio), I will probably buy Dell as well. Definitely nothing from Sony, because I did not find any way to change the display brightness for the 3 years old system, which makes it usable only next to a power outlet.

(This has ended up longer than I intended, largely because I felt I should then get into why. I'm aware I haven't got into all the nuances, so I hope readers familiar with the area will appreciate this is the compact version.)

Thorsten had a rant last week about PGP keysigning problems. He apologises for his tone, but that's not the issue I take with his rant.

It starts "Keysigning is useless". And yet his complaints seem to be:

• Dealing with the private half of your GPG key securely involves some faff (in this case booting with a live CD and having to set things up ready to keysign).
• He doesn't get on with caff.
• People reject email from machines with invalid HELOs and perform other anti spam measures on ISP access ranges (I'm not clear if it's just greylisting or outright rejects as that's not made clear).
• PGP/MIME is a protocol violation (yes, but it's much better than inline OpenPGP. Unless you have to deal with RT, which mangles it. *sigh*)

None of these seem to actually be about keysigning being useless. The process of doing it, maybe, though he misses the main valid rant about this I'd have, which is that most mass keysignings don't actually allow you to accurately verify the identity of other participants unless you already know them reasonably well. (The LCA2010 keysigning and DebConf5 in Helsinki spring to mind as 2 good examples of bad keysignings I've attended, but speaking to others suggests it's far from an isolated thing.)

Torsten does say that he'll continue to do keysigning on a per-person basis, so it doesn't sound like he's completely given up. I'm posting this largely so other Debian related people don't get the idea that it's not important to think about keysigning.

Why should we care?

Firstly, let's clarify what I mean when I sign someone else's key. If I sign your key then I think that I believe you hold the private part of a key that has your name and an email address I believe I can use to contact you on it. It means I have seen government issued ID that matches that name. It also means that I have interacted with you (and watched others interact with you) under that persona. In short I am happy that the key is a reasonable digital representation of your identity - something signed by it either comes from you or has involved the key being compromised or you coerced into using it against your will.

Why is this useful?

It gets useful thanks to the web of trust; ie the idea that there are a bunch of people I trust partially to sign other keys, and if enough of them have signed a key then I can have a reasonable expectation that the key belongs to the person I want to talk to. Which means I might be prepared to send private data to them. Or Debian might be prepared to accept an upload from them. Which, when you're dealing with a community that spans the planet and where most of the contributors haven't met each other, is pretty freakin' useful - I, as part of Debian's keyring team, don't need to personally be able to identify every Debian developer. All I need to do is be able to trust other DDs to be able to do so. (Though maybe I'm missing out on something here - perhaps Debian should be paying for Gunnar and me to travel the world verifying fingerprints. \o/)

(I still do mass keysignings btw. I'm picky about which keys I actually sign - this is in no way intended as a slight against those I don't, but a mass keysigning at least lets me know that the people involved are happy to exchange fingerprints. Though, FWIW, I normally have ID on me and frequently have fingerprint slips, so if you know me and want me to sign your key/want to sign mine then by all means ask me when you see me!)

For quite a while we are receiving TV via Internet. The original reason is that I got at most 2 MBit/s via ADSL due to line noise, but VDSL supports 25 MBit/s on the same line. Of course, you couldn t order the DSL line without also getting a phone flat rate and IPTV. Most of the channels are encrypted and can only be received with the original Media Receiver , which is a proprietary (and Microsoft) solution. But at least, I can watch the public service broadcasts using these playlists for VLC or mplayer.

Recently, Eclipse started ignoring clicks on dialog buttons for me. This seems to be due to some changes in gtk 2.18. It does not use native windows for all widgets anymore, and SWT seems to rely on it. Thanks to this blog post, I have this fix in my bashrc: The Debian bug tracker also knows about this problem, which is partly fixed for the eclipse packages. Bad luck that I am using a download from eclipse.org.

Working on another laptop, I was missing my quiltrc settings. I think, I got them from a this email by Marco d Itri. Perhaps it is of help to somebody (for example, when I go searching for it again). BTW, I changed it locally to check only for debian folder in parent directories and create debian/patches automatically if needed: I d rather end up with a patches dir inside the debian folder instead of having it at a random place in the package sources when adding the first quilt patch. I wonder if we should ship this with the quilt package!?

Most readers probably have installed Debian version 5.0 (Lenny) or an older version and are using shadow passwords with the md5 hash algorithm. This is not bad but not good enough. You can find out the details by looking at /etc/passwd and /etc/shadow (as root). The second column in these files should be a simple character x in /etc/passwd and a string like

$1$biMft/Pr$Lo3zPpiItdLZrzx8t/mTy0

in /etc/shadow. The number 1 between the 1st and 2nd $ sign means md5, the following string biMft/Pr is the salt and the last string Lo3zPpiItdLZrzx8t/mTy0 is the actual hash for the password ('testmd5' in this case). The salt is used to avoid attacks based on precomputed hash tables.

The package pam has switched to the stronger sha512 algorithm in version 1.1.0-2 on 31st august 2009. Look for a line like

password        [success=1 default=ignore]      pam_unix.so obscure sha512

in file /etc/pam.d/common-password if you have installed at least version 1.1.0-2. After changing the password I have the new password string

$6$qjc5gFgK$vaz/gLKMyDuhsVOU2oVIkDZrD0.reJM.2Ft3CMEoAsjN/lenvHC2ls6g/MY1ZaYaYBP3HHDOxel1dvTerl17q1

in /etc/shadow. The number 6 means sha512 and the hash

vaz/gLKMyDuhsVOU2oVIkDZrD0.reJM.2Ft3CMEoAsjNlenvHC2ls6g/MY1ZaYaYBP3HHDOxel1dvTerl17q1

is much longer than before.

The pam_unix module in combination with the sha algorithms allows specifying the number of rounds for hashing the password with the argument rounds=... which defaults to 5000. My current machine needs about 20 milliseconds to hash my password. That can be tested with the command

/usr/bin/time -f %U su testmd5 -c true

I have changed the number to 1 million

password        [success=1 default=ignore]      pam_unix.so obscure sha512 rounds=1000000

to make brute force attacks more difficult. After changing the password again the string is

$6$rounds=1000000$Va4plzLi$EtixueZQ1ZQlzQa7eHHsG6UcNvu.EnuCqM79kIyUe82eAZ.JNegn4SBY1RduYlACs0RWLFHD4d//PzQXMsCqk0

with the number of rounds embedded. The su command needs 1.79 seconds now which is an acceptable delay for the login process considering the improved security.

Don't forget to change the root password too if you have set one.

Ouch! This is the second time I am running into this so I ll write it up this time. I used libtool via automake for building a python module. Quite unhelpfully, libtool happens to build only the static library. It does that even though I passed the -module option, which should make it clear that a static library does not help at all. There is also no mention why it skips the shared library. After some research, my memory came back: libtool requires to pass the -rpath option to actually build shared libraries. I did not want to pass that options, since it is considered harmful where multiple variants of a library are available. It is even less useful in my specific case, as the module is only used inside the source tree for unit testing. Solution: I changed the Makefile.am to use Interestingly, the same scheme (apart from the wording) is used in libtool s own source.

I was working on replacing some mockup code for testing an internal library with python. Basically, the C code is incredibly big and I would rather mock the 3rd party API we are using in python. I wrote a generator to create wrapping code that forwards the C API calls to my python module. Now that most of the work is finished, I get the following error message from my python mock: What s going on here? This issue reminds me of a bug of my ancient Debian times which affected loading of GTK theme engines from python-gtk. The bug (#38138) is so old, it s not even in the BTS archive anymore The problem is illustrated by the following example program (consisting of three files):

demo.c

1 2 3 4 5 6 7

#include <Python.h> void test_python() Py_Initialize(); PyRun_SimpleString("import threading\n");

main.c

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

#include <stdio.h> #include <dlfcn.h> int main(void) const char *error; void *handle = dlopen("./demo.so", RTLD_LAZY EXTRA_RTLD_FLAGS); void (*test_python)(); *(void**) &test_python = dlsym(handle, "test_python"); if ((error = dlerror())) fprintf(stderr, "%s\n", error); return 1; printf("Calling test_python @ %p in shared object @ %p.\n", test_python, handle); (*test_python)(); dlclose(handle); printf("Feels fine, finishing.\n"); return 0;

run_it.sh

1 2 3 4 5 6 7 8 9 10 11 12 13

#! /bin/sh gcc -shared python-config --includes -o demo.so demo.c python-config --ldflags echo "Running example with default RTLD flags:" gcc -DEXTRA_RTLD_FLAGS=0 -o main main.c -ldl ./main echo echo "Passing RTLD_GLOBAL in addition:" gcc -DEXTRA_RTLD_FLAGS=RTLD_GLOBAL -o main main.c -ldl ./main echo

On my system, this results in the following output:

torsten@pulsar:~/sh_bug$ ./run_it.sh
Running example with default RTLD flags:
Calling test_python @ 0xb77084bc in shared object @ 0x96bc018.
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib/python2.5/threading.py", line 11, in <module>
    from time import time as _time, sleep as _sleep
ImportError: /usr/lib/python2.5/lib-dynload/time.so: undefined symbol: PyExc_ValueError
Feels fine, finishing.
Passing RTLD_GLOBAL in addition:
Calling test_python @ 0xb783f4bc in shared object @ 0x95e1018.
Feels fine, finishing.

Sucky. So embedding Python into an application is easy but if you want to use the interpreter and its modules from a plugin, you are out of luck. Somebody knows a way around this problem? The only solution I can think of is to link libpython.so into each of the python plugins. Update: Work around Small update: For my current problem, the work around is to run the application with the python library preloaded: LD_PRELOAD=/usr/lib/libpython2.5.so.1.0 app. Back to adding functionality

I am moving from my old Debian development system to a new one, changing architectures from i386 to amd64. So I need to do a fresh install, but basically I want to keep my package selection. Conventional wisdom is to use dpkg --get-selections and dpkg --set-selections to preserve the package selection. However, this does not keep the information about automatically installed packages. Instead, I used

aptitude search '?installed?not(?automatic)' -F %p > packages.txt

to dump the packages I installed manually. Installing these was a matter of running:

aptitude install  cat packages.txt 

In fact this was taking so long that I loaded the packages in batches using

cat packages.txt xargs -n 100 aptitude install --schedule-only; aptitude

While I was at it, it ran

aptitude remove '?obsolete'

on the original system, killing of a few hundred packages that accumulated since 2003.

Great, I spent a few hours today to set up a nice OpenVPN server. Nice in that I wanted the (Windows) clients to be able to access the company network like they were connected locally. My idea was to use the OpenVPN tap mode and let the DHCP server at work assign IPs to the VPN clients. This turned out to be a dumb idea. After I got everything going, I noticed the following message in syslog (which probably scrolled by previously in the debug drivel):

NOTE: your local LAN uses the extremely common subnet address 192.168.0.x or 192.168.1.x. Be aware that this might create routing conflicts if you connect to the VPN server from public locations such as internet cafes that use the same subnet.

Hmm, sure, I guess that will exclude every second incoming VPN connection. Summary: Think about IP space clashes before setting up a VPN.

Now that there is some content here, I added myself to the Planet Debian blog aggregator. Sorry for my weird head image, the shadow looked much better in Gimp. I ll have to correct that on another day Thanks to Holger Levsen for pointing me at the wiki entry which describes how a Debian developer can add himself to the Planet.

I got a new computer at home a week ago and finally got around to assemble all the parts. Which wasn t as easy as expected, especially fitting the CPU cooler was a hard fight. Specs For the curious, here are the specs:

CPU

AMD Phenom II X4 965 (4 3.4 GHz)

Mainboard

MSI 790GX-G65

Graphics

ATI Radeon HD 3300 (on-board)

RAM

8 GB, DDR3

Hard drives

2x SATA 1.5 TB (by Western Digital)

Ubuntu installation For testing and having a first look, I installed Ubuntu karmic koala (amd64). Installation went like a breeze, everything was detected and worked out of the box. Well, kind of graphics performance was dreadful. Which was kind of expected. Debian installation I originally thought about using Debian only inside virtual machines or change roots. Still, Ubuntu does not really feel like the real thing . So I went to install Debian, aiming at a sid/unstable installation. The first boot using the official squeeze snapshot netinst image (Binary-1 20091128-11:21) went fine. Up to the first prompt: No input was possible. Probably a problem with the USB keyboard I had connected (Logitech wireless). Out of curiosity I tried the graphical installer, which did not even get so far. It was stuck in an endless loop trying to start an X11 server. So I dug for a PS/2 connected keyboard and had more luck. I got to the point where the installer searches for the CD-ROM drive. As I did not want to dismantle my old system yet, I used an external USB DVD/RW drive. This was not detected by the installer so I was unable to continue installation. I guess, the NIC driver was also on the disc so no ethernet either. Today I installed the DVD burner into the tower and had more luck. It still amazes me how easy it is to create my default storage setup using d-i (LVM on RAID). However, the installer failed to reread the partitions after I created two on each drive, interestingly telling me about /dev/sda2 being busy. Perhaps a left-over swap partition from the Ubuntu install? Anyway, after running fdisk manually and writing the same partition table again, I was able to continue. The remaining d-i steps went fine, with just a nuisance: I was asked for the console font setting twice. And I had no idea what it was asking of me, AFAIK UTF-8 should be fine for all possible uses. I selected # Latin1 and Latin5 western Europe and Turkic languages. Not that I will see the console unless Xorg fails to run After having the base system running, I rebooted without selecting any more software, partly because I knew that the resync on md1 will need restarting after booting into the new system. The new system booted fine and I called aptitude to install build-essential, Xorg and both KDE and Gnome desktops. This pulled in MySQL via akonadi-server (ouch!) and I was asked for a MySQL root password. Seriously, I don t care, this is a desktop system. I tend to forget the password anyway and the last time, root was able to reset it. So I just hit Enter, leaving no password set. This lead to the installation asking me two more times for the password, which really sucks given that the server is only used by Akonadi for whatever reason and the last time I looked, it creates its own MySQL configuration. Albeit my old system is 8 years old, the new system still seemed slower. Which of course is due to disk latencies, given that /dev/md1 was being synchronized in the background. Anyway, I was eager to test the desktop experience and started gdm. X came up fine, but again I had no mouse and no keyboard (USB mouse, keyboard connected as well as PS/2 keyboard). I also was unable to switch to a VT, so I logged in remotely and rebooted the new system. After the reboot, hal obviously picked up the input devices and X11 worked fine now. At this point, I stopped as the sunday almost passed already. Summary: Debian installation still needs some improvements I think. Maybe our distribution is just too stable, after all my last install is 3 years back due to a disk crash Relevant Debian bugs

• #558679: My installation report with some logs included.
• #558681: Nagging about MySQL root password.
• #558686: Failure to reload partition table.
• #545933: No USB keyboard support
• #315553: Installation from optical drive on usb fails (but this is for kernel 2.4)
• #558691: No keyboard and mouse after fresh installation of xserver-xorg.

Since some days we keep packages of Architecture: all in the archive as long as they are needed. You can find some details about that in my former post:
dak dominate will dodadoda the Debian archive soon.

The package that could currently profit most from that change is rpm! But the package dependencies are actually not strong enough. The source package rpm builds some arch all packages like rpm-common and several arch any packages and some of them (rpm, librpm0) have an unversioned field
Depends: rpm-common.
This dependency can be improved to
Depends: rpm-common (= $ source:Version )
to avoid nasty bugs after upgrading.

I fear that we have more of such packages in Debian.

This blog post is about fixing the bug #246992: 'arch all package available before arch any dependancy'. What does that mean: we will keep multiple versions of arch all and source packages per suite as long as older arch 'any' package are still available because maybe newer versions haven't been built by the buildds yet. That means that packages from the unstable suite will always be installable in the future.

The old code in make_suite_file_list.py has been replaced by generate_filelist.py and dominate.py. The first one is generating the file lists for apt-ftparchive and the second one removes obsolete packages from the database. The code in make_suite_file_list.py has been written by people that are no longer members of the ftpteam. Its main control function has a nice name: do_da_do_da(). The new script dominate.py still ships with a small function doDaDoDa() as a reminiscence to our forefathers.

My code has been merged into dak and will be activated on ftp-master.debian.org soon. It can't re-add packages that have already been removed in the past but is will make the archive more friendly in the future. Unfortunately it will leave more cruft in the archive that cannot be cleaned fully automatically. We will need your help to find such corner cases. Please report any errors in the archive as a bug report against the virtual package 'ftp.debian.org'.

More information about the topic can be found in ftpteam's wiki.

I think this was my first contribution to the Debian operating system:

grace  (5.0.3-1) unstable; urgency=low

* added Replaces: xmgr, closes #35010, #42115, the only conflicting
  file is the grconvert binary which is identical in both packages
* changed editor to sensible-editor
* redebianized using dh_make and debhelper
* new upstream, closes: #41146, #27308, #28944, #29705, #38214
* NMU

-- Torsten Werner   Mon, 6 Sep 1999 22:19:04 +0200

That was 10 years ago. By the way the package is still in the distribution but orphaned now. Please note that our bug numbers had 5 digits only!

I don't want to count the packages that I am involved today but I am concentrating on Java related stuff. We got OpenJDK into Lenny and since DebConf9 it is our default JDK. Thanks to the recent work of Ludovic Claude we can use Maven for building official Debian packages. That will hopefully make packaging easier for many packages where upstream is using Maven as the build tool. I recommend joining the debian-java list if you are interested in those topics.

And I am a member of the FTP team today which is a great honour. It is quite
some extra work but we are now closer to the 1 week waiting time for NEW
processing (on average). Processing NEW is another place where I could see that
times are changing: this week I accepted a package (c) Microsoft Corporation
into Debian main what seemed to be impossible ten years ago.

The strongly connected set of the GPG keys graph contains a bit more than 40000 keys now (yes, that’s a lot of geeks!). I wondered what was the biggest clique (complete subgraph) in that graph, and also of course the biggest clique I was in. It’s easy to grab the whole web of trust there. Finding the maximum clique in a graph is NP-complete, but there are algorithms that work quite well for small instances (and you don’t need to consider all 40000 keys: to be in a clique of n keys, a key must have at least n-1 signatures, so it’s easy to simplify the graph — if you find a clique with 20 keys, you can remove all keys that have less than 19 signatures). My first googling result pointed to Ashay Dharwadker’s solver implementation (which also proves P=NP ;). Googling further allowed me to find the solver provided with the DIMACS benchmarks. It’s clearly not the state of the art, but it was enough in my case (allowed to find the result almost immediately). The biggest clique contains 47 keys. However, it looks like someone had fun, and injected a lot of bogus keys in the keyring. See the clique. So I ignored those keys, and re-ran the solver. And guess what’s the size of the biggest “real” clique? Yes. 42. Here are the winners:

CF3401A9 Elmar Hoffmann
AF260AB1 Florian Zumbiehl
454C864C Moritz Lapp
E6AB2957 Tilman Koschnick
A0ED982D Christian Brueffer
5A35FD42 Christoph Ulrich Scholler
514B3E7C Florian Ernst
AB0CB8C0 Frank Mohr
797EBFAB Enrico Zini
A521F8B5 Manuel Zeise
57E19B02 Thomas Glanzmann
3096372C Michael Fladerer
E63CD6D6 Daniel Hess
A244C858 Torsten Marek
82FB4EAD Timo Weing rtner
1EEF26F4 Christoph Ulrich Scholler
AAE6022E Karlheinz Geyer
EA2D2C41 Mattia Dongili
FCC5040F Stephan Beyer
6B79D401 Giunchedi Filippo
74B11360 Frank Mohr
94C09C7F Peter Palfrader
2274C4DA Andreas Priesz
3B443922 Mathias Rachor
C54BD798 Helmut Grohne
9DE1EEB1 Marc Brockschmidt
41CF0322 Christoph Reeg
218D18D7 Robert Schiele
0DCB0431 Daniel Hess
B84EF12A Mathias Rachor
FD6A8D9D Andreas Madsack
67007C30 Bernd Paysan
9978AF86 Christoph Probst
BD8B050D Roland Rosenfeld
E3DB4EA7 Christian Barth
E263FCD4 Kurt Gramlich
0E6D09CE Mathias Rachor
2A623F72 Christoph Probst
E05C21AF Sebastian Inacker
5D64F870 Martin Zobel-Helas
248AEB73 Rene Engelhard
9C67CD96 Torsten Veller

It’s likely that this happened thanks to a very successful key signing party somewhere in germany (looking at the email addresses). [Update: It was the LinuxTag 2005 KSP.] It might be a nice challenge to beat that clique during next Debconf ;) And the biggest clique I’m in contains 23 keys. Not too bad.

Software becomes more and more important in science as in other areas of life. Scientist have a tradition to publish their work very openly but that does often not include the source code of the software that was developed to carry out simulations which has some obvious problems such as:
- other scientists cannot check the software for errors,
- other scientists cannot fix the bugs and easily reproduce the results,
- other scientists cannot base their new research on already existing software and have to write it completely from scratch again and again,
- software package from different authors cannot be combined easily.

But things are getting better. One field of scientific research where we can see some improvement is machine learning - http://en.wikipedia.org/wiki/Machine_learning which is a broad subfield of artificial intelligence and concerned with the design and development of algorithms and techniques that allow computers to "learn". S ren Sonnenburg et.al. wrote a paper about "The Need for Open Source Software in Machine Learning" which is available at http://jmlr.csail.mit.edu/papers/v8/sonnenburg07a.html. They even created a portal with the goal to support a community creating a comprehensive open source machine learning environment at http://mloss.org.

An increasing number of software package are available in Debian like
- some simple-to-use utilities to apply compression techniques to the process of discovering and learning patterns: http://packages.debian.org/sid/complearn-gui
- a python package for convex optimization: http://packages.debian.org/sid/python-cvxopt
- a library for support vector machines: http://packages.debian.org/sid/libsvm2
- a machine-learning library: http://packages.debian.org/sid/libtorch3-dev
- an object-oriented programming language designed for researchers, experimenters, and engineers interested in large-scale numerical and graphic applications: http://packages.debian.org/sid/lush
- a large scale machine learning toolbox: http://packages.debian.org/sid/shogun-python-modular
- a data mining software in java: http://packages.debian.org/sid/weka

I'd like to know if you are using some of the packages or some other scientific software in Debian. Feel free to leave comment. Or maybe you are missing something in Debian?

If you are an author or user of some free software related to the topic of machine learning please consider registering it at http://mloss.org.

Some days ago I wrote down my experiences with packaging docbook-defguide. The main (remaining) issues I mentioned were the resources and the time the package needs to build. Even on an AMD X2 4600+ with 6GB of RAM it needs 7-8 hours. Today I met with Torsten Werner. He mentioned, that there are some move JVMs I could try. So I tested alternatives to GIJ this night. I found this short summary about free JVMs, which was some kind of interesting. I began with cacao, which seemed to be fast, but it was killed very early in the build process with an java.lang.OutOfMemory error. Even playing around with the -Xms and -Xmx switches in buildtools/saxon.sh did not help. So I dropped cacao from the list. Seems both cacao and kaffe create similar problems here and are not suitable for building the package. Second alternative I tried was sablevm. It directly throw out some warnings or errors so I directly dropped it too. Next JVM was jamvm. But it was as slow as GIJ. So I dropped it from the list of alternatives too. Then I found an interesting statement in the article I linked somewhere above. The author said, that his perfomance test time with GCJ/GIJ reduced from 433 to 9 seconds, when he compiled his application into a native executable. So I took a fast look through the docbook-defguide build dependencies and found, that Debian already provides a natively compiled Xerces package libxerces2-java-gcj. But there were no packages for libsaxon-java, libxml-commons-resolver1.1-java and docbook-xsl-saxon. So short and dirty: I downloaded the source for these packages, added the necessary stuff to get natively compiled packages too, built and installed them. Fortunately packages with native code already exist (JAXP 1.3 and Xerces) for their dependencies. And what should I say: Now building the TDG needs less then 512MB RAM and it builds in around an hour … even on my system. I will ask the Debian Java maintainers to add -gcj packages for Saxon and XML-Commons and fix my own docbook-xsl-saxon package. This will hopefully help maintaining docbook-defguide.

IcedTea is the 100% free variant of Sun's OpenJDK. I have ported the existing Ubuntu package 'icedtea-java7' to Debian. My inofficial package is currently available at http://people.debian.org/~twerner/ for the architectures amd64 and i386. I do not plan to upload it to Debian.