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
signature.asc
Description: Digital signature
_______________________________________________ devscripts-devel mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/devscripts-devel
