Re: Packaging Ray for Debian Med
Hi Sébastien, On Sun, Nov 04, 2012 at 10:46:23AM -0500, Sébastien Boisvert wrote: The binary delta is between the original tarball and the collection of Git objects corresponding to its content. Oh I understand now. pristine-tar/x.y.z-R is something applied to upstream/x.y.z in order to produce package_x.y.z-R.orig.tar.bz2. Why not just pick the upstream tarball then ? Because you save on storage ? Yes. Even if this might not really matter for ray it is just part of a general workflow that is implemented in tools like git-buildpackage and there are a lot of packages where it makes definitely sense. So sticking to the very same workflow even if the gain in this specific case might be not that remarkable makes sense. Thanks ! I did pristine-tar commit ~/debian-med/ray_2.1.0.orig.tar.bz2 I don't need to put any tag for branch pristine-tar, right ? I tested the packaging using git-buildpackage and it worked for me - so it seems you got the result right. too. This is equivalent to having RayGit and RayPlatformGit and then adding debian/. I admit I do not understand this sentence - perhaps because the difference between RayGit and RayPlatformGit is not clear to me. However, the Debian Med team policy document[1] should explain how to handle pristine-tar. In that case, a pristine-tar binary delta would contain a full copy of RayPlatform. But what's the workflow when upstream RayPlatformGit changes too ? Do we pull it inside branch upstream ? I guess I will use pristine-tar commit ~/debian-med/ray_x.y.z.orig.tar.bz2 when we ship a new release ? As I said above I do not really understand this. If you issue a new source tarball (and I have no idea whether you do this for Ray and RayPlatform in a synchronised manner) you create a new Debian package from it. (No idea whether this answer might match the question.) But given the size (856 here), it may not be a problem if the number or releases is limited. So far, we ship around 3 to 6 releases per year. The bz2 tarball size is 330 KB. So size is not an issue. Definitely not in this case but as I said above sticking to a well known workflow seems to have an additional and way more important advantage. What you can also do is generate an orig.tar.gz tarball from the Git repository on Alioth, and then commit it in the pristine-tar branch. I did this (see above). Thanks for the pointer. Works as said above. :-) Once having created the packages I would like to mention that I'm not fully convinced that the split into ray-doc and ray-extra makes real sense in this specific case. I'm usually a fan of separate binary packages but in this specific case the sizes of both extra packages do not rectify this extra effort at all. Stripping of some txt files (ray-doc) and small scripts (in ray-extra) both ending up in binary packages 50kB is something I would not do personally. In the end it is a matter of taste but if you would decide to keep these packages they should be Architecture: all in any case. This said, there is no problem on Debian's side to package RayPlatform separately. In RayPlatform, there is a CMakeList.txt and it can build libRayPlatform.so. The Makefile of ray needs a patch though: --- a/Makefile +++ b/Makefile @@ -185,16 +185,16 @@ showOptions: @touch showOptions # how to make Ray -Ray: showOptions RayPlatform/libRayPlatform.a code/TheRayGenomeAssembler.a - $(MPICXX) $(LDFLAGS) code/TheRayGenomeAssembler.a RayPlatform/libRayPlatform.a -o $@ +Ray: showOptions RayPlatform/libRayPlatform.so code/TheRayGenomeAssembler.a + $(MPICXX) $(LDFLAGS) code/TheRayGenomeAssembler.a RayPlatform/libRayPlatform.so -o $@ @echo $(PREFIX) PREFIX @echo Ray TARGETS code/TheRayGenomeAssembler.a: @cd code; make MPICXX=$(MPICXX) CXXFLAGS=$(CXXFLAGS) -j $(J) all ; cd .. -RayPlatform/libRayPlatform.a: - @cd RayPlatform; make MPICXX=$(MPICXX) CXXFLAGS=$(CXXFLAGS) -j $(J) ; cd .. +RayPlatform/libRayPlatform.so: + @cd RayPlatform; cmake .; make MPICXX=$(MPICXX) CXXFLAGS=$(CXXFLAGS) -j $(J) ; cd .. clean: @rm -f Ray showOptions PREFIX TARGETS $ ldd Ray linux-vdso.so.1 = (0x7fff5a9ff000) libRayPlatform.so = /home/seb/git-clones/RayPlatform/libRayPlatform.so (0x7f1be1752000) libmpi_cxx.so.1 = /usr/lib64/openmpi/lib/libmpi_cxx.so.1 (0x7f1be1538000) libmpi.so.1 = /usr/lib64/openmpi/lib/libmpi.so.1 (0x0034d4e0) libdl.so.2 = /lib64/libdl.so.2 (0x003d5600) libstdc++.so.6 = /lib64/libstdc++.so.6 (0x003d5c40) libm.so.6 = /lib64/libm.so.6 (0x003d5580) libgcc_s.so.1 = /lib64/libgcc_s.so.1 (0x003d5880) libpthread.so.0 = /lib64/libpthread.so.0 (0x003d55c0) libc.so.6 = /lib64/libc.so.6 (0x003d5540) libnsl.so.1 = /lib64/libnsl.so.1 (0x003d69c0)
Re: Packaging Ray for Debian Med
Le Mon, Nov 05, 2012 at 09:13:44AM +0100, Andreas Tille a écrit : On Sun, Nov 04, 2012 at 10:46:23AM -0500, Sébastien Boisvert wrote: Is libgtextutils used by other packages as well ? I can not answer this question but please be aware that the answer to it is not always helpful to draw a final decision. My experience shows that people are requesting libraries and even development packages for those libraries even if they are not used at all by any package *inside* Debian. There might be a lot of use for people developing applications around this packaged software and they might profit from a library package. I have no idea whether this is the case for libgtextutils nor for RayPlatform. Hi all, No other package than fastx-toolkit depends on libgtextutils. But I do not know for other programs outside Debian. Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121105081858.gc12...@falafel.plessy.net
Re: Bowtie2 ready for upload?
On 11/04/2012 05:38 AM, Charles Plessy wrote: Le Fri, Nov 02, 2012 at 11:25:54PM -0400, Carlos Borroto a écrit : I uploaded latest upstream version for Bowtie2, which dropped the beta tag. The package seems ready, but I haven't worked in this package before. Alex, could you please take a look and see if things look good. Hi Carlos and Alex, Bowtie 2.0.2 looks good to me. I pushed two minor commits to remove obsoleted Lintian overrides and use pristine-tar by default. I recommend to upload directly to Unstable. In case a RC bug were found in 2.0.0-beta6-3, it would not make much sense spending time correcting this beta version anyway. Lastly, have you considered adding regression tests using the example data ? You can see http://dep.debian.net/deps/dep8/ for one framework available in Debian and Ubuntu. Have a nice Sunday, Hi, After all job is done it also looks good for me :). Just a few questions: I've uploaded 2.0.0-beta7-1 to unstable, but the notice of that has vanished from debian/changelog, I updated the changelog to reflect this change. Regarding the regression tests, I've tried to create one, but I couldn't see at which state the test is executed. The lintian complains: W: bowtie2 source: unknown-field-in-dsc testsuite could it be that lintian is not in sync so far ? or am I doing it wrong ? Thank you, Alex -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/509792b2.9070...@biotec.tu-dresden.de
Re: Bowtie2 ready for upload?
Le Mon, Nov 05, 2012 at 11:19:30AM +0100, Alex Mestiashvili a écrit : The lintian complains: W: bowtie2 source: unknown-field-in-dsc testsuite could it be that lintian is not in sync so far ? Definitely. Perhaps it deserves a bug report, or perhaps it will be solved by dpkg itself. By the way, there are related discussion on debian-devel and debian-qa. http://lists.debian.org/20121104180112.ga3...@upsilon.cc Cheers, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121105133754.ge11...@falafel.plessy.net
Re: Bowtie2 ready for upload?
On Mon, Nov 5, 2012 at 5:19 AM, Alex Mestiashvili a...@biotec.tu-dresden.de wrote: I've uploaded 2.0.0-beta7-1 to unstable, but the notice of that has vanished from debian/changelog, I updated the changelog to reflect this change. Odd, I replaced 2.0.0-beta7-1 with 2.0.2-1, cause it was marked as UNRELEASED. See commit: http://anonscm.debian.org/gitweb/?p=debian-med/bowtie2.git;a=commitdiff;h=c1ba6b64379ca8d55db8852e825904f7cf194110 And raw changelog before the commit: http://anonscm.debian.org/gitweb/?p=debian-med/bowtie2.git;a=blob_plain;f=debian/changelog;hb=b4d4b3dcd68198cb373e2b7ca79a74b8b6069138 However you are correct, 2.0.0-beta7-1 was already uploaded to unstable. I thought in order to upload, the changelog would have to be properly marked for the right Debian release. I also like merging unreleased version after updating to a new upstream version, as I don't see the point of keeping the changelog clutter with unreleased stuffs. Cheers, Carlos -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CABgGhB+bhSLop9Roa_MeT0cDcPn7GS5ynJnn_zpLC=pwfwe...@mail.gmail.com
Re: Tophat 2.0.6 is ready for upload
On Sun, Nov 4, 2012 at 8:36 PM, Charles Plessy ple...@debian.org wrote: Hi all, I just realised that tophat never made it into Wheezy befor the freeze. Therefore, 2.0.6 is perfectly suitable for Sid. I lost track of who is DM or not. Please let me know if you need somebody to upload (and apply to DM). Have a nice day, I'm not a DM, so I will need sponsoring for this package. Thanks, Carlos -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cabgghb+9xacenw3rrckm0by0ovv6wqmevj-mk8hgl_ioovc...@mail.gmail.com
Re: Bowtie2 ready for upload?
On 11/05/2012 04:01 PM, Carlos Borroto wrote: On Mon, Nov 5, 2012 at 5:19 AM, Alex Mestiashvili a...@biotec.tu-dresden.de wrote: I've uploaded 2.0.0-beta7-1 to unstable, but the notice of that has vanished from debian/changelog, I updated the changelog to reflect this change. Odd, I replaced 2.0.0-beta7-1 with 2.0.2-1, cause it was marked as UNRELEASED. See commit: http://anonscm.debian.org/gitweb/?p=debian-med/bowtie2.git;a=commitdiff;h=c1ba6b64379ca8d55db8852e825904f7cf194110 Yes, you are right. Probably I forgot to push the changes. And raw changelog before the commit: http://anonscm.debian.org/gitweb/?p=debian-med/bowtie2.git;a=blob_plain;f=debian/changelog;hb=b4d4b3dcd68198cb373e2b7ca79a74b8b6069138 However you are correct, 2.0.0-beta7-1 was already uploaded to unstable. I thought in order to upload, the changelog would have to be properly marked for the right Debian release. I also like merging unreleased version after updating to a new upstream version, as I don't see the point of keeping the changelog clutter with unreleased stuffs. Agree, it makes more sense. Cheers, Carlos Regards, Alex -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5097d8fa.3010...@biotec.tu-dresden.de
Re: Packaging Ray for Debian Med
Hi ! On 11/05/2012 03:13 AM, Andreas Tille wrote: Hi Sébastien, On Sun, Nov 04, 2012 at 10:46:23AM -0500, Sébastien Boisvert wrote: The binary delta is between the original tarball and the collection of Git objects corresponding to its content. Oh I understand now. pristine-tar/x.y.z-R is something applied to upstream/x.y.z in order to produce package_x.y.z-R.orig.tar.bz2. Why not just pick the upstream tarball then ? Because you save on storage ? Yes. Even if this might not really matter for ray it is just part of a general workflow that is implemented in tools like git-buildpackage and there are a lot of packages where it makes definitely sense. So sticking to the very same workflow even if the gain in this specific case might be not that remarkable makes sense. Thanks ! I did pristine-tar commit ~/debian-med/ray_2.1.0.orig.tar.bz2 I don't need to put any tag for branch pristine-tar, right ? I tested the packaging using git-buildpackage and it worked for me - so it seems you got the result right. I thank you for showing me how to do it. too. This is equivalent to having RayGit and RayPlatformGit and then adding debian/. I admit I do not understand this sentence - perhaps because the difference between RayGit and RayPlatformGit is not clear to me. However, the Debian Med team policy document[1] should explain how to handle pristine-tar. In that case, a pristine-tar binary delta would contain a full copy of RayPlatform. But what's the workflow when upstream RayPlatformGit changes too ? Do we pull it inside branch upstream ? I guess I will use pristine-tar commit ~/debian-med/ray_x.y.z.orig.tar.bz2 when we ship a new release ? As I said above I do not really understand this. If you issue a new source tarball (and I have no idea whether you do this for Ray and RayPlatform in a synchronised manner) you create a new Debian package from it. (No idea whether this answer might match the question.) But given the size (856 here), it may not be a problem if the number or releases is limited. So far, we ship around 3 to 6 releases per year. The bz2 tarball size is 330 KB. So size is not an issue. Definitely not in this case but as I said above sticking to a well known workflow seems to have an additional and way more important advantage. What you can also do is generate an orig.tar.gz tarball from the Git repository on Alioth, and then commit it in the pristine-tar branch. I did this (see above). Thanks for the pointer. Works as said above. :-) Once having created the packages I would like to mention that I'm not fully convinced that the split into ray-doc and ray-extra makes real sense in this specific case. I'm usually a fan of separate binary packages but in this specific case the sizes of both extra packages do not rectify this extra effort at all. Stripping of some txt files (ray-doc) and small scripts (in ray-extra) both ending up in binary packages 50kB is something I would not do personally. I want the ray-extra because ray contains the executable Ray whereas ray-extra has some R and python scripts which are not used in most Ray workflows. Thus, I don't want the ray package to require (or suggest) r-base-core or python. ray-doc contains documentation not required to operate Ray. The man page alone is sufficient. In the end it is a matter of taste but if you would decide to keep these packages they should be Architecture: all in any case. Fixed. http://anonscm.debian.org/gitweb/?p=debian-med/ray.git;a=commitdiff;h=446f11f7b4522f7c4664e5ac8eb0e4c9d87f55a3 This said, there is no problem on Debian's side to package RayPlatform separately. In RayPlatform, there is a CMakeList.txt and it can build libRayPlatform.so. The Makefile of ray needs a patch though: --- a/Makefile +++ b/Makefile @@ -185,16 +185,16 @@ showOptions: @touch showOptions # how to make Ray -Ray: showOptions RayPlatform/libRayPlatform.a code/TheRayGenomeAssembler.a - $(MPICXX) $(LDFLAGS) code/TheRayGenomeAssembler.a RayPlatform/libRayPlatform.a -o $@ +Ray: showOptions RayPlatform/libRayPlatform.so code/TheRayGenomeAssembler.a + $(MPICXX) $(LDFLAGS) code/TheRayGenomeAssembler.a RayPlatform/libRayPlatform.so -o $@ @echo $(PREFIX) PREFIX @echo Ray TARGETS code/TheRayGenomeAssembler.a: @cd code; make MPICXX=$(MPICXX) CXXFLAGS=$(CXXFLAGS) -j $(J) all ; cd .. -RayPlatform/libRayPlatform.a: - @cd RayPlatform; make MPICXX=$(MPICXX) CXXFLAGS=$(CXXFLAGS) -j $(J) ; cd .. +RayPlatform/libRayPlatform.so: + @cd RayPlatform; cmake .; make MPICXX=$(MPICXX) CXXFLAGS=$(CXXFLAGS) -j $(J) ; cd .. clean: @rm -f Ray showOptions PREFIX TARGETS $ ldd Ray linux-vdso.so.1 = (0x7fff5a9ff000) libRayPlatform.so = /home/seb/git-clones/RayPlatform/libRayPlatform.so (0x7f1be1752000) libmpi_cxx.so.1 = /usr/lib64/openmpi/lib/libmpi_cxx.so.1 (0x7f1be1538000)
Re: Packaging Ray for Debian Med
Hi Sébastien, On Mon, Nov 05, 2012 at 06:59:27PM -0500, Sébastien Boisvert wrote: I want the ray-extra because ray contains the executable Ray whereas ray-extra has some R and python scripts which are not used in most Ray workflows. Thus, I don't want the ray package to require (or suggest) r-base-core or python. Right, avoiding some extra dependencies which are usually unneeded is a fair reason for a separate binary package. ray-doc contains documentation not required to operate Ray. The man page alone is sufficient. I understood this but as I previosely said I personally would not split these few bytes from the main package. But in any case it is your decision as the person responsible for the package. I just wanted to make sure you are aware about typical reasons for splitting and that your decision was not simply after having read in the docs that it is possible to split up into different binary packages. In the end it is a matter of taste but if you would decide to keep these packages they should be Architecture: all in any case. Fixed. Fine. I guess now you need to fire up lintian -i ray_2.1.0-1_amd64.changes which tells you about some issues of your packaging. The explanation that are triggered in verbose mode (-i) should give you a reasonable clue what needs to be done but in any case feel free to ask here if you might stumble upon any issue you might not understand. Regarding W: ray: hardening-no-relro usr/bin/Ray W: ray: hardening-no-fortify-functions usr/bin/Ray I would recommend to simply try debian/compat: 9 and in Build-Depends: debhelper (= 9) which gives you good chances that hardening will be switched on in case Ray has a properly crafted build system. BTW, in debian/changelog you are using stable as target distribution. Besides the fact that you *never* can upload to stable and always have to target at unstable our convention is to use UNRELEASED in VCS as long as the package is not yet uploaded. Kind regards and thanks for your work on this Andreas. Sent from my IBM Blue Gene/Q Way cooler than any other booring Sent from my ... signatures. :-) -- 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: http://lists.debian.org/20121106071817.ga7...@an3as.eu
