[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#665354: RFS: viennacl/1.3.0+dfsg-1 (for experimental)



On 08/04/2012 09:08 AM, Bart Martens wrote:
> Hi Michael,
> 
> About your package at mentors uploaded there on 2012-08-03 08:00.  You wrote
> this in debian/copyright :
> 
>   |  Source: http://sourceforge.net/projects/viennacl/files/
>   |   The repacked source as used in the upload of this package was obtained by
>   |   using git-import-orig(1) as follows:
>   |     $ git import-orig --uscan --filter-pristine-tar \
>   |         --filter="*/TU_Signet_CMYK.eps"
>   |   .
>   |   To obtain the exact same file, use the following:
>   |     $ git clone git://git.debian.org/debian-science/packages/viennacl.git
>   |     $ cd viennacl
>   |     $ git branch -t pristine-tar origin/pristine-tar
>   |     $ pristine-tar export ../viennacl_1.3.0+dfsg.orig.tar.gz
>   |   .
>   |   The equivalent repackaged source without using git and pristine-tar can be
>   |   created by following these steps:
>   |     $ wget http://sourceforge.net/projects/viennacl/files/1.3.x/ViennaCL-1.3.0-src.tar.gz
>   |     $ gunzip ViennaCL-1.3.0-src.tar.gz
>   |     $ tar --delete -f ViennaCL-1.3.0-src.tar ViennaCL-1.3.0-src/doc/manual/figures/TU_Signet_CMYK.eps
>   |     $ mv ViennaCL-1.3.0-src.tar viennacl_1.3.0+dfsg.orig.tar
>   |     $ gzip -9 viennacl_1.3.0+dfsg.orig.tar
> 
> You write "using git-import-orig(1)" but then you write "$ git import-orig",
> not "$ git-import-orig".

Apparently you don't know squat about git. git-import-orig(1) names the
man-page, and the program is also called git-import-orig. But when using
git(1) the way I show, it will search some private directories and the
PATH for git-import-orig. This way it is possible to easily add helpers
and new utilities to git without recompiling it and still retain a
uniform syntax.

> 
> The part about git.debian.org doesn't belong here because that is about getting
> the already repackaged upstream source code, not about retrieving the upstream
> source code from upstream and reproducing the repackaging.

It shows how to get the bit-wise identical DFSG-clean tar-ball.

> 
> The last part doesn't include renaming the top directory as documented here:
> http://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html#bpp-origtargz
> "A repackaged .orig.tar.{gz,bz2,xz} should use
> packagename-upstream-version.orig as the name of the top-level directory in its
> tarball."

That's a best-practice recommendation and not mandated by the policy.
git-import-orig doesn't do it, and since that's the program I used to
create the DFSG-clean tar-ball, I chose to give instructions that are
the *equivalent* of what it does. If you still think that this is wrong,
feel free to file a bug against the git-buildpackage package.

> 
> Regards,
> 
> Bart Martens
> 

I feel that this review process is degrading into nit-picking and I just
don't have the time and patience to engage in word-fencing over such a
small thing as the instructions on how to remove a *single* file from a
tar-ball!

If you can't find more substantial points to criticize, I ask you to
either sponsor me and upload the package to experimental, fix it
yourself, or let somebody else do it. Should this charade continue, I'll
have to orphan the package, simple as that.

Michael


Reply to: