Archive for April 2009

More on the move to Arch Linux

After installing a basic Arch system and adding X.org it still isn’t very usable. My desktop of choice is Gnome, so that’s what I installed next, with a few extra packages to make it prettier and more useful.

I found out the hard way a few weeks ago that if you install gnome without gnome-extras then it’s a bad idea to install gdm and configure your system to boot to X. That way you’ll end up in a situation where your desktop doesn’t have an X terminal. I made sure to avoid that situation this time around. After installing gnome,gnome-extras and gdm I noticed that both gdm and policykit created users with uid 120 and 102, respectively. Just like exptected from services they have low uids. What surprised me was that they ended up having gid 1001 and 1002. That looks like bugs to me :-) I decided to fix that up manually myself by editing the group file (using vigr of course) and then searching for all file with the offending gids (using find / -gid 1001 for the first, with obvious changes to find the second).

After configuring gdm I realised I also needed gdm-themes :-) And I also added a few pretty fonts, and removed a few of the unpretty ones:

# pacman -S ttf-ms-fonts ttf-cheapskate artwiz-fonts ttf-bitstream-vera
# pacman -Rns xorg-fonts-75dpi xorg-fonts-100dpi

Then of course I needed to install xmonad:

# pacman -S xmonad-contrib

Co-ercing Gnome to actually use it was interesting though. I followed the instructions for running Xmonad in Jaunty, but that wasn’t enough. I also needed to place a file named xmonad.desktop in /usr/share/applications/ with the following contents (greatly inspired by the metacity.desktop found in the same location):

[Desktop Entry]
Type=Application
Encoding=UTF-8
Name=Xmonad
Exec=xmonad
NoDisplay=true
X-GNOME-WMName=Xmonad
X-GNOME-Autostart-Phase=WindowManager
X-GNOME-Provides=windowmanager

After that it was time to install stuff that is useful :-) First off was Thunderbird, which I immidiately had to equip with a few plug-ins of course. When setting up my mail account again I noticed that my Gnome session wasn’t quite the way I wanted—there was no gpg-agent running. After a quick check with the people on arch-general, without receiving any definitive resolution, I wrote my own little hack to address it. Of course I posted it in the thread I had started, but I might as well include it here too:

--- /etc/gdm/Xsession_orig  2009-04-27 17:13:50.346834448 +0100
+++ /etc/gdm/Xsession   2009-04-27 17:16:25.310151728 +0100
@@ -213,6 +213,14 @@
   fi
 fi

+# add seahorse if found
+seahorse="`gdmwhich seahorse-agent`"
+if [ -n "${seahorse}" ] && [ -x "${seahorse}" ]; then
+    command="seahorse-agent --execute $command"
+elif [ -z "${seahorse}" ]; then
+    echo "$0: seahorse not found!"
+fi
+
 # add ssh-agent if found
 sshagent="`gdmwhich ssh-agent`"
 if [ -n "$sshagent" ] && [ -x "$sshagent" ] && [ -z "$SSH_AUTH_SOCK" ]; then

There’s one more tool I can’t live without, parcellite, which is also available pre-built on Arch.

Moving to Arch Linux

<rant>So my irritation with Debian on the desktop reached a critical moment over the last few days. Sid is a good desktop system for most things, but if you are interested in Haskell then you really should prepare yourself for being a little behind on things. If it isn’t GHC that is out of date then it’s some library that hasn’t been rebuilt for the latest version of GHC. If you’re lucky then new packages are uploaded to the NEW queue and it’s only a matter of waiting for the autobuilders to get to them. Of course that doesn’t mean you can get those packages, so not that much luck in the end anyway.</rant>

I decided to move to the only other distro I’ve used seriously since Linux’ move to 2.x kernels, Arch. I remember it as a slightly less polished than Debian, but more up-to-date than even Sid. Also, there is a vibrant group of Haskell hackers working on providing almost all of Hackage in Arch’s native packaging system.

Installing Arch turned out to be a bit of a blast from the past, even when compared to Debian. Luckily the Arch wiki is there to help with the things that are different compared to Debian. I would suggest having a second computer with a browser pointed to Arch’s home pages nearby during the entire install.

For my installation of Debian I had opted to use LVM and I wanted to keep my /home around so I had to follow the steps required to use LVM in Arch. Installation went smooth and the reboot was successful. Now starts the hard work—configuring the system and updating my home folder.

The very first thing I noticed was that vim wasn’t installed by default, only vi was available. Not a big problem, except that my muscle memory resulted in a lot of vim: command not found messages. Clearly I had to install vim just to keep my sanity.

Next thing to do was to install X.org and the video driver I need:

# pacman -S xorg xf86-video-intel

After adding hal to /etc/rc.conf I started it manually and I ran startx as non-root. Wow, it all worked perfect, without creating any configuration file for X first. I double checked and it used the driver I wanted, i.e. it didn’t pick a safe default, like vesa, as its first option. Brilliant.

After following the instructions for changing the keyboard layout in X.org using hal I even had my ‘@’ on the right key. (The most confusing thing was that in X.org the UK keyboard layout is called gb, while in the console setup it’s called uk.)

I’ll post a bit more about the setup and configuration of my system as I progress towards my ideal desktop.

dataenc 0.12.1.0 released

Yesterday I released a new version of dataenc. It’s available on Hackage of course. Summary of (visible) changes:

  • implementation of a bunch of new encodings:
    • xxencode
    • quoted-printable
    • python escaping
    • url encoding
  • squashing of a bug in the yEncoding implementation that only manifested on 32-bit systems
  • an attempt to conform to the guidelines for the Haskell Platform regarding versioning and dependencies

Missing data encodings?

My thoughts on debianisation of haskell packages

I have written a few posts on debianising haskell packages in the past. Back then I stopped looking at it because of the age of the ghc-related packages in Debian Sid. Things have since improved and I’ve finally found some time to revisit the problem. This isn’t however a technical post, but rather a post on the strategy I think would be best for making Debian the best Haskell development environment in the universe.

In my opinion there is no point in trying to get all packages on Hackage into Debian proper. The few Debian developers (DD) who are interested in Haskell and maintain the existing packages are already terribly short on time and adding further burden would improve the chance of timely availability of GHC in the future. Sure, it would be possible to recruit more DDs with an interest in Haskell (I’ve considered in the past to try to become a DD, but the timing was off on both sides and I decided to postpone it) but it would take time. Maintaining 1000 packages is a huge task, and would require quite a large team I think. I suspect the recruiting would be such that if one were to plot the number of packages the team could maintain as it grew over time, compared to the number of packages on Hackage, then the lines would diverge rather than converge ;-)

Instead I think all packages on Hackage should first be debianised and put in a source-only repository. As some packages grow in importance and get added into Debian proper (e.g. a killer-app written in Haskell) then it and its dependencies are removed.

I believe that with this solution it’d be possible to quickly make a large part of Hackage available on Debian while still giving the DDs time to grow the number of “Haskell-friendlies” within Debian.

This of course rests on a few assumptions:

  1. It would require a smaller team to maintain source packages than binary packages. At least it would require less time from DDs.
  2. There is some space to store the source packages, ideally non-Debian space since that would mean even less involvement required by DDs.
  3. There’s a tool available in Debian that makes it easy for end-users to download, compile, and install source packages.
  4. There’s a tool that automates the creation of a Debian source package from a Cabal package.

In my optimism I’ve decided to not worry about the two first points and instead focus on the last two. Besides the optimism they also feel like the points I can actually address on my own, I’ll need help with the first two.

The tool in Debian for handling source packages is apt-src. In my opinion it will suffice, but if the developer would address one issue then it would be perfect.

The tool for automating the creation of Debian source packages could be cabal-debian. It is a very good tool, and it seems to be suited for maintaining Debian packages. I only have two objections to it. The first objection I have is that it is almost too well engineered; it does more than is necessary, e.g. there is no need to maintain proper changelogs in the source repo. The second is that it requires all dependencies of a package to be installed when it’s debianised. It is almost certainly the tool for the team charged with maintaining a large set of Cabal-based packages in Debian proper, but for the source-repo it might be too much. Because of that I’ve started hacking on a simplistic tool that I feel would be better suited for the source-repo.

VirtualBox with Linux 2.6.29

After a recent upgrade which brought in kernel 2.6.29 VirtualBox stopped working for me; the kernel module failed to find the symbol g_SUPGlobalInfoPage. How irritating!

Here’s a solution I found:

  1. Modify /usr/share/virtualbox/src/vboxdrv/Makefile, uncomment the line

    # VBOX_USE_INSERT_PAGE = 1
    
  2. Recompile the kernel modules:

    # /etc/init.d/vboxdrv setup
    

Now I only have to find a solution for the second problem that upgrade brought in, deskbar-applet failing to load in the Gnome panel.