System calls quizz

  1. What is special about the socket, connect, bind, accept, … system calls?
  2. How does the errno value get from the kernel to applications?
  3. Some system calls return a number of times different of 1 in some cases. Which ones? (Put differently: enter a syscall once, exit more or less than once. Which ones can do that?)

(Thanks MG!)

RVM: seriously?

There’s some hype in the Ruby community about RVM (Ruby Version Manager). It’s a tool that allows to switch between Ruby versions on the same system (much like what the alternatives system provides for Java on Debian, except that RVM does it either system-wide or per-user).

However, when you look at it, RVM looks quite scary.

The recommended installation instruction is:
bash < <( curl ).
That script doesn’t use set -e, and actually does a git clone behind the scenes. Without first checking that git is installed. But if you don’t have git installed, it’s not a problem: there’s another script later on the page that downloads and compiles it for you.

After installing RVM itself, you need to install rubies (different ruby implementations). Use rvm install ree,1.9.2-head,jruby. That will automatically download and build the various versions in your homedir. It’s interesting to note the the compilation messages were probably too scary, and are not displayed.

But how does it handle the switch between different versions ? First, you need to add some magic to your .bashrc:
[[ -s "$HOME/.rvm/scripts/rvm" ]] && . "$HOME/.rvm/scripts/rvm"
or, for a system-wide install of rvm:
[[ -s "/usr/local/rvm/scripts/rvm" ]] && . "/usr/local/rvm/scripts/rvm"
And then, you can select your ruby implementation using rvm --default 1.9.2, for example. That works by redefining $PATH:
# echo $PATH

Of course, that’s quite fragile: if you are in one of the cases where bash doesn’t read .bashrc, or if you happen to be using dash, you lose.

Looking at the code of RVM itself, it is also very fragile: it’s pure bash, without any error handling. During my test (in a chroot), I often got error messages about missing commands that were apparently ignored. The installer insists on using colors, and spews lots of error messages if executed without a controlling tty. There are also some interesting code snippets like perl -e 'sleep 0.5'.

So, where do we go from here? Well, obviously, with my Debian hat, I’m not going to advocate a solution that makes everything possible to avoid the distribution’s packaging system, and I don’t see RVM being packaged in Debian anytime soon.
In Debian, we already provide co-installability of Ruby 1.8 and 1.9.2, and users are free to choose which one to use on a per-script basis, by running them with version-suffixed ruby executables. The ‘ruby’ executable itself still points to 1.8, as it’s clearly too early to make 1.9.2 the default. Many Ruby libraries are provided for both 1.8 and 1.9.2, and we plan to discuss changes in the packaging system to be able to make it easier to provide packages for both versions. There’s also recent work on packaging JRuby, but it’s quite hard as it requires removing all the non-free or undistributable parts, and packaging them separately.

List of new Debian contributors

Since I worked on UDD‘s upload history gatherer during Debconf, I generated the list of new Debian contributors. (By contributor, I mean here someone in the Changed-By field of an upload (so it’s not necessarily the maintainer of the package he/she upload)).

It’s quite fun to try to remember the context of your first upload to Debian (which package, who sponsored it), and look at the other contributors that “graduated” at the same time as you did. Or to see the constant flux of new contributors.

On extending Debian membership to non-programming contributors

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 And upload rights could be limited to non-core packages (and extended by the DD on 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

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

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!