unstable

GNOME 3 transition happening in Debian unstable

October 17, 2011 by Raphaël Hertzog

The few articles I wrote that explained how to install GNOME 3 from Debian experimental have been very popular. So I figured out that a small update would be welcome.

The Debian GNOME team started uploading a mix of GNOME 3.0 and 3.2 packages to Debian unstable because the release team is ready to take care of this transition. This means that as soon as the packages are ready in Debian unstable, the release team will ensure that they also reach wheezy (aka the current testing distribution).

So if you’re a Debian unstable/testing user with a GNOME Desktop, expect some important changes… by the way my experience with GNOME 3 was recently plagued by some rendering issues resulting in parts of the screen not being properly refreshed. While trying to track this down (and investigating clutter as a possible culprit) I came upon this mail on the clutter-devel mailing list. I recompiled mutter with the indicated patch and it fixed my issue. I immediately uploaded mutter 3.0.2.1-4 with the fix… so this issue should be gone for the many people who are going to experience GNOME 3 for the first time in the coming days.

It’s also worth noting that contrary to how upstream handles it (they hide the fallback mode and the user has to enable an option to use it in place of the GNOME Shell), Debian has a dedicated session for the GNOME 3 fallback mode so you decide what you get right from the login screen. This will be appreciated by the people who do not see GNOME 3 as a step in the right direction. Unless they switch to XFCE as some did.

As far I am concerned, I’m already used to GNOME 3. I spend most of my time in terminals, browsers and an IRC application and the whole Shell does not fundamentally changes my work habits.

5 reasons why Debian Unstable does not deserve its name

December 20, 2010 by Raphaël Hertzog

Debian Unstable (also known as sid) is one of the 3 distributions that Debian provides (along with Stable and Testing).

It’s not conceived as a product for end-users, instead it’s the place where contributors are uploading newer packages. Daily. Yes that means that Unstable is a quickly moving target and it’s not for everybody. But you can use it and your computer won’t explode.

1. It contains mainly stable versions of the software

Yes, you read it right. Unstable is not full of development versions of the various software. It happens on some software but then it’s usually a conscious decision of the maintainer who believes that this specific version is already better than the previous one.

The packages in sid are supposed to migrate to testing, the place where the next Debian stable release is prepared. So maintainers are advised to only upload stuff that is of release quality, the rest should be uploaded to experimental instead.

2. It doesn’t break badly every other day

Breakages happen but they are not a big deal usually. It has been long time since I could not reboot my computer after an upgrade or since the graphical interface was no longer working. The kind of breakages that you have is that one software stops working, or triggers an annoying bug, or that a few packages are uninstallable.

In most cases, you can save yourself by downgrading to the version available in Testing. Or by finding a work-around in the bug tracking system. Or by not upgrading because you have apt-listbugs installed and you have been warned about the problem.

3. It’s the basis of other distributions

If Debian Unstable was really so bad, it would not be a good basis to build a derivative distribution, isn’t it? But Ubuntu and ~~Sidux~~Aptosid (to name only two) are based on Debian Sid.

4. It’s not inherently less secure than Stable or Testing

High impact security vulnerabilities will usually be quickly fixed in Stable and Unstable. The stable upload is done by the security team while the unstable one is made by the maintainer. Testing will usually get the fix through the package uploaded to Unstable, so testing users get security updates with a delay.

For less serious vulnerabilities, it’s entirely possible that stable does not get any update at all. In that case, unstable/testing users are better served since they will get the fix with the next upstream version anyway.

Of course, it happens that maintainers are busy or that something falls through the cracks, but there are other people watching RC bugs who will fix this if the maintainer doesn’t react at all.

5. I use it on my main computer

And many other people do the same. And you can do the same if you meet the criteria below:

you can work on the command-line (enough to downgrade a problematic package, to edit configuration files, etc.);
you know how to work with APT and multiple distributions in /etc/apt/sources.list;
you are able to read/write English so that you can read/file bug reports when needed;
you have another computer connected to the Internet that you can use to lookup documentation (or the bug tracking system, or the support mailing lists) when your usual computer is off-line for a reason that you don’t understand.

If you feel you are not ready for the jump, click here to subscribe to this blog (or here via the RSS feed), I’ll surely teach some of the required skills in future articles.

PS: All that said, if you have a working sid installation, do not upgrade it just before an important presentation, or before a trip. It will always break at the most annoying time. Unless you like to live dangerously, of course.

How Ubuntu builds up on Debian

November 22, 2010 by Raphaël Hertzog

I have been asked how Ubuntu relates to Debian, and how packages flow from one to the other. So here’s my attempt at clarifying the whole picture.

Where do the packages come from?

Most packages are created by Debian contributors and they are uploaded in Debian unstable (or Debian experimental). New packages are reviewed by the Debian ftpmasters before being accepted in the official archive. The packages are held in the NEW queue until the review is over, and the time spent there varies between a few hours and a few months (usually they are processed within one week or two).

Ubuntu imports all the official Debian packages, but they also add some packages of their own. About 7% of the Ubuntu packages are third-party software that have been packaged for Ubuntu but not for Debian.

What are the changes made by Ubuntu?

From all the source packages coming from Debian, 17% have additional changes made by Ubuntu. Many of them are part of the “main” repository, which is actively maintained by Canonical and Ubuntu core developers. The “universe” repository is usually closer to the official Debian packages.

Many of the changes made by Ubuntu are the results of the decisions taken during the Ubuntu Developer Summit in order to reach specific goals: provide a better user interface, offer faster boot times, become a better platform for third-party software developers, offer a good integration with their online services (Launchpad, Ubuntu One), etc. Other changes are simply the result of fixing bugs reported by Ubuntu users.

Note that even non-modified source packages will result in different binary packages for Ubuntu. That’s because Ubuntu has made changes to the build environment. They only support Intel-based computers with a 686-class (or newer) CPU, they enable some compiler options that Debian doesn’t, etc. And all binary packages are modified by a program called pkgbinarymangler.

Ubuntu’s release cycle and the relation with Debian

Ubuntu releases every 6 months (that’s what time based releases is about). Debian has a very different schedule. How does Ubuntu manage to reuse Debian’s work?

Ubuntu imports packages from Debian unstable (even experimental sometimes) to get the newest packages. If the Ubuntu package already has Ubuntu-specific changes, they merge their changes in the updated Debian package. Otherwise the Debian package is simply grabbed and rebuilt in Ubuntu. This works well because Debian unstable is much more usable than the name suggests. And this process only goes on during the first 2 months of the cycle (until the Debian Import Freeze), so there’s plenty of time afterward to fix the biggest problems.

In the third and fourth month, it’s still possible to pick updated packages from Debian but it must be requested by a developer, it won’t be done automatically. At the end of the fourth month, the feature freeze is put in place.

The 2 months left are dedicated to bug fixing and polishing the distribution. There are various sub-freezes that happen in this period, you can check the Natty release schedule as an example. Picking updated packages from Debian is now the exception, it will only be allowed if the update on the Debian side is a bug-fix only release.

Credits: some figures taken from a talk of Lucas Nussbaum, they were collected based on the packages available in the Lucid Lynx release of Ubuntu.

Click here to subscribe to my newsletter and get my monthly update on what’s going on in Debian and Ubuntu.

Understanding Debian’s release process

October 18, 2010 by Raphaël Hertzog

Currently, the main product of the Debian project is its stable release^[1]. Those release come out approximately every 18-24 months. This article gives a short overview of the process leading to the next stable release.

Creating a new distribution

Immediately after a stable release, a new distribution is created in the Debian archive. Its initial content is a copy of the (just released) stable distribution. Its codename is decided by the release managers and there’s a tradition of picking a character’s name from the Toy Story movie.

As an example, the “wheezy” distribution will be created once “squeeze” (aka Debian 6.0) is out.

For simplicity there’s a generic name to refer to the distribution used to prepare the next stable release: it’s testing. In the Debian archive, testing is just a symbolic link pointing to the right directory (squeeze currently).

Updating packages, working on release goals

During most of the cycle, developers work on packaging new upstream versions and implementing release goals. They upload their packages in the unstable distribution.

From there packages trickle to the testing distribution once they satisfy some quality checks: they must not have new release-critical bugs, they must have been built on all architectures that were previously supported, they must not break any dependency in testing, and they must have spent at least 10 days in unstable.

This minimal period ensures the package has been tested and gives enough time to users to file bugs if the package is suffering from problems. If the problems are deemed release-critical, they will block the migration of the package to testing.

During this part of the release cycle, the main work of the release team is ensuring that updated packages flow from unstable to testing. It can be a tricky task: package dependencies frequently tie packages together so that they can only migrate to testing together. If only one of the tied packages is not ready (for example if a new revision has been uploaded and has not spent 10 days in unstable yet), then none of them can migrate.

Stabilizing, polishing, fixing release-critical issues

The constant churn of new packages makes it very difficult to build a very polished release. That’s why, at some point, release managers freeze the testing distribution: automatic updates are stopped and they vet every single update made to testing. They have strong requirements, the goal is to only allow updates fixing release critical bugs, or those which are low-risk and bring significant value to the user experience (like new translations, updated documentation, etc.).

During freeze, some packages are also removed because the current upstream version can’t be supported for the lifetime of the stable release.

The freeze tends to slow down the pace of changes in unstable. Many maintainers opt to push new upstream versions in experimental instead so that if they need to update their packages in testing, they can still do it through unstable. This procedure is recommended by the release managers because it means that updates that they unblock have been tested as usual. It’s not the case for updates uploaded directly to testing (through testing-proposed-updates).

This behavior is rather annoying for the bleeding-edge users that use testing or unstable like a rolling release.

Release time

Once release managers are satisfied of the quality of the new distribution, some last minute work is needed, like generating the CD images. In the Debian archive, the release is made official by pointing the “stable” symbolic link to the new distribution (and the “oldstable” one to the previous distribution).

Now it’s party time, the cycle is over, and a new one can start. 🙂

^[1] The Constantly Usable Testing project aims to make testing a first-class product like stable—but with a very different update policy.

Follow me on Identi.ca, Twitter and Facebook.