If you don't have any interest in tedious licensing discussion then I recommend not reading this. It's not going to be a great deal of fun.

Having said that:

I'm looking at the Canonical Individual Contributor License Agreement (pdf here). In contrast to the previous copyright assignment, it merely grants a broad set of rights to Canonical, including the right to relicense the work under any license they choose. Notably, it does not transfer copyright to Canonical. The contributor retains copyright.

So here's a thought experiment. Canonical release a project under the GPLv3. I produce a significant modification to it. It's now clearly a derived work of Canonical's project, so I have to distribute it under the GPLv3. I have no right to distribute it under a proprietary license. I sign the CLA and provide my modification to Canonical. The grant I give them includes giving them permission to relicense my work under any license they choose. As copyright holders to the original work, they may also change the license of that work. But, notably, I have not granted them copyright to my work. I continue to hold that.

Now someone else decides to extend the functionality that I added. By doing so they are creating a work that's both a derivative work of Canonical's code and also a derivative work of my code. How can they sign the CLA? I granted Canonical the right to grant extra permissions on my work. I didn't grant anyone else that right.

This wasn't a problem with the copyright assignment case, because as copyright holders Canonical could simply grant that permission to all downstream recipients. But Canonical aren't the copyright holder, and unless they explicitly relicense my work I don't see any way that they can accept derivatives of it. The only way I can see this working is if all Canonical code is actually distributed under an implicit license that's slightly more permissive than the GPLv3. But there's nothing saying that it is at present.

Now, I'm obviously not a lawyer. I may be entirely wrong about the above. But asymmetric CLAs introduce an additional level of complexity into the entire process of contributing that make it even more difficult for a potential contributor to become involved. I've spent far more time than most worrying about licenses and even I don't understand exactly what I'm giving up, which is ironic given that a stated aim is usually that they increase certainty about licensing. Is the opportunity to relicense really worth alienating people who would otherwise be doing free work for you?

As the main reason why I got Nokia N950 is that I promised to write some applications for that, I started to look deeply at available options how to write them. Unfortunately there are too many options and all documentation I've found is pretty confusing. The short story is that you should use Qt for user interface. However it is not that easy as it looks, you can use regular Qt, which can be run on the phone, but looks ugly in the end (maybe I did something wrong, but it did look completely different to anything else running in the phone). You can use Qt Quick, which is easy to write (simple UI definition and JavaScript variant for code), but it does not seem to support much of the widgets. And then there is Meego Touch library, which seems like a best option, however not mentioned at all on Nokia developer website. Looks like I need to learn few more things before actually starting to code.

Filed under: English Meego 7 comments Flattr this!

Sitting in , , (Banja Luka, Republika Srpska, Bosna i Hercegovina) let s just say the country is pretty nice. People are okay, the beer is not called Nektar by accident, and the Mark (subunit Fennig, funnily enough) is worth 1 DM. Price niveau is below Germany (even when we had the DM) in some things, below or at modern European in others. In short, very affordable. They don t accept paper money though, it s really hard to get coins in most places, and they only want those. The food is okay, and my hotel is very luxurious. It s also got LAN. The weather is not so nice at the moment though: raining a lot, and expecting 30 C too-hot sun in two days. And there are still no Geocaches in the area. Anyway, DebConf is going on, I m acclimating and trying to get people, faces, nicknames and realnames connected. And accents. (And pronunciation of names for example, Ian differs totally from what I d use.) We even have working wire network (LAN) most of the time ;-) We re indeed still working on resurrecting m68k, but that s no news. More on that later, I d say.

If you thought Debian/m68k was dead and buried and where happy about it, I'm sorry to disappoint you. The reason m68k had died out slightly was not that we'd lost interest, or that we'd been kicked out of the archive, or anything of the sorts, as I've seen people believe. Instead, the reasons were fully technical: glibc past some particular version needs TLS (thread-local storage) support, which hadn't been implemented for m68k yet, and nobody within the Debian/m68k team had the expertise to work on this. That was all. Not so long ago, some people within RedHat had started doing a TLS implementation for m68k, however. This was paid for by one of their customers who needed the ColdFire to work, and therefore it was focused mostly on ColdFire. However, ColdFire is close enough to plain old m68k that it was possible to port this TLS support to plain old without too much effort. Unfortunately, most of our machines were pretty much nonfunctional by that time; so in order to get things to work, we'd have to

• Reinstall some of our machines, fix the others, without a functional installer,
• Do the necessary porting and package integration work,
• Rebootstrap the architecture,
• do other things necessary (such as providing a working installer, etc).

Not quite impossible, but still a lot of work that would need someone to put in quite an amount of time. This wasn't something that people in the m68k port could invest; and I'm also not sure we had the necessary skills amongst the team to do the necessary porting. So the work lay there, and it wasn't being done. Until one Thorsten Glaser, author of a shell called 'mksh' that I hadn't heard of until then, came along, and noted that his mksh package wasn't being built for m68k. Upon investigating, he discovered, as expected, that the port was almost dead. Now most people would leave it at that and decide that they couldn't build for an architecture that wasn't being maintained anymore and that would be perfectly fine but not Thorsten. On the brink of death, he almost single-handedly revived the m68k port, and got stuff to work to such an extent that it is now again possible to build a working and fairly up-to-date Linux/m68k ARAnyM virtual machine. As I'm typing this, my ARAnyM instance is checking out the d-i repository (so I can start building d-i), and building sudo at the same time. Let's see what comes from this.

Recently I received a bug report for psmisc that basically supplied a patch so psmisc works in a cygwin environment. Nothing terribly exciting in that and the changes are pretty uncontroversial. One of the changes is in that instead of using rawmemchr to find the end of the string, cygwin doesn t have that function and so it is replaced by strchr. I ve not seen the function rawmemchr before so I had a closer look. Initially I was a little worried, rawmemchr tries to find the given byte starting at a given pointer but unlike strchr it doesn t stop unless it finds the character. I think the only time this function is safe, or is no more evil than anything else, is when you are searching for the NUL character which is what fuser in psmisc does. Still, the string being checked is coming from getcwd which requires a string or buffer length so perhaps it would be better to use memchr which is a little slower but has a maximum length parameter. If you have code that uses this function, you may just want to check how it is being used because it seems like an old bad gets function that plagued a lot of programs.

If a single man can display so much hatred
think only of how much love we all can display together.

Stine Renate H heim

I wrote a Norwegian post explaining my experience at Ut ya. I had taken this blog for dead, and had entirely forgotten that it was syndicated on Planet Debian. I don t want to let Google Translate make this disaster any worse than it is the translation of bullets into balls being particularly bad so the international attention the massacre has garnered in consideration, I am writing an English translation of my experiences. I feel somehow duty-bound to make people aware of what happened, but I don t want to get into anything else but a sober description of the events and some very brief reflections. There are many details I have chosen to omit. Others have written their experiences of the events at Ut ya. I wanted to write mine down as well, and get it out there . Partly, I want to write this down because I m unsure if I will remember all the details at a later point in time, although I think I d prefer it if I couldn t. I m also writing this because people are asking about my experiences and it s much better to have an URL to give them, lest I have to keep going through the same spiel over and over again. Our former Prime Minister and current labour movement demigod Gro Harlem Brundtland had recently left the island. I had been the cameraman for a video interview of her talking about Ut ya, and I was in the media group room encoding the video into a file suitable for YouTube, when someone else in the room startled and said that Twitter was full of messages about a loud explosion in Oslo. As the newspapers brought us information about the extent of the damages, a consensus arose that an informational meeting was in order. As soon as the current round of talks finished, we were gathered into the main hall. The meeting was duly held, and after the statement was made that a TV feed would be made available, I took it upon myself as the local alpha geek to make it happen. Of course, the situation caused both the wireless network and the GPRS networks to become totally unusable. As I was waiting for someone to set up a password, I took the opportunity to face the consequences of having eaten two bits of a microwavable dish called Hold-It the local equivalent of a Hot Pocket and went to the toilet. As I was in there, I first heard agitated shouting, then screams, then gunshots coming from just outside the toilets. More than anything else, it sounded like a toy gun. I was convinced that someone was making a joke in incredibly bad taste and I stormed out of the booth with the intent of halting it. As I tore the door open, I saw two of my comrades hiding in a recessed corner. Their facial expressions left absolutely no doubt that this was no toy. They signalled for me to get back in the booth. I closed the door, did a mental double-take in utter, complete confusion, and opened it again. They were still signalling. Had they not stood there, I would have run straight into the gunman; they saved my life. I looked out into the hallway, and I made eye contact with a young boy lying in a pool of blood. He was motioning for me to help him. I heard more gunshots from inside the building and retreated back inside. As I was trying to think through my next move, I realized that the decidedly insubstantial wood-fiber door would not resist any kind of bullets. I made my way out into the hallway, with the intent of escaping outside. At that point, I was of course not aware that there was an intention to kill as many as possible, so I thought that the open spaces outside would be a place of relative safety. Of course, this proved to be wrong and my life was probably saved a second time by one of the caf volunteers taking me into a hard-to-spot employee s bathroom. We sat there for ninety minutes. Always ready to make a run for it, ready for just about anything. A peculiar group dynamic arose with these two people with whom I had barely previously spoken. We came to share a strange sense of common destiny and gallows humour. One of them had seen the shooter and described the police uniform. I perceived it to be realistic that we were the only ones aware of the wounded outside the toilet. I tried to reach the emergency services, but all their lines were busy; the terror attack in Oslo had probably clogged their lines. I finally got through to the fire services, who could inform me that the police did know about the situation and were on their way. This was to take 90 minutes and by the time we evacuated, the young boy outside my door had perished. The despair I first saw in his eyes as I passed him, fleeing from one room to the other and the empty, blank stare as we left, are burned into me and they are images I will never in my life forget. Finally, the real police arrived. We walked out. I chose the path through the minor conference hall something I now regret. The sight was simply beyond my capacity to describe fully, and so terrifying that I barely remember the sight only the terror it struck in me. There were several people bunched up in a corner, a big amorphous heap of bodies. Some were conscious and yelled at me not to do anything that could startle the police, others lay still. Their bodies were all covered in blood, and a thick pool of blood extended at least a half-metre in all directions around them. The policeman across the hall was screaming orders at me, but he was screaming so loudly that I couldn t make out his words at first. We were first moved into the camp newspaper s offices. There were about eight of us there, I think, in addition to one girl who lay wounded. Towards the end she was drifting in and out of consciousness. We covered her with sweaters to keep her warm and one of us tried to at least temper her bleeding. The bullet had missed her heart, but by the entry wound it was clear that it was not by far. I do not know who this girl was or how she is now. I sat behind and never saw her face. The wounded were evacuated first. I don t remember how long we remained; I had lost all concept of time. In spite of protests from the group who knew him, one kid was put in handcuffs. At the time I didn t understand why, and the policeman seemed to say something almost to the effect that there was no reason for it at all. I didn t see when they undid his cuffs, but I remember thinking that this treatment made a terrible experience even worse for him. I tried my best to comfort him but knew it would be little help. Later, when things stabilised a little, we were told that he was handcuffed because he had come from an unsecured area. The police was extremely good at carefully explaining what was happening and why; this was a big help and I am grateful for it. Eventually we were moved out into the main corridor of the building, where we joined up into a group of about fifty. Only when I saw the two people who saved my life did any emotion other than mild confusion arise. I broke down shivering in tears in one of their arms. After a few seconds, I came back to my senses and realised that this was not the time. I quickly gathered myself, got the shaking under control, and sat down. We were given some chocolate and soda from the kiosk. I remember making an offhand remark that an inability to find joy in free candy was a sure sign of a bad situation. We all laughed out loud. Gallows humour is a coping mechanism, but in retrospect one almost feels guilty for it. We were shown out in a single file with hands above our heads. I remember an intense concern that someone would slip in the steep, muddy slope and create a misunderstanding. Outside, there were more bodies. Some under improvised covers a tarpaulin from the waffle stand, the deflated bouncy castle but some simply lay there. Everyone I met displayed a courage, a mental discipline and unity of purpose far beyond anything one would ever wish to expect from people this young. Everyone conducted themselves with an attitude that could almost be described as stiff upper lip . Safely across the fjord we were offered blankets. I was asked if I was aware of any injuries, and asked to lift my shirt and show my abdominal region. We were shown into the bus which took us to the hotel used by the survivors and their family. I simply cannot describe in any words the relief I felt when I was able to embrace my living comrades. It was completely unlike anything I had ever felt before in my life. The euphoric feeling was tempered only by the realisation that there would be many I could never see again, comrades whom I had taken great pride in calling my friends, with futures in the service of all mankind, futures I had previously found such great joy in pondering and guessing about. The feeling which continues to upset me the most, is the feeling that so many of my comrades left behind grieving families and friends. Torn away senselessly. I do not know how much more than this relatively sober account of the events on Ut ya I can muster. I would, however, like to offer some reflections. First of all, from the bottom of my heart, I want to thank the police who saved the lives of so many still on the island, the holidaymakers who took aboard swimmers into their boats and the rescue services staffed primarily by volunteers who have spared no effort in trying to soften the blow as much as they can. The opportunity to spend time with those comrades who underwent the same experience as myself has also been an immeasurable aid. I was also so relieved to find my very closest friend among the survivors, which has also been an indescribable help. If I can name a single positive in this tragedy: Had he arrived with his automatic weapon fifteen or twenty minutes prior, he would have arrived during the informational meeting, at a time when the major hall was absolutely jam-packed the death toll would be many times what it ended up being. I am agonisingly aware of the meager comfort this provides to those who have been bereft of their closest, but I do find some solace in this. We cannot sweep under a rug that this was without question! a political attack on the labour movement. But it is thankfully also an attack which has been perceived by everyone as an attack on the Norwegian society, and on a symbol of the wide recruitment to the participatory democracy which lies at our very national soul. I cannot thank the Norwegian people, and indeed the people in other nations who have offered their condolences, enough for their shows of support and shared grief. It really has been a tremendous help to me knowing that so many people feel with us. I also want to thank from the bottom of my heart the rock-steadiness of everyone in both the national and local wings of the Labour Party and Labour Youth in supporting us, and the political milieu in general for their resolute steadfastness saving me from losing yet more that I cherish; our freedoms in a participatory democracy. Our Party has lost many of its very brightest youngsters. Personally I feel an angry spite, a deep restless urge to get the wheels of society going again. I want to show his kind that we will not be broken. We re stronger than that. I will not be frightened into silence and passivity. I want to remember the dead, and honor them by carrying on our common work. I want to end this with a request to everyone who reads this, echoing a statement I read by one of my good friends and comrades: Please, don t let me see any messages of hatred, wishes for the death penalty, anything like that. If anyone should be of the belief that anything will improve by murdering this sad little person, they would be profoundly wrong. All attention now should be plowed into caring for those victims and their relatives who did not share my luck, and not giving an audience to a perpetrator who wants one. Tore Sinding Bekkedal

I have released version 0.18 of Obnam, my backup application. From the NEWS file:

• The repository format has again changed in an incompatible manner, so you will need to re-backup everything again. (If this is a problem, tell me, and I'll consider adding backwards compatibility before 1.0 is released.)
• New option --exclude-caches allows automatic exclusion of cache directories that are marked as such.
• Obnam now makes files in the repository be read-only, so that they're that much harder to delete by mistake.
• Error message about files that can't be backed up now mentions the correct file.
• Bugfix: unreadable files and directories no longer cause the backup to fail. The problems are reported, but the backup continues. Thanks to Jeff Epler for reporting the bug.
• Speed improvement from Jeff Epler for excluding files from backups.
• Various other speed improvements.
• Bugfix: restoring symlinks now works even if the symlink is restored before its target. Also, the permissions of the symlink (rather than its target) are now restored correctly. Thanks to Jeff Epler for an exemplary bug report.
• New option --one-file-system, from Jeff Epler.
• New benchmarking tool obnam-benchmark, which is more flexible than the old run-benchmark.
• When encrypting/decrypting data with GnuPG, temporary files are no longer used.
• When verifying, .../foo and .../foo/ now work the same way.
• New option --symmetric-key-bits.
• The chunk directory uses more hierarchy levels, and the way chunks are stored there is now user-configurable (but you'll get into trouble if you don't always use the same configuration). This should speed things up a bit once the number of chunks grows very large.
• New --chunkids-per-group option, for yet more knobs to tweak when searching for optimal performance.
• Local files are now opened using O_NOATIME so they can be backed up without affecting timestamps.
• Now uses the cliapp framework for writing command line applications. The primary user-visible effect is that the manpage now has an accurate list of options.
• Bugfix: Obnam now again reports VFS I/O statistics.
• Bugfix: Obnam can again back up live data that is accessed using sftp. Thanks to Tapani Tarvainen for reporting the problem.

I alse made releases of some dependencies of Obnam. They're all in my code.liw.fi repository, and some of them are also now in Debian unstable.

I have released version 0.18 of Obnam, my backup application. From the NEWS file:

• The repository format has again changed in an incompatible manner, so you will need to re-backup everything again. (If this is a problem, tell me, and I'll consider adding backwards compatibility before 1.0 is released.)
• New option --exclude-caches allows automatic exclusion of cache directories that are marked as such.
• Obnam now makes files in the repository be read-only, so that they're that much harder to delete by mistake.
• Error message about files that can't be backed up now mentions the correct file.
• Bugfix: unreadable files and directories no longer cause the backup to fail. The problems are reported, but the backup continues. Thanks to Jeff Epler for reporting the bug.
• Speed improvement from Jeff Epler for excluding files from backups.
• Various other speed improvements.
• Bugfix: restoring symlinks now works even if the symlink is restored before its target. Also, the permissions of the symlink (rather than its target) are now restored correctly. Thanks to Jeff Epler for an exemplary bug report.
• New option --one-file-system, from Jeff Epler.
• New benchmarking tool obnam-benchmark, which is more flexible than the old run-benchmark.
• When encrypting/decrypting data with GnuPG, temporary files are no longer used.
• When verifying, .../foo and .../foo/ now work the same way.
• New option --symmetric-key-bits.
• The chunk directory uses more hierarchy levels, and the way chunks are stored there is now user-configurable (but you'll get into trouble if you don't always use the same configuration). This should speed things up a bit once the number of chunks grows very large.
• New --chunkids-per-group option, for yet more knobs to tweak when searching for optimal performance.
• Local files are now opened using O_NOATIME so they can be backed up without affecting timestamps.
• Now uses the cliapp framework for writing command line applications. The primary user-visible effect is that the manpage now has an accurate list of options.
• Bugfix: Obnam now again reports VFS I/O statistics.
• Bugfix: Obnam can again back up live data that is accessed using sftp. Thanks to Tapani Tarvainen for reporting the problem.

I alse made releases of some dependencies of Obnam. They're all in my code.liw.fi repository, and some of them are also now in Debian unstable.

Sorry for the late notification about the video streams. We ve been rather busy down here. However, DebianDay is about to start, and it looks, like it will turn out to be a great event! The Video Setup is finished, too. The easiest way to watch the streams and to participate via irc is by using the Web 2.0 thingy at http://debconf11.debconf.org/watch.xhtml. You can also point your preferred video player at http://video.debconf.org:8000/Roundroom.ogv for the smaller round room, or http://video.debconf.org:8000/Auditorium.ogv for the larger auditorium, where DebianDay will take place. The full schedule for the entire conference is available at http://penta.debconf.org/dc11_schedule/index.en.html. As usual we ll make the videos available for download later.

In my previous post I expressed a desire to use regular expressions for files that may appear in multiple places in the tree due to bind mounts for /run and /var/run etc [1]. However there is a problem with this idea. The SE Linux file labeling program restorecon reads the file /etc/selinux/$SELINUXTYPE/contexts/files/file_contexts which contains a set of regular expressions to assign labels to files. That file is ordered and the last entry which matches is the one that counts. When the file_contexts file is created the order is based on how many characters at the start of the file specification aren t regular expression meta-characters. For example the entry /.* is at the top of the file (and therefore has the lowest precedence), which makes it the catch-all entry for files that have no other match. So an entry for /var/run/REGEX will have a higher precedence than one for /var/REGEX , this means however that when I replaced the /var/run part with a regular expression then it had a lower precedence and it didn t work properly. I should have remembered this as I did a lot of work on setfiles (which became restorecon) in the early days. I have now developed a new way of solving this and this time I m testing it before blogging about it. I have written the following PERL program to fix the file contexts, this adds multiple lines and uses a distro_debian conditional on them so that they don t slip into upstream use and so that if I lose track of where each patch came from I ll know that I can delete them in future because it only matters to Debian. #!/usr/bin/perl
use warnings;
use strict; open(LIST, "find . -name \"*.fc\" xargs egrep \"^/(var.*run) (var/lock) (dev/shm)\" cut -f1 -d: uniq ") or die "Can't get file list\n";
while(<LIST>)

my $filename = $_;
chomp $filename;
open(my $infile, "<", $filename) or die "Can't open file $filename";
open(my $outfile, ">", $filename . ".new") or die "Can't open file ". $filename . ".new";
while(<$infile>)

print $outfile $_;
my $newline;
if($_ =~ /^\/var\/run/)

print $outfile "ifdef( distro_debian', \n";
$newline = $_;
$newline =~ s/^\/var//;
print $outfile $newline;
print $outfile "')\n";

if($_ =~ /^\/var\/lock/)

print $outfile "ifdef( distro_debian', \n";
$newline = $_;
$newline =~ s/^\/var/\/var\/run/;
print $outfile $newline;
$newline =~ s/^\/var//;
print $outfile $newline;
print $outfile "')\n";

if($_ =~ /^\/dev\/shm/)

print $outfile "ifdef( distro_debian', \n";
$newline = $_;
$newline =~ s/^\/dev/\/run/;
print $outfile $newline;
print $outfile "/var" . $newline;
print $outfile "')\n";


close($infile);
close($outfile);
rename $filename . ".new", $filename or die "Can't rename " . $filename . ".new to " . $filename;
The next policy thing that I have to work on is systemd. From a quick test it seems that systemd policy changes will be more invasive than is suitable for Squeeze. This means that someone who wants to upgrade from Squeeze to Wheezy+systemd will have to upgrade to Wheeze policy before installing systemd. I think that I will make 0.2.20100524-10 the last version in Unstable based on the 2010 release, I will now start work on packaging the latest upstream policy for Unstable. PS I m not much of a PERL programmer, so if anyone has suggestions for how to improve the above PERL code then please let me know. Please note however that I m not interested in making my code look like line-noise.

• [1] http://etbe.coker.com.au/2011/07/22/run-se-linux-policy/

Oppdatering: Jeg har skrevet en engelsk versjon av dette som er mer gjennomtenkt. I have written an English version of this post which I have had more time to think through. Det var meningen f rst ha dette som en kladd, for senere g igjennom og skrive mer, men WordPress krangler og jeg orker ikke finne ut av det. Derfor publiserer jeg dette n . Jeg har lenge nsket sette opp en ny bloggmotor men har aldri kommet meg til gj re det og dette er definitivt ikke tidspunktet, s jeg gjenoppliver min gamle, engelskspr klige blogg. Andre har skrevet sine fortellinger om hva som skjedde p Ut ya. Jeg ville gjerne skrive ned min ogs , f den ut. Jeg vil dels skrive det ned fordi jeg ikke vet om jeg vil huske alle disse detaljene senere. P en m te h per jeg ikke det. Dels ogs for at jeg skal slippe m tte beskrive dette hele tiden for alle som sp r. Gro Harlem Brundtland hadde nylig forlatt leiren. Jeg hadde tatt opp en videohilsen fra henne, og var i kontoret til mediegruppen for redigere filen til noe vi kunne laste opp p YouTube. En av de som var i rommet skvatt til og fortalte at Twitter var fullt av meldinger om en eksplosjon i Oslo. Etterhvert som pressen kunne fortelle om hvor angrepet hadde skjedd, ble det mer og mer tydelig at et informasjonsm te var p sin plass. Det ble enighet om at det m tet skulle avholdes etter at bolken med innledninger var ferdig. Informasjonsm tet ble avholdt, og jeg tok p meg som den lokale nerd-in-chief sette opp en laptop som kunne vise NRK Nett-TV s folk kunne f sett hva som skjedde. Det tr dl se nettverket gikk nesten umiddelbart ned, s vi ble enige om at det skulle settes et passord p det. I p vente av at noen andre gjorde det, gikk jeg p do. Idet jeg satt der, h rte jeg f rst agitert roping, s skriking, s skudd. Det h rtes mer ut som en lekepistol enn noe annet og jeg antok at dette bare var en eller annen som kom med en totalt smakl s vits. Med dette i tankene, kom jeg n rmest stormende ut av b sen men idet jeg vrengte opp d ren s jeg to mennesker som signaliserte at jeg skulle komme meg inn igjen. Ansiktsuttrykkene deres levnet overhodet ingen tvil om at dette var alvor. At de var der reddet utvilsomt livet mitt. Jeg var mest av alt forvirret. Jeg antok der og da det var en AUFer som hadde gjort dette, g tt amok. Jeg tittet ut igjen. De to var der fremdeles. Denne gangen s jeg en person som l der p gulvet, i en blodp l. Jeg hadde yekontakt med ham, og han signaliserte tydelig etter hjelp. Jeg tenkte umiddelbart at de d rene ikke ville st imot noen som helst type kuler, s jeg tenkte kun p forflytte meg vekk fra b sen. Min f rste tanke var komme meg utend rs. Jeg l p ut korridoren, og akkurat da kom en fra kaf gjengen mot meg. Hun pnet ansatt-toalettet, og jeg, hun, og en annen kastet seg inn. Det er bare en av de mange tilfeldighetene som jeg i etterkant m innse at jeg antar reddet livet mitt. Vi satt der, i halvannen time. Klare til l pe, klare for egentlig hva som helst. Det ble til en eiendommelig dynamikk mellom oss tre, en slags perpleks galgenhumor. Jeg, ettersom det var helt realistisk at v r gruppe var den eneste som visste om likene i bygget, pr vde umiddelbart f varslet om det. 112 fungerte ikke. 110 fungerte ikke. Til slutt kom jeg igjennom p 113, og de kunne opplyse om at politiet var klar over situasjonen og var p vei. Det skulle ta halvannen time, og da vi ble evakuert l han der d d. Det ekte politiet ankom omsider. Vi gikk ut. Jeg tok veien rundt lillesalen, noe jeg i etterkant angrer p ; det jeg s der vil nok bli med meg en stund. Det l en haug med folk jeg husker ingen ansikter, bare et stort, amorft sammensurium av kropper i en fryktelig stor blodp l noen av dem, jeg mener huske to, var fremdeles bevisste. Vi ble f rst flyttet til Planet Ut ya-kontoret leiravisa hvor det var en jente som hadde blitt skutt. Vi rev opp noen poser med gensere fra lageret og dekket til henne. Der satt vi en stund jeg hadde forlengst mistet tidsbegrepet jeg mener det m ha v rt tolv av oss. En av ungdommene ble trass i protester fra de i gruppa som kjente og gikk god for ham p f rt h ndjern. Jeg forstod ikke helt hvorfor. Senere ble vi forklart at det var fordi han hadde kommet fra et omr de politiet ikke hadde oversikt over. Jeg s ikke n r de h ndjernene ble l snet, men jeg husker ihvertfall at det slo meg som uverdig behandling. Politimannen som hadde vakt p posten der vi var, var veldig dyktig til forklare oss situasjonen. Vi ble flyttet ut til hovedkorridoren, hvor omkring 50 av oss var. F rst idet jeg s og omfavnet de som antakeligvis reddet livet mitt, knakk jeg sammen i gr t. Jeg tok meg fort inn igjen, fikk skjelvingen under kontroll, og etter en del venting ble vi marsjert med hendene p hodet mot fergen. Jeg husker hvor redd jeg var for at noen skulle gli i den bratte, gj rmete bakken og skape en misforst else. Det var flere lik ute. Noen var tildekket p improvisert vis, andre l der bare. Alle jeg s viste mot, ro og beherskelse p et niv langt over det noen nsker forvente fra folk i de aldersgruppene. Det var et samhold og en m lbevissthet som gjorde et inntrykk. Vel over fjorden ble vi tilbudt tepper. Jeg ble spurt om jeg var skadet, og bedt om vise mageregionen. Vi ble loset ombord i bussen, og kj rt til Sundvolden hotell. F lelsen, den totalt utrolige lettelsen av se sine n rmeste venner igjen kan jeg virkelig ikke beskrive. Lettelsen ble temperert av usikkerheten rundt de man ikke s . Det dreier seg blant annet om mennesker som jeg i skrivende stund m anta har mistet livet. Blant dem mennesker jeg tidligere hadde hatt stor glede av vissheten om at kom til gj re fantastiske ting i landets og verdens tjeneste n er de revet vekk. Jeg vet ikke hvor mye mer enn denne litt n kterne rapport av hendelsene jeg klarer komme med akkurat n . Men slik var det ihvertfall jeg opplevde situasjonen jeg kom ut av takket v re en serie tilfeldigheter. Litt kort vil jeg legge til: Redningstjenestene var en stor hjelp. Vel s stor, om ikke st rre, har muligheten til tilbringe tid sammen med de andre overlevende v rt. Vi holder sammen og tr ster hverandre med v r felles erfaring. Ett lyspunkt ser jeg her: Mest av alt er jeg s utrolig glad for at han ikke var fremme tyve minutter tidligere, under informasjonsm tet. Da var hele Ut ya samlet som sild i t nne i hovedsalen, og med hans automatv pen ville d dstallene i l pet av noen titalls sekunder blitt det mangedobbelte av det vi endte opp med. At det er en veldig mager tr st for de etterlatte er jeg inderlig klar over. Mine aller dypeste tanker er med dem alle. Dette var et angrep p hele det norske demokratiet. I forvirrelsen f ler jeg en bitter trass. Vi skal vise hans likesinnede at det er sterkere enn som s . Jeg vil ikke la meg skremme til taushet og passivitet. Jeg nsker minnes de d de, og deretter hedre dem ved fortsette arbeidet de var en del av.

I m here at DebConf11 and it started in the worst possible way. First my wife and me had the pleasure of being guests of the Bosnien border police for 11 hours. Overnight stay in a small room in a small building far away from whatever we know. And unknown status when it goes on. Oh fun. And then, after finally arriving here, my Laptop breaks. Stupid machine, why break at the beginning and not at the end of the conf? It heated up, all to 120 C (which I don t believe is good, nono) and then turned off. Came back on some time later, but the graphics card got a kick. The left part of the screen now shows a big white strip all over it. Which doesn t help it at all. Additionally the thing does not want to operate below 70 C anymore. At least it only takes seconds for it to heat up that far. The fans stay off. There is a way to turn them on by software. If i use that way - the temperate quickly climbs over 100 C. WTF? Well. Guess that means I am looking for a replacement. I don t have too many requirements. Basically I want a BIG screen (and I mean big, my current has 17 ) and that it works well with Debian. Reasonable battery life (1.5hours is reasonable for such a thing, anything more is fine. Its NOT a mobile thing to use on trips, for that I have other devices. It is a workstation you can easily take with you) and the usual rest of a good CPU, at least 4GB RAM and >60GB Harddiskspace. Any suggestions?

why proprietary relicensing is unacceptable for a Free Software enthusiast The past few months have witnessed a large debate about copyright assignment, which seems to has neared its peak around the time Project Harmony has released version 1.0 of its agreement templates. (Note: I use the expression "copyright assignment" in this post, but I'd happily include into it both actual Copyright Assignment Agreements CCAs and Contributor License Agreements CLAs, as both could be used to permit various forms of proprietary relicensing.) Mark Shuttleworth has been one of the most prominent voices campaigning in favor of copyright assignments (to for-profit companies). A couple of interesting blog posts of his where this is evident are "On balancing economic power in the FLOSS ecosystem" and "The responsibilities of ownership". Voices against the opportunity of increasing the popularity of copyright assignments are aplenty and it is pointless to repeat good arguments which I find fully convincing. If you are interested in the subject, here are a few good reads I recommend:

• "Some thougts on copyright assignment", seminal essay (circa end of 2009) by Michael Meeks that provides a good coverage of copyright assignment basics and effects on the surrounding ecosystem
• Richard Fontana's "The trouble with Harmony"; in particular, I recommend taking a close look at "The illusion of constraint" part

What I would like to add to the debate is the point of view of a Free Software enthusiast, not unlike yours truly. I contribute to Free Software not because it is superior to proprietary software in either its software products or in its development methodology. (It actually is superior in many cases, but that's just not my primary motivation.) I do contribute to Free Software to build a world in which users are in complete control of the software they run. Let's assume we have a broken toaster at home. We are all free to (1) open it up and try to repair it by ourselves. If we don't have the needed knowledge, we are free to (2) hand it over to a person that we trust and who does have the needed knowledge to repair it. That failing, we can (3) ask the toaster producer to repair it for us. Many people like me simply don't accept to live in a world where, once all the toasters will be software-driven, the only repair option will be (3), just because the toaster software is proprietary. (Given various kind of [broken] metaphors have been used to explain copyright assignments, it seemed sensible to propose my broken toaster metaphor in exchange.) When I contribute to some Free Software project, I not only care about being able myself to get a Free Software licensed copy of the whole product (i.e. the original software product + my own contribution). I care that all recipients of the product, present and future, will be able to get that contribution with enough freedoms attached to put them in control of the software that includes it. This desire can be fulfilled with a varying degree of success, depending on the license of the code base I contribute to. For instance, I find more pleasant to contribute to a copyleft licensed code base than to a weak-/non-copyleft licensed one, and more pleasant to contribute to an AGPL-ed web app than to a copyleft web app. It also means that, given the option, I will not allow the code base maintainer to re-license my contribution under terms that allow distributing it without suitable freedoms attached. Different contributors will be ready to accept different re-licensing promises, but the mere fact we are debating all this and that companies like Canonical feel the need of campaigning for copyright assignments is evidence that many contributors like me exists and actually have a problem with allowing downstream relicensing of their contributions. What is feared the most is of course proprietary relicensing. According to my moral horizon this is the case not because the company might end up gaining money out of my code: I wouldn't have a problem with that. The reason is rather that the company will be able to distribute my own code in a way that grants less freedoms to users than those that were implicitly "agreed upon" when the contribution has been written. In that respect, I can't help thinking at harmony agreements as a large scale smoke screen experiment meant to convince volunteers that copyright assignments are something Free Software needs. By exploiting the creative-commons-like "it's easy, just choose one" scheme, Harmony takes the chance of offering misleading options such as the one labeled "any OSI approved license". Via that option, which is seemingly fine, the copyright recipient will be allowed to relicense the contribution under some non-copyleft license (e.g. BSD) and from there do essentially what they want. All in all, companies campaigning for copyright assignments seem to have failed to understand two main points. The first one is that contributors motivated by Free Software ideals want the code to remain free not only for themselves, but for all recipients of the code. I'm not claiming that all contributors to FOSS projects belong to this category, but the fact that there is a considerable amount of such people is undeniable. Hoping that they will be fooled by tricks like the "any OSI approved license" agreement is foolish. The second is that while volunteer Free Software communities do respect companies that provide huge amounts of code contributions, they also expect companies to figure out by themselves which business models make their businesses sustainable. Telling volunteers that current business models are not sustainable without proprietary relicensing is worthless. Volunteers just don't care. They want software freedom guarantees and are not willing to renounce to them in exchange of the wealth of companies, not even under the (implicit) threat that otherwise those companies will be forced to reduce the amount of their code contributions.

---

Update: explain in the initial note why my reasoning here encompasses both CCAs and CLAs. Thanks Tollef for noticing that it wasn't clear.

As I type this, it's just passed midnight. I'm in the back of a BMW somewhere in east Germany , and the Debian UK convoy is doing 110 mph on the autobahn, twenty hours into a twenty-five hour first leg of our trip to Banja Lunka. This all started out so sanely with a 3 am departure to catch the 6 am ferry at Dover. Followed by a couple of hours leisurely breakfast onboard. First hint that yes, this is a road trip in which things will go wrong was a minor bumper denting of one of the convoy's cars by a stray landrover during the ferry trip, but it didn't really phase us. On to Cologne, for a very nice lunch and to pick up another person. But we didn't anticipate how brutal the next leg to Gratz would be. Nor did we count on apparently half of Germany and the Netherlands getting out their campers and heading east this Friday. Spent multiple hours stop-and-go, and many more in constant traffic. Finally it opened out, so we can follow the night speed limit. And while we started out horsing around on the radio, we've developed some real comms discipline by now to keep the convoy together. Also people seem to be amazingly keeping rested while not driving. To add to the sleep debt to me, I flew in the day before, but I actually feel caught up now. Still I've not been driving at all due to mislaid license and general inability to safely drive a right side drive stick shift at 100 mph at night. Our 7 drivers are doing an amazing job. Update: Arrived safely in Gratz at 4 am. Austria tantilized with 30+ miles of tunnels thru the alps, but I've not seen an alp yet.

---

PS, you'll never appreciate a stinky, free bathroom until you're in a country where all the antiseptic bathrooms cost money and hoards of vacationers are doing the logical thing next to service stations.

Lintian now has a warning for debian/rules missing build-arch and build-indep targets. As a dh user, I was surprised that some of my dh-using packages had this problem. And when looking at the source, I remembered how I came to this: GNU make is stupid. Considering the following excerpt of the GNU make manual:

.PHONY

The prerequisites of the special target .PHONY are considered to be phony targets. When it is time to consider such a target, make will run its recipe unconditionally, regardless of whether a file with that name exists or what its last-modification time is.

And considering the following debian/rules:

.PHONY: build
%:
        dh $@

What do you think happens when you run debian/rules build in a directory containing a build file or directory?

make: Nothing to be done for build .

However, an explicit rule, like the following, works:

.PHONY: build
build:
        dh $@

It happens that many of the packages I maintain contain a build subdirectory in their source. As such, to work around the aforementioned issue, I just declared the dh rules explicitely, as in:

.PHONY: build binary binary-arch binary-indep (...)
build binary binary-arch binary-indep (...):
        dh $@

And this obviously doesn t scale for new rules such as build-arch and build-indep. To be future-proof, I ll use the following instead:

.PHONY: build
build %:
        dh $@

I don t know why I didn t do that the first time

This probable is more a tweet [Edit: typo.Thanks to Robot101 :D] than a blog article, but since my last post was about the same subject, I felt it'd make sense to point this article out.

Its author analysed in a deeper way than what I did what the future looks (or is?) like and, I have to say, that after a bit of time spent on G+, I envisioned pretty much a similar future, reason for which I started following Edd Dumbill on G+ and of Twitter ;)
Also thanks to Zack for mentioning the article.

End of post, I said it was short, didn't I? ... and I made it longer than what originally conceived :)

It looks like I might actually lose it sooner than I was thinking in my previous blog post, a few days ago. On the 18th, Formateur Elio di Rupo had written a proposed document on which to start negotiations. Most parties agreed to that, except for N-VA and CD&V. Unfortunately, that was enough to make further negotiations useless, so di Rupo had offered his resignation as formateur to the King, who kept his response "under advisement". I thought I was going to end up like Andrew. Since he wasn't formally ex-formateur yet, however, he continued working. And today, merely a few days later, with an extra proposal and perhaps also partly due to the King's angry speech for today's national holiday CD&V has now been persuaded to join the negotiations. It's been over fourhundred days, and far too many weirdos, but they're actually sitting down to talk. Like, right now. I'll hold off on buying those razor blades for now, but we might yet get there.

... or TDDD and DEP8 context As a nice byproduct of the huge "rolling" discussion we had back in April/May, various people have brainstormed about applying Test-Driven Development (TDD) techniques to Debian development. Here is a brief summary of some opinions on the matter:

• a seminal conversation on identi.ca
• a couple of blog posts by Lars, discussing the general problem of how to use TDD in distribution development and to a lesser extent its instantiation to Debian
• a separate post by Daniel stressing the specific TDD advantage of increasing the confidence of maintainers in making far reaching changes

... and hey, they've also coined the cool TDDD acronym, which I hereby took the freedom to re-target to Test-Driven Development in Debian. Having a cool acronym, we are already half-way to actually having the process up and running *g*. more testing I believe Debian needs more testing and I've been advocating for that since quite a while e.g. at DebConf10, as one of the main goals we should pursue in the near future. Of course advocating alone is not enough in Debian to make things happen and that is probably why this goal has been (thus far) less successful that others we have put forward, such as welcoming non-packaging contributors as Debian Project members. There are important reasons for increasing testing in Debian. quality assurance Quality Assurance has always been, and still is, one of the distinctive traits of Debian. I often say that Debian has a widespread culture of technical excellence and that is visible in several places: the Debian Policy process, lintian, piuparts, periodic full archive rebuilds, the EDOS/Mancoosi QA tools, the cultural fact that maintainers tend to know a lot about the software they're packaging rather than only about packaging, the we release when it's ready mantra, etc. But caring about quality is not a boolean, it's rather something that should be continuously cherished, refining quality requirements over time. By simply maintaining the status quo in its QA tools and processes, Debian won't remain for long a distribution who could claim to care about package quality. Others will catch up and are in fact already doing that. In particular, we surely have room for improvements in our quality tools and processes for:

• Build time package testing. Several packages run their build-time test suites during package build. This aspect is somewhat supported by the Debian policy; we also do a best effort attempt to run build-time test suites via debhelper (starting from version 7). At the same time we could probably campaign more to encourage maintainers to look for build-time test suites which do not follow common Makefile target naming or, fwiw, which don't rely on make at all. TodoList.add("investigate and possibly file bug report against policy to encourage maintainers to run build-time test suites")
TodoList.add("investigate and possibly file bug report against lintian to spot the presence of [non-invoked] build-time test suites")
• Runtime package testing (AKA "as-installed package testing"). Some kinds of test-suites are difficult to run at build-time (e.g. complex applications that don't offer easy way to re-configure on the fly their filesystem paths) and some others are plainly impossible to run without having the packages to be tested properly setup (e.g. running services that are accessible only through the network) or an isolated, throw-away testbed (e.g. bootloaders, kernels, etc.). TTBOMK this kind of testing is not currently in use neither in Debian nor, indirectly, in any of its derivatives. autopkgtest (AKA DEP8) is a step in this direction; I will get back to it later on in this post.
• Integration testing. When applied in the context of distributions, integration testing is about testing package combinations, task (as in tasksel) combinations, basic system functionalities, automated installations, etc. This is the aspect that Lars has discussed the most (and in which he seems to be interested the most) so I don't feel like adding much. Still, it's interesting to note that on this front Debian has an important potential to exploit. The large base of its developers and the fact that the average Debian user is technical savvy mean that we can potentially collect a lot of test cases. It's "just" (with well-deserved double quotes) a matter of deciding a standard interface for test case submissions and developing a most likely virtualized test runner. At that point a continuous integration service that periodically run and publishes results can be setup independently from the rest of the Debian infrastructure and offered to interested eyes, such as Release Team's. Any taker?
• Automated code analysis and in particular automated bug finding is something which is becoming more and more common and finally, after decades of research viable. Successful proprietary tools and businesses are aplenty (a nice and very fun read on the subject is the story of Coverity), as well as FOSS solutions. For instance, the Linux kernel is routinely using Coccinelle to automatically find bugs and even produce the corresponding patches. Add to the above the fact that Debian is one of the largest software collection in existence (and quite probably the largest collection of Free software in existence) and is upstream of the packaging of that software for the most part. That turns Debian into a very peculiar platform for large scale automated code analyses. Not that we can aim at fixing all the bugs we are going to find, or even hope to tame all the false positives we are going to find. But we can offer an important service to the whole ecosystem of Free software and use it to pinpoint important class of bugs from a distribution point of view, such as nasty security bugs (as long as they can be automatically found ). DACA is a very good step in the right direction, even though it is still in its infancy.

reducing inertia Inertia is a recurring topic among Debian lovers (and haters). It is often argued how difficult it is to make changes in Debian, both small and large, due to several (alleged) hindrances such as the size of the archive, the number of ports, the number of maintainers that should agree before proceeding with a cross-package change, etc. It's undeniable that the more code/ports/diversity you have, the more difficult is to apply "global" changes. But at least for what concerns the archive size, I believe that for the most part it's just FUD: simply debunking the self-inflicted culture about how "dangerous" doing NMUs is might go and has already gone, imho a long way to fight inertia. Adding per-package and integration tests will make us go another long way in reducing inertia when it comes to performing archive-wide changes. Indeed if a package you are not entirely familiar with has extensive test suites, and if they still pass after your changes, you can be more confident in your changes. The barrier to contribution, possibly via NMU, gets reduced as a result. And if your change will turn out to be bad but still not spot by the test suites, then you can NMU (or otherwise contribute) again to extend the test suite and make the life easier for future contributors to that package. It smells a lot like an useful virtuous cycle to me. autopkgtest / DEP8 how you can help Of all the above, the topic that intrigues me the most is as-installed package testing. Work on that front has been started a few years ago by Ian Jackson when he was working for Canonical. The status quo is embodied by the autopkgtest package. At present, the package contains of various tools and the following two specs:

1. README.package-tests provides a standard format to declare per-package tests using the new debian/tests/control file. Tests come as executable files which will be run by the adt-run tool in a testbed where the package(s) to be tested is already installed. This part of the specs has been reified as DEP8 which I'm (supposedly) co-driving with Iustin Pop and Ian (for well-deserved credits).
2. README.virtualisation-sever describes the interface among the test runner and the testbed. A nice separation is provided among the runner and the testbed, enabling different testbed environments with a varying degree of isolation: you can have a "null" testbed which runs tests on your real machines (needless to say, this is highly discouraged, but is provided by the adt-virt-null tool), a chroot testbed (adt-chroot), or a XEN/LVM based testbed (adt-virt-xenlvm).

The specs allow for several runtime testing scenarios and look quite flexible. The tools on the other hand suffer a bit of bitrot, which is unsurprisingly given they haven't been used much for several years. At the very minimum the following Python development tasks are in need of some love:

• The usage of python-apt needs to be ported to recent API, as several used methods and attributes are now gone.
• Porting from dchroot to schroot is needed for the adt-virt-chroot backend.
• A kvm backend for the test runner would be nice.

If you are both interested in TDDD and grok Python, the above and many others tasks might whet your appetite. If this is the case don't hesitate to contact me, I'll be happy to provide some guidance.

---

Note: this post is the basis for the TDDD BoF that I will co-host with Tom Marble at DebConf11. If you plan to come, we will appreciate your thoughts on this matter as well as your help in getting the autopkgtest toolchain up and running again.

One of the first things that I worked on here at DebConf11 is supporting the HTML target in gnome-terminal. This means that if you copy a part of the screen and paste it into some application that handles HTML (such as evolution or my blog s edit field), attributes such as color and boldness are preserved. Here are some examples: A man page

MAN(1)                           Manual pager utils                           MAN(1)
NAME
       man - an interface to the on-line reference manuals
SYNOPSIS
       man [-C file] [-d] [-D] [--warnings[=warnings]] [-R encoding] [-L locale] [-m
       system[,...]] [-M path] [-S list] [-e extension] [-i -I] [--regex --wildcard]
       [--names-only]  [-a]  [-u]  [--no-subpages]  [-P  pager] [-r prompt] [-7] [-E
       encoding]   [--no-hyphenation]   [--no-justification]   [-p   string]    [-t]
       [-T[device]] [-H[browser]] [-X[dpi]] [-Z] [[section] page ...] ...
       man -k [apropos options] regexp ...
       man -K [-w -W] [-S list] [-i -I] [--regex] [section] term ...
       man -f [whatis options] page ...
       man  -l [-C file] [-d] [-D] [--warnings[=warnings]] [-R encoding] [-L locale]
       [-P pager] [-r prompt] [-7]  [-E  encoding]  [-p  string]  [-t]  [-T[device]]
       [-H[browser]] [-X[dpi]] [-Z] file ...
       man -w -W [-C file] [-d] [-D] page ...
       man -c [-C file] [-d] [-D] page ...
       man [-hV]
DESCRIPTION
       man is the system's manual pager. Each page argument given to man is normally
       the name of a program, utility or function.  The manual page associated  with
       each  of these arguments is then found and displayed. A section, if provided,
 Manual page man(1) line 1 (press h for help or q to quit)

A coloured diff from git

commit 55c514ae6a714abcfa818c33f00a2c051412c3d9
Author: Joachim Breitner <mail@joachim-breitner.de>
Date:   Thu Jul 21 12:08:56 2011 +0200
    Refactor vte_terminal_determine_colors_internal
    
    to work on VteCellAttr instead of VteCell, and use it in
    vte_terminal_cellattr_to_html.
diff --git a/src/vte.c b/src/vte.c
index 8bcc95d..7d4a6f1 100644
--- a/src/vte.c
+++ b/src/vte.c
@@ -6532,19 +6532,18 @@ swap (guint *a, guint *b)
 
 static void
 vte_terminal_determine_colors_internal(VteTerminal *terminal,
-                                      const VteCell *cell,
+                                      const VteCellAttr *attr,
                                       gboolean selected,
                                       gboolean cursor,
                                       guint *pfore, guint *pback)
  
        guint fore, back;

Midnight commander

  Links     Datei     Befehl     Optionen     Rechts
 <  ~/build/gnome-terminal/vte  .[^]> <  ~/build/gnome-terminal/vte  .[^]> 
 'n        Name            Gr e  Modifikations 'n         Name            Gr e  Modifikations 
 /..                      BERVZ. 20. Jul 18:23 /..                       BERVZ. 20. Jul 18:23 
 /.git                       4096 22. Jul 12:42 /.git                        4096 22. Jul 12:42 
 /autom4te.cache             4096 22. Jul 11:20 /autom4te.cache              4096 22. Jul 11:20 
 /doc                        4096 22. Jul 11:20 /doc                         4096 22. Jul 11:20 
 /glade                      4096 22. Jul 11:20 /glade                       4096 22. Jul 11:20 
 /gnome-pty-helper           4096 22. Jul 09:47 /gnome-pty-helper            4096 22. Jul 09:47 
 /perf                       4096 22. Jul 11:20 /perf                        4096 22. Jul 11:20 
 /po                         4096 22. Jul 11:20 /po                          4096 22. Jul 11:20 
 /src                       12288 22. Jul 12:41 /src                        12288 22. Jul 12:41 
 /termcaps                   4096 22. Jul 11:20 /termcaps                    4096 22. Jul 11:20 
  .gitignore                  935 22. Jul 11:20  .gitignore                   935 22. Jul 11:20 
  AUTHORS                      41 20. Jul 18:25  AUTHORS                       41 20. Jul 18:25 
  COPYING                   35068 22. Jul 11:11  COPYING                    35068 22. Jul 11:11 
  ChangeLog.pre-git        433051 20. Jul 18:25  ChangeLog.pre-git         433051 20. Jul 18:25 
  HACKING                     905 20. Jul 18:25  HACKING                      905 20. Jul 18:25 
  MAINTAINERS                 118 20. Jul 18:25  MAINTAINERS                  118 20. Jul 18:25 
  Makefile                  30512 22. Jul 11:20  Makefile                   30512 22. Jul 11:20 
  Makefile.am                1247 22. Jul 11:11  Makefile.am                 1247 22. Jul 11:11 
  Makefile.in               28812 22. Jul 11:20  Makefile.in                28812 22. Jul 11:20 
  NEWS                      43910 20. Jul 18:25  NEWS                       43910 20. Jul 18:25 
  README                      496 20. Jul 18:25  README                       496 20. Jul 18:25 
  aclocal.m4               377874 22. Jul 11:20  aclocal.m4                377874 22. Jul 11:20 
 *autogen.sh                  610 20. Jul 18:25 *autogen.sh                   610 20. Jul 18:25 
 
 BERVZ.                                        BERVZ.                                         
  10G/104G (9%)   10G/104G (9%)  
Hint: To look at the output of a command in the viewer, use M-!
~/build/gnome-terminal/vte $
 1Hilfe   2Men     3Ansicht  4Bear~ten 5Kopieren 6Ver~ben 7Mkdir    8L schen  9Men s   10Beenden

These changes are discussed in GNOME Bugzilla bug #365121 and can be downloaded in my git repository. Unfortunately, I later found out that I was not basing my work on the current development version, which has changed considerably, so we will see how and when my changes will actually make it into GNOME. Also note that my blog s HTML editor actually modifies the HTML code, so looking at the source of this page does not give you the code that I generate. Update: I ported my changes onto the vte-next branch, so they could be merged now. Please follow the bug report if you want to know more.

Flattr this post

Martin Michlmayr is a Debian developer since 2000 and I share quite a few things with him, starting with his age and involvement in the quality assurance team. He managed to be elected Debian Project Leader in 2003 and 2004. He s no longer as active as he used to be but his input is always very valuable and he continues to do very interesting things in particular concerning the support of NAS devices. Read on for the details. Raphael: Who are you? Martin: I m Martin Michlmayr. I m 32, originally from Austria, and currently living in the UK. I ve contributed to various free software projects over the years but Debian is without doubt the one I m most passionate about. I joined Debian in 2000 when I was a student. I worked on Debian more or less full time for a few years while I was pretending to study. Later I started a PhD to do research about quality and management aspects of volunteer free software projects. I investigated the release process in several free software projects, in particular looking at time-based releases. After finishing my PhD in 2007, I joined Hewlett-Packard. I m part of HP s Open Source Program Office and work on various free software and open source activities, both internally and within the community. Raphael: How did you start contributing to Debian? Martin: I first used Debian in the days of 0.93R6, some time around the end of 1995. The 0.93R6 release was still based on a.out but I needed an ELF-based system for some application, so I moved to Slackware. I then quickly moved to Red Hat Linux where I stayed for several years. I rediscovered Debian in 2000 and quickly decided to join the project. I cannot recall how I rediscovered Debian but when I did, it was clear to me that Debian was the ideal project for me: I could identify with its philosophy, I liked the volunteer nature of the project, and I found the size and diversity of Debian interesting since a large project offers a lot of different challenges and opportunities. I remember how many new things there were to learn and back then the documentation and other resources for new contributors were nowhere as good as they are today. My application manager, Julian Gilbey, was a great help he was incredibly friendly and passionate about Debian. I also remember meeting up with Peter Palfrader (weasel) for key signing when we were both in the New Maintainer queue. I was incredibly lucky with my New Maintainer process and soon became an official Debian Developer. Because there was a shortage of application managers, my first major contribution in Debian was to become an application manager myself and help other people join the project. Debian is a large project with a long history and a rich culture, so new contributors should expect that it will take some time to become familiar with everything. Fortunately, there are many resources, such as documentation and the debian-mentors list, for new contributors. Another great way to become familiar with the way things are done in Debian is to subscribe to various Debian mailing lists and ideally to read some mailing list archives. It s also a great idea to attend the Debian Conference or other conferences since meeting people in real life is a great way to integrate. I remember attending Debian Conference 1 in Bordeaux where I gave my first public talk. Finally, new contributors should find an area where they can make a unique contribution. Most people in Debian maintain packages but there are so many other ways to contribute. For example, most of my contributions were not technical but were about coordination and other organizational activities. Raphael: What s your biggest achievement within Debian? Martin: I m particularly proud of a number of achievements:

• New Maintainer: I helped a lot of people join Debian. It s great to help someone join the project and then see how they contribute. Of course, some people join Debian and then quickly become inactive or retire you never know in advance how it will work out. But I had the pleasure to help some truly outstanding contributors to join Debian.
• Quality Assurance: I helped improve QA processes within Debian. In particular, I realized a few years ago that a lot of packages had maintainers who were inactive and that nobody did anything about it. I started to write to those maintainers to see what could be done. It s hard because you don t know the circumstance of someone they may be inactive because of an illness or for other good reasons so you have to be friendly, but yet persistent. Fortunately, most maintainers I contacted were truly inactive and so they couldn t complain when I took their packages away.
• DPL: I acted as the Debian Project Leader for two years. I m particularly proud of this because Debian is a great project and it was an honour to represent it. I performed important organizational and coordination tasks. I also traveled to a lot of conferences and had the pleasure to meet many Debian Developers as well as users of Debian. It s very motivating to meet users and to hear how they use Debian and how we can further improve it.
• Debian on NAS: Debian is without the doubt the Linux distro with the best support for NAS (Network Attached Storage) devices. I was always impressed by what the OpenWRT folks have done to support wireless routers and wanted to do something similar for Debian. Unfortunately, wireless routers just don t have enough storage for a full distro. But then NAS devices came along and they obviously have enough space since they are meant for storage.

Raphael: Speaking about NAS devices: what exactly are you doing on this topic and how can people help? Martin: There are plenty of instructions on the Internet to install Linux distributions on NAS or various embedded devices by connecting a serial console and then typing in hundreds of commands. What I found is that such instructions significantly limit the user base because they are way too complicated for most users. There are just too many steps that can go wrong. So instead, in Debian, we provide a solution that just works: usually, you download a firmware image for your NAS device from Debian and when you upgrade you get the Debian installer. You connect to the installer via SSH and perform a normal installation. The installer knows about the device and will prepare everything for you automatically for example, it knows if the device has requirements for the partition layout and it will install the kernel where the device expects to find it; unfortunately, NAS devices are not like PCs, so the requirements are different for almost every device and therefore you need special code to support a new device. Finally, there are detailed installation guides and we provide help on our mailing lists. There are a number of technical areas for improvement. The installation could be made even easier, and it would be nice to support new platforms and devices. A bigger problem is that while we ve implemented a great solution for NAS devices, we haven t really extended this work to support other classes of devices. For example, tablets and mobile phones are getting incredibly popular and we don t have a compelling solution for such devices, mostly because of the lack of an appropriate GUI. Raphael: What are your plans for Debian Wheezy? Martin: I ve recently been asked by Stefano Zacchiroli, our current Debian Project Leader, to coordinate the care-taking of Debian finances. Debian, as a volunteer project, relies on donations and in-kind gifts (e.g. hardware) to maintain its infrastructure and to support various development efforts, such as funding sprints and other developer gatherings. Debian s money and other assets are held by affiliate organizations around the world. My responsibility will be to keep track of money and other assets (e.g. hardware and trademarks), work with the DPL to establish procedures related to the use of Debian s assets, and make sure that the procedures are followed. Finally, we want to publish public statements so our donors know how we use their donations to further improve Debian. I just started working on this and this will be my main activity in Debian in the coming months. Raphael: Speaking of money, I plan to run a fundraising to get the Debian book I wrote with Roland Mas translated (cf. http://debian-handbook.info). Is this something Debian should support? Martin: First of all, I should make it clear that I don t decide how Debian spends its money. This is up to the DPL to decide together with the project at a whole. I ll just make sure that procedures are followed and expenses tracked and reported properly. Having said that, in my opinion, it s unlikely that Debian as a project will fund this effort. It would be inconsistent with the position of the project not to fund work directly (only some related expenses, such as travel costs to allow Debian teams to organize face-to-face meetings). Whether Debian should support the fundraising effort by helping to promote it is another question and that s probably not as clear cut. It looks like a worthwhile effort, but on the other hand it would be unfair for authors of other Debian books for Debian to put its weight behind one and there are many other efforts that are worth promoting if you promote one, where do you stop? So while it sounds worthwhile, it s probably better for Debian to stay out of it. But somehow related to this, I sometimes worry about the fact that there are so few paid opportunities around Debian. If you contribute to the Linux kernel for a while, you have an excellent chance to get hired by someone and to work on the kernel full time. The kernel may be an extreme example but there are a lot of projects that have more paid opportunities than Debian, e.g. Mono, GNOME, OpenOffice/LibreOffice and KDE. Obviously, there are some Debian Developers who can spend some time on Debian as part of their job. I know that some Canonical employees contribute to Debian, that support companies like credativ improve Debian as part of their work, and that system administrators fix bugs or package new software as they deploy Debian. But I think this is a minority of contributors and even they don t work full time on Debian. Instead what I see is that a lot of people leave university, get a job and then no longer have time for Debian or people start a family and no longer have time. I can take myself as an example since I don t have nearly as much time as I did in the past when I was a student. I guess there are different ways to deal with this problem one would be to create more paid opportunities around Debian outside the project, another one might be to make it easier for new volunteers to join the project. I don t have the answers to these questions but it s something I wonder about, and I also wonder whether pure volunteer projects can still keep up with projects with a lot of full time contributors. Raphael: What motivates you to continue to contribute year after year? Martin: Debian is a great project with a great mission, goals and people. I contribute to make Debian a better solution and to promote the free software philosophy. Finally, the community around Debian provides a lot of motivation. It s amazing how much I ve learned about other cultures because of my involvement in Debian and how many friends I ve made over the years all around the world. Raphael: Do you have wishes for Debian Wheezy? Martin: Not really. I m pretty happy with the way things are going at the moment. We have made a lot of organizational changes in the last few years from which the project has greatly benefited. I m particularly pleased about the plans to adopt a time-based freeze. Raphael: Is there someone in Debian that you admire for their contributions? Martin: There are many people I admire greatly. I d like to mention Joey Hess because he s a great example to follow. He doesn t get involved in politics, is easy to work with and does great technical work. In fact, he has made not one but several contributions that have completely changed Debian (debconf, debhelper, and debian-installer). Furthermore, Debian has a lot of contributors who have done great work over the years but who are not very vocal about it. People like Colin Watson or Peter Palfrader. Debian has many unique contributors and the list of people I admire is much longer than the few people I just mentioned.

---

Thank you to Martin for the time spent answering my questions. I hope you enjoyed reading his answers as I did. He raised some interesting questions. Subscribe to my newsletter to get my monthly summary of the Debian/Ubuntu news and to not miss further interviews. You can also follow along on Identi.ca, Twitter and Facebook.

No comment Liked this article? Click here. My blog is Flattr-enabled.