Since there aren't only serious grave and critical bugs we have to fix for the release, the RM Team spontaneously decided to make a front attack to the g++-4.3 FTBFSes. All in all we did probably more than 110 to 120 NMU to fix g++-4.3 FTBFS bugs. Our champion is definitely Marc Brockschmidt who uploaded 50 packages. I NMUed 22, and also did one QA upload. Add to that 5 sponsored NMUs for Cyril Brulebois, and one for Arthur Loiret who happens to be my NM, and fixed one of those bugs for his T&S. There are still twice as many to fix, those are really easy bugs to deal with, just give it a try ! I'd like to thank Cyril Brulebois for his awesome work on the g++-4.3 release goal. A shame that he's still elmo-ed, as he wrote more than 150 patches, and could have uploaded them himself if not still waiting for his account. Shame on us.

I've been critical of the almost abusive terms in the user agreements of most user-harvesting-based services (sometimes called Web 2.0) for a while now. There are quite a few services that I simply won't use because their owners want me, all my web "content" (whether explicitly posted to their site or not), my first born child, or similar. There are even more sites where I'm careful not to put much beyond the bare minimum and try to make sure that I keep backups of nearly all of it. Usually that means keeping a copy of the input, as getting my data back out of most sites is a pig. So far, when I've criticised aggressive user agreements, I've felt like a lone voice in the wilderness. It's been heartening to spot two user-harvesting services geting some abuse over the last week or two. First, the Swift online community platform for conferences has been attacked by both David Lee King and librarian.net for its over-zealous user agreement demands. Particularly "nice" is the feature where one rule of Swift club is that you don't talk about Swift club (see last paragraph of David Lee King's post). Swift's owners have responded. I'll watch and see whether it improves enough to get a follow-up post from either blog. Secondly, the Phorm advertising system has faced hard questions from both Open Rights Group and Sir Tim Berners-Lee over its mysterious user tracking. Phorm hasn't yet replied properly about their potential to harvest user-generated content (web histories and so on) without consent, as far as I can see. If you know anyone on Talk Talk, BT or Virgin, tell them to start planning the exit route. If you'd like to refer them to our agency for The Phone Coop that would be great. I suspect the owners of The Phone Coop would get quite vocal if it ever tried to track users like this and a comment on the ORG post suggests someone else has asked Are we seeing the start of a user-harvesting backlash?

emacs-goodies-el

• Test debian-mr-copyright-mode and report suggestions to Vincent Fourmond: done. Next todo: include it, probably in dpkg-dev-el.

pkg-games

• Prepare latest Bos Wars upstream, ask for a sponsor: done. Bos Wars is a futuristic real time strategy game. It used to have copyright and license troubles, but upstreams kindly addressed that.

pkg-phototools

• Finish libpuzzle packaging: done. Libpuzzle is a library to compare images, which also comes with a simple puzzle-diff binary scoring image similarity. Next todo: Wait for a review of the PHP bindings by Emmanuel Bouthenot (who already kindly rewrote upstream's manpages in a proper manner), then ask for a sponsor. Another todo: Check upstream status of CLSimilarImages, see whether it might be worth packaging it, and point the upstream authors to each others.
• Check LuxRender's upstream status: done. LuxRender is a rendering system for physically correct, unbiased image synthesis. The packaging has been ready for weeks, waiting for a released tarball (rather than working on a CVS snapshot). RC5 is on its way.

Misc.

• Suggest an option for fork()-based rendering to Blender upstreams: done. Blender is a free open source 3D content creation suite, including modelling and animating tools, as well as an internal renderer. For some reasons, one might want to use a fork()-based solution rather than one (only) based on threads (limited to 8 by default through a #define), when it comes to using a cluster. Next todo: try and hack it myself.
• Check appletouch's bug #465278 with latest kernel: done. appletouch is the mouse driver on iBook G4 machines, and tends to break badly when resuming from suspend2ram: it's unusuable until the next reboot. Not any better with 2.6.25-rc5-powerpc. Next todo: Report it upstream, following Maximilian's request.
• Check the status of a nasty xfwm4 bug: done. When the switch back to previous workspace option is enabled, and one keeps the key for switching to another workspace pressed too long, xfwm4 starts flickering between both workspaces, endlessly. Restarting X helps. That was previously reported to happen only on low machines, but it's easy to trigger this bug by lowering the delay before character repetition in the keyboard settings.

Of course, that's just an excerpt of the actual todo-list

Somebody called Pigeon has posted a truly outstanding contribution to the debate on what kind of content is adequate for packaging as a Debian package to the debian-curiosa mailing list (this time the debate apparently is if Dopewars is ok, in other instances, the debate was about other games or the text of the Bible.)

I am a huge political junkie and I have been closely following Europe and US politics for more than 5 years. After this time and several disappointments, I have to admit that Obama is the first truly inspirational politician I have seen (listen to the Yes We Can song based on his New Hampshire speech). Some of his detractors dismiss his speeches as lousy, empty or vague, but you just have to listen to a couple of them to see that he is genuinely smart (such as the one about faith and atheism or the interview at Google). He doesn’t only take the right stance on most issues that I care about (Iraq, foreign policy, ethics, net neutrality, …), but he does it in a sincere way. Obama just gets it. I have got this impression from watching several of his speeches and interviews, but Marc Andreessen had the chance to spend an hour and a half with him a year ago and got the very same feeling. The main argument against Barack Obama nowadays is his alleged lack of experience. “Watch how I run my campaign”, Barack said to Marc when inquired about that. It’s obvious that running a primary campaign isn’t the same as being POTUS, but being the president’s wife isn’t exactly the same either. So if we compare the Obama and Hillary campaigns we can easily see Hillary’s experience as an “old school” politician. She overstates, lies, accepts loads of money from lobbies (because “they represent people too”, haha), resorts to fear-mongering (”Obama is not a muslim, …, as far as I know”, 3 a.m. ad), sides with McCain if needed to get some extra votes, surrounds herself with nitwits, … . To summarize, she uses every dirty trick she has learned in these years in Washington, and that’s exactly what I am so sick of right now. On the other hand, Obama’s campaign hasn’t just been one of the best organized and executed campaigns I have ever seen, but also the cleanest one. He has managed to overcome double-digit Hillary leads in most states without having to resort to any of these experienced politician’s dirty tricks. If I have to trust one of both to run a country, the decision is obvious. If I didn’t manage to convince you, I hope Lawrence Lessig and xkcd’s Randall Munroe do. Obama is leading and almost there, he just needs the final push. Please, do the right thing.

I just installed a new kernel on my thinkpad. The migration was done from a 2.6.23 kernel and brings a new 80211g driver: iwl3945. This new driver is fully included in the kernel and only need an additional firmware, which can be found in firmware-iwlwifi Debian package. It works pretty well, seems to connect faster, but the blinking WIFI antenna on my laptop doesn't work anymore. It replaces ipw3945 with a daemon in user space. The installation was not straightforward, since ipw3945 and udev persistent net rules prevent it. The solution is to remove lines concerning the net interface using ipw3945 (the line "# PCI device 0x8086:0x4227 (ipw3945)" and the line after) in the file /etc/udev/rules.d/z25_persistent-net.rules. After this, you must do:

modprobe -r iwl3945
modprobe iwl3945

The file /etc/udev/rules.d/z25_persistent-net.rules now contains a line for the iwl3945 driver. Installing the driver for etch requires to update the package wireless-tools using its backport to etch and downloading/installing the package firmware-iwlwifi from unstable.

It's funny sitting down to finally write something on LJ and not being sure what to write. I can tell stories of Angie's mom coming to support her and giving me time with my wife. I could rant about students putting in some of their first IVs (or not, actually since after the third try I got bitchy and she ran away. Literally. Oops.) I could talk about recovery, the joy that is delaudid, the devil that Valium turned out to be, or wonderful nurses who were so helpful and encouraging (and the ones who bent the rules and let me see Leif on his first year birthday) or the ones who lied, failed to check in on me and left me in distress for several hours.

On the whole, the people and experience were very good. From almost immediately after I woke up, things have been better. I hadn't realized there was pain associated with all this until it was gone post-surgery. The numbness is still there, but better that it was before by a long shot.

I do want to make sure I say thanks for all the energy, thoughts, and prayers. I felt good on Monday going in with the power and energy of literally hundreds behind me. Religiously, I have a complex relationship with this stuff, but I believe that at moments where a yes or a no gets to be decided by luck or external unknown forces, this can really help the answer be a yes. And I think we'd be surprised at how much of life fits into that category.

There are lots of emails and posts I haven't replied to yet. My lifting restrictions are such that I can't pick up my laptop. So if you see emails or LJ posts from me, its been typed on the iPhone or the Blackberry. Same with the instant messenger. I have my status set to "do not disturb" when I'm around so that I don't exceed my ability to type by getting into talking to too many people at once. My lifting restrictions continue for the next 6 weeks.

That said, I do enjoy chatting and writing. It just takes a while and is quite tiring.

I haven't figured out how to upload pictures to flickr such that the pictures are public, but that are not forced onto people who just wanted to see pictures of Leif. :)

Tired now. If there is any particular part of the surgery/recovery you want details on, let me know and i'll write about it.

*hugs and love*
Jeff

PGAPack is rather nice and fairly small library for 'parallel' optimisation via generic algorithms using the MPI message passing protocol. PGAPack 1.0 was written by David Levine while doing graduate work during the mid-1990s at Argonne Labs / University of Chicago. PGAPack has also been in or around Debian for a rather long time, but it suffered from benign neglect in the last few years. Some of this came to the fore in this bugreport which lead to my offer to the then-maintainer Andreas to help on the relicencing request. After all, Argonne Labs is just a few miles from where I live, and I had already spent a little bit of time polishing and upgrading the package for my own exploratory use. So I called Rusty Lust, head of the Mathematics and Computer Science section at Argonne to try to sort this out. He was sympathetic and put me in email contact with David Levine. As we are all somewhat busy, this dragged on for a little longer than we thought --- but as of today, about and a half years later, we have a new and shiny PGAPack 1.1 release, or around twelve years after the initial 1.0 version came out. I have done a fair amount of polishing: there are now two library packages for serial use (i.e. for debugging) as well as parallel use via MPI. We use Open MPI where available and LAM where not. All open Debian bugs have been addressed. One minor issue in the postscript documentation remains as David can no longer locate his LaTeX sources; I may just have to extract the text and re-latex this from scratch to update it. One day. Anyway, for full reference, the changelog entry is below. The package is currently in the NEW queue (as the new sub-package require manual inspection and approval) but should hit mirrors in a couple of days. My thanks to the two previous Debian maintainers; to Rusty Lusk for helping with the from the end MSC department at Argonne Labs and for suggesting the rather liberal and easy MPICH2 license (and he happens to be one of the MPICH2 authors); and of course to David Levine for writing PGAPack in the first place, for agreeing to relicense it and giving valuable feedback on my repackaging of what is now version 1.1 on the MCS ftp server at Argonne --- this library has held up really well over the years; let's hope it will find more good use going forward.

pgapack (1.1-1) unstable; urgency=low
  * Really good news:  The MCS divsion of Argonne National Laboratories has
    agreed to relicense pgapack using the MPICH2 license. So pgapack
    is now Free Software and can move into Debian's main archive!
  
    Our thanks go to David Levine and Rusty Lusk to make this possible.
  
  * New maintainer, following Andreas' offer dated 2006-10-04 in #379388
  * debian/control: Change section to math		(Closes: #379388)
  
  * Added new brinary packages libpgapack-mpi1 and libpgapack-serial1
  * The MPI package is configured using Open MPI where available and LAM
    where not. 
  * debian/control: Changed Build-Depends: to use OpenMPI where available, 
    and LAM otherwise.
 
  * Finally acknowledges old NMUs 		(Closes: #379168,#359549)
  * source/integer.c: Apply patch for one-off error 	(Closes: #333381)
  * source/report.c:  Do not unconditionally print at generation 1
  
  * debian/rules: Remove a bashism 			(Closes: #379168)
  * debian/rules: Install examples directly 		(Closes: #134331)
  * debian/control: libpgapack-lam1 Depends on lam4 	(Closes: #60376)
  * debian/rules: Rewritten using debhelper
  * debian/control: Added Build-Depends: section for debhelper
  * No longer install mpi.h in /usr/include		(Closes: #404027)
    
  * debian/control: Updated Standards-Version: to current version
  * man/man1/PGAGetCharacterAllele.1: fix whatis entry 		(lintian)
  
 -- Dirk Eddelbuettel   Mon, 10 Mar 2008 18:03:34 -0500

I previously wrote about my visits to Turkey to develop our export market in the Middle-East and how I ended up representing the whole Estonian business world in bilateral negotiations with Turkey. I'm going there again for two weeks, this time accompanied by a whole business delegation headed by Estonian prime minister Andrus Ansip. Asides from various official events organized by our Turkish hosts to present Turkey to their Estonian guests, the crux of the visit is a conference hosted by DEIK and the Estonian embassy, on Tuesday, March 18th. The goal of this conference is to present Estonia's extremely advanced use of ICT technology in E-Business and E-Governance. Speakers from several private and public sector organizations will explain how they benefited from Estonia's hyper-connected lifestyle and, most of all, how this has made every Estonian's life more pleasant, because it offers a convenient way of performing a broad range of online transactions not just with businesses, but also with governmental organizations. Yours truly will speak about the advantages Estonia offers to investors and technology freaks alike, from the perspective of an industry insider who, given the opportunity of choosing his first pick for a liberal high-tech nation, dropped the Nokiaesque lands of Suomi to go Eesti. The morning of conference will end with a business lunch where interested Turks can network with their Estonian counterparts and create lucrative bilateral opportunities. Space in the TOBB Plaza auditorium is limited so those interested in attending should promptly contact DEIK to get their name added to the guest list. Turks interested in learning more about Estonia in their own language should visit estonya.net.

While rebuilding packages FTBFS'ing with gcc-4.3, I stumbled upon various quality/sanity levels for code & build systems: from very clean to not-so-nice, dirty, and even scary. Fortunately, upstreams are sometimes funny and want to make us smile. This one succeeded. That one is clanlib, bug #454818. Like pusling already pointed out, there's still a lot to do with RC/RG bugs (although some of them are just prospective/incomplete patches, ls -1 *_gcc-4.3.diff wc -l reports 133 right now). Introductory reading for GCC 4.3: Porting to the New Tools. Please fix your bugs, prepare NMUs and so on, instead of just trolling like/with a bird.

Since my last example of fixing a bug received some interesting feedback (although I notice no upload of the package in question ..) we'll have another go. Looking over my ~/.bash_history file one command I use multiple times a day is make. Happily GNU make has at least one interesting bug open:

• #419190 - make: double free or corruption

I verified this bug by saving the Makefile in the report and running make:

skx@gold:~$ make
make: file.c:84: lookup_file: Assertion  *name != '\0'' failed.
Aborted

(OK so this isn't a segfault; but an assertion failure is just as bad. Honest!) So I downloaded the source to make, and rebuilt it. This left me with a binary with debugging symbols. The execution was much more interesting this time round:

skx@gold:~$ ./make
*** glibc detected ***
  /home/skx/./make: double free or corruption (fasttop): 0x00000000006327b0 ***
======= Backtrace: =========
/lib/libc.so.6[0x2b273dbdd8a8]
/lib/libc.so.6(cfree+0x76)[0x2b273dbdf9b6]
/home/skx/./make[0x4120a5]
/home/skx/./make[0x4068ee]
/home/skx/./make[0x406fb2]
...
[snip mucho texto]

And once I'd allowed core-file creation ("ulimit -c 9999999") I found I had a core file to help debugging. Running the unstripped version under gdb showed this:

(gdb) up
#5  0x00000000004120a5 in multi_glob (chain=0x1c, size=40) at read.c:3106
3106			    free (memname);

So it seems likely that this free is causing the abort. There are two simple things to do here:

• Comment out the free() call - to see if the crash goes away (!)
• Understand the code to see why this pointer might be causing us pain.

To get started I did the first of these: Commenting out the free() call did indeed fix the problem, or at least mask it (at the cost of a memory leak):

skx@gold:~$ ./make
make: *** No rule to make target  Erreur_Lexicale.o', needed by  compilateur'.  Stop.

So, now we need to go back to read.c and see why that free was causing problems. The function containing the free() is "multi_glob". It has scary pointer magic in it, and it took me a lot of tracing to determine the source of the bug. In short we need to change this:

free (memname);

To this:

free (memname);
memname = 0;

Otherwise the memory is freed multiple times, (once each time through the loop in that function. See the source for details). Patch mailed.

Daniel notes that self-delusion is a necessary component of all voluntary work.
Any human activity can be over-analysed into oblivion, especially if the terms of reference for "meaning" are impacted by a view of the real world that is overly abstract. Even paid work needs some self-delusion because no matter how much money you earn, the old maxims bite back - "you can't take it with you" and "no point earning it unless you can enjoy it".
Before I started with voluntary software work, I was heavily involved in voluntary charity work and the motivation is much the same. "The grand scheme of things" will never be sufficiently affected by any activity such as to provide the sole justification for that activity. The vast majority of people and the vast majority of actions simply are not and cannot become that important. (This is where religion is important for some people, the hope that despite all evidence to the contrary, acts of random kindness have some meaning to the person doing the act instead of just to the recipient.)
Voluntary work is generally for the benefit of others. In free software it is about writing code to solve our own issues in a way that others can use without facing the problems that we had to solve. Writing new code to solve a problem or fixing bugs in existing code to solve a new problem can only help others if the solution is shared. So the validation of that work is in helping someone else accomplish a task without having to spend the time fixing that issue, leaving them time to fix the next one.
Working on free software of all kinds is worthwhile simply because it is a way of helping others.
"When all things are considered", most people working on Debian are the lucky ones. Born into an environment where good education is available and where parents/relatives were able to indulge our fascination with electronic and computerised widgets that had no direct bearing on whether our basic human needs were met with regard to food, warmth and health. Trained at great expense and able to use that training not only to meet our personal financial needs but also to make time available for other unpaid tasks that benefit others who do not have those things. Living in a time of peace and stability, where the more esoteric and "frivolous" tasks can be undertaken without causing hardship or neglect of others. (My nephew frequently sums up this whole idea as like having won the lottery just by existing.)
There is an element of justification that can be derived from such a view - an element of responsibility and duty. After experiencing all those good things and after realising that we have such an opportunity, it can engender a feeling of obligation to do something that justifies what we have already received to balance out those who have the skills to do what we do but, for reasons of birth alone, do not have that opportunity or the means.
That is a form of secular humanism - validation of our own situation in the use of our skills and time to make things easier for those who are less fortunate.
OK, Debian isn't about providing clean water for all, or the redistribution of food and medicines to those without but the organisations that do that work can be assisted indirectly by making the systems used by such organisations work more efficiently, with greater stability and with more flexibility.
Not everyone can (or should) be on the front line of whatever acts of kindness will solve the problem of inequality but there is an obligation on those of us who have received the benefits of inequality to do what we can to make it easier to redraw the balance.
Debian is one such way and it is a truly international way of benefiting others too. It is more beneficial than the charity work that I did previously - chiefly because that was a very local service that was very labour-intensive and so could only benefit small numbers of people.
Improving Debian won't make us more important to the universe, life and everything (the answer to that is 42 as we all know), but it will help others do what they do, it will improve their lives and their ability to spend their time on what they want to do instead of having to fix problems that we have already solved.
Debian, to me, is about sharing solutions. Helping someone else do something that Debian could not do before, without requiring them to fix all the problems that I had to solve to devise the solution in the first place. Sharing not just the solution but the method of the solution and the means to extend the solution to new problems.
We, as Debian developers, have been granted the access and tools to solve these problems for the benefit of those who do not have upload privileges. Those rights come with responsibilities (as always) to use our skills and time to find the solution and without making things more difficult in the process.
In the grand scheme of what I can actually do as opposed to what might be possible if X, Y and Z were different, what I do in Debian and Emdebian is worthwhile. In fact, it is just as worthwhile as my paid non-IT employment in healthcare provision because, within healthcare, I can only help the single person in front of me. In Debian, I can help all those people who I will probably never meet but who want Debian to do something that I am able to achieve.
What is particularly nice about Emdebian is that there are people who tell us that our work is worthwhile by putting up the hard cash to fund work sessions and conferences that bring the various developers into one place. The international aspects of Debian can be a barrier in some ways and things always happen more quickly when the various members of the team can be brought from the four corners of the planet into one place for a week or so. It is these gatherings that boost the motivation and the enjoyment of making progress towards a common goal. Debian can be a solitary world where communication is limited to plain text. Probably the best way to "oil the wheels" in Debian is to get a group of Debian people together and just let them hack.
Voluntary work of all kinds requires personal motivation and working alone with only limited means of communication with others can be quite demotivating. Getting people together is a very useful antidote.

Or, as it's said, history repeats itself. Today I sold my motorcycle (wait for the “blade” photograph).
Again it wasn't really old, just 4 years; but it too had over 54000 kilometres; time again to release it.

I didn't quite get the money of it that I wished for, but then again, for a bike with that mileage you can't really be picky about what people pay for it. And in hindsight the fireblade seems to have been a bad choice; there's a lot of them on sale at least over here right now.
Note to self: try to get a less popular bike next time, it pays off when trying to sell it.

Actually I've already made the choice for a new bike (though I do not know if my choice follows the rule I just laid out). But it's been a hard choice; which is a story in itself. And that story is for another time.

Again, I must say it feels strange. While this wasn't the first bike I sold off, I feel a little melancholious about it. I guess that's just part of selling any bike. Assuming you've build a bond with the machine. But then again, any real motor rider would build such bond. IMHO.

Continuing from where we left off… The lower bound for me becoming a DD was 8th Feb ‘98 when I applied; for comparison, the upper bound as best I can make out was 23rd Feb, when I would have received this mail through the debian-private list:

Resent-Date: 23 Feb 1998 18:18:57 -0000
From: Martin Schulze 
To: Debian Private 
Subject: New accepted maintainers
Hi folks,
I wish you a pleasant beginning of the week.  Here are the first good
news of the week (probably).
This is the weekly progress report about new-maintainers.  These people
have been accepted as new maintainer for Debian GNU/Linux within the
last week.
[...]
Anthony Towns <ajt@debian.org>
    Anthony is going to package the personal proxy from
    distributed.net - we don't have the source... He may adopt the
    transproxy package, too.
Regards,
        Joey

I never did adopt transproxy – apparently Adam Heath started fixing bugs in it a few days later anyway, and it was later taken over by Bernd Eckenfels (ifconfig upstream!) who’s maintained it ever since. Obviously I did do other things instead, which brings us back to where we left off…

---

• Crypto in main: It’s getting hard to remember the days when strong crypto software was classed as munitions and even getting a web browser to do SSL properly was a legal challenge; but for a long while that’s how it was, and as a result we had to keep all our security tools hosted separately to our main, US-based archive. The laws for that changed in early 2000, introducing a new exemption to the prohibition for software whose source code was available royalty-free (I think they called it “public source”). Unfortunately there were still drawbacks: it wouldn’t apply to some stuff in non-free, it wasn’t clear how far you had to go with the source code (is libssl’s source enough, or do you need the source for the apps that use ssl too?), and the biggest problem was you had to notify the export bureau and the NSA for everything you wanted to distribute. And all of that’s couched in the sort of confusing language you’d expect to find in, well, export regulations. So we ended up getting nowhere on merging crypto into the main archive for a long while because we couldn’t be confident of what we actually needed to do. We’d more or less already missed the opportunity to do the merge for the potato (2.2) release because it was frozen more or less exactly when the new regulations came out, and according to my mail archives Ben Collins (DPL at the time) got a team organised to review the legal issues by mid-May 2001. By July 2001, though, we still weren’t really getting anywhere; the lawyer we were talking to was looking at the ENC exception (which was for closed source stuff, and requires an active review by the BXA), instead of the TSU exception (which just requires notification). While it wasn’t terrible legal advice – following the ENC exception had a lower risk of misunderstandings on our part leading to problems later – it wasn’t useful in achieving our aims, ie, getting crypto stuff into main with a minimal level of ongoing effort, as well as a minimal level of risk. So moving onto August, we’d moved on from the lawyer we’d been using for this and other issues, to talking to a lawyer who specialised in export issues (and whose time was being covered by HP). That actually got us somewhere, with the end results being a matter of public record – we got the advice we wanted by November, we got a new incoming system so we could make sure we didn’t publish anything we hadn’t advised the NSA and BXA about, and most of all, we got cryptographic software in main for woody’s release. ssh at standard priority, apt by default checking archive signatures before downloading code to run as root, iceweasel coping with https:// urls out of the box all suddenly became possible, rather than artificially blocked due to pointless legal constraints. Yay! The way we notified BXA/NSA was somewhat interesting – we ended up notifying once for each package, when it passed through NEW: which is easy to automate, and limits the amount of software we block from review by other developers as best we can. OTOH, it also means a lot of notifications: the initial notification was a huge box of paper that got faxed off (there should be pictures somewhere on the net, but I don’t know where), and the vague hope that the ongoing reporting would not only comply with the regs, but manage to be something of a denial-of-service by compliance. As it turns out it apparently got noticed, with the following mail arriving in September 2005:

  From: Encryption 
  Date: Fri, 23 Sep 2005 12:51:02 -0400
  Subject: Addition to Debian Source Code updates
  Dear Mr. Collins,
  Your diligent reporting of updates to the Debian source code to the Bureau
  of Industry and Security has been an excellent example of perspicacity.
  However, you no longer need to do so per the following update to the EAR:
  [...]
  

  (The mails have always been sent with Ben's name attached) That mail was followed by another suggesting a phone conversation; unfortunately nobody seemed to notice the mail, at least until a year later (to the day!) when Joerg pointed out he was getting bounces form the BXA email address we'd been using... (Since then, based on the above mail, we've been recording notifications, but not passing them on; I sent a reply to the mails above indicating that, but didn't receive a response. There's been about 5000 notifications since then)
• Security and the architecture explosion: with crypto-in-main out of the way, along with lots of RC bug squashing, woody was looking good to come out in April or May, but unfortunately that all fell apart because of a lack of automation for handling security updates. Taking a step back, woody managed to introduce five new architectures compared to the previous release -- HP's pets, hppa and ia64; the IBM mainfram arch, s390, and the SGI/embedded mips and mipsel chips. That came just short of doubling our supported architectures (which had been i386, m68k, alpha, arm, sparc and powerpc), and was working really impressively well: testing was watching that they kept in sync, and the buildd network was keeping them all up to date with the latest source uploads, and the toolchain maintainers were making sure new kernels and compilers didn't cause massive breakages. It was great fun to be a part of, and I'm not sure how much is just blurry memories, but from here, it sure feels like it was a golden age on that score... Anyway, all the extra architectures freaked the security team out, given they were already having to worry about ssh'ing to half a dozen machines and manually do builds, and fix them when they broke, and to deal with that there'd been plans afoot for "rbuilder" to get rolled out, which never actually happened. All of which means it escalated from being the security team's problem, to a problem for everyone, particularly the release manager... The result of which meant knuckling down and coming up with a new security build infrastructure, which involved doing a dak install for the security archive, then building on the changes just rolled out for crypto-in-main to allow for packages to be autobuilt before actually being included in the archive, then updating official buildds for all the various architectures to target stable-security and testing-security and prioritise them and upload to the right place. But as stressful and last minute as that was, at least it worked, and woody made it out the door on July 20th 2002 -- and it's a good thing it worked, given woody ended up getting security support until June 30th 2006 -- the usual year after it's successor is released -- for four years support. (The same rule applied to sarge has resulted in two years and ten months' security support; eighteen month release cycles in general should result in two years and six months of support) Since then, with security managed by dak, there's been a few more bits I've been involved in. The most interesting of which (to my mind) was splitting the security upload queue from being completely secret and restricted to folks who are allowed to access updates prior to public announcement, into separate secret and non-secret queues. That was December 2005, and since then we've gone from having Joey Schulze basically being the sole person doing security updates to two separate teams, with ten new members. It's not without it's problems -- particularly for packages that get (mis)classified as NEW, or that get lost on their way for inclusion in the next stable point update, but it's nevertheless lightyears from where we were in April 2002, or even November 2005.
• Playing other people for suckers: with woody released, the whole "redo to release process" thing was essentially done -- it had been implemented, it had worked all the way to getting a release out, and in a fair few respects had improved things. Instead of the eight months of hand-approved uploads for the potato freeze, things had gone it automatically, albeit with gradually stricter constraints, right up until April; and even when the security problems delayed things, the manual updates only lasted a bit under three months. So at that point I was pretty happy, and looking forward to making things work a bit better and basically passing the buck to someone else. The first bit of buck passing that worked exceptionally well was jumping on Colin Watson, who'd been offering some debbugs patches on IRC, and after a delightfully brief discussion with some of the other debbugs folks, got getting him added to the group and able to make changes directly on the site. His advogato post the next day was:

  Yesterday I was invited onto the group that administers the Debian bug tracking system. I can't decide whether to be intimidated or excited. There's a great deal to do: my first couple of major projects look set to be integrating some of the existing QA interfaces to release-critical bug tracking, and developing a tool to help us edit spam out of bug histories.

  There's a lot to be said for grabbing people at the point where they're still intimidated by what they're joining; sure there's a definite risk that they'll break something you'll have to clean up, but that's pretty easy to deal with, and well worth all the extra excitement and energy that comes with a little bit of nerves. I did a talk on debbugs a few years later, at the 2005 DebConf, at which point we managed to entice Pascal Hakim and Don Armstrong into signing up, if I'm remembering right. At the same time Colin rolled out his implementation of version tracking support for debbugs (which I'd specced up a while ago, and helped design, but cannily avoided actually coding). Shortly after, Pasc put together bug subscriptions, and these days Don's pretty much the primary maintainer of debbugs. How cool is that? Passing on release managership was a bit less fortuitous though; it's a big job, and it's not something that you can offer "patches" for, generally. So after a bit of cogitating on just how to do it, I went with an open recruitment call in March 2003, and then a bunch of practical assignments to get the volunteers used to what RM work actually entailed and to see whether they actually like it. The recruitment call was mostly focussed on all the negatives, half to avoid people volunteering to be RM for the power (to decide which release policy wins, to tell maintainers what to do, to drop packages, or to just decide what name/number the next release gets) instead of wanting to actually do the work to get the next release out and keep developers happy; and the other half was the theory that if you make a job look hard, technical, but not terribly risky, it starts looking interesting to the right kind of people. The assignments generally were two parters -- first to introduce some stuff about release management that they mightn't be familiar with, and the second a bunch of problems that needed resolving that'd use those skills. The first set was RC bug fixing, followed by working out why packages aren't getting into testing, followed by dealing with packages with mutual dependencies and removing packages. At some point that evolved into the testing scripts accepting "hints" from the release team as to what packages to try in combination, or which packages to force out of testing. That turned out pretty successful, with Steve Langasek, Colin Watson and Joey Hess becoming official release assistants in August, and Colin and Steve replacing me as RM in mid-2004. It was also pretty satisfying to see Andi Barth do some more release assistant recruiting in 2005 following much the same model, and indeed using much of my mail verbatim. You can't really ask for better than that, I figure.

Geez, this was meant to be briefer...

Between February 29 and March 4, 2008 I attended the Sage Days 8, hosted at the Enthought headquarters in Austin, Texas. This was my 5th time in the USA and it was a marvelous experience, as with all my visits in the states.

As usual, I had some adventures in Atlanta, that interested readers can find at the end of this post. Anyway, on the Austin's airport I met Peter and his wife Crystal, Fernando, Benjamin, Jarrod, Eric and Clement. We went to have a dinner and then me and Clement were staying at Peter's house:



You can see the neighbor's cat and Peter's dog Trinity behind the window. The next day we went to Enthought, that was providing us with a breakfast and a lunch each day - and it was delicious. After the breakfast, we gathered in the room and introduced ourselves. Enthought rents 3/4 of the 21th floor in the Bank of America building, so when I looked left I saw:



When I looked behind I saw:



and in front of me, I saw all the participants (I took photos of all participants together with names). As you can see, there were really good people in there, like Travis (creator of NumPy), William (main author of Sage), Eric (CEO of Enthought), Fernando (author of IPython), Jarrod (the release manager of SciPy), Michael (the release manager of Sage) etc. See also the Fernando's welcome speech and the video of each of us introducting himself.

The views from the windows are terrific. I enjoyed working on each of the 4 sides of the skyscraper with completely different scenery, or when the sun is going down, that's also very cool.

We spent the whole Friday doing presentations, some of which you can find here. Then we went to Eric's house to have a big dinner together.

On Saturday, Sunday and Monday we were all hacking on many different things. I joined Fernando, Benjamin, Brian and Stefan on ipython1, Travis was implementing a new type (gmp integer) in NumPy, William wrote a manipulate command in Sage, Eric did the same in Traits, Gary and Michael implemented parallel testing of Sage, ...

On Tuesday we had final status reports and people left in the afternoon. In the evening we went with Clement to have a dinner and then we visited some bars on the 6th street, having a beer in each.

On Wednesday I visited John and Roy from the Computational Fluid Dynamics Lab at the University of Texas, Austin, who wrote the libMesh library, that I extensively used and also created a Debian package of. It was very influential to see the libMesh "from behind", also John and Roy are cool people (not mentioning the Debian tradition of having good relations with upstream:). Then I visited some professors at the same campus, after which I went into the Capitol and then I took the bus to the Barton Creek Square Mall to buy some ipods and jeans, so that I can say I have jeans from Texas. BTW, the ipod works excellent in Debian - I plugged it in and it just shows on my Gnome desktop. It's true that naively dragging mp3 files on it didn't make it play, but these instructions made it work.

On Thursday I fixed the remaining release blockers in SymPy and made a new release. In the evening, I am going to meet Aswin, he also uses SciPy and also is a friend of Kumar, who is now maintaining python-numpy and python-scipy Debian packages with me (Kumar also knows Prabhu, the author of Mayavi2 hosted at Enthought, so it's all connected).

Anyway, the whole workshop was an excellent experience for me. I learned a lot of new things and being able to speak with people who wrote tools that I use almost everyday is important. We also extensively discussed the future of all the projects (Sage, SciPy, NumPy, IPython, Cython, SymPy). See my summarizing email to the SymPy mailinglist.

Another thing, that I find very interesting is that Microsoft is financing the windows port of Sage, that will make basically anything that uses Python/Cython/C/Fortran very easy to install on windows (just a spkg package in sage). I find it really cool that MS is not only supporting but even financing a truly opensource project.

Finally the promised adventure in Atlanta: we took off the Prague airport on February 28th with a 2 hours delay (due to some paperwork as we were told by the captain). As I had 3 hours in Atlanta for the connection to Austin and I had to go through immigration, it was clear that I'll miss it. But I was not surprised, last time I was flying through Atlanta, they canceled my flight to LA completely. We arrived in Atlanta an hour and a half before my departure, then I was waiting for about an hour at immigration, it was incredibly slow. When I had around 20 min to departure, I had to ask people standing in front of me if they let me in, they were very nice and did. I was leaving immigration 10 min to my departure, then I was running to get my luggage and myself through customs and screening, it was 5 min to my departure when I ran down to the display with departure times. Then I was sprinting like hell to the terminal D to only see the clerk doing some final paperwork with all the people already boarded and the jetway door shut. After a little persuading he let me in too, fortunately there was still one seat left, so I made it. You can imagine my pleasant surprise in Austin when I discovered, that my luggage made it too, considering that I handed it to the Atlanta's airport personnel exactly 10 min prior the departure.

I like autotools, I use them widely and I'm happy that I understand autotools sufficiently that I can be confident in using them and helping others with theirs. All my own upstream C projects rely on autotools and I have a personal rule that I always preserve make distcheck compatibility during CVS/SVN changes and without fail prior to ALL releases.
Lenny will be the second Debian release with which I've been involved and as I prepare to round on the RC bugs once again, I'm noticing a pattern in autotools bugs from other upstream teams.

1. If more upstream projects enforced rigorous testing with make distcheck, a lot of bone-headed numbskull errors would be prevented in the upstream codebase. Fixing make distcheck isn't that hard because it is a test of the build system files, not necessarily the source code. Once an upstream build is fixed, subsequent make distcheck failures are both rare and serious. Other failures in the test suite should be easier to spot too. The important point is that make check only tests the current build on the upstream system. make distcheck goes a long way to ensuring that the package will build in the same way on lots of systems, including cross builds.


2. autotools expects such fixes to be made upstream and fixing things after the release can be a serious PITA, so fix it before release.


3. The single greatest weakness of make distcheck and autotools in general is bit rot. It is so important for upstream to refresh the autogenerated files on an intermittent basis. With a big development team, this can be easy - especially if new people are regularly joining and building the source for the first time from CVS/SVN. Once that rotation stops, the difficulties of trying to fix the upstream code get more and more noticeable. Maybe one day autotools will fix this and become more resistant to bit rot but, for now, it is a significant problem.


4. As a consequence of file rotation, it is seldom a good idea to keep any autotools generated files in any form of RCS, even distributed ones. This is where I fall foul of many who want to package directly from SVN CVS foo. The mantra of lots of RCS helpers is "everything must be in the RCS" which is just plain wrong IMNSHO. The only things that must be in any RCS are the bits that upstream needs to write. So Makefile.am is, Makefile.in is not. configure.ac is, configure is not. Same for libtool, ltmain.sh, config.* and a host of other autotools generated files. If autogen.sh can generate or symlink them, don't have them in RCS. If, as upstream, you have not had to edit the file or copy it into place using a patch supplied by someone else, it should not be in the RCS. This discipline ensures that when someone starts from a fresh checkout, the build system is refreshed (and is why many autotools upstreams add a "make rcsclean" rule that goes one stage beyond make distclean by going back to raw RCS). If you maintain a helper that is meant to build packages like this, ensure that the helper has support for getting from raw RCS to make distcheck and ensure that the helper uses the tarball created by make dist not one of it's own.

Yes, bit rot is the curse of all software but when combined with the lack of usage of make distcheck prior to upstream falling quiet, I sometimes wonder about the merits of trying to fix bugs in the build system of packages with a most recent upstream release that precedes Etch. I get a real chill thinking about upstream packages with a most recent release that precedes Sarge.
So, if you're working on an upstream project using autotools, just do everyone a favour:

 svn cvs  ci -m "make sure things work"

make uninstall

make distclean

./autogen.sh

./configure --prefix=... 

make

make check

make install

make distcheck

Repeat the last stage until it completes without errors, commit the changes and retest from the beginning.
I'm not proposing something I do not do myself - as above, I do these tests on my own (released) upstreams on a regular basis. I just wish more upstreams would do so too. If every upstream did this prior to that final release, it would be so much easier to do all kinds of cool things with your code, long after you lose interest in it yourself.

What's the best way to join a community, any community? Little by little.
I have been working with Ruby on Rails for well over a year already, even given a talk (at Encuentro Nacional Linux y Software Libre ENLi) inviting other people to use this very nice and well thought out environment. But, so far, I've been only a end-user, not really giving anything back besides minor bug reports.
Well, it's not as much as to say that I'm now a contributor - this is just a first statement of intent. I have worked a bit on several bits of code I keep repeating and hand-copying over my different Rails projects. Of course, that's completely not DRY - And completely not nice. So I decided to stop advancing on several projects, and learn my way on stting those bits of code as Rails plugins.
So far, it's been quite simple - and a good excercise on proper separation. I started, of course, with the easiest bit of code I could think of as useful in a general sense, and packaged it up as acts_as_catalog (of course, proper SVN tree and very basic, introductory README. And, of course, as I keep progressing with this work, I'll keep adding some plugins to my currently quite empty RubyForge page.
Anyway... Little by little, time will come where we have to think more seriously on how to properly bring together the Ruby on Rails style to work more tightly with Debian. Currently, the two have such different points of view on how to manage and ship components that I am not sure we will be able to truly bridge them together... But it is definitively worth trying. Hmh, looks like a task for Debconf! ;-)

On Saturday 1 March, I attended the Constitutional Review Roadshow at Explore@Bristol (pictured). The review is trying to develop the rules for the Cooperative Group after its merger with United. The event wasn't at all what I expected or hoped for. There were relatively few individual members there. I don't know the split, but most of the 60 or so attendees seemed to be elected members of some sort and this was the first chance they'd had to comment since the open consultation ended last year. Some of the elected members had travelled from the Eastern and South East regions. The initial slide "Purpose of Today" stated three aims:

1. bring members up to date;
2. give members the opportunity to ask questions;
3. and aid members in preparing their formal feedback.

I don't feel the event really brought us up to date or aided in preparing formal feedback, because the roadshow appeared to summarise a report which hasn't been published. Some of the elected members had seen it the day before, but no copies were available to use at the event, so we were pretty much in the dark for some aspects. The event didn't give us much opporunity to ask questions either, despite its length. I was expecting more of a consultation event, which was reinforced when I entered the room and saw seats gathered around tables. I did not expect an hour-long lecture followed by three hours or so of whole-group question-and-answer, broken by lunch. Even with the competent chairing (AFAICT), that was an amazingly inefficient way of working, with some people being cut short, but still leaving some people not being heard. It can be summed up by the chairman commenting

"I do not want this to turn into a discussion"

while the big screen next to him said "questions and discussion"! Headlines from the review: similar elected structures to current Group structure, but regional board nominated by individual members; merge regions to produce six new regions (West Midlands and North West, Wales and South West, London and South East, Eastern England and East and South Midlands, Yorkshire and Humber and North East, Scotland and Northern Ireland); add management and non-executive directors to national board; no clue how to fix diversity problems; no view on fees or job spec until structures are defined. I'll go through the slides in detail and post the questions and answers if anyone leaves a comment asking for them. Otherwise, I think I've lost enough time to this for now.

Soon after Bernd Zeimetz joined our company, he infected me with the geocaching virus. In the meantime, I bought a GPS receiver, and am now endeavoring around the town and the nearby woods, searching for caches. There's not that much free GPS and/or geocaching software around. gpsd works quite well, but I don't take my computer to the woods ;) Viking is very nice for visualizing waypoints and sorting them in categories, but is still somewhere between alpha and beta state. gpsbabel reads and writes a zillion different file format and talks to a vast array of receivers, but often needs several attempts to upload data to mine. Things are moving fast though and the GPS community looks active. Last week I started looking into OpenStreetMap and already added a few roads in my neighborhood. Compared to commercial maps, there's still much to do, especially for smaller tracks and features like foot bridges or woods outside bigger cities. I'll keep collecting GPS data :) For the free software side, neither OSM's online editor worked here (flash), nor the recommended tool for local use (java), so I tried merkaartor (qt4) which works nicely. It also has some bugs, but feels very usable (though sometimes slow). Starting from upstream's debian/ dir, building packages was straightforward, and after some more editing, packages are now in unstable. (The svn repository is in collab-maint, contributors welcome.)

My FOSDEM talk didn't go entirely as planned. I tried to run a demo of the beid packages, but unfortunately they decided to play up again. This isn't the first time; they sometimes have this. It has something to do with OpenSC or OpenCT, I believe, but it's hard to figure out what, exactly. When I got back at the office with the machine that failed to work properly, and tried again, it did work. Heisenbugs suck. Pun intended. Anyway, since things work now, I prepared a screencast showing off what I wanted to show during the talk; it takes about 8 minutes. I was going to edit the talk to hide the spammer who was DoS'ing my mailserver just as I was trying to send an email out, and perhaps to hide away the long waits at times; but I didn't find an easy way to do so, and I got tired looking. If you're interested, have a look. Also, the screencast doesn't include any sound. This is because I couldn't find any piece of equipment on which istanbul would produce correct imagery (it appears to be buggy on powerpc), where the hardware was fast enough to capture and encode both a video at 1024x768 resolution and sound from the sound card (ruling out "anything", the machine on which I tried to do the presentation at FOSDEM), and on which the microphone would actually work (ruling out the amd64 box that was standing nearby). Since I could at least create a correct movie on the last machine, I just forgot about the sound. Instead, I tried to make the screencast show what was going on, by pointing at important tidbits with my mouse pointer. Which kindof worked, but was not ideal. Oh well.