Pasky’s Log

At our university department, we have a reasonably large deployment of Debian installations that are all (almost) the same software-wise, but quite diverse hardware-wise (we buy few new computers each year, and get rid of the oldest ones). Our users are fairly conservative (except wrt. the ‘ida’ package, for some reason) and we have quite a few local tweaks, so even though these are desktop machines, we follow Debian stable and it’s ideal for us – it takes us quite long to test, tweak and debug new release before an upgrade.

Of course, there is a catch – new computers have graphic cards that lenny simply cannot cope with anymore. And if you want new drivers, you need new xorg version. There are no official backports. So you are faced with installing xorg from testing (squeeze), but this is a fairly large-scale operation: your libc6 package and other base libraries will be upgraded, your keyboard/console configuration will change, etc. Especially the library upgrade is troublesome, since in order to stay binary-compatible across the whole department, we would need to install libc6 etc. from squeeze on *all* our machines. It is not very likely significant breakage of these packages would go through to testing, but there are risks and overally it adds significant overhead to the task.

Thankfully, there is a neat alternative solution – add Ubuntu to the repository cauldron! Ubuntu Jaunty is very similar to Debian Lenny package-wise, and in fact not even libc upgrade is necessary. Only a fairly isolated set of xorg-related packages will be upgraded, which seems ideal for the purpose.

First, we need to add extra repositories to our Debian stable system. We will need both jaunty and squeeze – this is a mystery, AFAICT no packages from squeeze are being installed during the process, but the squeeze repository is needed for APT to figure out the upgrade path.

Make sure you will stay in stable on general – add this to /etc/apt/apt.conf (create it if necessary):

APT::Default-Release "stable";

Add this to /etc/apt/sources.list:

deb http://ftp.cz.debian.org/debian/ squeeze main non-free contrib                                                                 
deb-src http://ftp.cz.debian.org/debian/ squeeze main non-free contrib                                                             
                                                                                                                                           
deb http://archive.ubuntu.com/ubuntu/ jaunty main restricted                                                                       
deb-src http://archive.ubuntu.com/ubuntu/ jaunty main restricted                                                                   

Not to worry, apt will keep operating on stable unless you explicitly tell it otherwise. Which we shall do right now:

apt-get install -t jaunty xserver-xorg-video-ati xserver-xorg-video-radeonhd \
  xserver-xorg-video-all xserver-xorg-input-kbd xserver-xorg-input-mouse \
  xserver-xorg

This set of packages is crafted for our installations and so that APT allows the upgrade, you will perhaps need to tweak it slightly; you certainly will want to add more input drivers if you are doing this on a notebook. We mess with the input packages since xserver-xorg-input-wacom would pull in newer libc6 package. Carefully review the installation proposal before agreeing to it, of course. Voila, you should have new X.org version with current video drivers on your system now!

Perhaps if we were starting from scratch, Ubuntu LTS releases would be a good option to consider since they keep hardware support up-to-date. However, moving to Ubuntu nowadays would be tedious, and we don’t like various Ubuntu fancy desktop stuff, being conservative UNIXy persons.

screenenv is a gadget that should make your applications within GNU Screen use the right display and ssh agent information based on which attached screen client you call them from.

The motivation is simple – I have screen session that I create on my desktop, but when on the go (or in the next room ;) with my notebook, I want to ssh -X in and be able to still open image attachments in my mutt properly.

Several approaches are possible, I chose a fairly invasive one – I hijack getenv() calls by applications and substitute few chosen environment variables (mainly $DISPLAY and $SSH_* – e.g. $SSH_AUTH_SOCK) based on their settings in the most recently active screen client attached to the current session.

Thus, you can just keep going back’n’forth between two sessions, keep working seamlessly, no explicit action is required on your part and all your applications will Do The Right Thing.

Of course, the v0.1 release has many rough edges – if a long-term application saves the getenv’d variable, then keeps checking other volatile ones, it will probably crash (that’s fixable, though; and I think this should be very rare situation in practice, most or all of the volatile variables are for one-shot use within a single process). Also, we should cache the client lookup (which involves walking all processes) at least for few seconds…