Running Debian on your Linksys WRT54G* … sort of

I’m the happy owner of a Linksys WRT54GL. OpenWRT is nice, but … well. Debian is just nicer. And I couldn’t resist the idea of running Debian on this little MIPS system. Since there’s clearly not enough space available on the Linksys, I decided to install etch in a chroot, that I would mount using NFS.

Joey tried that already, the Debian wiki provides some information, but I use another technique.

First, on another system (an i386, I debootstrap’ed a mipsel etch, using --foreign. This tells debootstrap not to run the second stage:
debootstrap --arch mipsel --foreign etch /space/debian-mipsel http://ftp.fr.debian.org/debian

Then, I modified /etc/exports to allow the router to mount that chroot:
/space/debian-mipsel 192.168.1.1(rw,sync,no_root_squash)

I mounted it on the router:
ipkg install kmod-nfs
insmod sunrpc
insmod lockd
insmod nfs
mount -t nfs star:/space/debian-mipsel /debian -o nolock
mount -t proc /dev/null /debian/proc

I set up some swap space on the NFS mount (mandatory, or debootstrap’s second stage will fail):
ipkg install losetup
ipkg install kmod-loop
ipkg install swap-utils
dd if=/dev/zero of=/debian/swapfile bs=1M count=100
losetup /dev/loop/0 /debian/swapfile
mkswap /dev/loop/0
swapon /dev/loop/0

I chrooted inside /debian, and ran debootstrap’s second stage:
chroot /debian /bin/bash
debootstrap/debootstrap --second-stage

When you are done playing, you can disable the swap space and umount everything:
swapoff /dev/loop/0
losetup -d /dev/loop/0
umount /debian/proc
sleep 1 # or umount /debian will fail
umount /debian

If you want to re-mount everything, all you need to do is:
insmod sunrpc
insmod lockd
insmod nfs
mount -t nfs star:/space/debian-mipsel /debian -o nolock
mount -t proc /dev/null /debian/proc
losetup /dev/loop/0 /debian/swapfile
swapon /dev/loop/0
chroot /debian /bin/bash

That first stage/second stage split in debootstrap is really cool: it’s an easy way to run Debian anywhere, only requiring to be able to chroot at some point.

more efficient IRCing?

I need to reconsider my current way to do IRC.

  • My main computer is a laptop, so I can’t leave my IRC client open all the time.
  • More and more, I tend to ask stuff on IRC, then I have to leave, so I never get the chance to see the answer. Being able to stay connected all the time would be much easier.
  • I’m currently using XChat, and would like to continue using it (ie: I’d prefer to avoid going back to irssi).
  • Most of the time, I’m connected to two different networks (OFTC and Freenode).
  • I tried to set up an IRC bouncer, but I had the impression that it was complex, and not very user-friendly. (Maybe I’m wrong, or maybe I should have tried a different bouncer (which one?))
  • I’ve considered running two clients: XChat for my “main client”, and irssi just for logging everything. But that’s not really optimal.

Which solution are you using? Should I really go back to using irssi? Any good example irssi configs somewhere?

Update:

  • Comments are now open (they were closed because of a broken WP plugin)
  • I used to use screen+irssi, but then, I switched to xchat. I really like xchat, have written some custom scripts for it, and would prefer to continue to use it…
  • The possible suggestions I already got are:
    • use xchat with irssi_proxy
    • use xchat with ctrlproxy (looks very nice, but RC buggy and not in etch)
    • use xchat with shroudbnc (or psybnc, or dircproxy)

    Update 2:

    Ok, due to all the praise of the screen+irssi solution, I’ll give it another try…!

Debian Package of the Day is now alive again, and needs your help!

For those who have missed the previous blog entries: Debian Package of the Day (aka Deb-a-day) is now alive again ! There has already been several entries (published 2 times a week, on wednesdays and sundays, until we make sure that we can sustain an higher rate):

Deb-a-day is not syndicated on Planet Debian (because of the “only personal blogs” rule), but it’s syndicated on Planet Ubuntu, and it might be syndicated on Debian Times (negociations are still ongoing :-). Don’t forget to subscribe to the feed !

We (the nice team of editors) have 2 entries ready in the queue, but that’s not enough. If you discovered an interesting package through Deb-a-day, and didn’t submit an entry yet, you should really feel guilty now ! (we are especially looking for cool graphical apps, so Deb-a-day becomes less nerdy, but apps for nerds are welcomed as well, of course.)

Of Debian Etch’s quality and release schedule

The delay of Debian Etch caught some bad press this week. Some articles compare Debian to Ubuntu (which tries hard to have fixed-time releases), and some bloggers are amused by the fact that the next Debian release was delayed “again”. There are some important points though:

  • Etch wasn’t really scheduled to be released on Dec 4th. This target date was mainly used to determine other dates in the release process, like the freeze dates.
  • Ubuntu Dapper was delayed as well, for 6 weeks. Ubuntu Edgy wasn’t delayed, but I don’t think anybody can seriously compare Ubuntu Edgy’s quality with the upcoming Debian etch’s quality: edgy was more like a technology preview.

Now, the question is: how good is Debian Etch compared to Ubuntu Dapper ? It’s difficult to compare distributions: there aren’t a lot of good metrics for this. Of course, one could compare the number of packages that fail to build from source (it’s a good indicator of something seriously wrong in a package). But a lot of work has been done on etch about this, so it wouldn’t really be fair for Ubuntu. A good alternative is debcheck.

debcheck checks that packages can be installed (i.e that their dependancies can be satisfied). It does so by analyzing the content of the Packages files. I compared the results of debcheck on etch as of today (I re-processed it, but the same results are available from qa.d.o), and of debcheck on Dapper (not including dapper-updates – I wanted to compare quality at release date). Included sections were main for etch, and main, restricted and universe for dapper (I didn’t want to consider non-free packages, since their quality tend to be lower).

Results:

4 packages have unsatisfiable Depends on etch, on i386. 49 have unsatisfiable Recommends.

In the main section of Dapper, still on i386, only one package has a problem with its Depends (it was psycopg, because its binary package python2.3-psycopg has a dependancy on python2.3-egenix-mxdatetime). 46 packages in main had unsatisfiable Recommends. This is better than Etch, of course, but Ubuntu/main is much smaller than Debian/main.

When restricted and universe are included, the results are much worse. 80 packages have unsatisfiable Depends, and 150 packages have unsatisfiable Recommends. It is worth noting that those numbers are worse than those of Debian unstable as of today (67 packages have unsat Depends, 34 have unsat Recommends).

Conclusions (sort of):

  • Using the debcheck metric (which is actually quite important, since it translates in uninstallable packages for the users), Debian etch is already of better quality than Ubuntu Dapper when it was released (again, I haven’t checked with dapper-updates included).
  • It would be great to integrate such tests into the Ubuntu release process. Fixing bug is good, but such tools help to improve the distribution quality as a whole. I’ll try to work on this for Feisty after the Etch release.

Features vs. Freedom

Jono Bacon wrote a long blog entry on Planet Ubuntu about his vision of freedom, and how it applies to the proprietary drivers. This is a good opportunity to write sthing I wanted to write for a long time.

Ubuntu’s bug #1 is “Microsoft has a majority market share“. Well, I think that this should be of severity minor or wishlist, not critical. A better bug #1 would be “our priority is our users” (does it ring a bell ?). I find it far more important to improve the satisfaction of people already using a Linux distribution, than to try to convince others to use it.

Most users of Windows have very good reasons for using Windows, like proprietary applications that have no equivalent in the Free Software world. I don’t think that “Linux doesn’t have a 3D desktop” is the major blocker for people not using Linux. Windows doesn’t have a 3D desktop. Many Mac OS X users don’t use the 3D features. I haven’t felt the slightest need to try a 3D desktop, and I’m using GNOME/metacity, so the jump wouldn’t so hard to make to compiz.

I’m not saying that a 3D desktop is not a good idea. Of course, it would be nice to have LiveCDs that just work and start a 3D desktop, so we could show off at conferences. But I haven’t even bothered to google for such LiveCDs.

Sometimes, proprietary drivers are more needed on Linux, for example for people who bought a Wifi card without checking first if it was supported. But I don’t think that 3D graphic drivers are that important. I still hope that Ubuntu will not ship proprietary software by default, and that Ubuntu will try to help the free drivers instead.

Update: I forgot to close the comments when publishing this entry. They are closed now, but trackbacks are open if you want to write your own blog about this (I don’t think it’s necessary, all arguments have been reharsed many times already. Ah, and for the records, the free ati driver works perfectly fine and fast (using MergedFB) in my dual-screen setup (2560*1024), with xv on both monitors.

Resurrecting “Debian package a day”, part two.

After this blog entry, I thought for a while, and decided to take over Debian package a day. I’m well aware that it needs a lot of time, so I’ll try to make this a collaborative work:

  • It should be as easy as possible for readers to submit entries
  • There will be a team of editors, willing to dedicate some time to this on a regular basis, who will receive new entries from users, improve them and publish them.

The publishing rate should depend on the number of ready-to-go entries in the queue. Starting with publishing twice a week should be okay.

I have already started to set up a wordpress blog (using drafts to prepare entries + mails to coordinate should be enough for now ; we can always switch to something more complex later).

TODO List :

  1. Get control over the debaday.debian.net domain. I couldn’t do it directly since DAMs seem to want to wait until Christmas to deliver my Debian account, so buxy did it for me. Should resolve soon.
  2. Get added to Planet Debian and Planet Ubuntu. If the posting rate stays low, it shouldn’t be a problem, and we can always change this later.
  3. Write the initial pages explaining how to contribute, etc.
  4. Get the first entry online.
  5. Recruit editors to share the load.
  6. Wait for you to submit entries :-)

Update (08/12/06) : Debian Package of the Day won’t be added on Planet Debian: a recent discussion concluded that non-personal blogs should not be on Planet Debian. So you have to subscribe directly to its feed (if you read Planet Ubuntu, you probably don’t need to, since it was added there).

Resurrecting “Debian package a day” ?

A long time ago (until Nov 2004), there was this good blog which described one cool Debian package every day. It allowed to discover a lot of interesting software, but it suddenly stopped being updated.

It would be nice to resurrect this. A team of editors could work on this, and readers could submit new entries. Editors wouldn’t need to be Debian users : we could have Ubuntu users too, and it would be a nice way to determine what are the things that have been packaged in Ubuntu that we should (but don’t) have in Debian yet.

Leave a comment if you would like to dedicate some time to this (either as an editor, or as a regular submitter of entries). If there’s enough manpower, I’ll try to setup a mailing list or something to discuss the minimum infrastructure we would need.

When Ubuntu users discover that unofficial repositories can be harmful

Unofficial APT repositories are a PITA in the Ubuntu community. Most users use stable release (see previous post about that) since Ubuntu development releases tend to be much more bleeding edge than Debian unstable. But users still want the newest software, so they use unofficial repositories. There are lots of posts about private repositories on Planet.ubuntu-fr.org, and it seems to be the same on other local planets.

Recently, somebody posted a sources.list file with a huge list of unofficial repositories. The maintainer of one of these repositories, Jοhan Kiviniemi, was surprised to be in this list without even being contacted first. He chose a good answer: he uploaded a package with cool new default wallpapers. He also wrote a detailed explanation, with which I couldn’t agree more.

But this story raises a question: why do all these people work on their unofficial repositories, instead of filing and fixing bugs, improving the official packages, and getting their packages into Ubuntu ? It’s a shame that so much manpower is lost on such stuff.

PS: Johan Kiviniemi seems to have a lot of good opinions. :-)

List operators on files in shell ? (updated)

I often need to do list-like operations on files in shell, for example:

  • substract lines in one file from the lines in another file
  • add lines from two lines, suppressing duplicates
  • keep only lines which are not in both files
  • keep only lines which are in both files
  • etc

Such operations are easy to do with a combination of sort, uniq, cut, diff, etc. But they are so basic operations that it is a bit annoying to write the small shell script each time I need to do one of them.

Isn’t there a tool out there already providing all of them ?

Also, it would be great if such operations could be achieved considering only the first n characters or words (a bit like uniq -w, or the removed uniq -W option). It would be an easy way to do :

i1 c1
i2 c2
i3 c3
i4 c4

minus

i2
i4

Comments are opened.

Update: many people pointed me to moreutils‘ combine. It looks good, bug not exactly what I need, so I filed wishlist bugs #398187 (combine: provide aliases for set theory operators) and #398193 (combine: allow to compare only on a subset of the lines). I won’t have time to provide patches, so if somebody want to work on them …. :-)

Feature request: confirmation for non-member posts in mailman

There are basically two kinds of setups for mailing lists managed using Mailman, regarding posts from non-members :

  • Accept posts from non-members. This lead to quite a lot of spam on the list, but also to no work for the moderators.
  • Put posts from non-members in a moderation queue. This result in a spam-free mailing list, but also in a lot of work for moderators, and in posts delayed for days.

It would be great if Mailman could ask the sender for confirmation (either email-based or web-based) before accepting the mail or putting it in the moderation queue. This would greatly reduce the amount of spam on the list or in the moderation queue.

This is also known as Mailman feature request #673265. A similar feature has apparently been in Sympa for nearly 4 years.