Creating and booting an ia32 debian system from an amd64 one

I've recently gone back to use wine to play "old" Windows games. Unfortunately, Morrowind, the one I'd like to play - really great one, if I daresay, is not working on my computer, though it should, according to its AppDB page. I tweaked wine's configuration, but no success so far. I decided it would be worth to try from within a real IA32 environment, just to check if that could be a bug linked to this. So, today's game is to create an IA32 debian system from my own, set it up and boot it.

First thing, create a i386 chroot using debootstrap:

debootstrap --arch=i386 sid /chroots http://ftp.fr.debian.org/debian

The target, here /chroots must be the root directory of a given device -- else booting won't work. Then, you must set up a proper /etc/fstab file, so it actually can mount things once you've decided to boot it.

Then, for fun, I've decided to cross-compile the kernel I would be using, so, after download/extracting recent kernel source, this is what I did. First, spawn the configuration tool:

make xconfig ARCH=i386
make -j2 ARCH=i386 

Then, I copied the kernel images using

cp arch/i386/boot/bzImage /chroots/boot/vmlinux
cp arch/i386/boot/compressed/vmlinux.bin /chroots/boot

The latter is important for the kexec kernel call. I also copied the kernel sources from the current system to the chroot, so as to be able to build kernel modules in the target system. Then, I did use the kexec utility to boot my new kernel:

telinit 1
kexec -l /chroots/boot/vmlinux.bin --append=root=0342
kexec -e

And there you go !! Then, you probably need to setup new users and also configure the network (try to copy from your current config).

So I did all this, to finally realize that it didn't work any better with a full ia32 system... Pity !

A very annoying sound bug - and a workaround

Quite some time ago, I posted a bug report against ALSA because my sound would lock from time to time. No error message from any program using the sound, but they simply hang, and nothing is to be heard. I tracked the problem down to a blocking call to a semaphore operation, for all programs that were concerned. The thing was that I could not find a way to recover from this situation until the computer was rebooted, which, admittedly, is very painful. However, I found a way to do so today: you can actually kill semaphores by hand using ipcrm. If that happens, have a look in your /proc/sysvipc/sem file:

~ cat /proc/sysvipc/sem 
       key      semid perms      nsems   uid   gid  cuid  cgid      otime      ctime
   5678293     163840   660          1  1000    29  1000  1000 1201199302 1201198890

The only semaphore listed here is the one we're interested about. Kill it with the following command-line (probably only works as root):

~ ipcrm -S 5678293

And then, magic ! Sound works again !

The real limitation of Qt...

I've been posting here quite often that I like using this wonderful GUI library that is Qt. I've always found it really comfortable to work with. But it looks like I've finally hit a limitation:

[  5%] QT Wrapped File
/home/vincent/Prog/UltimateRipper/src/genericcombo.hh:26: Error: Template classes not supported by Q_OBJECT
make[2]: *** [moc_genericcombo.cxx] Error 1
make[1]: *** [CMakeFiles/ur.dir/all] Error 2
make: *** [all] Error 2

I knew that it is technically delicate to deal with that... I hope they had found a solution. Well, pity. After all, there must be a very good reason why they wrote so much code for QVariant, to provide an alternative to templates. Pity ! I'll have to go on with this class without specific signals/slots.

A bzr repository for my debian-related works

I'm always scripting quite a lot, and I always store them in SVN in my personal backed-up server. However, it is not very convenient for sharing, as it is not always on and completely locked anyway. So I thought I could rather use a bzr repository on people.debian.org. I did set it up yesterday. There probably will be several branches in the future, but there currently is only one:

bzr branch http://people.debian.org/~fourmond/bzr/scripts

It currently contains one script, rdebsums that runs debsums on one package and on all its dependencies. It is the answer to a wishlist bug I submitted long ago against debsums. Enjoy !

Find all package from a repository that install a file somewhere

As I'm trying to provide a much cleaner way to wrap java programs into scripts for Debian, I need to know how many of the package maintained by the Debian Java Team install scripts in /usr/bin/. I first thought that the way to go was to use apt-file for doing so, running apt-file show on each package found in the repository. Bad idea: it takes, say, 10 seconds to run apt-file show on my machine. Mutliply that by around 600 binary packages, it takes some time.

So, I wrote a script based on the same idea (using Contents files, see apt-file(1)) that does the both the lookup of all binary packages produced by source trees present in the current directory and looking up a pattern in the Contents file. You can download it here. Typical uses:

• find all binary packages generated from source tree in the current directory:

  find-packages
  

• find all of them that install a file in /usr/bin:

  find-packages usr/bin ~/.apt-file/ftp.fr.debian.org_debian_dists_unstable_Contents-amd64.gz
  

  The file ~/.apt-file/ftp.fr.debian.org_..._Contents-amd64.gz or a similar one can be found in apt-file's cache.

Meanwhile, out of nearly 600 packages, there are only 61 binaries out of 35 packages. Java packages are mostly libraries, then.

Tioga and text sizes

Tioga is powerful, as I undoubtedly mentioned here already. But, so far, it had a dreadful drawback: it was not possible to know the (TeX) text size other than by guesswork. This has now changed: starting from revision 453, it can find out and provide the information. All you need to do is to give a 'measure' => 'name' argument to show_text, and you can get information about the text size using get_text_size('name'). I used this new feature in figures.rb for a small demonstration:

    def text_size
      t.stroke_rect(0,0,1,1)
      t.rescale(0.5)

      equation = '\int_{-\infty}^{\infty} \! e^{-x^{2}}\, \! dx = \sqrt{\pi}'
      text = "\\fbox{$\\displaystyle #{equation}$}"

      nb = 5
      nb.times do |i|
        scale = 0.5 + i * 0.2
        angle = i * 37
        x = (i+1)/(nb+1.0)
        y = x
        color = [1.0 - i * 0.2, i*0.2, 0]
        t.show_text('text' => text, 'color' => color, 'x' => x, 
                    'y' => x,
                    'alignment' => ALIGNED_AT_MIDHEIGHT,
                    'scale' => scale , 'measure' => "box#{i}", 
                    'angle' => angle )
        size = t.get_text_size("box#{i}")
        w = size['width']
        h = size['height']
        t.stroke_color = color
        t.stroke_rect(x - w/2, x - h/2, w, h)
      end
    end

This works really simply: Tioga uses a wrapper TeX function that displays the size of the text on pdflatex output. If Tioga detects that a size was requested, it fills in the information, gives it back to the program via get_text_size and runs pdflatex a second time use the information. For the first call, dummy values are given by get_text_size. It seems that the last showstopper of Tioga has finally fallen today !

Team work...

I don't know how it feels for you, but that starts to look like team work:

a7xpg (0.11.dfsg1-3) unstable; urgency=low

  [ Barry deFreese ]
  * Add watch file

  [ Jon Dowland ]
  * Add Homepage: control field to source stanza

  [ Peter De Wachter ]
  * Don't abort if the audio device couldn't be opened. (Closes: #448786)
  * Fixed link command, patch from Arthur Loiret. (Closes: #458277)

  [ Miriam Ruiz ]
  * Added XS-DM-Upload-Allowed tag to control to allow uploads from Debian
    Maintainers.

  [ Vincent Fourmond ]
  * Added myself to Uploaders
  * Fixed Vcs* fields and remove stale Homepage fields

 -- Vincent Fourmond   Thu, 03 Jan 2008 14:14:15 +0100

The Debian Games Team is pretty dynamic, I'd say.

lighttpd + debarchiver + dput: very good combination for local archives

I've grown pretty much accustomed to cowbuilder. In fact, I nearly build all my packages this way. I seldom have lots of coding/testing to do on my packages, so I don't want to clutter my machine with loads of unneeded build-depends... Especially when it comes to java packages. And the thing is that the current version of batik does not build with versions 1.5 and 1.6 of Sun's Java: an earlier one is apparently necessary (I don't have time to dig into this yet). So, I need a cowbuilder with sun-j2sdk1.4. As the latter is not on public archives, cowbuilder will not find it and fail. Hence, the need for a private personal archive. I found the combination of lighttpd, debarchiver and dput very convenient to setup and keep a personal archive. It is the combination that needs the less configuration, and just works !

First, install lighttpd, dput and debarchiver. I used /var/local/debian as my local repository root, so I made sure the directory existed and that I had write access on it with my normal user. Then, configuration of debarchiver; you only need to modify two lines in /etc/debarchiver.conf:

$destdir = "/var/local/debian/dists";
$inputdir = "/var/local/debian/incoming";

Running debarchiver as a normal user once creates the directories, so you don't need to bother about that yourself. You probably should also modify the line containing @mailtos if you want dak-like email notices. I used the folllowing:

@mailtos = ('root@localhost');

Next step is to make dput aware of this local repository. Here is the relevant part of my $HOME/.dput.cf:

[local]
fqdn = localhost
incoming = /var/local/debian/incoming
method = local
run_dinstall = 0
post_upload_command = debarchiver -x

The -x is very important as is asks debarchiver to rebuild the package index, so your packages are available immediately. The last bit now is to make lighttpd serve the repository. I simply symlinked /var/local/debian into /var/www, and now I use that in my sources.list:

deb http://localhost/debian unstable main contrib non-free

And everything works perfectly well ! Very easy to install and configure.

(pre-)Introducing jardeps

Since I've joined the Debian Java Team, I've been working on a script to get as much information for packaging as we could get from jar files, such as their possible dependencies and so on. I've come up with a pretty neat tool, jardeps, based on jclassinfo, that can provide quite some information about java archives:

• list classes/methods the archive provides
• look for dependencies in other jars (still very rough, or way too slow)
• and, what I've been working on recently, a way to spot differences in the interface/dependencies between two version of a package, a sort of debdiff for Java classes

I won't post the code yet, but I'll introduce it on the Java mailing lists as soon as jclassinfo makes it through the NEW queue (which it probably should have done today had I been more careful about copyright notices).