Search Results: "ana"

9 January 2010

Andrew Pollock: [life] Twenty weeks later

Sarah hit the 20 week mark on Monday, and so we had the big anatomical ultrasound. We also found out that it looks like we're having a girl. We're now trying to come up with a name. There was also a worrying piece of news: they couldn't see the cavum septum pellucidum, while they were checking out her brain. Apparently the cavum septum pellucidum is a particular marker they look for when they're checking everything out. Now what the absence of the cavum septum pellucidum actually means isn't terribly clear. Apparently normally this is found along with other abnormalities, but the rest of her brain structures look fine. The nuchal translucency we had earlier in the pregnancy came back fine also. So we got bustled off to have a chat with the genetic counsellor (during which the 4.1 earthquake happened). We got booked in for an amniocentesis for later that afternoon, as well as a fetal MRI at 22 weeks, and trundled off home. To cap things off, when we were trying to park back at the hospital for the 2pm appointment, I managed to scrape the car up against one of the poles in the car park. (The lower level parking is notoriously tight). Note to self: always use the free valet parking service from now on. Sarah had some second thoughts about the amniocentesis, as it does carry with it some risk of miscarriage, and after chatting with with a couple of the obstetricians, we elected not to do it. The fetal MRI should definitively determine if the cavum septum pellucidum is absent, and then we can talk to a paediatric neurologist about what the ramifications of that might be. One of the reasons they wanted to do an amniocentesis now, rather than after the fetal MRI, is the amniocentesis itself takes a couple of weeks for the results to come back, and that would bring us up to the 24 week mark. Apparently if we wanted to terminate the pregnancy, once it was at 24 weeks, we'd have to go to LA to do it. Whilst I consider myself an atheist these days, I was raised a Catholic, and although I like to think of myself as pro-choice, I still have a lot of problems with abortion, so I don't think I'd be comfortable terminating unless it could be shown with reasonable certainty that our baby was going to be in a really bad way. Based on how the rest of the brain looked, and the nuchal translucency results, and the fact that the amniocentesis would only identify chromosomal and not genetic neurological disorders, I don't think we'll be aborting. From my limited research, it sounds like the cavum septum pellucidum disappears at about 3 months after birth anyway, so looking at it one way, you could say our baby's brain is developing faster. Other research has indicated a correlation with optic nerve development issues, so I don't know if that means she might be blind. We really need to chat with a paediatric neurologist. But hopefully the fetal MRI will find it, and this will turn out to be nothing. An anxious two weeks will now follow.

8 January 2010

Theppitak Karoonboonyanan: My Recent Deb Migrations Finished

I've just finished migrations on Debian packages under my maintenance: The last upload was done on the New Year (2010-01-01). Just have time to blog about it.

Russell Coker: Ext4 and Debian/Lenny

I want to use the Ext4 filesystem on Xen DomUs. The reason for this is that the problem of fsck times on ext4 (as described in my previous post about Ext4 [1]) is compounded if you have multiple DomUs running fsck at the same time. One issue that makes this difficult is the fact that it is very important to be able to mount a DomU filesystem in the Dom0 and it is extremely useful to be able to fsck a DomU filesystem from a Dom0 (for example when you want to resize the root filesystem of the DomU). I have Dom0 systems running CentOS5, RHEL5, and Debian/Lenny, and I have DomU systems running CentOS5, RHEL4, Debian/Lenny, and Debian/Unstable. So to get Ext4 support on all my Xen servers I need it for Debian/Lenny and RHEL4 (Debian/Unstable has full support for Ext4 and RHEL5 and CentOS5 have been updated to support it [2]). The Debian kernel team apparently don t plan to add kernel support for Ext4 in Lenny (they generally don t do such things) and even backports.debian.org doesn t have a version of e2fsprogs that supports ext4. So getting Lenny going with Ext4 requires a non-default kernel and a back-port of the utilities. In the past I ve used CentOS and RHEL kernels to run Debian systems and that has worked reasonably well. I wouldn t recommend doing so for a Dom0 or a non-virtual install, but for a DomU it works reasonably well and it s not too difficult to recover from problems. So I have decided to upgrade most of my Lenny virtual machines to a CentOS 5 kernel. When installing a CentOS 5 kernel to replace a Debian/Lenny kernel you have to use console=tty0 as a kernel parameter instead of xencons=tty , you have to use /dev/xvc0 as the name of the terminal for running a getty (IE xvc0 is a parameter to getty) and you have to edit /etc/rc.local (or some other init script) to run killall -9 nash-hotplug as a nash process from the Red Hat initrd goes into an infinite loop. Of course upgrading a CentOS kernel on a Debian system is a little more inconvenient (I upgrade a CentOS DomU and then copy the kernel modules to the Debian DomUs and the vmlinuz and initrd to the Dom0). The inconvenience of this can be an issue in an environment where multiple people are involved in running the systems, if a sysadmin who lacks skills or confidence takes over they may be afraid to upgrade the kernel to solve security issues. Also apt-get dist-upgrade won t show that a CentOS kernel can be updated, so a little more management effort is required in tracking which machines need to be upgraded. deb http://www.coker.com.au lenny misc To backport the e2fsprogs package I first needed to backport util-linux, debhelper, libtool, xz-utils, base-files, and dpkg. This is the most significant and invasive back-port I ve done. The above apt repository has all the packages for AMD64 and i386 architectures. For a Debian system after the right kernel is installed and e2fsprogs (and it s dependencies) are upgraded the command tune2fs -O flex_bg,uninit_bg /dev/xvda can be used to enable the ext4 filesystem. At the next reboot the system will prompt for the root password and allow you to manually run e2fsck -y /dev/xvda to do the real work of transitioning the filesystem (unlike Red Hat based distributions which do this automatically). So the state of my Debian systems running this is that the DomUs run the CentOS kernel and my backported utilities while the Dom0 just runs the backported utilities with the Lenny kernel. Thus the Debian Dom0 can t mount filesystems from the DomUs which makes things very difficult when there is a problem that needs to be fixed in a DomU, I have to either mount the filesystem from another DomU or boot with init=/bin/bash .

Chris Lawrence: From the department of bad statistics

I m glad to see that some things never change; in this case, it s the low quality of local news reporting in Laredo. Pro8News breathlessly reports that Mexican drivers are less likely to be ticketed since less than 25% of parking tickets in Laredo are issued to Mexican-licensed vehicles. This story just begs to be placed on a research methods final as one of those identify all of the problems with this analysis questions. Bonus points for invoking Bayes theorem.

7 January 2010

Joachim Breitner: screen-message ported to Windows

Over the holidays I investigated how to cross-compile GTK applications for Windows, and managed to port screen-message. I also created an Inno Setup based installer for it that includes the necessary GTK DLLs. You can grab it from the screen-message homepage. The installer optionally binds screen-messages to the key combination Alt-Ctrl-S.
I would have published the binary much earlier if starting the application had not always given the error message
The application failed to initialize properly (0xc000007b). Click on OK to terminate the application.
on Windows, while it worked fine under WINE. It took me a while to find the cause, as there seems to be only one mention of it in the internet: One must not use MinGW s strip.exe utility on DLLs not created with MinGW, it seems. I added a make installer target to the Makefile to create the installer. If you are curious about how that works, have a look at the source.

Kumar Appaiah: Brief updates and some advice

So, while Richard is busy doing research and arranging or facilitating several Debian workshops, here I am, gulping down Idlis and Dosas by the dozen. It's been a fun visit, and I got to visit several places in my native state, but since my visit to Mumbai is rather short, I won't be able to say hello to several friends this time (Sorry Kartik). Maybe this would happen only when I am back in India on a permanent basis; let's see...Here are some general guidelines for travelers which I'd like to share:It's been a really fun trip, and I am sure I'll enjoy the rest of the trip, till I get back to my old routine and resume work.Finally, in keeping with the spirit of a blog I try to understand (albeit, in vain, I must accept), I duplicate the concept of a post from that blog, here is an up-to-date list of airports in which I have sat, but never left except by way of airplane:More updates later. Bye for now.

5 January 2010

Peter Eisentraut: Remove and Purge

Debian's package manager dpkg has the perhaps unique feature that it distinguishes between removing and purging a package. Removing it removes the program files but keeps the configuration files (and sometimes the logs) around, purging it really removes everything. While this distinction undoubtedly has some uses, I have found that I almost never make use of it. I think in about six years of using Debian I have actually needed a remove-but-not-purge functionality about five times, during some really tricky upgrades (and using Aptitude instead of APT might have helped, not sure) and once when I wanted to build a package that had a build dependency that conflicted with a package I had installed (cowbuilder came later).

I think many people don't fully realize this distinction, and thus aged systems will often contain dozens or hundreds of removed-but-not-purged packages lying around. Great fun cleaning that up. And therefore, at some point in the distant past I have switched all my APTs to purge by default, using the configuration setting Apt::Get::Purge "true";. At the time I thought this would be daring, but I have never looked back. The one time a year that I don't want to purge I override this by hand.

Later, APT actually got an apt-get purge command, but there is no apt-get autopurge and no apt-get dist-upgrade-and-purge (or whatever) to purge the packages it wants to remove. This can be worked around by carefully adding --purge to all invocations of apt-get, but who will remember that. And of course apt-get remove is hardwired into my fingers.

How do other people handle this? Are there undiscovered reasons removing is the better default? How do you clean up packages that were forgotten to be purged?

3 January 2010

Thorsten Glaser: new MirBSD-current snapshot; more TODO done

The MirBSD Midi-ISO (bi-arch manifold boot) and NetInstall for both i386 and sparc have been upgraded to the 20091226 snapshot (sorry for the delay). A separate news announcement will be done when a full ISO (MirBSD + MirGRML) is done. Other than that, I have fixed a couple of things all over the place, jupp for example. The planned release of mksh R39b is still not done though, as I m only human as well, and too much hacking isn t something one can do without relaxing some in between. On the Debian front, my RCBD #1 was continued, here s #1 results: Explanations: I did go overboard during the first patching session, but I suppose this is what the NM learning period is for too. The autossh maintainer said thanks and will probably integrate my patches, so I don t need to NMU. I could close the dietlibc bug. The other two didn t look as good, I had to separate the fix for the RC bug (and other required fixes, such as ftp-master rejects there were none though) and my other fixes; I submit the former as NMU diffs again and pointed Zack to the .dsc files, and opened the aforementioned two new bugs with the rest of the diffs, so the proper maintainers can take and apply them. There s questioning if gidentd should be removed (see the PR for more); the acorn-fdisk upstream (arm-fdisk it s called there) is not actively developing but will receive patches; the autossh maintainer said thanks but I didn t yet hear back from upstream. The binutils as intel_mode bug was fixed upstream and in experimental for my case, but I had to reopen things because the variant documented in binutils-current still doesn t work, so others (who use the new, more intel-like, syntax) don t run into it. Luk sent me a request to do more mipsel-FTBFS-due-to-toolchain-bugs workarounds. Will do (but can t promise to do so before the upcoming BSP. Robert Millan incorporated something like manifold-boot into GRUB 2, after I described it to him (the debian-bsd@ people are currently sorting out some heisenbugs with it, though). Now there s three variants (but then, this helps spotting bugs that don t appear in all implementations). sendmail 8.13.4 is out, I wonder when OgreBSD will upgrade I could do it myself again, but this time it s not that urgent. Still waiting for the TLS extension, though

Bernhard R. Link: Alpha testers wanted

If you ever tried to determine what patches other distributions apply to some package you are interested in, you might have come to the same conclusion as I: It is quite an impudence how those are presented. If you don't give up, you end up with programs or scripts to extract many propietary source package formats, more VCS systems installed than you think there should exist. Thats when you start to love the concept that every Debian mirror has next to each binary package the source in a format that you can extract the changes easily with only tools you find on every unixoid. And that's why I love the new (though in my eyes quite misnamed) "3.0 (quilt)" format, because that makes it even clearer and easier. Sadly one problem remained: How to generate and store those patches? While you can just use patches manually or use quilt to handle those patches and store the result in a vcs of your choice, the newfangled VCSes (especially git) became quite good at managing, moving and merging changes around, so it seems quite a waste to not be able to use this also to handle those patches easily. While one can either use git to handle a patchset, by storing it as a chain of commits and using the interactive rebase, or using git to store the history of your package, doing both at the same time is tricky and not resonably doable with git provided porcelain. Thus I wrote my own tool to faciliate git for both tasks at the same time. The idea is to have three branches: a branch storing the history of the your package, a branch storing your patches in a way suitable to submit them upstream or to create a debian/patches/ directory from, and an branch with the upstream contents. I've an implemenation which seems to already work, though I am sure there is still much to improve and many errors and pitfalls still to find. Thus if you also like to experiment with handling patches of a debian package in git, take a look at the manpage or the program at git://git.debian.org/~brlink/git-dpm.git
(WARNING: as stated above: alpha quality; also places are temporary and are likely to change in the future).

Clint Adams: Odontoceti

Is it just me, or did Jeff Addiss just say, Fuck you dolphin, fuck you, whale. ?

Mohammed Sameer: Not First MMS sent via N900 (Fremantle)

I've spent the past few days trying to get MMS to work on the N900.

EDIT: Seems frals has managed to beat me! read more

Dirk Eddelbuettel: Rcpp 0.7.1

Two weeks after the Rcpp 0.7.0 release, Romain and I are happy to announce release 0.7.1 of Rcpp. It is currently in the incoming section of CRAN and has been accepted into Debian. Mirrors will catch up over the next few days, in the meantime the local page is available for download too. A lot has changed under the hood since 0.7.0, and this is the first release that really reflects many of Romain's additions. Some of the changes are As before, fuller details are in the ChangeLog on the Rcpp page.

2 January 2010

Asheesh Laroia: Detecting stale versions of WordPress

I run a personal server that hosts web space for a few friends. Probably the most popular thing to do with the space is to install WordPress and run a personal blog. A few days ago, I discovered some attackers were abusing one of the sites. Once we upgraded the site to the latest version of WordPress, the attack went away. So I wrote a tool that, every night, emails me a report of the locations of old versions of WordPress. A sample email:
Current version of WordPress: 2.9

oldroommate has WordPress 2.5 in /home/oldroommate/web/oldroommate.com/
Eek! WordPress 2.5 is old!

How it works Each time it runs, it looks at wordpress.org to see what the current version is. The code to do that is written in Python and uses lxml.html. It prints the current version in the report, and it uses it when analyzing WordPress installs. To analyze WordPress installs, it executes locate readme.html, looking for WordPress's tell-tale documentation file. For every such readme.html, if it matches a simple regular expression suggesting it's a WordPress readme file, it performs the following analysis:
  • It does some simple seding and greping looking for the version of WordPress described by that file.
  • If the version detected is older (as calculated by dpkg --compare-versions), it creates a one-line report like the one above about oldroommate.
If it found any installs of old WordPress, it prints a report like the one blockquoted above to stdout.

How to use it To get emails, I run it with cron. You can add a stanza like this to your crontab (edit it with crontab -e):
@daily cd find-out-of-date-wordpress; ./look.sh
Ta-da, nightly reports.

To get a copy Do a git clone:
git clone git://git.asheesh.org/find-out-of-date-wordpress.git
or browse its gitweb.

Feedback I'm quite interested to hear what others do to avoid old web apps being attacked. If there's another bit of software that monitors web apps for needing upgrades, I'd love to hear about it! Obviously if you have feedback on this tidbit I wrote, let me know. (To me, apt-get doesn't seem to be the answer. Web apps (especially PHP ones) don't usually seem to support keeping the code in one place with multiple different configuration files. And users get excited about the latest and greatest and don't want to wait for me to upgrade, and I can't blame them.) If some of you don't like the Python dependency or anything else, I do welcome patches!

1 January 2010

Thorsten Glaser: RCBD #1

My first RC Bug-squashing Day (or rather night): I picked all of them mostly randomly from the list Zack gave me, and except dietlibc they are packages I had not even heard of before. The first one begun easily (track down licencing information, pimp debian/copyright, but I ended up fixing compiler and lintian warnings and even wrote a manpage for it while there (but for this one, I didn t bump the Standards-Version). The second one was only the second one to complete because the others took longer; it s basically a change of a d mon to use two instead of one listening socket, to work with a doble stack OS instead of just a dual stack OS by not using v4-mapped IPv6 addresses (I considered if to use select(2) or poll(2), or to just fork and have two d mons running, but that seemed too ressource-consuming to me so I chose the less-complicated poll(2) method, looking at popa3d(8) s source code (inherited from OpenBSD) in the MirBSD tree since I could not find my network programming book. The third one was basically communicating with upstream; the bug can be blosed with no change to the package. The fourth one took me a while; luckily I have qemu 0.11.0 on MirBSD, and aurel32 s mipsel qemu images helped a great deal; however, cowbuilder --create failed for me, so I ended up waiting almost the entire night for a-g d-u to finish; in the end, it was simply a bug in upstream s configure.ac which is only exposed due to a toolchain bug on mips(el). To do: my AM Zack needs to upload the NMUs (after checking, of course); I need to communicate some of the fixes upstream (the gidentd upstream is NXDOMAIN ), produce a very small testcase for the mipsel toolchain bug, maybe fix some more mipsel FTBFSen as I have a working qemu instance now, but maybe I ll do that at the BSP when I can t find IPv6 bugs or so that I feel I can fix (I also want to do an mksh release which has to be prepared first RSN, and there s still the need to formally publish the MirBSD-current bi-arch snapshot and make another ISO out of it for BT and prepare the multi-BSD USB stick for allbsd.de ). Annoyances: a-g d-u could ask me things at the start before working for some four+ hours instead of in the middle, and the same questions several times (PAM restart). The sid kernel doesn t boot today but did yesterday, the lenny kernel produces this:
Starting the hotplug events dispatcher: udevdudevd[320]: udev: missing sysfs features; please update the kernel or disable the kernel's CONFIG_SYSFS_DEPRECATED option; udev may fail to work correctly
(I hate udev.) And, worst of all, these annoying fireworks (some sounded like originating from inside our staircase, I pity the neighbour s cats) when one wants to hack Finally, I *loathe* CDBS. Debhelper v5 rules! Oh, and I also was under the impression that Firstname LASTNAME was a French thing, and to a much lesser extent Asian. (@bubulle)

Craig Small: Happy new RC

It's the late afternoon of the first day of 2010 here, though I suppose its still 2009 for someone for a little while.

After a lot of waiting, JFFNMS release candidate 1 for 0.8.5 got uploaded to sourceforge. This release is mainly about fixing some database release bugs 0.8.4 had and they're all caused by the fact that working with PHP and database to release code is plain awful.

The problem is tracking changes in your database. So version 1 has 3 tables and 60 rows, version 2 has 4 tables and 90 rows, but what changed? Everything I've seen so far is a bit of a hack or is real fiddly. JFFNMS release process is both which is why I'll go and release several versions of C code or Debian packages before trying to crack that nut again.

If you are wondering what JFFNMS is, its a Network Management System. It makes graphs and red/green icons depending on the status of your routers and servers. Written in PHP and web based and of course licensed under the GPL
<script defer="defer" src="http://static.zemanta.com/readside/loader.js" type="text/javascript"></script>

29 December 2009

Wouter Verhelst: Perl on the N900

Since about a week, I have a Nokia N900. They're not actually on sale in Belgium yet, but I managed to get hold of one through a grey market shop. The device is quite nice. I do have a few irks with the interface here and there, but Nokia has a public bugzilla that I'll surely use to file bugs whenever and wherever appropriate. And after using it for about a week, I thought of migrating this small application which I once wrote on half an afternoon using perl, postgres, and Gtk2, to the device. It's mainly a cataloguing system that I store my DVD collection in (which has gotten large enough that this is necessary), nothing earthshattering. The ideal candidate to get my feet wet in developing for the N900, so to speak. That effort got stopped dead in its tracks pretty quickly.
Nokia-N900-42-11:~# perl
use Gtk2;
Can't locate Gtk2.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.8.3 /usr/local/share/perl/5.8.3 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl .) at - line 1.
BEGIN failed--compilation aborted at - line 1.
Nokia-N900-42-11:~# apt-cache search perl
perl - Larry Wall's Practical Extraction and Report Language.
libpcrecpp0 - Perl 5 Compatible Regular Expression Library - C++ runtime files
po4a - tools for helping translation of documentation
libpcre3 - Perl 5 Compatible Regular Expression Library - runtime files
libgdbm3 - GNU dbm database routines (runtime version)
perl-base - The Pathologically Eclectic Rubbish Lister.
liblocale-gettext-perl - Using libc functions for internationalization in Perl
Or, in other words: they only ship the perl bits needed to make dpkg run. Hrmpf. This would make stuff slightly more... involved. Oh well.

28 December 2009

Luca Bruno: Uzbl in Debian


After some delay, uzbl is now available in Debian (testing and unstable). Uzbl is a webkit based browser which aims to adhere to the Unix philosophy of having programs that do one thing and do it well; as such, it comes with a main binary (uzbl-core), acting as the real web-renderer, which is controllable by third-parties via standard fifo s and sockets. The package also bundle some external helper scripts for daily web-surfing (ie. handling history, bookmarks, cookies, etc.) and a ready-to-user wrapper (uzbl-browser) to help setting up the environment, using the default config.
As a standalone browser, it may look quite similar to vimperator (default key-bindings and interface are strongly vim-like), but overall it offers a more powerful and completely reconfigurable user-interface, can be fully scripted and hooked with self-made helpers and is even embeddable in other applications (eg. Emacs). Nonetheless, it brings all the power of a fully fledged webkit renderer. You may find it particularly useful when working within a tiling window manager (like awesome or xmonad), or used as a full-screen remote monitor, easily controllable via socket (you should really try socat with it!) or plain-text fifo (for a bunch of stats, as easy as a echo "uri italiaora.org" > /tmp/uzbl_fifo_your-instance )

27 December 2009

Francois Marier: Ignoring files in git repositories

According to the man page, there are three ways to exclude files from being tracked by git.

Shared list of files to ignore The most well-known way of preventing files from being part of a git branch is to add such files in .gitignore. (This is analogous to CVS' .cvsignore files.)

Here's an example:
*.generated.html
/config.php
The above ignore list will prevent automatically generated HTML files from being committed by mistake to the repository. Because this is useful to all developers on the project, .gitignore is a good place for this.

The next line prevents the local configuration file from being tracked by git, something else that all developers will want to have.

One thing to note here is the use of a leading slash character with config.php. This is to specifically match the config file in the same directory as the .gitignore file (in this case, the root directory of the repository) but no other. Without this slash, the following files would also be ignored by git:
/app/config.php
/plugins/address/config.php
/module/config.php

Local list (specific to one project)For those custom files that you don't want version controlled but that others probably don't have or don't want to automatically ignore, git provides a second facility: .git/info/exclude

It works the same way as .gitignore but be aware that this list is only stored locally and only applies to the repository in which it lives.

(I can't think of a good example for when you'd want to use this one because I don't really use it. Feel free to leave a comment if you do use it though, I'm curious to know what others do with it.)

Local list (common to all projects)Should you wish to automatically ignore file patterns in all of your projects, you will need to use the third gitignore method: core.excludesfile

Put this line in your ~/.gitconfig:
[core]
excludesfile = /home/username/.gitexcludes
(you need to put the absolute path to your home directory, ~/ will not work here unless you use git 1.6.6 or later)

and then put the patterns to ignore in ~/.gitexcludes. For example, this will ignore the automatic backups made by emacs when you save a file:
*~
This is the ideal place to put anything that is generated by your development tools and that doesn't need to appear in your project repositories.

Chris Lamb: Readline tab completion using Django models

The following snippet allows readline-style tab completion backed onto Django models. I am using this in management commands in preference to specifying primary keys as arguments.
class QuerySetCompleter(object):
    def __init__(self, qs, field):
        self.qs = qs
        self.field = field
        self.prefix = None
    def __call__(self, prefix, index):
        if prefix != self.prefix:
            qs = self.qs.values_list(self.field, flat=True)
            if prefix:
                qs = qs.filter(** 
                    '%s__startswith' % self.field: prefix,
                 )
            self.matching = list(qs)
            self.prefix = prefix
        try:
            return self.matching[index]
        except IndexError:
            return None
Example usage:
import readline
from mymodels import MyModel
completer = QuerySetCompleter(MyModel.objects.all(), 'name')
readline.set_completer(completer)
readline.parse_and_bind("tab: complete")
readline.set_completer_delims('')
while 1:
    print repr(raw_input(">>> "))
Pressing <tab> at this >>> prompt will complete from the name field of the MyModel model just like a regular shell would. We call readline.set_completer_delims as our items may contain word delimeters - otherwise readline would attempt a seperate completion of (eg) "Bar" if one of our items was "Foo Bar".

Andreas Barth: Backup non-NIH?

I'm currently looking for some backup tool, but each tool lacks some features. I'd like to I took a deeper look at duplicity, but the encryption to gnupg means I need to copy files around. Also the webdav-uploader has some issues if backups get too large (i.e. uploads take too long). Any other hints? Or is it worth to start to enhance duplicity? Update: I'd like to generate the backup on the backuped system, but to manage them (i.e. purge old versions) on the backup system. And of course restore to any host within my control. Without exposing any affected gpg key, but just the one-time key(s) for the affected backup(s).

Next.

Previous.