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 <kulv...@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 >
