Re: Python < 2.5 anyone?

["Elijah Newren" <newren gmail com>]

On Dec 24, 2007 2:24 PM, Olav Vitters <olav bkor dhs org> wrote:
> On Mon, Dec 24, 2007 at 02:46:15PM +0100, Olav Vitters wrote:
> > I've been changing convert-to-tarballs.py and realised that it now
> > requires Python 2.5. Does anyone have 2.4? I can maybe support that (I'd
> > rather not though).
> >
> > Changes I've made up to now:
> >  * General cleanup of the Python code
> >  * Sort of handle the gtksourceview-1.0 case
> >  * Allow to call convert-to-tarballs.py from another directory
> >  * Waf support (meaning, the <waf> XML bits)
> >  * The following works on a 'proper' setup: convert-to-tarballs.py -v 2.11.91
> >    (the location of the gnome-2.22.modules + tarball location)
> >  * Determine latest tarball versions on download.gnome.org using sftp.
> >    This to avoid mirror lag
> >    Notes:
> >     - Still downloads using http
> >     - Requires: python-paramiko package, ssh-agent setup, configured
> >       username for master.gnome.org in ~/.ssh/config and
> >       master.gnome.org should appear in ~/.ssh/known_hosts
> >     - Automatically falls back to http if sftp support is not working
> >       (not in all cases)
> >     - Need to add a connection cache as logging in is slow
> >  * Handle http redirects a bit better (download.gnome.org), this
> >    avoids ~ 50 secs of redirects (could be further improved)
>  * Now with a connection cache. SFTP using only Python is still really
>   slow though. It adds ~2 min to the whole process.
>  * Switched to curl instead of wget. This for the 1-line progress bar.
>   Further, made curl change the local tarball timestamp to that of the
>   server. Wget could do this as well, this is just a preparation for
>   when someone wants to check when a tarball was released (either in
>   the script or a ls -lt in the tarball directory).
>
> The conversion at this time takes ~11min (with a clean tarball
> directory). I'll now try to add more error checking to the script
> (to avoid too new tarball versions being released accidentally). The
> script might already do this though.
>
> Oh, for some reason when using 'sftp', the script isn't doesn't stop
> when expected. E.g. coding error, sys.exit(1), ctrl-c. It only occurs
> after the 'sftp' connection is closed. No idea why this is and I can't
> figure out what paramiko (module implementing sftp) is doing to cause
> this.

Sweet!  You rock.