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

[Andreas Tille]

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