awg's blog

Installing Debian Packages Locally

My department is planning to install Ubuntu on all our lab machines, and probably take away sudo access from everyone who doesn't truly need it (i.e. anyone who isn't a sysadmin). I'm looking forward to having Ubuntu, but it's less useful if I can't install the software I want with apt-get. Thus, I started wondering whether it's possible to install Debian packages in a non-standard location, without being root.

dpkg has a --root option that lets you change the installation prefix, but it still won't let you install anything without being root. apt-get will fetch packages, but, again, only as root. So I figured I'd write a script to do it all.

The script is here. It takes as arguments either the name of a package (like you'd pass to apt-get install) or the filename of a .deb, and the prefix to which you'd like to install it. It fetches dependencies (and the package itself if necessary), then unpacks the debs and installs them. I'm planning to use it in combination with stow to install packages to $HOME/.local.

Caveats:

• If you install more than one package with the same dependency, that dependency will be installed more than once. This will cause problems with stow. Hopefully common dependencies are already installed on your system.
• It only installs one level of dependencies, so the dependencies might be missing dependencies, causing things not to work.
• There is probably some terrible bug I don't know about. Let me know if you find one!

Sending Keystrokes to Applications in Linux (Programatically)

Lately I've been using the Awesome window manager, a simple dynamic window manager based on dwm. It's great, but it seems to fight with imwheel, which I've long used to map my mouse's thumb buttons to page-up and page-down. I wondered: why is there no reasonable imwheel alternative?

I tried xrebind and xnee, but it wasn't easy to get either to do what I wanted. I realized that Awesome has a built-in mouse binding support, but doesn't have a way to send keystrokes to client applications. So, I ended up figuring out a little C program that sends a keystroke to the focused client, and telling Awesome to run the program with the appropriate argument when the mouse thumb buttons are pressed.

Read more…

Xubuntu on the HP 2133 Mini-Note

After getting tired of the default SUSE on my Mini-Note, I decided to install Xubuntu (my Linux of choice). It didn't all go smoothly, following the wiki instructions, so I thought I'd write it up here. Note that these are instructions for installation from a USB drive. Doing it from an external CD drive may be easier, but I don't have one of those.

Read more…

Getting Pretty Emacs Colors in Screen

Emacs 22 has extremely nice color schemes for syntax hilighting. However, they only work in terminals that support lots of colors. By default, screen doesn't support lots of colors, so you're stuck with the plain old color scheme in emacs when using screen.

I recently found a good guide about how to make the pretty colors work in screen. The original URL of the guide is http://pastie.caboo.se/125089.txt, and I've mirrored it on xvx.ca in case the original disappears.

Happy emacsing.

Eclipse and the Mystical Error 13

This is less of a rant and more of a how-to. But also a bit of a rant, since there's no reason why I should have had to figure out how to do this.

What I wanted to do: Install Eclipse on our new database server and X-Forward it to my desktop, so I can compile some stuff we want to run on the DB server the same way I would compile it on my desktop. The database server is a 64-bit box running 64-bit Fedora.

What I expected to do: Install Java using the RPM from Sun's website (I don't trust Fedora's Java). Install Eclipse from the tarball on Eclipse's site (I don't trust Fedora's Eclipse). SSH into the server with -X and run eclipse.

What happened: Installing Java went fine, as expected. But then I tried to X-Forward something from that machine, and it didn't work. Of course, the server didn't have an X server on it, but we expected that as long as it had the X client libraries, we should be able to X-Forward without any trouble. As it turns out, you also need the xauth package. Of course, no one has documented this anywhere. But, once I had yum installed xorg-x11-xauth, it worked fine. Then came installing eclipse. Easy enough, un-tar the package in to /opt, and run it. I got a nice dialog box with an exceptionally informative error: Error 13. Thanks, Java.

As it turns out, one of the many causes of Error 13 is telling the 64-bit Java that your application is 32-bit. Magic portability my ass! And the kicker is: Eclipse doesn't link to a 64-bit version anywhere on their website. The only way to get it seems to be copying the location of the 32-bit version and rummaging through the directory where it's kept to find the 64-bit version. For your reference, the Europa version can be found here (courtesy of Waterloo's CS club).

So, there are three things to rant about here:

1. Java's error reporting: Error 13 wouldn't even be so bad if it were documented, but it's not.
2. The fact that even though Java claims to provide magic portability, you need to download a special 64-bit version of a Java app to make it run on a 64-bit system.
3. The fact that Eclipse knows about this, and even provides a 64-bit version, but doesn't link to that version on their website (which is a generally un-navigatable mess).