Samuel Thibault is a French guy like me, but it took years until we met. He tends to keep a low profile, even though he s doing lots of good work that deserves to be mentioned. He focuses on improving Debian s accessibility and contributes to the Hurd. Who said he s a dreamer? Checkout his interview to have some news of Wheezy s status on those topics. Raphael: Who are you? Samuel: I am 30 years old, and live in Bordeaux, France. During the workday, I teach Computer Science (Architecture, Networking, Operating Systems, and Parallel Programming, roughly) at the University of Bordeaux, and conduct researches in heterogeneous parallel computing. During the evening, I play the drums and the trombone in various orchestra (harmonic/symphonic/banda/brass). During the night, I hack on whatever fun things I can find, mainly accessibility and the Hurd at the moment, but also miscellaneous bits such as the Linux console support. I am also involved in the development of Aquilenet, an associative ISP around Bordeaux, and getting involved in the development of the network infrastructure in Bordeaux. I am not practicing Judo any more, but I roller-skate to work, and I like hiking in the mountains. I also read quite a few mangas. Saturday mornings do not exist in my schedule (Sunday mornings do, it s Brass Band rehearsal ). Raphael: How did you start contributing to Debian? Samuel: Bit by bit. I have been hacking around GNU/Linux since around 1998. I installed my first Debian system around 2000, as a replacement for my old Mandrake installation (which after all my tinkering was actually no longer looking like a Mandrake system any more!). That was Potato at the time, which somebody offered me through a set of CDs (downloading packages over the Internet was unthinkable at the time with the old modems). I have been happily reading and hacking around documentation, source code, etc. provided on them. Contribution things really started to take off when I went to the ENS Lyon high school in 2001: broadband Internet access in one s own student room! Since sending a mail was then really free, I started submitting bugs against various packages I was using. Right after that I started submitting patches along them, and then patches to other bugs. I did that for a long time actually. I had very little knowledge of all packaging details at the time, I was just a happy hacker submitting reports and patches against the upstream source code. At ENS Lyon, I met a blind colleague with very similar hacking tastes (of course we got friends) and he proposed me, for our student project, to work on a brlnet project (now called brlapi), a client/server protocol that lets applications render text on braille devices themselves. Along the way, I got to learn in details how a blind person can use a Unix system and the principles that should be followed when developing Accessibility. That is how I got involved in it. We presented our project at JDLL, and the Hurd booth happened to be next to our table, so I discussed with the Hurd people there about how the Hurd console could be used through braille. That is how I got into the Hurd too. From then on, I progressively contributed more and more to the upstream parts of both accessibility software and the Hurd. And then to the packaging part of them. Through patches in bug reports first, as usual, as well as through discussions on the mailing lists. But quickly enough people gave me commit access so I could just throw the code in. I was also given control over the Hurd buildds to keep them running. It was all good at that stage: I could contribute in all the parts I was caring about. People however started telling me that I should just apply for being a Debian Developer; both from accessibility and Hurd sides. I had also seen a bunch of my friends going through the process. I was however a bit scared (or probably it was just an excuse) by having to manage a gpg key, it seemed like a quite dangerous tool to me (even if I already had commit access to glibc at the time anyway ). I eventually applied for DM in 2008 so as to at least be able to upload some packages to help the little manpower of the Accessibility and Hurd teams. Henceforth I had already a gpg key, thus no excuse any more. And having it in the DM keyring was not enough for e.g. signing the hurd-i386 buildd packages. So I ended up going through NM in 2009, which went very fast, since I had already been contributing to Debian and learning all the needed stuff for almost 10 years! I now have around 50 packages in my QA page, and being a DD is actually useful for my work, to easily push our software to the masses So to sum it up, the Debian project is very easy to contribute to and open to new people. It was used during discussions at the GNU Hackers Meeting 2011 as an example of a very open community with public mailing lists and discussions. The mere fact that anybody can take the initiative of manipulating the BTS (if not scared by the commands) without having to ask anybody is an excellent thing to welcome contributions; it is notable tha the GNU project migrated to the Debbugs BTS. More generally, I don t really see the DD status as a must, especially now that we have the DM status (which is still a very good way to drag people into becoming DDs). For instance, I gave a talk at FOSDEM 2008 about the state of accessibility in Debian. People did not care whom I was, they cared that there was important stuff going on and somebody talking about it. More generally, decisions that are made through a vote are actually very rare. Most of the time, things just happen on the mailing lists or IRC channels where anybody can join the discussion. So I would recommend beginners to first use the software, then start reporting bugs, then start digging in the software to try fix the bugs by oneself, eventually propose patches, get them reviewed. At some point the submitted patches will be correct already most of the time. That s when the maintainers will start getting bored of just applying the patches, and simply provide with commit access, and voil , one has become a main contributor. Raphael: You re one of the main contributors to the Debian GNU/Hurd port. What motivates you in this project? Samuel: As I mentioned above, I first got real contact with the Hurd from the accessibility point of view. That initially brought me into the Hurd console, which uses a flexible design and nice interfaces to interact with it. The Hurd driver for console accessibility is actually very straightforward, way simpler than the Windows or Linux drivers. That is what caught me initially. I have continued working on it for several reasons. First, the design is really interesting for users. There are many things that are natural in the Hurd while Linux is still struggling to achieve them, such as UID isolation, recently mentioned in LWN. What I really like in the Hurd is that it excels at providing users with the same features as the administrator s. For instance, I find it annoying that I still can not mount an ISO image that I build on e.g. ries.debian.org. Linux now has FUSE which is supposed to permit that, but I have never seen it enabled on an ssh-accessible machine, only on desktop machines, and usually just because the administrator happens to be the user of the machine (who could as well just have used sudo ) For me, it is actually Freedom #0 of Free Software: let the user run programs for any purpose, that is, combining things together all the possible ways, and not being prevented from doing some things just because the design does not permit to achieve them securely. I had the chance to give a Hurd talk to explain that at GHM 2011, whose main topic was extensibility , I called it GNU/Hurd AKA Extensibility from the Ground, because the design of the Hurd is basically meant for extensibility, and does not care whether it is done by root or a mere user. All the tools that root uses to build a GNU/Hurd system can be used by the user to build its own GNU/Hurd environment. That is guaranteed by the design itself: the libc asks for things not to the kernel, but to servers (called translators), which can be provided by root, or by the user. It is interesting to see that it is actually also tried with varying success in GNU/Linux, through gvfs or Plash. An example of things I love being able to do is: $ zgrep foo ~/ftp://cdn.debian.net/debian/dists/sid/main/Contents-*.gz On my Hurd box, the ~/ftp: directory is indeed actually served by an ftpfs translator, run under my user uid, which is thus completely harmless to the system. Secondly and not the least, the Hurd provides me with interesting yet not too hard challenges. LWN confirmed several times that the Linux kernel has become very difficult to significantly contribute to, so it is no real hacking fun any more. I have notably implemented TLS support in the Hurd and the Xen and 64bit support in the GNU Mach kernel used by the Hurd. All three were very interesting to do, but were already done for Linux (at least for all the architectures which I actually know a bit and own). It happens that both TLS and Xen hacking experience became actually useful later on: I implemented TLS in the threading library of our research team, and the Xen port was a quite interesting line on my CV for getting a postdoc position at XenSource Lastly, I would say that I am used to lost causes My work on accessibility is sometimes a real struggle, so the Hurd is almost a kind of relief. It is famous for his vapourware reputation anyway, and so it is fun to just try to contribute to it nevertheless. An interesting thing is that the opinion of people on the Hurd is often quite extreme, and only rarely neutral. Some will say it is pure vapourware, while others will say that it is the hope of humanity (yes we do see those coming to #hurd, and they are not always just trolls!). When I published a 0.401 version on 2011 April 1st, the comments of people were very diverse, and some even went as far as saying that it was horrible of us to make a joke about the promised software Raphael: The FTPmasters want to demote the Hurd port to the debian-ports.org archive if it doesn t manage a stable release with wheezy. We re now at 2 months of the freeze. How far are you from being releasable ? Samuel: Of course, I can not speak for the Debian Release team. The current progress is however encouraging. During Debconf11, Michael Banck and I discussed with a few Debian Release team members about the kind of goals that should be achieved, and we are near completion of that part. The Debian GNU/Hurd port can almost completely be installed from the official mirrors, using the standard Debian Installer. Some patches need some polishing, but others are just waiting for being uploaded Debian GNU/Hurd can start a graphical desktop and run office tools such as gnumeric, as well as the iceweasel graphical web browser, KDE applications thanks to Pino Toscano s care, and GNOME application thanks to Emilio Pozuelo Monfort s care. Of course, general textmode hacking with gcc/make/gdb/etc. just works smoothly. Thanks to recent work on ghc and ada by Svante Signell, the archive coverage has passed 76%. There was a concern about network board driver support: until recently, the GNU Mach kernel was indeed still using a glue layer to embed the Linux 2.2 or even 2.0 drivers (!). Finding a network board supported by such drivers had of course become a real challenge. Thanks to the GSoC work of Zheng Da, the DDE layer can now be used to embed Linux 2.6.32 drivers in userland translators, which was recently ACCEPTed into the archive, and thus brings way larger support for network boards. It also pushes yet more toward the Hurd design: network drivers as userland process rather than kernel modules. That said, the freeze itself is not the final deadline. Actually, freeze periods are rests for porters, because maintainers stop bringing newer upstream versions which of course break on peculiar architectures. That will probably be helpful to continue improving the archive coverage. Raphael: The kfreebsd port brought into light all the packages which were not portable between different kernels. Did that help the Hurd port or are the problems too different to expect any mutual benefit? Samuel: The two ports have clearly helped each other in many aspects. The hurd-i386 port is the only non-Linux one that has been kept working (at least basically) for the past decade. That helped to make sure that all tools (dpkg, apt, toolchain, etc.) were able to cope with non-Linux ports, and keep that odd-but-why-not goal around, and evidently-enough achievable. In return, the kFreeBSD port managed to show that it was actually releasable, at least as a technological preview, thus making an example. In the daily work, we have sometimes worked hand in hand. The recent porting efforts of the Debian Installer happened roughly at the same time. When fixing some piece of code for one, the switch-case would be left for the other. When some code could be reused by the other, a mail would be sent to advise doing so, etc. In the packaging effort, it also made a lot of difference that a non-Linux port is exposed as released architecture: people attempted by themselves to fix code that is Linuxish for no real reason. The presence of the kFreeBSD is however also sometimes a difficulty for the Hurd: in the discussions, it sometimes tends to become a target to be reached, even if the systems are not really comparable. I do not need to detail the long history of the FreeBSD kernel and the amount of people hacking on it, some of them full-time, while the Hurd has only a small handful of free-time hackers. The FreeBSD kernel stability has already seen long-term polishing, and a fair amount of the Debian software was actually already ported to the FreeBSD kernel, thanks to the big existing pure-FreeBSD hackerbase. These do not hold for the GNU/Hurd port, so the expectations should go along. Raphael: You re also very much involved in the Debian Accessibility team. What are the responsibilities of this team and what are you doing there? Samuel: As you would expect it, the Debian Accessibility team works on packaging accessibility-related packages, and helping users with them; I thus do both. But the goal is way beyond just that. Actual accessibility requires integration. Ideally enough, a blind user should be able to just come to a Debian desktop system, plug his braille device, or press a shortcut to enable speech synthesis, and just use the damn computer, without having to ask the administrator to install some oddly-named package and whatnot. Just like any sighted user would do. He should be able to diagnose why his system does not boot, and at worse be able to reinstall his computer all by himself (typically at 2am ). And that is hard to achieve, because it means discussing about integration by default of accessibility features. For instance, the Debian CD images now beep during at the boot menu. That is a precious feature that has been discussed between debian-boot and debian-accessibility for a few weeks before agreeing on how to do it without too much disturbance. Similarly, my proposition of installing the desktop accessibility engines has been discussed for some time before being commited. What was however surprisingly great is that when somebody brought the topic back for discussion, non-debian-accessibility people answered themselves. This is reassuring, because it means things can be done durably in Debian. On the installation side, our current status is that the stable Debian installer has a high contrast color theme, and several years ago, I have pushed toward making standard CD images automatically detect braille devices, which permits standalone installation. I have added to the Wheezy installer some software speech synthesis (which again brought discussion about size increase vs versatility etc.) for blind people who do not have a braille device. I find it interesting to work on such topic in Debian rather than another distribution, because Debian is an upstream for a lot of distributions. Hopefully they just inherit our accessibility work. It at least worked for the text installer of Ubuntu. Of course, the Accessibility team is looking for help, to maintain our current packages, but also introduce new packages from the TODO list or create some backports. One does not need to be an expert in accessibility: tools can usually be tested, at least basically, by anybody, without particular hardware (I do not own any, I contributed virtual ones to qemu). For new developments and ideas, it is strongly recommended to come and discuss on debian-accessibility, because it is easy to get on a wrong track that does not bring actual accessibility. We still have several goals to achieve: the closest one is to just fix the transition to gnome3, which has been quite bad for accessibility so far :/ On the longer run, we should ideally reach the scenario I have detailed above: desktop accessibility available and ready to be enabled easily by default. Raphael: What s the biggest problem of Debian? Samuel: Debian is famous for its heated debian-devel discussions. And some people eventually say this no fun any more . That is exemplified in a less extreme way in the debian-boot/accessibility discussions that I have mentioned above. Sometimes, one needs to have a real stubborn thick head to continue the discussion until finding a compromise that will be accepted for commit. That is a problem because people do not necessarily have so much patience, and will thus prefer to contribute to a project with easier acceptance. But it is also a quality: as I explained above, once it is there, it is apparently for good. The Ubuntu support of accessibility in its installer has been very diverse, in part due to quite changing codebase. The Debian Installer codebase is more in a convergence process. Its base will have almost not changed between squeeze and wheezy. That allowed the Debian Accessibility team to continue improving its accessibility support, and not have to re-do it. A wiki page explains how to test its accessibility features, and some non-debian-accessibility people do go through it. A problem I am much more frightened by is the manpower in some core teams. The Debian Installer, grub, glibc, Xorg, gcc, mozilla derivatives, When reading the changelogs of these, we essentially keep seeing the same very few names over and over. And when one core developer leaves, it is very often still the same names which appear again to do the work. It is hard to believe that there are a thousand DDs working on Debian. I fear that Debian does not manage to get people to work on core things. I often hear people saying that they do not even dare thinking about putting their hands inside Xorg, for instance. Xorg is complex, but it seems to me that it tends to be overrated, and a lot of people could actually help there, as well as all the teams mentioned above. And if nobody does it, who will? Raphael: Do you have wishes for Debian Wheezy? Samuel: That is an easy one Of course I wish that we manage to release the hurd-i386 port. I also wish that accessibility of gnome3 gets fixed enough to become usable again. The current state is worrying: so much has changed that the transition will be difficult for users already, the current bugs will clearly not help. I also hope to find the time to fix the qt-at-spi bridge, which should (at last!) bring complete KDE accessibility. Raphael: Is there someone in Debian that you admire for their contributions? Samuel: Given the concerns I expressed above, I admire all the people who do spend time on core packages, even when that is really not fun everyday. Just to alphabetically name a few people I have seen so often here and there in the areas I have touched in the last few years: Aur lien Jarno, Bastian Blank, Christian Perrier, Colin Watson, Cyril Brulebois, Frans Pop, J rg Jaspert, Joey Hess, Josselin Mouette, Julien Cristau, Matthias Klose, Mike Hommey, Otavio Salvador, Petr Salinger, Robert Millan, Steve Langasek. Man, so many things that each of them works on! Of course this list is biased towards the parts that I touched, but people working in others core areas also deserve the same admiration.

---

Thank you to Samuel for the time spent answering my questions. I hope you enjoyed reading his answers as I did. Note that older interviews are indexed on wiki.debian.org/PeopleBehindDebian.

Subscribe to my newsletter to get my monthly summary of the Debian/Ubuntu news and to not miss further interviews. You can also follow along on Identi.ca, Google+, Twitter and Facebook.

3 comments Liked this article? Click here. My blog is Flattr-enabled.

Still waiting for mine - though I did buy a case for when it comes. News from www.raspberrypi.org - the prototype submitted for EMC testing has apparently passed, though the paperwork has to be validated (blog posting).
It has passed CE marking, FCC part 15 marking, Canadian certification and the Australian C-Tick scheme. There is also an updated trademark policy at new trademark rules ( http://www.raspberrypi.org/trademark-rules ) and a video over at the Farnell/Element14 website from Eben Upton detailing how to set up the Raspberry Pi, shots of booting, explanations of how to use an editor, compile a first Python program and how to build the graphics demos provided. ( http://www.element14.com/community/docs/DOC-44459 )

So, the vote is over, and Stefano won. During many past DPL elections, I've made my vote public, and this one is no different:

V: 1223 		597c362e6156ec7e37b334837161da26

That's me, in this list. Obviously I wouldn't run if I'm not serious about it, so I voted myself first. As to the other part: I thought long and hard about that, but eventually came to the conclusion that both Stefano and Gergely had properties as a candidate that I liked, and properties that I didn't like, and that therefore I couldn't prefer either of them over the other. I found Gergely's platform to be fairly similar to my own, which is a good thing; but there were a few details that made me have some pause about his candidacy. And while I stand by the things I said during campaigning about Stefano as a DPL, the truth is that the project could be far worse off than to have him re-elected. As to the outcome... I can't say it's entirely unexpected. I knew it was a long shot even before I started, and then campaigning didn't excactly go as I would have hoped. I expected to lose, but not by such a margin what Stefano did wasn't winning, it's called 'trashing the opposition'. Congratulations, zack, for a truly exceptional performance; and thanks, also to Gergely, for being a worthy opponent. In closing, I'll say that I don't think I'll run again. I've gone through the process three times now, and have never gotten very close to winning; this probably means that what I feel about the position of DPL is somewhat removed from what the project as a whole thinks about it. So, absent some radical changes in either the project itself or in the way I look upon it, another candidacy from me is highly unlikely. I guess I'll have to find other ways to spend my time...

another weekend, another RCBW report:

• #387756 crack-common: "crack: Do not expect the /var/run/ content to persist"
  apply patch from Georgios M. Zarkadas, upload to DELAYED/2
• #655329 src:libperl5i-perl: "libperl5i-perl: FTBFS: Failed test at t/utf8.t line 23"
  add patch from upstream git (pkg-perl)
• #655844 quassel-core: "quassel-core: fails to upgrade from squeeze"
  fix preinst script, upload to DELAYED/2
• #664939 src:egenix-mx-base: "egenix-mx-base: FTBFS with Python 2.7.3: ImportError: cannot import name customize_compiler"
  add patch from Ubuntu / Colin Watson, upload to DELAYED/2
• #665083 src:kdepim: "kdepim: FTBFS: cp: cannot stat debian/tmp/usr/lib/libakregatorinterfaces.so.4.6.0': No such file or directory"
  send patch to the BTS
• #666278 src:polybori: "polybori: FTBFS: mv: cannot stat debian/python-polybori2.7/*': No such file or directory"
  add build-arch target in debian/rules, upload to DELAYED/2
• #666279 src:ulogd: "ulogd: FTBFS: cp: cannot stat ./debian/tmp/usr/lib/ulogd/ulogd_SQLITE3.so': No such file or directory"
  add patches from from Ubuntu / Clint Byrum, upload to DELAYED/2, then integrated into an NMU by bubulle that adds debconf translations
• #666283 src:proftpd-mod-msg: "proftpd-mod-msg: FTBFS: mod_msg.c:314:5: error: format not a string literal and no format arguments [-Werror=format-security]"
  add patch to add missing format string, upload to DELAYED/2
• #666284 src:avbin: "avbin: FTBFS: make[1]: *** No rule to make target Makefile.'. Stop."
  sponsor NMU by Sebastian Ramacher, upload to DELAYED/2
• #666285 src:garlic: "garlic: FTBFS: cp: cannot stat ./garlic': No such file or directory"
  add build-arch target in debian/rules, upload to DELAYED/2
• #666295 src:scotch: "scotch: FTBFS: cp: cannot stat debian/tmp/int/bin/scotch_esmumps': No such file or directory"
  fix target dependencies in debian/rules, upload to DELAYED/2
• #666296 src:scmxx: "scmxx: FTBFS: cp: cannot stat debian/debian_provider_logo.bmp': No such file or directory"
  add build-arch target in debian/rules, upload to DELAYED/2

All aboard the Choo Choo train! As some of you know, we are planning our trip on the Trans-Siberian (well, Trans-Mongolian to be exact) railway, at the moment. Given the wall of text my post about Svalbard turned out to be, I am trying to split early and often. The plan Our three-week itinerary is pretty much fixed, by now:

• Fly to Moscow, tour the city
• Take the train to Novosibirsk, tour the city and industrial area (if anyone knows of good photo opportunities, do let me know! Novosibirsk is supposedly incredible if you know where to look... and I don't...)
• Take the train to Irkutsk, continue to Listvyanka near Lake Baikal, scuba dive, maybe take train around Lake Baikal just because
• Take the train to Ulan Bator, tour Mongolia for five days
• Take the train to Beijing, visit usual places, have chinese candy
• Take the train to Shanghai, marvel at skyline at night, visit one of the water cities nearby
• Fly back home

Visa issues Not wanting to just book any random package with any random travel agent, we are picking and mixing our own, as usual. Given visa requirements, language barriers and things that are plain weird, it's been an interesting ride before we even pack our bags a month or two from now. Being European, visas are something that do not concern us a lot, normally. I am starting to realize how incredibly lucky we are... barring India, we never needed to do much to be allowed to enter any foreign country. Not so on this trip... While Mongolia has rather lax, or let's just say reasonable, terms, China and Russia are different. To get a visa for Russia, you need:

• Passport, valid for at least six months after your planned departure
• Photo, not older than six months
• Personal invitation (you simply buy those from agencies within Russia)
• Voucher from an accredited travel agency
• Detailed itinerary
• Proof of health insurance for exact time of stay, i.e. dates of entry and departure; make it too long and you may have trouble getting your visa
• Copy of one of the following:
  • Current pay slip
  • Bank statement
  • Registration of real estate
  • Registration of company in your name

For China, you need to provide a night-to-night itinerary of hotel stays. This may be a remnant of Mao's philosophy of restricting free movement of the population within China, I don't know. On the plus side, they don't require an invitation, health insurance or means of industrial espionage. With processing times ranging from one to four weeks per visa, you will wait one to two months until your passports are back with you and properly visa'ed by everyone. Tickets, please Purchasing tickets in advance, but not through a travel agent, is turning out to be rather complicated. As you can not book train tickets with RZD, the Russian rail company, more than 45 days in advance, you end up with nice circular dependencies. We could pay a premium for faster processing of our visas and buy via travel agencies which sell train tickets from their special contingents, but that's kinda boring, innit? Also, rzd.ru offers Russian order forms, only. With the help of Google translate, ##russian on irc.freenode.net, and a lot of guess-work, we were able to hammer out the connections from Moscow to Novosibirsk and from there on to Irkutsk. Yet, it's quite a different experience not to not be able to fall back to English. No matter where we went in the past, English was the lingua franca, at least to some extent. That's not the case in any of our three intended destinations so those phrase books will get used a lot, I suspect... We are still not sure if the 4-people cabins in second class have a door, let alone one that can be locked, but we decided that this is not too much of an issue. Generally speaking, people are nice and there are train attendants so crime should not be an issue. And even if things do disappear, as long as we stay healthy and I still have one of my several copies of all photos I will take, I will be reasonably happy. As to getting from Irkutsk to Ulan Bator... even a Russian travel agent we contacted claimed you can only purchase tickets on site, not online. From Ulan Bator to Beijing, it's a different booking system. And from Beijing to Shanghai, it's yet another one. This is the most fragmented booking process we ever went through. Other than a few moments of stress and frustration, the hunting for information, cross-referencing and having the occasional eureka moment is tons of fun, though; no complaints here. When in Rome... According to Lonely Planet, the Trans-Siberian is more or less one large picnic where everyone shares whatever they have with them with everyone else. I poked a few Russians about what typically German food they like and they came up with Frankfurters, mustard, and beer. Guess that's what we will be stuffing our backpack with once everything else is packed. And snuff; apparently it's common courtesy to offer your snuff to other men you meet in Mongolia and then snuff from their bottle. When in Rome... German snuff tends to be mixed with menthol, I suspect that will raise some eyebrows ;) No idea if there is any non-obvious social grease to bring to China; still working on that. Initially, we wanted to tour Mongolia's main attractions, but we would either have to sit in a car for days on end or go by plane. Driving for days in between a solid week(!) spent on trains is not very appealing and neither is breaking our personal ground travel record by cheating flying. Thus, we decided to take the eco-tourism route: After a two-hour orientation course in Mongolian behaviour and manners, we will travel a few hundred kilometers by public bus, be picked up by a local, driven out into the outback and ride from ger to ger by camel and horse before returning to Ulan Bator by bus. The stays at the gers are immersive, if short; we will live with the families, help them do their daily chores, and visit local places of interest in between. Oddly enough, I am looking to forward to the bus ride even more than to the gers. At the gers, at least one person is able to speak basic English. Not so with the local bus. People on the various trains will be used to strangers, as are the families at the gers. People on the bus are, most likely, not. Communicating with hand, foot, phrasebook, and a smile will, hopefully, be a lasting experience. If time permits, we will try to visit kiva.org borrowers while in Ulan Bator; this is something we never had a chance to do before and it's been on the bucket list for some time, now. As an aside, the local agent in Mongolia asked us if our sleeping bags are rated down to -26 degrees Celsius. I do hope he was joking... On the privileges of living in a first-world country... Travelling by horse means travelling light. Not a problem for us as we pack light by default and still manage to bring everything from Swiss Tool to water bottles, zip ties, medkit, and everything in between. Still, there's one major thing I have been taking for granted all my life: electricity. Being without any source of power for four to five days is... challenging. Even more so as every single gadget I rely on uses a different type of battery. Flashlight: CR123A and AA; GPS: Ni-MH AA rechargeables and Lithium AAA primaries respectively; Laptop, cameras, cell phone, ebook reader, Nintendo DS and MP3 player: proprietary. I am starting to truly understand why NATO has a hard rule of allowing AA-powered devices, only; planning spares is a pain. Obviously, I am focusing on flashlights, GPS, and, above all, cameras. Battery grips with AA adapters to the rescue! Another even more unsettling realization came when I asked if it would be possible to have boodog (vegetarians/vegans: don't click). Mongolians do not usually prepare boodog in spring as the animals which survived the harsh winter need to fatten and breed before being killed for food. All my life, I have never even once considered the remote possibility of not being able to slaughter domesticated animals due to outside constraints. Mongolian nomads need their animals. This is not about wanting to do things one way or another; this is about survival. Quite fascinating, and humbling, to think about. I am incredibly privileged and, as you are reading this, so are you. An exercise for the reader If you have any information regarding:

• Good places to see in and around Novosibirsk in one day
• Social grease and tips, especially regarding China
• Getting from Irkutsk to Ulan Bator
• Reliable solar chargers for Ni-MH AA batteries
• Interesting things I didn't mention in this post

please let me know. As usual, but just a little bit more than usual, comments are appreciated.

Two weeks ago, I was at LOAD, where I did a tutorial on Debian Packaging. Unfortunately, I wasn't doing very well physically, and as a result my preparation wasn't what I had hoped for. It ended up being not so much a tutorial as a walking the audience through packaging a piece of software in casu NBD with debhelper in dh mode. Not very difficult, but since there's nothing for people to fall back on afterwards, it may help if they have a writedown of what I said during the session; and I promised to put it on my blog. So, here goes. However, note that the canonical written tutorial on Debian Packaging is here. With apologies to readers of Planet Debian, most of whom for which all this is probably old hat. Unlike RPM packaging, in Debian, the data that tells the debian packaging system how to package a piece of software is functionally split among a number of files. All these files go in a toplevel directory in the source package, (unsurprisingly) called 'debian'. There are four files that are required for every Debian package: the control, changelog, copyright, and rules files. Without these files, dpkg-dev will fail to produce a package any package. The first, the control file, contains metadata on packages: the name of the package, its description, the dependencies, etc. Basically, almost all the information you see when you run 'apt-cache show <package>' (with one exception) is in the control file. If you have a source package that builds multiple binary packages, then you should have multiple 'Package' stanzas in the control file. In my opinion, creating a control file is easiest done by copying a control file from another (similar?) package, and modifying it to suit the software you're dealing with. The one exception, the one bit of metadata that is not found in the control file is the version number: this data is contained in the changelog file. This file looks like a free-form file for the most part, but it really is a machine-parsable format; as such, it's best to edit it with specialized tools, such as the debian-changelog-mode in the emacs editor, or the debchange script, also available as dch, from the devscripts package. In the changelog, you should document any changes you make to the package, making sure the version number (top line), distribution (unstable, experimental, stable, ...; top line), urgency (top line; used mainly when testing needs to be updated urgently for things like security updates), author (bottom line) and date and time (also bottom line) are correct. The copyright file, unsurprisingly, should contain the copyrights statements of the original software, and the license (or a reference to a copy of the same license text under /usr/share/common-licenses). This file is still free-format in most packages today, although a machine-readable format for this file has recently been defined. Of the four required files, this is probably the most boring one, but hey, we can't like everything we do. The last file, the rules file, is where all the action happens. This file is defined as a Makefile, of which the targets are called for various parts of the build system. The rules file has a number of required targets (such as build, clean, and others), but if you're using debhelper in dh mode, you don't need to worry about those; instead, you can use the following simple rules file:

#!/usr/bin/make -f
%:
	dh $@

With the first line, the shebang, we make clear that this is a makefile, and that it should be called by make. The next is a generic target (the % is a wildcard for make), with just one command: 'call dh with the name of the target being called'. Since dh implements all required rules targets, that immediately gets you a working package. Go ahead, try! Run 'dpkg-buildpackage -rfakeroot', and see what happens. Did that work? Maybe, maybe not. First, you'll have seen loads of warnings about something involving a "compatibility level". This is from debhelper; this compatibility level, or 'API level' if you wish, allows debhelper to move forward and make incompatible changes without breaking all the existing packages out there; whenever the compat level is bumped, some new functionality will only be made available if you also raise the compat level in your source package (and then you'll know you may have some changes to do in your package). Since the original debhelper, over a decade ago, did not have a compat level, the absense of a compat level signals compat level 1, which is far outdated now, and about to be unsupported. Hence the warning. The fix is simple: create a file debian/compat containing a single number: the compatibility level you're working with. It's best to use the most recent level which debhelper supports when you create your package, which as of this writing is level 9. Ignoring the compatibility level, if you're building a software package which uses a well-established build system, and you only build one binary package out of that, chances are pretty high that everything worked as expected. If not, you'll have more work. Building multiple packages requires that you tell debhelper somehow which file goes in which package. You can do this with a file debian/package.install, where package is the name of the binary package you're building. The install file is read by dh_install, one of many tools in the debhelper suite. You see, in the old days (before debhelper 7), debhelper was just a suite of tools, which required that you wrote a debian/rules file containing all the individual tools to be called in the correct order. This mode is still supported; in fact, even if you do use dh, you do, since all that tool really does is call the right tools in the right order; the real work is done by the invidual tools. They all have their own man page; to understand how dh_install chooses which file to put in which package, go read man dh_install. Go ahead, do it now; I'll wait. Back? Good. You've now learned that dh_install can install files either from the source directory (useful for packages containing only scripts or so), or from a directory debian/tmp. If you use an autotools-based software package, this is what dh will do for you. When you called dpkg-builpackage above, you may also have noticed that the output contained many lines starting with dh_, one of which said dh_install. As you may have guessed, dh echoes every debhelper command just before it will execute them. This allows you to look at the output, and see what's happening. For more detail, set the environment variable DH_VERBOSE to a non-zero value. I'm sure you'll have seen one or two debhelper tools that could make your package better. Go ahead, go and read their man pages to see what they do, and how they do it. Most of these will require you to create a file debian/package.toolname to specify details. In some cases, you may need to specify command-line arguments to the tool to get it to do what you want. In yet other cases, the tool won't support what you need it to do, and you'll have to do something manual. What to do now? The dh command line doesn't support adding extra commands easily. Does this mean you'd have to revert to old-style long, non-dh debian/rules files? Luckily, no. You can create an override target. If dh detects that you have such a target for a particular tool, it will call that target instead of the tool. This target's rules can then call the tool in question (or not), and add any command line arguments, or extra commands, as needed. An override target is a normal Makefile target with a name of the form override_dh_something, where dh_something is the name of the tool you wish to override. At this point, I'd reached almost the end of my two allotted hours, and a member of the audience asked how to make dpkg deal with configuration files. The answer is, you don't need to do anything! Not if you use debhelper, anyway; all you need to do is install the file in /etc. Since debian policy specifies that all files in /etc need to be configuration files and that no conffiles may be placed anywhere but in /etc, debhelper will automatically mark any file installed in /etc as a conffile, which will cause dpkg to ask the user what to do with changes to such files. Note that in Debian parlance, a conffile is not the same thing as a configuration file: a conffile is a configuration file that is part of the binary package (i.e., if you call 'dpkg --contents' on the .deb file, you'll see it in the output), whereas a configuration file is a file (any file, including files generated during or after installation of the .deb file on a system). Occasionally, this is also why some differences to configuration files are managed through debconf, while others aren't: the ones managed through debconf are non-conffile configuration files managed through ucf, whereas the others are conffiles. So in the simplest of cases, if you want to install a configuration file and you want to make sure it's protected against accidental overwrites by package upgrades, all you need to do is make sure it's installed to /etc; debhelper will do the rest. And that concludes this introduction. Please note it's only an introduction, not a full-blown tutorial; while this will allow you to get started, you may have to learn a bit more if you wish to eventually upload a package to Debian.

A few years ago I started to run my own server. This was an interesting challenge back then but today I only consider it a waste of time and money. Therefore I'm searching for (a) service provider(s) to substitute my self hosted applications:

• mail server with IMAP, Spamfilter, webmail
• private/public Git hosting
• (sharable) file hosting
• blog
• photo gallery
• wikis
• mailing lists
• online address book, calendar
• feed reader

However I'm a bit insane about privacy, security and reliability. I simply want to be able to TRUST. This rules out IMHO: Google, Github, Yahoo. On the other hand I'd probably be prepared to pay an insane monthly fee for a provider that just keeps me happy.

I'd love to here your recommendations! I'm especially interested in providers that are organized as cooperatives and care about environmental issues.

Do I need to mention free software? An extra plus would be a healthy distaste for PHP.

some cooperative-style provider initiatives that I still need to evaluate:

• immerda.ch
• riseup.net
• jpberlin (mail, lists)
• ecobytes.net
• mayfirst.org
• hcoop.net
• tuxfaily.org
• more ...

I ve been getting a lot of spam recently from people wanting to write guest posts or have their site included in a future links post. Guest Posts For guest posts the social convention for the planets which aggregate my blog seems to be that random guest posts are unacceptable. I could change my blog feed to have some posts excluded from the planet feeds but that s too much effort and I don t want random guest posts anyway. The only situations in which I will accept guest posts are when someone is writing what I might have written (IE they generally agree with me) or if they are a member of the free software community who doesn t have their own blog but has something relevant to say. Any applicant for a guest post who runs a business that is useless and/or evil IMHO (EG anything related to the TSA) is going to get rejected firmly. Any applicant who tells me that they can write on a wide variety of topics probably isn t capable of making me an offer that I would accept. Tell me that you can write about Linux programming or computer security and I ll be interested, but you have to provide links to your previous work. An application to write a guest post that starts with something like I liked your recent post at the above URL but I think you missed some important points, as I have some experience in that field I think I could write a guest post that would help educate your readers may be accepted. Probably the best thing to do however is to write comments on my blog, if you can write informative comments and offer to make a longer comment into a guest post then there s a good chance that I ll be interested. Generally though I will only offer the opportunity to write a guest post to someone who writes something really informative in private email or on a closed mailing list. If you can solve a technical problem about Linux that has me stumped then I will almost certainly be willing to accept a guest post about it! Links Posts There are many sites which consist of nothing but links to other sites. In the 90 s such sites were really useful but since the rise of Google their value has declined dramatically. As an aside when I ran an Internet Cafe in the 90 s I had every web browser start with the main page of my Hot Stuff list, the purpose of this was to increase the hit rate of my Squid cache by having most of the customers visit the same sites. Even back then I probably wouldn t have bothered if it wasn t for Squid hits. It must seem like an easy way to make money to create pages of links to articles with short summaries and then hope for advertising revenue, a domain sale, or the launch of some sort of profitable business once people start using the site. I wonder whether that ever works out for people. It doesn t seem like a good business model, doing something that requires little skill, which can be done by almost anyone, and which is done by many people. Maybe there are sweat-shops dedicated to this. Anyway my links posts are unlikely to ever link to any such links pages, I don t think that the people who read my blog want double indirection. I won t entirely rule out linking to a links page, but it would have to be of very high quality and related to something very technical about computers. Basically anyone who reads this should give up on the idea of submitting a links page to me, if it s good enough to make me break my policy of not linking to such things then I ll probably find it myself. Conclusion As a general rule if you want someone to publish your work then you need to look at what they are publishing and make sure that your work fits. With the recent requests for links and guest posts I ve been getting I have to wonder whether the people making the requests have even read my blog. That method of operating is unlikely to give any success at a blog that has any reasonable number of readers. I ll probably link to this from my about page or something. It might discourage some of the spammers. Related posts:

1. Link Within Good Things about LinkWithin For the last 10 weeks I ve...
2. Feedburner Item Link Clicks For a while I used the Item Link Clicks feature...
3. Can you run SE Linux on a Xen Guest? I was asked Can you run SELinux on a XEN...

It has taken a decade to get there, but finally the buildds are able to call debian/rules build-arch. Compare the unfinished old build

 Finished at 20120228-0753
 Build needed 22:25:00, 35528k disc space

with the new one on the same architecture finally only building what is needed

 Finished at 20120404-0615
 Build needed 00:11:28, 27604k disc space

This is my monthly summary of my Debian related activities. If you re among the people who made a donation to support my work (227.83 , thanks everybody!), then you can learn how I spent your money. Otherwise it s just an interesting status update on my various projects. Dpkg Thanks to Guillem, dpkg with multiarch support is now available in Debian sid. The road has been bumpy, and it has again been delayed multiple times even after Guillem announced it on debian-devel-announce. Finally, the upload happened on March 19th. I did not appreciate his announce because it was not coordinated at all, and had I been involved from the start, we could have drafted it in a way that sounded less scary for people. In the end, I provided a script so that people can verify whether they were affected by one of the potential problems that Guillem pointed out. While real, most of them are rather unlikely for typical multiarch usage. Bernhard R. Link submitted a patch to add a new status command to dpkg-buildflags. This command would print all the information required to understand which flags are activated and why. It would typically be called during the build process by debian/rules to keep a trace of the build flags configuration. The goal is to help debugging and also to make it possible to extract that information automatically from build logs. I reviewed his patch and we made several iterations, it s mostly ready to be merged but there s one detail where Bernhard and I disagree and I solicited Guillem s opinion to try to take a decision. Unfortunately neither Guillem nor anyone else chimed in. On request of Alexander Wirt, I uploaded a new backport of dpkg where I dropped the DEB_HOST_MULTIARCH variable from dpkg-architecture to ensure multi-arch is never accidentally enabled in other backports. One last thing that I did not mention publicly at all yet, is that I contacted Lennart Poettering to suggest an improvement to the /etc/os-release file that he s trying to standardize across distributions. It occurred to me that this file could also replace our /etc/dpkg/origins/default file (and not only /etc/debian_version) provided that it could store ancestry information. After some discussions, he documented new official fields for that file (ID_LIKE, HOME_URL, SUPPORT_URL, BUG_REPORT_URL). Next step for me is to improve dpkg-vendor to support this file (as a fallback or as default, I don t know yet). Packaging I packaged quilt 0.60 (we re now down to 9 Debian-specific patches, from a whopping 26 in version 0.48!) and zim 0.55. In prevision of the next upstream version of Publican, I asked the Perl team to package a few Perl modules that Publican now requires. Less than two weeks after, all of them were in Debian Unstable. Congrats and many thanks to the Perl team (and Salvatore Bonaccorso in particular, which I happen to know because we were on the same plane during last Debconf!). On a side note, being the maintainer of nautilus-dropbox became progressively less fun over the last months, in particular because the upstream authors tried to override some of the (IMO correct) packaging decisions that I made and got in touch with Ubuntu community managers to try to have their way. Last but not least, I keep getting duplicates of a bug that is not in my package but in the official package and that Dropbox did not respond to my query. Book update The translation is finished and we re now reviewing the whole book. It takes a bit more time than expected because we re trying to harmonize the style and because it s difficult to coordinate the work of several volunteer reviewers. The book cover is now almost finalized (click on it to view it in higher definitions): We also made some progress on the interior design for the paperback. Unfortunately, I have nothing to show you yet. But it will be very nice and made with just a LaTeX stylesheet tailored for use with dblatex. The liberation fundraising slowed down with only 41 new supporters this month but it made a nice bump anyway thanks to a generous donation of 1000 EUR by Offensive security, the company behind Backtrack Linux. They will soon communicate on this, hopefully it will boost the operation. It would be really nice if we managed to raise the remaining 3000 EUR in the few weeks left until the official release of the book! The work on my book dominated the month and explains my relative inactivity on other fronts. I worked much more than usual, and my wife keeps telling me that I look tired and that I should go in bed earlier but I see the end of the tunnel: if everything goes well, the book should be released in a few weeks and I will be able to switch back to a saner lifestyle. Thanks See you next month for a new summary of my activities.

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

due to some new incoming RC bugs, this week was more devoted to fixing bugs in "our" (= the Debian Perl Group's) packages. here's the list:

• #641816 libmusicbrainz3-dev: "libmusicbrainz3-dev should depends on libneon25-dev and libdiscid"
  add missing dependencies, upload to DELAYED/2
• #646649 src:libio-async-loop-epoll-perl: "libio-async-loop-epoll-perl: FTBFS: Failed 1/8 test programs. 1/86 subtests failed."
  upload with patches from Niko Tyni (pkg-perl)
• #656791 approx: "approx: should depend on system-log-daemon"
  add missing dependency, upload to DELAYED/2
• #661799 libcvs-perl: "libcvs-perl: FTBFS"
  upload with patch from Niko Tyni (pkg-perl)
• #663052 leds-alix-source: "leds-alix-source: module fails to compile"
  apply patch from Federico Brega, upload to DELAYED/2
• #663567 wxglade: "wxglade: FTBFS: ImportError: No module named wx"
  send patch to the BTS
• #665233 src:libanyevent-perl: "libanyevent-perl: FTBFS: tests failed"
  upload patched package prepared by Alessandro Ghedini (pkg-perl)
• #665388 src:libperlbal-xs-httpheaders-perl: "libperlbal-xs-httpheaders-perl: FTBFS: C code doesn't load reliably"
  add patch, upload package prepared by Jonathan Steinert (pkg-perl)
• #666292 src:libmecab-perl: "libmecab-perl: FTBFS: MeCab_wrap.cxx:1826:16: error: 'mecab_node_t' has no member named 'sentence_length'"
  upload new upstream version (pkg-perl)
• #666369 src:fbcat: "fbcat: FTBFS: doc/fbcat.1: No such file or directory at /usr/bin/dh_installman line 127."
  fix targets in debian/rules, upload to DELAYED/5, then fixed earlier in a maintainer upload
• #666581 src:latexdiff: "latexdiff: FTBFS: ! LaTeX Error: File ulem.sty' not found."
  finish and upload package with fix prepared by David Bremner (pkg-perl)
• #666638 src:libcpan-mini-perl: "libcpan-mini-perl: FTBFS: test failed"
  use writable HOME during build (pkg-perl)

Review: Agile Project Management with Scrum, by Ken Schwaber

Publisher:	Microsoft
Copyright:	2004
ISBN:	0-7356-1993-X
Format:	Trade paperback
Pages:	153

Ken Schwaber is one of the two original developers of Scrum and one of the signatories to the Agile Manifesto. Agile Project Management with Scrum is an introduction to Scrum by him that feels aimed primarily at business people (project managers, executives, line managers) rather than at technical people. There's very little about agile software development in general; the emphasis is on business process, team organization, and how the Scrum process looks to the rest of the organization. After an introductory chapter laying out the basics of Scrum, the remainder of the book is primarily case studies. Schwaber presents some principle and then discuss an anonymized case study that illustrates the principle. Each major Scrum role (ScrumMaster, Product Owner, and Team Member) gets their own chapter, interspersed with chapters on planning, reporting, and scaling. Finally, there are some concluding appendices laying out the rules of Scrum in more detail, adding a brief (and very disappointing) discussion of fixed-term, fixed-price contracts, and providing some other supplemental information. This is only the second regular book that I've read about Scrum, but my reading has been a bit out of order. We've been using Scrum for various projects for about a year and a half, I've played both team member and product owner roles, and we've been thinking hard about how to integrate Scrum more into the way we do development. My impression of this book is that it's intended as more of an introduction for people who aren't yet comfortable with Scrum or who are still struggling to make the pieces fit together. I'm therefore possibly not the target audience. Much of this book is a rehash of things someone who has studied Scrum will already know. I'm of two minds about the case study presentation style of this book. On one hand, it does help to make the points Schwaber discusses more concrete, and it's difficult to talk about business process in any other way. They're also more interesting and engaging than Schwaber's straight rule descriptions. But I had difficulty digging into most of the ones here. They're very simple and a little shallow, and I had trouble applying many of them to practical situations I might be in. I would have liked somewhat more detailed stories with more analysis and possible alternatives within the situation, rather than simple illustrations of how Scrum solves the problem that Schwaber had just said it would solve. What I did like about this book is that it provides the background and theory of Scrum as empirical process control much more clearly than any material I'd previously read. Schwaber is good at explaining what empirical process control is and why it's a superior approach, and he gave me new vocabulary and basic concepts to use to talk about Scrum. I also liked the high-level look from a management perspective without getting into the details of story points and velocity estimation (Schwaber doesn't use them at all in this book, relying instead on traditional "days of work" estimates). Much of my previous experience with Scrum was tightly focused on its advantages for estimation and responsiveness to changes, and it's nice to see some of the other advantages of Scrum (developer job satisfaction, improved focus, incremental deployment) highlighted more. Another part of this book I appreciated was the discussion of sprint length. Schwaber doesn't go into the possible alternatives, largely assuming that a month is the best interval, but the discussion of the impact and implications of a month sprint length helped me see the advantages of longer sprints. (To date, we've been doing either one week or two week sprints.) I came away with the feeling that a hybrid model where longer sprints are used for business purposes and then subdivided into shorter sprints for developer coordination might be particularly effective, although that's not an idea that Schwaber presents. This is not a particularly compelling read, particularly if, like me, you're not a huge fan of genericized case studies. Schwaber's writing is clear, but wooden and occasionally awkward, and the book is often dry. But it talks about Scrum from a management angle instead of a developer angle, which is an additional perspective that I found valuable. Possibly worth taking a look if you want more detail about Scrum from a high-level management perspective, although I don't think you're missing a lot by not reading it. Rating: 6 out of 10

zfsonlinux recently added support for visible .zfs snapshot directories, so you no longer have to mount a snapshot to browse/view/recover files from it. This is good, but has caused my rsync backup to zfs script to complain about being unable to delete files in the .zfs directory (which is in the backup but not in the source). e.g.

sending incremental file list
rsync: delete_file: unlink(.zfs/snapshot/2012-03-31/vmlinuz.old) failed: Read-only file system (30)
rsync: delete_file: unlink(.zfs/snapshot/2012-03-31/vmlinuz) failed: Read-only file system (30)
[...]
cannot delete non-empty directory: .zfs/snapshot/2012-03-31
rsync: delete_file: rmdir(.zfs/snapshot/2012-03-31) failed: Device or resource busy (16)
rsync: delete_file: unlink(.zfs/snapshot/2012-03-30/vmlinuz.old) failed: Read-only file system (30)
rsync: delete_file: unlink(.zfs/snapshot/2012-03-30/vmlinuz) failed: Read-only file system (30)
[...]

The solution is to tell rsync to ignore .zfs directories on the destination. 1. use the -F option to make rsync use /.rsync-filter
2. create or add the following line to /.rsync-filter

-r .zfs/***
-s .zfs/***

On the first line, the - makes it an exclude rule, and the r indicates that the rule applies to the receiving side. Together, -r prevents rsync from attempting to delete the .zfs directories On the second line, the -s indicates that the rule applies to the sending side, preventing rsync from trying to backup any .zfs snapshot directories. This is only useful when backing up a ZFS filesystem. rsync and .zfs snapshot directories is a post from: Errata

OK, this is not another post on how to use Mutt and Gmail. This is just to comment on a feature I found in Mutt that was not obvious, and that helped me to stop running my own anti-spam tool. So, for a number of reasons, my company stop filtering spams. I was setting up dspam to take over that job when I decided that it was just too much pain for a single account. Besides, although I am spammed a lot, I would never possibly be more efficient than Gmail anti-spam, given the load of emails their users classify everyday. I am not migrating my old emails over to Gmail, though. And I am pretty comfortable with my current email work-flow I am simply not going to use a webmail (even one as powerful as Gmail). OK, I am using GNOME 3 after being a Fluxbox and Bluetile user, but everything has a limit But how to keep the best of both worlds? And, more important, how to do that with minimum disruption of what I already have (my own IMAP server and Mutt managing my account there as spoolfile)? The answer is a little known trick using the mailboxes directive in .muttrc. This directive accepts a fully-qualified imap mailbox address. So I just added something like: and added some shortcuts to save email from my inbox to that mailbox (the same as train-as-spam) and to rescue email from it (the same as train-as-ham): and that was it. In my IMAP machine I got a fetchmail downloading emails from Gmail s INBOX so I can get trained-as-ham and new emails (all emails arrive first in my Gmail account) into my IMAP server. All my sieve rules are in place and nothing changed in my email work-flow. It s been working flawlessly for a week now. The only drawbacks are (1) Gmail knowing everything that arrives to me (not a big deal, since unencrypted emails aren t private anyway), and (2) not getting the spam-count once Mutt is run: I have to change into that mailbox to log-in to Gmail. Update: Mar 30, 2012 @ 18:15: I just found out that drawback number (2) above can be fixed by adding the following to .muttrc:

thanks to lucas' last archive rebuild, this week offered some new & easy additional RC bugs :) here's the list:

• #646177 src:python-djvulibre: "python-djvulibre: FTBFS: FAIL: test_decode.test_documents.test_export_ps"
  add patch from upstream repo, upload to DELAYED/2
• #651317 src:pike7.8: "pike7.8: FTBFS on i386: Segmentation fault"
  send debdiff with patch from Ubuntu / Matthias Klose to BTS
• #656669 gedit-latex-plugin: "gedit-latex-plugin: FTBFS due to latex/latex/environment.py not in POTFILES.in"
  add patch from Ubuntu / Mathieu Trudel-Lapierre, upload to DELAYED/2
• #660379 libchart-perl: "libchart-perl 2.4.4 breaks the return value of scalar_png()"
  upload package prepared by Florian Schlichting (pkg-perl)
• #662585 qd: "FTBFS"
  add patch to fix a Makefile.am variable, upload to DELAYED/2
• #662764 sagan: "sagan: FTBFS: dh_auto_configure fails"
  fix configure call in debian/rules, upload to DELAYED/2
• #663063 python-gtkglext1: "python-gtkglext1: FTBFS: dh_autoreconf: Can only be run once"
  add a new target to debian/rules to run dh_autoreconf, upload to DELAYED/2
• #665076 velocity: "velocity: /usr/share/java/velocity.jar missing"
  triage and reassign
• #665219 src:libpadre-plugin-perlcritic-perl: "libpadre-plugin-perlcritic-perl: FTBFS: tests failed"
  set HOME during build (pkg-perl)
• #665228 src:libconfig-model-perl: "libconfig-model-perl: FTBFS: tests failed"
  set HOME during build (pkg-perl)
• #665246 src:liborlite-mirror-perl: "liborlite-mirror-perl: FTBFS: tests failed"
  set HOME during build (pkg-perl)

I first learned that David Hicks had written an autobiography when I saw some press coverage of there being an attempt by the Australian Government to ban the sale of it, so I asked my sister if she could get me a copy for my birthday before any ban happened. The book doesn't appear to be available on Amazon. I sat down and tried to read it almost immediately, but at the time found his writing style to be rather inarticulate, so I put the book down for a month or so. When I next had a platelet donation to make, I took it along with me, and forced myself to read it for duration of the donation. On the second reading, I managed to engage with the book, and from that point on, once I made it through his early years in that initial forced reading session, it ended up being quite enthralling. I plugged my way through the 456 pages in a bit over a month I guess. We'll never truly know the full story of David Hicks, because I'm sure that unless there's some sort of inquiry (and even then, there's multiple country's governments involved), the full story won't come out. I was always sympathetic to Hicks' plight, since I don't believe that anyone should be held without due process let alone for anywhere near as long as he was. Certainly, the way the book reads, Hicks comes across as a very young, naive, but principled individual. Like many Australians, he got the travel bug, and by way of it, got to interact with some different cultures, which awakened a hunger for social justice in him (at least that's my interpretation of his portrayal). I guess I have a different mental image of torture than Hicks did, because I didn't really find any incidences of what I'd consider torture in his story. There was plenty of despicable, inhumane treatment though, so I can see how the line might get blurry, particularly if you're the one experiencing it. Specifically on the (mis)treatment of the detainees: it was pretty bad, based on the book. I'm surprised there haven't been more whistle blowers that have come out. I can't believe that the many soldiers who were stationed there could treat detainees the way Hicks says they were treated and then can look themselves in the mirror. The ICRC seemed well apprised of the detainees conditions (since they seemed to have the most access to them of any non-military people). I don't know what confidentiality is imposed on them in return for that access, though. The fact that he's able to string a sentence together at all after the treatment he describes for the length of time he received it, I think is pretty amazing. I couldn't imagine having to endure what he says he went through. I did feel quite appalled by my own country's complete disregard for his plight, and similarly in the way the US Government treated these detainees for as long as they did. Given there are still 171 detainees in Guantanamo today, it makes me wonder what the conditions and treatment are like there now. It certainly seems to have fallen out of the mainstream press. Overall, not the most well written book, but a fascinating and shocking account of what happened to one person. I think Hicks should be congratulated for the courage to relive his experiences to get them down on paper, and Random House should also be congratulated for publishing his work, which I'm sure put them under some political pressure. I have no idea how well the book has sold, or how widely it has been read, but I certainly recommend it.

Some of my recent time has been devoted to making our boot media more Mac friendly, which has entailed rather a lot of rebooting. This would have been fine, if tedious, except that some number of boots would fall over with either a clearly impossible kernel panic or userspace segfaulting in places that made no sense. Something was clearly wrong. Crashes that shouldn't happen are generally an indication of memory corruption. The question is how that corruption is being triggered. Hunting that down wasn't terribly easy.

My first thought was that we were possibly managing to load the kernel over a region used by UEFI code. UEFI defines two types of code - boot services and runtime services. While runtime services code and data must be preserved by the OS, in theory boot services code and data is available to the OS once the firmware has exited. In practice, that's not true. It seemed entirely possible that the kernel might be ending up on top of some of that boot services code or data and getting trodden on. Grub now has code to avoid putting the kernel on boot services, so testing the latest code seemed like a good plan. But no, crashes still happened.

That pretty much ruled out the bootloader. My next thought was that executing some of the firmware code was triggering a write to some other memory that contained the kernel. Josh Boyer suggested the next trick, which was to try marking the kernel read-only to see whether anything was hitting it. x86 lets you mark pages as read-only - any attempt to write to them should take a fault. UEFI functions are executed in the context of the kernel, so share the same page tables. That let me rule this out, since everything still went just as wrong and I wasn't taking an extra fault first.

However, at this point I was reasonably happy that it wasn't the kernel itself being overwritten - faults were occurring in userspace code as well. That was a pretty strong indication that what was happening was continuing to happen once userspace had started, so it wasn't a direct response to a firmware call. I made sure of that by stubbing out all the calls that could be triggered after kernel initialisation, and saw the same failures. Once all attempts to be clever have failed, it's time to just start using brute force. The kernel lets you reserve areas of RAM by passing arguments like memmap=0xlength$0xstart to block length bytes starting at start from being used. It took a while, but I finally found a 256MB range that made a difference - reserving it resulted in the machine booting reliably, letting the OS use it resulted in occasional crashes.

Definite progress. Comparing that memory range to the EFI memory map was helpful. There were several blocks of UEFI boot services data present there, which really seemed like too much of a coincidence. By reserving each of them in turn, I'd traced it down to a single 31MB region of boot service data - that is, memory reserved by the firmware for use by the UEFI boot services. Per spec, this is available to the OS once the boot environment has been exited. Nothing other than the OS should be touching this after boot, but something clearly was. Tracking down what was far easier than I expected, although the first attempt was a failure. Setting it read-only should have triggered a fault, but didn't. That was rather confusing. But, rather than give up, I patched the kernel to fill the region with 0xff at kernel init. Then I booted the system, read it back and looked for values that weren't 0xff. I got this:

00000000  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff   ................ 
*
001568a0  ff ff ff ff ff ff ff ff  ff ff ff ff 84 00 00 00   ................ 
001568b0  00 20 a7 ac 46 00 00 00  00 00 00 00 00 00 06 01   . ..F........... 
001568c0  c2 0b 0c 00 ff ff ff ff  ff ff ff ff ff ff ff ff   ................ 
001568d0  ff ff 0a 04 f0 03 82 0d  40 00 00 00 ff ff ff ff   ........@....... 
001568e0  ff ff 00 21 00 36 9a 80  ff ff ff ff ff ff 00 7e   ...!.6.........~ 
001568f0  00 09 43 48 41 2d 47 75  65 73 74 01 04 02 04 0b   ..CHA-Guest..... 
00156900  16 32 08 0c 12 18 24 30  48 60 6c 2d 1a 0e 18 1a   .2....$0H l-.... 
00156910  ff ff 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................ 
00156920  00 00 00 00 00 00 00 dd  09 00 10 18 02 00 10 01   ................ 
00156930  00 00 dd 1e 00 90 4c 33  0e 18 1a ff ff 00 00 00   ......L3........ 
00156940  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................ 
00156950  00 00 bd ea f8 b3 ff ff  ff ff ff ff ff ff ff ff   ................ 
00156960  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff   ................ 
*
022fb000

That's a lot of 0xffs (around 31MB of them) with one small section that contains an 802.11 probe packet with the SSID of the hospital across the road from my house. Apple support network booting off wireless networks. It seems that the firmware brought up the wireless card, associated with this network (it's the only public one nearby) and then left the card DMAing packets into RAM. The read-only page attribute only applies to CPU-initiated accesses, so it could do this without triggering a page fault. It also explained why it was so random - whether memory corruption occurred would depend on whether a packet appeared between that memory being used by the OS and the kernel reinitialising the wireless card. It certainly explains why I couldn't reproduce it when I left the machine repeatedly rebooting on the bus home.

How do we fix this? Unsure. With luck disconnecting the UEFI driver in the bootloader should quiesce the hardware, but without testing I'm not sure of that yet. For now it's just another example of firmware managing to break expectations in deeply strange ways.

comments

---

---

Hi,

in this bits:

1. Debian Med Bug Squashing Advent Calendar 2011
2. Anniversary of Debian Med
3. Second Debian Med sprint (Southport, 27th-29th January 2012)
4. Mentoring of Month (MoM)
5. DDs who came to Debian because of Debian Med
6. Future plans
7. General lessons learned
   

Debian Med Bug Squashing Advent Calendar 2011In December last year Thorsten Alteholz has started a nice QA initiative which might be interesting for other teams next Advent. The Debian Med team was able to fix about 70 bugs in this time. Thanks to Thorsten for this nice piece of motivation and thanks to everybody who took part in the bug squashing.

Anniversary of Debian MedOn Mon, 7 Jan 2002 the Debian Med project was first officially announced. I submitted a short blog posting about this and perhaps you might like to see a long sequence of talks about this topic.

Second Debian Med sprint (Southport, 27th-29th January 2012)In end of January 2012 the Debian Med team has met to the second sprint. As last year I would call this a very successfull event and I would recommend other teams to instanciate such meetings as well. Feel free to read my more verbose report.

Mentoring of Month (MoM)I have started this project for the following reasons:

• gather more manpower to the team
• strengthen connections to upstream (which might become MoM students)
• help shy people to become more verbose
• to learn myself about potential problems of people who do not feel fit for packaging tasks

I made a short summary how the first MoM project worked (see at bottom).

DDs who came to Debian because of Debian MedAfter realising that several members of the Debian Med team finally became DDs I made a little survey to find out about their reasons to become DD / DM. I came to the conclusion that a Blend could be a nice entry point for people to join Debian because newcomers can identify themselves with a known topic (the scope of the Blend - in this case medicine and bioinformatics) first and learn Debian rules in a team with common interest. This perfectly fits my expectation which I had from the beginning 10 years ago and I would be very happy if other Blends would follow this example to be nice, inviting and try to *actively* ask people for cooperation (see some simple rules which I learned in this process below). In the teammetrics GSOC project some graphs were created where you can see the level of contribution of these people (and other team members).

Future plansCurrently some heavy work regarding bringing bibliographic references about packages straight into package information is going on. This topic is specifically interesting in Biology because programs are frequently connected to some publication about the methods used inside the code. This topic is as well relevant to Debian Science and DebiChem. Thanks to the patient work done by Charles Plessy we now have about 70 packages featuring debian/upstream files featuring bibliographic references and there is ongoing work to move these data to UDD to enable further usage. We are in the process of final polishing the format and finishing scripts for the import. If people are interested to join this effort this would be the right moment to raise their hand.

General lessons learned

1. Do not let wait anybody who wants to do work.
2. Newcomers are frequently shy - try to invite them kindly and patiently.
3. Tell people verbosely about your project - it is astonishing how less people know and what wrong assumptions they make about your project.

Kind regards
Andreas.

Last saturday, I took an exam. Today, I noticed that I passed it (dutch): I am now a tennis official. Spooky. The exam itself wasn't all that difficult. There was a course two weeks ago in which the relevant rules were explained, and there was some preparation material on the vtv website that we were told to go through. In other news, I'm also running for DPL again. While that isn't a new job yet, it may become one. After having gone through the whole thing three times now, I must say that getting my platform written was never this difficult; I've been working at the text for quite some time now. Here's for hoping third time's a charm...