Re: [MoM] Re: Help with Debian packaging of DCMTK++
Hi Andreas, Le 30/07/2015 18:34, Andreas Tille a écrit : On Thu, Jul 30, 2015 at 05:33:08PM +0200, Julien Lamy wrote: feels like the first version of the package is ready: is there anything else I should correct? Nothing. What would be the next steps? Waiting until the package will pass new queue since I uploaded right now. Congratulation for the successful MoM project My thanks to you and all debian-med for your help! Best regards, -- Julien signature.asc Description: OpenPGP digital signature
Re: [MoM] Re: Help with Debian packaging of DCMTK++
Hi Julien, On Thu, Jul 30, 2015 at 05:33:08PM +0200, Julien Lamy wrote: feels like the first version of the package is ready: is there anything else I should correct? Nothing. What would be the next steps? Waiting until the package will pass new queue since I uploaded right now. Congratulation for the successful MoM project Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150730163421.gv7...@an3as.eu
Re: [MoM] Re: Help with Debian packaging of DCMTK++
Hi, Le 23/07/2015 18:20, Andreas Tille a écrit : On Thu, Jul 23, 2015 at 05:59:10PM +0200, Julien Lamy wrote: I still have to generate a documentation package: I'll try to get this done early next week… Sounds like good progress. Just let us know about any problem. I added the documentation in a new package without too many difficulties. However, I wondered whether the documentation package should contain the library version or not (i.e. libdcmtkpp0-doc vs. libdcmtkpp-doc): unless I'm mistaken, both kinds of package exist. Is there any preference? Best, -- Julien signature.asc Description: OpenPGP digital signature
Re: [MoM] Re: Help with Debian packaging of DCMTK++
Hi Julien, On Fri, Jul 24, 2015 at 07:23:12PM +0200, Julien Lamy wrote: Sounds like good progress. Just let us know about any problem. I added the documentation in a new package without too many difficulties. However, I wondered whether the documentation package should contain the library version or not (i.e. libdcmtkpp0-doc vs. libdcmtkpp-doc): unless I'm mistaken, both kinds of package exist. Is there any preference? I think it is a matter of taste. My taste would say to drop the version number. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150724180059.gn26...@an3as.eu
Re: [MoM] Re: Help with Debian packaging of DCMTK++
Hi,
Le 22/07/2015 21:07, Andreas Tille a écrit :
Hi again,
On Mon, Jul 20, 2015 at 07:03:35PM +0200, Andreas Tille wrote:
I looked at d-shlibs, but I'm not sure what it is supposed to achieve :
it seems to me that all files are already in place and that they do not
need to be moved in the package. What am I missing?
D-shlibs moves the files for you and also respects multiarch and proper
file names. When using d-shlibs you can drop the debian/*.install
files.
I noticed that you decided to move to d-shlibs in Git. Seems to
be convincing. :-)
Yes it is! Although the package requires quite a few overrides, the
overall readability is improved.
The last thing you need to change in debian/control is:
$ git diff
diff --git a/debian/control b/debian/control
index aaa7533..93683c4 100644
--- a/debian/control
+++ b/debian/control
@@ -29,7 +29,7 @@ Description: Wrappers around DCMTK to have an easier API
Package: libdcmtkpp0-dev
Architecture: any
Section: libdevel
-Depends: libdcmtkpp0,
+Depends: libdcmtkpp0 (= ${binary:Version}),
${devlibs:Depends},
${misc:Depends}
Provides: libdcmtkpp-dev
Done.
See the lintian error for an explanation (I guess you were running
lintian, aren't you?)
Lintian has also an Information mode. You might like to check
lintian -i -I *.changes
I was indeed running Lintian, but on the .deb and not on the changes. Is
there any advantage of using *.changes instead of *.deb?
Lintian is now error and warning free, and, excluding the typo in the
binary file, the only information left is the no-symbols-control-file:
this one is a bit puzzling to me, is this something I should look into
more closely, or can I let it pass for now and come back to it in later
revisions?
I also submitted the ITP and updated the changelog: the problem I
mentioned earlier concerning reportbug was actually not an issue with my
SMTP configuration, but was related to bugs 789047 and 72226. Should any
one else get bitten by this one before the fix reaches unstable, pulling
the patch from Github [1] works.
I still have to generate a documentation package: I'll try to get this
done early next week…
[1] https://github.com/venthur/python-debianbts/pull/5
Best regards,
--
Julien
signature.asc
Description: OpenPGP digital signature
Re: [MoM] Re: Help with Debian packaging of DCMTK++
Hi Julien,
On Thu, Jul 23, 2015 at 05:59:10PM +0200, Julien Lamy wrote:
I noticed that you decided to move to d-shlibs in Git. Seems to
be convincing. :-)
Yes it is! Although the package requires quite a few overrides, the
overall readability is improved.
Hmmm, seems I should have a look onto d-shlibs whether these could be
included. I did some team uploads with such overrides in the past.
-Depends: libdcmtkpp0,
+Depends: libdcmtkpp0 (= ${binary:Version}),
Done.
Good.
See the lintian error for an explanation (I guess you were running
lintian, aren't you?)
Lintian has also an Information mode. You might like to check
lintian -i -I *.changes
I was indeed running Lintian, but on the .deb and not on the changes. Is
there any advantage of using *.changes instead of *.deb?
Lintian is running on all files mentioned in the changes file - so this
is the simplest way to check everything.
Lintian is now error and warning free, and, excluding the typo in the
binary file, the only information left is the no-symbols-control-file:
this one is a bit puzzling to me, is this something I should look into
more closely, or can I let it pass for now and come back to it in later
revisions?
I personally ignore this in all my library packages. Lintian provides
some link but you always need manual work for each new version and the
gain for such unfrequently used packages is very low. So I'd recommend
to ignore this.
I also submitted the ITP and updated the changelog: the problem I
mentioned earlier concerning reportbug was actually not an issue with my
SMTP configuration, but was related to bugs 789047 and 72226. Should any
one else get bitten by this one before the fix reaches unstable, pulling
the patch from Github [1] works.
Ahhh, thanks for the research on this.
I still have to generate a documentation package: I'll try to get this
done early next week…
Sounds like good progress. Just let us know about any problem.
Kind regards
Andreas.
--
http://fam-tille.de
--
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150723162047.gz11...@an3as.eu
Re: [MoM] Re: Help with Debian packaging of DCMTK++
Hi again,
On Mon, Jul 20, 2015 at 07:03:35PM +0200, Andreas Tille wrote:
I looked at d-shlibs, but I'm not sure what it is supposed to achieve :
it seems to me that all files are already in place and that they do not
need to be moved in the package. What am I missing?
D-shlibs moves the files for you and also respects multiarch and proper
file names. When using d-shlibs you can drop the debian/*.install
files.
I noticed that you decided to move to d-shlibs in Git. Seems to
be convincing. :-)
The last thing you need to change in debian/control is:
$ git diff
diff --git a/debian/control b/debian/control
index aaa7533..93683c4 100644
--- a/debian/control
+++ b/debian/control
@@ -29,7 +29,7 @@ Description: Wrappers around DCMTK to have an easier API
Package: libdcmtkpp0-dev
Architecture: any
Section: libdevel
-Depends: libdcmtkpp0,
+Depends: libdcmtkpp0 (= ${binary:Version}),
${devlibs:Depends},
${misc:Depends}
Provides: libdcmtkpp-dev
See the lintian error for an explanation (I guess you were running
lintian, aren't you?)
Lintian has also an Information mode. You might like to check
lintian -i -I *.changes
This tells you that the extended dscrtiption is to short. Since
you are upstream you might be easily able to make the description
more verbose.
Kind regards
Andreas.
--
http://fam-tille.de
--
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150722190751.go9...@an3as.eu
Re: [MoM] Re: Help with Debian packaging of DCMTK++
Hi, Le 17/07/2015 20:02, Andreas Tille a écrit : Good. I have two points to mention. You used some versioned dependencies and these are not all needed since the versions in question are provided anyway at minimum. The easiest way to find this out is to use cme fix dpkg-control (see policy what packages are needed to make this work). Beside some formatting changes you see where the versions are dropped. I'd recommend to use the result of this process. Done: dropping the version has the additional benefit to yield an easier to read file :) Moreover you will have seen a lintian warning about the maintainer. In debian/changelog you need to specify one of the maintainers (instead of DMPT) mentioned as Uploaders, so actually yours. BTW, I do not really mind whether I'm listed as Uploader or not - feel free to drop my name there until I might have done some mentionable work on the package. Done. I think you can also drop the postinst file. Ldconfig is automatically injected by debhelper - so there is no need to care about this. Done; I'm not sure why Lintian complained about this, but today's modifications fixed this. I still have to get rid of the ITP-related warning, but reportbug yields an Internal server error; will try again tomorrow… Finally I's like to stress that I made very good experiences by using d-shlibs to package libraries. We have several examples for its usage in Git - as a random pick have a look into git://anonscm.debian.org/debian-med/libmems.git I looked at d-shlibs, but I'm not sure what it is supposed to achieve : it seems to me that all files are already in place and that they do not need to be moved in the package. What am I missing? Best, -- Julien signature.asc Description: OpenPGP digital signature
Re: [MoM] Re: Help with Debian packaging of DCMTK++
Hi Julien, On Mon, Jul 20, 2015 at 06:11:23PM +0200, Julien Lamy wrote: (see policy what packages are needed to make this work). Beside some formatting changes you see where the versions are dropped. I'd recommend to use the result of this process. Done: dropping the version has the additional benefit to yield an easier to read file :) Yes, that's a welcome side effect. Moreover you will have seen a lintian warning about the maintainer. In debian/changelog you need to specify one of the maintainers (instead of DMPT) mentioned as Uploaders, so actually yours. BTW, I do not really mind whether I'm listed as Uploader or not - feel free to drop my name there until I might have done some mentionable work on the package. Done. OK. I think you can also drop the postinst file. Ldconfig is automatically injected by debhelper - so there is no need to care about this. Done; I'm not sure why Lintian complained about this, but today's modifications fixed this. Lintian usually complains since debhelper is clever enough to do things properly without manually specifying ldconfig. I still have to get rid of the ITP-related warning, but reportbug yields an Internal server error; will try again tomorrow… Is this when creating the bug report or rather in the final step. A common issue is that SMTP is not configured properly and reportbug wants to send an e-mail. So you might like to check some simple: mailx -s Test y...@e.mail /dev/null to verify this. If this is the case and you can not get it working properly you can simply save the mail that reportbug wanted to create and send it with any mail client to cont...@bugs.debian.org. Finally I's like to stress that I made very good experiences by using d-shlibs to package libraries. We have several examples for its usage in Git - as a random pick have a look into git://anonscm.debian.org/debian-med/libmems.git I looked at d-shlibs, but I'm not sure what it is supposed to achieve : it seems to me that all files are already in place and that they do not need to be moved in the package. What am I missing? D-shlibs moves the files for you and also respects multiarch and proper file names. When using d-shlibs you can drop the debian/*.install files. BTW, I've found a remaining issue when usin pbuilder (actually cowbuilder): ... /usr/bin/ld: cannot find -lz collect2: error: ld returned 1 exit status ... This is a typical sign that there is a missing Build-Dependency (in this case zlib1g-dev). Please make sure that you at least once test the build in a chroot to verify this. I'd recommend to setup cowbuilder. Things should be described properly in Debian Med policy. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150720170335.gg17...@an3as.eu
Re: [MoM] Re: Help with Debian packaging of DCMTK++
Le 16/07/2015 20:39, Andreas Tille a écrit : That's OK now. I guess your next commits will be a debian/ dir. Feel free to commit your latest stuff you just did and improve from there. I just pushed the first version of the debian dir, which raised a question regarding unit tests: should I assume that the tests have been run upstream or should I run them during the build? Right now, I've gone the easy way and skipped them: they run relatively quickly but require a specific environment (environment variables, running processes and whatnot, a script is provided to set up all of this). Next week, I'll try to integrate the code documentation and to fix the shlib-related Lintian warnings. Best, -- Julien signature.asc Description: OpenPGP digital signature
Re: [MoM] Re: Help with Debian packaging of DCMTK++
On 17/07/15 17:33, Julien Lamy wrote: Le 16/07/2015 20:39, Andreas Tille a écrit : That's OK now. I guess your next commits will be a debian/ dir. Feel free to commit your latest stuff you just did and improve from there. I just pushed the first version of the debian dir, which raised a question regarding unit tests: should I assume that the tests have been run upstream or should I run them during the build? Right now, I've gone the easy way and skipped them: they run relatively quickly but require a specific environment (environment variables, running processes and whatnot, a script is provided to set up all of this). Next week, I'll try to integrate the code documentation and to fix the shlib-related Lintian warnings. Best, The test suite should be run during the package build process. Since you said that a specific setup is required, you may want to use an override (override_dh_auto_test) to achieve the necessary setup / teardown for the test suite to run successfully. It should look like this in your d/rules: override_dh_auto_test: # set your envvars up here ENVVAR1 = ... ENVVAR2 = ... # call the test suite dh_auto_test # optional teardown, if stuff needs to be cleared... rm ... Bon courage, Ghislain -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55a9379b.8020...@gmail.com
Re: [MoM] Re: Help with Debian packaging of DCMTK++
On Fri, Jul 17, 2015 at 06:33:04PM +0200, Julien Lamy wrote: Le 16/07/2015 20:39, Andreas Tille a écrit : That's OK now. I guess your next commits will be a debian/ dir. Feel free to commit your latest stuff you just did and improve from there. I just pushed the first version of the debian dir, which raised a question regarding unit tests: should I assume that the tests have been run upstream or should I run them during the build? My opinion is that you should always run them. Upstream will test usually one specific environment but Debian builds on many architectures. Good unit tests can fail a build before a buggy version gets out there. -Steve signature.asc Description: Digital signature
Re: [MoM] Re: Help with Debian packaging of DCMTK++
Hi, On Fri, Jul 17, 2015 at 06:33:04PM +0200, Julien Lamy wrote: I just pushed the first version of the debian dir, Good. I have two points to mention. You used some versioned dependencies and these are not all needed since the versions in question are provided anyway at minimum. The easiest way to find this out is to use cme fix dpkg-control (see policy what packages are needed to make this work). Beside some formatting changes you see where the versions are dropped. I'd recommend to use the result of this process. Moreover you will have seen a lintian warning about the maintainer. In debian/changelog you need to specify one of the maintainers (instead of DMPT) mentioned as Uploaders, so actually yours. BTW, I do not really mind whether I'm listed as Uploader or not - feel free to drop my name there until I might have done some mentionable work on the package. The debian/copyright file seems to be OK. Usually we use an extra paragraph for Files: debian/* since in most cases the upstream developer has not created the debian/ dir. In your case it is fine I'm mentioning it anyway for completeness. which raised a question regarding unit tests: should I assume that the tests have been run upstream or should I run them during the build? Right now, I've gone the easy way and skipped them: they run relatively quickly but require a specific environment (environment variables, running processes and whatnot, a script is provided to set up all of this). Nothing to be added to the other team members. :-) Next week, I'll try to integrate the code documentation and to fix the shlib-related Lintian warnings. I think you can also drop the postinst file. Ldconfig is automatically injected by debhelper - so there is no need to care about this. Finally I's like to stress that I made very good experiences by using d-shlibs to package libraries. We have several examples for its usage in Git - as a random pick have a look into git://anonscm.debian.org/debian-med/libmems.git The usage of d-shlibs makes it quite easy to follow the library packaging guide and thus I'd strongly recommend it. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150717180254.go13...@an3as.eu
Re: [MoM] Re: Help with Debian packaging of DCMTK++
Hi Julien, On Thu, Jul 16, 2015 at 12:20:31PM +0200, Julien Lamy wrote: My SSH access is up and running. If I understand correctly, my next steps should be: 1. Submit the Intent to package That#s the officialy suggested first step. I have developed the habit to do it a bit later if I can be sure that I will not face any problems when packaging to make sure I will be really able to close the IRC bug. Feel free to do it as first step but please add the Debian Med mailing list in CC once reportbug --no-query-bts wnpp (which is what I'm using) asks you for other mail addresses. 2. Create a git repository on Alioth, push the upstream repo to the upstream branch To be clear here: Usually we use gbp import-orig --pristine-tar source_tarball If you mean this with push the upstream repo then yes. There are workflows where you can use a clone from upstream Git but this is way less tested and not documented in our team. Thus it would mean asking for trouble which might nto be the best idea for the beginning. 3. Prepare my package in the master branch Yes. 4. Notify the list when the package seems ready In the best case yes - feel free to ask in between in case of any trouble. Am I correct, or just going too fast? No, perfect. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150716104548.ga2...@an3as.eu
Re: [MoM] Re: Help with Debian packaging of DCMTK++
Hi Julien, welcome from me as well. To be clear here: Usually we use gbp import-orig --pristine-tar source_tarball Regarding this step: I've seen that your source tree does include the /debian subdirectory. It is usually better not to include it in the tarball, or name it differently, e.g. debian-example [1]. [1] https://wiki.debian.org/UpstreamGuide#Pristine_Upstream_Source best, Gert -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1437050232.7828.3.ca...@gmail.com
Re: [MoM] Re: Help with Debian packaging of DCMTK++
Hi Gert, Le 16/07/2015 14:37, Gert Wollny a écrit : Hi Julien, welcome from me as well. Thanks! To be clear here: Usually we use gbp import-orig --pristine-tar source_tarball Regarding this step: I've seen that your source tree does include the /debian subdirectory. It is usually better not to include it in the tarball, or name it differently, e.g. debian-example [1]. We added a debian [2] branch to our upstream repository in order to experiment with packaging: for the Alioth repository, I imported an archive from the master branch [3] which doesn't include the /debian directory. Since we do not plan to merge those branches in the upstream repository, it seems to me that this should not cause any problem when creating tarballs, even for future releases: am I right? [1] https://wiki.debian.org/UpstreamGuide#Pristine_Upstream_Source [2] https://github.com/lamyj/dcmtkpp/tree/debian [3] https://github.com/lamyj/dcmtkpp/tree/master Best, -- Julien signature.asc Description: OpenPGP digital signature
Re: [MoM] Re: Help with Debian packaging of DCMTK++
Hi Julien, We added a debian [2] branch to our upstream repository in order to experiment with packaging: for the Alioth repository, I imported an archive from the master branch [3] which doesn't include the /debian directory. Since we do not plan to merge those branches in the upstream repository, it seems to me that this should not cause any problem when creating tarballs, even for future releases: am I right? Great, the important thing is that the tarball doesn't include it. Best, Gert PS: Always stick to the list ;) -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1437063384.7828.6.ca...@gmail.com
