Skip navigation.
Home

DownloadManager

Summary: 
download manager for Fetch, limiting the number of simultaneous downloads
Current stable version: 
0.1.3
Current testing version: 
0.1.4
Primary author(s): 
Stephen Watson

This program acts as a download manager for Fetch (and possibly other programs), limiting the number of instances of Fetch that will be downloading at any one time.

The addapp feed for 0.1.2 is

The addapp feed for 0.1.2 is broken: it links to DownloadManager-0.1.1, but contains the file size and signature information for 0.1.2.

Thanks for fixing.

Injector feed

Updated now, please test.

(I have got to automate the release process more).

rox-release

I've put rox-release in CVS now. It's not finished, but it might be a useful starting point if you want to script things. I've used it to release Wallpaper and ROX-Session.

To use it, update all version numbers and commit any changes. Then:

$ cd releases
$ rox-release /path/to/cvs/myprog/myprog.xml

You should end up with two files in the current directory: a .tar.bz2 with the release and an injector feed which will download it from sf.net.

Other things it does includes: checking consistency of version numbers, checking for uncommitted files, tagging and exporting, running unit tests, creating translations, setting the release date and generating the manifest digest.

It's not very general (check for XXX and TODO in the code first!) yet, but feedback is welcome. Run with --test first for a trial run (no CVS operations).

I'm hoping to get more done on it this weekend...

Works now, thanks! Btw, I

Works now, thanks!

Btw, I had to change the python binary in the first line to "python2.4" (on debian unstable, dbus bindings at version 0.60 are available only for python 2.4).

I realize that it is a nightmare to support every configuration, but could you make that the default? I think that there are a few debian users who would thank you for it (-:

python2.4

I really think that is Debian's problem, not mine.

Debian's D-BUS support

There's already a Debian bug about this: bug 346491.

I think we need an exit strategy for D-BUS. The number of problem configurations is ridiculous. Do we have an XSOAP implementation for Python? That might be the answer, especially if we make the API similar to the D-BUS APIs.

Python XSOAP

I looked into it a while back but pygtk is missing some critical API (sending client messages if memory serves) so I got nowhere.

The DBus mailing list has had some more rumblings over the weekend about releasing 1.0, but it still seems to be of the order of months.

Alternatively

ln -s .../python2.4 ~/bin/python

and make sure you have ~/bin earlier in your path. Unless you have a reason to prefer older versions of Python...

Syndicate content