If you would like to contribute to a session while watching the live stream, please join the respective IRC channels. These are: #debconf-auditorium and #debconf-roundroom on irc.debian.org. The Web 2.0 thingy at http://debconf11.debconf.org/watch.xhtml will be updated soonish.

The trip down from Gratz to Banja Luka was much easier than the day before. After a while you just get used to being sat in a car for ages. Plenty of nice scenery to enjoy through Slovenia. After a while our car's GPS's began to fail, showing us driving through fields, and we were stuck for 1.5 hours in a traffic jam when the 4 lane highway seemed to end. Got around that with some guesswork, and on into Croatia by back roads. The Bosnian border was an interesting experience, all the guards could say in English was "green card! green card!" -- which from an American POV is an unsettling thing to be asked for at a border, especially if they've already taken your passport away -- but at least we were not detained overnight. While drivers were away getting the car insurance settled it descended toward farce as we had to hand roll the cars forward to let trucks get into the country. (Or we thought we did.. one was rolled with the keys in it as it turned out.) Arrived at the Hotel in Banja Luka in the middle of a wedding, which was amazingly loud (I could still hear it from the 5th floor at 2 am). There's also a casino at the hotel, so first impression was garish and loud! ... But now that it's a rainy Sunday, seems much nicer here.

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.

Hello I m happy to announce that Perl6 (as rakudo) is now available on Debian unstable. Thanks also to Gabor Szabo for the Perl6 talk he gave at FOSDEM. His talk made me think: Why the hell don t we have rakudo on Debian ? . So I stepped up, pushed to get a recent parrot package, ghedo and I created a pkg-rakudo team on Alioth, and we updated the old rakudo package done by ryan52. Enjoy

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/

When Marvell originally released the first plug computer, they created their own version of u-boot with support for their new devices. Unfortunately, this version of u-boot is fairly out of date nowadays compared to mainline u-boot and has several problems. Support for plug computers (such as SheevaPlug and GuruPlug) have been integrated into the mainline u-boot (also known as DENX u-boot) in the meantime and Clint Adams has packaged it for Debian. I finally found the time to test Clint's u-boot binary on my devices and have updated the SheevaPlug installation guide accordingly. If you're have installed Debian to a SheevaPlug according to my instructions, I suggest you upgrade. If you boot from a MMC/SD card, you should be aware that the mmcinit command has been renamed to mmc init in order to be consistent with the naming of other commands. You'll therefore have to update your bootcmd_mmc variable in u-boot like this:

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?

Earlier this week, Conrad Sanderson issued a minor bug fix release 2.0.2 of his Armadillo library which provides templated C++ code for linear algebra. We wrapped that into a new RcppArmadillo release 0.2.26 and shipped it to CRAN. Due to it being summer and the otherwise tirelesss human operator behind the curtain being on a well-deserved vacation, it sat in the incoming queue til this morning---but is now on CRAN. Conrad did not rest either and just yesterday released version 2.1.91 as a first step towards a new 2.2.0 release sometime soon. And also yesterday, we wrapped that new version into RcppArmadillo release 0.2.27. With CRAN being back in full swing, we pushed it over there this morning and it already made its way into the repository. The NEWS entries summarising the changes---which are exclusively upstream---are below:

0.2.27  2011-07-22
    o   Upgraded to Armadillo release 2.1.91 "v2.2 beta 1"
          * faster multiplication of small matrices
          * faster trans()
          * faster handling of submatrices by norm()
          * added economical singular value decomposition: svd_thin()
          * added circ_toeplitz()
          * added .is_colvec() & .is_rowvec()
0.2.26  2011-07-17
    o   Upgraded to Armadillo release 2.0.2 
          * fix for handling of conjugate transpose by as_scalar()
          * fix for handling of aliasing by diagmat()
          * fix for handling of empty matrices by symmatu()/symmatl()

Courtesy of CRANberries, there are also diffstat reports for 0.2.27 relative to 0.2.26 and for 0.2.26 relative to 0.2.25. As always, more detailed information is on the RcppArmadillo page. Questions, comments etc should go to the rcpp-devel mailing list off the R-Forge page.

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

Finally. Since the release of squeeze, I've been fighting to get nbd to actually build on "most" architectures. There had been several issues, not the least of which was the fact that it had categorically refused to build on the kFreeBSD ports. I'd tried to debug that several times, but could not understand the issues. So then I set up a VirtualBox image with kFreeBSD to test, and when I finally got it to build there, I did an upload with the changes that I'd applied. Only to find it didn't build on the autobuilders. I briefly considered building it myself and uploading that, but then we have two kFreeBSD ports, so that wouldn't help. And, I guess, it would be severely frowned upon. Eventually I found the final issue: the test suite has recently acquired a set of "integrity" tests, that replay a recorded session and verify that the responses from the server are correct. This implementation in nbd-tester-client, however, has non-blocking writes to the server, and the server also does non-blocking writes. The "integrityhuge" test tries to write rather large blocks in one go; so basically, what happened not only on kfreebsd-* but also on some Linux architectures, like s390 and ia64, was that the buffers of both the server and the tester client were full, and they would deadlock when both wait for the other to read before they could continue writing. This is a bug, yes, but one that has existed for a very long time, and one which is unlikely to hit in actual usage the integrityhuge test fires off a multitude of very large reads and writes, without waiting; a situation that is highly unlikely to occur in real usage. So for now, I will disable the integrityhuge test, until such a time when I can implement async writes a feature that has been on my TODO list for a significant amount of time.

Hello, world! So, now this blog is being syndicated on Planet Debian, and I decided to write something to introduce myself. I was born in Salvador, Bahia, Brazil. I am married to Josy, a wonderful person; we do not have any kids yet, but anyone can notice we both discretely drooling when close to small children. I have a passion for building things, and making things work. Programming happens to be the better building toy that someone already invented. I became am official Debian Developer a little more than one week ago, but I have been working in the project for some time already. In the very beginning I was involved with the Perl group, but now almost all my work is in the Ruby team. I am a PhD student at Federal University of Bahia under supervision of professor Christina Chavez. My research involves three topics I am just fascinated about: Free ("and Open Source") Software, Software Design and Empirical Software Engineering. I am investigating whether it is possible to explain the variation in Structural Complexity by analyzing developer attributes. I want to answer questions such as "do developers with more experience in a project produce more complex code?", or "do developers that focus on a single part of the project produce more complex code than developers who work on the entire project?". As part of my PhD research I have been working on analizo, a multi-language source code analysis and visualization toolkit. I plan to write specifically about it in a later opportunity. My other job is running my own company, Colivre, together with several other great people. Colivre is a cooperative, which basically means that everyone who works there is also an owner of the company. We provide web solutions, in special social networking environments, social media websites and the like. Working on (and with) free software is our premise at Colivre, and most of our work involves either Noosfero or Foswiki. Right now I am taking some time off from Colivre to be able to concentrate on (and finish!) my PhD. Until late September I live at the beautiful Vancouver, BC, Canada, where I am currenly a visiting reasearcher at the Software Practices Lab at UBC under supervision of professor Gail Murphy. So that's it, I hope to post interesting stuff here and to get your feedback whenever you find it's worth. I also maintain a microblog at identi.ca, where you'll find shorter (and more frequent) updates.

Earlier this month, for the first time in 4 years I unchecked the box "I want to attend this conference" in Penta, the DebConf conference management system. Despite this, I *do* want to attend DebConf11 but unfortunately due to work obligations I'm unable to attend this year. Hope to see you in Nicaragua!

average sprint speed: 1 sprint/month I've proposed a DebConf11 BoF on Debian sprints and, more generally, on how we have been using Debian money in the past 1.3 years. As part of the BoF preparation, I've taken the time to review the last 16 months of sprints and check how the Debian Sprint Program which we've recently streamlined and "marketed" quite a bit is going. In particular, I've finally done the homework of preparing the big table of sprints and their costs, in order to evaluate how sustainable the sprint program is. Without further ado, here is the table:

Debian sprints held from April 2010 to June 2011

No	Sprint	When (month)	Where	Attendees	Debian cost (EUR)
1	groupware (report)	04/2010	de	4	240
2	FAI (report)	06/2010	de	7	570
	(DebConf10)	08/2010	us
3	ftpmaster (report)	09/2010	de	3	350
4	DSA (report)	09/2010	de	3	400
5	release team (report)	10/2010	fr	6	0
6	kernel team (report)	10/2010	fr	3	120
7	www team	12/2010	at	5	1430
8	debian med	01/2011	de	25	460
9	security team	01/2011	de	7	1000
10	emdebian	02/2011	uk	17	0
11	ftpmaster	03/2011	de	5	2000
12	groupware	04/2011	de	6	300
13	alioth	05/2011	uk	4	500
14	debian edu	06/2011	de	9	760
15	release team	06/2011	be	5	1640
	(DebConf11)	07/2010	ba
Total	15 sprints	16 months			9770

To better understand the table, several comments are in order:

• numbers are approximate in various ways. In particular, 2010 costs predate a protocol I've agreed upon with the Debian auditors to do proper accounting, hence it is possible that some costs are slightly overestimated
• costs are Debian's costs and do not include reimbursements for non-Debian people that might have attended the sprint. This also explains why some sprints have been at 0 cost: they have been entirely sponsored by other entities interested in supporting Debian, such as companies or institutions.
• where needed, costs have been normalized to Euro
• we have streamlined the sprint process around October 2010 (you can find the underlying rationales in an old RFC). Sprints happened before that data had a different way of being announced and of reporting back to the project.
• the above data are not detailed enough to properly estimate per-person costs, as we lack a breakdown of Debian vs non-Debian attendees
• no costs for DebConf-s are included, as they have their own budgets which aims to be amortized 0 cost in the long run

Please note that the purpose of the table is not to be precise and transparent about Debian finances and how we use them. That is a (very!) worthwhile goal and I do think Debian should do much better in informing its community about how donated money are used to further Debian goals. But that is a broader topic on which the auditors are working; it is not up to me to discuss it here. If you are interested in that topic though, you might want to follow tbm's BoF at DebConf11. The purpose of the table is rather to find out some general figures about Debian sprints held in the recent past:

• we have had a total of 15 sprints in 16 months (about 1 sprint/month)
• we have spent about 10'000 EUR for sprints, for an average per-sprint cost of about 650 EUR
• all sprints have been held in Europe
  (given DD geographical distribution, I find quite surprising that no group of US-based Debian hackers have asked for sprint sponsoring)
• about half of the sprints have been held in Germany
  (probably thanks to DD-density there and also to the welcoming attitude of friendly venues such as the Linux Hotel)
• the variance of per-person costs is high: there are very cheap sprints (e.g. when people travel within Europe by train and stay at friends') and quite expensive sprints (e.g. when one or more of the participant needs to be flown oversea which has happened only once, up to now)

I'm personally quite happy about those figures. Enabling volunteer developers to meet and hack together in person is possibly the most valuable way of using donated money. Having 1 sprint/month is not bad, but in a project the size of Debian is quite possibly a minimum. Doing more than that is highly desirable. It is also financially sustainable, especially if we will be able to show by actually having more sprints and being transparent about them that we can put into good use donated money. Another, more subtle, aspect of sustainability is that related to sprint management. Processing sprint requests and ensuring that transparency guidelines are actually followed by the organizers is still quite some work. I've been mostly doing that myself up to now, which is all fine and well, but does not necessarily scale. Other organizations (such as KDE e.V.) have realized that to the point of having hired people specifically to manage sprints in an otherwise volunteer community. In Debian we are quite keen of maintaining the project running on a volunteer basis. At the same time I feel we should have more room for scalability in the number of sprints we could run. So if you are looking for a management task to help Debian with, think about becoming, err, "sprint master", and contact me. If otherwise you want to focus on Debian hacking, what are you waiting for? Check the guidelines and propose your sprint! To know more about sprints, Debian money, and how you could help with all that, be sure not to miss the Sprint and money BoF.

There was an interesting issue in D-Bus, related to unicast vs broadcast signals, which led [edit: typo] to a small change in specs and which might be of some interest for D-Bus developers.

Unicast signals are not widely known and probably even less used, but they are possible.
They are useful, for instance, when you need to trigger an action from a single client, among your listeners.

Until some days ago, when a unicast signal was emitted, it was actually received by everyone listening to the signal's interface (unless a strict rule was added, unusual), waking up a number of processes which actually weren't interested in the signal.
Collateral effect, waking up cost apart: those processes might actually consider the signal as they were the actual recipient and take some action upon it. Bad.

Typical rule having this problem is "sender="org.foo,interface=org.bar".
Imagine several clients using this rule to listen to org.foo, but org.foo wanting to send a signal to :1.23 only.
Specifying destination=:1.23 for the signal object didn't really work since no dest=val was specified in the rule, allowing any destination actually matching it and all the listeners to be woken up anyway.

The problem with this situation was fixing the bad behaviour without filter out eavesdroppers, which actually wanted to receive the message even if not for them.

The solution is a sort of "eavesdrop opt-in", as Thiago proposed to add a keyword to DBusMatchRule, "eavesdrop=true false" which defaults to false and with which the listener declares that it really wants to eavesdrop, enabling it to receive messages (including signals) not meant for it (AKA eavesdropping).
Otherwise any message (again, including signals) with a specified destination won't match a filter with no or different destination. Also a rule with a specific destination won't match broadcast messages.


In other words, by default a match rule filter will match only broadcast messages or the ones specifically for you, unless you declare your very nature of eavesdropper by adding "eavesdrop=true" to your filter rule.

This is a behavioural change and consequently means a small amend to the D-Bus spec for 1.5.x.

It also means that if you maintain some code which acts as an eavesdropper, you should fix the code adding "eavesdrop=true" to your filter.
Note that it's only for 1.5.x branch; adding the "eavesdrop" keyword to a filter sent to a 1.4.x bus will fail as the keyword is not recognized.
An example on how to deal with this change keeping compatibility toward 1.4.x (stable branch) and 1.5.x (devel branch) at the same time is shown by this bustle fix. It checks for the feature presence and prepends the keyword if supported.

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