You are here: Home / Archives for 2011

300 EUR for Debian

December 20, 2011 By

It’s the amount of the wire transfer that I made to ffis e.V., the German association that works together with Software in the Public Interest to hold Debian’s monetary assets.

This amount includes the 10% of the benefits of my Debian DVD sales (for a total of 47 USD =~ 36 EUR) and the 15% affiliate revenue that was granted to Debian by some supporters of the Debian Administrator’s Handbook crowdfunding campaign (for a total of 259.49 EUR).

Thank you everybody, this donation is really yours and not mine!

If you want to complement this donation, and make a nice gift to Debian for Christmas, go to this page and follow the instructions.

Filed Under: Debian News, News Tagged With: , , ,

“3.0 (quilt)” is the most widely used Debian source package format

December 15, 2011 By

My goal with the “3.0 (quilt)” source format has always been to standardize the patch management in Debian source packages. This message seems to have been well understood. dbs and dpatch have been deprecated by their respective maintainers.

I made numerous efforts to make this source format useful in as many use cases as possible (but some improvements are still possible) and I have added hints to encourage maintainers to switch. Thanks to this, the adoption rate of this new source format has been very good and it’s now the most widely used source package format in Debian—only two years after its introduction in Debian unstable.

With 9829 source package using “3.0 (quilt)”, it surpassed the number of source package still using “1.0″ (7368). (Those numbers have been taken from http://upsilon.cc/~zack/stuff/dpkg-v3/ on december 13th 2011.) The number of source packages using “3.0 (quilt)” doubled this year.

(Click on the picture to see it full size)

Of the 7368 packages using the old format, 6816 packages trigger the missing-debian-source-format lintian tag. This means that only 552 source packages have explicitly opted to keep using the old format and that the bulk of the remaining packages are rarely updated packages that have not been switched yet.

Filed Under: Debian News, News Tagged With: , , , ,

People behind Debian: Ben Hutchings, member of the kernel team

December 13, 2011 By

Ben Hutchings, photo by Andrew Mc Millan, license CC-BY-2.0

Ben Hutchings is a rather unassuming guy… but hiding behind his hat, there’s a real kernel hacker who backports new drivers for the kernel in Debian stable so that our flagship release supports very recent hardware.

Read on to learn more about Ben and the kernel team’s projects for Debian Wheezy!

Raphael: Who are you?

Ben: I’m a professional programmer, living in Cambridge, England with my long-suffering wife Nattie. In Debian, I mostly work on the Linux kernel and related packages.

Raphael: How did you start contributing to Debian?

Ben: I started using Debian in 1998 and at some point I subscribed to Debian Weekly News. So in 2003 I heard about the planned Debian 10th birthday party in Cambridge, and thought I would like to go to that. Somehow I persuaded Nattie that we should go, even though it was on the day of our wedding anniversary! We both enjoyed it; we made new friends and met some old ones (small world). From then on we have
both been socially involved in Debian UK.

In 2004 there was a bug-squashing party in Cambridge, and we attended that as well. That’s where I really started contributing – fixing bugs and learning about Debian packaging. Then in 2005 I made my first package (sgt-puzzles), attended DebConf, and was persuaded to enter the New Maintainer process.

NM involved a lot of waiting, but by the time I was given questions and tasks to do I had learned enough to get through quite quickly. In April 2006 I was approved as a Debian Developer.

Meanwhile, I looked at the videos from DebConf 5 and thought that it would be useful to distribute them on a DVD. That led me to start writing video software and to get involved in the video team for the next year’s DebConf.

Raphael: You have been one the main driver behind the removal of non-free firmwares from the kernel. Explain us what you did and what’s the status nowadays?

Ben: That’s giving me a bit more credit than I deserve.

For a long time the easy way for drivers to load ‘firmware’ programs was to include them as a ‘blob’ in their static data, but more recently the kernel has included a simple method for drivers to request a named blob at run-time. These requests are normally handled by udev by reading from files on disk, although there is a build-time option to include blobs in the kernel. Several upstream and distribution developers worked to convert the older drivers to use this method. I converted the last few of these drivers that Debian included in its binary packages.

In the upstream Linux source, those blobs have not actually been removed; they have been moved to a ‘firmware’ subdirectory. The long-term plan is to remove this while still allowing the inclusion of blobs at build-time from the separate ‘linux-firmware’ repository. For now, the Debian source package excludes this subdirectory from the upstream tarball, so it is all free software.

There are still a few drivers that have not been converted, and in Debian we just exclude the firmware from them (so they cannot be built). And from time to time a driver will be added to the ‘staging’ section of Linux that includes firmware in the old way. But it’s understood in the kernel community that it’s one of the bugs that will have to be fixed before the driver can move out of ‘staging’.

Raphael: Do you believe that Debian has done enough to make it easy for users to install the non-free firmwares that they need?

Ben: The installer, the Linux binary packages and initramfs-tools will warn about specific files that may be needed but are missing. Users who have enabled the non-free section should then be able to find the necessary package with apt-cache search, because each of the
binaries built from the firmware-nonfree source package includes driver and file names within its description. For the installer, there is a single tarball that provides everything.

We could make this easier, but I think we have gone about as far as we can while following the Debian Social Contract and Debian policy.

Raphael: At some point in the past, the Debian kernel team was not working very well. Did the situation improve?

Ben: Back in 2008 when I started working on the Linux kernel package to sort out the firmware issues, I think there were some problems of communication and coordination, and quite possibly some members were burned-out.

Since then, many of the most active kernel team members have been able to meet face-to-face to discuss future plans at LPC 2009 in Portland and the 2010 mini-DebConf in Paris. We generally seem to have productive discussions on the debian-kernel mailing list and elsewhere, and I think the team is working quite well. Several new contributors have joined after me.

I would say our biggest problem today is that we just don’t have enough time to do all we want to. Certainly, almost all my Debian time is now taken up with integrating upstream kernel releases and handling some fraction of the incoming bug reports. Occasionally I can take the time to work on actual features or the other packages I’m neglecting!

“Our biggest problem today is that we just don’t have enough time to do all we want to.”

Raphael: It is widely known that Linux is maintained in a git repository. But the Debian kernel team is using Subversion. I believe a switch is planned. Why was not git used from the start?

Ben: The linux-2.6 source package dates from the time when Linus made his first release using git. I wasn’t part of the team back then so I don’t know for sure why it was imported to Subversion. However, at that time hardly anyone knew how to use git, no-one had experience hosting public git repositories, and Alioth certainly didn’t offer that option.

Today there are no real blockers: everyone on the kernel team is familiar with using git; Alioth is ready to host it; we don’t have per-architecture patches that would require large numbers of branches. But it still takes time to plan such a conversion for what is a relatively complex source package (actually a small set of related source packages).

Raphael: What are your plans for Debian Wheezy?

Ben: Something I’ve already done, in conjunction with the installer team, is to start generating udebs from the linux-2.6 source package. The kernel and modules have to be repacked into lots of little udebs to avoid using too much memory during installation. The configuration for this used to be in a bunch of separate source packages; these could get out of step with the kernel build configuration and this would only be noticed some time later. Now we can update them both at the same time, they are effectively cross-checked on every upload, and the installer can always be built from the latest kernel version in testing or unstable.

I think that we should be encouraging PC users to install the 64-bit build (amd64), but many users will still use 32-bit (i386) for backward compatibility or out of habit. On i386, we’ve slightly reduced the variety of kernel flavours by getting rid of ’686′ and making ’686-pae’ the default (previously this was called ’686-bigmem’). This means that the NX security feature will be used on all systems that support it. It should also mean that the first i386 CD can have suitable kernel packages for all systems.

I have been trying to work on providing a full choice of Linux Security Modules (LSMs). Despite their name, they cannot be built as kernel modules, so every enabled LSM is a waste of memory on the systems that don’t use it. This is a significant concern for smaller Debian systems. My intent is to allow all unused LSMs to be freed at boot time so that we can happily enable all of them.

I recently proposed to drop support for older x86 systems, starting with 486-class processors in wheezy. In general, this would allow the use of more compiler optimisations throughout userland and the kernel. However it seems that there isn’t that much to be gained unless we also drop 586-class processors, and there are still quite a few of those in use. So I think this will have to wait.

Uwe Kleine-König has been working to include real-time support (also known as PREEMPT_RT). This can provide low and very predictable I/O latency, which is useful for live audio synthesis, for example. It still requires a number of patches and a build configuration change, resulting in a separate binary package. We’re currently only building that for 64-bit PCs. (You may notice this is missing for Linux 3.1, because the real-time developers skipped this release.)

Raphael: What’s the biggest problem of Debian?

Ben: I think we try too hard to accommodate every possible option, without regard for the cost to developers and users in general. As an example, we now have sysvinit, file-rc, upstart and systemd all in testing. Daemon maintainers can’t rely on any advanced features of upstart or systemd because we refuse to choose between them. And the decision to support the FreeBSD kernel means that we cannot choose upstart or systemd as the only option. So all daemon maintainers will have to maintain those baroque init scripts for the indefinite future. We really should be able to decide as a distribution that when one option is technically good and popular then it can be made the only option. But no-one really has the authority to do that, so we muddle along with the pretence that all the options are equally valid and functional, while none of them is supported as well as they should be.

“We try too hard to accommodate every possible option, without regard for the cost to developers and users in general.”

We also try to build every package on every architecture, in general. I’m quite sure there are many (package, architecture) combinations that have no users, ever. But if at some point that combination FTBFS, developers will waste time investigating and fixing that – time that could have been spent working on bugs and features that users actually care about. Yes, sure, portability is good but you can’t prove portability just by making a package compile on every architecture. This also applies to the selection of drivers for the kernel, by the way.

Raphael: Is there someone in Debian that you admire for their contributions?

Well, there are many people, but I will pick out just a few:

Steve McIntyre, for his work as DPL to improve communication with the various Debian derivatives and to bring fresh blood into various core teams. Also for being a generous host for countless Debian social and bug-squashing events.

Stefano Zacchiroli, for improving further on communications with both downstream and upstream projects, and for regularly exercising his power to lead discussions to the benefit of the project.

Julien Cristau, for maintaining good humour while not only fighting against the tide of graphics driver regressions in X and the Linux kernel but also working on release management.

Jonathan Nieder, for taking on the unglamorous and frustrating task of kernel bug triage as a non-maintainer and developing it to a fine art.

Thank you to Ben 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, Google+, Twitter and Facebook

.

Filed Under: Debian News, News Tagged With: , , , ,

My Debian Activities in November 2011

December 2, 2011 By

This is my monthly summary of my Debian related activities. If you’re among the people who made a donation to support my work (310.73 €, thanks everybody!), then you can learn how I spent your money. Otherwise it’s just an interesting status update on my various projects.

Dpkg: Multi-Arch Saga

I know lots of people are waiting the landing of multiarch in Debian unstable, and so am I. Things are progressing, though not as quickly as I hoped. Guillem merged about half of the branch between the 24th October and the 6th of November. After that most of the work happened on his personal repository in his pu/multiarch/master branch.

I verify this repository from time to time because Guillem does not inform me when he has made progress. I noticed changes on his repository on the 10th, 19th, 23th, 28th of November and on the 1th of December.

He announced a long time ago that he had some “interface changes” and up to now only wrote about the switch from the command-line option --foreign-architecture (to put in /etc/dpkg/dpkg.cfg) to the explicit command dpkg --add-architecture that only needs to be called once (see mail here). As of today (December 2th), the promised email for the other interface changes is still not here.

On November 23th, I reviewed Guillem’s work and tried to run the code in his branch. I spent the whole day chasing up regressions and submitted lots of fixes to Guillem. Thanks to the extensive test-suite I wrote when I developed my branch, it has been fairly easy to track them all down.

All the issues I reported have been fixed in the latest version of Guillem’s branch although the fixes are often slightly different from those that I submitted.

Dpkg: Squeeze Backport

At the start of the month, I uploaded what I expected to be a fairly uncontroversial backport of dpkg 1.16.1.1. It turns out I was wrong.

After some discussion, I think we came to an agreement that it was acceptable to backport dpkg-dev and libdpkg-perl only. My goal was not to bring the latest dpkg to users but to make it easier for package maintainers to backport packages using new features provided by dpkg-dev >= 1.16 (such as hardening build flags, the makefile snippets provided in /usr/share/dpkg/, or the improved dpkg-buildflags interface).

Thus I modified the source package uploaded to squeeze-backports to build only dpkg-dev and libdpkg-perl. It has been uploaded on November 23th and it’s waiting in the NEW queue for a backports admin to process it.

Misc Dpkg Work

I merged a patch of Colin Watson to be able to verify build-dependencies for a foreign architecture (taking into account the Multi-Arch status of each package listed).

I released dpkg 1.16.1.2 with two minor fixes that were sitting in the sid branch. I wanted to get rid of this so that the path is clear for a 1.16.2 upload with multiarch. The package just migrated to testing so we’re fine.

I spent another day doing dpkg bug triaging on Launchpad, we’re now down to 77 bugs with many of them tagged as incomplete and likely to expire in 2 months.

The Debian Administrator’s Handbook

eBookWe released a sample chapter so that it’s easier to have an idea of the quality of the book. The chapter covers the APT tools quite extensively. I bet that even you could learn something about apt-get/aptitude…

The crowfunding campaign on Ulule ended on November 28th.
With 673 supporters, we raised 24345 EUR. Of those, 14935 EUR have been put in the liberation fund and the rest corresponds to the various pre-orders and rewards offered.

This means that the translation will happen (we just started) but that the book is currently not going to be released under a free license. Don’t despair… As planned, the liberation campaign is carried on until the 25 K€ target is reached!

Instead of being hosted on Ulule, this permanent campaign is on the project website at debian-handbook.info/liberation/. Note that any contribution of 10 EUR or more means that you get a copy of the ebook as soon as it’s available (even if the liberation target is not reached).

Package Tracking System

At the start of the month, I filed two ideas of improvements for the PTS in the bug tracking system: #647258 is about showing outstanding bugs that relate to a release goal and #647901 is about warning maintainers that the package is affected by a current transition. If you’re a coder and want to start contributing to Debian and its QA team, those bugs could be interesting targets for a start. :-) In both cases, I have been in contact with members of the release team because those ideas require some structured data from the release team as input. Thanks to Meddi Dohguy and Niels Thykier for their help.

Later in the month, the topic of relocating the PTS once again came up. For historical reasons, the PTS was hosted on master.debian.org together with the BTS. Nowadays the BTS has its own host and it made no sense anymore to have the PTS separate from the rest of the QA services hosted on qa.debian.org (currently quantz.debian.org). So together with Martin Zobel Helas we took care to plan the migration and on November 19th we executed the plan. It worked like a charm and almost nobody noticed (only one undocumented dependency was missed, which broke the SOAP interface).

Misc Packaging Work

WordPress was broken in Ubuntu and it was also not properly synchronized with Debian due to an almost useless change on their side. Thus I requested a sync so that the working version from Debian gets imported in Ubuntu.

I sponsored the docbook-xsl 1.76.1 upload that I needed for Publican. Then I updated Publican just to discover that the test-suite triggers a new bug in fop (filed as #649476). I disabled the test-suite temporarily and uploaded Publican 2.8 to unstable. BTW, I also filed 2 upstream bugs with patches for issues I discovered while trying to generate the sample chapter of my book (see here and here).

I uploaded a version 0.7.1 of nautilus-dropbox and fixed #648215 at the same time. I made an NMU of bison to fix a long-standing release critical bug that hit me once more during an upgrade (see #645038).

I uploaded to experimental a new version of gnome-shell-timer compatible with GNOME 3.2. I took the opportunity to install from experimental the few GNOME 3.2 packages which are not yet in unstable…

Thanks

See you next month for a new summary of my activities.

Filed Under: Debian News, Meta, News Tagged With: , , , , , ,

People behind Debian: Stefano Zacchiroli, Debian Project Leader

November 22, 2011 By

picture by Tiago Bortoletto Vaz, CC BY-NC-SA 2.0


It’s been one year since the first People behind Debian interview. For this special occasion, I wanted a special guest… and I’m happy that our Debian Project Leader (DPL)—Stefano Zacchiroli—accepted my invitation.

He has a difficult role in the community, but he’s doing a really great job of it. He’s a great mediator in difficult situations, but he’s also opinionated and can push a discussion towards a conclusion.

Read on to learn how he became a Debian developer and later DPL, what he’s excited about in the next Debian release, and much more.

Raphael: Who are you?

Stefano: I’m Stefano Zacchiroli, but I prefer to be called Zack, both on the Internet and in real life. I’m 32, Italian, emigrated to France about 4 years ago. I live in Paris, and I find it to be one of the most gorgeous and exciting cities in the world.

As my day job I’m a Computer Science researcher and teacher at University Paris Diderot and IRILL. In my copious free time™ I contribute to Debian, and I’m firmly convinced that doing so is an effective way to help the cause of Free Software. Besides, I find it to be a lot of fun!

Raphael: How did you start contributing to Debian?

Stefano: Flash back to 1999, when I was a 2nd year student in Computer Science at the University of Bologna. Back then in Italy it was uncommon for young geeks to get exposed to Free Software: Internet was way less pervasive than today and most computer magazines didn’t pay much attention to GNU/Linux. Luckily for me, the professor in charge of the student lab was a Free Software enthusiast and all students machines there were running Debian. Not only that, but there was also a student program that allowed volunteers to become sysadmins after having shown their skills and convinced the director they were trustworthy. Becoming one of those volunteer Debian admins quickly became one of my top objectives for the year, and that is were I’ve learned using Debian.

The year after that, I got in touch with a research group that was to become the happy bunch of hackers with whom I would have done both my master and PhD theses. They were designing a new proof assistant. Most of the development was in OCaml and happened on Debian. OCaml was available in Debian, but many of the libraries we needed were not. So I approached the Debian OCaml Team offering to help. Before I realize what was going on I was (co-)maintainer of tens of OCaml-related packages. At some point I got told “I think you should apply as a Debian Developer”. So I did and in a couple of months I went through the New Member (NM) process, that was back then in its infancy. I still remember my happiness while reading the “account created” mail, the day after my 22nd birthday.

I know the NM process went through some bad publicity in the past, but I’m happy to see that nowadays the process can be as swift as it has been for me 10 years ago.

Raphael: It’s your second year as Debian Project Leader (DPL). Are you feeling more productive in the role? Do you fear to burn out?

Stefano: I’m feeling way more productive, no doubts.

The task of the Debian Project Leader is not necessarily difficult, but it is a complex and scarcely documented one. It is also profoundly different from any other task that Debian people usually work on, so that experience doesn’t help much in getting started. Before becoming effective as DPL one needs to get to know many people and mechanisms he is not familiar with. More importantly, one needs to set up a personal work-flow that allows to keep up with day-to-day DPL tasks (which are aplenty) as well as with urgencies (that tend to pop-up in the leader@debian.org INBOX at the least convenient time). Finally, one also needs to do proper “traffic shaping” and always retain enough “motivation bandwidth” to keep the Project informed about what is going on in DPL-land.

Finding the right balance among all these ingredients can take some time. Once one is past it, everything goes way more smoothly.

The above is why I’m constantly encouraging people interested in running for DPL in the future to reach out to me and work on some tasks of the current DPL’s TODO list. I swear it is not just a cheap attempt at slavery!. It is rather an attempt at DPL mentoring that could be beneficial: both to give future candidates more awareness of the task, and to reduce the potential downtime when handing over from one DPL to the next.

Regarding burn out, I don’t feel prone to its risk these days. If I look back, I can say that my contributions as DPL have been pretty constant in volume over time; my enthusiasm for the task, if anything, is on the rise. The effectiveness of my contributions as DPL are, on the other hand, not mine to judge.

Raphael: If you had to single out two achievements where you were involved as DPL, what would they be?

Stefano: I’d go for the following two, in no particular order:

  • Dialogue with derivatives. When I became DPL ~1.5 years ago the situation on that front was pretty dire. In the specific case of Ubuntu, by far the most successful and customized of all Debian derivatives, I remember being scared of raising the topic of collaboration with them on mailing lists. More generally, we had no specific initiatives to foster technical collaboration with and among derivatives. A huge potential of (forwarded) contributions to Debian was being wasted.

    Today things look much better, as I’ve documented in recent talks at DebConf11 and UDS-P. The amount of forwarded patches we receive from downstream is at its maximum and many people who apply to become Debian Developers come from derivatives. Conflict situations still exist, for good reasons that we still have to either fix or figure out entirely. But I’m positive we’re on the right track.

    “The amount of forwarded patches we receive from downstream is at its maximum”

    This is by far not an achievement of mine alone. In particular, many of the activity of the Derivatives Front Desk have been organized by other enthusiastic volunteers. But I’ve done my part, especially in breaking the ice and in proposing a vision of Free Software distribution where all distros play a role and are welcome to join the game, as long as they give back and give credit to their respective upstreams.

  • Process membership. I’m proud of having promoted the general resolution (GR) that has clarified (and advertised to the world) that Debian welcomes all kind of contributions, and that they all equally matter to become proper members of the Project. I notice only now while writing this that the GR title, traditionally chosen by the secretary, was “Debian Project Members”. That choice harmonically closes the circle with the recent renaming of the NM process to “New Member” process.

    Today, we have several project members (AKA “Debian Developers”) that are active citizen of Debian with voting rights, even though they take care of tasks other than packaging. Anyone can become a Debian citizen, as long as they are ready to abide by Debian’s values, have a track record of verifiable contributions to Debian, and are committed to keep them coming in the future.

    “We have several project members that […] take care of tasks other than packaging.”

    Once gain, this is by far not an achievement of mine alone, very little project-wide achievements are. DAM has helped a lot and support from the project as a whole has been immense.

OK, let me cheat and add a third one… I’m also proud of having been able to report to the Project my whereabouts as DPL, thoroughly and periodically, since the very beginning is first term. People annoyed by my reporting logorrhea now have all my sympathies.

Raphael: Among the possible new features of Debian Wheezy, which one gets you excited most?

Stefano: It’s multi-arch, no doubt. Even though it is not a directly user visible change, it’s a very far reaching one. It is also one of those changes that make me feel that moment of truth of coders, when you realize you are finally doing the right thing and ditching piles of ugly hacks.

“It’s multi-arch […] you realize you are finally doing the right thing and ditching piles of ugly hacks.”

Raphael: If you were not DPL and could spend all your time on Debian, what project would you do?

Stefano: I would sit down and do software development for Debian.

It’s impressive how many important and beneficial changes for Debian could be delivered by specific software improvements in various parts of our infrastructure. We tend to attract many packagers, but not so many people willing to maintain Debian infrastructure softwares like dak, britney, debbugs, the PTS, etc. Their maintenance burden then falls on the shoulders of the respective teams which are generally very busy with other important tasks.

As a project, we seem to be more appealing to packagers than to software developers. That is a pity given the amount of exciting coding tasks that are everywhere in Debian. Part of the reason we are not appealing to developers is that we are not particularly good at collecting coding tasks in a place where interested developers could easily pick them up. It also takes quite a bit of inside knowledge to spot infrastructure bugs and understand how to fix them.

I long for some spare hacking time to check if I’m still good enough of a coder to hunt down longstanding bugs in our infrastructure, which have ended up being my pet peeves.

I’d also love to dive again into RCBW. It’s less committing than package maintenance, more diverse and challenging, and also an immensely useful activity to get Debian releases done.

Raphael: Martin Michlmayr is worried that there is so few paid opportunities around Debian. Do you agree with his sentiment, and if yes do you have ideas on how to improve this situation?

Stefano: The idealistic me wishes Debian to be a community made only of volunteers that devote their free time to the Project. Oh, and that me also wishes Debian to be competitive with similar projects, no matter how many full-time employees others have! That is coherent with a view of society where everyone has a day job, but also engages in volunteering activities ensuring that public interest is pursued by people motivated by interests other than profit.

But I do realize that for Free Software to succeed companies, employees, and salaries should all have a role. I admire projects that strike a good balance between volunteer and paid work. The Linux kernel is emblematic in that respect: many developers are paid by companies that have a commercial or strategic interest in Linux. Nevertheless volunteers contributions are aplenty and the Linux community gives a convincing impression that choices are driven by the community itself (or by its benevolent dictator) without money-driven impositions.

“I do realize that for Free Software to succeed companies, employees, and salaries should all have a role.”

Such an ecosystem does not exist around Debian. We do have a partner program that allows for it to happen, but we have very few partners with an interest in doing distribution development work. Like Martin, I’m worried by this state of affairs, because it de facto means we lag behind in terms of available people power. In a community of volunteers, that might frustrate people and that is not good.

To improve over the status quo the first step is to federate together small and medium companies that have a strategic interest in Debian and listen to their needs. I’m already in touch with representatives of such companies that, in many cases, already employ Debian Developers to do some distribution work in Debian. We will be soon sending out a call to reach out to more such companies, but since we are discussing this, why waiting? If some of our readers here are representative of such companies, I encourage them to get in touch with me about this.

Raphael: You know that the fundraising campaign for the Debian Administrator’s Handbook is on good track but the liberation of the book is not yet assured. What do you think of this project?

Stefano: I’m happy about the project, to the point that I’ve accepted writing a testimonial for it :-) . I’m sad about the scarce availability of up to date and high quality (DFSG-)Free books about Debian and I welcome any initiative that might help closing that gap.

“I’m sad about the scarce availability of up to date and high quality (DFSG-)Free books about Debian.”

Free Culture is a great offspring of Free Software and I’m convinced we need to stand up against double standards in the two camps. Letting aside software-specific licensing details, the basic freedoms to be defended are the same. They are those freedoms that ensure that a reader is in full control of his book, pretty much as they ensure that a computer user is in full control of the software that runs on it. I’m therefore proud that Debian has long resolved that the Debian Free Software Guidelines (DFSG) apply not only to software but also to books and other pieces of documentation.

But the status quo implies that not only we have very few up to date, high quality books about Debian. It also implies that, at present, we have no such book that we can distribute in the Debian archive, showing off the Free Software (and Free Culture!) values we stand for.
Crowdfunding is considered to be a good mate for Free Culture, where the services model that applies to Free Software is more difficult to exploit. I so wish any luck to yours and Roland’s initiative.

A different matter is whether Debian, as a project, should endorse the initiative and actively campaign for it. As you know, I think it should not. While we do advertise general project donations, we don’t do mission-specific fundraising campaign for Debian itself. Coherently with that, I don’t think we should relay crowdfunding campaigns for 3rd parties, even when the result would be beneficial to Debian.

Raphael: Is there someone in Debian that you admire for their contributions?

Stefano: There are two classes of people that I particularly admire in Debian:

  • Those with an uncanny ability to guide discussions towards constructive conclusions. We are lucky to have many in Debian and I admire all of them. Having to single out one I’d name Russ Allbery, in honor of whom I hereby propose the periodic “Russ Allbery’s Distinguished Flametamer Award”.
  • People stepping up for responsibility roles, especially when the responsibility put them in tough spots. Release teams, ftp-masters, DSA, DAM, as well as past and present members of teams with similarly “hot” seats have all my admiration.
Thank you to Zack 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, Google+, Twitter and Facebook

.

Filed Under: Debian News, News Tagged With: , , , , ,

People Behind Debian: Mark Shuttleworth, Ubuntu’s founder

November 17, 2011 By

I probably don’t have to present Mark Shuttleworth… he was already a Debian developer when he became millionaire after having sold Thawte to Verisign in 1999. Then in 2002 he became the first African (and first Debian developer) in space. 2 years later, he found another grandiose project to pursue: bring the Microsoft monopoly to an end with a new alternative operating system named Ubuntu (see bug #1).

I have met Mark during Debconf 6 in Oaxtepec (Mexico), we were both trying to find ways to enhance the collaboration between Debian and Ubuntu. The least I can say is that Mark is opinionated but any leader usually is, and in particular the self-appointed ones! :-)

Read on to discover his view on the Ubuntu-Debian relationship and much more.

Raphael: Who are you?

Mark: At heart I’m an explorer, inventor and strategist. Change in technology, society and business is what fascinates me, and I devote almost all of my time and wealth to the catalysis of change in a direction that I hope improves society and the environment.

I’m 38, studied information systems and finance at the University of Cape Town. My ‘hearts home’ is Cape Town, and I’ve lived there and in Star City and in London, now I live in the Isle of Man with my girlfriend Claire and 14 precocious ducks. I joined Debian in around 1995 because I was helping to setup web servers for as many groups as possible, and I thought Debian’s approach to packaging was very sensible but there was no package for Apache. In those days, the NM process was a little easier ;-)

Raphael: What was your initial motivation when you decided to create Ubuntu 7 years ago?

Mark: Ubuntu is designed to fulfill a dream of change; a belief that the potential of free software was to have a profound impact on the economics of software as well as its technology. It’s obvious that the technology world is enormously influenced by Linux, GNU and the free software ecosystem, but the economics of software are still essentially unchanged.

Before Ubuntu, we have a two-tier world of Linux: there’s the community world (Debian, Fedora, Arch, Gentoo) where you support yourself, and the restricted, commercial world of RHEL and SLES/SLED. While the community distributions are wonderful in many regards, they don’t and can’t meet the needs of the whole of society; one can’t find them pre-installed, one can’t get certified and build a career around them, one can’t expect a school to deploy at scale a platform which is not blessed by a wide range of institutions. And the community distributions cannot create the institutions that would fix that.

Ubuntu brings those two worlds together, into one whole, with a commercial-grade release (inheriting the goodness of Debian) that is freely available but also backed by an institution.

The key to that dream is economics, and as always, a change in economics; it was clear to me that the flow of money around personal software would change from licensing (“buying Windows”) to services (“paying for your Ubuntu ONE storage”). If that change was coming, then there might be room for a truly free, free software distribution, with an institution that could make all the commitments needed to match the commercial Linux world. And that would be the achievement of a lifetime. So I decided to dedicate a chunk of my lifetime to the attempt, and found a number of wonderful people who shared that vision to help with the attempt.

It made sense to me to include Debian in that vision; I knew it well as both a user and insider, and believed that it would always be the most rigorous of the community distributions. I share Debian’s values and those values are compatible with those we set for Ubuntu.

“Debian would always be the most rigorous of the community distributions.”

Debian on its own, as an institution, could not be a partner for industry or enterprise. The bits are brilliant, but the design of an institution for independence implies making it difficult to be decisive counterparty, or contractual provider. It would be essentially impossible to achieve the goals of pre-installation, certification and support for third-party hardware and software inside an institution that is designed for neutrality, impartiality and independence.

However, two complementary institutions could cover both sides of this coin.

So Ubuntu is the second half of a complete Debian-Ubuntu ecosystem. Debian’s strengths complement Ubuntu’s, Ubuntu can achieve things that Debian cannot (not because its members are not capable, but because the institution has chosen other priorities) and conversely, Debian delivers things which Ubuntu cannot, not because its members are not capable, but because it chooses other priorities as an institution.

Many people are starting to understand this: Ubuntu is Debian’s arrow, Debian is Ubuntu’s bow. Neither instrument is particularly useful on its own, except in a museum of anthropology ;)

“Ubuntu is Debian’s arrow, Debian is Ubuntu’s bow.”

So the worst and most frustrating attitude comes from those who think Debian and Ubuntu compete. If you care about Debian, and want it to compete on every level with Ubuntu, you are going to be rather miserable; you will want Debian to lose some of its best qualities and change some of its most important practices. However, if you see the Ubuntu-Debian ecosystem as a coherent whole, you will celebrate the strengths and accomplishments of both, and more importantly, work to make Debian a better Debian and Ubuntu a better Ubuntu, as opposed to wishing Ubuntu was more like Debian and vice versa.

Raphael: The Ubuntu-Debian relationship was rather hectic at the start, it took several years to “mature”. If you had to start over, would you do some things differently?

Mark: Yes, there are lessons learned, but none of them are fundamental. Some of the tension was based on human factors that cannot really be altered: some of the harshest DD critics of Canonical and Ubuntu are folk who applied for but were not selected for positions at Canonical. I can’t change that, and wouldn’t change that, and would understand the consequences are, emotionally, what they are.

Nevertheless, it would have been good to be wiser about the way people would react to some approaches. We famously went to DebConf 5 in Porto Allegre and hacked in a room at the conference. It had an open door, and many people popped a head in, but I think the not-a-cabal collection of people in there was intimidating and the story became one of exclusion. If we’d wanted to be exclusive, we would have gone somewhere else! So I would have worked harder to make that clear at the time if I’d known how many times that story would be used to paint Canonical in a bad light.

As for engagement with Debian, I think the situation is one of highs and lows. As a high, it is generally possible to collaborate with any given maintainer in Debian on a problem in which there is mutual interest. There are exceptions, but those exceptions are as problematic within Debian as between Debian and outsiders. As a low, it is impossible to collaborate with Debian as an institution, because of the design of the institution.

“It is generally possible to collaborate with any given maintainer […] [but] it is impossible to collaborate with Debian as an institution.”

In order to collaborate, two parties must make and keep commitments. So while one Debian developer and one Ubuntu developer can make personal commitments to each other, Debian cannot make commitments to Ubuntu, because there is no person or body that can make such commitments on behalf of the institution, on any sort of agile basis. A GR is not agile ;-) . I don’t say this as a critique of Debian; remember, I think Debian has made some very important choices, one of those is the complete independence of its developers, which means they are under no obligation to follow a decision made by anyone else.

It’s also important to understand the difference between collaboration and teamwork. When two people have exactly the same goal and produce the same output, that’s just teamwork. When two people have different goals and produce different product, but still find ways to improve one anothers product, that’s collaboration.

So in order to have great collaboration between Ubuntu and Debian, we need to start with mutual recognition of the value and importance of the differences in our approach. When someone criticises Ubuntu because it exists, or because it does not do things the same way as Debian, or because it does not structure every process with the primary goal of improving Debian, it’s sad. The differences between us are valuable: Ubuntu can take Debian places Debian cannot go, and Debian’s debianness brings a whole raft of goodness for Ubuntu.

Raphael: What’s the biggest problem of Debian?

Mark: Internal tension about the vision and goals of Debian make it difficult to create a harmonious environment, which is compounded by an unwillingness to censure destructive behaviour.

Does Debian measure its success by the number of installs? The number of maintainers? The number of flamewars? The number of packages? The number of messages to mailing lists? The quality of Debian Policy? The quality of packages? The “freshness” of packages? The length and quality of maintenance of releases? The frequency or infrequency of releases? The breadth of derivatives?

Many of these metrics are in direct tension with one another; as a consequence, the fact that different DD’s prioritise all of these (and other goals) differently makes for… interesting debate. The sort of debate that goes on and on because there is no way to choose between the goals when everyone has different ones. You know the sort of debate I mean :-)

Raphael: Do you think that the Debian community improved in the last 7 years? If yes, do you think that the coopetition with Ubuntu partly explains it?

Mark: Yes, I think some of the areas that concern me have improved. Much of this is to do with time giving people the opportunity to consider a thought from different perspectives, perhaps with the benefit of maturity. Time also allows ideas to flow and and of course introduces new people into the mix. There are plenty of DD’s now who became DD’s after Ubuntu existed, so it’s not as if this new supernova has suddenly gone off in their galactic neighbourhood. And many of them became DD’s because of Ubuntu. So at least from the perspective of the Ubuntu-Debian relationship, things are much healthier.

We could do much better. Now that we are on track for four consecutive Ubuntu LTS releases, on a two-year cadence, it’s clear we could collaborate beautifully if we shared a freeze date. Canonical offered to help with Squeeze on that basis, but institutional commitment phobia reared its head and scotched it. And with the proposal to put Debian’s first planned freeze exactly in the middle of Ubuntu’s LTS cycle, our alignment in interests will be at a minimum, not a maximum. Pure <facepalm />.

Raphael: What would you suggest to people (like me) who do not feel like joining Canonical and would like to be paid to work on improving Debian?

Mark: We share the problem; I would like to be paid to work on improving Ubuntu, but that’s also a long term dream ;-)

Raphael: What about using the earnings of the dormant Ubuntu Foundation to fund some Debian projects?

Mark: The Foundation is there in the event of Canonical’s failure to ensure that commitments, like LTS maintenance, are met. It will hopefully be dormant for good ;-)

Raphael: The crowdfunding campaign for the Debian Administrator’s Handbook is still going on and I briefly envisioned the possibility to create the Ubuntu Administrator’s Handbook. What do you think of this project?

Mark: Crowdfunding is a great match for free software and open content, so I hope this works out very well for you. I also think you’d find a bigger market for an Ubuntu book, not because Ubuntu is any more important than Debian but because it is likely to appeal to people who are more inclined to buy or download a book than to dive into the source.

Again, this is about understanding the difference in audiences, not judging the projects or the products.

Raphael: Is there someone in Debian that you admire for their contributions?

Mark: Zack is the best DPL since 1995; it’s an impossible job which he handles with grace and distinction. I hope praise from me doesn’t tarnish his reputation in the project!

Thank you to Mark 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, Google+, Twitter and Facebook

.

Filed Under: Debian News, News, Ubuntu News Tagged With: , , , ,

20 Things to Learn About APT With the Free Chapter of the Debian Administrator’s Handbook

November 15, 2011 By

We just released a sample chapter of the Debian Administrator’s Handbook. It covers the APT family of tools: apt-get, aptitude, synaptic, update-manager, etc.


Click here to get your free sample chapter

I’m sure you will enjoy it. There are many interesting things to learn:

  • How to customize the sources.list file
  • The various APT repositories that Debian offers (Security Updates, Stable Updates, Proposed Updates, Backports, Experimental, etc.)
  • How to select the best Debian mirror for you
  • How to find old package versions
  • How to install the same selection of packages on multiple computers
  • How to install and remove a package on a single command-line
  • How to reinstall packages and how to install a specific version of a package
  • How to pass options to dpkg via APT
  • How to configure a proxy for APT
  • How to set priorities to various package sources (APT pinning)
  • How to safely mix packages from several distributions on a single system
  • How to use aptitude’s text-mode graphical interface
  • How to use the tracking of automatically installed packages to keep a clean system
  • How APT checks the authenticity of packages that it downloads
  • How to add supplementary GnuPG keys to APT’s trusted keyring
  • How to upgrade from one stable distribution to the next
  • How to handles problems after an upgrade
  • How to keep a system up-to-date
  • How to automate upgrades
  • How to find the package that you’re looking for

If you liked this chapter, click here to contribute a few euros towards the liberation of the whole book. That way you’ll get a copy of the ebook as soon as it’s available. Thank you!

I also invite you to share this sample chapter as widely as possible. We’re only at 40% of the liberation fund and there’s less than 2 weeks left. I hope this book extract will convince enough people that the book is going to be great, and that it really deserves to be liberated and bundled with Debian!

Filed Under: Debian News, News, Ubuntu News Tagged With: , , , , , , ,

My Debian activities in October 2011

November 1, 2011 By

This is my monthly summary of my Debian related activities. If you’re among the people who made a donation to support my work (130.30 €, thanks everybody!), then you can learn how I spent your money. Otherwise it’s just an interesting status update on my various projects.

Dpkg work

The month started with fixing newly reported bugs to prepare the 1.16.1.1 release:

  • #644492: there was a flaw in a change I made to the trigger setup code. This resulted in packages being incorrectly marked as configured while they were only unpacked in a new chroot.
  • #642656: dpkg-source’s refusal to build when it detects unrecorded changes broke the (mostly unused, except by the lintian test suite apparently) “2.0” source format.
  • #644412: the Makefile snippet “buildflags.mk” did not respect the new maintainer specific environment variables (like DEB_CFLAGS_MAINT_APPEND) because make does not forward environment variable through $(shell …). Fixed that by manually exporting the required variables.
  • I also disabled dpkg-buildpackage’s output of the build flags since it was confusing several maintainers. dpkg-buildpackage invokes debian/rules and it has no (clean) way to discover the build flags changes that maintainer request by setting the dedicated environment variables in debian/rules. Maintainers expect to see the build flags with the modifications they have requested and not just the default values set by the distribution.

With the help of Guillem, we decided on a proper fix for a race condition sometimes triggered by parallel builds when 2 concurrent dpkg-gencontrol try to update debian/files (see #642608). This ended up requiring a new package (libfile-fcntllock-perl) that the Debian perl team kindly packaged for us. With all this sorted, it was a rather easy fix.

Multiarch progress

I also spent lots of time on multiarch. I fixed an old bug that requested to support the multi-arch paths in case of cross-building (see #595144), the discussion was not really conclusive on which of the two proposed patches was better so I ended up picking my own patch because it was closer to how we currently deal with cross-building. Then I fixed 2 issues that have been reported on Ubuntu’s dpkg. The first one (LP #863675) was rather severe since an installed package ended being “disappeared” in favor of its foreign counterpart that was removed (but that had some config files left). The second one (LP #853679) only affected dselect users (apparently there are still some!) who had a self-conflicting library (Provides: foo, Conflicts: foo) installed for multiple architectures.

But the bulk of the time spent on multiarch has been spent discussing with various parties on how to go forward with multiarch. The release team commented on the schedule of the merge to ensure it makes it into Wheezy, and the Debian project leader also commented on the problems encountered so far.

While not the best course of action I could have hoped for, it certainly helped since Guillem started pushing some reviewed commits. Out of the 66 commits that were in my pu/multiarch/full branch one week ago, 20 have been merged in the master branch already.

Python-django security update and RC bug

Since python-django’s maintainer did not manage to prepare the required security updates, I stepped in and prepared version 1.2.3-3+squeeze2 for Squeeze and 1.0.2-1+lenny3 for Lenny. Unfortunately this security update is an example of how an inactive maintainer is likely to result in a severe delay for the release of security updates.

Furthermore in this specific case, the security team did not want to release the Squeeze security update until the Lenny one had been investigated (which required some time since upstream no longer supports the version in Lenny) but they did not make this very clear.

Later another release critical bug had been filed against the package (#646634) but after investigation, it turned out to be a local configuration problem so I downgraded it. I still forwarded the test suite failure to upstream authors since the test could be enhanced.

In any case, co-maintainers for python-django are welcome. I really preferred the situation where I can quietly sit down as backup maintainer… :-)

WordPress packaging

WordPress sounds similar to python-django. I’m also “only a backup maintainer” but Giuseppe has been inactive for many months and I had to step in August because I wanted the new upstream version. I discovered a bit late that I was not subscribed to wordpress’ bugs and thus the release critical bug #639733 (that I introduced with my new upstream version) went unattended for a rather long time. Once aware, though, I quickly fixed it.

I also took the opportunity to start a discussion on debian-devel about how to deal with embedded javascript libraries and proposed a mechanism of “opportunistic replacement with symlinks”. WordPress is my testbed package for this mechanism, you can check out its debian/dh_linktree that implements the replacement logic.

The discussion has not been very interesting but at least I learned that Debian now requires that each source package shipping minified javascript files includes the original files too. It’s somewhat of a pain since it’s not a license requirement in many cases (many of those libraries are not under the GPL), but just a Debian requirement that many upstreams are not complying with. WordPress is affected and Jakub Wilk thus opened #646729 which is going to be a long-standing RC bug. To give good measures, I spent several hours investigating the case of each javascript file in the WordPress source package and I filed a new ticket on the upstream bugtracker.

Dropbox packaging work

A few months after the introduction of nautilus-dropbox to Debian and Ubuntu, I can say that the decision to only support the download of dropbox in the postinst has been a mistake. Because of this decision I had to make the postinst fail if the download failed. Even if the error message is relatively clear, this lead to many (mostly automated) bug reports on the Ubuntu side. Various other problems cropped up on top of this (trying to start dropbox while the package was not configured would result in an error because the user did not have the required rights to install the software, reinstalling the package while dropbox was running would result in a failure too, etc.).

I have fixed all those issues in the version 0.7.0-2 of the package. Now if the user has to install dropbox, it will use PolicyKit to request the root rights. The postinst will no longer fail if the dropbox download fails since it can be run later by the user. And I fixed the download code to remove the replaced file before unpacking a new file (insead of overwriting the existing file). All this work has been forwarded upstream.

The Debian Administrator’s Handbook Update

I’m glad to tell you that the translation will happen because we reached the minimal funding goal on October 22th with the help of 380 supporters.

Now the fundraising continues, but this time the goal is the liberation of the resulting book. For this to happen, we need to reach 25000 EUR in the liberation fund. So far we’re at 37% of this goal with 9400 EUR in the liberation fund (which means that 59% of the money raised has been put in the liberation fund).

Click here if you want to contribute towards the liberation of this book.

With (less than) 27 days left, it’s going to be a challenge to meet the goal, but we do like challenges, don’t we?

Misc work

  • I filed #644486 against dh-make so that new packages have proper support of dpkg-buildflags from the start.
  • I merged lots of patches from Luca Falavigna in the developers-reference.
  • I discussed debtags integration in the PTS with Enrico Zini and Paul Wise.
  • I updated publican’s packaging for the new upstream version 2.8. I had to write a new patch that I forwarded upstream.
  • I filed an upstream bug on hamster-applet because just running hamster-time-tracker no longer brings its window forward.

Thanks

See you next month for a new summary of my activities.

Filed Under: Debian News, Meta, News Tagged With: , , , , , , ,

The promising OpenMediaVault failed its debut as free software project

October 31, 2011 By

Volker Theile is well known for his work on FreeNAS. But at one point, he decided to give up on it and to restart from scratch but this time based on Debian (instead of FreeBSD). OpenMediaVault is the name of this new Debian based product.

Here’s how he defines the project:

OpenMediaVault is the next generation network attached storage (NAS) solution based on Debian Linux. It contains services like SSH, (S)FTP, SMB/CIFS, DAAP media server, RSync, BitTorrent client and many more. Thanks to the modular design of the framework it can be enhanced via plugins.

OpenMediaVault is primarily designed to be used in home environments or small home offices, but is not limited to those scenarios. It is a simple and easy to use out-of-the-box solution that will allow everyone to install and administrate a Network Attached Storage without deeper knowledge.

Even though all the work was private, he managed to attract an important following, and I must say that I was looking forward to this project. He regularly blogged on his progress, sharing some good-looking video of the resulting product (example here).

The first public release (Version 0.2, codenamed Ix) happened on October 17th. I have yet to try it but I took a look on the website. As a Debian developer, I was keen on seeing the source code and how the project was managed.

The GPLv3 license is presented as an important feature and I was expecting a well-managed open source project. The fact that it was a private one-man project up to now did not bother me, we’re quite used to the “scratch your itch” kind of start for free software projects.

Enough to say is that I have been very disappointed. First you come across a contributor agreement, it’s frowned upon by many free software developers. But why not, maybe he bought the argument of Mark Shuttleworth and wants to give it a try.

But then I looked at the subversion repository, it’s obvious that it’s just a dumping ground of files that are managed somewhere else in another repository. A bit like Android which is not developed in the open but released as a whole from time to time.

But the worst was yet to be found on the licensing page:

Beside being freely available for personal end-users, System Builders and System Integrators, in general Installers, require a commercial license for OpenMediaVault.

Besides the fact that I’m still not sure what this means, I would like to know how he reconciles this requirement with the terms of the GPLv3.

It’s a shame that a so promising project ends up being a disaster from a free software perspective.

Have you tried OpenMediaVault already? If yes, I’d be glad to read your thoughts in the comments.

Filed Under: News Tagged With: , , , , , ,

Debian joins Dropbox’s officially supported platforms along with Fedora and Ubuntu

October 28, 2011 By

If you checkout Dropbox’s Linux download page, you will see that Debian packages are provided. Up to a few days ago, they only provided packages for Ubuntu and Fedora.

I’m glad to see that packaging nautilus-dropbox for Debian and being in touch with them due to this led to this result.

Another positive outcome is that the version 0.7.0 now ensures the origin of the downloaded binaries with GPG.

Filed Under: Debian News, News Tagged With: , , , ,
« Older Posts