The Mancoosi Team has recently published the details of a study we conducted analyzing different packages managers available in debian. The goal of this study was to compare MPM (the mancoosi package manager) to other legacy solvers and try to get a big picture regarding of the state of the art. A similar study was conduct during EDOS and the results are still available here. As I wrote few months ago, MPM is a proof of concept that we wrote to test the behavior of a number of solvers that have been developed for the MISC competition in a real world scenario. These results do not show anything new w.r.t. the experience of a lot of poeple dueling daily with their machines in order to install a new piece of software. In a nutshell, we have shown that apt-get, aptitude, smart and cupt perform pretty well when used only with one baseline (for example a stable release) : this conforms with the experience of the majority of users of debian based systems. However problems start to arise when a user start mixing more then one baseline putting a lot of stress on the solver in order to find a satisfying solution. This solution of course exists, but it is cleverly hidden in the dependency structure of more then 40K packages... MPM is not as fast as other package solvers (say 10 seconds for mpm, while apt-get is able to find a solution in 3 second), but is remarkably stable. It is always able to find a satisfying solution, even in the harder cases where all the other failed. In these experiments MPM uses the postdam solver aspcud. This solver uses only GPL components and it would be a good candidate for inclusion in debian (there are actually a couple of ITP already filled for clasp and gringo). The results (with a lot of details) are published on the mancoosi website (a more detailed report is in the works). Enjoy ! During fosdem the Mancoosi team that authored this work (Roberto, Ralf, Zack and Me) will be around, so, please stop us for a chat ! And don't miss Ralf's talk !!

So Debian 6.0 "Squeeze" is due to be released this weekend. I've been doing my part annoying the release team with various risky last minute changes for not-formally-RC bugs. The best of these was making kFreeBSD CD images be actually used by d-i. Which had been silently ignoring them (so nobody noticed), and then I "broke" it to at least complain that it couldn't use them, and is now entirely fixed. Anyhow, there are these Debian release parties planned in 68 locations worldwide, this weekend. I have never been to a Debian release party. The timing is never right. The nearest one is 6 hours away, so I won't be making the trip. But yesterday I had a crazy idea, and I seem to have done enough that I can't back out now. announcing the Debian Party Line mumble.debian.net is a mumble server. Mumble is a nice system for doing group voice chats. I will be hosting a kind of virtual release party there, on February 5th and 6th. We'll follow the progress of the release, maybe have some scheduled events (if someone wants to do a talk or tutorial session). And at the end we'll hear what it sounds like when we all get Squeezed. So, should be fun, assuming my servers don't melt down due to bandwidth use. Hope to chat with you there! Please visit its page for details and to RSVP.

Another year, another FOSDEM. Yay, I m attending again! The biggest open source event in Europe, with more than 200 conferences and 5,000 people.

This year I will be talking about KDE on Windows. Sunday, 10.15, CrossDesktop Room (H.1309). If you are interested in helping us with KDE on Windows development, in making use of KDE on Windows for your application, or just want to use your favorite KDE applications on Windows, then you should come.

For as long as I have known Mike, he s been maintaining one of the largest (and most widely used) package: Iceweasel, Debian s default web browser. It s effectively Mozilla s Firefox although it has been renamed to avoid some rules enforced by Mozilla s trademark policy. But we might see Firefox back in Debian read on to know Mike s plans. His story is also very interesting in that he went from simple user to Iceweasel maintainer, and now he s working for Mozilla Corporation. But you already knew that contributing to free software is a good way to grow skills and gain experience that are valuable on the job market, right? My questions are in bold, the rest is by Mike. Who are you? I am Mike Hommey. I am French, even if my name doesn t sound so. I have been a GNU/Linux user since 1995, using Debian since 1999, and started packaging in 2003. After a long time in the NM queue, I became a DD in 2005. The main reason I started being actively involved is quite selfish: I wanted some things done, and I just did them. My first packages were extensions for the Mozilla Suite, the old one that directly inherited from Netscape Communicator. Later on, I wanted some of these extensions to work with the new kid on the block: Phoenix; or maybe it was already Firebird. By then, integrating extensions was a hassle, and the mozilla-browser maintainer had come up with a script that would make it easier for extension packages. So I ported that script for use with Phoenix/Firebird and sent it to the BTS. Then Phoenix/Firebird became Firefox, and it grew a real extension manager. Except that is was entirely not suited for extensions installed by the packaging system. So I made it work better. And made a few more changes to make Firefox work better. All through patches or NMUs. Then I became co-maintainer, then Firefox couldn t keep its name and became Iceweasel, and, fast-forward until today, I m now taking care of Iceweasel/Xulrunner and Iceape in stable, unstable, experimental and an external repository. This 8 years-long story (wow, I hadn t even realized it had been that long until I wrote it) tells you something: newcomers shouldn t be afraid to stick their hands anywhere, even in big packages. I was only a Mozilla and Phoenix end-user when I started. Apart from Mozilla-related packaging, I also happen to (co-)maintain some other packages in Debian, most notably webkit, though I haven t been very active in the pkg-webkit team recently. There are several reasons for that, the main one being that there are other team members getting the job done. And I can t say that much about the pkg-mozilla team, since there are effectively no other team members. What s your biggest achievement within Debian? I am quite proud that Squeeze will be the first Debian release where Iceweasel works on all supported architectures. Previously, we only knew the package compiled on all these architectures. Starting with Squeeze, we know it passes several of the test suites coming with the source code. This ensures most of the browser is functional. It was actually far from being the case before, as it appeared when the test suites were first enabled. I think it is very important to have properly working packages on all our supported architectures. The current evolution of hardware shows how important it still is. Who would have thought a few years back that we would see ARM or MIPS based netbooks today ? What are your plans for Debian Wheezy? For Debian Wheezy, I would like to improve Iceweasel/Icedove/Iceape integration with the packaging system. Something that would allow to use the apt database to find extensions or plugins, on top of the current behaviour. I also want to improve desktop integration, most notably for KDE. Another thing I d like to see happen is to package google breakpad independently (its source code is currently embedded in chromium and iceweasel, though not built, as far as I know), and have our Mozilla products builds be able to send their crash reports upstream. It is very important that upstream gets direct visibility over what crashes on GNU/Linux systems. It helps making them aware of issues that would otherwise probably remain unnoticed, as there are much more users using distributions packages than upstream tarballs. And not all Debian users report crashes to the BTS. I know at least Fedora and SuSE are already doing it. More importantly, I want to avoid the sad situation we got with Squeeze, where we re going to release a 18 months old Iceweasel. We got there for a combination of reasons, one being that I was preparing for a freeze in December 2009 and focusing on getting 3.5 in shape instead of the then upcoming 3.6. The result was that we didn t get 3.6 packages before upstream released 3.6.3 in April 2010. By then it was too late, considering the uncertainty of the release schedule, to update reverse dependencies and get 3.6 ready for Squeeze. Things are different for 4.0. I m already getting ahead of things, and while reverse dependencies haven t been taken care of, all beta releases have been made available through http://mozilla.debian.net/, usually within hours after upstream release (sometimes even a few hours before official announcement, but always after availability on ftp.mozilla.org). A great share of our patches were also pushed upstream. Several things made that possible:

• I m now closely following upstream trunk
• I m starting to prepare packages when candidate builds are distributed upstream, which usually happens a few days ahead for betas, and more than a week ahead for stable releases.
• I automated part of the package building process, and have a beefy build machine. I m getting near being able to provide nightly builds of upstream trunk.

There will be a couple major upstream releases until Wheezy comes along, and I want to make them available early in unstable, even if that means breaking reverse dependencies until they are fixed. Finally, I would like to get other people involved, starting with the Icedove maintainer. Volunteers are very much welcome, for any kind of involvement: bug triaging, documentation (which we are deeply lacking), testing, code People interested can contact the pkg-mozilla team list. As the Debian packaging gets less time consuming, I should be able to spend more time mentoring, which should help. If you could spend all your time on Debian, what would you work on? I actually have been working almost full time on Debian for a few months during a more-or-less purposeful unemployment period. That s when I attempted to add an alert popup when Iceweasel or extensions are upgraded (which was eventually removed because not working very effectively). That s when I worked on Iceweasel 3.6 and the first 4.0 betas. That s when I pushed more than 70 patches upstream, and got upstream commit access. I know for a fact that keeping up with upstream and answering bug reports is already time consuming, and time comes in finite quantity. Working full time on Debian allows to do more than that, as I ve been able to experience first hand. Unfortunately, that doesn t help pay the bills, so it would be best if time could be shared with other persons. Like, actual members in the pkg-mozilla team. Anyways, if I were to work full time on Debian again, I d like to do more than packaging, and help improve some of our infrastructure, most notably the buildd network, to grow some automated way to get packages built on all or some of our architectures. Call that PPA if you want, though I don t think we need something exactly like PPA. We sure do have porter boxes, but there is a huge overhead to get packages built there: you need to first try, then see you lack build dependencies, then wait for admins to install them, then come back and launch your build, and finally come back again much later to see how it went. And that s when it goes smoothly. Repeat for each architecture. It s already cumbersome when it s a small package, so imagine when it s Iceweasel. I d like to be able to push a (signed) .dsc somewhere, say I want it built on that and that architecture, and get binary packages and logs back. It could then be up to developers to distribute them, or not. Sometimes, you re just interested in test suite results. Another related wish would be a way to access build trees of failed builds, possibly on the buildd where it failed. What s the biggest problem of Debian? Lack of contributors, lack of contributors, and lack of contributors. It can sound weird to say that in a community of 1000+ people. But the sad reality is that we ve seen, repeatedly, calls for help in various places from various understaffed teams (most often of effectively one member) for years. So there is obviously a problem getting people to invest time in these teams either on the long term, or at all. I know this is not a very significant metric, but it already should say a lot: I wouldn t be surprised if more than 2/3 of the number of source lines of code in Debian come from less than 5% of the number of packages in the archive, and see less than 5% of the DD/DM population involved. If someone feels like doing the actual math, I m curious to know how far I m from reality, and in what direction. We also lack manpower to be able to make our release development smoother. In a perfect world where manpower is not a scarce resource, we should work on $release+1 when $release is being frozen. Said otherwise, we should have been able to start working on Wheezy in August 2010, or even earlier. You ve been working for Mozilla Corporation for a few months. How does the work look like and what are you working on? I am actually not working full time for MoCo; I am only contracting for 4 days a week. That was a request I made to keep having enough spare time for Debian or other activities. I am working from home, and am pretty much free about when I work, as long as I work long enough. I take advantage of this freedom and the saved commuting time to live a healthier life by doing some sports in the daytime (which also happens to be cheaper). I mostly work with Taras Glek and other people on various aspects of Firefox startup performance. This involves pretty interesting low-level stuff, in which I actually got involved before being contracted. This work has nothing to do with packaging Iceweasel, though I can have a few opportunities to do things somehow related. You told in your blog that you were discussing with Mozilla how Debian could use the Firefox trademark. Can you tell us a bit about the progress you made? I have got an informal approval of the patches we are applying to the Iceweasel 4.0 beta packages. There are a few concerns about using the system cairo library, and the embedded copy of libpng needs to be used to have support for the animated PNGs that are used in the user interface and that are required in Firefox feature-set. Other than that, there are pretty much no objection on the technical side. We managed to get to some common ground as to how to manage stable updates and more generally, changes to our packages, but I m still waiting for an actual agreement draft. While I, as the maintainer, am fine with the way it should look according to my discussions with the people involved at Mozilla, I ll seek review from my fellow Debian Developers when I ll have something to show. I haven t decided yet how this will reflect on the Debian packages, though. For example, would Iceweasel stay? But I do hope Wheezy will get Firefox back. Is there someone in Debian that you admire for their contributions? Not someone, but all past, present and future release team members. This is a team that receives a lot of critics (and I indirectly gave one a few paragraphs ago), yet manages to keep doing an amazing job and its members are very committed to their task. I admire their dedication.

---

Thank you to Mike for the time spent answering my questions. I hope you enjoyed reading his answers as I did. 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, Twitter and Facebook.

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

I have submitted an talk about the Haskell programming language to the organizers of GNUnify, a Free Software conference in Pune, India, on 11th and 12th of Februrary, and they accepted. The talk will be similar to the one I gave to the FOSSEE group. If you are at GNUnify and want to exchange key signatures or chat, just talk to me.

Hello I ve taken a step back and looked at the synopsis of the Config::Model man
pages. Boy, I m not proud of what I ve released. Except the ones I ve reworked recently, most of them are worthless. The next release of Config::Model will feature new synopsis. Each synopsis will contain a valid example that can be run with a cut n'paste in a test file. The code in the synopsis will actually do something visible. Here s an example extracted from the next version of Config::Model::Dumper:

 use Config::Model ;
 use Log::Log4perl qw(:easy) ;
 Log::Log4perl->easy_init($WARN);
 # define configuration tree object
 my $model = Config::Model->new ;
 $model ->create_config_class (
    name => "MyClass",
    element => [
        [qw/foo bar/] =>  
            type => 'leaf',
            value_type => 'string'
         ,
        baz =>  
            type => 'hash',
            index_type => 'string' ,
            cargo =>  
                type => 'leaf',
                value_type => 'string',
             ,
         ,
    ],
 ) ;
 my $inst = $model->instance(root_class_name => 'MyClass' );
 my $root = $inst->config_root ;
 # put some data in config tree the hard way
 $root->fetch_element('foo')->store('yada') ;
 $root->fetch_element('bar')->store('bla bla') ;
 $root->fetch_element('baz')->fetch_with_id('en')->store('hello') ;
 # put more data the easy way
 my $step = 'baz:fr=bonjour baz:hr="dobar dan"';
 $root->load( step => $step ) ;
 # dump data
 print $root->dump_tree;

Feel free to log bugs on Debian BTS or on CPAN RT if the next synopsis still have problems. All the best

Gzip streaming in Python (or lack thereof) Consider this simple Python snippet:

#!/usr/bin/python
import gzip
from urllib import urlopen
zfd = urlopen("http://ftp.debian.org/debian/dists/sid/Contents-udeb.gz")
fd = gzip.GzipFile(fileobj=zfd, mode="r")
for line in fd:
    foobar(line)

It does not work: it turns out GzipFile wants to seek() and tell() on its file object:

$ /tmp/z.py 
Traceback (most recent call last):
  File "/tmp/z.py", line 8, in <module>
    for line in fd:
  File "/usr/lib/python2.6/gzip.py", line 438, in next
    line = self.readline()
  File "/usr/lib/python2.6/gzip.py", line 393, in readline
    c = self.read(readsize)
  File "/usr/lib/python2.6/gzip.py", line 219, in read
    self._read(readsize)
  File "/usr/lib/python2.6/gzip.py", line 247, in _read
    pos = self.fileobj.tell()   # Save current position
AttributeError: addinfourl instance has no attribute 'tell'

Oh dear... this really shouldn't be. Let's look around the internet for details:

Since opener.open returns a file-like object, and you know from the headers that when you read it, you're going to get gzip-compressed data, why not simply pass that file-like object directly to GzipFile? As you read from the GzipFile instance, it will read compressed data from the remote HTTP server and decompress it on the fly. It's a good idea, but unfortunately it doesn't work. Because of the way gzip compression works, GzipFile needs to save its position and move forwards and backwards through the compressed file. This doesn't work when the file is a stream of bytes coming from a remote server; all you can do with it is retrieve bytes one at a time, not move back and forth through the data stream. So the inelegant hack of using StringIO is the best solution: download the compressed data, create a file-like object out of it with StringIO, and then decompress the data from that.

Oh really, so it's a limitation of "the way gzip compression works", and the only way to work around this fundamental design flaw of gzip is to buffer the lot in memory or to a temporary file? [facepalm]

# Apparently, this is not how gzip compression works:
curl http://ftp.debian.org/debian/dists/sid/Contents-udeb.gz   zcat

This is not the first time that, after finding a frustrating spot in core Python things, looking around the internet for extra information has the effect of amplifying my frustration by destroying my expectations of common sense. What is the gzip module doing anyway?

    if self._new_member:
        # If the _new_member flag is set, we have to
        # jump to the next member, if there is one.
        #
        # First, check if we're at the end of the file;
        # if so, it's time to stop; no more members to read.
        pos = self.fileobj.tell()   # Save current position
        self.fileobj.seek(0, 2)     # Seek to end of file
        if pos == self.fileobj.tell():
            raise EOFError, "Reached EOF"
        else:
            self.fileobj.seek( pos ) # Return to original position
        self._init_read()
        self._read_gzip_header()
        self.decompress = zlib.decompressobj(-zlib.MAX_WBITS)
        self._new_member = False

Right, tell() and seek() in order to check if it's reached end of file. Oh dear... So, there's a flaw in the Python standard library, and:

• it is not explicitly mentioned in the module documentation, which just says "fileobj [...] can be a regular file, a StringIO object, or any other object which simulates a file".
• in basic Python learning material, we find a paragraph whose purpose is to explain that this is not Python's fault, but it is a fundamental limitation on the way gzip works.

I wish core Python documentation started properly documenting Python flaws so that one can code with language limitations in mind, insted of having to rediscover them and their work arounds every time.

As you might know, Debian was one of the 20 organizations selected to participate in the first Google Code-in. We got a moderate success since we started preparing the contest very late (I joined as mentor/admin the very first day of the contest!). Because of this, unlike other organizations, we did not manage to engage interested students from the very beginning of the Code-in. Since we did not have too many Debian tasks the first days, we did not attract many students, and thus did not have very many throughout the contest. Given Debian tasks were mostly about improving and contributing to Debian, it was quite hard having tasks that did not require having a Debian installation and that made it difficult for many students to get involved. Also, until the last two weeks we did not have any translation task that could have attracted earlier students without too much confidence in their technical and English skills. Nonetheless, Debian got 39 tasks done:

• 9 write manpages tasks, resulting in ~35 manpages submitted to the BTS
• 14 triage bugs tasks, resulting in 42 bugs triaged in the BTS
• 4 new packages created
• 1 QA upload
• 1 video showing Squeeze s artwork
• http://wiki.debian.org/IntroDebianPackaging got translated into Spanish, Italian, Catalan and Romanian. And http://wiki.debian.org/UsingGit got translated into Italian.
• elinks got some nice icons
• dpkg got a small enhacement and a manpage for deb-src-control
• an initial draft of how to create a BOINC project with Debian
• and update-notifier-kde got a reboot option.

With about 30 students participating and at least one of the students has keep contributing to Debian after the contest! The contest was sometimes stressful with several students wanting their tasks to be reviewed at the same time, and the date was problematic due to the winter (or summer!) holidays but still I am quite happy with the final result :D Debian will be also participating again this year in the Google Summer of Code 2011. Join the soc-coordination mailing list and stay tunned if you want to participate as mentor or student.

Before you start reading: this post is only intended to test a plugin that I've just written to give PyBlosxom a txt2tags formatting support. The original txt2tag sample used here is available at txt2tag website. Mine with few changes is here.IntroductionWelcome to the txt2tags sample file.Here you have examples and a brief explanation of allmarks.The first 3 lines of the this file are used as headers,on the following format:

  line1: document title  line2: author name, email  line3: date, version

Lines with balanced equal signs = around are titles.Fonts and BeautifiersWe have two sets of fonts:The NORMAL type that can be improved with beautifiers.The TYPEWRITER type that uses monospaced font forpre-formatted text.We will now enter on a subtitle...BeautifiersThe text marks for beautifiers are simple, just as youtype on a plain text email message.We use double *, /, - and _ to represent bold,italic, strike and underline.The bold italic style is also supported as acombination.Pre-Formatted TextWe can put a code sample or other pre-formatted text:

    here    is     pre-formatted  //marks// are  **not**   interpreted 

And also, it's easy to put a one line pre-formattedtext:

  prompt$ ls /etc

Or use pre-formatted inside sentences.More CosmeticsSpecial entities like email (duh@somewhere.com) and URL (http://www.duh.com)are detected automagically, as long as the horizontal line:

---

^ thin or large v

---

You can also specify an explicit link with label.And remember,

A TAB in front of the line does a quotation.

More TABs, more depth (if allowed).

Nice.ListsA list of items is natural, just putting a dash ora plus at the beginning of the line.Plain ListThe dash is the default list identifier. For sublists,just add spaces at the beginning of the line. Morespaces, more sublists.

• Earth
  • America
    • South America
      • Brazil
        • How deep can I go?
  • Europe
    • Lots of countries
• Mars
  • Who knows?

The list ends with two consecutive blank lines.Numbered ListThe same rules as the plain list, just a differentidentifier (plus).

1. one
2. two
3. three
   • mixed lists!
   • what a mess
     1. counting again
     2. ...
4. four

Definition ListThe definition list identifier is a colon, followed bythe term. The term contents is placed on the next line.

orange

a yellow fruit

apple

a green or red fruit

other fruits

• wee!
• mixing lists
  1. again!
  2. and again!

TablesUse pipes to compose table rows and cells.Double pipe at the line beginning starts a heading row.Natural spaces specify each cell alignment.

heading 1	heading 2	heading 3
cell 1.1	cell 1.2	cell 1.3
cell 2.1	cell 2.2	cell 2.3

Without the last pipe, no border:

heading 1	heading 2	heading 3
cell 1.1	cell 1.2	cell 1.3
cell 2.1	cell 2.2	cell 2.3

Special EntitiesBecause things were too simple.ImagesThe image mark is as simple as it can be: [filename].

• The filename must end in PNG, JPG, GIF, or similar.
• No spaces inside the brackets!

OtherThe handy %%date macro expands to the current date.So today is 20110206 on the ISO YYYYMMDD format.You can also specify the date format with the %? flags,as %%date(%m-%d-%Y) which gives: 02-06-2011.That's all for now.

---

A down-under talk on the role of Debian, A.D. 2011 I'm back from LCA 2011, which I've attended to share some thoughts about the role that Debian plays in the Free Software ecosystem, 18 years after its inception (yes, we are that old^Welder). The talk title---Who the bloody hell cares about Debian? [1]---was meant to be rather provocative. The idea was indeed to challenge the meme that, in the era of distributions that release every 6 months, a distribution with a release cycle of circa 2 years (like Debian, considering the past 5 years) is not a project that deserves your attention anymore. Is it really the case? In the talk I (obviously) claim it is not, using two main arguments. The first argument is based on the observation that Debian offers a set of pretty rare, if not unique, features among mainstream FOSS distributions. Those features consist of a mix of technical and "political" aspects: (1) a focus on package quality, with no distinction among first and second class packages; (2) a strong culture of software freedom, which refuses to offer non-free software (or firmware) by default to users and distribution developers (as parts of the infrastructure used to make Debian); (3) independence from commercial interests, with no single company or entity that could claim to babysit Debian; and (4) a decision making model based on a weighted sum of do-ocracy and democracy, which implies that by doing (rather than talking) everyone has a chance to have an impact on Debian. Considering all that and looking at the most popular FOSS distributions, one can easily identify Debian as one of the few remaining players who both care about Free Software and can be trusted in making choices not driven by profit. Mind you, I've nothing against companies in general and I'm very well aware that many FOSS companies carry a good deal of the burden of developing and promoting Free Software. Nonetheless, in days in which it is striking how quickly FOSS-friendly companies can become very much FOSS-unfriendly, I can't help putting my trust and efforts into community-driven projects, better if with no attached company label whatsoever. Furthermore, having distributions like Debian around can encourage other company-backed distributions to demand more and more independence and clarifications about the relationships between the community and the backing company. The second argument about the relevance of Debian is more pragmatic and rather straightforward: Debian is the root of a huge tree of derived-distribution (AKA "derivatives"), more than 120 according to popular distribution indexing sites. Each Debian derivative focuses its attention on, and directs its people power to, customizing Debian for a specific target and build entierly upon Debian work for all parts that do not need customization. That possibility is one key advantage of Free Software, after all. A well-known derivative example is Ubuntu, which is probably the most popular Debian derivative, enjoying a user base way larger than that of Debian itself. Ubuntu is heavily customized with respect to Debian and still had only about (at the time of Natty) 25% of packages which either differed from their Debian counterparts or that did not exist in Debian at all. Other Debian derivatives tend to be way less customized than that. Either way, if you are running a Debian derivative, chances are that you heavily depend on Debian and on its well-being. (Yes, it is so also if you didn't know about that, sorry.) Let's now fast-forward to the end of the talk, skipping my usual comments on how to keep the whole tree of Debian derivatives sustainable and beneficial for Free Software as a whole (i.e. by reducing as much as possible the viscosity of patch flow along the derivatives tree). Feedback People's reaction to such a provocative talk has been positive and we have enjoyed a fairly long Q&A session discussing the topics mentioned above as well as other Debian-related topics. A (commented) summary of the obtained feedback is reported below. Judging from the recurrent questions and suggestions I've received doing Debian talks in the past 8 months, I dare to say that LCA feedback is fairly representative of the feelings of many Debian users.

• Some people believe that Debian is too silent about its role with respect to derivatives. I agree: we should communicate clearly about this, as well as asking our derivatives to do the same. Initiatives such as the Derivatives Front Desk and, more recently, the Derivatives Census seem to go in the right direction.
• More generally, users seem to believe that we have the tendency to undersell what Debian has to offer and, in particular, the testing distribution (whose name is too scary in comparison to the unique balance it offers of up to date and tested software).
• There is a clear interest in rolling distributions among GNU/Linux users and Debian enthusiasts are no exception. Mentioning CUT seems to invariably whet the appetite of our users.
• On the other hand, there are also inquiries about the support period for Debian stable releases (currently about 3.5 years) and the possibility of having it extended. Once more, recent work in progress by the security team seems to be going in the right direction. As another potential underselling problem, not all users seem to be aware that Debian security support is on the whole archive, whereas other LTS offerings are not.
• Various users are enthusiast about the free firmware achievement for Squeeze and happy about the way we communicated about it. Questions about the purpose of other "free firmware" distributions with respect to Debian invariably arise, although it's not up to us to answer those.
• There is also interest in cross-distribution collaboration, probably triggered by a natural generalization of the invite of of collaborating across derivatives. I've been asked about Debian participation into the AppStream thingie and I've been happy to reiterate that it has been an important milestone in cross-distro collaboration.

Slides of the talk are available, while a video will eventually be posted at http://linuxconfau.blip.tv.

---

[1] Kudos to Francois Marier for suggesting the title. If the title doesn't ring a bell for you (it didn't for me in the beginning), you might want to check out the story of this ad. Update: minor rephrasing in the 4th paragraph

My FSF colleague Brett Smith and I will be making the case against software patents on a panel at the Churchill Club in Mountain View, CA, the evening of February 16th. Hope to see End Software Patents supporters in the audience! More information: Churchill Club Panel Discussion on Software Patents Free Software Foundation working together for free software

Using a combination of bad luck and some of the more advanced git options, it is possible to mess up a centralised repository by accidentally pushing a branch and overwriting the existing branch pointer (or "head") on the server.

If you know where the head was pointing prior to that push, recovering it is a simple matter of running this on the server:

git update-ref /refs/heads/branchname commit_id

However, if you don't know the previous commit ID, then you pretty much have to dig through the history using git log.

Enabling a server-side reflogOne option to prevent this from happening is to simply enable the reflog, which is disabled by default in bare repositories, on the server.

Simply add this to your git config file on the server:

[core]
   logallrefupdates = true

and then whenever a head is updated, an entry will be added to the reflog.

I often have ideas for little web sites, stuff I just get the urge to create for the fun of it. Some of them have done rather well, like langpop.com but even that doesn't make any money, and, sadly, as I age, that is becoming a more important factor in life. So I decided to try a little experiment. I was thinking some about "value" stocks, and fiddling around with Google's stock screener, and thought of the idea of a site that highlights underperforming stocks: http://underperformingstocks.com - so far so good - I went ahead and registered the domain, and put together the beginnings of a Rails application. At the same time though, I decided I have enough things to do in my evenings and weekends, so I decided that it might be interesting to start selling the site at the same time I'm building it. I'm not really sure how it will work out: perhaps people will see that there's not much there and not bid for it. Perhaps someone likes the idea behind it and is willing to buy on that. My idea, in any case, is to keep working on it as the auction progresses. As an additional twist, there are obviously a lot of features that could be added to the site, so I'll prioritize work on features suggested by users who have bid on the site. Here's the auction listing on Flippa.com: Edit: I'll also be posting updates to the twitter account I created for the project: http://twitter.com/#!/underpstocks

One of the things that everyone seems to do different is managing passwords. We haven t looked at that in quite some time, despite growth both of the company and the IT department. As I look to us moving some things to the cloud, and shifting offsite backups from carrying tapes to a bank to backups via the Internet, I m aware that the potential for mischief whether intentional or not is magnified. With cloud hosting, a person could, with the press of a button, wipe out the equivalent of racks of machines in a few seconds. With disk-based local and Internet-based offsite backups, the potential for malicious behavior may be magnified; someone could pretty quickly wipe out local and remote backups. Add to that the mysterious fact that many enterprise-targeted services allow only a single username/password for an account, and make no provision for ACLs to delegate permissions to others. Even Rackspace Cloud has this problem, as do their JungleDisk backup product, and many, many other offsite backup products. Amazon AWS seems to be the only real exception to this rule, and their ACL support is more than a little complicated. So one of the questions we will have to address is the balance of who has these passwords. Too many people and the probability of trouble, intentional or not, rises. Too few and productivity is harmed, and potentially also the ability to restore. (If only one person has the password, and that person is unavailable, company data may be as well.) The company does have some storage locations, including locked vaults and safe deposit boxes, that no IT people have access to. I am thinking that putting a record of passwords in those locations may be a good first step, as putting the passwords in the control of those that can t use them seems a reasonable step. But we ve been thinking of this as it pertains to our local systems as well. We have, for a number of years now, assigned a unique root password to every server. These passwords are then stored in a password-management tool, encrypted with a master password, and stored on a shared filesystem. Everyone in the department therefore can access every password. Many places where I worked used this scheme, or some variant of it. The general idea was that if root on one machine was compromised and the attacker got root s password, it would prevent the person from being able to just try that password on the other servers on the network and achieve a greater level of intrusion. However, the drawback is that we now have more servers than anyone can really remember the passwords for. So many people are just leaving the password tool running. Moreover, while the attack described above is still possible, these days I worry more about automated intrusion attempts that most likely won t try that attack vector. A couple of ways we could go may include using a single root password everywhere, or a small set of root passwords. Another option may be to not log in to root accounts at all possibly even disabling their password and requiring the use of user accounts plus sudo. This hasn t been practical to date. We don t want to make a dependency on LDAP from a bunch of machines just to be able to use root, and we haven t been using a tool such as puppet or cfengine to manage this stuff. Using such a tool is on our roadmap and could let us manage that approach more easily. But this approach has risks too. One is that if user accounts can get to root on many machines, then we re not really more secure than a standard root password. Second is that it makes it more difficult to detect and enforce password expiration and systematic password changes. I m curious what approaches other people are taking on this.

All translatable debconf templates for packages in squeeze are translated in Czech, German, French and Swedish. Two other language teams nearly reached that goal and failed to reach it because of flaws in communication with package maintainers:

• Russian is only missing 3 strings in debian-edu-config (they reached the package maintainers too late);
• Portuguese is missing 4 strings in udev (the package was uploaded way too late even though the translation was sitting there for weeks: next time, I'll NMU that package).

So, in my opinion, I will count SIX languages as reaching 100% in po-debconf. Another great effort is currently going on with the Squeeze Release Notes translation, where 8 languages are very likely to be complete (http://www.debian.org/releases/testing/statistics.html) and a strong last-minute effort by a motivated Danish team could likely add one. And, of course, you all know that Debian Installer supports 70 languages with 57 of them with a full translation.

Apparently I forgot to put my initial call for release parties on planet.debian.org. Sorry, so much things to do, so little time... As Debian Squeeze will be released next weekend, it's a good time to start preparing a release party in your city. Be it in a pub, a pizzeria, or your living room: Organizing and hosting a release party is an ideal opportunity to meet, exchange GPG fingerprints, exchange knowledge and of course be merry and celebrate :) If there's going to be an event in your city, please add it to our wiki page so others can find it and join you :) Oh, and the publicity got the idea to do some live commenting of the release process via Debian's official identi.ca account. Might become interesting to watch that, too, as we also plan to fill boring waiting parts with funny and interesting facts :) Oh, and if you should know / or would be interested in an interesting facts (e.g. the the 150'000 closed bugs since Lenny got released please contact us, as we are still preparing them ;)

Hello My blog How about a configfs with Config::Model ? mentioned the on-going work to provide an access to configuration data through a virtual file system , i.e. through fuse. This new feature is now working since Config::Model 1.231. As an example, let s see how Fuse can be used to your ssh client. I.e. how to use config-edit command to modify your ~/.ssh/config through a virtual file system. Note that this is just an example, Fuse can also be used for other configuration withan existing model. First, you need to install Config::Model and Fuse and the fuse software. If you re on Debian/Sid, installing all this is straightforward:

$ sudo aptitude install libconfig-model-perl libfuse-perl

On other systems, you can use CPAN to install the Perl modules

$ cpanp i Fuse
$ cpanp i Config::Model

Hopefully, fuse library will be available through a package on your favorite repository. Let s start from an empty ssh configuration file. First you need to create a directory that will be used by Fuse as a mount point:

$ mkdir my_fuse_dir

Then run config-edit-ssh (which will be changed later to config-edit -applit ssh ):

$ config-edit-ssh -ui fuse -fuse_dir my_fuse_dir
Mounting config on my_fuse_dir in background.
Use command fusermount -u my_fuse_dir to unmount

Now, all parameters that can be configured in /.ssh/config are shown as files and directories in the fuse directory (the list was reduced to save electrons):

$ tree my_fuse_dir/
my_fuse_dir/
AddressFamily
BatchMode
BindAddress
ForwardX11
ForwardX11Trusted
[snip]
HashKnownHosts
Host
*
ConnectionAttempts
[snip]
User
UserKnownHostsFile
VerifyHostKeyDNS
VisualHostKey
XAuthLocation
HostbasedAuthentication
HostKeyAlgorithms
[snip] 14 directories, 119 files

Let s say that we want to configure specific settings for 2 hosts:

• Always forward X11 on host repoman
• Connect with user foo-guest on all debian system

First step is to create the repoman entry:

$ mkdir my_fuse_dir/Host/repoman

A ls command in that new directory will show a lot of files:

$ ls my_fuse_dir/Host/repoman
IdentityFile Protocol Tunnel
CheckHostIP ForwardX11 KbdInteractiveAuthentication ProxyCommand TunnelDevice

Lo and behold, one of them is ForwardX11 ! Let s check what s in there:

$ cat my_fuse_dir/Host/repoman/ForwardX11

Since the entry is new, it s still empty. Enabling X11Forward for repoman is quite easy:

$ echo 1 > my_fuse_dir/Host/repoman/ForwardX11

Let s check:

$ cat my_fuse_dir/Host/repoman/ForwardX11
1

Now, unmount the fuse directory:

$ fusermount -u my_fuse_dir

And see the modified .ssh/config file:

$ cat ~/.ssh/config
Host repoman
ForwardX11 yes

You can see that ForwardX11 is indeed set to yes for host repoman. Last but not least, you may consider that handling files and directories through shell commands is not very easy for the end user. You re right. But that s not the point. The idea is to enable programmers to access and edit configuration data with any language (not only Perl). Just like a lot of program can access kernel data through /proc and /sys, configuration data can now be accessed in a unified way through this virtual file system. May be, one day, exploring /config will be as common as exploring /sys All the best

Since my NAS at home also acts as DHCP server, the obvious idea was to back up my PC and my laptop whenever they're switched on. Sadly, the documentation on how to do this from dhcpd.conf (instead of watching log files and reacting to log messages) is quite hidden, so here it is: I found the "execute" keyword (see the dhcp-eval manpage), and I found Tim Gustafson, which allowed me to pull it off (although, since I only have the two computers, I opted for a execute statement each and hardcoded the client IP in the call to the backup script. So I don't know if the address parsing stuff he does is correct.) So the host statements for me look just like this:

  host laeggerli-wifi  
    hardware ethernet 00:22:69:aa:bb:cc;
    fixed-address 172.23.5.19;
    on commit  
      execute("/usr/local/sbin/dhcp-run-backup", "commit", "laeggerli");
     
   

And the script to start dirvish is similarly simple, except that it needs to fork to the background to make sure dhcpd is not blocked. The sleep 600 is based on the theory that if I'm on my way out in the morning and need to check mail quickly, that will be less than 10 min, whereas when I'm still online after 10 min, there's a good chance that the back up will go through. Obviously, this could be improved...

#! /bin/bash
# called by dhcpd.conf
# arguments:
#  $1 -> "commit" if called from dhcpd.conf, fork into background
#     -> "run"    if called internall from first instance
#  $2 -> client host
if [ "$1" == "commit" ]; then
    # fork to background
    $0 run "$2" >> /var/log/dhcpbackup.log 2>&1 &
    exit 0
fi
if [ "$1" != "run" ]; then
    echo error
    exit 1
fi
# figure out which host:
host="$2"
if [ "$host" != "laeggerli" -a "$host" != "faehrimaa" ]; then
    echo "Unknown host: $2"
    exit 1
fi
# did backup already run today?
d= date +%Y%m%d 
if [ -d "/srv/backup/$ host _home/$d" ]; then
    exit 0
fi
# wait 10min before actually running the backup
# (if computer still runs after 10min, it'll likely run for longer...
sleep 600
ping -n -w 3 $host >/dev/null 2>&1   exit 0
agentpid="/var/run/dirvish/ssh-agent-$host.pid"
[ -f "$agentpid" ] && \
    kill $(< "$agentpid") 2>/dev/null
mkdir /var/run/dirvish >/dev/null 2>&1
eval  ssh-agent  >/dev/null 2>&1
echo $SSH_AGENT_PID > "$agentpid"
ssh-add /etc/dirvish/ssh-key >/dev/null 2>&1
/usr/sbin/dirvish --vault $ host _home
/usr/sbin/dirvish --vault $ host _root
/usr/sbin/dirvish-expire --quiet --vault $ host _home
/usr/sbin/dirvish-expire --quiet --vault $ host _root
kill $SSH_AGENT_PID
rm "$agentpid"

(I don't claim any rights on any of it, it's trivial enough.)

Since my NAS at home also acts as DHCP server, the obvious idea was to back up my PC and my laptop whenever they're switched on. Sadly, the documentation on how to do this from dhcpd.conf (instead of watching log files and reacting to log messages) is quite hidden, so here it is: I found the "execute" keyword (see the dhcp-eval manpage), and I found Tim Gustafson, which allowed me to pull it off (although, since I only have the two computers, I opted for a execute statement each and hardcoded the client IP in the call to the backup script. So I don't know if the address parsing stuff he does is correct.) So the host statements for me look just like this:

  host laeggerli-wifi  
    hardware ethernet 00:22:69:aa:bb:cc;
    fixed-address 172.23.5.19;
    on commit  
      execute("/usr/local/sbin/dhcp-run-backup", "commit", "laeggerli");
     
   

And the script to start dirvish is similarly simple, except that it needs to fork to the background to make sure dhcpd is not blocked. The sleep 600 is based on the theory that if I'm on my way out in the morning and need to check mail quickly, that will be less than 10 min, whereas when I'm still online after 10 min, there's a good chance that the back up will go through. Obviously, this could be improved...

#! /bin/bash
# called by dhcpd.conf
# arguments:
#  $1 -> "commit" if called from dhcpd.conf, fork into background
#     -> "run"    if called internall from first instance
#  $2 -> client host
if [ "$1" == "commit" ]; then
    # fork to background
    $0 run "$2" >> /var/log/dhcpbackup.log 2>&1 &
    exit 0
fi
if [ "$1" != "run" ]; then
    echo error
    exit 1
fi
# figure out which host:
host="$2"
if [ "$host" != "laeggerli" -a "$host" != "faehrimaa" ]; then
    echo "Unknown host: $2"
    exit 1
fi
# did backup already run today?
d= date +%Y%m%d 
if [ -d "/srv/backup/$ host _home/$d" ]; then
    exit 0
fi
# wait 10min before actually running the backup
# (if computer still runs after 10min, it'll likely run for longer...
sleep 600
ping -n -w 3 $host >/dev/null 2>&1   exit 0
agentpid="/var/run/dirvish/ssh-agent-$host.pid"
[ -f "$agentpid" ] && \
    kill $(< "$agentpid") 2>/dev/null
mkdir /var/run/dirvish >/dev/null 2>&1
eval  ssh-agent  >/dev/null 2>&1
echo $SSH_AGENT_PID > "$agentpid"
ssh-add /etc/dirvish/ssh-key >/dev/null 2>&1
/usr/sbin/dirvish --vault $ host _home
/usr/sbin/dirvish --vault $ host _root
/usr/sbin/dirvish-expire --quiet --vault $ host _home
/usr/sbin/dirvish-expire --quiet --vault $ host _root
kill $SSH_AGENT_PID
rm "$agentpid"

(I don't claim any rights on any of it, it's trivial enough.)

... yet it is not a Belgian final. How is this possible? Answer: An-Sophie Mestach just won the juniors singles title, while Kim Clijsters will compete for the singles titles in the main event in about half an hour. While not as impressive as winning the main event, it's certainly great! Especially since she also won the Doubles title, together with the Dutch Demi Schuurs Congratulations, An-Sophie!