Bug#804239: [uscan] Failure when basename is in query string

[Robie Basak]

Package: devscripts
Version: 2.15.8

If the download URL is a query string, such as
http://www.example.com/download?file=package-version.tar.gz, then uscan
ends up downloading the file as package-version.download which
subsequently causes mk-origtargz to fail with something like:

Parameter ../package-version.download does not look like a tar archive or a zip file. at /usr/bin/mk-origtargz line 330.

As far as I can tell, this makes uscan unusable for me for mysql-5.6.
More specifics for my case:

http://dev.mysql.com/downloads/mysql/5.6.html?os=src lists opaque link
URLs for the actual upstream tarballs (eg.
http://dev.mysql.com/downloads/file/?id=459308) but does have links with
versions embedded for the gpg files (eg.
http://dev.mysql.com/downloads/gpg/?file=mysql-5.6.27.tar.gz) and I know
how to construct a link for a corresponding release tarball (eg.
http://dev.mysql.com/get/Downloads/MySQL-5.6/mysql-5.6.27.tar.gz).

So it appeared to me that I could coax uscan into working with this
scheme and came up with the following:

opts=downloadurlmangle=s/\/downloads\/gpg\/?\?file=(mysql-([\d\.]*).tar.gz)/\/get\/Downloads\/MySQL-5.6\/$1/,pgpsigurlmangle=s/\/get\/Downloads\/MySQL-5.6\/(mysql-([\d\.]*).tar.gz)/\/downloads\/gpg\/?file=$1/ \
http://dev.mysql.com/downloads/mysql/5.6.html?os=src /downloads/gpg/\?file=mysql-([\d\.]*).tar.gz

This works to find the available versions and does download and gpg verify
the release tarball correctly. However it then fails with:

Parameter ../mysql-5.6-5.6.27.download does not look like a tar archive or a zip file. at /usr/bin/mk-origtargz line 330.
uscan: error: mk-origtargz --package mysql-5.6 --version 5.6.27 --compression gzip --directory .. --copyright-file debian/copyright ../mysql-5.6-5.6.27.download gave error exit status 255

AFAICT the cause is the following snippet in uscan:

    # Remove HTTP header trash
    if ($site =~ m%^https?://%) {
        $newfile_base =~ s/\?.*$//;
        # just in case this leaves us with nothing
        if ($newfile_base eq '') {
            $newfile_base = "$pkg-$newversion.download";
        }
    }

It seems to me that the "just in case" handling will always cause a
future failure because mk-origtargz will always reject this name. I
haven't tested this but if instead of .download it used .tar.gz then it
would work in my case.

I haven't found any way of working around this but suggestions
appreciated. In the meantime I'm filing this bug because:

1) the "just in case" code will always cause a future failure (though I
appreciate it causes creation using a sensible filename and it is
protecting me in a way that does work)

2) there does not appear to be a way for me to write a watch file that
will work in my case because of this issue. I did try filenamemangle but
I don't have any way to reference the version number in there which is
already lost in $newfile_base, so I cannot recover it.

Thanks,

Robie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/devscripts-devel/attachments/20151106/655e08a4/attachment.sig>