Re: [MoM] kmer-tools status update
Hi Afif, On Thu, May 28, 2015 at 02:58:58AM -0700, Afif Elghraoui wrote: so we do have counter examples to this (surely not build with d-shlibs) and so it might be possibly to forget d-shlibs and move around the files via usual dh_install but I think we should draw a cutting line here. I'd (strongly) recommend to upstream using autoconf + libtool to get a proper build system and we could live with the static lib for the moment. Okay, but I wouldn't hold my breath for getting a new build system here. Upstream seems to have gone out of there way to get a build system with non-recursive Make. I'll have to bring this up with him and see what he says. If he's willing to go with it, I would probably end up being the one to implement it. If upstream might be willing to adopt this this would be at least a solution. In the end you need to outwight the time you spend to work around a broken build system and the time you might need to implement a sensible build system. I remember that this was one of my first packages (wordnet) back in the 90th when I did it the first time and when locking back from now it was the correct thing to do. There is no ensurance that this will really be the case. By the way, wgs-assembler uses the same build system. The upside, though, is that it doesn't make any libraries--at least as far as I know. Lets hope new processing will be a bit faster and I have seen some nice accepts in the last couple of days. :-) point. I think this is a sign that the clean target does not leave the directory tree in the same state as before the first build which has the effect that the package does not build twice in a row. This is considered an error and there are people running checks on the archive from time to time and file according bug reports. That is strange. I will have to keep an eye out for this behavior, but I'd rebuild several times at one sitting throughout the packaging process and haven't encountered any such issues. This might just be a problem with the sharedlibs branch. May be the latter is the case. For the moment I do not consider this a large enough problem to stop me from uploading to new and so I did this. :-) Thank you! You are welcome - the most work was done on your side anyway. :-) Thanks for your good work on this complex package for a MoM project And thank you for your help and support throughout the process. I admit I'm quite happy that I started the MoM project since it has brought us new packages and more importantly new team members. 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/20150528130029.ga18...@an3as.eu
Re: [MoM] kmer-tools status update
Hi Afif, On Tue, May 26, 2015 at 09:24:58PM -0700, Afif Elghraoui wrote: It might be helpful to add that command in the managing patches section on the Debian Med policy. I was always following the steps there when doing my patching. I know the New Maintainer's Guide has it, but it's not easy to read two guides at once. Good hint. If you provide a patch that is easily understandable I'd happily apply this. Ok, I'll see what I can do. This would be great. Adding another binary package requires another new processing. While *usually* this is only a short check (1-3 days delay) we have currently at least two packages (fis-gtm and orthanc) that are hanging there for several weeks for reasons I totally fail to understand (even an ftpmaster ping hasn't triggered any action). I have seen new packages dripping in slowly recently but since about 8-9 monthers new processing is heavily delayed for reasons I don't know. I hope this will change in a decent time frame - usually it is a lack of manpower and bothering an overworked team with questions does not enable them to work more quickly - so I did not used this option (out of previous experiences). I'll take Debian Conference as a chance to find out. If these additional modifications can be easily added later, I say please go ahead with the upload. If you stick to this under the circumstances above I'll upload. I have tried the library packaging, but there is no soname and I am not sure how to assign one since I don't know the state of the interface and how this changes between different svn revisions. I have committed my attempts to the sharedlibs branch (or some similar name), leaving master in a working state. The sharedlibs branch does not build because an actual file is found rather than a symlink to the library+soname, as I describe in my commit message. I checked this and while you correctly noticed that there is some option to get a dynamic library this is not the libtool option which enforces a clean library. The build in the sharedlibs branch fails since d-shlibmove is requiring a symlink for the *.so file. Out of curiosity I checked on my local machine $ readlink /usr/lib/x86_64-linux-gnu/*.so | grep \.so$ libncurses.so libldap_r.so libpng12.so so we do have counter examples to this (surely not build with d-shlibs) and so it might be possibly to forget d-shlibs and move around the files via usual dh_install but I think we should draw a cutting line here. I'd (strongly) recommend to upstream using autoconf + libtool to get a proper build system and we could live with the static lib for the moment. In this view, this looks like it will take a little time and some communication with upstream to sort out. Please upload the current state if it all looks good to you. When doing some experiments with the sharedlibs branch I tried a simple debuild after the build failed due to the d-shlibmove check. I realised that the build in this case failed at some earlier (totally unrelated) point. I think this is a sign that the clean target does not leave the directory tree in the same state as before the first build which has the effect that the package does not build twice in a row. This is considered an error and there are people running checks on the archive from time to time and file according bug reports. For the moment I do not consider this a large enough problem to stop me from uploading to new and so I did this. :-) I just wanted to prepare you about things that might be necessary to do once the package will reach the package pool but perhaps meanwhile the build system has changed and the situation at this point will be different anyway and the problem might have vanished silently. Thanks for your good work on this complex package for a 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/20150527122934.ga13...@an3as.eu
Re: [MoM] kmer-tools status update
Hi, Andreas, On الثلاثاء 26 أيار 2015 04:27, Andreas Tille wrote: Hi Afif, No need to sorry about this. There are long standing developers who not provide DEP3 headers. :-) It might be helpful to add that command in the managing patches section on the Debian Med policy. I was always following the steps there when doing my patching. I know the New Maintainer's Guide has it, but it's not easy to read two guides at once. Good hint. If you provide a patch that is easily understandable I'd happily apply this. Ok, I'll see what I can do. In short: If you confirm that you intentionally want to go with static linking for now I'd go on uploading to the new queue. Ok, so if you upload it now, how easy will it be to later add new binary packages from this source-- like the shared library package and the other components of kmer? I'm a bit eager to get in line at the new queue since reading about how far it's backed up. Adding another binary package requires another new processing. While *usually* this is only a short check (1-3 days delay) we have currently at least two packages (fis-gtm and orthanc) that are hanging there for several weeks for reasons I totally fail to understand (even an ftpmaster ping hasn't triggered any action). I have seen new packages dripping in slowly recently but since about 8-9 monthers new processing is heavily delayed for reasons I don't know. I hope this will change in a decent time frame - usually it is a lack of manpower and bothering an overworked team with questions does not enable them to work more quickly - so I did not used this option (out of previous experiences). I'll take Debian Conference as a chance to find out. If these additional modifications can be easily added later, I say please go ahead with the upload. If you stick to this under the circumstances above I'll upload. I have tried the library packaging, but there is no soname and I am not sure how to assign one since I don't know the state of the interface and how this changes between different svn revisions. I have committed my attempts to the sharedlibs branch (or some similar name), leaving master in a working state. The sharedlibs branch does not build because an actual file is found rather than a symlink to the library+soname, as I describe in my commit message. In this view, this looks like it will take a little time and some communication with upstream to sort out. Please upload the current state if it all looks good to you. Many thanks and regards Afif -- Afif Elghraoui | عفيف الغراوي http://afif.ghraoui.name -- 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/5565471a.7050...@ghraoui.name
Re: [MoM] kmer-tools status update
Hi, Andreas, On الإثنين 25 أيار 2015 00:13, Andreas Tille wrote: Hi Afif, On Sun, May 24, 2015 at 11:12:00PM -0700, Afif Elghraoui wrote: Hi, Andreas, I tried to go ahead with packaging shared libraries, but it looks like I have to read three to five more manuals before I can proceed and know what I'm doing. Hmmm, I can not parse this as a specific question to me - just ask if I can help somehow. Regarding packaging shared libraries I personally recommend using d-shlibs. There are some examples in our repositories for instance bambamc, bamtools or snp-sites (just a random pick from my poor mind with no specific order or preference) Thanks. These are good enough pointers for me to start trying something. I was mostly confused by having to mind the symbols and sonames. It looks like I should just build the .so files and take care of their placement in multiarch folders...at least, as a first step. [...] Moreover, the spacing is the same for the other two generated packages and I don't get this warning for them. Otherwise, the package is lintian clean. See my latest push. :-) Oh... I see. :facepalm: On the other hand when I'm using the latest lintian (from unstable) I get some more things as info, which might be worth fixing Ok, I just discovered the -I flag for lintian and see what you saw. I: kmer-tools source: duplicate-short-description meryl libmeryl-dev Done. I: kmer-tools source: quilt-patch-missing-description kazlib.patch I: kmer-tools source: quilt-patch-missing-description remove-kazlib.patch Done. You might like to override I: kmer-tools source: debian-watch-file-is-missing with a comment to express the fact that there is no chance to write such a file. Lintian info recommended creating a dummy watch file with comments explaining the situation. I did that and hope it's ok with you (more details in my commit message). I decide from time to time whether I fix things like I: meryl: spelling-error-in-binary usr/bin/existDB endianess endianness If there is a responsive upstream I send a patch. Fixing this involves renaming two of the source files. Is there an way to do that with quilt without essentially deleting it and creating it with a different name? I feel like upstream will laugh at me if I send in a patch to correct such a minor thing. For things like I: meryl: hardening-no-fortify-functions usr/bin/existDB I never found a solution myself and consider this false positives. Feel free to leave these untouched. I was able to resolve this. The dh_make debian/rules template had some extremely useful information in this regard. Please add the DEP3 headers to the patches since this is helpful for other team members. Done (and sorry about that; I totally forgot about the quilt header thing). Thanks and regards Afif -- Afif Elghraoui | عفيف الغراوي http://afif.ghraoui.name -- 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/55642cc3.5020...@ghraoui.name
Re: [MoM] kmer-tools status update
Hi Afif, On Tue, May 26, 2015 at 01:20:19AM -0700, Afif Elghraoui wrote: Hmmm, I can not parse this as a specific question to me - just ask if I can help somehow. Regarding packaging shared libraries I personally recommend using d-shlibs. There are some examples in our repositories for instance bambamc, bamtools or snp-sites (just a random pick from my poor mind with no specific order or preference) Thanks. These are good enough pointers for me to start trying something. I was mostly confused by having to mind the symbols and sonames. It looks like I should just build the .so files and take care of their placement in multiarch folders...at least, as a first step. Yes. I like the fact that d-shlibmove makes it easy by simply specifying --multiarch and that you do not neet to care whether sonames are correct or not since d-shlibmove checks it for you. Things basically turn out to be something like d-shlibmove --commit \ --multiarch \ --devunversioned \ --exclude-la \ --movedev debian/tmp/usr/include/* usr/include \ debian/tmp/usr/lib/lib*.so However, it seems there are no dynamic libraries provided since you do only provide a libmeryl-dev package but no libmerylsoname package, right? While the dynamic library package would be the high art of packaging I would have no problems to follow the pragmatic approach and go with the static linking for the moment. Finally we do not want to leave our final goal to package wgs-assembler out of sight. Otherwise you need to tweak the build system to use libtool and create dynamic libraries. Moreover, the spacing is the same for the other two generated packages and I don't get this warning for them. Otherwise, the package is lintian clean. See my latest push. :-) Oh... I see. :facepalm: :-) Yes, that simply happens... I: kmer-tools source: duplicate-short-description meryl libmeryl-dev Done. I: kmer-tools source: quilt-patch-missing-description kazlib.patch I: kmer-tools source: quilt-patch-missing-description remove-kazlib.patch Done. Fine. BTW, for lintian I recommend the following: $ cat ~/.lintianrc color=always display-experimental=no display-info=yes pedantic=no ## show-overrides=yes You might like to override I: kmer-tools source: debian-watch-file-is-missing with a comment to express the fact that there is no chance to write such a file. Lintian info recommended creating a dummy watch file with comments explaining the situation. I did that and hope it's ok with you (more details in my commit message). Yes, that's perfectly OK. I decide from time to time whether I fix things like I: meryl: spelling-error-in-binary usr/bin/existDB endianess endianness If there is a responsive upstream I send a patch. Fixing this involves renaming two of the source files. Is there an way to do that with quilt without essentially deleting it and creating it with a different name? I feel like upstream will laugh at me if I send in a patch to correct such a minor thing. If you feel upstream will laugh at you than please do not mind spending your time on this with quilt tricks. There is no sense in huntin down any lintian info just for the sake of it. The maintenance burden (for now and in future if possibly other Debian developers need to understand your code) does not rectify just fixing spelling errors only because lintian has detected them (there are possibly more undetected ones). For things like I: meryl: hardening-no-fortify-functions usr/bin/existDB I never found a solution myself and consider this false positives. Feel free to leave these untouched. I was able to resolve this. The dh_make debian/rules template had some extremely useful information in this regard. Hmmm, interesting. I was always able to get rid of the relro *Warning* when doing this. May be I need to review the rules files in future more thoroughly. Thanks for hunting this down. Please add the DEP3 headers to the patches since this is helpful for other team members. Done (and sorry about that; I totally forgot about the quilt header thing). No need to sorry about this. There are long standing developers who not provide DEP3 headers. :-) In short: If you confirm that you intentionally want to go with static linking for now I'd go on uploading to the new queue. Kind regards and thanks for your thorough work on this 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/20150526093339.gc5...@an3as.eu
Re: [MoM] kmer-tools status update
Hi, Andreas, On الثلاثاء 26 أيار 2015 02:33, Andreas Tille wrote: Thanks. These are good enough pointers for me to start trying something. I was mostly confused by having to mind the symbols and sonames. It looks like I should just build the .so files and take care of their placement in multiarch folders...at least, as a first step. Yes. I like the fact that d-shlibmove makes it easy by simply specifying --multiarch and that you do not neet to care whether sonames are correct or not since d-shlibmove checks it for you. Things basically turn out to be something like d-shlibmove --commit \ --multiarch \ --devunversioned \ --exclude-la \ --movedev debian/tmp/usr/include/* usr/include \ debian/tmp/usr/lib/lib*.so That looks great. However, it seems there are no dynamic libraries provided since you do only provide a libmeryl-dev package but no libmerylsoname package, right? I actually started doing this, but don't have a commit ready yet. While the dynamic library package would be the high art of packaging I would have no problems to follow the pragmatic approach and go with the static linking for the moment. Finally we do not want to leave our final goal to package wgs-assembler out of sight. Otherwise you need to tweak the build system to use libtool and create dynamic libraries. This part isn't too bad, actually. The custom build system has a shared library option that I was able to latch onto and make them with. BTW, for lintian I recommend the following: $ cat ~/.lintianrc color=always display-experimental=no display-info=yes pedantic=no ## show-overrides=yes Good to know. I'll copy that. I decide from time to time whether I fix things like I: meryl: spelling-error-in-binary usr/bin/existDB endianess endianness If there is a responsive upstream I send a patch. Fixing this involves renaming two of the source files. Is there an way to do that with quilt without essentially deleting it and creating it with a different name? I feel like upstream will laugh at me if I send in a patch to correct such a minor thing. If you feel upstream will laugh at you than please do not mind spending your time on this with quilt tricks. There is no sense in huntin down any lintian info just for the sake of it. The maintenance burden (for now and in future if possibly other Debian developers need to understand your code) does not rectify just fixing spelling errors only because lintian has detected them (there are possibly more undetected ones). Ok. Yeah, I don't think it will be considered worth the potential headache of breaking something inadvertently. For things like I: meryl: hardening-no-fortify-functions usr/bin/existDB I never found a solution myself and consider this false positives. Feel free to leave these untouched. I was able to resolve this. The dh_make debian/rules template had some extremely useful information in this regard. Hmmm, interesting. I was always able to get rid of the relro *Warning* when doing this. May be I need to review the rules files in future more thoroughly. Thanks for hunting this down. :) Please add the DEP3 headers to the patches since this is helpful for other team members. Done (and sorry about that; I totally forgot about the quilt header thing). No need to sorry about this. There are long standing developers who not provide DEP3 headers. :-) It might be helpful to add that command in the managing patches section on the Debian Med policy. I was always following the steps there when doing my patching. I know the New Maintainer's Guide has it, but it's not easy to read two guides at once. In short: If you confirm that you intentionally want to go with static linking for now I'd go on uploading to the new queue. Ok, so if you upload it now, how easy will it be to later add new binary packages from this source-- like the shared library package and the other components of kmer? I'm a bit eager to get in line at the new queue since reading about how far it's backed up. If these additional modifications can be easily added later, I say please go ahead with the upload. Kind regards and thanks for your thorough work on this Thanks for all your help in speeding up the process :) Afif -- Afif Elghraoui | عفيف الغراوي http://afif.ghraoui.name -- 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/55644589.9070...@ghraoui.name
Re: [MoM] kmer-tools status update
Hi Afif, On Tue, May 26, 2015 at 03:06:01AM -0700, Afif Elghraoui wrote: Yes. I like the fact that d-shlibmove makes it easy by simply specifying --multiarch and that you do not neet to care whether sonames are correct or not since d-shlibmove checks it for you. Things basically turn out to be something like d-shlibmove --commit \ --multiarch \ --devunversioned \ --exclude-la \ --movedev debian/tmp/usr/include/* usr/include \ debian/tmp/usr/lib/lib*.so That looks great. However, it seems there are no dynamic libraries provided since you do only provide a libmeryl-dev package but no libmerylsoname package, right? I actually started doing this, but don't have a commit ready yet. While the dynamic library package would be the high art of packaging I would have no problems to follow the pragmatic approach and go with the static linking for the moment. Finally we do not want to leave our final goal to package wgs-assembler out of sight. Otherwise you need to tweak the build system to use libtool and create dynamic libraries. This part isn't too bad, actually. The custom build system has a shared library option that I was able to latch onto and make them with. In this case I'd recommend using it. No need to sorry about this. There are long standing developers who not provide DEP3 headers. :-) It might be helpful to add that command in the managing patches section on the Debian Med policy. I was always following the steps there when doing my patching. I know the New Maintainer's Guide has it, but it's not easy to read two guides at once. Good hint. If you provide a patch that is easily understandable I'd happily apply this. In short: If you confirm that you intentionally want to go with static linking for now I'd go on uploading to the new queue. Ok, so if you upload it now, how easy will it be to later add new binary packages from this source-- like the shared library package and the other components of kmer? I'm a bit eager to get in line at the new queue since reading about how far it's backed up. Adding another binary package requires another new processing. While *usually* this is only a short check (1-3 days delay) we have currently at least two packages (fis-gtm and orthanc) that are hanging there for several weeks for reasons I totally fail to understand (even an ftpmaster ping hasn't triggered any action). I have seen new packages dripping in slowly recently but since about 8-9 monthers new processing is heavily delayed for reasons I don't know. I hope this will change in a decent time frame - usually it is a lack of manpower and bothering an overworked team with questions does not enable them to work more quickly - so I did not used this option (out of previous experiences). I'll take Debian Conference as a chance to find out. If these additional modifications can be easily added later, I say please go ahead with the upload. If you stick to this under the circumstances above I'll upload. Kind regards and thanks for your thorough work on this Thanks for all your help in speeding up the process :) You are welcome 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/20150526112723.gf5...@an3as.eu
Re: [MoM] kmer-tools status update
Hi Afif, On Sun, May 24, 2015 at 11:12:00PM -0700, Afif Elghraoui wrote: Hi, Andreas, I tried to go ahead with packaging shared libraries, but it looks like I have to read three to five more manuals before I can proceed and know what I'm doing. Hmmm, I can not parse this as a specific question to me - just ask if I can help somehow. Regarding packaging shared libraries I personally recommend using d-shlibs. There are some examples in our repositories for instance bambamc, bamtools or snp-sites (just a random pick from my poor mind with no specific order or preference) The package is otherwise ready to go. I have man pages for all the executables and I believe everything is in order. Fine. My lintian is complaining about a leading space on the description field for the meryl and libmeryl-dev binary packages. I put the the description immediately after the colon and rebuild and still get this warning. Moreover, the spacing is the same for the other two generated packages and I don't get this warning for them. Otherwise, the package is lintian clean. See my latest push. :-) On the other hand when I'm using the latest lintian (from unstable) I get some more things as info, which might be worth fixing I: kmer-tools source: duplicate-short-description meryl libmeryl-dev I: kmer-tools source: quilt-patch-missing-description kazlib.patch I: kmer-tools source: quilt-patch-missing-description remove-kazlib.patch You might like to override I: kmer-tools source: debian-watch-file-is-missing with a comment to express the fact that there is no chance to write such a file. I decide from time to time whether I fix things like I: meryl: spelling-error-in-binary usr/bin/existDB endianess endianness If there is a responsive upstream I send a patch. For things like I: meryl: hardening-no-fortify-functions usr/bin/existDB I never found a solution myself and consider this false positives. Feel free to leave these untouched. How does this look to you? Please add the DEP3 headers to the patches since this is helpful for other team members. All other lintian infos are free to your decision. Thanks and regards Thanks for your work on this 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/20150525071308.gc4...@an3as.eu
