2017-09-18 22:49 GMT+02:00 Vojtech Kulvait <kulv...@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 <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 >> > >