Yesterday, the right-wing PAN candidate for the presidency of Mexico, Felipe Calder n, made a declaration that shadows the current president, Vicente Fox (from his same political party) almost look like a genuine statesman. (some links, La Jornada, El Universal) - And that's no easy feat, given that Mr. Fox is -so far- the nation's most prolific president... When it comes to stupid sayings.
How come Calder n rose so quickly to become a statesman? Let me first go through a bit of history. Not much, promise. Well, I'll do my best.
Twelve years and one month ago, Mexicans woke up with the frightening news we had a violent guerrilla group in Chiapas, one of Mexico's richest states, but one with the highest percentages of poor people - and, not coincidentally, of indigenous population as well. This uprising was very soon known all over the world - And its leaders quickly learned how to ensure they would not be prosecuted and exterminated: Simultaneously with the fighting, they made as large a media coverage as they could, strongly supported in the Internet democratization of the information that had just begun. Thousands of people all over the world understood their ideas -at least what they said at that time- and spread the word. I had my first trip in Europe with my (now) wife in 1996, and we saw many grafittis stating Viva Chiapas, Viva EZLN... It was amazing.
EZLN was (is) specially hard for the government to kill. As they don't do military sabotages, terrorism or so on, it is very hard to justify military action. After 12 days of fighting, a truce was decreed. The truce was broken once, in the early years of the Zedillo government, but officially there is a cease-fire, observed by both sides. The Zapatistas have took the ideas and further promoted them, with action. My Chiapas-born friend Alex Ju rez often tells me about the tremendous cultural difference between the Zapatista territories and the paramilitary ones - In the Zapatista areas, you see indians reading books, working their land, organizing themselves in the Fair Government councils, and strongly opposing alcohol and drugs. Just the opposite from the other areas.
EZLN shifted their strategy some months ago, going beyond stating their wishes for a fair regime and waiting for the government to look at them. I still don't really understand where they are heading, but the Sixth Declaration of the Lacandon Rainforest turns them into a political movement, clearly separated from the existing regime. They do not seek to be elected, they oppose every party and candidate. They define themselves as an anticapitalist movement, located down and to the left - Lets see where this goes to.
Well, back on track... One of the president's most famous stupid quotes is that, during his campaign, he promised to solve the Chiapas conflict in fifteen minutes. Well, it's been either fifteen very long minutes, or he just hasn't had any time to devote to those dirty indians. Mexicans are very frustrated by the lack of importance this man gave to one of our country's longest and most desperate needs.
Of course, Felipe Calder n must do something in this regard. Fox's shadow is a big one, and this little man must try to escape from Fox's biggest mistakes. So he just came with a formula that I don't know why no statesman thought of before: Instead of negotiating, instead of working to solve a very difficult problem, he declared he will unilaterally declare peace with EZLN.
I wonder if this year's Nobel prize will go to such an abnegated, smart and selfless person. Man, we could take this same solution to Darfur, to Israel/Palestine, to Congo, to Chechnya... If rulers all over the world start declaring peace unilaterally, all of the world's problems will be solved! What comes next, he will declare (maybe as Salinas did) that we are a first world country? Poor people are only sad reflections in the sand but don't exist in his reality?
Please, Mexicans: The man is clearly schizoid. Are you happy with Foxilandia? It seems that alternate realities are part of the PAN's action program. If you are not satisfied with Fox's results (who is?), don't vote for this guy. We will all regret it.

I wonder how often things like this (“Dear Sir, calling StarForce ‘Anti-copying malware’ is a good enough cause to press charges and that is what our corporate lawyer is busy doing right now”) actually have their desired effect. I suppose it might work in cases where the recipient is actually dumber than the writer. On the plus side, that sort of letter could certainly create declaratory judgment jurisdiction; the recipient could turn around and sue the sender for a declaration that they have done nothing unlawful. I also wonder whether companies like StarForce actually have a “corporate lawyer,” and if that person is aware of these emails. I sure hope not. Update: Apparently this story has been slashdotted. I try not to post about things that also appear on slashdot, on the theory that most people will have seen the story somewhere else at that point, but this entry went up before the slashdot article. A commenter makes a good point, though, that Cory Doctorow (the recipient of the abovementioned threat) is Canadian and lives in London—something the writer of the threat seems to have no clue about.

Prompted by #350357, I did something I've planned to do a long time already, but had so, so far, failed to do: I wrote an nbd-tester-client. All it does currently is a sequential read of the entire block device, but it's written in such a manner that it should be easy to add additional tests—say, random reads, or write-read-verify cycles. Not that I actually needed such an application to identify and fix the bug (which boils down to a forgotten return 0 somewhere halfway the code; upload on the way), but it's a good thing none the less. It even pointed out one problem with nbd-server: that it will do write() calls without select, thus allowing for a deadlock if both the client and the server have a full write queue. I'll fix that for NBD 2.9 (might be too intrusive for 2.8, and I'm not sure whether the kernel actually writes without waiting for its write queue to be emptied). The code is in CVS HEAD, if you want it.

Many have tried to solve spam problem, even Micrsoft (with a quite strange solution ;-), but except personal solutions like well working and well-kept spam filters, no well-working general technical solution has been found yet. Although I really would like to see a technical solution and often think about this problem, I currently believe that this primarily is a social problem which cannot be solved solely with technic. UserFriendly’s Erwin seems to see it the same way and proposed today a quite drastical solution. There are good ideas out there (e.g. SPF, RBL, Greylisting and Teergrubing), but all seem to have their problems, too. Especially RBL often have administrative problems, i.e. if an entry is justified or not. Greylisting simply can be bypassed by being SMTP conform and trying again, so it’s usefulness will decrease permanently. And against Lutz Donnerhacke’s teergrubing, spammers seem to have found workarounds quite quickly. Haven’t heard much about it in the last years. (I just can’t remember what the drawback of SPF was.) For myself I’ve solved the spam problem with a learning SpamAssassin and sorting mail by spam-level into several mailboxes. The higher the spam-level of such an inbox, the more seldom I look into it. Works fine. For me. No general solution though, since the SpamAssassin needs to be fed with fresh spam regularly.

According to the graphs, we are now officially no longer the worst architecture! Whee. Not that I feel happy for the hppa folks, but we've been in this position for way too long already, now. It's about time we got through this. Therefore: Whee! Of course, the fact that we're not the last in the list now does not mean that our problems are over. There's #345574 to care about (and, hence, #340563; and there are a bit more issues like that one that will need a bit of love to be resolved. But we're going in the good direction again, which is great. In somewhat related news, some of our ColdFire eval boards have arrived at their destinations already. Unfortunately, mine has not arrived yet; but I presume it will rather soonishly. I should probably finish patching binutils to handle those FPU instructions as well, so that I can start testing and comparing...

In a little while I’ll be packing my things: clothes (with a few formal attires), a couple of (C/data structures) books, some snacks (Nerds!) and spare change (no bills). I’ve yet to see all of them fit in my backpack, so I’ll probably bring a couple of bags. Tomorrow, I will be bound for Manila yet again, much earlier than usual, for the AsiaBusinessTour on Thursday. And on the 16th, there will be the Bicol Open Source Forum in Legazpi City. Joseph Davidton Cadag invited me to be a speaker; I’ve yet to accept, but I’m leaning to it, especially since this would be a great opportunity to speak more about FOSS to my fellow Bikolanos. Also, its a nice time to meet up with Irvin Piraman who will be giving some Ubuntu CDs in the Forum too. I just hope I can finish my (re)packaging of ecb which I ITA‘d since last August. There is a package of the new upstream version already, but there seems to be a lack of Debian sponsors who can look into Emacs-related packages. sigh

This took a bit too much work to figure out so here it is. If you're like me and had to buy a usb sound card (nearly as sensible a name as a cable modem) since the laptop's onboard headphone jack broke, and would like to have that card used by default when it's plugged in, but otherwise have builtin card be used, create an /etc/udev/rules.d/00_local.rules containing:

# Default to using additional (USB) sound cards when they are available.
KERNEL=="pcmC[D0-9cp]*", ACTION=="add", PROGRAM="/bin/sh -c 'K=%k; K=$$ K#pcmC ; K=$$ K%%D* ; echo defaults.ctl.card $$K > /etc/asound.conf; echo defaults.pcm.card $$K >>/etc/asound.conf'"
KERNEL=="pcmC[D0-9cp]*", ACTION=="remove", PROGRAM="/bin/sh -c 'echo defaults.ctl.card 0 > /etc/asound.conf; echo defaults.pcm.card 0 >>/etc/asound.conf'"

Only programs started after the sound card is plugged in will use it of course, and this might not work if you have it plugged in while booting.

Where I'm working, they wanted to try "netoffice", a PHP collaboration/time tracking/productivity thing. I downloaded the "dwins" version of it, and ran the install script after reading the instructions. Being a bit late, I hit the return key one too many times, and noticed some funny error messages about problems deleting files in /dev. Oh shit... Turns out the script has the following line:

rm -rf $ INSTALL_DIR /*

Simply brilliant. Thanks a lot, guys... So at this point I'm sitting there with two shells opened via ssh, no /bin/, no /etc/ and nothing much in /dev. For reasons I won't discuss here we don't have backups - suffice it to say that it wasn't my decision. Not good. ssh didn't work any more, either in or out, because it needs files in /etc/ and /dev, and so I couldn't just copy new stuff in. Luckily, I had a fully stocked /usr/bin, and I did the first thing that came to my head: a small server in Tcl that copied its input into the specified file. Using that and netcat on the other side to send the files, I recreated enough of /bin to get MAKEDEV working in /dev. Phew... a little bit better, but /etc/ was still gone. I brought in a few more bits and pieces like /etc/passwd and /etc/group using my Tcl server, which was enough to get scp working from the machine. At that point, I brought in the rest of /etc. I was starting to think about going home when I ran the fateful script, so at this point it was pretty late, I was starving, so the rest will have to wait for tomorrow. The biggest problem, I think, is how to restore the files in /etc at least to the pristine installed state required by the packages that own them? The other problem is that the password file uid's are now out of sync with the file system, which is causing problems here and there. Unless I think of a brilliant way to fix those two issues, I'll probably consider myself satisfied that I got things running to a point where I can get the important data off the system, set up some temporary services on other machines, and reinstall the whole thing. This is all on Ubuntu systems, by the way.

Insipired by Daniel Burrows’ tests, I decided to do mine. The object is to come up with a Haskell program that performs the job of wc -l as efficiently as possible. My test material is a randomly generated file with all lines less than 80 characters long. Summary: my final idiomatic version is twice as slow as wc -l, and my final nonidiomatic version is as fast as wc -l, or at least within the margin of error. First, the baseline:

$ time wc -l testfile
7798137 testfile
real    0m12.127s
user    0m0.765s
sys     0m0.399s

Then the most idiomatic program. Honestly, I expect it to suck performance-wise:

main = getContents >>= print . length . lines

And it does:

$ time ./wcl1.hs < testfile
7798137
real    1m14.993s
user    0m54.182s
sys     0m0.573s

But only by a factor of six. My first hypothesis is that garbage collection is the culprit. And, indeed:

$ time ./wcl1.hs +RTS -sstderr -RTS < testfile
./wcl1.hs +RTS -sstderr
7798137
25,236,174,340 bytes allocated in the heap
5,070,193,924 bytes copied during GC
117,484 bytes maximum residency (3750 sample(s))
96274 collections in generation 0 ( 26.36s)
3750 collections in generation 1 (  0.74s)
2 Mb total memory in use
INIT  time    0.00s  (  0.00s elapsed)
MUT   time   27.17s  ( 42.72s elapsed)
GC    time   27.10s  ( 33.72s elapsed)
EXIT  time    0.00s  (  0.00s elapsed)
Total time   54.27s  ( 76.44s elapsed)
%GC time      49.9%  (44.1% elapsed)
Alloc rate    928,824,966 bytes per MUT second
Productivity  50.1% of total user, 35.5% of total elapsed
real    1m16.616s
user    0m54.278s
sys     0m0.700s

As you can see, GC takes half of the processing time. Unfortunately, minimizing GC time does not have as big an effect as I hoped:

$ time ./wcl1.hs +RTS -H100M  -RTS  < testfile
7798137
real    1m1.354s
user    0m44.371s
sys     0m1.171s

Here, I’m effectively telling it to use a 100-megabyte heap. A separate GC profiling run tells me that GC time has dropped from 50 % to 1 %. The memory problem seems to be a red herring. What we’re doing here is creating four separately allocated memory cells for each character in the input. Of course, the cells are generated lazily, that is, a cell pair is allocated when the lines function demands another character; it then creates another cell pair to denote the same character in a list of lines. As soon as each line has been counted, the four cells become garbage. This sounds like a lot of work! But apparently it isn’t; I tried a few variations that did away with the stream of input altogether, not much unlike what Daniel did in his tests. Surprisingly, the performance worsened a lot. The lesson: functional programming language implementations, unlike typical imperative ones, are built on the assumption that you’ll be doing a lot of allocation. What I suspect is taking a lot of the time is arithmetic. Haskell’s Int is boxed, and lazy by default, adding a lot of overhead. I hand-fused length and line, yielding a tail-recursive countLines function, and I added the command-line switch -funbox-strict-fields, which enables a few significant optimizations of the laziness of Int. The results were nice:

ajk@kukkamaljakko:~/scratch$ cat wcl4.hs
module Main (main) where
main :: IO ()
main = getContents >>= print . countLines 0
countLines :: Int -> String -> Int
countLines n ('n':r) = countLines (n + 1) r
countLines n (_:r) = countLines n r
countLines n [] = n
ajk@kukkamaljakko:~/scratch$ ghc -O -Wall -funbox-strict-fields --make wcl4.hs -o wcl4
Chasing modules from: wcl4.hs
Compiling Main             ( wcl4.hs, wcl4.o )
Linking ...
ajk@kukkamaljakko:~/scratch$ time ./wcl4 < testfile
7798137
real    0m37.961s
user    0m29.853s
sys     0m0.495s
ajk@kukkamaljakko:~/scratch$ time ./wcl4 +RTS -H100M < testfile
7798137
real    0m25.153s
user    0m13.497s
sys     0m0.803s
ajk@kukkamaljakko:~/scratch$

With a large heap, the program is only twice as slow as the baseline. This is pretty good, considering that the code is still idiomatically functional. The following rather ugly, imperative program does away with the lazy stream and carefully avoids any laziness without doing any too dirty tricks:

ajk@kukkamaljakko:~/scratch$ cat wcl7.hs
module Main (main) where
import Data.Word
import Data.Array.IO
import IO (stdin)
count :: Int -> (Int, Int) -> IOUArray Int Word8 -> IO Int
count 0 _ _   False = undefined -- force ac evaluation
count ac (l,u) _   l > u = return ac
count ac (l,u) ar
    = do a < - readArray ar l
         let ac' = case a of 10 -> ac + 1
                             _  -> ac
         count ac’ (l+1, u) ar
maxn :: Int
maxn = 4096
main :: IO ()
main = do
  arr < - newArray (0,maxn) 0
  let loop :: Int -> IO Int
      loop acc = do n < - hGetArray stdin arr maxn
                    if n == 0
                       then return acc
                       else do acc' <- count acc (0,n) arr
                               loop acc'
  res <- loop 0
  print res
ajk@kukkamaljakko:~/scratch$ ghc -O  -Wall -funbox-strict-fields --make wcl7.hs -o wcl7
Chasing modules from: wcl7.hs
Compiling Main             ( wcl7.hs, wcl7.o )
Linking ...
ajk@kukkamaljakko:~/scratch$ time ./wcl7 < testfile
7798137
real    0m13.431s
user    0m10.342s
sys     0m0.467s

Of course, this program is not Haskell 98, but the nonstandard things it uses are fairly common. As can be seen, this version’s performance is, considering the margin of error, equal to the baseline. The compiler used in this test is The Glorious Glasgow Haskell Compilation System, version 6.4.1, as packaged in Debian sid.

wouter@western:~$ gpg --no-default-keyring --keyring .gnupg/importring.gpg --list-keys   grep '^pub'   wc -l
39

Which is not to say that 39 people will be attending; only that there are 39 keys, since some people have sent in more than one key. If you want to participate, all you have to do is to go read the instructions and send in your key.

My laptop is now gone for repair of the backlight. While I have my HD at home (and an external casing for it), I don't have my usual work environment... So I will probably not do any Debian work until I have my laptop back; if you want to NMU (or adopt minit, where I did the orphan upload just yesterday), just send me an email. I should still be reading my email frequently. I hope with the repaired backlight the laptop will continue running until I've decided on a model to buy instead. Current favourites: IBM Thinkpad T43p (which supposedly is almost the same as my current laptop, and especially also has hopefully the same 1600x1200 15" display...), Samsung X20 or X50, maybe an Apple, or (which is really pretty, but seems overpriced) Samsung Q30plus. Ranked in order of importance to me: Display quality (shouldn't reflect too much, should be very fine) then weight. Everything else is rather uninteresting...

After experimenting a bit with Haskell and using it for some toy projects, I decided to see if there was any chance it could be used for a non-toy task; i.e., one where it might one day be necessary to actually have fast code. As a proxy for this, I decided to try a very simple task: counting the number of lines in a file. As input, I generated a file with a million lines of random data and an average of 40 bytes per line; all the Haskell programs were compiled with the current GHC in Debian unstable and with optimizations enabled.

The baseline is, of course, our friend "wc":

real    0m0.084s
user    0m0.043s
sys     0m0.040s

(this and all other timing data was taken after "cat /tmp/testwc.txt > /dev/null" to ensure that the file was cached) Now, it's probably too much to hope that a Haskell program will run as fast as a C program does, since the C program can run in a tight loop. But it seems reasonable that it should be possible for Haskell to be competitive with the trivial Python implementation of this program -- after all, Python is interpreted and Haskell is compiled.

import sys
n = 0
for line in sys.stdin:
   n += 1
print n

Running this simple Python program under "time" produces the following statistics, a bit less than 10 times slower than the C version:

real    0m0.698s
user    0m0.643s
sys     0m0.050s

The trivial Haskell program to count the lines of its input is:

main = do c <- getContents ; print $ length $ lines c

Note that this is basically identical to the Python program, but expressed in a functional style. Pretty, but how does it stack up?

real    0m6.744s
user    0m6.426s
sys     0m0.213s

OW! Ten times slower than the Python code, and a good 80 times faster than "wc"! The gap can be lowered to "only" 50 times with the following program --

do c <- getContents; print $ length $ elemIndices '\n' c

-- but surely it's possible to do better. I'd expect that the expense here is in the use of lazy streams for IO; eliminating them gives us the following code:

wc :: Handle -> IO Int
wc h = do a <- mallocArray bufSize :: IO (Ptr Word8)
          loop a 0
    where loop a n = do amt  <- hGetBuf h a bufSize
                        elts <- peekArray amt  a
                        (if amt == 0
                         then return n
                         else loop a $! n + nlCount elts)

At this point, we're basically using Haskell as a (bad) imperative language. This function allocates a buffer, repeatedly reads into it, and counts the number of newlines in the buffer (I dropped some auxillary code to keep the post short). The $! is important; without it, even though this routine is tail-recursive, Haskell will still allocate an unbounded amount of memory to store the return value. (because, of course, it's terribly important to remember that you're actually returning "1+2+3", not "6")

So, how does this unreadable, hand-optimized version of the code perform?

real    0m1.980s
user    0m1.757s
sys     0m0.094s

That's right -- I've eliminated most uses of higher-level functional techniques, and the Haskell version is still two times slower than an ultra-high-level interpreted language, while also being uglier and harder to read! Ouch. It appears the old performance albatross of functional languages is not quite dead yet.

The incumbent, Tarja Halonen, carried the runoff, taking 51.8 % of the vote. The runner-up, former minister of finance Sauli Niinist was left with 48.2 % of the vote. The margin was roughly 113,000 votes. The next Late Night with Conan O’Brien will be interesting to watch.

At work we have recently started testing a web-based trading platform for swaps. After pointing the browser to the respective URL you enter the relevant data (effective date, notional, currency, &c;) and klick on "request for quote". The system will take a little time to process the data and price the swap; and you have about 7 seconds to accept (and immediately enter a contract) or reject the quote by klicking on the respective button on the popup.

I have often used his platform to get tradeable price-*indications* until recently when I had the chance to take a look at the inner workings. We had some technical problem with the systems and contacted the support. They passed us on to the trader, a person who has to _manually_ release any quote before it is sent out. D'oh!

Kathy and I went out for dinner last night at Tootsies with Becca, Dave, Eli, J, Kaz and Will. It was a good night (even if the girls beat us at Cranium), but I found myself having to stop talking about weddings - I could see J and Kaz starting to glaze over early in the evening. This a frightening event. Is this how people become baby bores? Anyway. Kathy and I managed to look at a couple of potential venues yesterday and have another one arranged for next Sunday, and a few more to ring this week to hopefully see next weekend. It's all still very scary.

This is a blog entry I wanted to write for about six weeks now, but I was busy with other stuff. In December 2005 I got curious why 2.4.32 wasn't packaged for Debian and investigated the situation a bit.

There are several reasons why 2.4 is still interesting:

- Kernel 2.6 is still a moving target...

- Some hardware is only supported with 2.4, for example older laptops which need APM and don't work with ACPI. Also some non-i386 machines.

- According to popcon, 6-7% of the i386 users have a kernel-2.4 image installed.

Unfortunatly, nobody from the kernel team is really interested in working on 2.4 anymore. They do security fixes for the 2.4 kernels in woody and sarge, for which I'm very thankful, but that's about it.

Even though 2.4 is moving very slowly nowadays (mostly security updates, very seldom new drivers are including), this is more work than needed, because every fix needs to be backported to 2.4.27 (and 2.4.18 for woody).

Of course there are some issues which need to be taken into consideration when thinking about whether it's worthwhile to have 2.4.3x in Etch:

- it needs gcc-3.3 to compile, gcc-4.0 won't work. Period. So gcc-3.4 also needs to supported during etch's lifetime - which will be something like 2009 when etch+1 will become oldstable (by current release cycles)...

- it's not sensible to have powerpc and amd64 flavors, and probably others. So this kernel package will not be arch any. (Which is not really a problem, but unusual.)

- Both kernel 2.4 and 2.6 contain non-free firmware and drivers. I seriously doubt people want to deal with this issue and solve it for 2.4. For 2.6 it will be done, but for 2.4 ? As I see it, this is the biggest showstopper for 2.4 in etch, I would be happy to be proven wrong. As a starting point, you can look at this investigation by Bill Allombert about the the situation in 2.4.25.

Removing those files would be an option, but maybe we can also "borrow a better solution" from 2.6...?!

- if 2.4.32 or .33 shall be used in d-i/g-i, work on this integration needs to be started real soon now.

I have done some work on creating a linux-2.4.32 package which is based on the new kernel packaging. I got busy with videos for debconf-es2, so I didn't finish and commit this.

Horms made a presentation about the kernel packaging in debian for LCA and gave two options: a.) support and backport fixes for 2.4.27 or b.) go with 2.4.32. Somehow he did not consider the option of dropping 2.4 even if he calls it legacy ;-)

Besides technical reasons (security fixes handled by upstream, some driver updates and very few new ones) I think we should not forget that most people have no idea that 2.4.27 in debian is far closer to 2.4.32 than to .27, and therefore will think debian ships an outdated 2.4 kernel. So I think we should simply go for 2.4.3x, if it is sensible to support 2.4 in etch at all.

It "just" needs to be done, and I volunteer to do it (with the help of the kernel team, the porters and anybody else who wants to join), if this work will not be in vain.

Please send comments to the debian-kernel-mailinglist, where I posted this blog entry before. Thanks.

Call For Papers for the 4th. World Forum on Free Knowledge is now released in english (non-official translation, sorry for mine) and spanish. The WFFK is a Community-organized Forum, made possible by the sponsorship of Government Enterprises and Private Enterprises, as well as Volunteers and Donations. The first was made in Caracas, on November 2004, in the installations of the Universidad Bolivariana de Venezuela, with the sponsorship of the Venezuelan Oil Company, PDVSA. The second WFFK was made in Thiruvananthapuram, in Kerala-India, under the name Free Software, Free Society in May 2005, and the third WFFK was made in Maracaibo, Venezuela, with the support of several Institutions, including PDVSA, CONATEL and serveral others. Impressed by the success of the 3rd. WFFK, a group of people is organizing the fourth, which will take place in Puerto La Cruz, Venezuela, in October 2006. This is the first ocassion a Call For Papers is being done, because the Forum will have a Congress inside it, as well as selected articles. In the past, we only had selected articles and invited speakers on a certain basis. This time, a Call For Papers will also be done, so we can invite nice speakers to come and share with the attendance. Last time in Maracaibo we had David Moreno Garza with us, as well as several Debian Maintainers and Co-Maintainers with us, from Venezuela and Colombia: Ernesto Hern ndez-Novich, Polkan Garc a, Ernesto Crespo, V ctor P rez, Ana Delgado, Gerardo Curiel, Manuel Garc a, V ctor P rez and myself (am I missing someone?). So this was quite a MiniDebConf! Let’s make the 4th. a complete one