[ Update, 2013-10: This post post is not up to date anymore. On newer Debians (since 7.0/wheezy) and Ubuntus (at least since 12.04, Precise Pangolin), you should be able to install zsnes out of the box: sudo apt-get install zsnes:i386. For details see the MultiArch documentation for Debian and Ubuntu. ]

Before I bought my current hardware, I was working on a 32-bit-based system, and I really appreciated ZSNES as an SNES emulator. But unfortunately, my new hardware was an AMD64 system, and there is currently no ZSNES package for 64-bit Ubuntu or Debian So I decided to google a bit about the issue, but it took me until now (a year later) to get ZSNES finally working on my machine. The problem is, if you build ZSNES on a 64-bit machine, all the application does is segfault at start, and if you try to compile for 32-bit systems, you get errors about missing 32-bit libs (in particular, configure does not find a suitable libsdl). Instead, if you just take the binary which was compiled on a 32-bit system, and install the ia32-libs package, everything seems to work—at least I was able to play a few levels of Super Mario World succesfully

So here was my idea: take the 32-bit package from the Ubuntu repository, and just change the Architecture control field, and by this fool dpkg :P And as it turned out, this idea worked great. You can get the Debian package here if you want, it should work for Ubuntu Karmic and Lucid, as well as for Debian testing (but I only tested it on Lucid, so there is no warranty here—but I’m happy to hear if it works :-)):

• zsnes_1.510-2.2ubuntu3~ppa1_amd64.deb
• SHA1: 716bbd37267b477ef02961a7727212619309b83f
• MD5: 452ea5230ad17df1dee649ab4cc6c8c0

How to Reproduce It

For the curious people reading here, here is what I actually did:

1. wget http://archive.ubuntu.com/ubuntu/pool/universe/z/zsnes/zsnes_1.510-2.2ubuntu3_i386.deb
2. ar x zsnes_1.510-2.2ubuntu3_i386.deb
3. tar xzf data.tar.gz

4. Edit usr/share/applications/zsnes.desktop and added -ad sdl to the Exec: field, otherwise it would just segfault on the first run:

   Exec=zsnes -ad sdl
   

5. Edit usr/share/doc/zsnes/changelog.Debian.gz and added a new changelog entry for the version (just copy one of the previous entries and adapt it)

6. tar xzf control.tar.gz

7. Edit the control file, changed the Version: and Architecture: field to amd64, added the ia32-libs dependency, and set myself as maintainer:

   Package: zsnes
   Version: 1.510-2.2ubuntu3~ppa1
   Architecture: amd64
   Maintainer: Roland Hieber <foobar@example.org>
   Installed-Size: 4160
   Depends: ia32-libs, libao2 (>= 0.8.8), libc6 (>= 2.4), libgcc1 (>= 1:4.1.1),
     libgl1-mesa-glx | libgl1, libpng12-0 (>= 1.2.13-4),
     libsdl1.2debian (>= 1.2.10-1), libstdc++6 (>= 4.1.1), zlib1g (>= 1:1.2.2.3)
   [...]
   

8. Change the md5sums file for the right values for usr/share/applications/zsnes.desktop and usr/share/doc/zsnes/changelog.Debian.gz (I used the md5sum command and copy-pasted it)

9. tar czf control.tar.gz control md5sums postrm postinst
10. tar czf data.tar.gz usr/
11. ar r zsnes_1.510-2.2ubuntu3~ppa1_amd64.deb debian-binary control.tar.gz data.tar.gz

I’m afraid that I can’t put the package into my PPA, Launchpad only accepts source packages for uploads, and builds the binary packages itself, both for i386 and AMD64. This approach can not be used here, since we needed the i386 binary for AMD64.

Yesterday, I ran into an interesting problem: I tried to set up SSH public key authentication between two of my machines, c3po and r2d2, so I could log in from rohieb@r2d2 to rohieb@c3po without a passphrase. However, everytime I tried to login to c3po, I was prompted to enter the passwort for rohieb@c3po, and the debug output mentioned something that the key could not be verified. More astonishing, when I established a second SSH connection while the first was still running, I was not prompted for a password, and debug output said that key authentication had been sucessful. I googled a bit, and after a while got to this comment on Launchpad, mentioning problems when the user on the remote machine had its home directory encrypted through ecryptfs – which was the case for me. Of course, since ecryptfs only encrypts the user’s home after he has been authenticated, the SSH daemon cannot read his ~/.ssh/authorized_keys at the first time, and falls back to password authentication.

The Launchpad comment proposes to first unmount the ecryptfs filesystem, then store ~/.ssh/authorized_keys unencrypted, and then mount the encrypted home again (note that no program should be running that could try to access your home directory):

$ ecryptfs-umount-private
$ cd $HOME
$ chmod 700 .
$ mkdir -m 700 .ssh
$ chmod 500 .
$ echo $YOUR_REAL_PUBLIC_KEY > .ssh/authorized_keys
$ ecryptfs-mount-private

This works indeed, but has the drawback that key authentication only works for the first login, because ecryptfs hides the unencrypted files when it mounts the encrypted directory on login; and you had to synchronize the encrypted and the unencrypted version of authorized_keys everytime you add a new key. To circumvent that, I simply moved the file to /etc/ssh/authorized_keys/rohieb (with the file only readable and writable by me, and /etc/ssh/authorized_keys writeable for all users) and adjusting /etc/ssh/sshd_config appropriately:

$ sudo vi /etc/ssh/sshd_config  # or use your favorite editor instead of vi
[... some lines ...]
AuthorizedKeysFile /etc/ssh/authorized_keys/%u
[... some more lines ...]
$ sudo /etc/init.d/ssh restart

Update

There is yet a better approach instead, which doesn’t need the SSHd config to be edited at all:

1. login to the user on the remote machine
2. create /home/.ecryptfs/$USER/.ssh and put your authorized_hosts there

3. symlink your encrypted version there:

   $ ln -s /home/.ecryptfs/$USER/.ssh/authorized_hosts ~/.ssh/authorized_hosts
   

4. symlink your unencrypted version there (as above, make sure no process wants to write to your home directory in the meantime):

   $ ecryptf-umount-private
   $ mkdir ~/.ssh
   $ ln -s /home/.ecryptfs/$USER/.ssh/authorized_hosts ~/.ssh/authorized_hosts
   $ ecryptfs-mount-private
   

The paths are for Ubuntu 9.10 (Karmic Koala) and later. On other systems, you might want to replace /home/.ecryptfs with /var/lib/ecryptfs.