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).

Debian java packaging and jclassinfo

I've become more and more interested in packaging Java programs recently, and I find that it is not easy for several reasons:

• There are at least half a dozen java implementation, some free, others non-free, with slightly different standard libraries. I find it all very confusing and error-prone.
• A fair amount of Java packages depend Sun's Swing graphical user interface, and some others depend on Sun's XML parsing (at least as I understand it); they must therefore go to contrib
• Java programs need script wrappers, often rather ugly, even more hackish and definitely not reusable/reused
• There is currently no way to find dependencies of a Java package

I've nearly finished to package jclassinfo, a very useful tool that could bring an answer to some of the problems above, by extracting dependency information from class files. With its help, it could be possible to write something like dh_shlibdeps for Java classes. This would bring a real solution to the dependency problem, and possibly help as well for the main/contrib fight. More information later.