Nicola Benaglia reported bug #510000 on Sunday December 28th. As bug #500000 was reported as of Sep 24th 2008, this marks a considerable slowdown of our bug reporting rate: between bugs 400000 and 500000, it always took us nearly exactly two months to have 10000 bugs reported. Here, we needed more than 3 months! This is a 50% drop in the bug reporting speed. I think we can conclude this is a very good illustration of the considerable drop in the development of Debian, while everybody is awaiting for the release of Lenny. You still have a few days to correct your bet for bug 600000 date. Ah, and the very same day, the result for the very controversial vote about firmwares has been published. Even though it is very hard to interprete, I think that the very very low rating of option 1 (worded as "Reaffirm the Social Contract" but indeed meaning "let's be Free Software Zealots and nitpick every single bit of firmwares so that we can be sure to never release Lenny") clearly shows that Debian developers still have their feet in reality. So, now let's release the bloody thing...and prove the world we still exist...

Last year, on December 24th, my Christmas gift to me was running my first half-marathon (alone in the woods, just as I like). This year, I couldn't do less and I offered myself another wonderful gift: my longest distance ever: 33,8km. That was a wonderful run on a sunny winter morning, around zero degrees, around the "Etangs de Hollande", a very well known spot in the Rambouillet Forest, then north to Montfort l'Amaury (the run is the red line on the map...the blue line is more or less my 2007 first half-marathon). 33,8km in 3h20 minutes, by the way, for those of you who are marathoners. Just above 10km/h (the end was very slow as I was dead tired!). Really the best gift I could do to myself. Great Christmas.

The Debian Python Modules Team is discussing which DVCS to switch to from SVN. Ondrej Certik asked how to generate a list of commiters to the team s repository, so I looked at it and got this:
emilio@saturno:~/deb/python-modules$ svn log egrep "^r[0-9]+ cut -f2 -d sed s/-guest// sort uniq -c sort -n -r
865 piotr
609 morph
598 kov
532 bzed
388 pox
302 arnau
253 certik
216 shlomme
212 malex
175 hertzog
140 nslater
130 kobold
123 nijel
121 kitterma
106 bernat
99 kibi
87 varun
83 stratus
81 nobse
81 netzwurm
78 azatoth
76 mca
73 dottedmag
70 jluebbe
68 zack
68 cgalisteo
61 speijnik
61 odd_bloke
60 rganesan
55 kumanna
52 werner
50 haas
48 mejo
45 ucko
43 pabs
42 stew
42 luciano
41 mithrandi
40 wardi
36 gudjon
35 jandd
34 smcv
34 brettp
32 jenner
31 davidvilla
31 aurel32
30 rousseau
30 mtaylor
28 thomasbl
26 lool
25 gaspa
25 ffm
24 adn
22 jmalonzo
21 santiago
21 appaji
18 goedson
17 toadstool
17 sto
17 awen
16 mlizaur
16 akumar
15 nacho
14 smr
14 hanska
13 tviehmann
13 norsetto
13 mbaldessari
12 stone
12 sharky
11 rainct
11 fabrizio
10 lash
9 rodrigogc
9 pcc
9 miriam
9 madduck
9 ftlerror
8 pere
8 crschmidt
7 ncommander
7 myon
7 abuss
6 jwilk
6 bdrung
6 atehwa
5 kcoyner
5 catlee
5 andyp
4 vt
4 ross
4 osrevolution
4 lamby
4 baby
3 sez
3 joss
3 geole
2 rustybear
2 edmonds
2 astraw
2 ana
1 twerner
1 tincho
1 pochu
1 danderson
As it s likely that the Python Applications Packaging Team will switch too to the same DVCS at the same time, here are the numbers for its repo:

emilio@saturno:~/deb/python-apps$ svn log egrep "^r[0-9]+ cut -f2 -d sed s/-guest// sort uniq -c sort -n -r
401 nijel
288 piotr
235 gothicx
159 pochu
76 nslater
69 kumanna
68 rainct
66 gilir
63 certik
52 vdanjean
52 bzed
46 dottedmag
41 stani
39 varun
37 kitterma
36 morph
35 odd_bloke
29 pcc
29 gudjon
28 appaji
25 thomasbl
24 arnau
20 sc
20 andyp
18 jalet
15 gerardo
14 eike
14 ana
13 dfiloni
11 tklauser
10 ryanakca
10 nxvl
10 akumar
8 sez
8 baby
6 catlee
4 osrevolution
4 cody-somerville
2 mithrandi
2 cjsmo
1 nenolod
1 ffm
Here I m the 4th most committer And while I was on it, I thought I could do the same for the GNOME and GStreamer teams:
emilio@saturno:~/deb/pkg-gnome$ svn log egrep "^r[0-9]+ cut -f2 -d sed s/-guest// sort uniq -c sort -n -r
5357 lool
2701 joss
1633 slomo
1164 kov
825 seb128
622 jordi
621 jdassen
574 manphiz
335 sjoerd
298 mlang
296 netsnipe
291 grm
255 ross
236 ari
203 pochu
198 ondrej
190 he
180 kilian
176 alanbach
170 ftlerror
148 nobse
112 marco
87 jak
84 samm
78 rfrancoise
75 oysteigi
73 jsogo
65 svena
65 otavio
55 duck
54 jcurbo
53 zorglub
53 rtp
49 wasabi
49 giskard
42 tagoh
42 kartikm
40 gpastore
34 brad
32 robtaylor
31 xaiki
30 stratus
30 daf
26 johannes
24 sander-m
21 kk
19 bubulle
16 arnau
15 dodji
12 mbanck
11 ruoso
11 fpeters
11 dedu
11 christine
10 cpm
7 ember
7 drew
7 debotux
6 tico
6 emil
6 bradsmith
5 robster
5 carlosliu
4 rotty
4 diegoe
3 biebl
2 thibaut
2 ejad
1 naoliv
1 huats
1 gilir

emilio@saturno:~/deb/pkg-gstreamer$ svn log egrep "^r[0-9]+ cut -f2 -d sed s/-guest// sort uniq -c sort -n -r
891 lool
840 slomo
99 pnormand
69 sjoerd
27 seb128
21 manphiz
8 he
7 aquette
4 elmarco
1 fabian
Conclusions:
- Why do I have the full python-modules and pkg-gstreamer trees, if I have just one commit to DPMT, and don t even have commit access to the GStreamer team?
- If you don t want to seem like you have done less commits than you have actually done, don t change your alioth name when you become a DD (hint: pox-guest and piotr in python-modules are the same person)
- If the switch to a new VCS was based on a vote where you have one vote per commit, the top 3 commiters in pkg-gnome could win the vote if they chosed the same! For python-apps it s the 4 top commiters, and the 7 ones for python-modules. pkg-gstreamer is a bit special

Samba in unstable is 3.2.5 currently, while upstream published 3.2.6 a few days ago. This is mostly because 3.2.6 has too many changes that make it unsuitable for lenny, which will have 3.2.5. As we want to keep the "update through unstable" path, we can't upload 3.2.6 to unstable. Simultaneously, we are using experimental for 3.3.* releases. Upstream recently published 3.3.0-rc2 which I uploaded yesterday to experimental. So, we don't have any easy way to make post-3.2.5 releases available to our users. I briefly imagined using backports.org for this, but:

• there is no lenny-backports distribution there
• it is meant for packages backported from unstable versions (late correction: it is meant for packages backported from *testing*....)

Finally, I opened http://pkg-samba.alioth.debian.org/packages/ as a private repository to hold these packages. You can use the following in sources.list:

deb http://pkg-samba.alioth.debian.org/packages/ ./
deb-src http://pkg-samba.alioth.debian.org/packages/ ./

The packages are signed with my own GPG key, which you need to add to "trusted" keys for APT" (be sure to read http://wiki.debian.org/SecureApt first). They are numbered the same way they would be if they were on backports.org. These packages are maintained in the Samba packaging team SVN. Please take this as a commitment to try providing up-to-date packages for lenny during its release cycle. Of course, the security support will be done on a best effort basis but should at least not be worse than upstream's (which is known to be good and very reactive). I hope that samba users will enjoy....and if some of you could join the team and help triaging bugs, that would be appreciated..:-)

Samba in unstable is 3.2.5 currently, while upstream published 3.2.6 a few days ago. This is mostly because 3.2.6 has too many changes that make it unsuitable for lenny, which will have 3.2.5. As we want to keep the "update through unstable" path, we can't upload 3.2.6 to unstable. Simultaneously, we are using experimental for 3.3.* releases. Upstream recently published 3.3.0-rc2 which I uploaded yesterday to experimental. So, we don't have any easy way to make post-3.2.5 releases available to our users. I briefly imagined using backports.org for this, but:

• there is no lenny-backports distribution there
• it is meants for packages backported from unstable versions

Finally, I opened http://pkg-samba.alioth.debian.org/packages/ as a private repository to hold these packages. You can use the following in sources.list:

deb http://pkg-samba.alioth.debian.org/packages/ ./
deb-src http://pkg-samba.alioth.debian.org/packages/ ./

The packages are signed with my own GPG key, which you need to add to "trusted" keys for APT" (be sure to read http://wiki.debian.org/SecureApt first). They are numbered the same way they would be if they were on backports.org. These packages are maintained in the Samba packaging team SVN. Please take this as a commitment to try providing up-to-date packages for lenny during its release cycle. Of course, the security support will be done on a best effort basis but should at least not be worse than upstream's (which is known to be good and very reactive). I hope that samba users will enjoy....and if some of you could join the team and help triaging bugs, that would be appreciated..:-)

Dato points me that the way I mentioned my vote is confusing and he's right. By writing that I voted 5462371, I wanted to say that I ranked option 5 as first, option 4 as second, etc. However, one could understand that I ranked option 1 as 5th, option 2 as 4th, etc. ...which is indeed the most common way we talk about our votes.... So, let's make it clearer. I voted: 7452136. So the first option (freeness bigotry) is ranked below Further discussion. I'll re-consider it in terms of strategy but I consider it honest: this is how I rank the various options altogether. I did not try to mke this vote "strategical" but I agree that this needs to be deeply thought. The issue is really important and can even be seen as a trap, yes.

A variety of Debian tasks all lined up in the top priority - get it done now or not at all - work queue this morning. Two GR's, one RC bug fix and one long overdue experimental upload.
All I'm saying about the first GR (the "anti-ganeff" vote) is 2212. That was the most ridiculous GR I've come across so far, until vote3 which is just politics gone insane. My own opinion? 7235146 which disagrees quite a lot with bubulle even though I have the same aims as bubulle - that alone indicates the nature of the vote. The options are illogical, the vote is pointless, the subject matter is moot, the initial proposal doesn't have any understanding or relation to the real world and the amendments have been unnecessarily divided in such a way to make it all but impossible to be logical in the vote priorities. The abuse of votes by a vocal minority undermines the process itself. All in all, we desperately need an option that basically says stop being pathetic and get something useful done in all future GR's - as well as making it harder to make a GR in the first place. Over use of referenda is as poisonous to democracy as under use - just ask Ireland.
After all that political spin and muck spreading, I had to just do something useful as a partial compensation. So, after a ping from the MIT BSP I've fixed 507316.
I've also made the tslib experimental upload that has been quietly developing on my own system for a few days.
Right, now I'm getting back to adding more packages to Emdebian Grip - so far, we have enough packages for a basic XFCE/Gtk system with an email client, a blog client, a few GPE games and Thunar as file manager. Now need to add iceweasel and dependencies. Once that is done, I'll be switching my Acer Aspire1 from Debian Lenny to Emdebian Grip unstable and creating a testing repository for Grip. Once I've got some figures from that switch, I'll post some more details to debian-embedded@lists.debian.org.
Sigh. Emdebian Grip was meant to go alongside Debian Squeeze - it looks now as if Emdebian Grip will be released before Debian Lenny - it's even likely to use the Lenny installer and debian-live support. I hope the pedants are happy because I'm not.

Christian notes, and rightly so, how much this vote sucks, for various reasons. There are too many viable options (as far as releasing Lenny is concerned) and that makes it tricky to vote in a useful way. And Christian got bitten by it: do not vote by ranking all options 1 to 7, or this vote will end up being our most EPIC FAIL to date. With that many options, the votes will end up diluted and who knows what the result will be. For this vote to succeed and be meaningful, it s pretty much required to rank several options equally. That is, and provided it matches your views, ranking the Let s release Lenny and give the finger to the zealots options at the same level. Be careful when voting on this one. IT S A TRAP.

I am somewhat under the feeling that the Debian project is currently facing a critical moment of its history. The development momentum has slowed down a lot during last months (approximately since Debconf and even more since October. I feel just like we're facing a moment where either we release Lenny (which is technically a great progress over Etch and, being a little bit more than 18 months after Etch, well suited wrt "modernity")....or we delay it for several months and will suffer more and more from the long freeze process (remember sarge). The momentum is then very likely to continue moving elsewhere (should I say Ubuntu or did everybody understand already?). And now we have to vote about firmware blobs, a proposal that popped up because a few (*very* few) vocal folks who (in my opinion) live on a planet that has no connection with the real world, think that we should triple check the freeness of each and every bit that is likely to be run on a Debian machine. Moreover, the proposal is worded and was pushed in a way that all (but one) options that would allow us to release lenny will need a 3:1 majority, which is obviously very hard to achieve (and as, there are several such proposals, the vote will be spread out among all of them). So, those folks who make the release of lenny their priority are now facing an interesting tactical choice: how the ..... should we vote for this to happen? I personnally did choose to vote this way: 5462371. Yes, I ranked "reaffirm the Social Contract" after everything, which makes me sad....and I blame the play on words by the zealots who pushed that proposal for forcing me to do this. I think this is the best "tactical" choice for those (and I hope we are a strong majority) who still make the *release* of the best possible and most possibly free operating system their priority. Believe me or not: if we don't release lenny soon, we will die slowly and rot peacefully. We will rot being 150% free and proud to be 150% free on our little planet, outside the solar system and the real world. *This* is the choice we are facing. Ah, and before I forget: film at 11, of course. PS: no comment system on my blog (I don't want to deal with spam and put complicated systems there). Please comment in public in your own blog. I very much prefer this over private comments which will be mostly ignored.

Waking up this morning, I noticed a low traffic in my incoming mail in "Debian work" mailboxes (PTS mailboxes, personal email, bugs, -release, etc.). Then I read -devel and understood. Everything is there. We have a new flamewar (apparently about NEW processing). It's interesting to see that the closer we get from a release, the biggest flamewars we are doing. Sounds like everybody is boring (have you notived the strong drop in the bug report rate?). Crap, there's a lot of work left to do, to release the damn Lenny:

• Zap down RC bugs (last time I checked 64 were both in lenny and unstable, not marked pending and not hinted)
• Release D-I RC2
• Test upgrade paths
• And, of course, I should not forget about the most important thing on earth: vote about firmware cra^W haircutt^W proposals

For $ DEITY 's sake, could we do that, so that developers stop boring, then go back to their development duties and the number of flamewars lowers down again (maybe after the squeeze release goals discussion which will probably be "interesting", also)? Please...your home page, these days, should really be http://bts.turmzimmer.net...

after my call for help when searching a backup solution for kind of special needs, I got a lot of feedback. Actually: I got more feedback than I'll be able to answer ;) So I take this way to thank you for all the hints, proposals and scripts! Special thanks to Bubulle for insisted me on using bacula and to Wouter for pointing out, that the default configuration will back up it's database automatically. Works like a charm and it was some fun to install it, play with it, test it. Oh, and I even understood how to restore files from the backup ;)

Interestingly, the just finished Extremadura QA + ftpmaster + i18n meeting also turned into a quite strong Bug "Smashing" party. Several participants were digging around the list of RC bugs affecting both lenny and unstable. Most often, it turned out to many bug downgrades (for many of which I'll take the blame). It's "funny" to see how sometimes our bug reporters tend to inflate their reports, most often because they feel that "bug should absolutely be fixed", but completely forgetting about the definition of 'serious' or 'grave'. I also feel that, in some way, several maintainers begin to be quite demotivated by the length of the process (which I personnally consider as being caused by several factors: decreasing (wo)manpower, haircutting about freeness of every single byte on Debian CD's or even shyness wrt correct actions needed to deal with bugs). And several of these bugs just needed a very simple action by the maintainer. And, therefore, just because we were about 15 people with a lot of time to devote to Debian for 3 days, we ended up digging in that pile of mud....removing most of the dust and sometimes very debatable RC bug reports, and finally having that count of bugs affecting both lenny and unstable go down again. This comforts me in the feeling that an aggressive approach is a good key to bug squashing. After all, if I'm sometimes too aggressive and inappropriately downgrade an RC bug, I'm sure that someone will correct me (and, anyway, I'm not that mad: sometimes I seek for advices). Ah, and "aggressive" also sometimes mean proposing to tag some bugs "lenny-ignore" (and, that needs to be very convincing with our release managers, believe me). So, what about you? Have you already smashed an RC bug today? If not, do it. Kill those nasty beasts, they deserve it. No mercy.

It's interesting to be here in Casar de Caceres for the joined i18n+QA+FTPmasters Extremadura meeting. Today, I've been sitting all day long in the biblioteca, which is used as hacklab, and just watched all great people around playing around with the concept of "tdebs". That weird beast can be described in two words as a concept of deb packages that would be able to distribute translation data in a more independent way then "regular" deb packages. Don't smash me as the concept is currently being twisted around in all directions by the nice folks here, to bring it to a great concept well suited for "side" material of our packages. To get an idea, you can read the original concept that popped up during the 2006 i18n Extremadura meeting, but got transformed drastically by ideas exchanged at Debconf 8 All this is made possible because the concept is now a very important issue for Emdebian and is strongly pushed by Neil Williams, whose nickname shall now be "MisterT", by general agreement of the folks here. What's really interesting right now is to see live discussions happening all the way round and see the concept slowly emerging from this. Something we could probably never do in regular mailing lists discussions or on IRC. We should really grant tons of rewards to the Extremadura region, and particularly out tireless C sar who again organised that meeting. It's still hard to say what will emerge from this and we willprobably need some more such live meetings to have real implementations of these tdeb beasts, but this is really how I like to see free software development going on. And now people begin to think about coding stuff and prepare patches, which is a good sign, in general.

I just registered for the Paris Marathon. There were only 1350 seats left out of 37,000. Finally, I decided that it's more likely that I would regret it if I don't try, so I decided to go for it. We'll see. Again, my offer to host Debian marathoners for that week-end still stands.

Last week-end, I went very close to the 2/3 marathon mark by running 27 km again after I did one such run on Nov. 11th. So, indeed, I ran 27km twice with only 4 days in between (and I ran also 7km during two of these four days). That last 27km run was like a November dream: over 20km in woods, with muddy paths full of dead leaves, about 200 meters positive slope (in four climbing sections), and I didn't finish completely dead. The rate was 5'55"/km (9'37"/mile, Dirk). Tuesday, I didn't go under the 6'/km mark, so that's an improvement. Actually, this is mostly because this time, I wasn't originally imagining I would go for so long, but more an half-marathon. Ralf Treinen and No l K the (who ran together at Cologne marathon the week-end before) are trying to convince me to participate to the Paris marathon next April. It seems indeed more and more likely that I will. Other Debian runners, what about meeting next April in Paris and do it? I can host folks in my house, of course. All this, the very same week-end Bdale got his level 3 in rocketry. Great success for the 61 folks.... Cheers!

The D-I team finally released Debian Installer RC1 for lenny. That wasn't an easy process and it revealed some miscommunication and rampant conflicts inside the team. That will needed to be solved for squeeze development but, as of now, we (the very few of us still working on D-I development...) focus on preparing an RC2 release. That release is meant to be out ASAP. It is mostly meant to deal with recent kernel updates and definitely not add new features. Even bug fixing will probably be limited to what's considered major blockers. That's another step towards the overall release of lenny, I think. Now we should probably all focus on remaining RC bugs, which count seems to have stopped going down during last weeks, which is IMHO worrying. But, of course, let our good release team deal with all this first (which probably involves dropping some crappy packages, imho).

Disclaimer: this post talks about Debian *Installer*....not overall Debian. The D-I team and the CD team have created images of Debian Installer Release Candidate 1 for Lenny. They are available at http://cdimage.debian.org/cdimage/.lenny_rc1/. Please test them out and report problems through installation reports as described from the Debian Installer web page. This is really important as this is very probably how the real released Lenny installation media will look like. Debian Installer is short of testing. So, yes, we need *you*. And, again, if you spread the word, don't talk about "Debian Lenny RC1". This is no such beast (even though this will look like a Release Candidate of Debian as the rest of the distribution is of course begin prepared for the release). The 'official' name is "Debian Installer for Lenny, Release Candidate 1".

...for maintaining bacula and maintaining it well. I adopted Bacula as backup solution for my local machines, at home, after I went very close to a complete disaster on my home server, last summer. As of now, my home server and my laptop are now backed up with it. The backup is done on a dedicated disk of the server (until I setup a dedicated server, probably in the house's ceiling). And things are just...working. Of course, Bacula is a fairly compilcated beast but, well, as I managed to make it work, I consider that anybody can do it. This morning, I finally setup the bacula graphical console on my laptop. As the laptop is running unstable, with Bacula 2 packages, I indeed had to upgrade bacula packages on the server (which runs Etch, where Bacula version is 1.*). I just went to backports.org, found backported packages there, kindly prepared by John (and Rhonda, apparently). One "apt-get install -t etch-backports" after, I'm just running Bacula 2. John, you deserve a full tank of beers... I'll think about it next time I happen to come in the middle of Kansas..:-)

... as people at work found this one.

I'm now reaching the very bottom of the Debian localization radar that points out packages with pending debconf l10n bug reports. About 20 packages are currently still under work (either waiting for the maintainer's answer, or in a translation update round...or waiting for the package to go out from DELAYED). That should be completed in about 10 days. The remaining packages are those with very recent l10n bug reports and I can't decently nag maintainers for bugs sent since less than one month. The result is now that we have 3 languages that reached near 100% completeness: German, French, Portuguese. Czech is over 97%. Swedish has been dramatically revived and now over 85%. And some more translation teams such as the Basque, Russian, Italian and others have taken this last opportunity to get as many translations as possible in the game. The overall quality of several packages I NMU is not optimal. I often refrained myself from trivial fixes as this is not the policy during freezes but that's really sad. I might initiate a QA NMU campaign when we enter the squeeze development round, to fix all those trivial lintian warnings (obsolete debhelper compat level, maintainer scripts ignoring errors, debian/rules ignoring make errors, typos here and there, etc.) Anyway, once this l10n NMU stuff is done, the question becomes: what will I do now and until we release lenny? Maybe come back to the French translation of the Developer's Reference which I worked on during the trip to Debconf8, then left aside since then....