Re: Problem with uscan --repack
On Wed, 25 May 2011 06:48:56 +0200, Daniele Tricoli wrote:
I'm taking care of python-peak.util (under the umbrella of DPMT) and
close #606382 I have to obtain a new orig tarball. python-peak.util
multi-upstream source package but obtain a new orig tarball in not a
difficult task because Stefano Zacchiroli made a get-orig-source
inside debian/rules and you have only to invoke it.
get-orig-source target uses uscan and I'm having problems with it. On
development box with Debian Wheezy (devscripts 2.10.73) I get:
$ uscan --watchfile debian/peak.util-addons.watch --repack \
--upstream-version 0 --package peak.util-addons --download \
--destdir get-orig-source.tmp/ --verbose
-- In debian/peak.util-addons.watch, processing watchfile line:
-- Found the following matching hrefs:
Newest version on remote site is 0.7, local version is 0
=> Newer version available from
-- Downloading updated package AddOns-0.7.zip
-- Repacking from zip to .tar.gz
tar (child): get-orig-source.tmp/AddOns-0.7.tar.gz: Cannot open: No
file or directory
tar (child): Error is not recoverable: exiting now
Repacking from zip to tar.gz failed (could not create tarball)
This is a regression introduced by devscripts 2.10.72. I supplied a fix
for some other issues (see #615108), and it appears to have been
incomplete as the --destdir option no longer works with relative paths.
I'll report a bug against devscripts with a patch tonight.
On Lenny (I don't have a Squeeze box at the moment) the command above
works... man uscan did not help so looking at the source code (I
Perl) What am I missing?
I noticed that using --destdir /tmp/ works but is not what I need.
You can temporarily work around this by using an absolute one, eg: