[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 20:49:21 UTC 2017

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.

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/
> 71c95c8e5f3bba1845444a246d04646825e6bab3
> > .
> >   * 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/e073cffb/attachment-0001.html>