I'm both back from LCA 2011 and also over the associated brutal jetlag, so if you sent me mail and I still haven't replied then it's fallen down some sort of cliff and you should probably shout at me until I do something about it. LCA was, as usual, excellent. Especially given that the original venue was the same distance above the river as the now somewhat misleadingly described dry dock on the opposite bank.

I did a bunch of talks this year, and they're now all online, so without further ado:

Enterprise power management - a discussion of power management with a focus on enterprise users, given at the plumbers miniconf. LWN did a writeup here, and every time I say "Tera" you should pretend that I'm saying "Giga". I have no good excuse.

Linux license compliance - about the poor observance of the GPL's conditions by vendors, given at the business miniconf. A useful example presented itself in the form of a GPL-violating Android tablet that I bought in literally the first store I went into in Australia this year. Probably also the last appearance of my Knuth t-shirt, because it appears to have several holes in places where it shouldn't.

Making laptops work in Linux - talking about identifying how laptop-specific functionality is wired up, with an emphasis on reverse-engineering ACPI methods to figure out how to make things work. This one was my presentation at the main conference.

The organisers and volunteers deserve incredible gratitude for the way the conference was managed, especially considering that the CBD was underwater a week and a half earlier.

The taz (short for die tageszeitung) is one of the major German daily newspapers. And they currently feature the Squeeze release on their frontpage! The article is very good (and well investigated), managing to explain some technical details quite well, and...
It's currently the most read article! Wow! Update: The online version of the austrian newspaper der Standard has also an article about the Squeeze release!

The regular monthly board of SPI (Software in the Public Interest, the contributor-run non-profit which supports debian, drupal and many other projects not beginning with the letter d) is on IRC this evening at 20:30 UTC in #spi on irc.oftc.net. If you need an Internet Relay Chat client, check what s available in your package manager, or you could do worse than adding Chatzilla to Iceweasel or Firefox. The agenda has been posted and the reports really ought to be included by the time this blog post appears. Come along and see FOSS project support infrastructure do its thing, then maybe chat a bit afterwards.

When I started to use Emacs, I got hooked by many stuff like Gnus and Org-mode. One thing I quickly started to hate is how the Lisp code can be old and unmaintained. That especially applies to BBDB, which has been unmaintained for years, and has very very very old and obsolete code. Therefore I've decided to develop my own BBDB replacement based on my lovely Org-mode. It's called org-contacts, and it allows you to handle your contact like anything you would handle in Org. This way you can manage them the way you want, without any preset fields or any assumptions like BBDB has. I had the chance to present it at the Paris OrgCamp a couple of weeks ago, and due to the enthusiastic audience I had, I'm now releasing it to the wide Internet.

So Debian squeeze has finally been released and it is time to look toward to what we might work on or want to happen for the next release, codenamed Debian wheezy. An informal discussion on IRC mentioned libburnia libraries and apps, finishing DEP5, objnam, wayland, multiarch, Matthew Palmer plans to work on netcfg, ifupdown and the KDE team plan to remove Qt3/KDE3. I personally plan to work on catching up with my packages, the removal of defoma, boosting the Debian games team, improving collaboration with derivatives, changes to the Debian wiki, reviewing more packages mentioned on debian-mentors and more. I am really excited to see the cross-distro collaboration of Enrico Zini and others in bringing application management to Linux distributions, the multiarch work by Steve Langasek and others and hopefully optimistic about the recent discussions of automated post-install testing. I probably will not work on almost all of these but I would like to see multiarch, cross compiliation, widespread systemd integration, netconf revival, porting to phones/tablets, OEM mode and media for d-i, partitioning improvments for d-i, widespread automated post-install testing, expansion of daca, deployment of debexpo, widespread adoption of PET, automated removal of bad packages, better pro-active security measures, building all packages on buildds, migration away from Debian-specific stuff in favour of cross-distro solutions, addition of new UI experiences (like MeeGo, Android, Unity, QtMoko), addition of new APIs for portability (like Android, Khronos, MacOS/iOS stuff), more interesting/weird ports, merging derivatives into Debian, better integration of Debian Pure Blends, removing non-free packages where free alternatives exist, ex-developers and MIA folks returning to Debian, expansion of the backports repository, fixes for lots of bugs and probably other things I forgot. What are you going to work on? What do you wish you could work on? What work are you hoping others will do? What work are you excited about that others are doing?

The last weeks before a Debian release are usually boring with respect to working on new stuff since unstable is pretty much closed to development. Now that the release is finished, this fun is back \o/ I have been in an upload frenzy since yesterday night and I have updated some packages in unstable: KOffice[1] and KOffice-l10n 2.3.1, yakuake, rsibreak and tintin++. Another of my packages, kid3, got magically updated itself in unstable before I had time to look at it, the magic of having active co-maintainers. [1] Thanks for the gentle push to update this, Pino :) I also emailed one of my upstream maintainers to ask him about the KDE 4 version of his application and he will likely make a release soon. One of the goals for wheezy is remove completely KDE 3 and Qt 3. If you are maintaining a KDE 3 or Qt 3 based application, we are about to start annoying you about this! See http://wiki.debian.org/kdelibs4c2aRemoval and http://wiki.debian.org/qt3-x11-freeRemoval The last 2 weeks before the release I had some fun watching how the Squeeze release countdown banner I published at http://news.debian.net spread to a lot of websites, personal blogs, community sites, forums to news portals.
The traffic has been increasing little by little through the 2 weeks the banner has been online and currently is still moderately high, since people keeps retweeting the news item about the Debian release. While writing these lines, the banner has been served 449575 times to a total of 244975 unique IP addresses!

FOSDEM ended yesterday and here I am sitting at Charleroi Airport (also known as Brussels South , quite a misleading name given that it s 80 Km from Brussels). I have already passed all controls, check-in and everything. While I wait for boarding, I am watching the shameful spectacle of airport personnel (let me reiterate that: airport personnel, not Ryanair s) enforcing RyanAir s 10 Kg cabin baggage limit. According to RyanAir, they want to minimize the weight the plane carries to use less fuel. So far, so good. Here is what I have seen: people who do not carry any baggage (very few, they have probably checked it in because it exceeded size or weight), people who are below the 10 Kg limit and people who are way over it (and have been told to check luggage in). I am OK with those cases. There is still a fourth case: people who are slightly over 10 Kg. I ve seen a woman whose bag was 10.15 Kg to be told to pay 20 EUR to check her bag, or go back to the RyanAir desk to check-in the bag. She opened her bag, took a scarf, put it on and now the bag matched the weight limit. Yes, RyanAir is charging 20 EUR/Kg for hand baggage from 10 Kg on. What a rip-off. A couple of East-European girls were about 1 Kg in excess each. They put a couple of extra jumpers on and now baggage was under 10 Kg. Many people were about 1 Kg in excess. When they were told their suitcase better got lighter or pay 20 to 40 EUR. Most of them just took something (camera, food, slippers, whatever) and put in the pockets of their coats. Fortunately, RyanAir is not charging for body and clothes weight (yet?). In all those cases the plane will end up transporting the same weight and RyanAir won t get one more dime, so why RyanAir? Why are you such a shameful company? Why are you enforcing ludicrous and pointless policies? Don t you know after passing the control everybody just put everything back into the suitcase? Of course you do. So after watching this ridiculous spectacle go on for a while, I had a devious idea: let s organize a fat people conference and fly them all over to and from using RyanAir. Further, all of them should carry exactly 10 Kg hand baggage.

This is the gazillionth entry on Planet Debian about Squeeze being released. If I had to say one thing about it, it would be that I think the way it was handled this time has been really great. The debian-publicity team, lead by the tireless Reichles, did great job in doing as many buzz as possible around that release....but managed to do it in the "spirit" of free software (pushing release parties, animating a feed on identi.ca, preparing press releases, etc.). The Release Team did a tremendous job during the 6 months of the freeze, by carefully balancing between conservatism and liberalism in accepting (or denying) our gazillion of request for freeze exceptions The FTP, CD, installer, website, documentation teams organized things really well for their respective fields of responsibility. A special mention to the tremendous effort done about the release notes, release announcements documents (and of course, their translators). I'm currently busy upgrading my servers (at home and at work) and things are going smoothly (except the first two I did without carefully reading warnings about missing firmwares...they're now waiting for me to provide them with the right non free firmware packages, 30km away from here). And, for myself, I celebrated the release this morning by squashing my personal best time on an half-marathon (officials races excepted) by nearly 7 minutes, bringing it just below 1h45 (PB in official races is 1h37). Release power! :) And, during that afternoon, I also had the please of having my pet package (geneweb) and my most important package (samba) having their first release in unstable, targeted for wheezy. Squeeeeeeze meeeeeeeeeeeee!

Could some please put a picture of one of the new spacefun themed T-Shirts somewhere? I really want to see them... Update: Christoph Kluenter was so nice to upload some pictures.

It's been reported for some time now that the number of active editors on Wikipedia (usually defined as people who have edited at least 5 times in a given month) peaked in 2007 and has been mostly stable since then. A graph of the total number of active editors in every month since Wikipedia's founding is shown below. The graph shows the aggregate numbers for all language Wikipedias. English Wikipedia is the largest component of this and is generally more variable. That said, very similar patterns exist for most larger languages. Felipe Ortega, who has provided many of these statistics, has warned against fatalist claims. Although there seems to be a decrease in the total number of active editors over the last two years, the situation seems to have somewhat stabilized in most languages. New editors in Wikipedia are replacing folks at almost the rate that they are leaving. It is also widely known that the number of readers of Wikipedia has been increasing during this period. According to the report cards released by the foundation using comScore data, the number of unique visitors to Wikipedia each month has increased by 61 million people in the last year -- over 17%. This discrepancy between rising readership and stable or sinking editorship should raise major concern. After all, the Wikimedia Foundation's mission is two part: (1) to empower and engage people around the world to collect and develop educational content and (2) to disseminate it effectively and globally. Although the Foundation report cards include measures of raw levels of editorship, a better metric of engagement and empowerment might be the proportion of readers who engage in editing. I could not find reliable data on the number of unique readers reached each month for more than a few months in the last year. What is available, however, is wonderful data on page views each month going back to 2008. Analysis of the data from available report cards show that, at least during the last year, there is a very stable ratio of 35 page views per unique visitor, as estimated by comScore. Using that measure, we can do a back of the envelope estimation on the proportion of users that are editors for the period where page view data is available, dating back from February 2008 ( marked with the grey dashed lined above). The graphs below show the very different results you get when you consider the change in the number of Wikipedia editors and the change in the editor-to-reader ratio. Once again, these data are combined data for all language Wikipedias although graphs look very similar for most larger languages. The results are striking. Although there has been a 12% decrease between February 2008 and December 2010 in the number of active editors, there is a 42% decrease in the proportion of readers who edit at least five times a month. We can see that fulfilling the first half of the Wikimedia mission remains a struggle. Although the graphs above do not say anything directly about the most active core contributors to Wikipedia, the fact that Wikipedia is being maintained by a tiny -- and shrinking -- proportion of its readership does mean that the idea behind Wikipedia is under threat. Although none are as big as Wikipedia, there are lots of good encyclopedias out there. The reason Wikipedia is different, interesting, and important is because -- unlike all those others -- Wikipedia is the encyclopedia that anyone can edit. Wikipedia is powerful because it allow its users to transcend their role as consumers of the information they use to understand the world. Wikipedia allows users to define the reference works that define their understanding of the their environment and each other. But 99.98% of the time, readers do not transcend that role. I think that's a problem. Worse, that the number is growing. The Wikimedia Foundation recently ran a major successful effort to attract donations in its annual fundraiser. Jimmy Wales' smiling mug is apparently enough in the way of motivation to get something like 1% of its readers to donate money to support the project. I think that's very good news. If the Wikimedia community can entice even half of those people to contribute through an increased involvement in the projects themselves, they might do more than ensure Wikipedia's continued growth. They would help take a step toward the empowerment and engagement of those users in sharing their own knowledge, and the continued fulfillment of a critically important mission.

As you probably already know, Debian released Squeeze aka Debian 6.0 this week-end. It was a really great week-end. I saw quite a few release already, but none with so much online social activity. Alexander and Meike Schmehl live commented the release on the Debian identi.ca account and Joey Hess held his Debian Party Line. On top of this, the team in charge of the website rolled out a new design on quite a few online services during the week-end including www.debian.org, wiki.debian.org, planet.debian.org and more. Congratulations to all the people who made this happen (and the release team in particular). It s great to see Debian achieve all of this. Do you know that it s the third time in a row that we manage to release in the 18-24 months timeframe? 3.1: June 2005 4.0: April 2007 5.0: February 2009 6.0: February 2011. Yes, despite our size and the fact that we are all volunteers, we have managed to stick to a reasonable schedule for a stable distribution that is deployed on a large scale. Wheezy kicks off The best part of the release for us the developers is that wheezy is now open for development and we can work on new features for the next release. And it started quickly: according to UDD, wheezy already features 488 new source packages that are not in squeeze, 1713 updated source packages and among those 1246 are new upstream versions. I really look forward to the upcoming projects and related discussions.

Click here to subscribe to my free newsletter and get my monthly analysis on what s going on in Debian and Ubuntu. Or just follow along via the RSS feed, Identi.ca, Twitter or Facebook.

---

For the curious, here are the UDD queries I used:

# Updated packages in wheezy
select count(source) from sources_uniq as su where (select version from sources_uniq where release='squeeze' and distribution='debian' and source = su.source) < su.version and release='wheezy' and distribution='debian';
# Updated with a new upstream version
select count(source) from sources_uniq as su where debversion(regexp_replace((select version from sources_uniq where release='squeeze' and distribution='debian' and source = su.source), '-.*', '')) < debversion(regexp_replace(su.version, '-.*', '')) and release='wheezy' and distribution='debian';
# New package in wheezy
select count(source) from sources_uniq as su where source not in (select source from sources_uniq where release='squeeze' and distribution='debian' and source = su.source) and release='wheezy' and distribution='debian';

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

One of the many Free Software projects I work on is JFFNMS, which is a network management system written in PHP. In light that the last IPv4 address blocks have now been allocated to APNIC it s probably timely to look at how to manage network devices in a new IPv6 world. First you need to get the basics sorted out and for that it is best to use the net-snmp command line utilities to check all is well. Then its onto what to do in JFFNMS itself. Now fixed with proper markup, I hope.

    strlcpy(hostname, a1, sizeof(hostname));
        if ((pptr = strchr (hostname, ':')))  
            remote_port = strtol (pptr + 1, NULL, 0);
         

Special Agent 6 All devices that are capable of being managed with SNMP have an agent. It s basically the SNMP server on the router, switch or server. The first step is to make sure it can accept and send traffic using IPv6. Depending on what the device is, it can be real simple. For example, my little Juniper router its a matter of setting the community and access control, just like IPv4 settings:

csmall@juniper1# set snmp community public clients 2001:db8:62:d0::/64

And then run snmpget on the command line to check

csmall@elmo$ snmpget -v 1 -c public udp6:2001:44b8:62:d0::4 system.sysObjectID.0
SNMPv2-MIB::sysObjectID.0 = OID: SNMPv2-SMI::enterprises.2636.1.1.1.2.41

We have success! For Linux systems that use net-snmp you will need to make the snmp daemon listen on UDPv6 ports as well as adjusting the access control. Access control is a matter of adding com2sec6 lines to /etc/snmp/snmpd.conf They are the same format as com2sec lines and are reasonably straight forward. Next, get the daemon to listen to requests on the IPv6 ports as well. The snmpd(8) man page says:

By default, snmpd listens for incoming SNMP requests on UDP port 161 on all IPv4 interfaces. However, it is possible to modify this behaviour by specifying one or more listening addresses as arguments to snmpd.

It wouldn t of killed them to put comma separated list somewhere, now would it? My /etc/default/snmpd file now looks like:

SNMPDOPTS= -Lf /dev/null -u snmp -g snmp -I -smux -p /var/run/snmpd.pid udp:127.0.0.1,udp6:[::1]:161

The bits in bold are the changes. Then its a quick check:

csmall@elmo$ snmpget -v 1 -c public udp6:[::1] system.sysObjectID.0
SNMPv2-MIB::sysObjectID.0 = OID: NET-SNMP-MIB::netSnmpAgentOIDs.10

And we have working agents! JFFNMS Changes OK, we have a working IPv6 network and snmp works across our network so we can query devices. JFFNMS uses PHP so all should be well, shouldn t it? Database Tables This is an almost classic problem with converting IPv4 to IPv6. You have 15 bytes for a IP address string 111.222.333.444 . Ipv6 can be much larger than that. JFFNMS has things like

  CREATE TABLE  hosts (
    [...]
   ip  char(20) NOT NULL default '',

A simple fix to use a char(39) or varchar(39) will do the trick. Fixing the JFFNMS code One of the most troubling problems with the host entries is that the values entered by a user can be a hostname, IP address or IP address and port separated by a colon. There are lots of bits of code that separate out the port or address by just finding the colon or use non-IPv6 aware functions like gethostbyname() that will need to be fixed. I ve got a function to check for an IPv6 address, using the inet_pton() function.

  function is_ipv6($addr)
 
  $net_addr = @inet_pton($addr);
  if ($net_addr === FALSE   strlen($net_addr) < 16)
    return FALSE;
  return TRUE;
 

PHP functions PHP still has the old IPv4 only functions, but unlike libc does not have the Address Family independent functions. The most significant absence is the replacement functions for gethostbyname(). There is dnsgetrecord() but it is quite low-level (it won t recurse lookups if you get alias or CNAME results). It s a little hit and miss in PHP-land with what functions work with IPv6 addresses and what ones do not. fsockopen() and file() do work with IPv6. PHP and SNMP To query remote devices using SNMP, JFFNMS uses the PHP SNMP functions. Unfortunately, while there is some IPv6 support in PHP, it doesn t extend to the SNMP functions. The library does it, as the net-snmp command lines use the same library, it is just that the small shim between the script and net-snmp that is PHP gets in the way. Looking at the PHP code itself you find things like

    strlcpy(hostname, a1, sizeof(hostname));
        if ((pptr = strchr (hostname, ':')))  
            remote_port = strtol (pptr + 1, NULL, 0);
         

which definitely need to be fixed for IPv6. There is also some simple address lookup going on somewhere as well which will also need to fixed. In short, JFFNMS won t be doing SNMP based queries over IPv6 until php5-snmp can do it. Reachability JFFNMS also has a different sort of query called a reachability type. It s essentially a ping from the server running JFFNMS out to the device being managed. It uses fping to do this work, but there is also a program called fping6. It s a simple matter of checking the address type and then selecting fping or fping6 to do the reachability work. The JFFNMS code soon to be pushed into git has this change in it now. Anything Else? The next stage is to find anything else that will work with IPv6. A likely candidate is the TCP and UDP port types as they use nmap to discover the ports and the fsockopen() function call to poll it. fsockopen() does handle IPv6 addresses if you escape them in square brackets.

DebianNYC is having a Squeeze release/super bowl party this Sunday. It is in Park Slope, Brooklyn, and there will be both super bowl watchers and Debian installers/hackers who didn't know the super bowl was this weekend. For more information and to RSVP, see the wiki.Someone in IRC had the bright idea to have a "upgrade to half-broken testing" party in a few weeks. This sounds a lot more fun - and educational. We have been having so many events lately that I am a bit worried about having things too close together, so I guess we'll take it as it comes and people want to organize things. In the near future, we could have a Novice Night in Brooklyn, a Novice Night in the Bronx, a workshop on configuration management of clusters, and now this testing upgrade party.

The bug webinterface of the Ultimate Debian Database currently knows about the following release critical bugs:

In Total:	574
Affecting Squeeze:	2
Squeeze only:	2
Remaining to be fixed in Squeeze:	0

Of these 0 bugs, the following tags are set:

Pending in Squeeze:	0
Patched in Squeeze:	0
Duplicates in Squeeze:	0
Can be fixed in a security Update:	0
Contrib or non-free in Squeeze:	0
Claimed in Squeeze:	0
Delayed in Squeeze:	0
Otherwise fixed in Squeeze:	0

Ignoring all the above (multiple tags possible) 0 bugs need to be fixed by Debian Contributors to get Debian 6.0 Squeeze released. However, with the view of the Release Managers, 2 need to be dealt with for the release to happen. Please see Interpreting the release critical bug statistics for an explanation of the different numbers.

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 !!

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.

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.

Time for a third Debian XSF News issue! Debian XSF News #3

• Julien Viard de Galbert keeps on triaging bugs: TXBW9+10+11.
• After having taken some advice from Sven Joachim, I uploaded mesa 7.10 to experimental. I made both dh_install and dh_makeshlibs stricter, which triggered a FTBFS on i386 and sparc respectively. The former is fixed in git already, the latter still needs to be fixed. mesa 7.9 was already failing on non-Linux ports, and that s still happening for 7.10.
• I uploaded xkeyboard-config 2.1 to experimental. It is the source package for both xkb-data and xkb-data-udeb, which contain XKB configuration data. As mentioned in the changelog that s a big jump (3 upstream releases at once). While preparing it, I noticed a significant size increase: the udeb grew from 3.1MB to 3.5MB. Since size matters in the Debian Installer, I tried compressing the files shipped in the udeb, getting rid of a bunch of extra whitespaces and comments. A few tests seem to show no regressions, and the size went down to 2.6MB. Yay!.
• I did some heavy bug triaging myself, attacking some source packages: xkeyboard-config, mesa, and xorg-server. All in all, I managed to send 80+ mails in less than 16 hours, meaning 5+ answers per hour in average. I spent some more time after that, reaching 150+ mails in less than a week. Many bugs got closed, which can be seen on Mike Hommey s BTS graphs. The most interesting graph can be seen below.
• I closed a very old bug.
• I uploaded a new release candidate for xorg-server 1.9.4 to experimental. Nothing fancy on the upstream side (mostly XQuartz fixes), but on the Debian side, an update of the bug script. As a reminder, that s the script run by reportbug to collect information about the system. That should help us spot more common issues.
• The bug script update was cherry-picked into xorg-server 2:1.7.7-12 for unstable, along with two bugfixes. If everything goes fine, we might try and get it accepted for squeeze s r1 (in other words: the first point release for squeeze).
• I finally managed to get mesa to work on my Intel board enough to let me test wayland. Having a look at the architecture (it has pictures!) and at the FAQ should help interested folks to understand what this is all about. I opened an ITP for it, as well as one for libxkbcommon. The latter is already uploaded and sitting in NEW. We ll also need GL support in cairo, so I requested it.
• I should stress a few points: wayland is really at an early stage of development; all that is going to be shipped for now is a sample compositor implementation and a few sample clients for people to play with. Maybe wayland is going to replace X some day, but it should be noted that it comes with heavy requirements, like GL/EGL support. It s nice since many features and bugfixes are going to land in mesa, but that means that it s going to be available on a restricted class of hardware only, as opposed to X s ability to run more or less anywhere. This also means that early testers might need a pretty recent mesa snapshot. I ll try to make that easier, or at least well-documented. (Many thanks to Darxus for the review.)

It s been a year On a personal note, it s been a year to the day since I first looked into X. After having hacked on the Debian Installer to make it use X.Org instead of DirectFB, I did some heavy bug triaging, resulting in a drop in the xorg-server bug count in March. The same happened past week as written above, resulting in a second drop. In the meanwhile, the bug count remained more or less stable, since we try to reply quickly to new bugs, and since Julien Viard de Galbert does bug triaging on a weekly basis: One might ask: what does maintaining X mean?

• Packaging mostly everything X-related.
• Taking care of incoming bug reports as well as older ones.
• Working with upstream (which is going to be the subject of a later blog post), as well as coordinating with Ubuntu.
• Keeping an eye on the Graphical Installer.
• Writing documentation targeted at both users and maintainers.
• Advertising XSF s work.

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.

---

Debian Med Bioinformatics Sprint Last weekend, I was at the Debian Med Meeting in Travem nde near L beck, thanks to an invitation by Steffen M ller and Andreas Tille. It was a great opportunity to finally meet Steffen and some of the other bioinformatics people in Debian like Manuel Prinz face-to-face for the first time. Also, lots of upstream and related bioinformatics packagers from e.g. Biolinux were present as well, many of them from the UK. I discussed with and helped some people about Debian packaging. There is a big push to get Debian packages done and integrated in Debian and Ubuntu, but often enough people are not exactly sure what the requirements are and what needs to be done. Hopefully, the sprint was successful to clear things up and move forward. I also managed to finalize the initial Jmol packaging and uploaded it to Debian towards the end of the sprint. I plan to update the other bioinformatics related packages in debichem like pymol and openbabel as soon as squeeze is released. Overall, it was a great weekend, many thanks to NERC and Debian for making it possible, and to Steffen M ller for organizing it!