[Debian-med-packaging] [med-svn] [kineticstools] 01/01: pristine-tar data for kineticstools_0.6.1+dfsg.orig.tar.xz

[Afif Elghraoui]

على الأحد 15 كانون الثاني 2017 ‫13:03، كتب Afif Elghraoui:
> Hi, Andreas,
> 
> على السبت 24 كانون الأول 2016 ‫11:41، كتب Andreas Tille:
>> Hi Afif,
>>
>> On Sat, Dec 24, 2016 at 07:48:27AM -0800, Afif Elghraoui wrote:
>>> I had already imported the 0.6.1 tarball in the repository in anticipation
>>> that someone might beat me to updating this package, especially since I
>>> hadn't made the get-orig-source script like I should have.
>>>
>>> Was there a problem with the version I had in Git?
>>
>> Probably the only problem was that I failed in reading the Git log
>> properly and just was looking at d/changelog which I usually bump the
>> version in connection with the import of a new upstream tarball.  It
>> might make sense if you verify the get-orig-source script and feel
>> free to kick one of the duplicated upstream source (since we have
>> gz and xz version now).
>>
> 
> There is a problem with the tarball you replaced mine with. It does not
> have the non-dfsg files removed (mk-origtargz should have been called on
> the tarball downloaded from github--now documented in README.source).
> 

Actually, it looks like upstream has removed those non-DFSG compliant
files over time. The pdf there now has its tex source and so we don't
need to repack anymore.

> It also does not actually reflect version 0.6.1 because it's a
> development snapshot from after that version was assigned. I tried
> re-importing the git HEAD under the version 0.6.1+20161222+dfsg, but
> this versioning scheme won't really work (0.6.1+dfsg >
> 0.6.1+20161222+dfsg), so I'm not really sure what to do right now short
> of rewinding the pristine-tar and upstream branches, and moving the
> upstream/0.6.1+dfsg tag to where it used to be before being deleted.
> 
>> The real problems I had are now in the changelog.  I had no better
>> reason for touching the bug than simply trying to find another target
>> for the advent calendar. ;-)
>>
> 
> Regarding not finding pybigwig to be a real dependency-- it is not
> declared as such, but the program will crash if it is not installed
> because there is some module that tries to import it.
> 

regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name