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

Andreas Tille andreas at fam-tille.de
Mon Sep 18 08:22:26 UTC 2017


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



More information about the Debian-med-packaging mailing list