Bug#775526: /usr/bin/uscan: passing --compression=xz ignored
Vagrant Cascadian
vagrant at debian.org
Fri Jan 16 22:14:56 UTC 2015
On 2015-01-16, David Prévot wrote:
> On Fri, Jan 16, 2015 at 11:19:18AM -0800, Vagrant Cascadian wrote:
>> I've tried passing the --compression=xz option to uscan, but it
>> doesn't appear to pass that on to mk-origtgz.
> […]
>> Running uscan:
>>
>> uscan --compression=xz
> […]
>> Successfully repacked ../u-boot-2015.01.tar.bz2 as ../u-boot_2015.01+dfsg1.orig.tar.bz2, deleting 17 files from it.
>
>> It simply repacks the tarball as bz2 file.
>
> Actually, it simply strips away the files from the existing tarball, and
> renames it(s copy) to match the usual expectations.
Ah, so "Sucessfully repacked" is misleading me to think it's using
--repack. :)
> You need to explicitly use the --repack switch if you want a repack
> (unless the original is not a friendly format, e.g., ZIP):
>
> uscan --repack --compression=xz
Yup, that works. Thanks!
> Maybe the text in uscan(1) comes from an earlier implementation, and
> the text within parenthesis:
>
> --compression [ gzip | bzip2 | lzma | xz ]
> In the case where the upstream sources are
> repacked (either because --repack option is given
> or debian/copyright contains the field Files-
> Excluded) […]
>
> should be changed to something like:
>
> (either because it is a zip file or because
> of --repack)
>
> (and ditto in mk-origtargz(1)).
Sure, that would be an improvement.
It would be nice if mk-origtargz/uscan could error out with a message if
--compression is asked for but --repack isn't specified, or have
--compression imply --repack. Or is there a valid use of --compression
without --repack?
live well,
vagrant
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/devscripts-devel/attachments/20150116/b1bbefa5/attachment.sig>
More information about the devscripts-devel
mailing list