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.

As said in a recent comment, I use logwatch to look at the logs on my server. Every night logwatch send me a mail with a report of what has happen. One thing lacking was logs analysis for ikiwiki: ikiwiki don't produce log per-se. Access are logged and reported because they are done by the http server, but modification are only seen in the git repository, and comment waiting moderation are only in the ikiwiki directory. So I needed a way for logwatch to report specific ikiwiki activity.

• First we need to have a file logging activity in the ikiwiki's git repository. So in cron.daily, before logwatch is run, I put:

  git --git-dir $IKIWIKI_MAIN_DIR/.git log --after="6 month ago" --format="%cd (%h) %an: %s" --date=iso > /var/log/ikiwiki.log
  

  of course a better way to do it would be to create a git hook that generate the logs when modification are done, and not once everyday just before the logs are generated.
• Then we need to tell logwatch to look at this file, so in /etc/logwatch/conf/logfiles/ikiwiki.conf I put

  ########################################################
  # Define log file group for ikiwiki
  ########################################################
  # What actual file? Defaults to LogPath if not absolute path....
  LogFile = ikiwiki.log
  *ApplyEuroDate
  

  The ApplyEuroDate make ikiwiki read the date in iso format, so it will only report commit done today. I've found no way to tell logwatch to look at the output of a program instead of looking at a file.
• We then must tell logwatch that it must generate the report for a new service, so in /etc/logwatch/conf/services/ikiwiki.conf

  ########################################################
  # Configuration file for ikiwiki filter
  ########################################################
  Title = "Ikiwiki"
  # Which logfile group...
  LogFile = ikiwiki
  

• Finally, we have to taught to generate the report, in /etc/logwatch/scripts/services/ikiwiki

  #!/bin/bash
  # First look at pending comment
  find $IKIWIKI_MAIN_DIR/ -name "*_pending" -exec echo "Pending comment:" \; -quit
  ( 
      cd $IKIWIKI_MAIN_DIR/
      find . -name "*_pending" -exec echo "     " \;
  )
  # we then look at new commit
  fst=true
  while read d t tz j; do
      if [ $fst == true ]; then
          echo "New commit:"
          fst=false
      fi
      echo -n "  "
      echo $j
  done
  

Hi, Alex. Hi, Del. Good night, Irene.

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.

Normally people aren't stupid or evil enough to demand that I not use a word at all. On the occasions that they are that stupid or evil, typically only one word is singled out. Thus, when someone demonstrates enough unwisdom to give me a list, I feel the need to share publicly:

• moist
• foodie
• panties
• partner in crime

Seriously.

Many websites have addresses that use a www.- prefix. Some people are encouraging this practice, other are advising against it. I, for one, think this prefix makes sense and is really useful, so here is an explanation of my opinion. In a nutshell: the Wold Wide Web is one Internet service among many other such as domain name, mail, mailboxes or instant messenging; using a dedicated prefix allows to distribute all these services to specific servers in a convenient way.On Internet, you can expose several services, the most common being domain names (DNS), websites (HTTP), incoming mail (SMTP), outgoing mail submission (submission), mailbox fetching (POP) or consultating (IMAP) and instant messenging (XMPP). Constraints Modern Internet services can have constraints such as load balancing, failover and most importantly the possibility to use specific servers for each service instead of having all of them on the same server. Dedicated records Some service were designed or revised to take these contraints into account; this include the domain name, incoming mail and instant messenging, by using dedicated DNS records:

example.com.                    NS              roquefort.example.com.
example.com.                    MX  10          morbier.example.com.
_xmpp-server._tcp.example.com.  SRV 10 100 5269 morbier.example.com.

In that example, the name service of example.com. is provided by the server Roquefort while the incoming mail and instant messenging service are provided by Morbier Dedicated prefixes On the contrary, some services were not designed to take these constraint into account, and may be too fossilized to be revised for that; this includes the Web and mailbox service. A convenient way to work around the antiquated design of these services is to use a well known prefix:

www.example.com.                CNAME           ossau-iraty.example.com.
smtp.example.com.               CNAME           morbier.example.com.
pop.example.com.                CNAME           morbier.example.com.
imap.example.com.               CNAME           morbier.example.com.

In that example, the Web service of example.com. is provided by the server Ossay-Iraty while the email submission and mailbox services are provided by Morbier. Readability and flexibility Using dedicated records and prefixes increases the consistency and readability of a DNS zone, since it allows to refer to the servers by their canonical host name, and to define their IP addresses once and for all:

; Services
example.com.                    NS              roquefort.example.com.
example.com.                    MX  10          morbier.example.com.
pop.example.com.                CNAME           morbier.example.com.
imap.example.com.               CNAME           morbier.example.com.
www.example.com.                CNAME           ossau-iraty.example.com.
; Hosts
roquefort.example.com.          A               192.2.0.12
                                AAAA            2001:db8::12
morbier.example.com             A               192.2.0.42
                                AAAA            2001:db8::42
ossau-iraty.example.com.        A               192.2.0.51
                                AAAA            2001:db8::51

You can think of that practice as connecting dots between services and hosts:

name service    Roquefort
incoming mail   Morbier
mailboxes         Ossau-Iraty
website        

With such a DNS zone, it is very easy to identify which server is hosting each service. Using host names rather than IP addresses multiple times reduces the information duplication, which in turn facilitates future chances and reduces the risk of error (it is easier to swith the website from Ossay-Iraty to Morbier than from 192.2.0.51/2001:db8::51 to 192.2.0.42/2001:db8::42).

The Debian Project is pleased to announce that registration is now open for DebConf12, which will take place in Managua, Nicaragua, from Sunday 8 July to Saturday 14 July 2012. The conference will be preceded as usual by one week of DebCamp, from Sunday 1 July to Saturday 7 July. As previous years, three different registration options will be available: Sponsored, Professional and Corporate. Through the Sponsored category, the Debian Project intend to help some people attend who would not be able to pay for their own travel to DebConf. The Corporate category, with a USD 1300 (EUR 1000) registration fee is intended for those attending DebConf as representatives of companies. The Professional category, with a USD 650 (EUR 500) registration fee, is intended for any individual or company who wants to help the conference by paying the direct costs of their attendence. It will only be possible to apply for food and accommodation grants and/or travel grants until 15 May. For more detailed information about how to register, please see the separate announcement from the DebConf team. Call for papers Debian invites submissions of proposals for papers, presentations, discussion sessions and tutorials for its DebConf12 conference. Submissions are not limited to raditional talks: you could propose a performance, art installation, debate, or anything else. Official submissions will be accepted until 1 June 2012, 23:59 UTC. This year, we will continue to organize some talks into thematic tracks. If you have a proposal for a DebConf track, please contact <debconf-team@lists.debconf.org>. Previous examples included Debian Science, Debian Infrastructure, and Community Outreach tracks. If you would like to be a track coordinator, please volunteer on that list. Detailed information on how to submit an event are available on the mail from the DebConf team.

Agile processes harness change for the customer's competitive advantage. Principles behind the Agile Manifesto

After two and a half years at Smoothwall, I'm moving on - Friday is my last day. Since I joined the development team, we have adopted Agile development, set up a pretty nifty Gerrit/Jenkins code review + integration system, and introduced dpkg for package management. Along the way, I helped with a bunch of important features for the business, like a ground-up rewrite of the web filter, and time-based browsing usage quotas. I will be starting at CV-Library on Monday, for a whole new set of challenges. They're based in Fleet, so I'll have an hour-long commute each way on the train. I've been assured by an expert in these matters that facilitating wage slavery is a comparatively more ethical pursuit than facilitating internet censorship. :) To make the commute somewhat more bearable, I'm moving house on Saturday. So far, the packing's going quite well...

---

---

---

Updated (2012-04-11): Now contains the final and correct pip install command. TL;DR: pip install django-money will give you a working set of Django fields that handle Money and Currency. Read below for how that happened. I began this Easter weekend trying to finish up one of my pet-projects and get it ready to publish. The goal of the website is to compare providers, of the same thing, from around the world. Representing prices is simple. A float will do if you are in a hurry. Except. When you need to perform calculations and you run into rounding errors. At that point you will likely discover the Decimal module. Which also works perfectly fine. And if you only ever deal in a single market that is fine. But across markets? That requires Money. Money is normally defined as a value and currency. Once you have both of those, you can then do cross-market comparison and upgrade you program to handle multi-currency easily. I hoped that I was not the only person who had realised this, so I started to look around. And I struck gold! I found Python Money. It even included appropriate Django fields as well. Unfortunately it had had no updates since 2008. . Worse it didn't work so well. I continued my search. I kept on looking and found Django Money. Even better. This separated out the Django support and the Python support. It turned out Jakewin's py-moneyed was actually a fork of Limist's py-moneyed. So I set about retrieving every fork and comparing them. <aside>Aside: There should be a git hubclone command which will add every fork of a project as an upstream so you can easily compare what has occurred and what has happened amongst them.</aside> It turns out that Jakewin's version was good, just out-of-date. It mentioned waiting until a pull request has been merged in to limist's version. Which had been done a while ago. And Jakewin's Django-money (djmoney) was nicely done too, unittests and all. It had just bitrotted compared to newer versions of Django (and South). I discovered there were a set of forks of django-money at github too. I analysed them all, and basically only jakewins's and reinbach's mattered. I created fixes for jakewins and reinbach's version. I also opened up on an issue asking limist's to tag and upload a new version of py-moneyed. I also got a response from limist and now you can do pip install py-moneyed and get a useful, working, version. And reinbach also responded and now you can do pip install django-money and get a working, usable, representation of Money within Django. It turned out to be a productive, if yak-shaving, weekend after all.

With the latest release of Spacewalk PostgreSQL seems to be supported properly - finally. Also there are efforts to support Debian as a client system. So I'm thinking about using the upcoming BugSquashingParty in Salzburg to

• analyze the current support of Debian as a client in Spacewalk and maybe work on a better integration
• finalize the packaging and upload the client packages which were prepared by Miroslav Such (I hope he will be able to join us!)
• maybe work on packaging the server side of Spacewalk for Debian (Java is involved, so it would be great to have somebody form the Java team around!)

in the hope that you (yes, you!) are joining me! Please let me know if you are interested to work on Spacewalk related packages, even if you are not able to come to Salzburg.

I just booked my flights for going to Managua next July. I'll be leaving Paris on July 2nd, fly through Atlanta with Air France, then connect to Delta to Managua. A fairly simple trip that allows me to use my Air France miles..:-) Elisabeth, my wife, will join in Managua around July 14th, then we'll spend two weeks visiting Nicaragua and leave back home on July 31st. That will be a wonderful trip. See you in MGA!

I got into a discussion recently about what a Linux distribution actually is. To some people, a distro is just a convenient way of source of binaries from which to pick what you install, either on your own computer or when creating an embedded system, or some other specific kind of system. To others it's a way of life, and the realization of the ideals of software freedom. To yet others, a distro is an outdated concept that will go away in the near-ish future, to be replaced by ... something. Here's my take: a Linux distribution is defined by the following things:

• It's a specific, chosen set of upstream projects. The selection criteria vary wildly between distros, and may be based on things like purpose, quality, licenses, etc. Debian, for example, chooses pretty much everything that is free software, but a distro targeted at providing NAS devices would choose a much smaller set.
• It's a set of changes made to the upstream code, and specific configurations of the upstream code, in order make all the software work well together. For example, if the distro supports multiple mail transport agents, they might all need to be patched and configured to store incoming mail the same way by default.
• It's the tools, processes, policies, and workflows used to develop the distribution.
• It's the tools provided to the people using the distribution to install and manage their systems.
• It's the people and companies who develop the distribution and support its users, and their shared values and purpose. This may be a real community, or just the kind of community that exists as a web page.

Historically, there has been a lot of variation in all aspects mentioned above. Some of this variation may today be unnecessary. For example, it might be helpful for more distributions to share work on common tools, so that not everyone needs to re-invent and re-implement the same kinds of tools. However, my gut feeling is that due to the inherent interconnectedness of all things, it may be very difficult to have one set of tools to support well all workflows, policies, processes, and communities. The most important differentiating factors between the various distros are not the tools, but the community values, the perceived purpose of the distro, and the resultant criteria for choosing what to include and the workflow for developing the distro. Even when two distros use the same tools, there can be a lot of difference in the end result. Fedora and RHEL, for example, use a lot of the same infrastructure, but their purpose is entirely different. Debian and Ubuntu use mostly the same packages, even, and still there's a huge difference between the two distros: one aims at a high quality system based on free software, the other aims to support the business of one particular company. For this reason, there will always be a lot of Linux distributions around, and that is good.

Many of the SAN components in Debian have me involved. So I think out to give an update on what the state of SAN would be in Debian Wheezy. Open-iSCSI: Just uploaded a newer version to experimental which eventually will crawl into testing. It should fix all release goals for Wheezy. Please give it a good testiscsitarget: Same goes here. This one is already in testing. Please test. It has some bugs reported, all in needinfo, as they haven't been easily reproducible or reported complete.multipath-tools: It is in pretty good shape. Some minor bugs. But still, please test. :-)Open-FCoE: Being dependent on hardware, for which I couldn't manage resource commitment, this one is literally untested. It lies in testing, untested.LIO Target: The newest target implementation for Linux. It is also available in testing, has had some minor bugs reported by users, and fixed. If you use, or anticipate to use it in the Wheezy life cycle, now is the time to test.

apport just cleared the new queue and is now available in experimental. For those who do not know what apport is:

Debugging program crashes without any automated tools has been pretty time consuming and hard for both developers and users. Many program crashes remain unreported or unfixed because:

• Many crashes are not easily reproducible.

• End users do not know how to prepare a report that is really useful for developers, like building a package with debug symbols, operating gdb, etc.

• A considerable part of bug triage is spent with collecting relevant information about the crash itself, package versions, hardware architecture, operating system version, etc.
• There is no easy frontend which allow users to submit detailed problem reports.
• Existing solutions like bug-buddy or krash are specific to a particular desktop environment, are nontrivial to adapt to the needs of a distribution developer, do not work for crashes of background servers (like a database or an email server), and do not integrate well with existing debug packages that a distribution might provide.

Apport is a system which

• intercepts crashes right when they happen the first time,
• gathers potentially useful information about the crash and the OS environment,
• can be automatically invoked for unhandled exceptions in other programming languages (e. g. in Ubuntu this is done for Python),
• can be automatically invoked for other problems that can be automatically detected (e. g. Ubuntu automatically detects and reports package installation/upgrade failures from update-manager),
• presents a UI that informs the user about the crash and instructs them on how to proceed,
• and is able to file non-crash bug reports about software, so that developers still get information about package versions, OS version etc.

At this moment, it is quite broken. The crashes are not intercepted by update-notifier on my box. With it now in experimental, my intent is to slowly integrate it well with all dependent tools for Debian. It won't be ready for the Wheezy release, but hopefully for the one after that.On the Ubuntu side, Canonical hosts a retracing service that takes user reported core dumps and generates a usable backtrace. For Debian, my plan is to have a chroot kind interface, where in the user could opt-in to download all debug packages to generate a valid backtrace. This could go as the debian backend for apport in the future. On the bug reporting side, afaik, we do not have a web interface to lodge bugs. To report bugs (minus the core dumps), we will want a backend to submit it over email. The current apport report gathering tool is pretty good (if compared to other tools like reportbug), so here the low hanging fruit would be to just take the report and feed in email to our BTS server. For the eyes:

I met Francesca in Debconf 11 in Banja Luka. If I recall correctly, it s Enrico Zini who introduced me to her, because she was the madamezou (her IRC nickname) who started to get involved in the publicity team. Since then and despite having a bachelor thesis to complete she got way more involved and even gained official responsibilities in the project. Before starting with the interview, I wanted to mention that Francesca is drafting a diversity statement for Debian I was expecting the discussions to go nowhere but she listened to all objections and managed to improve the text and build a consensus around it. Thank you for this and keep up the good work, Francesca! Rapha l: Who are you? Francesca: My name is Francesca, I m 30 and I studied Social Sciences. Currently I live in Italy but I m planning to go abroad (not a lot of jobs here for geeky social scientists). Apart for Debian and FLOSS world in general, I have unrestrained passions for chocolate; zombie movies; sci-fi; zombie books; knitting sewing crafting and DIY in general; zombie videogames; bicycles; pulling apart objects to look inside them; splatter B movies, David Foster Wallace s books, playing trumpet, and did I already mentioned zombies? Days are too short for all this stuff, but I try to do my best. Raphael: How did you start contributing to Debian? Francesca: Some years ago I was stuck in bed for literally some months, due to a grave series of migraine attacks. I wasn t able to do anything: no social life, no books or television. So, I decided to turn on the laptop and do something constructive with it: I was already a Debian user and it seemed quite logical to me to try to give back to the community. I am not a coder and I ve not studied Computer Science, so my first step was to join an Italian Debian on-line community (Debianizzati) and help with tutorials, users support, wiki management. In a couple of months I learnt many things: helping other users with their problems forces you to do lots of research! My first contributions to the Debian project were mostly translations of the main website. Translators are the perfect typos spotters: they work so precisely on the text to be translated that they finish to do a great QA job. This is how I ve started to contribute to the Debian website: with very simple things, fixing typos or wrong links or misplaced wml tags. I still remember my first commit to the website: the idea was to undercase some tags, but it ended up that I misplaced some of them and in addition I fixed them only in the English page and not on the translations as well. When after a couple of minutes, K re Thor Olsen a long time contributor of the team and now webmaster reverted my commit, I felt so stupid and full of shame. But, to my great surprise, no one treated me like an idiot for that error: Gerfried Fuchs, one of the guru of the team, replies me in a really helpful and polite way explaining what I did wrong and how to do things correctly. I think this episode was a turning point in my Debian life: there s this idea that Debian Developers are just a bunch of arrogant assholes and maybe it was true in the past, but for my experience they are not. Well, at least the ones I met and work with .

To my great surprise, no one treated me like an idiot for that error.

Since then, I joined the WWW team and helped them apply the shiny new design provided by Kalle S derman. A lot of work was done during the week immediately before the release of the new website. Oh that was a week! We worked night and day to have the new design ready for February 6th, and it was fantastic when we finally published it, simultaneously with the release of Squeeze. At the same time, I started to contribute more actively to the Debian Publicity team, not only translating news but also writing them. It can sound scary for a non native English speaker to write something from scratch in English, but you have to keep in mind that your text will be reviewed by native speakers before being published. And we have some fantastic reviewers in the English localisation team: particularly Justin B Rye, who is tireless in his effort and more recently Moray Allan. I think I m particularly lucky to work with all these people: there s a special mood in both Publicity and WWW team, which makes you feel happy to do things and at the same time pushes you to do more just because it s fun to work with them sharing jokes, ideas, rants, patches and hugs. Rapha l: I believe that you have been trough the new member process very quickly. You re now a Non-Uploading Debian Developer. How was the experience and what does this mean to you? Francesca: Becoming a Debian Developer was not so obvious for me, because I didn t need to be a DD for the work I do in Debian. For instance, I don t maintain packages, so I had no reasons to want to become a DD in order to have uploading rights. For a while I didn t really feel the necessity of being a DD. Luckily, some people started to pester me about it, asking me to apply for the NM process. I remember Martin Zobel-Helas doing this for an entire week every single day, and Gerfried Fuchs doing it as well. Suddenly, I realized that people I worked with felt that I deserved the DD status and that I simply had thought I didn t. As a non coder and a woman, there probably was a bit of impostor syndrome involved. Having people encouraging me, gave me more confidence and the desire to finally become a DD. And so I did. The process for non uploading DD is identical to the one to become an uploading DD, with one exception: in the second part of the process (named Tasks and Skills) instead of questions about how to create and maintain packages, there are questions about the non packaging work you usually do in Debian. The general resolution which created the possibility to become a non uploading DD gave us a chance to recognize the great effort of Debian contributors who work in various area (translations, documentation, artworks, etc.) that were not always considered as important as packaging efforts. And this is great because if you are a regular contributor, if you love Debian and you are committed to the project, there are no reasons to not be an official member of it. With regards to this, I like the metaphor used by Meike Reichle in her recent talk about the Debian Women Project (video recording here):

a Debian Developer status is a lot like a citizenship in a country that you re living in. If you live in a country and you don t have citizenship, you can find a job, buy a house, have a family [...] but if this country at any point in time decides to go into a direction that you don t like, there s nothing you can do about it. You are not in the position to make any change or to make any effect on that country: you just live there, but there s no way that you can excercise influence on the people who run this country.

Rapha l: You recently joined the Debian Press Team. What does it involve and how are you managing this new responsibility? Francesca: The Press Team is basically the armed wing of the Publicity Team: it handles announcements that need to be kept private until the release, moderate the debian-announce and debian-news mailing list and maintain contacts with press people from outside the project. The real job, so, is done within the Publicity Team. The most important part of our work is to write announcements and the newsletter: while the newsletter is published bi-weekly, the announcements need to be write in a shorter timeframe. Localization is really important in spreading Debian word, so we work closely with translators: both announcements and DPN are usually translated in four or five different languages. The publicity work could be stressful, as we have strict deadlines, we need to take quick decisions and often do last-minute changes. Personally, I like it: I work better under pressure. But I know that is sometimes difficult for contributors to accept that we can t debate endlessly on details, we have just to go on and do our best in a given timeframe.

The publicity work could be stressful, as we have strict deadlines, [ ]. Personally, I like it.

Raphael: You re one of the main editor behind the Debian Project News. What s the role and scope of this newsletter? Francesca: Debian Project News is our beloved newsletter, direct successor of the Debian Weekly News founded by Joey Hess in 1999 and later kept alive by Martin Schulze. In 2007, Debian Weekly News was discontinued but in 2008 the project was revived by Alexander Reichle Schmehl. The idea behind DPN is to provide our users an overview of what is happening inside and outside the project. As the core team of editors is formed by three people, the main problem is to be able to collect enough news from various sources: in this sense we are always glad when someone points us to interesting blogposts, mails and articles. DPN is also a good chance for non coders to contribute to Debian: propose news, write paragraphs and review the draft before the publication are quite easy tasks but very useful. English native speakers can do a proofread (as no one of the main editors is a native speaker) while others can always translate DPN in their native language. People who want to help us can take a look at our wiki page.

DPN is also a good chance for non coders to contribute to Debian.

Just yesterday I realized that since January we don t miss or delay an issue: so I d like to thank the fantastic team of editors, reviewers and translators who made it possible. The team is now working on another way of spreading Debian s message: a long-time project is finally becoming real. Stay tuned, surprise arriving! Raphael: You re trying to organize IRC training sessions but that doesn t seem to take off in Debian, while it s quite common in the Ubuntu community. How do you explain that? Francesca: I m not sure about it: both Debian users and contributors seemed to appreciate this initiative in the past. I was quite surprised by the amount of Debian members present during the various sessions and by the amount of interesting questions asked by the users. So the only reason I can think about is that I need to put more enthusiasm in convincing the teams to do it: they need more encouragement (or to be pestered more!). I, for myself, think that IRC training sessions are a great way to promote our work, to share our best practice, to talk about our project to a wider audience. And I ll sure try to organize more of them. Help, suggestions, ideas are really welcome! Raphael: If you could spend all your time on Debian, what would you work on? Francesca: There is a project I d like to give more love, but I always end up without the time to do it: the debian-community.org project. Back in 2007, Holger Levsen founded it with the aim of reducing the gap between Debian contributors and Debian users, giving all an opportunity to contribute, share ideas and more. The project was discontinued and I d really like to revive it: in these years various things have changed, but I think that the core idea of having a node to connect existing local communities is still good and doable. In Debian we don t have the wide and well articulated local infrastructure present in other distributions (Ubuntu, particularly, but also Fedora): even if I don t like too centralized structures, I think that a better connection between the project and local groups of users and on-line communities would be a step forward for the project. Being part of the Events Team, I m aware of how much we need to improve our communication with local groups. An example is the events organization: sometimes, Publicity and Events teams even don t know about regional Debian related events (like booth at conferences, workshops, talks, install parties, etc) and this is a shame because we could offer a lot of help in organizing and promoting local events. What we lack is better communication. And debian-community.org project could give us exactly this. Could be a cluster of local groups, a platform for events organization and even a useful resource for newbies who want to find a local group near them. I started some effort in this sense, sending a proposal about it, working on a census of Debian local groups. Any help is appreciated! I m really curious to see how many Debian communities (from all around the world and the web) are out there, and I d love to have members from these communities better connected with the Debian Project. Raphael: What s the biggest problem of Debian? Probably the bikeshedding feticism of almost all of us. It s the other side of the coin of Debian s commitment to technical excellence and our perfectionism, but sometimes it leads just to endless discussions about details, and it is a blocker for various initiatives. In Debian, you have to be really patient and in a way stubborn to push some changes. This is frustrating sometimes. On the other hand, I really appreciate how people take some times to think to each proposals, give some feedback and discuss about it: the process could be annoying, indeed, but the result is often an improvement of the initial proposal. Raphael: Is there someone in Debian that you admire for their contributions? Most of my teammates are simply brilliant and adorable and hard-working. But I have to admit that I particularly admire David Pr vot: beside being a webmaster he does a lot of things, from French translations to DPN editing. All his contributions have a great quality and he s able to push you always further in doing things and doing them better. He is a good example of how I d like to be as contributor: smart, tireless, friendly.

---

Thank you to Francesca for the time spent answering my questions. I hope you enjoyed reading her 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.

I look after a lot of systems, and most of them want identical and simple backups taking of their filesystems. Currently I use backup2l which works but suffers from a couple of minor issues. In short I want to take a full filesystem backup (i.e. Backup "/"). I wish to only exclude a few directories and mounted filesystems. So my configuration looks like this:

# List of directories to make backups of.
# All paths MUST be absolute and start with a '/'!
SRCLIST=(  / /boot -xdev )
# The following expression specifies the files not to be archived.
SKIPCOND=( -path '/var/backups/localhost' -o -path '/var/run/' -o \
    -path '/tmp'  -o -path '/var/tmp' \
    -o -path '/dev' -o -path '/spam' \
    -o -path '/var/spool/' )

The only surprising thing here is that I abuse the internals of backup2l because I know that it uses "find" to build up a list of files - so I sneakily add int "-xdev" to the first argument. This means I don't accidentally backup any mounted gluster filesystem, mounted MySQL binary/log mounts, etc. backup2l then goes and does its jobs. It allows me to define things to run before and after the backup runs via code like this:

# This user-defined bash function is executed before a backup is made
PRE_BACKUP ()
 
   if [ -d /etc/backup2l/pre.d/ ]; then
      run-parts /etc/backup2l/pre.d/
   fi
 

So what is my gripe? Well I get a daily email, per-system, which shows lots of detail - but the key thing. The important thing. The thing I care about more than anything else, the actual "success" or "fail" result is only discoverable by reading the mail. If the backup fails, due to out of disk, I won't know unless I read the middle of the mail. If the pre/post-steps fail I won't know unless I examine the output. As I said to a colleague today in my view the success or failure of the backup is the combination of each of three distinct steps:

• pre-backup jobs.
• backup itself
• post-backup jobs.

If any of the three fail I want to know. If they succeed then ideally I don't want a mail at all - but if I get one it should have:

Subject: Backup Success - $(hostname) - $(date)

So I've looked around at programs such as backup-ninja, backup-manager and they seem similar. It is a shame as I mostly like backup2l, but in short I want to do the same thing on about 50-250 hosts:

• Dump mysql, optionally.
• Dump postgresql, optionally.
• Dump the filesystem. Incrementals are great, but full copies are probably tolerable.
• Rsync those local filesystem backups to a remote location.

In my case it is usually the rsync-step that fails. Which is horrific if you don't notice (quota exceeded. connection reset by peer. etc). The local backups are good enough for 95% of recovery times - but if the hardware is fried having the backups be available, albeit slowly, is required. Using GNU Tar incrementally is trivial. If it weren't such a messy program I'd probably be inclined to hack on backup2l - but in 2012 I can't believe I need to. (Yes, backuppc rocks. So does duplicity. So does amanda. But they're not appropriate here. Sadly.) ObQuote: "Oh, I get it. I see now. You've been training for two years to take me out, and now here I am. Whew! " - Blade II - An example of a rare breed, a sequel that doesn't suck. No pun intended.

Hello Last week-end, I ve participated Perl/QA hackathon in Paris. Here s a short summary of the main activities during this week-end. I was not in the best of shape due to a nasty (biological) bug that wore me down before the hackathon. First of all, I discussed with rjbs about the bunch of debian patches I ve written for Software::License. These patches (and hacks) are used in Debian to provide licenses summaries in Debian::Dpkg::Copyright model to help write Debian copyright files. License management is boring but necessary. cme and Software::License help in making this task slightly less boring. Ricardo kindly suggested some modifications and agreed to include my patches. I implemented these modifications directly during the hackathon. The other tasks during this week-end were (not necessarily in that order):

• I discussed with alanhaggai and gave him some ideas to fix his Archive::Zip module
• I did a live demo of Debian packaging to ribasushi: I updated the Debian package libdbix-class-schema-loader-perl from CPAN and uploaded it in Debian.
• I presented how to package Perl modules for Debian. renormalist will package his own module Data::Dpath and its dependencies for Debian. I will sponsor his packages once they are available on Debian perl s team git repository. Unless gregoa beats me to it
• I discussed with Slaven Rezic some binding weirdness found in Perl/Tk HList. Config::Model s graphical interface provide a viewer widget and and editor widget for configuration items. As expected, the viewer is invoked by a single left click. One would expect a double click to invoke the editor widget. But the double click bindinngdoes not owrk in HList when the single click is used. Currently the editor widget is invoked with a right-click, which is not user-friendly. According to Slaven, the bug might be hidden quite deep in Perl/Tk guts. Fixing it won t be easy.
• As a Debian/sid user, I ve been quite spoiled: I ve always had a recent Perl available on my system. I ve neved had to compile Perl since my HPUX days back in last century. However, Config;:Model tests failed with Perl 5.15.9, a development version not available in Debian (sid is not that unstable). Thanks to Xavier Caron, I ve learned about perlbrew and cpanminus to reproduce this bug and fix the issue. Many apologies to miyagawa for asking dumb questions about cpanm: the disctinction between runtime and build time does not apply to cpan minus. I guess that s the drawback of wearing 2 hats (Debian dev hat and Perl dev hat): your brain may get confused and you conflate issues. Oops.

Many thanks to FreeSide who sponsored my travel, to the hackathons organisers and to all the participants for their welcome. All the best