Comment 13 for bug 934096

Revision history for this message
Jelmer Vernooij (jelmer) wrote : Re: [Bug 934096] Re: merge-upstream does not repack zip archive

On Wed, Mar 14, 2012 at 01:47:24PM -0000, Maarten Bezemer wrote:
> This is my output
> $ uscan --dehs --force-download
> <dehs>
> <package>mc</package>
> <debian-uversion>4.8.1</debian-uversion>
> <debian-mangled-uversion>4.8.1</debian-mangled-uversion>
> <upstream-version>4.8.1</upstream-version>
> <upstream-url>http://www.midnight-commander.org/downloads/mc-4.8.1.tar.bz2</upstream-url>
> <status>up to date</status>
> </dehs>

> (the archive is downloaded by uscan)

> No <target> element available... For both the oneiric and precise
> versions of devscripts. Do you use some (conveniently) modified uscan
> version? :)
:-)

> Furthermore, I tried to update sambe4 (after getting 4.4.0~alpha17 or
> something similar) and uscan gave an error that the watch file was
> incorrect, using the --debug shows no downloaded contenet (page), using
> wget results in a download and a generated index.html of the ftp site.
This was with the Debian package, which is on alpha18. I don't recall
updating the watch file between alpha17 and 18, but perhaps I did.

> Something seems to be different between our uscan versions (or libraries
> that are used).

> I am all pro, using the <target> element, but this difference needs to
> be 'solved' to be sure that others also have the <target> element (maybe
> we need to add/update package dependencies when we know the difference?)
I'm running devscripts from precise, so I'm not entirely sure what's
going on here.

My suggestion would be to look at the uscan source code to see
why and if it spits out the target path it has downloaded a tarball
to. Of course, another good alternative is still to download into a
temporary directory and to use os.listdir(temp_dir) to find out what
the name of the downloaded tarball is. Not as nice as parsing the XML,
but also not the worst kludge ever :)

Cheers,

Jelmer