News – Page 61

Debian 6.0 is out, Wheezy kicks off

February 6, 2011 by Raphaël Hertzog

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';

People behind Debian: Mike Hommey, Firefox/Iceweasel maintainer

February 3, 2011 by Raphaël Hertzog

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.

Debian is eating its own dog food more than ever

January 24, 2011 by Raphaël Hertzog

In its “Fast distributions and slow servers” article, Joe ‘Zonker’ Brockmeier explains the difficulties that Fedora has to use its own distribution on their infrastructure and echoes some questions they faced:

Why wouldn’t a Linux distribution project wish to showcase the distribution by hosting its infrastructure using its own system?

I completely share the underlying assumption. Eating its own dog food is very important if you want to build a Linux distribution and claim with some confidence that it’s of quality and usable.

Debian does quite well nowadays in that respect.

There were times where the mailing list server was using Qmail (non-free at that time, and thus not part of Debian) but that’s long gone. We have also seen our build infrastructure relying on software that was not public and not packaged in Debian, but that also is history.

The Debian System Administration team (DSA) maintains more than 140 servers running Debian. They mostly run the stable version of Debian but a few test machines are already running Squeeze since a few months (qa.debian.org for example). The Debian admins want to ensure that the next stable release of Debian still has everything they need and that the software they use still work as expected.

Big kudos to the DSA team for this choice! I hope we’ll be able to continue to live up to those standards for a long time to come.

PS: If you want to learn more about the setup that the DSA team uses, head to dsa.debian.org. You’ll find all their repositories and some of their internal documentation.

Subscribe to this blog by RSS, by email or on Facebook.

People behind Debian: Michael Vogt, synaptic and APT developer

January 21, 2011 by Raphaël Hertzog

Michael and Marie — Michael and his daughter Marie

Michael has been around for more than 10 years and has always contributed to the APT software family. He’s the author of the first real graphical interface to APT—synaptic. Since then he created “software-center” as part of his work for Ubuntu. Being the most experienced APT developer, he’s naturally the coordinator of the APT team. Check out what he has to say about APT’s possible evolutions.

My questions are in bold, the rest is by Michael.

Who are you?

My name is Michael Vogt, I’m married and have two little daughters. We live in Germany (near to Trier) and I work for Canonical as a software developer. I joined Debian as a developer in early 2000 and started to contribute to Ubuntu in 2004.

What’s your biggest achievement within Debian or Ubuntu?

I can not decide on a single one so I will just be a bit verbose.

From the very beginning I was interested in improving the package manager experience and the UI on top for our users. I’m proud of the work I did with synaptic. It was one of the earliest UIs on top of apt. Because of my work on synaptic I got into apt development as well and fixed bugs there and added new features. I still do most of the uploads here, but nowadays David Kalnischkies is the most active developer.

I also wrote a bunch of tools like gdebi, update-notifier, update-manager, unattended-upgrade and software-properties to make the update/install situation for the user easier to deal with. Most of the tools are written in python so I added a lot of improvements to python-apt along the way, including the initial high level “apt” interface and a bunch of missing low-level apt_pkg features. Julian Andres Klode made a big push in this area recently and thanks to his effort the bindings are fully complete now and have good documentation.

My most recent project is software-center. Its aim is to provide a UI strongly targeted for end-users. The goal of this project is to make finding and installing software easy and beautiful. We have a fantastic collection of software to offer and software-center tries to present it well (including screenshots, instant search results and soon ratings&reviews). This builds on great foundations like aptdaemon by Sebastian Heinlein, screenshots.debian.net by Christoph Haas, ddtp.debian.org by Michael Bramer, apt-xapian-index by Enrico Zini and many others (this is what I love about free software, it usually “adds”, rarely “takes away”).

What are your plans for Debian Wheezy?

For apt I would love to see a more plugable architecture for the acquire system. It would be nice to be able to make apt-get update (and the frontends that use this from libapt) be able to download additional data (like debtags or additional index file that contains more end-user targeted information). I also want to add some scripts so that apt (optionally) creates btrfs snapshots on upgrade and provide some easy way to rollback in case of problems.

There is also some interesting work going on around making the apt problem resolver a more plugable part. This way we should be able to do much faster development.

software-center will get ratings&reviews in the upstream branch, I really hope we can get that into Wheezy.

If you could spend all your time on Debian, what would you work on?

In that case I would start with a refactor of apt to make it more robust about ABI breaks. It would be possible to move much faster once this problem is solved (its not even hard, it just need to be done). Then I would add a more complete testsuite.

Another important problem to tackle is to make maintainer scripts more declarative. I triaged a lot of upgrade bug reports (mostly in ubuntu though) and a lot of them are caused by maintainer script failures. Worse is that depending on the error its really hard for the user to solve the problem. There is also a lot of code duplication. Having a central place that contains well tested code to do these jobs would be more robust. Triggers help us a lot here already, but I think there is still more room for improvement.

What’s the biggest problem of Debian?

That’s a hard question 🙂 I mostly like Debian the way it is. What frustrated me in the past were flamewars that could have been avoided. To me being respectful to each other is important, I don’t like flames and insults because I like solving problems and fighting like this rarely helps that. The other attitude I don’t like is to blame people and complain instead of trying to help and be positive (the difference between “it sucks because it does not support $foo” instead of “it would be so helpful if we had $foo because it enables me to let me do $bar”).

For a long time, I had the feeling you were mostly alone working on APT and were just ensuring that it keeps working. Did you also had this feeling and are things better nowadays ?

I felt a bit alone sometimes 🙂 That being said, there were great people like Eugene V. Lyubimkin and Otavio Salvador during my time who did do a lot of good work (especially at release crunch times) and helped me with the maintenance (but got interested in other area than apt later). And now we have the unstoppable David Kalnischkies and Julian Andres Klode.

Apt is too big for a single person, so I’m very happy that especially David is doing superb work on the day-to-day tasks and fixes (plus big project like multiarch and the important but not very thankful testsuite work). We talk about apt stuff almost daily, doing code reviews and discuss bugs. This makes the development process much more fun and healthy. Julian Andres Klode is doing interesting work around making the resolver more plugable and Christian Perrier is as tireless as always when it comes to the translations merging.

I did a quick grep over the bzr log output (including all branch merges) and count around ~4300 total commits (including all revisions of branches merged). Of that there ~950 commits from me plus an additional ~500 merges. It was more than just ensuring that it keeps working but I can see where this feeling comes from as I was never very verbose. Apt also was never my “only” project, I am involved in other upstream work like synaptic or update-manager or python-apt etc). This naturally reduced the time available to hack on apt and spend time doing the important day-to-day bug triage, response to mailing list messages etc.

One the python-apt side Julian Andres Klode did great work to improve the code and the documentation. It’s a really nice interface and if you need to do anything related to packages and love python I encourage you to try it. Its as simple as:

import apt
cache = apt.Cache()
cache["update-manager"].mark_install()
cache.commit()

Of course you can do much more with it (update-manager, software-center and lots of more tools use it). With “pydoc apt” you can get a good overview.

The apt team always welcomes contributors. We have a mailing list and a irc channel and it’s a great opportunity to solve real world problems. It does not matter if you want to help triage bugs or write documentation or write code, we welcome all contributors.

You’re also an Ubuntu developer employed by Canonical. Are you satisfied with the level of cooperation between both projects? What can we do to get Ubuntu to package new applications developed by Canonical directly in Debian?

Again a tricky question 🙂 When it comes to cooperation there is always room for improvement. I think (with my Canonical hat on) we do a lot better than we did in the past. And it’s great to see the current DPL coming to Ubuntu events and talking about ways to improve the collaboration. One area that I feel that Debian would benefit is to be more positive about NMUs and shared source repositories (collab-maint and LowThresholdNmu are good steps here). The lower the cost is to push a patch/fix (e.g. via direct commit or upload) the more there will be.

When it comes to getting packages into Debian I think the best solution is to have a person in Debian as a point of contact to help with that. Usually the amount of work is pretty small as the software will have a debian/* dir already with useful stuff in it. But it helps me a lot to have someone doing the Debian uploads, responding to the bugmail etc (even if the bugmail is just forwarded as upstream bugreports 🙂 IMO it is a great opportunity especially for new packagers as they will not have to do a lot of packaging work to get those apps into Debian. This model works very well for me for e.g. gdebi (where Luca Falavigna is really helpful on the Debian side).

Is there someone in Debian that you admire for his contributions?

There are many people I admire. Probably too many to mention them all. I always find it hard to single out individual people because the project as a whole can be so proud of their achievements.

The first name that comes to my mind is Jason Gunthorpe (the original apt author) who I’ve never met. The next is Daniel Burrows who I met and was inspired by. David Kalnischkies is doing great work on apt. From contributing his first (small) patch to being able to virtually fix any problem and adding big features like multiarch support in about a year. Sebastian Heinlein for aptdaemon.

Christian Perrier has always be one of my heroes because he cares so much about i18n. Christoph Haas for screenshots.debian.net, Michael Bramer for his work on debian translated package descriptions.

Thank you to Michael 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.

Wheezy kicks off

Tags

Recent Posts