[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