clc-register-user-package to the rescue! Create ~/.clc/source and put your ASDF package there, then simply run

$ clc-register-user-package ~/.clc/source/package/package.asd

and volia, you can (require :package) from any of your Lisp systems there after.

It's pretty awesome. :)

First things first, the files I want to backup are owned by all different users, so the only user who can run the backup process is root. Therefore I can't just run rsync from my local machine and grab the files from the server, the backup process has to be run on the server and backup to the backup machine. Now in my case this was a bit of a trick because the backup machine was behind a firewall, so the server had no direct line of communication to it. So I wrote a script to turn on a reverse ssh port forward.

recv-serv-backup.sh

 
#!/bin/sh
 
ssh -R 8000:127.0.0.1:22 -N user@kvasir.mindstab.net
 

When run on the backup machine behind a firewall, it connects to the server (kvasir) and listens on port 8000. When ssh on kvasir connects to port 8000 it redirects that traffic to local port 22, the ssh port of the backup machine. This is how the firewall is gotten around. Reverse port mapping is a cool trick to master.

Next as root on kvasir I generated a public ssh key and put it on the backup machine so root could automatically log on repeatedly to the back up machine (think lots of rsync calls) once the key was loaded once. Then I hooked up the key to keychain. That is all better outlined at:
Gentoo Linux Documentation: OpenSSH key management, Part 1 and
Gentoo Linux Documentation: OpenSSH key management, Part 2.

The all I needed to do was poke the rsync syntax to use the nonstandard ssh port for backup. The best method I found was

rsync -e "ssh -p 8000" -av

rsync for those of you who don't know is a great little backup tools. It's like a smart (in that it only copies files that have been modified since the last backup) network aware (since it can use ssh) copy tool. Simple but really useful.

So with that I wrote a backup script on the server

server-backup.sh

 
#!/bin/sh
 
backup () {
        echo "$1..."
        DST=`echo "$1" | awk '{split($0,a,"/");  result = "/"; for (i=2 ; i < length(a)  ; i++)   result = result "/" a[i];  print result;  };'`
        rsync -e "ssh -p 8000" -acv $1 dan@127.0.0.1:~/kvasir$DST ;
 
}
 
backup "/svn"
backup "/git"
...
 

There is one caveat, rsync won't create subdirectories on the other side specified in the path so you need to create the basic directory structure.

 rsync -e "ssh -p 8000" -av /git user@127.0.0.1:~/kvasir/git

is fine because it will create /git just fine, but

 rsync -e "ssh -p 8000" -av /home/user user@127.0.0.1:~/kvasir/home/user

will fail if ~/kvasir/home doesn't exist. So you'll need to create the basic directory structure or enhance the backup function to strip out extra directories in the target path.

Finally, I didn't want anyone and everyone to potentially be able to gain access to private data on the backup machine, so the target directory needed to be encrypted. There are a lot of options, but I opted for the easy encFS route and just installed "cryptkeeper" and had it setup the directory.

Now all I have to do is mount the encrypted backup directory, run the script to turn on the reverse ssh tunnel, and run the backup script, and I have an encrypted backup solution for my server that gets around firewalls.

Not bad.

References

• What Goes Out Can Come Back In -- SSH tricks
• Google

In Firefox, goto "about:config" and put a filter of "vendor" in and hit enter. Change general.useragent.vendor from "Ubuntu" to "Firefox".

Then it works fine. It's annoying MS is still doing such browser specific tweeking and it breaks on something so small, but then again, it does seem that they at least support vanilla Firefox. I don't know how important the vendor string is but if it's breaking compatibility maybe Canoncial should leave it alone?

Approach 1: Failure
I spent a bunch of time trying to patch the build process in portage to coax SBCL into building. First, of course, I used gcc-config to disable the hardened gcc profile, and just use the vanilla one. Then I created a suid root shell script to call "paxctl -m -p -r -e $1" so that the sandboxed build process could disable PaX features on the SBCL binaries. I added the command to the ebuild, and created a patch to insert the command into SBCL's build process. The process goes like this, portage download's the SBCL source and a pre-compiled SBCL binary. The patched ebuild then calls my suid root script which disables PaX on the pre-compiled binary so it actually runs (as opposed to crashing under PaX) and then a new SBCL binary is built from the source and the pre-compiled binary builds a core file from the SBCL lisp source. The patched SBCL make.sh then again calls the suid root script on the new binary, so it will run. Then it should load the new core and recompile the system for itself. Sadly, while it runs at least, it chokes on the core file and hangs while using 100% cpu. I couldn't get past this so I eventually gave up. If anyone has any suggestions that'd be great.

Approach 2: Success
So the actually solution was as follows: Download the most recent precompiled SBCL binary from the website (1.0.15 for x86), run "paxctl -p -e -m -r -x -s " on src/runtime/sbcl (to cover all the bases). Then run "sh install.sh" to install SBCL to /usr/local. That's it.

The problem with this is you can't emerge lisp packages in portage, you have to install them by hand (unless maybe you want to fake inject the package into the portage database).

I downloaded a copy of slime, untarred it and popped it in my .emacs and I had a full lisp environment ready to go, and on my hardened machine no less. Not so bad.

It's really easy, especially with Ubuntu.

To start with, you need to be a router, so you need firewall software that can do NAT (network address translation). This is part kernel side (NAT and iptables options enabled and modules loaded) and part user space side, in the form of the program 'iptables', so make sure it is installed, which it is by default on Ubuntu (I think).

Now all you really need to do is add two routing rules, one says anything coming on the ethernet port should go through the NAT procedure, which basically means it's IP headers are tweaked to make it look like they originated from your computer and then you send them along to the internet. The second rule helps facilitate this (I'm a little less sure what it does, but it's needed).

In this case we are assuming the interface eth0 is the wired network and eth1 is the wireless. Change as required.

iptables --table nat --append POSTROUTING --out-interface eth1 -j MASQUERADE
iptables --append FORWARD --in-interface eth0 -j ACCEPT

Next you just need to tell the kernel port forwarding should be turned on, and you can do this through the wonderful /proc filesystem.

echo 1  > /proc/sys/net/ipv4/ip_forward

Now you're pretty much ready to go. Connect to the wireless, presumably though NetworkManager or your wireless toll of choice. Then enable the wired network manually.

ifconfig eth0 up 192.168.1.1

This turns on eth0 with a local network address of 192.168.1.1. Now plug your friend's computer into the ehternet port with a crossover ethernet cable or into a hub and then the hub into you with regular ethernet cable and have them manually pick an address on 192.168.1.* (or whatever local network you chose, it doesn't matter) and set you (192.168.1.1) as the gateway router.

If this is a little much for them or they are running an OS that makes this non trivial, than its really another easy step for you to set up a DHCP server and do all the configuration for them :).

So install dhcpd, on Ubuntu it's 'dhcp3-server', on Gentoo I think it's just 'dhcpd'.

Now we have to configure it. We have to tell it the gateway router, which is us (192.168.1.1), the nameservers (the servers in /etc/resolv.conf) and the pool of IPs to use and what interface/network to listen on.

Open the config file, on Ubuntu '/etc/dhcp3dhcpd.conf'.

The relevant parts are as follows

...
# servers in /etc/resolv.conf
option domain-name-servers 192.168.0.1;

...

# the local network you created
subnet 192.168.1.0 netmask 255.255.255.0 {
        #IPs free to assign
        range 192.168.1.100 192.168.1.200;
        #your computer, the router
        option routers 192.168.1.1;
}

And that's it. (Re)Start the server

/etc/init.d/dhcp3-server restart

And you are now serving all the information your friend's computer will need to automatically connect properly.

They should now be online once they restart their internet connection.

One annoying thing about Ubuntu vs Gentoo is that on Ubuntu, the init system is a bit more kludgy and old fashioned. Any server software installed is automatically configured to start at boot time, forever, which in this case isn't what you want. You only want the dhcpd server to run very rarely, at parties, the rest of the time it's a waste. So we need to turn it's auto starting off. Apparently the /ubuntu init system barely supports this, we have to force it.

update-rc.d -f dhcp3-server remove

Now just turn it on when you need with its init.d file.

Then I went to use emacs on the console and the subtle light grey background highlight was suddenly grey text on a white background and completely unreadable. Very annoying, suddenly this little feature rendered -nox emacs useless.

Hours of google searching turned up nothing so finally I resorted to the irc channel. In only 10 minutes we got the answer.

<durka> aha
 customize emacs - applications - slime - slime mode - slime mode faces
 change highlight edits face

Thank you.

I've found documentation on the setup of git servers and public repositories kind of lacking, so here is my best attempt at documenting what works for me. Feel free to comment with bugs or enhancements please.

Contents

• 1. Setting Up A Local Repository
  • 1.1 From Scratch
  • 1.2 From An Existing Project
• 2. Setting Up A Remote Repository
  • 2.1 Remote Repository For Developer Only (ssh)
  • 2.2 Remote Repository For Public Access (git://)
  • 2.3 Shared Multi-Developer Public Repository
• 3. Managing Multiple Developers, Repositories and Branches
• References

1. Setting Up A Local Repository

Alice is going to start developing a project and she wants to add source control to it. There are a couple of reasons to set up a local repository that Alice likes including branch control, so that she can revert her code to previous releases, fix, patch or merge a bug fix, roll a release, and then pop back to the current development branch.

1.1 From Scratch

To set up a git repository for her project, Alice does the following:

alice@home $ mkdir proj
alice@home $ cd proj
alice@home $ git init

The project directory is now an empty git repository. As she creates files, she can add them to the respository with

alice@home $ git add newfile.src

And when she's done work or at least reached some break point, she can commit the new files, and all changes with

alice@home $ git commit -a

1.2 From An Existing Project

Also, occasionally Alice gets excited and starts coding before creating a repository. To create a repository from an already started project is as simple as

alice@home $ cd ~/proj
alice@home $ git init

and either

alice@home $ git add .

to add all the files, or

alice@home $ git add file1 file2 file3

to add just some of the files, both followed by

alice@home $ git commit -a

for the initial commit of the code to the new repository.

2. Setting Up A Remote Repository

Some times Alice needs her repositories to be remote and internet accessible. Sometimes she needs to work on them from several locations, and sometimes she wants her project's code to always be accessible to the public.

There are two primary methods for making remote git repositories accessible online. The first method is over ssh, which developers can use to both read and write to the repository and the second is through a dedicated git server which the public can use for read only access.

2.1 Remote Repository For Developer Only (ssh)

If Alice's project is personal and she just needs a central repository to access from a few locations like both work and home, she can set up a repository on any unix machine she has access to as follows.

Alice needs to create a bare repository clone of her working code and then transfer it to the server she will be using as the repository host

alice@home $ git clone --bare ~/proj proj.git
alice@home $ tar -czf proj.git.tar.gz proj.git
alice@home $ scp proj.git.tar.gz alice@server.com:~

Then, on the server

alice@server $ tar -xzf proj.git.tar.gz
alice@server $ mv proj.git proj

Now Alice can create working copies of the repository from anywhere, like work, and work on the code as normal as follows

alice@work $ git clone ssh://alice@server.com/home/alice/proj
alice@work $ cd proj
...
alice@work $ commit -a

However all this does is create a local clone of the repository and commit the changes to the new local clone. To push changes to the local repository back to the central repository, Alice does

alice@work $ git push

(As a note, Alice will also need to perform this clone of the remote repository at home so that her repository is aware of the remote repository, or she can use 'git remote add' to make her current original repository aware of the remote one)

When Alice gets home she can check out the latest changes with a simple

alice@home $ git pull

which pulls all the latest changes from the remote repository. Then she can develop, commit and push her changes and then the next day at work she can pull all those changes.

2.2 Remote Repository For Public Access (git://)

Now, to allow public read only access of the repository over the git:// protocol the steps of setting up a remote repository are all the same, however there are additional steps that need to be taken.

At a minimum, Alice needs to setup the git daemon on the server and tell each git repository that she wants to be publically accessible that it is so.

Setting up the a basic git daemon is up to Alice and her server's distribution, but once it is installed and running, it will try to export any directory on the server filesystem that is a) a git repository, and is b) flagged to be publically accessible.

To make her repositories accessible, Alice does the following

alice@server $ touch ~/proj/git-daemon-export-ok

Now when Bob hears about Alice's project, he can check out a copy of the repository himself as follows

bob@home $ git clone git://server.com/home/alice/proj

Bob actually ends up with the a full clone of the repository and can work with the code, and if he wants he can make changes and commit them to his local clone of the repository as normal. However, the one thing Bob cannot do is 'push' his changes back to the central repository.

He can, however, even stay up to date with the repository with git pull

bob@home $ git pull

and he'll always get the latest changes.

2.3 Shared Multi-Developer Public Repository

(Note: This is for those more used to CVS and Subversion style source control. Defacto and "proper" git style is outlined in section 3. Managing Multiple Developers, Repositories and Branches.)

Alice happens to have root access to her server and wants to set up a multiple developer git repository.

First she creates a git user group and makes a root git directory.

root@server # groupadd git
root@server # mkdir /git

Then Alice configures the git daemon to only export repositories in /git in the git-daemon's config file

GITDAEMON_OPTS="--syslog --verbose /git"

Now Alice creates a shared repository. She untars the git repository like normal, but sets its group to git and makes sure it'll stick by setting the stick bit, and then she makes it "shared" which means all the files are writeable by the group git.

root@server # cd /git
root@server # tar -xzf proj.git.tar.gz
root@server # mv proj.git proj
root@server # chgrp -R git proj
root@server # chmod g+ws proj -R
root@server # cd proj
root@server # git config core.sharedRepository true

And of course if Alice wants it to be publically viewable

root@server # touch git-daemon-export-ok

Now Alice has a git repository that several developers on the server can all use. Anyone in the git group can commit to the repository.

Alice's friend Charlie wants to develop for the project so Alice gives him an account on the server. Charlie can then start developing just like normal

charlie@home $ git clone ssh://charlie@server.com/git/proj
charlie@home $ cd proj
...
charlie@home $ git commit -a
charlie@home $ git push

Alice can get these changes at home, and any she's made from work with a simple

alice@home $ git pull

And if the repository was made public and exportable then Bob can checkout the code and keep up to date too

bob@home $ git clone git://server.com:/git/proj
bob@home $ cd proj
...
bob@home $ git pull

3. Managing Multiple Developers, Repositories and Branches

The proper way to use git with multiple developers is for each developer to have their own repository and branches and have a central manager who pulls from all the other branches and merges the code together before release. This is how Linux works (git was created by Linux's creator Linus).

Note: I know this is the proper way but I haven't really had any experience with it, so until I get time to play with it unfortunately this part of the document will be empty. Check out the official git manual for a good idea of how this should be managed, especially chapter 4 Sharing Development.

References

• Git User's Manual (for version 1.5.3 or newer)
• Setting up your Git repositories for open source projects at GitHub
• Google

It's as simple as this

rsync -a -e ssh Documents haplo@kvasir.mindstab.net:~/backup

And then the reverse to get new stuff.

The full article is at www.enterprisenetworkingplanet.com/netos/article.php/10951_1573881_2. I'm doing this with a bunch of my data now! I'm excited because I'd been thinking about setting up some backup solution for a bit but this is so trivially easy and more than good enough it's delightful.

 
grep -a -A 1000 -B 100 "import netpipe" /dev/md/5 > results.txt
 

The '-a' switch makes grep treat binary files like text files, so it'll work on devices, the '-A' switch tells grep how many lines to print After the line with the text we want is found and the '-B' switch tells grep how many line to print Before the line we want. I choose the numbers because the line I was looking for was clearly nearer the top of the file.

However this approach failed with grep giving me a ran out of memory error.

So a little more googleing and I found the solution, this little baby of a shell script

 
for ((skipamount=1 ; skipamount < 88188637184 ; ))
do
dd if=/dev/md/5 of=./testhex bs=1024 count=1024 skip=$((skipamount+=1024))
echo "Sector" $skipamount of 85899345920 echo "S" $skipamount>> ./found
echo >> ./found
grep "import netpipe" ./testhex --binary-files=text -A 1000 -B 100 >> ./found
done
date
echo "Done"
 

It's not pretty and you'll have to hand edit it to your particulars but essentially it reads over the hard drive picking out 1MB chunks piece at a time and running grep on those. The positive side of this is that it actually succeeded on running over my whole hard drive. The catches are that the found file is somewhat polluted with lines stating where it is, but this is actually handy because the other catch is that since we're pulling discreet 1MB chunks off the hard drive it's possible the file you are looking for will be arbitrarily split across them and you won't get all of it in your results file. But all the extra information in the fill will tell you exactly where to look and you can just use 'dd' to go in and get a more proper sized chunk with your whole file.

Anyways, a long story short, I found my file and was able to recover it. Hooray!

Also, a note! Crucial to deleted file recovery is to minimize writing to the drive the file was deleted on. Recovery works because the only information actually deleted are the pointers in the filesystem tree. The actually contents of the file are still on the drive, but now are as far as the file system is concerned, adrift in unused space and free to be allocated to be written over by the next program. So try to shut things down and stop writing to the partition with the lost files and run the recovery on a different partition or your recovery might overwrite your target!

Mission

To turn basic Familiar 0.8.4 on the IPaq hx4700 into something useful. More specifically, to make IR and Bluetooth work, to make my Belkin IR Keyboard (F8U1500-E) work, and then to install a Debian chroot on an SD card (via the cross install technique) where we can then install, for example, every programming language and text editor we could want for portable programming purposes.

Getting Started

So, first things first, you need an IPaq hx4700. Or at least an IPaq, and hopefully one supported by Familiar Linux. As you can see from the list the hx4700 is supposed to have A+ support. It turns out that's kind of a lie. But we can do surprisingly well with some work. First off, throw away the Familiar Installation guide, it doesn't apply to the hx4700. They put together a different one on the wiki at handhelds.org/moin/moin.cgi/HpIpaqHx4700HowtoInstallLinux. Read it.

Files and Filesystems

So now's as good a time as any to mention that I've collected all the files you'll need and put them on my FTP at ftp.mindstab.net/ipaq-hx4700.

First off you need a SD card and you need to write the bootloader all over it so whip out DD and does as the instructions say. Then when that's done toss an ext2 file system on your SD card, we'll need it later.

Now for some work with the CF card. Since we're flashing from it I'd suggest using the FAT filesystem. We'll stash all our system stuff on it here's a quick list of what you should grab from the FTP and put on it.

• zImage-2.6.15-hh2-ipaq-pxa270: kernel
• zImage-2.6.17-hh3: exciting new and more useful kernel, but we can't install it until the system is up and we copy it's modules over to the ipaq.
• bootgpe-v0.8.4-ipaq-pxa270.jffs2: Root filesystem with GPE installed. I'd recommend GPE over OPIE.
• reflash.ctl: Control file for the bootloader to know what it can flash. This one is updated with an option for the new kernel.
• RADIO0d.BIN: Firmware driver
• radio11.bin: Firmware driver
• wlangen.bin: Firmware driver
• 2.6.17-hh3.tar.gz: Kernel modules for a newer kernel. Untar it in place.
• install-firmware.sh: Shell script to install the firmware. The names are case sensitive so depending on how your FAT filesystem performs this might not work :/.
• install-modules.sh: Install the kernel modules for the 2.6.17 kernel. Assumes it's running with the untarred file 2.6.17-hh3.tar.gz. Copies the modules to /lib/modules on the ipaq.

And now is a good time to mention that I got an IR keyboard with my IPaq, specifically a Belkin F8U1500-E, which didn't work with the IPaq for a number of reasons at first. I solved them all. If you have this key board you'll also want the following files. If you have any IR keyboard you still might want at least the init.d file from the list.

• install-kbdd.sh: Shell script to install the files
• init.d.kbdd: Adds lines to the start function to remove extra IR kernel modules that prevent simply IR keyboards from working. Also kill irattach.
• kbdd.conf: Config file that just says use a belkinir keyboard on /dev/tts/2.
• kbdd: My patched kbdd program with proper support for my keyboard.

I also put up kbd.c which is the file I modified from the kbdd source for anyone who wanted to see what I'd done (also, I suppose, to comply with the GPL ;)). I know it's a hideous mess and hack, but using a case statement was easier initially in order for me to figure out how to get the keyboard working. I fully intended to turn it into an array latter, but once it worked I got lazy and left it. Meh.

Getting Familiar up and Running

Ok, you now have the CF card with all the files you need. Toss it in the IPaq and follow the flashing instructions on the wiki. Flash the 2.6.15 kernel, and then the GPE root filesystem. Then you can let GPE boot. It might take a bit.

Also, the boot loader and possibly the IPaq itself are kind of finicky. If it just won't turn on, don't worry, you probably haven't bricked it, its just in a funk. Let it sit for like 5 minutes. Also try pulling its battery for a bit, putting it back in and then putting it on AC power. Eventually it'll decide that the time is right to try booting again.

So, once GPE is up, there are a few change that we need to make to make life easier and better. First, go to "Setup->Login Setup" and set "Automatic Login" to yes. This will automatically log you on as root, instead of asking you for user name and password of some non root user. Really much beter in the long run for this device. Then log out and you should automatically be logged back in as root.

Now we can proceed.

We'll need to do some typing to get the necessary files installed, so you'll need to bring up the on screen keyboard. It kind of sucks, but I've seen worse. It is usable. Also, I've tried to write scripts to automate a bunch of stuff to keep the typing to a minimum until a real key board can be used.

So, bring up a root console from "Others->Root Console". "cd" onto the CF card, "/media/cf".

First we'll install the firmware, so run "sh install-firmware". Ideally this will work but you should double check and fix if it doesn't. What should happen is the 3 ".bin" files are copied into "/lib/firmware" and their names are all uppercase except the "d" in RADIO0d.BIN.

Next run "sh install-modules" which should copy the 2.6.17 kernel module directory (you untared the .tar.gz right :)) into /lib/modules. Now when we flash our new kernel it'll find it's kernel modules installed and actually work, as opposed to choking in boot, or booting but being generally useless.

If you have a Belkin IR Keyboard (F8U1500-E) then you'll also want my kbdd, and if you have any IR keyboard you might want my init.d.kbdd file.

So run "sh instal-kbdd". It should copy kbdd to /usr/sbin/kbdd (saving the old one as /usr/sbin/kbdd.old), copy kbdd.conf to /etc and copy init.d.kbdd to /etc/init.d/kbdd.

Now you should have your base system much closer to ready. Now that the firmware is installed if you were to reboot your Bluetooth should work. However the kernel that shipped with Familiar 0.8.4 had broken IR support, so we need to upgrade to the 2.6.17 kernel I compiled for the IPaq. If you have a different piece of hardware there are instructions in the handhelds.org wiki for getting and compiling kernel source. Ignore the part about them making their own configs, it didn't work for me, instead just copy /proc/config.gz to your sd/cf card and use that.

So to flash the new kernel after the modules are installed, reboot the IPaq holding the two upper keys (as the instructions said) as well to bring up the boot flasher and this time pick the 2.6.17 kernel.

Now it should boot up and Bluetooth and IR should work and your Belkin IR keyboard should work. Like magic. I still haven't gotten wireless to work but I'll update this if/when I do.

Wired USB internet

Next? We need connectivity. I still haven't gotten the wireless to work, but you can easily do ethernet-over-usb and use a desktop as a router. My instructions are Linux specific but I'm sure other OS specific instructions can easily be found by Google.

I already wrote instruction on how to get a mobile Linux device online with Linux so check out the instructions at www.mindstab.net/wordpress/archives/174#gp2x_networking.

The net.sh script for the IPaq has an extra line and looks like

#!/bin/sh

ifconfig usb0 up 10.1.0.2
route add default gw 10.1.0.1

and you can get it at ftp.mindstab.net/ipaq-hx4700/net.sh.

Native Video

So the IPaq can play video. It's a smidgen of a hack for GPE because the version with familiar doesn't actually have a mplayer compiled for it so I nicked the one for OPIE and flubbed one of the dependancies: instead of using the SDL 1.2.7 compiled for OPIE and depending on OPIE on used the 1.2.4 version compiled for GPE. This might be why the video is currently choppy until I can find a better solution because there might be a much faster rendering path on OPIE for SDL than there is under GPE. Still, this will work if you don't mind choppy video (but at least the audio is 100% solid). What I think I really need to do is find a way to make XV work on GPE and get mplayer to use it.

As for getting this working, all you need are some packages I've collected. Just grab the following from my iipkg collection at ftp.mindstab.net/ipaq-hx4700/ipkg:

• libmad.ipk
• libpostproc.ipk
• libsdl.ipk
• mplayer.ipk

I think that's all you need. Either way, if it asks for other dependancies they are in the folder, so just grab everything. I think you have to force one of them to install ignoring it's dependancies with the '-nodeps' flag. Anyway, once you get mplayer installed, it uses the SDL video output plugin. In order to make video and audio sync and not play laggy or slow I recomend the following flags:

mplayer -framedrop -nocache $MOVIE

As I said, it's currently laggy, but it works, and I'm looking for a better solution.

Making an ARM Debian Chroot

Note: For anyone who has been waiting for almost a year for my promised guide on how to make a Debian chroot for the GP2X, this is it. The instructions are the same. I originally did this on my GP2X until I got netwokring working on the IPaq, and shared the chroot SD card between them.

Now the IPaq only has limited space and only a limited number of programs compiled for it. If you want access to absolutely all software, then we need another source. The answer is a Debian chroot. Debian has great arm support so about 99% (Not Java) of stuff in the Debian repository will be accessible to you. All you need is space. So grab a decently sized SD card and put a reasonable filesystem on it, like ext2. Now, in order to install Debian we need Debootstrap, their utility for installing Debian from anywhere. You could try and install it on the IPaq but it'd be a hassle. I found the best solution was to download the ARM install disks (or minimal CD) and just copy off the entire filesystem. It's only a few MB. You can get my copy at ftp.mindstab.net/ipaq-hx4700/deboot.tar.gz Untar it on the SD card.

For this to work you'll need a network connection on the IPaq so make sure that's setup and working.

(For GP2X users, for each chroot (the debootstrap one, and the final one) you'll also want to run 'cp /lib/libiconv_plug.so lib' where lib is what will be the root lib directory in the chroot.)

Then on the IPaq execute the following to set up the environment to chroot into the Debian install environment.

cd deboot
cp /etc/resolve.conf etc
mount -t proc none proc
mount -o bind /dev dev
chroot .

Now you're in the actual minimal Debian install environment that is really only capable of doing one thing: running Debootstrap. So go for it. Install it in the chroot for now, you can always move it out once done.

debootstrap --verbose --arch arm etch /mnt/etch http://gulus.usherbrooke.ca/debian

Keeping in mind to change the Debian release name to what you want and to change the mirror to something appropriate to you. For a full list of Debian mirrors look at www.debian.org/mirror/list.

When it's done, you'll have your very own Debian chroot in /mnt/etch under the chroot or /media/card/deboot/mnt/etch in the IPaq filesystem.

You'll probably want to move the chroot to either the root of the SD card or just a subdirectory, so exit the chroot and then

mv /media/card/deboot/mnt/etch /media/card/etch

Now you have your very own Debian chroot. A few last things need to be set up before using it. Again, it will need internet too if you want to be able to install software, so run

cp /etc/resolve.conf /media/card/etch/etc

Next you need to add a few things so the environment will be have as Debian expects, and not inherit the slightly different IPaq environment, so grab profile and profile.ipaq and put them in the /etc directory of your chroot. Mostly it just sets your home directory to /root instead of /home/root and a few other minor things but important things.

Finally, get the chrootme.sh script and put it in the root of your chroot.

Now all you should need to do to use your chroot is

cd /media/card/etch
./chrootme.sh
source /etc/profile

Now you are in your live Debian chroot! Congrats! So why did we go to all this effort to just get another Linux environment when IPaq already has one? Well, this one can now install any software that Debian supports, which is pretty much all software :). But first, at least in my case, we have to do a few things for apt so it will be happy. Run

touch /root/.gnupg/trustedkeys.gpg

gpg  --keyserver subkeys.pgp.net --no-default-keyring --primary-keyring /etc/apt/trusted.gpg --recv 359AAB34 

wget http://ftp-master.debian.org/ziyi_key_2006.asc
gpg --no-default-keyring --primary-keyring /etc/apt/trusted.gpg --import ziyi_key_2006.asc

This install the required gpg trust info so that you can securely talk to the Debian package server.
You can also select a mirror by editing '/etc/apt/sources.list'. Now just

apt-get update

and then you can 'apt-get install ' any piece of software you want. I'd recommend starting off with a text editor like vim and/or emacs, and the some programming languages like Python, Ruby, Lisp, or C. Now you have a mobile coding environment that fits in your pocket!

Conclusion

Well, now you have an ultra portable computer that can run any piece of Linux software. I turned mine into a portable development machine. I've been using it at University in my CS classes, but you can do what ever you want with yours.

As for the future, the only real things this tutorial still need are ways to get the WiFi working and usable, and a way to squeeze better framerate out of MPlayer. If anyone has any ideas, please get in touch and let me know :)

I hope this set of notes/tutorial/howto is useful to anyone.