Advogato blog for sivang

5 Nov 2006

Sun, 5 Nov 2006 12:07:52 GMT

Through my work on hubackup, I'm occasionally exploring other backup related programs, solutions and code. This is to make sure that while climbing a mountain to mount its top, I have not forsaken any good rocks I could use to support myself instead of paving the way all alone. Today I explored a set of perl and shell scripts collectively referred to as Backup Manager.

Lately packaged for Debian, I had wanted to peek at it to see if it can be a better candidate then DAR - as an archiver backend. HUBackup currently using subprocess control through pttys (using python-pexpect module) mandates that the candidate back-end archiver interactively interacts with the user for slice changes, and has enough verbosity to allow proper progress indication by the front end. Backup Manager seems to be able to provide these.

When I tried my go at it to see how DVD-RW backups would be handled, I realized that it mostly ignored me trying to set up any of the parameters listed in /etc/backup-manager.conf by just 'export FOO="bar"' and I actually was required to edit the conffile everytime I changed a backup parameter. even then there was some bug that prevented me from actually using this to start a backup. It kept complaining

/usr/share/backup-manager/logger.sh: line 44: -t: command not found

. Still a nice go again in a rather not-too-much-explored area, and I'll make sure to check it periodically as development continues, as this is among the very few brave hearts that attempt to integrate burning optical media backups, with the archiving scripts. I believe this integration is crucial to enable simple users (that usually do not have access to remote file servers) to create backups in a breeze. The fact it was written using perl and bash was of less appeal to me, as again forcing me to use process spawning rather then being able to import a module into my programs name space. One of my goals is to make hubackup more robust by getting rid of the back-end spawning "approach". I would like to be able to use DAR's features from within python instead of having to deal with hairy process and ptty's fd(s). I should explore again if DAR has grown python bindings or embark on writing some myself.

24 Oct 2006

Tue, 24 Oct 2006 15:24:24 GMT

HUBackup In Debian

I've been recently contacted by a debian developer that wants to upload hubackup to Debian, as it could be useful for Debian users as well.

Since I am not a Debian Developer, we've agreed to compliment each other's packaging work such that hubackup will be uploaded to Debian with him as the maintainer, and I as the co-maintainer, and share and forward bug reports and upstream changes.

I also wish to make hubackup a distro agnostic product eventually, as is a first of kind attempt to solve the issue of desktop backups, and other distros should enjoy it. While this involves mostly some source cleanup and adding non Debian dependency checks, hubackup will need an upstream web site where to publish tarballs, host documentation and provide news. Since hubackup uses PyGTK and GNOME, I wonder if it could be adopted by it and hosted there? I'll have to see about that.

23 Oct 2006

Mon, 23 Oct 2006 18:36:28 GMT

Nice to see interest raising in hubackup lately, as this blog post might suggest.

Recently I was joined by Martin Bergner (giftnudel) that now actively helps with excellent bug fixing and improving the various back ends I originally wrote for the program. It seems that with maybe another person like him, we could aim and reach high for releasing a very high quality, very focused solution for Feisty that would be included in main and supported by us. However, fear not! even if this does not happen I plan to work until I drop, to have as mentioned solution for edgy+1.

I've also set yesterday to think up how should the accompanying meta file used for mime type association.

My main goals at sight are finishing the mime type support, which would enable me to fix hurestore, since hurestore now relies on being invoked using mime-type association against the meta file in question, move to adjust it to the new GUI that was designed in UDS Paris and by this reach the development milestones.

We would then move on to fixing bugs through the development cycle and make sure no exception or error can go un-noticed or not propagated to the user in a clean, easy to understand manner.