Hi Vojtech, thanks again for your contribution.
On Mon, Sep 18, 2017 at 12:27:42AM +0200, Vojtech Kulvait wrote: > Hi Andreas, > yes the bug is solved by the code I am sending when it is placed in > dicompyler/dicompyler directory (tested in stretch). > > I have access to the dicompyler git repository, however I do not understand > fully the patch policy of debian packages. > > I have built package using gbp buildpackage. That works and produce new > package when building using clean master git branch. > > The problem is that after single run gbp buildpackage, the contents > of dicompyler.egg-info/requires.txt and SOURCES.txt does change. I am > enclosing diff produced by dpkg-buildpackage > > --- dicompyler-0.4.2.orig/dicompyler.egg-info/SOURCES.txt > +++ dicompyler-0.4.2/dicompyler.egg-info/SOURCES.txt > @@ -2,6 +2,7 @@ MANIFEST.in > README.txt > dicompyler_app.py > distribute_setup.py > +setup.cfg > setup.py > dicompyler/__init__.py > dicompyler/credits.txt > --- dicompyler-0.4.2.orig/dicompyler.egg-info/requires.txt > +++ dicompyler-0.4.2/dicompyler.egg-info/requires.txt > @@ -1,4 +1,4 @@ > -matplotlib>=0.99, <=1.1.0 > +matplotlib>=0.99, <=2.0.0 > numpy>=1.2.1 > -pil>=1.1.7 > -pydicom>=0.9.5, <0.9.7 > \ No newline at end of file > +pillow>=2.5.1 > +pydicom>=0.9.5, <=0.9.9 > That results to an error > dpkg-source: error: aborting due to unexpected upstream changes, This egg-info stuff is a pure nuisance. You might observe this when using gbp without a pbuilder chroot. This leaves some stupid remainings that should not be there. (See Debian Med policy [1]) As far as I know the buildsystem pybuild is cleaning up egg-info completely but for some reason this does not reliably work (if you just remove the dir it should be OK with your method as well). > Well if I commit using dpkg-source --commit it creates a patch for that. > However I don't know what actually changed related files. > > The code I am sending is apparently working with unpatched files and > patches then fail to apply. > > As I have said I don't understand very well why the patches are maintained > separately of source code and how properly I can work on patched tree and > then create new patch. The usual way is to say: quilt push -a quilt new my_new_patch.patch quilt edit my_file_to_patch quilt refresh quilt pop -a git add debian/patches/my_new_patch.patch git commit -a > Am I right that in dicompyler directory there is vanilla upstream source of > dicompyler and I should not modify it in git and create patches instead? It > will probably take me some time. I did it on your behalf. After doing quilt push -a the dicompiler dir looks identical to your attached zip archive. Please verify that this is working for you. I also added a changelog entry on behalf of you. > Last question is about the directory dicompyler.egg-info. I don't > understand why it is there. If we will pretend that we are using upstream > version from the repository https://github.com/bastula/dicompyler/ then > there is no egg at all and I think we don't have to care about how the > package is packaged in python repositories. Grrrr, it seems the download tarball is (now???) different to what I imported once. I did a re-import and invented a version number 0.4.2.0. Now you should observe consistency between the Github download and the Debian packaging git. Your egg-info trouble should now have been gone. > I will be glad if you can address my questions. Please test and confirm that I can upload this (on behalf of yours since I used you as changelog owner for the Debian changes). I thing in the long run you should probably take over the Github project and release a new upstream version to enable all users of dicompyler profiting from your changes (not only Debian users). Kind regards Andreas. [1] https://debian-med.alioth.debian.org/docs/policy.html paragraph: "To make gbp buildpackage build the package with pdebuild." -- http://fam-tille.de