How to get Network Manager working with ratpoison //at 00:59 //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. :-)

Debian and GPRS with the Nokia E51 //at 00:39 //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. ;-)

Segmentation faulty tree //at 21:28 //by abe

aptitude on Etch just gave me a funny error message:

1/0/0 root@c2:pts/2 21:14:24 [~] # aptitude upgrade 
Reading package lists... Done
Segmentation faulty tree... 87%
2/139/0 root@c2:pts/2 21:14:43 [~] # 

Ctrl-Ms can be nice sometimes…

Following Bleeding Edge Software and still using Debian Stable //at 23:47 //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

Group packages by origin in aptitude //at 02:00 //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

Goodbye Woody, Welcome Etch //at 00:53 //by abe

It finally happened. I installed Debian Etch on my last Woody box, a 400 MHz Pentium II with 576 MB RAM named gsa which is my home desktop since I bought it at LinuxTag 2003 in Karlsruhe.

And no I didn’t do a dist-upgrade, neither direct no via Sarge. As already planned I removed some no more necessary operating systems from that box and installed Etch on the freed disk space. Woody is still installed on that box in parallel and was recognized perfectly by Etch’s installer.

I took a few hours but also was big fun to go through Etch package list and to decide what to install. Overall the installation of 5 GB of software took about half a day.

In general everything went fine, the only thing I’m yet missing is sound. Etch didn’t seem to recognize my soundcard at all although it’s a well-known brand and defacto standard for many other soundcards: a Creative Labs Soundblaster. Well, the 16-Bit ISA version, needing the full length of the slot. Worked fine under Woody. Well, I hope I’ll get it working again manually.

What on the other hand is really nice with udev hell —eh— hal and all those new automatic bells and whistles: The desktop (well, at least GNOME Nautilus as well as XFCE, but probably also KDE) recognises when I insert a 3.5” floppy into the drive and shows me a nice floppy icon on the desktop. You think, that’s impossible? Floppy drives don’t inform the rest of the system when a floppy has been inserted without you polling the drive every few seconds? Well, USB floppy drives can. And they do. :-)

I still need time to migrate all the old settings from Woody to Etch. I’ll probably stick with FVWM, but perhaps will use the GNOME enabled version. What’s already done is the migration from tcsh to zsh. On all new or dist-upgraded systems after Etch I’ve chosen zsh so with my last Woody installation retiring I’ve also fully migrated to zsh.

So I’ve got now most of my active private boxes running Etch. Only the noone.org web and mail server “sym” (an amd64 box) as well as my 133 MHz ThinkPad “bijou” are still running Sarge, both with 2.6 kernels.

So with switching to Etch on gsa, I also got no more Debian box running a 2.4 kernel. The only 2.4 kernel I run is on my FreeWRT WLAN router named pluriel, which runs 2.4.33.3. But I expect that 2.6.18 will be as stable and long lasting as the famous and rock-solid 2.4.18 from Woody. 18 seems to be Debian’s favourite kernel minor version recently. ;-)

VCFe talk online / bijou vs Etch //at 00:18 //by abe

With a few days lag, the slides to my VCFe 8.0 talk Aktuelle, freie Software auf alter Hardware (“Up to date, free software on old hardware”, held in German using Kazehakase and S5) are now online. In comparision to my former talks on that subject (held at some DebianDays), this talk was not Debian focused but focused more on not so well known, but resource-friendly free software as well as focused on an audience which has more knowledge of old hardware than of current software. :-)

Additionally, I updated my old blog post about X on my ThinkPad 760ED named bijou so that now also my current XF86Config-4 for Sarge on that box is linked in there.

Apropos bijou: I couldn’t recommend Debian 4.0 Etch that much for old computers with not so much memory since especially aptitude has grown much in regards of it’s memory and performance needs. Regarding my experiences with Etch, any computer with less than 50 MB of RAM will start to swap if aptitude is only started on such a box. I’ve looked throough the aptitude documentation, but I haven’t found a way to switch of some of the tables it generates internally. E.g. I have no need for the tag database it always generates. I really would be happy, if someone knows a way to turn even only that feature off. Then I may dist-upgrade bijou to Etch, since I found that dselect is no real alternative to aptitude anymore.

Oh yeah, and I of course bought new old hardware at the VCFe: A 386SX Thin Client named Flytech Carry-I 9300 from 1991 with about 200 MB of harddisk and 10 MB of RAM.