On extending Debian membership to non-programming contributors

Posted on by lucas

Stefano raised again the issue of providing some kind of Debian membership to people that contribute to Debian in unusual ways (not involving deep purely technical skills), like doing translation, documentation, marketing, design, etc.

Each time this discussion comes back, people seem to think that we need another membership status for them. But what for?

It’s true that the name “Debian Developer” is suboptimal for non-programmers. But it’s also suboptimal for most DDs, since most of us don’t strictly develop software: we “just” maintain packages, mainly developing meta-data around the upstream source code. “Debian Developer” is how we call our full-fledged project members. Do we want to classify those non-programming contributors as second-class citizens? If not, we need to make them “Debian Developers”, not some strange other name.

Of course, there’s the issue of security and trust. Debian Developers have upload rights on all packages, and access to the project’s machines. And it’s a bit strange to trust non-programmers with that level of power. On the other hand, we have many Debian Developers that are mostly inactive, became DDs half a decade ago, and have the same access rights. Worst, it’s possible that they remember how to use dput, having used it before! And 95% of DDs (me included) should probably not be uploading the libc, even if they can. Why should they be more trusted than active non-programming contributors that probably would be quite scared by the idea of breaking something?

Overall, I think that this issue is actually a non-issue. We should:

  • Acknowledge that, when a non-programming contributor has made notable contributions to Debian (proven by the advocacy of current members) and passed the relevant parts of the Philosophy and Procedures check, it should be made a Debian developer.
  • Orthogonally, acknowledge that we have a problem with security due to the size and the volunteer nature of the project, and address it independently. For example, shell accounts could be disabled after 3 months without connecting to Debian machines (and be re-enabled by the DD on http://db.debian.org/). And upload rights could be limited to non-core packages (and extended by the DD on http://db.debian.org/ too). It’s not about adding intermediate levels of membership, just about giving the possibility to developers to add a safe-guard against themselves.

Ubuntu bugs with patches on the PTS and the QA Packages Overview

Posted on by lucas

Like the Debian BTS, Launchpad is full of open bugs with patches[1]. They have an ongoing effort called Operation Cleansweep whose goal is to get the number of bugs with patches to zero, by reviewing patches and forwarding them upstream or to Debian.

Since it really makes sense to expose bugs with patches to the Debian maintainers, I’ve modified the Ubuntu box on the Packages Tracking System and the Ubuntu column on the QA Packages Overview (hidden by default for now) to include that information. You can see the result on the dpkg PTS page and the debian-pkg@ packages overview page.

Many thanks to Brian Murray for making this possible on the Launchpad side.

[1] Debian has 55115 open bugs affecting unstable, of which 4011 have a patch. Ubuntu has 76916 open bugs, of which 2207 have a patch. [Insert here disclaimer that this is not at all a judgement of value on the abilities of any distribution at triaging bugs, or at generating patches]
Relevant UDD queries:

select count(*) from bugs
where affects_unstable and status = 'pending'
and id in (select id from bugs_tags where tag ='patch');

select count(*) from bugs
where affects_unstable and status = 'pending';

select count(distinct bugs.bug)
from ubuntu_bugs_tasks tasks,ubuntu_bugs bugs
where tasks.bug = bugs.bug
and distro in ('', 'Ubuntu')
and status not in ('Invalid', 'Fix Released', 'Won''t Fix')
and bugs.patches is true;

select count(distinct bugs.bug)
from ubuntu_bugs_tasks tasks,ubuntu_bugs bugs
where tasks.bug = bugs.bug
and distro in ('', 'Ubuntu')
and status not in ('Invalid', 'Fix Released', 'Won''t Fix');

Help needed: analyzing and filing installation/removal/upgrade bugs

Posted on by lucas

I’ve been working on a piuparts-like tool call instest (yeah, crappy name) to test installation, removal and upgrade of packages. Compared to piuparts, it’s simpler and tries to make it easier to file bugs. However, running it on sid still raises ~3000 failures. So I’m seeking help to analyze those failures and file bugs.

The tasks are:

  • get a grasp on what instest does, the script used to analyze the results, and the current results (yes, I know there are some obvious false positives).
  • find possible improvements (isolate false positives or common error cases) and improve the scripts (no need to learn Ruby, I can help with that part)
  • file bugs (there are scripts – based on my archive rebuild ones – to do that efficiently)

If you want to help, just contact me at Debconf!

Skipping fsck checks during boot with CTRL-C

Posted on by lucas

According to Murphy’s law, the fsck check that happens once every n boots always happens at the worst time. By default, using CTRL-C to abort it causes fsck to exit with an error, and the filesystem to be remounted read-only. It’s easy to change that in /etc/e2fsck.conf:

[options]
allow_cancellation = true

Debcamp+Debconf again! (update)

Posted on by lucas

As I did since 2007, I will be attending Debconf again this year. I have been quite busy recently, and am lagging behind in some of my Debian work, so I plan to use Debconf to get stuff done, not just socialize and attend talks.

Here is my TODO list, basically by order of “willingness to do the work”. It’s probably too much for 9 days, so don’t hesitate to talk to me if you want to help with some items.

  • Switch the ruby1.9.1 package to a prerelease of Ruby 1.9.2. That package providing the development branch of the interpreter. That will be done while keeping the existing package name, as Ruby 1.9.1 and 1.9.2 are (supposed to be) compatible. It might be a bit confusing for users to have a ruby1.9.1 package that installs Ruby 1.9.2, but then we can just blame the upstream developers for using the same numbering space for “ruby compatibility level” and “ruby version”. Bonus: will fix 2 FTBFS on {kfreebsd-,}i386. ruby1.9.1 1.9.2~svn28788-1 uploaded, but it really means “ok, enough, let’s upload and see what happens”. There are some open issues on FreeBSD, and some patches that still require porting to that version.
  • Update the ruby1.8 package. There’s a few patches pending (including the “ruby is slow because of pthread” one). ruby1.8 1.8.7.299-2 uploaded, sync to Ubuntu requested.
  • Run an archive-wide test using instest again. instest is a piuparts re-implementation that is targetted at making it easy to file bugs about installation and removal failures. It’s nothing big, really, but already allowed to file 78 RC bugs a few months ago. Done, and call for help posted. Which raises another TODO item:
    • Process instest failures if nobody wants to help … Well, done partially. The number of issues found justifies that those tests are useful, so I’m a bit annoyed that nobody volunteered to help.
  • Run an archive rebuild. I did one last week-end mainly to provide food for RCBC, but there are some failures that haven’t been filed because they required more investigation. I also need to check back with various people about some custom rebuilds (newer GCC, etc). And I’ll probably also do a rebuild of Ubuntu maverick.Rebuild done, about 70 new RC bugs filed, and some cleanup done on old unreproducible bugs. Also did a rebuild with an updated hardening-wrapper for Raphael Geissert, and a rebuild of Ubuntu maverick on i386 and amd64 (results posted on ubuntu-devel@).
  • Do a ddpo-by-mail run. Last one was a longgg time ago. I have a few open requests about ddpo-by-mail that I’d like to address before spamming people again (for example, it shouldn’t report about merged bugs).Done, ~1300 emails sent.
  • Ultimate Debian Database work: merge the upload-history importer into UDD itself to drop the dependency on a script on merkel. Also address #540132 (strange info in the upload-history table). Make sure the changes to carnivore about DMs are compatible with the carnivore importer. All done!
  • Investigate how we could improve Ruby packaging with something like ruby-support. One of the requirements is to provide an easier way to support several Ruby versions.
  • Do some work on feed2imap. It got a few valid feature requests recently that I’d like to address in a 1.1 release.
  • Debian/Ubuntu work: add info about bugs with patches to the PTS now that this info is available in UDD thanks to Brian Murray’s work on the Launchpad side, and other pending work items from the Debian/Ubuntu BOF at UDS
  • Work on Bapase and the handling of poorly maintained and low-quality packages, resurrecting an old thread on debian-qa@
  • Do some packaging work: systemtap 1.3, tcsh, websec (long overdue!), and the usual pkg-ruby-extras shores. I also would like to take a look at the atlas FTBFS as I’m affected through hpcc.
  • Update developers-reference. I’m totally in lazy mode about that since the maintenance was transferred to debian-policy@, but I will try to address bugs with valid patches.

#debian-ubuntu on OFTC

Posted on by lucas

If you are a Debian developer and need realtime interaction with an Ubuntu developer about the state of your packages in Ubuntu (or vice-versa), #debian-ubuntu on irc.oftc.net might be useful. I had forgotten about that channel, but it resurfaced during the discussions about improving communication between both projects.

EtherPad: web-based collaborative editor

Posted on by lucas

I recently (during a UDS lightning talk) discovered EtherPad. It’s a collaborative editor (like gobby), but uses a browser instead of a standalone application. It’s free software (Google open sourced it after buying the company that was developing it), and there’s a free online instance at ietherpad.com. Setting up a new pad is as simple as going to http://ietherpad.com/foo and clicking Create Pad. It’s written in Java, and not packaged in Debian (yet).

XMPP Video calls with Nokia N900

Posted on by lucas

So, this morning, I did my first video call over XMPP between two N900.

However, so far, I failed to do an XMPP video call from an N900 to something else. When I try to call pidgin on my laptop, pidgin simply crashes, but of course that’s not a serious bug if people can DOS your pidgin instance since, according to the Debian bug:

Assuming your XMPP settings require that users must authenticate with you before being able to send you messages, only your authenticated users would be able to freeze your client, assuming they knew you were actually affected by this bug.

The upstream pidgin bug hasn’t seen a lot of activity lately. :-(

Booting ISO or USB key images directly from Grub2?

Posted on 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?