I switched to git from mercurial about 4 months ago. As Matt Mackall (the main author of mercurial) has pointed out, my arguments were partially just excuses for the switch, because everything could be fixed in mercurial as well (eventually). On the other hand, I really wasn't expecting to switch when I invested time and energy to learn mercurial. Also because I thought that git doesn't have such a nice documentation, has a steep learning curve and the community is hostile, because it is developed by the kernel people who are famous for sometimes being not so nice on the mailinglists (as I now found out, none of these are true). I was getting annoyed by small things one by one, after finally I said to myself enough is enough, let's just switch.

So as to the steep learning curve --- it took me a day or two to being able to do what I want, so it seems to me it's really easy to learn once you know some distributed vcs. I found out the documentation is much better than in mercurial --- in git one just types "git help command" and a full man page fires up with lot's of information and examples. In mercurial, one just gets a couple lines (compared to git) of help in the terminal, without examples. Also the first (actually second) thing I noticed is that "git log" (and other commands like "git diff") doesn't scroll out my terminal, but uses "less" automatically -- that's just great. The first thing I noticed is that git is superfast for almost every operation, especially it's noticeable with "git diff". As to the community, I only had a chance to send a few emails to the git list, so I cannot really say, but so far it's very responsive and friendly.

However, those are just little things that can (and I am sure they will) be fixed in mercurial as well. What is a big thing are branches, especially remote branches. One just fetches a remote repository and then works with it like with any other local branch, e.g. one can switch to it, or just "git log some_remote_branch" to see what is in there. One can easily compare them etc. With mercurial, I was using "hg out" and "hg in" commands to see what changes I will pull or push, but those commands require internet connection, so it really sucks and it's slow. In mercurial, I was using different directories for different branches, but that's just extremely inconvenient and also slow (creating a new branch is just a matter of adding one file, not copying the whole repository --- for example with the sympy hg repository, I often had to wait several seconds to clone a repo, while with the git repository it's just instant) and big (in terms of megabytes).

The bible of Mercurial, the hgbook says:

In most instances, isolating branches in repositories is the right approach.

But I think it's the wrong approach. The only argument for doing this that I accept is that sometimes you are not sure which branch you are in in git --- well, I use this trick (actually, just read the documentation of __git_ps1 in /etc/bash_completion.d/git), so my bash line always says which branch I am in using the red color. I never do any mistakes with this.

Anyways, I could continue like this (e.g. check out "git svn", "git rebase -i" and many other things), but you can read why git is better for example here, no need to repeat here. I am very happy now and I can only recommend to learn git.

So let me also say some things that are worse in git --- one thing that could be improved are URLs of the gitweb (hgweb urls are neat, gitweb urls use "?id=..." stuff). Another thing is that the debian package git is not git! You need to install git-core to get git (but this seems to be getting fixed).

There is also an interesting discussion happening right now in the debian-python mailinglist about switching the DPMT repositories to git. I think almost all opinions (for and against) were already stated, but if you have some opinion that wasn't yet said, please do so.

Fellow R user Paul Gilbert had invited me to come to Ottawa and the Bank of Canada to give a presentation/workshop on 'high-performance computing with R' similar to the UseR 2008 tutorial and talk. I just posted the updated slides from this talk, and there is also an updated live cdrom on the Alioth server. Also, it looks like the tutorial will be held again at UseR 2009 in Rennes, see here for a brief synopsis. It was nice to get back to Canada, even if it was a 24 hour whirlwind trip. Ottaws looked quite pretty in all the snow. And it seems that I got rather lucky with the travel dates as both the days before and after my trip had a large number of flight cancellations and delays due to snow storms.

Previously I've posted a couple of running commentries describing how I've examined and gone about fixing a couple of bugs in Debian packages I use, enjoy, or have stumbled upon by accident. Each of these commentries has resulted in a change or two to the affected software to make the bug vanish. Fixing the bug is usually the hard part, but obviously it isn't the only thing that you need to do. While it is fun to have a locally fixed piece of software if you don't share it then the very next release will have the same bug again - and you'll spend your life doing nothing more than fixing the same bug again and again. Generally the way that I report my fixes is by sending email to the Debian bug tracker - because I usually only try to fix bugs that I see reported already. Specificially I tend to only care about:

• Bugs in packages that I maintain.
• Bugs that affect me personally. I'm selfish.
• Bugs in packages I use, even if they don't affect me.
• Segfaults. Because segfaults and security issues often go hand in hand.

This entry got a little bit long .. click to read more ObFilm: Ghostbusters 2

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

or, "Youth choir of the year" Between my 16th and 25th birthday, I was a happy member of this particular choir; and today, five years later, there are still many members of this choir that I know personally including, of course, their conductor. It's not the first time Cantilene joined the race for "Choir of the year". The first two times, I was still a member. However, it is the first time they won in the category "youth choirs"; the first time, Cantilene came up second; the second time, we unfortunately did not make it to the finals. The fact that they did make it this time around, gives me mixed feelings; of course I'm happy that they won, but I'm sad that I couldn't be part of it this time. Well, that's part of getting older, I guess. In any case, here's a big contratulations to Cantilene! For those who care, if you do a search on youtube for "Cantilene", "Koor van het jaar", or "Luc Anthonis" (the conductor), you'll find a number of films most of them from the Canvas belgian TV station. In related news, with Caljent (the choir that I am a member of, today) we had two concerts last weekend. They were a success, but unfortunately no thanks to me; I lost my voice somewhere during the evening of the 20th, and thus was quite unable to sing most of what we were going to sing. That did not stop me from being on stage and singing anyway, but I had to playback about half that time... Here's for hoping that my voice will be better on christmas, since we're singing in mass then... I'm mostly there, but not quite entirely yet.

Recently much ink has been spilled on the forms of micro-writing (Twitter, Facebook status updates, micro-blogging) that have captivated the hearts, minds, and especially keyboards of those, like me, who spend a lot of time in front of the blue screen (whether a computer or a phone). Lately, perhaps in part because I was home bound for days, I went on a status-update frenzy, updating my Facebook feed like there was no tomorrow and checking in as often to read the short nuggets left by friends. Despite this recent bonanza, I don t admit to all my friends of this addiction as some of them seem to really dislike no the more accurate term is detest this linguistic genre. Generally, it seems to me, there are those that love these messages, and then there are those who disparage them for being inane, short blasts of egotistical information that reflect and worse, reinforce the rampant, raw, unfiltered American love with self, performing the individual, and all that related jazz. I am sympathetic with the haters and at times, I admit I feel nothing but the hate (and perhaps this is why I have yet to Twit) but after thinking about it I have decided I am not really in their camp. Why? Well, something I do when I am thinking through phenomenon is ask: What Would Bakhtin Think (WWBT) as he is a theorist that I adore for he avoids so many of the traps, mostly of binary thinking, that befall most academic theorists. The answer to WWBT, at least from the way I read him, would be that he would dig and find something quite significant about these linguistic ephemera. Bakhtin, who was a Russian literary critic and thinker , thought highly of the novel as a genre for, unlike poetry, it provides a window into everyday life, into the depths and heights of the prosaic, which, however prosaic, is actually where all the extraordinary stuff of life resides. For in the humdrum of life is where he locates wonder, magic, suffering, laughter, mystery, love, oppression, and joy even if its significance often slips right on by our awareness, our perceptual world, until it is unearthed by such genres as the novel (and I would add film). You really can t get more mundane than these micro-statements, though albeit they can be fantastically funny, frustratingly opaque, devilishly satiric, and in rare occasions, poetic; and it is for all these reasons that I find them personally enjoyable and analytically valuable. So much of our life is seeped and steeped in the mundane and yet it is whizzes by us without much reflection. We certainly don t have much of a window into the mundane lives of others, especially in any real time sense. These updates are short pauses, like a temporal parenthesis (which any reader of this blog can I tell I am fond of) or a pleasant hiccup. While many say that they are egotistical blasts, I experience them otherwise, especially when I find myself smiling, laughing, wondering not at what I say but what others throw out there. For with the short update, I am transported, however ephemerally and momentarily, to your mundane world and share in the pleasures of life as is. And for those that remain unconvinced, at least take my word that Bakhtin is worth paying attention to (that is, if you pay attention to academic theory), here is a review essay that might convince you (subscription required but I will try to post a full copy later)

I don't know if Aaron is an Ubuntu Developer. I hope not. And I hope that no one of the commenters is one. But this post and especially the comments to it (because the article may have some justification) is certainly not a way to improve the relationship between projects like Ubuntu and the projects its based on.

Yes, it is true, that we have a rough tone in our mailing lists and yes it is sad that every now and then topics pop up that need to be discussed till somebody is hurt and leaves (the project). I certainly hope that this can be improved over the time, but most likely this is not something which breaks the project. Who knows what its worth. We have a large community, very much different opinions and therefore conflicts. Possibly it enhances the quality of our distribution, because things that certainly would make our product worse (e.g. lowering quality standards) won't get done, because they'll get a strong opposition.

But whats the point with the innovations, Aaron? Is it the job of a distribution to serve with innovations? A distribution that serves as a base for more then 10 other distributions? A distribution that is known to care a lot about freedom and is known (and appreciated) for a high quality standard. I don't think we need to serve innovations. We served innovations back in a time where it was needed. Where things were missing. Like a good package management, like conf.d directories. Apart from this I think there were enough innovations in the past years. Possibly not that user-visible and trendy as a graphical virtualization frontend. What about xen-tools for example?
Now its all about reinventing the wheel or developing frontends. Launchpad for example is just reinventing the wheel. Savannah exists, GForge exists. Bazaar is just reinventing the wheel. Git exists. So does Mercurial.

But whats most sad about your posts and the comments is that you (and your commentors) seem to share the opinion that all Debian does is packaging software and nothing more. According to you Debian developers do not fix bugs, forward patches, file (important) wishlist bugs, encourage upstreams to remove horribly broken licensed software, improve their own software and tools (dpkg, aptitude, apt-get, the devscripts, ....), do integration work (alternatives, $EDITOR usage, ...), documentation work (writing manpages). The reality is that there are many small and greater things driven by Debian Developers that serve the whole community. Additional to the ground work that your favorite operating system is based on and without which it could not exist.
Its just not beeing doped like it is done by companies with their marketing departments that actually earn money with what they do. Take the projects you named. They all have one. They all have paid developers.

In any way such a ranting (with no real constructiveness) will not serve the relationships between other projects and Debian.

Following a thread on Planet GNOME, I decided to add a few more warning options to my main upstream projects. I started with:
-g -O2 -g2 -Wall -Werror -Wdeclaration-after-statement -Wno-pointer-sign -Wcast-align -Wbad-function-cast -Wmissing-declarations -Winline -Wsign-compare -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wl,--as-needed


I'm adding -Wredundant-decls (which itself has highlighted a bug in QOF 0.7.5, fixed in 0.8.0 SVN). and -Wwrite-strings which caught lots of nasty bugs. (You know the ones, you're confident that a string is newly allocated and needs a g_free but then the program seg.faults in operation and you can't find why?) Also added -Wformat-security, -Wswitch-enum, -Winit-self - the first one to not cause any new errors and -Wmissing-include-dirs (which I'm glad to say raised no errors because it is checking my autotools foo). Test project for this run: pilot-qof. Changes now in CVS (yes, CVS - why not? pilot-qof is stable enough that it doesn't need any of the SVN features that caused migration of other projects).

Later, I'll add the same warnings to QOF and gpe-expenses upstream.

Since I've ranted a little recently lets do another public bugfix. The last few times people seemed to like them, and writing things down helps me keep track of where I am, what I'm doing, and how soon it will be "beer o'clock". So I looked over the release critical bug list, looking for things that might be easy to fix. One bug jumped out at me:

• gnomad2: segfault on start up / vorbis comment headers
• (Original report)

I installed the package:

skx@gold:~$ apt-get install gnomad2
..
The following NEW packages will be installed
  gnomad2 libmtp7 libnjb5 libtagc0
..

Once I copied an .mp3 file to my home directory, with the .ogg suffix I got a segfault on startup:

skx@gold:~$ cp /home/music/Audio/RedDwarf-back-to-reality.mp3 ~/foo.ogg
skx@gold:~$ gnomad2
..
LIBMTP_Get_First_Device: No Devices Attached
PDE device NULL.
TagLib: Ogg::File::packet() -- Could not find the requested packet.
TagLib: Vorbis::File::read() - Could not find the Vorbis comment header.
[segfault]
skx@gold:~$

So I downloaded the source ("apt-get source gnomad2"), and the dependencies for rebuilding ("apt-get build-dep gnomad2"). This allowed me to rebuild it locally:

skx@gold:/tmp/gnomad2-2.9.1$ ./configure --enable-debug && make
skx@gold:/tmp/gnomad2-2.9.1$ cd src/

And now it can be run under GDB.

skx@gold:/tmp/gnomad2-2.9.1/src$ gdb ./gnomad2
GNU gdb 6.8-debian
...
(gdb) run
Starting program: /tmp/gnomad2-2.9.1/src/gnomad2
...
LIBMTP_Get_First_Device: No Devices Attached
PDE device NULL.
[New Thread 0x41dcd950 (LWP 23593)]
TagLib: Ogg::File::packet() -- Could not find the requested packet.
TagLib: Vorbis::File::read() - Could not find the Vorbis comment header.
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x41dcd950 (LWP 23593)]
0x00007fc89e0340b0 in taglib_tag_artist () from /usr/lib/libtag_c.so.0
(gdb)

Interestingly the crash comes from a library, libtag_c.so.0. So either:

• The bug is realy in the libtag module.
• The gnomad2 package doesn't handle a failure case it should.

Time to guess which that is. Charitably we'll assume any library that segfaults will be quickly fixed, because it will have more users than a single program.. Moving on we can look at the gnomad2 source for mentions of taglib. Several mentions are found, but src/tagfile.c is clearly the correct place to look. That file contains the following code:

void
get_tag_for_file (metadata_t *meta)
 
  gchar *tmppath = filename_fromutf8(meta->path);
  TagLib_Tag *tag;
  const TagLib_AudioProperties *properties;
  TagLib_File *file = taglib_file_new(tmppath);
  if(file == NULL)  
    g_printf("could not open file %s", tmppath);
    g_free(tmppath);
    return;
   
  g_free(tmppath);
  tag = taglib_file_tag(file);
  properties = taglib_file_audioproperties(file);
  gchar* artist = taglib_tag_artist(tag);
  ..

This looks like a great place to explore because opening a file to read the tags is most likely where the crash is going to be coming from. Interestingly we see the code:

• Calls taglib_file_new to get a handle of some kind relating to the file.
• Tests for errors with that operation.
• Calls taglib_file_tag to fetch tag information using the handle, and indirectly the file.
• But then uses taglib_tag_artist to fetch the artist (?I guess?) without testing the handle previously obtained was valid.

Let us guess that the file opening is succeeding but that the tag structure fetched via taglib_file_tag is NULL - and this causes the crash. A quick edit:

  g_free(tmppath);
  tag = taglib_file_tag(file);
  if(tag == NULL)  
    g_printf("tag was null");
    return;
   
  properties = taglib_file_audioproperties(file);
  gchar* artist = taglib_tag_artist(tag);

Rebuild, and the segfault is gone. We have a winner. Now we just need to file a patch... ObFilm: 300

Thanks to Neal McBurnett, Hecl for Android finally got to run wild and free on a real phone. There were some glitches, but by and large, things seem to work, which is always exciting, and something of a relief. Neil says it runs fairly quickly, and looks good. Once again, a big thanks to Neil, and now on to fixing the bugs! Android itself continues to evolve: http://fredstechblog.blogspot.com/2008/12/big-updates-ahead-for-android.html Now, if only I could get ahold of one of those dev phones! Although, truth be told, I think the "G2" or whatever it is, will probably be a significant improvement in terms of fixing up some of what needs improvement over the first generation, so I'll probably wait until sometime next year and get one of those.

Dear lazyweb, how do I pin lenny now and have that pin hold after lenny s release?

• Codename lenny doesn t work, apt cannot do this (#433624, 18 months old, without any reaction yet)
• Version 5.0 doesn t work, lenny s Release file doesn t have a Version field yet
• Suite testing will match lenny now and then track squeeze once squeeze is testing

Is there any method that will get me testing lenny now and stable lenny later and not testing squeeze?

Contrary to popular belief, eating cookie dough will not make your sore throat better.

Russ Allbery recently commented that it is really nice to receive patches for trivial scripts posted online. I agree. More than once I've posted a trivial script and had it be improved by people, or later included elsewhere. So in the spirit of sharing here is my latest toy script:

• make-whitelist

This is a trivial script which searches a Maildir hierarchy and outputs a list of each email address which you've ever sent mail to. Why would you want that? In my case my (personal) spam filtering makes use of whitelisting, and the assumption is that if I've ever mailed you in the past then I want to see your replies, and you get a break. These days my (personal) mail filtering has a couple of broad rules:

• If your mail is HTML it is junk. Unless I'm bored.
• If your mail is GPG signed/encrypted I will see it.
• If your mail address is on my whitelist then I want to see it.

After that then I see your message only if CRM119 decides I should.

#
# remove potentially spoofed header
#
:0 fhw
* ^X-whitelist:
  $FORMAIL -I "X-whitelist"
#
#  GPG-signed messages are OK and will be whitelisted
#
:0fW
* < 1024000
 /home/steve/bin/isgpged
:0e
  $FORMAIL -A "X-whitelist: yes" -A "X-GPG-Signed: Yes"
#
#  Get the sender of the message.
#
FROM= formail -x From:  sed 's/^\([^@]*[ <]\)//'   sed 's/\([ >]\).*$//' 
#
# Add a whitelist tag if appropriate
#
:0 fhw
* !^X-whitelist: yes
* ? test -s $HOME/.procmail_whitelist
* ? echo $FROM  fgrep -qisf $HOME/.procmail_whitelist
  $FORMAIL -A "X-whitelist: yes" -A "X-Whitelist-Test: $FROM"

The net result of these tests is that I can now run the spam filter on non-whitelisted mails:

#
# Run CRM114 mailreaver
#
:0fw: .msgid.lock
* !^X-whitelist: yes
  /usr/bin/crm -u /home/steve/.crm /usr/share/crm114/mailreaver.crm
#
#  Spam.
#
:0:
* ^X-CRM114-Status: SPAM.*
* !^X-whitelist: yes
.CRM.Spam/
#
#  Unsure.
#
:0
* ^X-CRM114-Status:.*UNSURE
* !^X-whitelist: yes
.CRM.Unsure/

There is more to my setup than that, but that's the minimum you'd need to see. Of course this is a reminder, once more, that the kind of filtering that you carry out for yourself is different from that that other people will do. ObFilm: The NeverEnding Story

I wanted to report a success story with topgit which is a rather new patch queue managment extension for git. If that sounds like gibberish to you, this is probably not the blog entry you are looking for. Some time ago I decided to migrate the debian packaging of bibutils to topgit. This is not a very complicated package, with 7 quilt patches applied to upstream source. Since I don't have any experience to go on, I decided to follow Martin 'madduck' Krafft's suggestion for workflow. It all looks a bit complicated (madduck will be the first to agree), but it forced me to think about which patches were intended to go upstream and which were not. At the end of the conversion I had 4 patches that were cleanly based on upstream, and (perhaps most importantly for lazy people like me), I could send them upstream with tg mail. I did that, and a few days later, Chris Putnam sent me a new upstream release incorporating all of those patches. Of course, now I have to package this new upstream release :-). The astute reader might complain that this is more about me developing half-decent workflow, and Chris being a great guy, than about any specific tool. That may be true, but one thing I have discovered since I started using git is that tools that encourage good workflow are very nice. Actually, before I started using git, I didn't even use the word workflow. So I just wanted to give a public thank you to pasky for writing topgit and to madduck for pushing it into debian, and thinking about debian packaging with topgit.

One of the discussion that always seems to come back is what to do with firmware. It's mostly about freedom versus usability. I think the main question is where do we want to put non-free firmware in our archive. The opinion seems to range from that it should be in the non-free archive to that it should be in the main archive, with many opinions in between, and they all have good arguments. We have 3 options that are related to it in our current vote that seem to come down to:

• Move all firmware that doesn't comply with the DFSG to non-free
• Change the DFSG to not require source for firmware so that it can be in main
• Assume that the blobs in the kernel are source so that it can be in main

I don't see the point of that second option, and really have to wonder if there is any firmware under a license that would comply with the DFSG except that the source isn't available. The third option can make sense for some of the blobs in the kernel that are basically settings that are written to the device. You could write an editor for it, assuming there is documentation for it. But I doubt that they're all settings, and it just seems to ignore the problem. I find Theodore Ts'o' suggestion about creating a new section for firmware the best idea so far, specially if we can agree that our official CD/DVD images will have that section on it. It has the advantage that all software in our main archive can comply with the DFSG, that you don't need to add the non-free section just to be able to use hardware that requires firmware and that you can just take a CD/DVD that works.

Yes, it's that time of the year again... it's almost Christmas, which means that I once again updated my 10 + 100 Creative Commons Christmas Songs blog article I originally wrote in 2005. That's a collection of a lot of freely downloadable, Creative Commons licensed Christmas music. Some of the older entries in the list are no longer available unfortunately, some only needed a URL update, and I also added more than 30 new songs this year. This currently makes a total of 256 CC Christmas songs (more will probably be added over the next few days), so head over to the full song list and get those downloads started... (Photo: Wikipedia. Author: Malene Thyssen. License: GFDL 1.2 / CC-BY-SA 2.5)

The title of this post sucks, so that's up to you help me come with an alternative. It's also a bit sarcastic to remember that Debian is around for ages, Internet was smaller and poor, web wasn't a hit on the streets. Debian GNU/Linux is successful being an universal operating system. The question is: What's next? Lenny is the short term answer, but we can do more...

Do we really need to stop and discuss everything? Let's discuss everything yeah, but always do the fun work in parallel. Let's force ourselves to much higher standards.

Please remember that in many cases it isn't that easy to contribute with more than ideas when an alternative implementation requires additional privileges. Higher standards doesn't mean lock everything even more, no. It involves release the keys and make sure we can revert any changes that are clearly bad.

Flame a new installer idea (remember that? nobody does...) or initial code is easy. Give it some room and see what happens later... Ask yourself now: Do I have any privileges in Debian that may be forbidding people to help this project? Well, if you answered yes please post in your blog, come out on IRC and talk to others. Make sure you act as an useful bridge not as a blocker. If you don't have enough time, share your privilege with a secondary (hint: Maintain a package is a privilege).

I'm on vacation from my regular job and committed to help Debian full-time on the following tasks, if folks from the respective projects are interested, drop me a comment. Those who disagree, please keep working on whatever you are. It will be much more productive to us. There we go:

RC bugs - Do downgrades/removals from packages with less XXX users (as in popcon) now. Higher standards! I can't do that by myself since I have no access, if you are a release team member and is happy with that, we define the number and I prepare the list based on BTS.

Site - I would like to help the team working on the web site to split it in two. "current" and "legacy". current would be a very small one with content related to a few topics such as: Lenny, download, documentation, how to contribute and more. It would have a new UI (multiple languages yes), use XHTML or whatever the team feels ok. The key detail is that current would be www.debian.org on the day we release Lenny and after. current would have a link (or multiple links) to legacy website. People are free to cross-post current content to legacy website as well, but the best would be move from legacy to current.

I have some more ideas, but let's focus on a few things so I can deliver. release team and www, it's your turn now.

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

I unsubscribed from -devel and -vote the other day, as the pain/gain ratio was just not worth it anymore (and -project is very much pending). Sadly, I still could not escape from what I wanted to escape from, as some people bring up those discussions and "their style" on planet.

Please show some fscking respect to your peers! Debian is not about freedom (whether you like it or not, and no matter how you define freedom), it's not about freedom of speech or being open minded, it's just about creating the greatest free operating system. The free operating system, that's why we are here.

I for one, disagree with many debian contributors ideas and believes, whether (those ideas are) Debian related or not. To give one example, I think religion is hillarious and believing in (a) higher being(s) is a sure sign of an ill (or weak, or both, or whatever) mind. (Quite similar to smoking btw, and for those who don't know, I do smoke.) But I'm not shoving this down all the time to anybody who makes a religious reference in Debian (nor in real life). Quite the contrary, I do admire quite some people who take motivation out of their religious believes to do things they think are good. I belive this is quite common the other way round too, eg when religious and human-rights motivated groups work together to help immigrants. They dont share (all) the same beliefs, and in some they have huge disagreements (eg. I think religion is the root and a means^wcontributor to many of the worlds evils) but they choose to respectfully disagree on these views to be able to work together on the common goal they share: help immigrants.

And in the same way I (try to) (dis)agree with my fellow Debian peers about their insane or great ideas. I try to respectfully disagree (or respectfully agree). And I do acknowledge that I sometimes fail, eg the above words about religion might have hurt some peoples feelings. I do give a damn about having hurt those people (so I ment to say sorry with that in cheek damn joke), even though I dont give a damn about religion. And I think the last sentence might have been too sharp to be respectful while I belive the above paragraph is fine. I also think its fine to be disrespectful (in or outside Debian) once in a while, since we are all humans and make mistakes once in a while, but I dont think it's fine to have those people in Debian who fail all the time (or too often), be it because they are incompetent to treat fellow peers with respect or because they dont care (or because they think they do something good with their kindergarten rhetoric).

Contributing to Debian is not a human right (and suppressing some voices (and esp. noise) in Debian is not censorship, for fucks sake!). We are only here, because we are standing on the shoulders of giants (except for the very few giants among us) and because we want to create/improve a great operating system. And thats why I think it's perfectly acceptable and desirable to not allow those messages here, which are distracting and/or blocking of from reaching this goal. An occasional outburst (and be that a 2-4 weeks long or a single big outburst) doesnt qualify in my book for being kicked out, no matter how harsh or unreasonable it was. Constant disruption IMO is. Where to draw the line is tricky (and I'm convinced there can't be a single written "line" covering everything in Debian), but not to draw any lines will result in only the vocal and thick-skin minorities to stay.

And with nice, respectful communities (which have policies quite a lot like the DFSG) like fedora and ubuntu available, failing to be(come again) a respectfull community might really contribute a lot to the end or slow decline of Debian. Sure, "the end of Debian!11" is a somewhat constant meme, but it is (sadly) not like Debian is undestroyable. Debian is very certainly much easier to destroy than to rebuild.

We need to take measures to prevent some peoples ideas of freedom from harming or destroying the project. And I don't mean some peoples ideas of Debian police state or Debian teletubby county - I'm very confident those ideas will not win here. But sadly I can see the results of poisonous people, or rather, their behaviour win.

And undoubtfully I also can see many great people in Debian making sure this will not happen.

The future is unwritten and I wish we show our fellows the respect they deserve. Debian wasn't made by you, more than 99,99999% of it was made by other people. And if you have to, attack ideas, not people. And usually it's also unneeded to _attack_ an idea (merely challanging it is usually enough), because usually the Debian person proposing it is not so stupid not to take your criticism into consideration.

That's why I'm still in favor of a social committee, even though I see very much the dangers of power abuse and the cultural norms in a world wide project. But I see much more danger in not stopping unrespectful assholes from urinating into our living rooms and work benches, using the waiver of "free speech" and "we all have different standards of whats acceptable."

Simpler said: either you respect the community or this community shall not be yours.

That said, I wish you all a very merry xmas, whether you celebrate and believe, or one of the two, or none. Be happy and let it be. And may we have a great 2009, despite we'll release lenny that late! ;-)
P.S.: I'll post this to -project as well, so you can reply more easily.