Another bzr2git example

Today, I tried to switch one of my personal repositories for debian-related scripts from bzr to git, just like I've done for pmount. The trick was that this time, I wanted to only move a part of the repository, not the full repository. I had only been working before with CVS and SVN who have the idea of modules, which is not the case for bzr or git. So I made the mistake of using a single bzr for several projects, which I realize now is not a very good idea...

In any case, I managed to drop some parts and here is how I did it; the trick was precisely to use SVN as an intermediate storage medium, using the following configurations files. First, bzr2svn.conf

[DEFAULT]
verbose = True
patch-name-format = ""

[project]
source = bzr:source
target = svn:target
start-revision = INITIAL
state-file = tailor.state

[bzr:source]
repository = /home/vincent/debian-devel/bzr/scripts

[svn:target]
repository = file:///tmp/testtai
module = biniou

and svn2git.conf:

[DEFAULT]
verbose = True
patch-name-format = ""

[project]
source = svn:source
target = git:target
start-revision = INITIAL
root-directory = /home/vincent/tmp/debian-mr-copyright-mode
state-file = tailor.state

[svn:source]
repository = file:///tmp/testtai
module = biniou/debian-mr-copyright-mode

[git:target]
git-command=/usr/bin/git

Then, all that is left to do is to run tailor on the resulting configuration files:

~ tailor -D -c bzr2svn.conf
~ tailor -D -c svn2git.conf

Sanitizing bad UTF-8

I've hit a problem recently where statsvn does not manage to generate statistics on one of my repositories. After investigation, it turned out that there are some raw latin1 sequences in the XML log file (from a conversion from latin to UTF-8 long time ago), and that makes logfile parsing fail. To sanitize this, I use the following filter:

iconv -c -f UTF-8 -t UTF-8

This way, obnoxious sequences are dropped and processing can go on. (or, at least, could go on if it was not failing just a little later with a Null pointer exception...).

pmount switching to git

I've been neglecting pmount for such a long time I feel ashamed about it. Thanks to tailor and a neat post, I've just switched it to a git repository at git://git.debian.org/git/pmount/pmount.git to get more work done (I don't like bzr too much in the end, don't flame me, it's just a matter of personal taste...). I hope that I'll be able to reduce the amazing number of bugs that have accumulated there...

pdfcrop vs pdfnup --trim

I make heavy use of pdfcrop (the version by Heiko Oberdiek included in texlive) for printing, as it allows to remove all the white spaces around the text before nupping and printing. However, with recent ghostscript, the bounding box detection is dreadfully slow, anything from one to ten seconds for a single page ! When you have a 60 pages article to print, it can be quite tedious...

Well, I've just discovered that the --trim option of pdfnup can do very similar things too. It removes a given amount of margins on the side, with the syntax 'left bottom right top'. Most of the time, a well-thought pdfnup --trim ... will work as well as pdfcrop while in the meantime being much faster...

What ctioga is missing

I haven't posted for a long while about ctioga, but that does not mean that development has stopped. It goes on, and features get added basically every single time I need them. Recent additions make it possible to tune a little more the look of the legends and add pure text lines in them.

I've however realized that now, what ctioga is missing the most is real flexibility over the coordinates. For now, all coordinate positions are either relative to the frame (such as for --inset) or to the graph (for --draw). What I really wish is a way to mix all kind of coordinates: real size (1cm), frame position and graph position. That will require quite a fair deal of work, of course, but that shouldn't be too difficult... I'll go on posting about it here.

CivCTP does not work with 2.6.25 kernels

Well, yes, I'm still playing old games like Civilization Call to Power, because I like... And I've recently had troubles getting it to play on a Debian/sid machine with a 2.6.25 kernel. I seemed to remember it was working fine before that, so I insisted, to the point that I switched back to a 2.6.18 kernel... And that worked ! I don't know what did change, but that is a weird bug indeed...

My lastest fight with udev...

Important note: This post has been modified according to a private remark from Marco d'Itri, thanks to him for his explanations !

I've been trying for a very long while to learn to write udev rules, but I've mostly been unsuccessful, or rather, successful by chance, which is hardly better, as it implies no understanding whatsoever of what I'm doing.

My game, today, was to create a symlink for a loop device (loop7) and set the device's group to cdrom (I might elaborate some time later why I need that). So, here is what I learned:

• at least for the GROUP= directive, the latest item in the /etc/udev/rules.d directory rules
• to test the modifications, the best thing is to generate a synthetic add using the following snippet:

  echo add > /sys/block/loop7/uevent
  

  Many thanks to Marco d'Itri for this information !

With that in mind, the following snippet worked for me, under the name 40-private-loop.rules:

KERNEL=="loop7", SYMLINK="videoloop", GROUP="cdrom"

Enjoy !