How free is the Nokia N900?

Dear readers,

So, I’ve been looking into buying a Nokia N900. However, what it provides regarding freedom is still not completely clear to me. And given that it is significantly more expensive than other smartphones, I’d like to make sure that it’s not a loss of money :-)

– Can I download the full source, recompile it, build a firmware from it and re-install my Nokia N900 from scratch? Is the process documented? It seems that you need to accept a EULA to download updated firmwares, and I couldn’t find the source for them. What exactly is available from firmware that is not available through normal repositories? (Are normal repositories only for “extras” apps, or is the base system also installable / upgradable from them?

– What’s the content of /etc/apt/sources.list? What exactly is http://repository.maemo.org/pool/maemo5.0/nokia-binaries/? What does Nokia need to hide? :-)

– Would it be possible to develop a Centos-like distribution, installing the Maemo firmware, but then upgrading everything to rebuilt versions using an unofficial repository? Are there some applications that are not packaged, or that would break if re-installed that way?

– Could I install Debian or Ubuntu on the N900? Is the process documented? Is it possible to dual-boot between, say, Maemo5 and Debian? (I’m not talking about setting up a chroot, of course)

– Besides the non-free telephony stack, are there any other “antifeatures” I should be aware of?

Thanks.

Doctor Capello!

He might too shy to tell everybody, but the world must know. Luca Capello successfully defended his PhD thesis today at Université de Genève, getting a “Très Bien” mention.

I must admit that my last biology lesson was 13 years ago, so I’m not sure I can really comment on his work on Vomeronasal Receptors: from Monogenic Expression to Axon Guidance. But I was very impressed by the quality of the experimental process, especially compared to what we do in computer science.

Debian was well represented at the defense, since Axel Beckert, Didier Raboud and the Debian kilt were also there.

Welcome to the list of Debian Developers holding PhD degrees, Luca!


Luca waiting at the door (again).
luca1
Luca ready to start.

Debian’s KVM + Ubuntu karmic => bug?

I’ve been playing with virtualization, and KVM in particular. However, I’m running into an interesting problem. Below is how Ubuntu Netbook Remix look inside my KVM (either using virt-viewer, virt-manager or directly KVM to display the VM). Note how the top panel is fine. I’m using KVM 88 from experimental (but I had the same problem with KVM 85 from unstable), the cirrus video driver inside the VM, and an up-to-date karmic VM.
Has someone ran into that problem already? If yes, where is it tracked? I’m been failing to find the correct search keywords so far.

kvm-unr

Re: Ubuntu Bugs

(Context: Michal ÄŒihaÅ™ complains about bugs filed in Ubuntu not being looked at nor forwarded to Debian or upstream)

Michal, I think that your complaint is caused by a misunderstanding of how package maintenance happens in Ubuntu. I’ll try to clarify it, based on what I understand (if you know better than me, don’t hesitate to comment).

The part of Canonical maintaining the distribution is organized into teams (full list here), like Kernel, Foundations, Desktop, Mobile, Server, etc. Most of those teams have mirror-teams in the community, like the Ubuntu Desktop team. Those teams take care of subsets of packages in Ubuntu, of relevance to the respective teams. (This is orthogonal to package upload rights, which are managed with the Ubuntu Core Development Team, and the Ubuntu Development Team ; there’s a proposal to change that so that package upload rights are based on the first set of teams).

However, there are some packages (probably more than 70% of the packages in Ubuntu, including main+universe) that are of no interest to any particular team. Those packages are maintained on a best-effort basis by all the Ubuntu developers (inside the loosely defined MOTU team), and focus is usually on not diverging from Debian, to make their work as easy as possible. It’s very similar to what we do in Debian with orphaned packages: sometimes, important bugs get fixed, because someone complained loudly enough or a developer ran into the bug and did a QA upload ; but usually, we don’t really do any bug triaging. Of course, there are some packages in Ubuntu that are not maintained by any “core” team, but still have someone that cares about them. They are more the exception than the rule.

So, yes, obviously, you will run into packages with lots of untriaged bugs, sometimes even with patches. And those bugs and patches are rarely being forwarded manually to Debian, simply because nobody cares about those packages in Ubuntu. In an ideal world, with infinite resources, this would not happen, of course. But realistically, this is not going to change anytime soon.

There’s a link on the PTS to the bugs of your packages in Ubuntu. The idea is to allow an easy access to the bugs reported in Ubuntu, which are likely to be also relevant to the Debian package. You should probably feel welcomed to triage the bugs against your package in ubuntu, if it makes it easier for you to monitor them.

There’s some noise in the Ubuntu bugs, of course, but more and more often, by looking at the Ubuntu bugs, I find important bugs in my Debian packages that are not even reported in Debian yet.

UDS Lucid

I’m back from Dallas, where I was invited at the Ubuntu Developer Summit for Lucid. I spent a great week there ; the event was extremely well organized (by organizing them every 6 months, you are probably able to gather a lot of experience!). Of course, after all I had heard about people hugging each other all the time in the Ubuntu community, I was a bit worried, especially with the flu spreading! But there are lots of fantastic people around Ubuntu, and it was a very nice opportunity to be able to meet them all.

Since it was my first UDS (I was at FOSSCAMP in Prague a few years ago, but didn’t stay for UDS back then), I was not really sure of what to expect. I was very pleasantly surprised.

UDS vs Debconf

UDS is very different from Debconf. In Debconf, we do three different kind of things:

  • we hack, mostly on our own, in the hacklabs
  • during talks, we report on what we have done recently
  • during some talks or BOFs, we discuss future (possible) changes

In UDS, the main focus is on the third point: most of the sessions are about discussing what will be implemented for the next release. All of the relevant developers are in the same room to discuss possible problems, and the outcome of each session is usually a detailed plan, with a list of action items. It’s a very nice way to ensure that changes are well thought, and allows making large-scale changes in Ubuntu very easily (you don’t spend weeks arguing about them on mailing lists). Of course, it’s probably also helped by the fact that there’s a company behind Ubuntu, with a set of large teams (kernel, foundations, desktop, etc), which helps transfering trust (not everybody feel like they have to participate in each discussion, even when they affect the whole distribution: the team in charge is trusted by the rest of the project).

On the other hand (yeah, let’s be negative for a while) it doesn’t really help spreading information between Ubuntu developers: it’s often a bit difficult to get the global view of what is happening inside Ubuntu, especially since lots of things are discussed on IRC.

Collaboration between Debian and Ubuntu

During the week, I mainly was interested on collaboration between Debian and Ubuntu. There’s a strong focus on doing the right thing wrt Debian (and also other upstreams). Then, of course, Ubuntu also has an agenda, which sometimes requires moving very fast on some things, or making compromises between technical purity and pragmatism. But the willingness to have common foundations between Debian Squeeze and Ubuntu Lucid will surely benefit both distros.

Quality Assurance

On the QA front, I am planning to do archive rebuilds for Ubuntu as well (fixing FTBFS is an easy way to start contributing to Ubuntu or Debian, and having those bugs fixed in Lucid would benefit Debian as well, by having patches already prepared). I also had a session with the QA team, where I gave an overview of what we are doing in the Debian QA group, to discuss opportunities for collaboration. The Ubuntu QA team focuses more on testing (with automated or manual testing) and bug triaging than archive quality — that part is left to the MOTUs and the release managers. (About MOTUs, I liked how what they do was described as long-tail maintenance, landscape gardening or terraforming. That gives a good idea of what it’s about).

Ultimate Debian Database

On the Ultimate Debian Database front, I did a plenary talk to try to demonstrate how UDD could be useful to Ubuntu as well, and, with Jorge Castro, we examined some metrics of Ubuntu’s giving back to Debian. I also talked with the Launchpad team to try to resolve my long standing “pretty please provide an export of Ubuntu bugs, so I can easily import them in UDD!” issue.

Ubuntu and ARM

ARM netbooks and smartbooks (mix between netbooks and smartphones) are coming, and Ubuntu is clearly very well positioned to play an important role on that market. There was a whole track about ARM support, with lots of changes that will be done for Lucid. Let’s all hope that Ubuntu-powered ARM netbooks win that market, so we don’t reproduce the failures of the non-ARM netbooks.

Distributed Development

James Westby has been working on a set of tools to be able to work on Ubuntu packaging using bzr. The point is not to store the canonical source for Ubuntu packages in bzr (well, at least it’s not the plan yet), but to provide a set of branches to make it easier to merge or cherry-pick from Debian. The resulting workflow looks extremely nice, with lots of syntaxic sugar. And even better, he assured me that his code is portable to Git ;)
Using his work, merging Ubuntu-specific changes in a new version of a Debian package basically means pulling from lp:ubuntu/foopkg, merging from lp:debian/sid/foopkg, and you are done!
As a bonus, we (Debian) would get bzr branches with the history of packages (kind of bzr-powered snapshots.debian.org).
James’ project is not completely ready yet, but should be very soon. It’s already basically usable, apparently.

Conclusion

Ubuntu has clearly gone a very long way since 2004. Everything looks very well organized and polished, and gives the impression of a big machine that nothing can stop. With Cloud Computing and now ARM netbooks, Ubuntu has proven to be able to adapt to the current trends and attract a lot of visibility. It is great news for Free Software, but also proposes an interesting challenge to Debian: of course, it’s nice that a Debian-based distro is in that position, but will Debian manage to stay relevant, or are we just going to be the technically-pure distro without many users that serves as a package supermarket for Ubuntu?

“Patches welcome”

When you merge a patch, especially a patch that has been waiting to be merged for more than 6 months, it is polite not to publicly mention that the patch required changes to the way it originally looked (a lot of patches do, especially when you didn’t provide much feedback during the 6 months waiting period), or that merging the patch required cleaning up, and introduced bugs.

Also, crediting the patch author in public communications doesn’t hurt.

If you fail to do that, people might feel that patches are not so welcome after all.

Free software improvements

Two things that have been annoying me for a long time have been fixed recently, and I discovered those two new features the same day (rainy week-ends are good for you).

  • OpenSSH’s problem with networks with large bandwidth-delay product has been fixed in OpenSSH 5.1. The problem was that OpenSSH has its own windowing system over TCP’s, and that its buffer were two small to be able to maximise the bandwidth on, say, a 1 Gbps link with 10ms latency, so you would get a ridiculous bandwidth because of that, even if TCP was correctly tuned. A patch (hpn-ssh) has been existing for a long time, but strangely, people don’t like patching their SSH servers and clients.
    That means I can now get decent bandwidth using scp or rsync over long distance links.
  • The radeon driver now supports TV out for R600 cards (including my X1250). I can now stop using the proprietary fglrx driver, and make the computer under the TV completely free!

OK, both changes have been there for a long time, but I’m sure I’m not the only one who didn’t notice them at the time. Big Thank You to both groups of developers (especially to the ati/radeon developers, who have been very helpful on IRC to troubleshoot my setup).

Bootstrapping Centos or Fedora from Debian or Ubuntu

Here are some notes about bootstrapping a Centos or Fedora chroot from Debian. It should also work from Ubuntu with minor changes, but I haven’t checked. The following should really be done in a chroot, since some commands will install files in your /etc or elsewhere, ignoring the --installroot passed to yum. The following instructions are for Centos, but replacing all occurences of centos with fedora should work.

  • apt-get install yum rpm python-m2crypto. If at some point, you get error messages about rpmlib(BuiltinLuaScripts), you need to install a newer rpm package (from Debian unstable, for example).
  • mkdir -p /tmp/centos/var/lib/rpm
  • rpm --root /tmp/centos --initdb
  • Go to http://rpm.pbone.net or http://www.rpmfind.net, search for centos-release or fedora-release, and download the rpm for the version you want.
  • rpm -ivh --force-debian --nodeps --root /tmp/centos centos-release*rpm (that populates /tmp/centos/etc with information about the centos repositories)
  • yum --installroot /tmp/centos/ install yum . That fails because of missing GPG information in /etc/pki. Do ln -s /tmp/centos/etc/pki /etc/pki, then again yum --installroot /tmp/centos/ install yum.
  • mount -t proc foo /tmp/centos/proc
  • mount -t sysfs foo /tmp/centos/sys
  • chroot /tmp/centos /bin/bash --login

If you get errors about different DB versions between Debian’s RPM and CentOS’ RPM, you can try, in the CentOS chroot:

  • cd /var/lib/rpm && rm * (simplest way to avoid problems between db versions for Debian’s RPM and centos’ RPM)
  • rpm --initdb
  • yum install yum (again, to restore the rpm db)
  • yum install vim-minimal less
  • That’s all!

Update: Jaldhar Vyas pointed me to mach, and Paul Wise to mock. Both packages are available in Debian, but use config files for each release shipped in the package. Unfortunately, both packages are out of date, and don’t include Fedora 9 or newer. Also, mock doesn’t support Centos.
Anyway, both packages could use a new maintainer. Don’t hesitate to jump in!

Managing your PTS subscriptions

Subscribing to packages on the PTS is really useful to stay informed of everything happening with those packages. Unfortunately, managing your PTS subscriptions is really a challenge. Here is how I proceed to subscribe to packages I forgot to subscribe after uploading them:

  • To get the list of your subscriptions, connect to master.d.o, and run
    /org/packages.qa.debian.org/bin/get-summary-subscribers.pl | grep your@email
    That’s also a way to know who is interested in your packages. :-)
  • You can use UDD (from master) to know the list of packages you should probably be subscribed to, that is, packages you maintain or co-maintain in sid:
    psql -A -t service=udd -c "select source from sources
    where distribution='debian' and release='sid'
    and maintainer_email='your@email'
    union select source from uploaders
    where distribution='debian' and release='sid'
    and email='your@email';"
  • You can them use combine to find the packages you should subscribe to, and mass-subscribe using the email interface.
  • Then, you are done, or almost done: mass-confirming PTS subscriptions is a PITA because of #340863.

Some more info:

  • The PTS lives on master, in /org/packages.qa.debian.org.
  • The script that handles emails send to pts@ is bin/control.pl.
  • The spool dir for pending requests is spool/. The files are simple text files.
  • You can send multiple commands per email. Sending them in the subject might be broken. (at least it failed for me)
  • You don't need to take special care of the From for your emails. It's ignored (unless you subscribe without specifying an email address).