Instances of the for those who care about X snowclone on Debian mailing lists:

• their packages in Ubuntu (the original!)
• lesbians
• Andrew Suffield
• debian-devel-announce
• their packages in klik
• the [GFDL] GR
• stable updates
• bits from [press and events] teams
• glib applications
• experimental
• Debconf
• Policy 7.6
• Switzerland/Liechtenstein
• X
• firmware
• bts-link
• lesbians (reloaded)
• pam-ssh
• Mercurial
• manpages
• their packages in Debian
• unbound
• irker
• [team metrics] statistics

(update: yesterday's version was using http://wiki.debian.org/Teams/ReleaseTeam as reference, while http://www.debian.org/intro/organization is the one that's up-to-date. Those watching the current traffic in debian-release can probably realize the huge *thank you* deserved by the entire release team for the work they're doing. So, how about spamming the release team members with (private!) "thank you" messages when they unblock a package of yours? And (even more difficult) also one when they don't unblock your package...but spent time reviewing it and more time to explain you why they prefer not unblocking it... In any case, thank you, Neil Maulkin, Adam adsb, Dann dannf, Felipe faw, Jurij trave11er, Luk luk, Mehdi mehdi, Pierre MadCoder, Julien jcristau (doh, French Cabal!)...and Martin zobel (who's apparently forgotten on the page). Not to forget Adam adsb and Phil phil for managing stable releases....and the Wise Release Wizards (vorlon, aba, luk, HE). Hat off, guys (only guys there, yet another place for d-w to show up).

Those watching the current traffic in debian-release can probably realize the huge *thank you* deserved by the entire release team for the work they're doing. So, how about spamming the release team members with (private!) "thank you" messages when they unblock a package of yours? And (even more difficult) also one when they don't unblock your package...but spent time reviewing it and more time to explain you why they prefer not unblocking it... In any case, thank you, Neil Maulkin, Adam adsb, Dann dannf, Felipe faw, Jurij trave11er, Luk luk, Mehdi mehdi, Pierre MadCoder, Julien jcristau (doh, French Cabal!). Not to forget Adam adsb and Phil phil for managing stable releases....and the Wise Release Wizards (vorlon, aba, HE). Hat off....

In the productive procrastination department: I repackaged rcs using debhelper (it feels like the future) and while I was at it, I implemented MadCoder's git maintenance scheme where changes from upstream are maintained in a rebased integration branch and serialized as patches in the Debian branch (master in my case) using git format-patch. It's pretty nice:

• I can use native Git commands to edit/refresh patches, which beats quilt any day;
• Changes to upstream are visible both as a git branch and as separated, commented patches in the Debian branch;
• If necessary (e.g. in case of NMU), outside contributors can just dump a -p1 patch in debian/patches and be done with it.

Of course this is a very low-maintenance package (the last upstream release was 13 years ago) so it doesn't matter very much which maintenance strategy it uses, but after implementing it I'm pretty confident that it works and I might switch my other packages to it.

If you're interested in knowing more about clever ways to use modern VCS for packaging, you may want to join the vcs-pkg mailing-list.

I apply (2007-07-26)
I am advocated (2007-07-26)
Mail from FD(myon) (2007-08-12)
I reply (2007-08-15)
FD(myon) says OK (2007-08-17)
AM assigned (2007-12-05)
First mails from my AM(white) (2007-12-06)
ID check done (2007-12-07)
P&P1 check done (2007-12-21)
P&P2 check done (2008-01-17)
T&S1 check done (2008-05-04)
T&S2 check done (2008-05-13)
AM report (2008-05-13)
FD(wouter) check done (2008-07-23)
DAM(myon) approval (2008-09-03)
Account created by DSA(weasel) (2008-09-08)
Debian Beer/Pastis Party in Marseille (2008-09-15) Thanks to all Debian people in particular opal, lmamane, white, madcoder, myon, wouter and weasel.

Following the recent post about my issues with byte swapping on amd64, I have received several answers.. Since comments were broken, Rupert sent me a good explanation of the cryptic code from OSS4. Let me remember you what it was doing: The code is indeed very simple, but it has to be decomposed carefully.. First, the author assumes that unsigned char = one byte, which seems reasonable. Then, a is initialised at the second character of the two-characters value x, and b on the first of the returned (swapped) value y. Now, the two cryptic lines can be decomposed as follows: *(b++) = *(a--), which literally means "put in b the value from a, and then increase b and decrease a. When executing the second line, a points to the first character from x, and b to the second from y. As Rupert noticed, the second call could simply have been *b = *a, but this wouldn't have been l33t enough :) Now, about the original code, namely (x 8) (x >> 8), MadCoder (salut !), as well as another anonymous comment both suggested that this would be a type error. Indeed, I had noticed the wrong right shift, but no matter how I tried, with or without mask, with unsigned short, short, or uint16_t, as suggested by MadCoder, I always get the same corrupted sound.. So, thanks for your comments, I'm now trying to dig the issue down in the code that makes use of this function. Most likely the issue comes from a wrong transtyping there.. I am also wondering what's the efficiency of the above OSS4's code with regard to (x 8) (x >> 8). Any idea ? PS: Yes, text on comments are mangled a lot. This is a basic safehtml protection, and I don't have the control over it, sorry..

  (1:55) 
  [artemis] sudo dpkg --purge ion3 ion3-scripts
 [sudo] password for madcoder: 
 (Reading database ... 126510 files and directories currently installed.)
 Removing ion3-scripts ...
 Purging configuration files for ion3-scripts ...
 Removing ion3 ...
 Purging configuration files for ion3 ...
 dpkg - warning: while removing ion3, directory  /etc/X11/ion3' not empty so not removed.
 dpkg - warning: while removing ion3, directory  /usr/lib/ion3/lc' not empty so not removed.
 Processing triggers for menu ...
 Processing triggers for man-db ...
 sudo dpkg --purge ion3 ion3-scripts  1,25s user 1,19s system 12% cpu 19,539 total

AAAAAAAAAAAAAAHHHHHHHHHHHHHHHHHHHHHHHHH I feel better now. I'm right now a proud awesome-3-git user. The current git version has 90% of what I used in ion3. I mostly mis tabs, but I'm almost already used not to have them anymore, tiling is way better after all, and there are pure lua implementations of those around, just the current one are not nice enough (IMHO) but it can only improve. Another missing feature is autocompletion in the launch command / ssh to / ... menus. But I assume this would not really be hard to add. OTOH there are already things that I like better in awesome: it's easier to extend than ion3, the widgets are a fantastic idea, it uses antialiased fonts, and so on. And layouts are a really clever idea for sure. See here to see what it can look like.

I've take some time this morning to work on xcb-util packaging. I've mainly urge that work because Sebastian Dr ge, the sweet cairo maintainer, agreed to enable the cairo XCB backend (#474353), which requires xcb-util. The first upload I've made was built from the latest upstream release which is old (i.e. more than one year old). So I've put a git repository in place this morning and packaged the latest git upstream version, with some good patches from Arnaud (upstream+patches branch), that the upstream XCB developers are still reviewing since several weeks: that is the cost to pay for good code quality Thanks to Sebastian, the new xcb-util targeted for unstable was just arrived in incoming that he already uploaded a new version of the Debian cairo package with XCB backend enabled. Well, that's a very good day for me since it means that building awesome 3 is no more a PITA (hi MadCoder!) since every dependency is available in the Debian archive.

Following Martin's post on the subject, since I created my prompt, I've updated quite a lot. It only showed the branch before, now it does so even when I'm on a detached head or something, and also shows when I'm in the middle of a rebase or a merge. You can see the zsh-fu for this. For example, when I'm in the middle of a rebase on my paid work repository, it looks like:

 (10:34) <~/dev/mmsx master <rebase -i>> 
 [artemis]                                                 (~/dev/mmsx/Build/)

With nice colors I cannot really show without a screenshot that I'm too lazy to do :) This is a recent addition that I shamelessly took from the contrib bash prompt in git-core package. And to be frank it's really needed, because it's cheap tests (basically looking for magic file names) and that it can tell you if you forgot to end a rebase or a merge, which can happen if you have been disturbed in the middle of it by a colleague for example. I liked the '*' idea from Martin to show if the tree is dirty. Sadly it's not an option. Martin, to do that, you can do:

 unclean=
 git diff-files --quiet && git diff-index --cached --quiet HEAD --   unclean='*'

But this is a very expensive operation. On the glibc git repository, it takes seconds with cold cache (and it's not very surprising because it basically has to stat(3) a lot of stuff). And not having a shell for seconds is a bit extreme. PS: I know my prompt only supports git, but:

1. I barely care about other VCSes as I only use git and sometimes svn for packaging ;
2. when I have to use svn it's for cheap stuff where I don't really need the prompt help.

I was excited by Pierre s idea to add Git branch information to the Zsh prompt and even more so when I saw Mike implement support for multiple VCSs. Unfortunately, Mike s a Bash user, and so I took it upon myself to port the idea to Zsh. The file 60vcsprompt is sourced from my .zshrc, which sets psvar[1] through psvar[3]. Those are then used in 80prompt (also sourced from .zshrc) when setting $PS1. My prompt follows the same principle as Mike s and puts the branch name at the repository root location in the repository path. In the following example, ~, ~/code, and ~/code/netconf/netconf are three separate Git repositories, while ~/code/unionfs-fuse and ~/code/unperish are maintained with Mercurial and Bazaar respectively:

lapse:~ master % cd code
lapse:~/code master % cd netconf 
lapse:~/code master netconf% cd netconf
lapse:..e/netconf/netconf master % cd src
lapse:..etconf/netconf master src% git checkout no-threads
Switched to branch "no-threads"
lapse:..nf/netconf no-threads src% cd ../../../unionfs-fuse 
lapse:../unionfs-fuse hg:default % cd ../unperish
lapse:..unperish bzr:unperish@159 %

You ll notice that unlike Mike s prompt, mine s limited to a maximum length of 25 characters. However, the repository root path is kept at least 10 characters long, so the prompt might get longer than 25 characters if you descend deep into a repository s subdirectories. I couldn t easily figure out how to add support for other version control systems, so if you do, please feed back the patches! And the same goes for suggestions and improvements. One of the next things I am planning to implement is an indicator for when your working tree contains uncommitted changes, e.g.:

lapse:..etconf/netconf master src% touch foo
lapse:..tconf/netconf master* src%

So watch those files. NP: Gazpacho: Bravo

Today is again about removing packages from testing as my hintfile says. We've discussed (in the RM team) policy a bit, and it seems that we agree that packages with Release Critical bugs open for more than 3 weeks without any kind of activity from the Maintainer warrant a removal from testing without prior notification. Tonight's work is then just doing the quite not fascinating work of going through this list and look for removal candidates. Note that we will always give more time to Maintainers that need it to fix a bug, if he/she states so in the bug report. Needing time is perfectly okay. Not telling about it isn't.

Today, I cheated a bit, and used my Release Assistant super powers, and removed from testing 2 packages with long standing RC bugs and no activity from the maintainers: See my hint file:

 #20080319
 # 467096
 remove traverso/0.42.0-1
 # 243363
 remove xcruise/0.30-8

edit: twinkle removal was a bit hasty, I totally missed that the bug wasn't RC from the beginning. And as a second thought I'm not either sure it's really RC.

I have spent one day and a half this week-end at FOSDEM. This was not as great as expected, but mostly because i don't have the time to stay the whole sunday. Next year, I will stay the whole week-end in order to have time to attend all the speak i should be interested in. The beer event was overcrowded, but all the beer i found there was great (in particular the Floris Pear). It was also a great time to have a demonstration of the XO OLPC laptop. This little thing is funny, but i don't get the way the UI should be used. Another bad point, is that the first console allow to login as root by pressing "Enter" (at least on the one i try). I suppose this kind of device is not intended to be secured. I also have time to talk with some Debian people and some other people -- in particular one who was thinking that Windows 2000 is the best ever OS. At least, it means that there were people from different horizons -- and this is a good thing. During Saturday, i spend half of the day in the big amphitheater (Janson). The talk about Tux with Shades (Linux in Hollywood) was impressive, regarding the trailer they show us... The talk about FreeBSD was interesting -- but not impressive as a trailer. I spend Saturday afternoon in the Debian devroom, following all the different talks. I miss the one from MadCoder about managing packages with git... That's a shame because i really want to see this one. Since my train was at 12am on Sunday, i choose to only pay a visit to the different booths. I have the pleasure to have a demonstration of the EeePC on the Debian booth that really please me. I found the UI more easy to understand than the one from XO. Speaking with the person demonstrating the laptop, she explained me that EeePC is more "standard desktop" and XO more "creative desktop". Conclusion: i am not creative ;-) Also talking about everything around talks and the meeting, i think Bruxelles is a really nice city for this kind of events. ULB is not near the center of Bruxelles but there are enough transportation. There was really a lot of people attending FOSDEM, and this is a good thing. I also have the pleasure to find some people from the OCaml Meeting.

So, MadCoder had doubts about the crazy idea, so I took a little time to do a test with a package I maintain, namely, xulrunner. First, take all the deb files in the history of the package (at least, everything that is available on snapshot.debian.net today).

wget -O - -q http://snapshot.debian.net/archive/pool/x/xulrunner/binary-amd64/Packages.gz gzip -cd > list
awk '/^Filename:/ print $2 ' list xargs -I wget http://snapshot.debian.net/archive/

Next, commit all these in a different repo per package name :

perl -e 'use Dpkg::Version qw(vercmp); sub v my $f = $_[0]; $f =~ s/.*_(.*)_.*/$1/; $f print sort vercmp(v($a), v($b)); map s/^Filename: .*\///; $_ grep /^Filename:/ ;’ list while read f; do
    pkg=$ f%_*_*
    [ ! -d $pkg ] && mkdir $pkg && ( cd $pkg ; git init )
    cd $pkg
    ar -x ../$f
    mkdir data control
    tar -C data -zxf data.tar.gz
    tar -C control -zxf control.tar.gz
    git add data control
    git commit -q -m $f
    rm -rf data control data.tar.gz control.tar.gz debian-binary
    cd ..
done

Finally, evaluate sizes for each package, respectively, of all .deb files, their content imported in git (only the .git directory, including the index ; some space could be gained removing it), and the “optimized” git repository (after git gc, without modifying delta depth or window size, which may even improve the result)

awk '/^Package:/ print $2 ' list sort -u while read p; do
    du -c --si $ p _*.deb tail -1
    du -s --si $p
    cd $p; git gc ; cd ..
    echo
done 17M total
16M libmozjs0d
4.7M libmozjs0d 34M total
31M libmozjs0d-dbg
14M libmozjs0d-dbg 4.7M total
7.1M libnspr4-0d
1.3M libnspr4-0d 9.2M total
12M libnspr4-0d-dbg
2.8M libnspr4-0d-dbg 25M total
28M libnss3-0d
4.6M libnss3-0d 81M total
61M libnss3-0d-dbg
21M libnss3-0d-dbg 15M total
16M libnss3-tools
3.1M libnss3-tools 288M total
265M libxul0d
146M libxul0d 2.0G total
1.8G libxul0d-dbg
1.1G libxul0d-dbg 5.1M total
6.8M python-xpcom
1.1M python-xpcom 2.5M total
5.6M spidermonkey-bin
861k spidermonkey-bin 13M total
14M xulrunner
2.0M xulrunner 3.3M total
5.9M xulrunner-gnome-support
979k xulrunner-gnome-support


So these packages, stored in git, take between 15 and roughly 50 percent of the .deb size, which may be a nice improvement. Il would be interesting to know how these numbers evolve with time. Some files, such as the changelog.Debian.gz files, would also benefit from being stored in plain text instead of gzipped form. Note git gc took a while and a lot of memory for libxul0d-dbg. Also note these don’t include delta files that would be necessary to recreate the original .deb file, but this shouldn’t make a huge difference.

PTS face lift(ed!) Ok, by now you've probably all already noticed, but I've finally committed the changes to the PTS package pages which implement a new layout and CSS. Thanks to Dan Callahan, Enrico Tassi and madcoder for their help with the CSS and to all who gave feedback (sorry, if it wasn't possible to satisfy all look and feel requests at the same time). There are still some minor, freshly introduced, glitches to fix (see for example 457168 and 457169), but I'm kinda tired to play with CSS and I'll give up for a while. But patches are always welcome!, I'll do my best to apply them timely. While I was at it, I've also fixed some other minor nuisances, such as the svnbuildstat link which is now shown only if the package is actually indexed by svnbuildstat. Thanks to Gon ri for having made available the info. PS totally unrelated, but thanks to Lucas now the homepage and vcs stats page sport wonderful graphs!

Ok, so two people replied to yesterday's post about triple negations - Dato (by email) and MadCoder. Both, said basically the same thing: false and && true are silly noops. And yes, knowing this, I added them. Why? Clarity... At least having them at the end of a test shows the statement is of conditional nature (and not just another obscure attempt to do $ DEITY -knows-what). They at least look cleaner than a one-line-squashed if block in a makefile. To me, at least ;-)But... If you noticed this post's title, it goes beyond this comment - One of the most benefical effects I noticed when I installed Jaws 0.7 (over 0.6, of course) is that I no longer had the swarms of spambots flooding me - I often had hundreds of comments a day, and nowadays I hardly get any spam. Now, I fail to see what is so strange in my blog's comment forms (it does not even have any obvious Javascript, although it does obfuscate a bit the source of the captcha image). And you are not the first Debian people to complain you cannot post comments to my site. Strangely, few non-Debian people have ever complained.And yes, the spam has stopped, almost completely.So, Debian guys: Are you human?

Congratulations to Yves-Alexis Perez (Corsac), Nicolas Fran ois (Nekral) and Sune Vuorela (Pusling) too \o/ Finally, some accounts (~30 ?) were created and i’m in. Thanks to all people involved in Debian and Kubuntu. In particular (no order) my co-maintainers, sponsors, helpers and application manager:
* Pierre habouzit (Madcoder)
* Mark Purcell (msp)
* Ana Beatriz Guerrero (Ana)
* Enrico Zini (enrico)
* Gustavo Franco (stratus)
* Lo c Minier (lool)
* Jonathan Riddell (riddell)
* Sarah Hobbs (hobbsee)
* and many many others But I don’t forget other people who missed this train: Cyril Brulebois (kibi). Next time, it’s your turn ! (i hope soon).

PTS: face lifting (i.e. tell me what PTS layout you like) My personal PTS small marathon is almost over. The latest addition is a shiny new look and feel. The rationale for that is partly aesthetic (the proposed new colors are mimicking wiki.debian.org and should be more debianish, thanks H01ger for the suggestion!) but mostly functional (the current layout is too "large" and too few information fits on a single average physical screen). So, here are some screenshots you can actually see:

1. current version . You can see this layout in action on whatever package in the PTS;
2. tighter layout (smaller fonts, less padding, wiki.d.o-like colors). You can see this layout in action on whatever package in the PTS since the CSS is listed as alternate: just access a page and (assuming you're using firefox) do "View > Page Style > Compact rendering";
3. tighter and reorganized layout (as for the point above + 3 columns layout, thanks MadCoder for the latter!). Unfortunately you can't try this out by yourself, as it isn't yet committed ... trust the screenshot then

So, question type, what do you like more of the above 3? I'm all for the latter (tighter and 3 columns) and plan to commit it RSN. If you have other preferences please mail me them; also suggestions for improvement are, of course, welcome.