Booting ISO or USB key images directly from Grub2?

Posted on May 25, 2010 by lucas

I’m playing with the idea of booting ISO images and USB key images stored in a disk partition directly from Grub2. That would allow to install Linux or test liveCDs without even using a USB key. It seems that Grub2 has everything needed for that (with a combination of drivemap and chainloader), but I can’t seem to get it working and, as usual with boot stuff, it’s a pain to understand what’s happening.

Has somebody recently tried that, or can point me to a howto?

Receive Ubuntu bugs by mail with the Debian PTS

Posted on May 14, 2010May 14, 2010 by lucas

It is now possible to subscribe to Ubuntu bugmail for the packages you care about, without having to use Launchpad (and subscribe on a per-package basis there). This is implemented as a new opt-in Package Tracking System keyword: derivatives-bugs.

To subscribe for all your packages, use keyword [email] + derivatives-bugs (as documented in the Developers Reference). You might also want to subscribe to derivatives (Ubuntu diff, etc. also opt-in).

Of course, if other derivative distributions are interested in providing such data, don’t hesitate to contact me or the Debian QA team.

Also, if you are like me and never remember about subscribing to packages you maintain, you can use that UDD script to check for missing subscriptions.

“But why isn’t Debian using Launchpad?”

Posted on May 3, 2010 by lucas

Due to my work on Ultimate Debian Database, I’m sometimes asked why Debian isn’t using Launchpad.

First, “using Launchpad” can mean two different things.

The first possibility is using Canonical’s instance of Launchpad. That would mean creating a Debian project on launchpad.net, and using Canonical’s infrastructure. Well, that’s clearly not a good idea. We (Debian) do not want to depend on Canonical to fix bugs or make enhancements that we require to improve Debian. For example, Canonical imposes the use of the Bazaar Version Control System in Launchpad: you simply can’t use Git instead (git-bzr hacks don’t count). We want to stay in control of our infrastructure, for obvious reasons.

So the other possibility would be to setup our own instance of Launchpad, given that Launchpad is now Free Software. However, it is not clear if it is actually possible: I was told by a Launchpad developer that they didn’t know of any external (outside Canonical) installation of Launchpad.

Even if this was possible, it is not clear at all that the Ubuntu infrastructure is superior to the Debian infrastructure. The Debian infrastructure has many nice features that are missing in Launchpad, for example version-tracking in the Bug Tracking System, which allows to track (by parsing the changelog) the versions of a package where a bug has been fixed or not (example with iceweasel).

So, when switching to Launchpad, we would have to reimplement quite a lot of needed features in in, with no clear benefit: the Debian infrastructure works fine, and is actively maintained.

It’s also interesting to note that while the Ubuntu infrastructure is centered on Launchpad, there are quite a lot of external services that are not integrated in Launchpad: the Ubuntu popularity contest, merges.u.c, patches.u.c, the various services on qa.ubuntuwire.org and qa.u.c, etc. With the Debian model, it is very easy to add a new service and get it integrated with the various dashboard (Debian Developer’s Packages Overview, Packages Tracking System). Within Ubuntu, those external services are really second-class citizens. All in all, the infrastructures of the two projects reflect their organizations: bazaar model for Debian, with an emphasis on collaboration between the services, controlled by Canonical for Ubuntu.

RC bugs of the week

Posted on March 13, 2010 by lucas

I just couldn’t resist… I joined the game, but did it the other way around.

I could only file 51 new FTBFS (Fail To Build From Source) bugs this time. Looks like Squeeze is getting closer!

I’ve also been doing rebuilds of Ubuntu lucid. There are currently 561 packages that fail to build from source in lucid/amd64, versus 430 in sid/amd64 (I will start rebuilding squeeze instead of sid after the freeze). Surprisingly, only 131 packages fail in both. I would have expected that number to be much higher.

Ruby release blockers for Lucid and Squeeze

Posted on March 7, 2010March 7, 2010 by lucas

For the first time since I got involved in Ruby maintenance in Debian & Ubuntu, we are seriously at risk of not being able to release working Ruby interpreters in both Ubuntu Lucid and Debian Squeeze, because of two pretty serious issues.

Ruby 1.8(.7.249) randomly hangs with eglibc 2.11

That issue was found by Google folks, because Puppet was hanging. After a lot of (quite heated) discussion, it was found that the problem is caused by something in eglibc 2.11: the problem can’t be reproduced in a Debian unstable chroot (with eglibc 2.10), but is reproducible if you just upgrade glibc to 2.11 (which is in Debian experimental).

It is not clear at all whether it is a glibc bug, or a ruby bug: Ruby has shown in the past that it was making some assumptions on the behaviour of pthread. It is possible that a valid change in glibc conflicts with an assumption made by Ruby.

Still, I wonder why Ubuntu chose to release with eglibc 2.11, while Debian still only has 2.10 in unstable, and Ubuntu doesn’t really have a lot of people with deep glibc knowledge. (Update: I assumed we would release squeeze with 2.10, but the eglibc maintainers plan to release 2.11 in squeeze.)

That issue is tracked in Launchpad as bug 520715 (which was reassigned to eglibc), and in Ruby’s redmine as bug 2739. Debian Squeeze isn’t affected by that issue, but we are likely to get bitten as well after Squeeze if a solution isn’t found by then.

As Ruby maintainers in Debian/Ubuntu, we can’t do much about this issue, because it requires either a lot of glibc knowledge, or a lot of understanding of the Ruby threading code.

Ruby 1.9(.1.37{6,8})’s test suite hangs on Sparc

The development branch of Ruby (declared stable by the interpreter developers, but not considered as such by the third-party libraries developers) also has interesting issues. Its test suite hangs on sparc, but only (apparently) on specific CPUs/kernel versions. Here again, it is not clear whether it is a Ruby issue, or a kernel issue, for the same reasons as above. It is also possible that it is fixed in Linux 2.6.32, but the Debian build daemons run the lenny kernel, so we can’t check that. This is tracked as Debian bug 565765, and is not tracked in Ruby’s redmine, because Sparc is not supported by the upstream Ruby developers.

This issue really requires Sparc knowledge (and access), so as Ruby maintainers, again, we can’t do much, besides coordinating and poking the various people that can help.

Check your PTS subscriptions with UDD!

Posted on March 1, 2010 by lucas

The Debian Packages Tracking System has a great feature: you can subscribe to packages that matter to you, and be informed of all uploads, bugs, testing migrations, etc.

However, when (co-)maintaining a lot of packages, it is easy to forget to subscribe. And then you might miss important information about your packages (uploaders don’t receive bugmail by default, for example).

Since PTS subscriptions are now imported into Ultimate Debian Database, it is easy to find out if you missed some subscriptions. It’s just a matter of going to http://udd.debian.org/cgi-bin/pts-check.cgi and entering your email!

And for those concerned with privacy, it should be noted that the unauthenticated access to UDD only gives you the hash of the subscribers’ emails. You need to be a DD, and use the guestdd account to see the email addresses (which DDs can already see on master.d.o).

Debian Squeeze, Ubuntu Lucid and Ruby 1.9.2: NO!

Posted on February 10, 2010 by lucas

Apparently, there’s some hype in the Ubuntu community about Ruby 1.9.2, so let’s clarify: it would be totally irresponsible to try to ship Ruby 1.9.2 in Debian Squeeze or Ubuntu Lucid.

Ruby 1.9.2 has not been released yet:

June 2009: The release schedule for 1.9.2 was announced
mid-July 2009: Ruby 1.9.2 preview 1 was released
September 2009: 1.9.2 preview 2 was tagged in SVN, but not announced
September 2009: The release plans were cancelled
October 2009: A meeting was announced to discussed new release plans, but I don’t think that the outcome was made public
Ruby 1.9.2 has not been branched off trunk yet

That’s where we stand now. Even if surprises are possible, it’s very unlikely that Ruby 1.9.2 will be released before Lucid’s release (or, what the real requirement is, before Lucid’s freeze). So we are sticking with 1.8.7 and 1.9.1 (1.9.0 will go away before the release).

If you can point to specific commits that fix real bugs in 1.9.1, and could be backported to the Debian package, feel free to notify the Debian Ruby maintainers.

Slides from my FOSDEM talk on Debian and Ubuntu

Posted on February 9, 2010February 9, 2010 by lucas

I’ve just put the slides of my talk on Debian and Ubuntu online.

Don’t hesitate to post comments to ask for clarifications where needed (it might be difficult to understand some parts of the slides without being in the room).

Clarifications:

In slide 15, I wrote that Ubuntu had a newer X. During the presentation, I think I said that I wasn’t sure if it was still the case. Indeed, it’s no longer the case (and hasn’t been for a long time ; Ubuntu has been mostly following Debian for X). I apparently remembered a change a long time ago that was picked by Ubuntu from the Debian X svn/git (xlibs-dev removal, I think), and that caused a number of FTBFS in Ubuntu. However, clearly, the best example of such changes made first in Ubuntu are newer GCC versions.

Going to FOSDEM

Posted on February 5, 2010 by lucas

Yes, I’m going to FOSDEM. And this year, I decided to innovate by starting the obligatory FOSDEM flu before leaving to FOSDEM.

I’m doing a talk on Sunday, on Debian and Ubuntu (Distributions room, H.1308, 13:45). It might not be on your schedule (but is on the printable schedule) since it was decided quite late.

Re: How free is the Nokia N900?

Posted on January 26, 2010 by lucas

Following my questions on the freeness of the Nokia N900, I received quite a lot of comments. I’m trying to summarize the most important points here.

Maemo is not 100% free software. There are some proprietary components. The Free Maemo wiki page lists them all, and there are some explanations on Why the closed packages.
The Mer project (install notes for N900) aims at providing a 100% free alternative to Maemo.
It’s possible to rebuild/upgrade the kernel, however the newest kernel build-depends on a fiasco-gen package that is not provided. It is being worked on.
Nokia is sponsoring someone to work on Maemo derivatives.

For all the details, see the comments and Tollef’s blog.

Lucas Nussbaum's Blog

Category: PlanetUbuntu