Never fear though, if you are willing to do a little bit of work . . . → Read More: Backporting new code to Debian packages]]> I like Linux distros packaging systems, especially Debian’s. It makes it trivial to install, remove and change to different versions of programs. The only problem is that sometimes there is a delay in packaging the latest version of an app.

Never fear though, if you are willing to do a little bit of work you can shoehorn the latest code into a package yourself without needing any special knowledge of how to create packages. Note this will only work with programs that already have been packaged since it re-uses the old packaging info with the new code.

I refer to Debian, but the exact same procedure will work on any deb based distro, such as Ubuntu.

Before starting make sure you have the devscripts and build-essential packages installed. These will install all the tools needed to build debian packages.

First download the source package of the old version.

apt-get source $NAME

Then, as a sanity check cd into the created directory and run

debuild -i -us -uc

This will probably complain about missing packages needed for building, so go ahead and install them with apt-get or aptitude or whatever. Then re-run the build command. Assuming that works you should end up with some .deb files in the parent dir.

Now grab the code for the latest version from its website. If it is not already in a tarball you’ll want to make one from it with

tar czf application_version-1.orig.tar.gz applicationdir

If it is a tarball already then just rename it to match the formatting application_version-1.orig.tar.gz. For example when backporting mesa I name the tarball mesa_7.7.0-1.orig.tar.gz.

Next copy the debian dir from the old application directory to the new one.

cp -a application-debianversion/debian application-newversion/

Then cd into the new directory and run

debchange -v version-1 "Updated code to latest version"

It is vital that the version number used in this command matches the naming of the .orig.tar.gz file you created earlier. For example for mesa I use 7.7.0-1. This is the magic that will make everything work.

The final step is to build the new package.

debuild -i -us -uc

and tada! With a bit of luck your shiny new version should be packaged up and ready to be installed.

I decided to . . . → Read More: Offsite backup Catch-22]]> Over the past couple of days I’ve been setting up a secure offsite backup for my home machines. Dreamhost started offering 50GB of space for backups for free to their customers, this is vastly superior to the “send an archive to gmail every now and then” method I was using before.

I decided to use duplicity as it will use scp as the transfer (among manu others), encrypts all the data and automatically does incremental backups transferring only the changed files. Newer versions even support gmail and amazon s3 as backends, which is really cool but not something I need.

I had one problem setting it up, which was the obscure and unhelpful error reporting.

Traceback (most recent call last):
  File "/usr/bin/duplicity", line 463, in 
    with_tempdir(main)
  File "/usr/bin/duplicity", line 458, in with_tempdir
    fn()
  File "/usr/bin/duplicity", line 451, in main
    incremental_backup(sig_chain)
  File "/usr/bin/duplicity", line 186, in incremental_backup
    bytes_written = write_multivol("inc", tarblock_iter, globals.backend)
  File "/usr/bin/duplicity", line 87, in write_multivol
    globals.gpg_profile,globals.volsize)
  File "/usr/lib/python2.5/site-packages/duplicity/gpg.py", line 217, in GPGWriteFile
    file.write(data)
  File "/usr/lib/python2.5/site-packages/duplicity/gpg.py", line 125, in write
    return self.gpg_input.write(buf)
IOError: [Errno 32] Broken pipe
close failed: [Errno 32] Broken pipe

That is not a useful error message (and I’ve programmed in python), the actual error turned out to be a typo in the GPG key id I had entered. Once I’d worked that out everything went fine.

The real problem is the catch-22 between security and recoverability. In order for the data to be secure it needs to be encrypted, for that you need either a key or a password (or both for an encrypted key). Therefore in order to restore the data you need a copy of that key/password, but the situations in which you are going to be restoring from the offsite backup are ones in which all your data and local backups have gone poof. In which case the key will have gone poof too.

Okay, if you used just a password and memorized it then you’d be fine. But a password you can memorize is probably too weak to be secure, certainly for me it is with my terrible memory.

So, in order to make the data recoverable the key used for encryption needs to be backed up offsite too, but then your security goes out the window. So the key itself needs to be encrypted before sending it offsite, and there we have the catch-22.

Data needs to be encrypted to be secure, but we need to save the key to make the data recoverable, which makes the data insecure.

What I do is seperate . . . → Read More: Home in subversion]]> I’ve mentioned previously that I’ve started putting my /home in subversion. I thought I’d go into how I handle things, as it takes a little adjustment in your thinking to get maximum benefit from this. I used this guide to get me started, and stuck pretty close to it.

What I do is seperate settings files into two groups, common and local (I don’t have any other data in home, that all lives on it’s own partition). Local settings are unique to each machine. Common settings are identical across all the machines the programs are used on. There are a few special cases that live in both worlds, like bash, but I’ll get to how I handle those later.

Each machine on my network has it’s own branch in the svn repo, and in each of those branches are two extra dirs, called “.svncommon” and “.svnlocal”. Inside these there are category dirs like “Bash”, “Devel”, “Internet” etc. that allow me to group together the settings for programs to make management easier. The .svnlocal one is not really necessary, I could just keep all the settings for the local group in the root of home instead of having them in .svnlocal and symlinks to those files in home but I like the symmetry of handling local files the same way as common ones.

Anyway, the category dirs in the common group are setup to use the svn:externals feature, so that they are actually connected to dirs in the trunk of the repo. So the files in ~/.svncommon/Devel are actually located in /trunk/Devel in the repo.

Here is the basic procedure I use to add a new machine to the shared setup (I assume the repo exists already).

1. First we need to add a branch for the new machine “svn mkdir svn://server/Repo/branches/MACHINE“
2. Then link the homedir to that branch so we can add the files “svn co svn://server/Repo/branches/MACHINE .“
3. Create the two dirs for the local and common files “svn mkdir .svnlocal .svncommon“
4. Setup the links to the common stuff”svn propedit svn:externals .svncommon”
   Bash/ svn://$REPO/trunk/Bash
GuiInternet/ svn://$REPO/trunk/GuiInternet
Internet/ svn://$REPO/trunk/Internet
Devel/ svn://$REPO/trunk/Devel
5. “svn ci .“
6. “svn up“

To add stuff to the repository you simply move it into one of the subdirs of .svnlocal or .svncommon. Then create a symlink to it in ~/ so the program can still access the file. Then “svn add” both the file and the symlink.

(the thingy at the bottom of the image) It’s achieved using the following magic incantation in my .screenrc

Oh, and each window gets automatically named after . . . → Read More: Screen hardstatus]]> GingerDog saw my screen and was curious about the status line I have. The entire screenrc I use.

(the thingy at the bottom of the image) It’s achieved using the following magic incantation in my
.screenrc

Oh, and each window gets
automatically named after the program running in it using the
following.

(Update 17/04/2006:
This appears to only work in a linux terminal, not any of the
X-terms. The X-terms seem to set the window title instead and I’m
not sure how to change this at the moment. I’m going to carry on
looking in to it though.) (Update 18/04/2006: Got it, for gui
terminals instead of “lastline” use “alwayslastline”)

Not being able to . . . → Read More: Backup script v2]]> I’ve rewritten my backup script in python (it was in bash) in order to make the old backup handling date-based rather than a simple iteration. So it now renames dirs to daily.1, daily2, weekly1, monthly1 for old backups that are one day, two days, one week, one month old etc.

Not being able to use external programs as easily means the script is about twice as big, but I guess the fewer external dependencies is a good thing. I’m still using ping and rsync binaries, I’d like to replace the ping with something in pure python but I’m not going to be reimplementing rsync in python .

There is also now a very nice option handling system, run gkbackup -h to see all the options. The log output is much better aswell, logging to stdout if running in a terminal and running quietly if not while also logging to a file in both cases if requested.

The new version is here.