Group packages by origin in aptitude //at 00:06 //by abe

I always wondered how others recognise non-Debian packages in the aptitude package tree. I also missed the additional priority level in the hierachy well-known from good old dselect.

For the last one, I quickly found out that you can set the priority as subsection — it’s straight forward after you’ve read the documentation: Just add ,priority at the end of the default grouping method for package views under “Options → UI Options” in the aptitude menu.

Getting the origin as given in the Release file of the repository a package originates from is a little bit more difficult. You need to use the pattern() group function with the appropriate search pattern: pattern(~O)

Since already the default default grouping method for package views doesn’t fit into the dialog, I nowadays just edit /etc/apt/apt.conf directly for changes on aptitude’s default grouping method for package views. It now looks like this on several of my machines:

Aptitude::UI {
  Default-Grouping "filter(missing),status,section(subdir,passthrough),pattern(~O),section(topdir),priority";
};

In aptitude this looks like this:

[...]
  --- text - Text processing utilities
  --\ utils - Various system utilities
    --- Debian
    --- Mowgli
    --- volatile.debian.org
  --\ web - Web browsers, servers, proxies, and other tools
    --- Debian
    --- Opera Software ASA
  --\ x11 - The X window system and related software
    --\ Debian
      --- contrib - Programs which depend on software not in Debian
      --\ main - The main Debian archive
        --- Priority optional
        --- Priority extra
      --- non-free - Programs which are not free software
    --- Mowgli
[...]

Unfortunately this doesn’t work with all non-Debian repositories since a few repository maintainer, e.g. those from Emdebian, arrogate to just keep “Debian” as their packages’ origin. This could be solved, if there’s a possibility to group by e.g. repository URL (host and/or path).

Another problem I haven’t solved yet is that grouping by origin does neither work with locally created nor virtual packages nor tasks — probably since all of them lack an origin. Those branches are just empty or don’t even show up anymore with this configuration. I probably have to dig a little bit more in the aptitude documentation to resolve this.

Now playing: E-Rotic — Max don’t have sex with your ex

Screen and Emacsclient: Automatically switching to the Emacs window //at 10:38 //by abe

For a very long time, I use mutt with emacsclient as configured editor and a single GNU Emacs instance started from either .screenrc or .Xsession, depending on the system. And I’m very used to switching the virtual desktop or the screen window after starting a mail in mutt.

Since Debian 5.0 Lenny and Emacs 22, Emacs automatically grabs the focus and switches to the right virtual desktop. So after telling mutt recipient and subject of a new e-mail, it invokes emacsclient and immediately the focus has moved to the running Emacs instance. Because I was used to switch one virtual desktop to the right at that point, I often found my self two desktops to the right until I got used to it. :-)

I usually hate applications which grab the focus without being asked. But in this case I basically asked for it. And there’s no delay like with starting up an application which has to read in some database first – think of Liferea or Rhythmbox which take many seconds to minutes to start up, even on my 2.2 GHz dual core ThinkPad.

In the meantime I got so used to that automatic desktop switch that I forget to switch the screen window in the second scenario where I use this combination: My screen doesn’t automatically switch to the Emacs window (window 1) after I told mutt recepient and subject in window 2.

Knowing that screen is quite scriptable, I found out that only a very small change is needed to my mutt configuration to get that desktop feature to my everyday screen session. I simply replaced the editor setting in my .muttrc with the following line:

set editor="screen -X select 1;emacsclient"

Now mutt tells screen to switch to window 1 (where Emacs is running) and then tells Emacs to open the appropriate file to edit my new mail.

Update Friday, 2009-04-24, 18:22

Even though Zack surely is right with his comment about the multi-terminal feature of the upcoming GNU Emacs 23, I still have Etch (and therefore GNU Emacs 21) on the server where I have my screen session.

So the next step was to switch back to the mutt window (window 2) after I’m finished with editing the mail. Since mutt gives the the file to edit as argument to the contents of $editor, simply adding ;screen -X select 2 at the end of $editor doesn’t suffice.

So I wrote a small shell script (named ~/.mutt/editor.sh) as wrapper which calls all the commands and passes the parameters to the right command:

#!/bin/sh

screen -X select 1
emacsclient -a ~/.mutt/alteditor.sh "$@"
screen -X select 2

Of course, $editor is now set to that script:

set editor="/home/abe/.mutt/editor.sh"

Emacsclient of GNU Emacs 21 already supports the -a option to call another editor in case of not being able to connect to a running Emacs instance. Since I don’t want to switch to another screen window in that case, I wrote a second shell script (named ~/.mutt/alteditor.sh) which switches back to the mutt window and then calls GNU Zile, my preferred low-end emacs clone:

#!/bin/sh

screen -X select 2
zile "$@"
screen -X select 1

I love it!

Useless Statistics, the 2nd //at 19:35 //by abe

Myon recently posted a nice statistic about popular single letter package name prefixes. Just out of curiosity I started wondering about popular single letter package name suffixes:

On a machine with Debian oldstable, stable, testing, unstable and experimental in its sources.list, I ran the following command:

$ apt-cache search -n . | \
    awk '{print $1}' | \
    sed -e 's/.$//' | \
    sort | \
    uniq -c | \
    sort -n

And to my surprise there is a non-obvious winner:

$ apt-cache search -n '^gp.$'
gpa - GNU Privacy Assistant
gpc - The GNU Pascal compiler
gpe - The G Palmtop Environment (GPE) metapackage
gpm - General Purpose Mouse interface
gpp - a general-purpose preprocessor with customizable syntax
gpr - GUI for lpr: print files and configure printer-specific options
gps - Graphical Process Statistics using GTK+
gpt - G-Portugol is a portuguese structured programming language
gpw - Trigraph Password Generator

But since I searched through the binary packages many other hits are more obvious, like the seven packages hbf-cns40-1 to hbf-cns40-7:

      [...]
      4 ar
      4 aspell-f
      4 automake1.
      4 cpp-4.
      4 e
      4 g++-4.
      4 gappletviewer-4.
      4 gcc-4.
      4 gcj-4.
      4 gcompris-sound-e
      4 gfortran-4.
      4 gij-4.
      4 go
      4 gobjc-4.
      4 gobjc++-4.
      4 h
      4 iceweasel-l10n-e
      4 iceweasel-l10n-k
      4 kde-i18n-f
      4 kde-i18n-h
      4 kde-l10n-e
      4 kde-l10n-s
      4 kile-i18n-e
      4 koffice-i18n-e
      4 koffice-i18n-s
      4 koffice-l10n-e
      4 koffice-l10n-f
      4 libqbanking
      4 myspell-f
      4 myspell-h
      4 openoffice.org-help-e
      4 openoffice.org-l10n-b
      4 openoffice.org-l10n-h
      4 openoffice.org-l10n-k
      4 sd
      4 tcl8.
      4 tk8.
      5 aspell-e
      5 aspell-h
      5 iceweasel-l10n-s
      5 kde-i18n-b
      5 kde-i18n-e
      5 kde-i18n-t
      5 kde-l10n-k
      5 openoffice.org-l10n-e
      5 openoffice.org-l10n-t
      5 pa
      5 tc
      6 gc
      6 kde-i18n-s
      6 libdb4.
      6 m
      6 openoffice.org-l10n-n
      6 openoffice.org-l10n-s
      6 s
      7 hbf-cns40-
      9 gp

But there are also some other interesting observations to make:

• OpenOffice.org seems to have by far the biggest number of localisations, with KDE being 2nd.
• There are 6 version of the Berkeley DB in Debian: libdb4.2 to libdb4.7 (including oldstable as mentioned above)

I leave it as an exercise to the reader to find the full names of the other package names starting with s, m, gc, pa or tc and having just one additional character. ;-)

Debian and GPRS with the Nokia E51 //at 01:33 //by abe

A while ago I wanted to have internet over GPRS (either EDGE or UMTS) via my Nokia E51 working before I leave for the weekend. But whatever I tried, I always got an ERROR if I sent any AT command. Even ATZ and ATH resulted in errors. So started googling for all components: I found AT commands which are said to work with the Nokia E51, I found AT commands which are said to work with Swisscom GPRS and I found many sites describing how to setup a bluetooth modem.

But since the even those AT commands which should work with both, Swisscom GPRS and Nokia E51 didn’t work at all, I noticed that all the Nokia E51 howtos were using the USB cable. So I tried that, too, and it worked immediately. It looks very strange to me that the set of AT commands is dependend on which way you connect to the phone. :-/

So here’s my working PPP config:

hide-password
noauth
connect "/usr/sbin/chat -e -f /etc/chatscripts/swisscom-gprs"
/dev/ttyACM0
460800
defaultroute
crtscts
user "guest"
usepeerdns
noccp
bsdcomp 0,0
lcp-echo-failure 10000
lcp-echo-interval 1000
asyncmap 0
novj
nomagic

TIMEOUT 5
ABORT BUSY
ABORT 'NO CARRIER'
ABORT VOICE
ABORT 'NO DIALTONE'
ABORT 'NO ANSWER'
ABORT DELAYED
ABORT ERROR
'' \nAT
TIMEOUT 12
OK ATH
OK ATE1
OK 'AT+CGDCONT=1,"IP","gprs.swisscom.ch"'
OK ATD*99#
CONNECT ""

So I have now four levels of mobile computing available:

• Nokia E51 with T9 and phone keyboard (for short texts)
• Nokia E51 with Nokia SU-8W bluetooth keyboard (for longer texts and emergencies, see photo on the right)
• ASUS EeePC (7", 630 MHz Celeron, 2GB RAM, 4GB SSD) with Nokia E51 as modem (complete computer, but still small, portable and nearly always with me)
• Lenovo ThinkPad T61 (14" wide screen, 2.2 GHz Core2Duo, 4GB RAM, 160 GB SATA Disk) with Nokia E51 as modem (complete computer with power and disk space)

Should suffice in nearly all situations. ;-)

How to get Network Manager working with ratpoison //at 23:53 //by abe

Using GNOME Network Manager is a neat way to connect to wireless or virtual private networks from a laptop running Debian Lenny, Sid, Etch with Backports or any of the *buntu distributions. You can control everything from the system tray. But not all window managers have a system tray. And with some window managers it’s not obvious how to make them work with one of those lean third party trays and panels.

Especially my favourite window manager for small displays as on the EeePC – ratpoison – insolently puts any panel or tray in the middle of the screen by default. It took me a moment to find out how to make ratpoison work with my favourite third party system tray trayer (which can handle transparency and is only a system tray, no taskbar).

First we need to make ratpoison ignore the trayer on the one hand and and reserve space for it on the screen. Fiddling around with preconfigured frames didn’t work well and the following way is also more straight forward:

1. trayer always has “panel” as window title, so adding the following line to your .ratpoisonrc makes ratpoison ignore trayer:

   unmanage panel

2. Now all windows overlap the trayer, so we need to configure the space for it. Trayer in the default configuration shows up at the bottom and has a height of 26 pixels, so we tell ratpoison to add a padding of 26 pixels at the bottom of the screen by adding the following line to the .ratpoisonrc:

   set padding 0 0 0 26

Now we are confronted with the problem that these settings only apply to new windows, not ones which were already running when ratpoison starts. I usually start my X session using an .xinitrc or an .Xsession which calls the window manager using exec at the end.

We can start the trayer later though by spawning a subshell in the background with a sleep at the beginning. Also the Network Manager applet (nm-applet) can be started that way. In my case the end of the .Xsession looks like this:

( sleep 1; \
  trayer --align right --edge bottom --distance 0 \
	 --expand true \
	 --transparent true --alpha 128 --tint 0 \
	 --SetDockType true --SetPartialStrut true & 
  nm-applet & ) &

exec ratpoison

The result could look like this:

The other programs in the system tray are from right to left: nm-applet (GNOME Network Manager), Twitux (GTK Twitter Client), Audacious, Opera, Pidgin (formerly known as GAIM), Icedove (unbranded Mozilla Thunderbird). The clock on the bottom left is from the package osdclock.

Oh, and although I’m fine with trayer: if anybody knows a possibility to control the GNOME Network Manager without the need for a system tray, I would be very happy if you could tell me. :-)

Update 18-June-2008 23:45:

Matto Fransen used my howto to get ratpoison and nm-applet working together on Ubuntu. He also explains in his blog post, what may be necessary to get nm-applet working as intended in the first place — things I already had forgotten when I wrote this posting initally. :-)

The days of my last running Woody are numbered… //at 21:29 //by abe

As many of the Planet Debian readers know, I bemoan Galeon 1.2 and therefore Woody. For a long time I haven’t found an appropriate browser replacement for Galeon 1.2 in Sarge, so I never switched my home workstation called “gsa” (Pentium II, 400 MHz, 572 MB RAM) to Sarge, since Woody was rockstable and just worked.

Though, after a few Galeon 1.3/2.0 rants, someone pointed me to Kazehakase, which indeed is a fine Galeon 1.2 replacement. But I noticed that Kazehakase in Sarge was in an early stage and the Kazehakase from testing (now Etch) were already much more matured.

So in comparison to Sarge with Etch I won’t have the problem of not having a mature and sage web browser in main. And due to security support for Woody ceased a few months ago and Etch is now declared stable, it’s time to reinstall my last Woody box with Etch.

For that, a repartioning of it’s two hard disks (8 GB and 40 GB) sounds like a good idea and so I had look, what’s on all those partitions where I once had a shot on quite a few Linux distributions and other unix-like operating systems. (Although I was already a big fan of Debian at that time, I wanted to look over my own nose and ordered a few CDs of free operating system at LinISO.de.)

So here’s what I found, never really used and will throw away quite soon:

• RedHat 9
• Mandrake 9.2beta2
• FreeBSD 4.8
• OpenBSD 3.3
• one more, not yet identified (or perhaps even never formatted) Linux partition

That should give enough space for an Etch installation without touching the Woody installation first. Thanks to Venty, I’ve got a DVD drive for that box, so I can install from DVD.

And for toying around with all those other neat and free operating systems nowadays, I’ve got my MicroClient Jr. named “c2”.

Following Bleeding Edge Software and still using Debian Stable //at 23:04 //by abe

Many Linux fans know that Debian Stable usually already lost the “b” when it’s being released. ;-) What seems not so well known (especially not by some DesktopBSD Marketing guy at last year’s LinuxDay.at :-) is that there is really a lot of people who really like this “stale” software collection — because it’s rock solid — especially compared to the ports in FreeBSD or DesktopBSD *evilgrin* which unnecessarily follow every new feature upstream introduces. This is really annoying in a server environment where you want as less changes as possible when updates are necessary due to security issues. My personal favourites here are Samba and CUPS. *grmpf*

Although I belong to those people who run Debian Stable even on brand-new hardware, I sometimes have to use the newest beta or alpha versions of some software to get it even only running. And doing so is fun but feels strange somehow, though. Currently I follow the pre-releases of three software makers quite close, due to a new laptop:

At the beginning of last semester I bought a brand-new Lenovo ThinkPad T61 (2,2 GHz Intel Core2 Duo T7500, 4 GB RAM, 160 GB HD, 1440x900 14” Widescreen) without preinstalled operating system (possible thanks to the ETHZ Neptun Project) and installed — of course — 64-bit Debian Stable on it.

While the Debian Installer from Etch worked fine even on such new hardware, not all features worked out of the box because some components were just too new.

So the first thing I did was installing 2.6.22 from Backports.org, quickly moving farther to vanilla 2.6.23. Nearly everything I needed worked except the wireless network card. It needs the iwlwifi driver which is officially in the Linux kernel starting at the upcoming 2.6.24 (said to be released during the next few days). So I run 2.6.24 pre-releases on the laptop since the first release candidate, always eagerly waiting for either the next RC or the final release. (And 2.6.24 looks impressively stable to me — even since the early release candidates. :-)

I even got the fingerprint reader working for login and sudo (but not xscreensaver) using libthinkfinger backported to Etch from Debian Experimental. I’m just not sure if this is a good idea since the back of the screen already has enough of my fingerprints on it. ;-)

The next software of which I’m currently running an alpha version is 64-bit Opera 9.50 (aka Kestrel, available at snapshot.opera.com) because no earlier Opera version is available for 64-bit Linuxes. Here I had different experiences: The builds from October and November were already quite stable, but since December it crashes usually several times a day.

At work I also run the 64-bit Opera on my workstation, but stalled updating it when I noticed that it became so unstable. So my Opera at work has currently an uptime of nearly four weeks — and would have probably more if I hadn’t rebooted my workstation in Mid-December.

Somehow this hunting for new versions and eagerly waiting for every new (pre-)release makes me really fidgety sometimes. And my understanding for people doing this for there whole userland or even operating system has grown, but I still prefer to have stale but stable software on all my productive machines, even on my laptop — just with some few and handpicked excpetions.

The third but less thrilling thing I’m following are nVidia drivers for X. Since the free nv driver of X.org doesn’t support (and not only just doesn’t know) my graphics card yet and nouveau isn’t ready yet, I run the binary only and closed source driver from nVidia, waiting for that one release which supports Xen since I really would like to run a Xen guest with Debian Unstable for testing purposes and package building on my laptop. Until then I have to content myself with the much more unwieldy QEMU respectively KVM.

Anyway, I’m very happy with the T61 and Debian Stable and can easily connive at the few not (yet) perfect issues like missing Xen support by nVidia, broken ad-hoc mode in the wireless card, no internal card-reader (as announced in the Neptun specifications) and no native serial port.

Some useful links regarding the subject of this post:

• Linux Weather Forecast
• Opera Desktop Team
• Nouveau: Open Source 3D acceleration for nVidia cards
• ThinkWiki

Now playing: Jean Michel Jarre — Rendez-vous à Paris