[Debian-med-packaging] Bug#854837: closed by Andreas Tille <tille at debian.org> (Bug#854837: fixed in dicompyler 0.4.2-4)

Mon Sep 18 21:08:14 UTC 2017

2017-09-18 22:49 GMT+02:00 Vojtech Kulvait <kulvait at gmail.com>:

> HI all,
> Andreas is correct that I was reverting changes in previous patches
> including mine, the reason was that initially I did not have fully patched
> tree. Now I am working on series of patches that will be clearer. Just let
> me to do this in a few days. I also agree to go through stretch-backports
> even if I consider this very conservative policy when current package in
> stretch is nonfunctional.
>
> One thing which I come through when making dicompyler work is that it
> uses wxmpl.py file that is outdated. I think It would by wise to substitute
> it by the new release of that file from https://github.com/NOAA-
> ORR-ERD/wxmpl
> What bothers me is the license. This file is released under MIT license,
> which should be OK. However even if the old file state
> # See the file "LICENSE" for information on usage and redistribution
> # of this file, and for a DISCLAIMER OF ALL WARRANTIES.
> the LICENSE file is not part of the dicompyler sources. So the question is
> how to give credit to wxmpl upstream developer. In this case I am into
> changing source tree and adding at least the https://github.com/NOAA-
> ORR-ERD/wxmpl/blob/master/LICENSE.txt file there.
>
The license file is present and state usage of that part of software.
Therefore everything is OK.

>
> Best,
> Vojtech.
>
> Hi Vojtech,
>> [please keep the bug in CC to make our discussion public.  There is no
>>  point in discussing this privately.]
>>
>> On Mon, Sep 18, 2017 at 03:41:06PM +0200, Vojtech Kulvait wrote:
>> > I have successfully checked out the source from git as kulvait-guest. I
>> > have also created my gpg keys, I am sending you my public key.
>>
>> Fine. There is no need to send me the public key.  Just push it to the
>> PGP mirrors and try to get some signatures from people you are meeting
>> face to face.
>>
>> > Build system really produces the directory egginfo.
>>
>> Yes, it is produced.  But there is no harm done since pybuild is removing
>> it again inside the build process.
>>
>> > I don't know how to get
>> > rid of this in the resulting package. However to spare git repository,
>> it
>> > is wise to create build directory outside source directory and call
>> bulding
>> > routines using
>> > gbp buildpackage --git-export-dir=../dicompyler_builddir
>> > Using that git directory will not be affected. I think previously
>> someone
>> > called gbp buildpackage and then committed changes due to build to the
>> git
>> > repository.
>>
>> Probably not - it was part of the upstream branch in Git.  Anyway, I
>> think we have settled with this issue now since it is not there any
>> more.
>>
>> > Thank you very much for the patch you sent into git. There were however
>> two
>> > additional things to fix. First it was wrong indentation
>>
>> Hmmm, according the wrong identantion this was introduced in your own
>> previous patch.  I've fixed it there in another commit.  However, are
>> you really sure you want to revert the previosly introduced matplotlib
>> compatibility conditionals?  What is wrong in
>>
>>      if matplotlib.__version__ > '1.2':
>>          grid = mpl_Path(contour).contains_points(dosegridpoints)
>>      else:
>>          grid = nx.points_inside_poly(dosegridpoints, contour)
>
>
>> which was introduced in patch enable_later_versions_of_matplotlib.patch
>> and reverted by you later?  Probably we should rather fix it in the
>> initial patch and not do patch reversals later.  This will lead to
>> confusion.
>
>
>> > and second it was
>> > incompatibility with pillow >= 3.0.0. I fixed this and added the new
>> patch
>> > (01.patch). Now it is possible to explore RT data. With the new patch,
>> the
>> > package is finally functional and I suggest propagating current change
>> into
>> > stretch.
>>
>> We can not simply move this to stretch since this is now released.  We
>> can upload to unstable for now and once it is error free there we can
>> upload to stretch-backports.
>>
>> > I have not made changes to changelog since I don't know how. If I
>> increase
>> > release number and add the following to changelog
>> > dicompyler (0.4.2.0-2) UNRELEASED; urgency=high
>> >
>> >   * Works with pillow >=3.0.0 addressing changes due to commit
>> > https://github.com/python-pillow/Pillow/commit/71c95c8e5f3bb
>> a1845444a246d04646825e6bab3
>> > .
>> >   * Indentation fix
>> >
>> >  -- Vojtěch Kulvait <kulvait at gmail.com>  Mon, Sep 18 15:21:26 CEST 2017
>> > It complains that
>> > W: dicompyler source: changelog-should-mention-nmu
>> > W: dicompyler source: source-nmu-has-incorrect-version-number 0.4.2.0-2
>>
>> That's because you are not yet mentioned in debian/control as Uploader.
>> Feel free to add yourself there!
>> Alternatively add a line
>>
>>   * Team upload
>>
>> to silence lintian.
>>
>> > W: dicompyler source: newer-standards-version 4.1.0 (current is 3.9.8)
>>
>> Feel free to ignore this (or better use lintian from unstable).
>>
>> > W: dicompyler: syntax-error-in-debian-changelog line 6 "badly formatted
>> > trailer line"
>> > W: dicompyler: syntax-error-in-debian-changelog line 9 "found start of
>> > entry where expected more change data or trailer"
>> > W: dicompyler: debian-changelog-line-too-long line 3
>>
>> That's due to your indentation mistake.  There is no need to
>> put the full URL there if it is just inside the patch.
>>
>> > gpg: /tmp/debsign.I7Bhm81m/dicompyler_0.4.2.0-2.dsc: clear-sign
>> failed: No
>> > secret key
>> >
>> > I am probably not allowed to increase even minor release num?
>>
>> No, you are - but it would be wrong anyway since 0.4.2.0-1 is UNRELEASED
>> yet - so please just leave the -1 and add your changes there.  (It even
>> has the suggested "Team upload" line!)  Simply use
>>
>>    dch
>>
>> to add your changes.
>>
>> > I suggest
>> > increasing urgency to high or even emergency to really stress that this
>> > version is functional.
>>
>> Per policy there is no reason to bump urgency.  This is a normal upload
>> to unstable.  As I explain we can NOT upload to stretch.  The only
>> chance to upload to stretch is if there are *security* relevant bugs.
>> So we need to go via stretch backports.
>>
>> > I think however one thing is left to do which is to allow visualization
>> of
>> > the structures drawn to RT data, I will try to work on that.
>>
>> Fine.  What about becoming upstream and create a new release?
>>
>> > Another task I can eventually look at is to explore upstream branch by
>> the
>> > dicompyler author
>> > https://github.com/bastula/dicompyler/tree/dependencyupdate however if
>> he
>> > claim that it was not tested on linux or with python3 it will probably
>> not
>> > be as important.
>> >
>> > As you suggested I can fork dicompyler on github and make the changes
>> > (probably including other debian patches if reasonable) public and
>> > eventually make pull request to upstream author. But first lets package
>> > functional debian package :)
>>
>> I'm fine with this.  As I said above please reconsider the matplotlib
>> change and afterwards I can upload as is while you can take your time
>> for other changes later.
>>
>> Kind regards
>>
>>       Andreas.
>>
>> --
>> http://fam-tille.de
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/debian-med-packaging/attachments/20170918/b94e36e8/attachment-0001.html>