Re: Update on Trinityrnaseq packaging
On Fri Feb 13 2015 at 12:55:49 AM Andreas Tille wrote: > [Reply to list only] > We are oppositely calibrated :-D I prefer to be CC'd even when I am a subscriber and you don't. > On Thu, Feb 12, 2015 at 09:42:45PM +, Michael Crusoe wrote: > > > > - [ ] binary-without-manpage usr/bin/Trinity > > > > > > Same as above. It would be nice to have (even nicer than hardening) > > > there are cases where it is hard to write a sensible manpage. > > > > I've produced one with help2man. > > That's usually the cheapest way and fine for the most cases. > Unfortunately it did not worked in this case - I commited a manually > edited manpage based on yours. The result at least fits nroff syntax. > :-) Thanks! > > > * trinity-plugins/Trimmomatic-0.32: Binary without source! > > >Trimmomatic is packaged in this version anyway - so this should > > >be simply dropped via Files-Excluded > > > > > > > Done > > OK - but the dir remains in the Git repository. You should import > a cleaned up archive. You can get this by > > debian/rules get-orig-source > > ... or if you want to save your bandwidth via > > mk-origtargz --repack --compress xz > Yeah, I had tried that; I get this head-scratching response: mcrusoe@athyra:~/debian/trinityrnaseq$ mk-origtargz --repack --compress xz ../v2.0.3.tar.gz tar: trinityrnaseq-2.0.3/Butterfly/src/lib/jung-graph-impl-2.0.1.jar: Not found in archive tar: trinityrnaseq-2.0.3/Butterfly/src/lib/jung-api-2.0.1.jar: Not found in archive tar: trinityrnaseq-2.0.3/Butterfly/src/lib/jung-algorithms-2.0.1.jar: Not found in archive tar: trinityrnaseq-2.0.3/Butterfly/src/lib/java-getopt-1.0.13.jar: Not found in archive tar: trinityrnaseq-2.0.3/Butterfly/src/lib/collections-generic-4.01.jar: Not found in archive tar: trinityrnaseq-2.0.3/Butterfly/src/lib/Jaligner.jar: Not found in archive tar: trinityrnaseq-2.0.3/Butterfly/prev_vers/Butterfly_r2013_08_14.jar: Not found in archive tar: Exiting with failure status due to previous errors (I checked and they do exist) > > > * trinity-plugins/fstrozzi-Fastool-7c3e034f05: While mentioned > > >properly in d/copyright I'd at least refer to the download > > >location > > > https://github.com/fstrozzi/Fastool > > >in a Comment: field. I'd regard it as the better solution to > > >create a separate package since it might be considered useful > > >for people not only using it via trinityrnaseq > > > > I've added the comment. As for packaging it separately I'll leave this to > > some other motivated individual to do so. There are a lot of > bioinformatics > > libraries that are functionally single use. > > May be I'll care for this in some MoM project. Usually these small > tools are easy targets and than it should be done also for the sake of > separate testing. > Have fun! > > > > * trinity-plugins/parafly/src/ParaFly.cpp: > > > Authors of this wrapper are MB Couger (mbcouger(AT Symbol) > gmail.com, > > > Matt Stowe mstowe(AT Symbol)okstate.edu > > >This should at least deserve an extra d/copyright line and you > > >should also dig for the original download location. I can > > >not evaluate the sense of a separate package. > > > > > > > Nothing coming up. Probably Broad Foundation employees / interns. I think > > they are covered by the existing entry. > > Finally it does not matter what you think but what you can convince > ftpmaster to accept. ;-) > Indeed, but it'll get properly packaged with transdecoder. Lacking an upstream distribution site makes a pretty clear case for not having its own package.
Re: Update on Trinityrnaseq packaging
[Reply to list only] Hi Michael, On Thu, Feb 12, 2015 at 09:42:45PM +, Michael Crusoe wrote: > > ... > > code I have seen (not too much admittedly) had extra *.so files in > > /usr/lib. If you are unsure asking on debian-j...@lists.debian.org is > > the best way to clarify. > > Upon review they are pure Java :-) > > > - [ ] binary-without-manpage usr/bin/Trinity > > > > Same as above. It would be nice to have (even nicer than hardening) > > there are cases where it is hard to write a sensible manpage. > > I've produced one with help2man. That's usually the cheapest way and fine for the most cases. Unfortunately it did not worked in this case - I commited a manually edited manpage based on yours. The result at least fits nroff syntax. :-) > > > - [ ] script-not-executable: several > > > > Usually this is either easy to fix or contains a hidden problem that > > should be fixed. > > Fixed Good! > > * `licensecheck -r *` did not uncover anything suspicious to me > > * trinity-plugins/GAL_0.2.1: This third party code should be > >specified separately with the license that can be found in the > >downloadable archive at > > http://www.sequenceontology.org/software/GAL_Code/ > >However, I'd prefer packaging GAL separately (in the latest > >version) > > Sure, for another day :-) :-) > > * trinity-plugins/Trimmomatic-0.32: Binary without source! > >Trimmomatic is packaged in this version anyway - so this should > >be simply dropped via Files-Excluded > > > > Done OK - but the dir remains in the Git repository. You should import a cleaned up archive. You can get this by debian/rules get-orig-source ... or if you want to save your bandwidth via mk-origtargz --repack --compress xz Afterwards do git import-orig --pristine-tar > > * trinity-plugins/collectl: Packaged for Debian. Once you are > >removing files via Files-Excluded the most easy thing would be > >to delete this as well which saves you the work of mentioning > >it in d/copyright > > Only used via a hidden option. Excluded and added as a 'suggests' If you are sure that it should not be Recommends that's fine for me. > > * trinity-plugins/fstrozzi-Fastool-7c3e034f05: While mentioned > >properly in d/copyright I'd at least refer to the download > >location > > https://github.com/fstrozzi/Fastool > >in a Comment: field. I'd regard it as the better solution to > >create a separate package since it might be considered useful > >for people not only using it via trinityrnaseq > > I've added the comment. As for packaging it separately I'll leave this to > some other motivated individual to do so. There are a lot of bioinformatics > libraries that are functionally single use. May be I'll care for this in some MoM project. Usually these small tools are easy targets and than it should be done also for the sake of separate testing. > > * trinity-plugins/parafly/src/ParaFly.cpp: > > Authors of this wrapper are MB Couger (mbcouger(AT Symbol)gmail.com, > > Matt Stowe mstowe(AT Symbol)okstate.edu > >This should at least deserve an extra d/copyright line and you > >should also dig for the original download location. I can > >not evaluate the sense of a separate package. > > > > Nothing coming up. Probably Broad Foundation employees / interns. I think > they are covered by the existing entry. Finally it does not matter what you think but what you can convince ftpmaster to accept. ;-) > > * trinity-plugins/slclust: Same as for Fasttool - I'd really > >love to see a separate package from > > http://sourceforge.net/projects/slclust/ > > See above :-) Yup. > > * trinity-plugins/TransDecoder_r20140704.tar.gz: > >Same as for Fasttool / slclust: > > https://transdecoder.github.io/ > > > Gah, this contains two programs already packaged (cd-hit & ffindex (two > versions!)) and another copy of Parafly. Looks like this will require a > separate package just to keep the source clean. Trinity can use the Parafly > from this (yet to be created) package. Sometimes the packaging view uncovers this kind of ugly things ... > > * trinity-plugins/jellyfish-2.1.4.tar.gz: --> Files-Excluded > >since we have a separate package > > * trinity-plugins/rsem-1.2.19.tar.gz: --> Files-Excluded since > >you ITP it as you wrote below > > Done. OK. > > Please feel free to ask for help here if you agree that Fastool, slclust > > and transdecoder should be packaged separately. I could even try to > > work in a MoM project with some potential student on these. > > > > > trinityrnaseq has two unfulfilled dependencies: rsem & express > > > > > > rsem > > > - [ ] lacks manpages > > > - [ ] lacks ITP > > > > > > express: > > > - [ ] lacks ITP > > > > Thanks for sending this kind of status messages. That's really helpful > > and enables team input. > > Go team! ... nice you like the cooperation Andreas. -- http://fam
Re: Update on Trinityrnaseq packaging
On Thu Feb 12 2015 at 9:53:12 AM Andreas Tille wrote: > On Thu, Feb 12, 2015 at 12:16:57AM +, Michael Crusoe wrote: > > - [ ] hardening-no-relro usr/lib/trinityrnaseq/Chrysalis/* > > Needs investigation > > While fixing this is nice to have I would not insist on it for sponsoring > the package. > Good to know! > > > - [ ] jar-not-in-usr-share usr/lib/trinityrnaseq/ > Butterfly/Butterfly.jar, > > usr/lib/trinityrnaseq/util/support_scripts/ExitTester.jar > > May be fixable with a move + symlink. Need to make sure that they are > pure > > Java > > I'm not a Java expert but IMHO all JARs are machine independent and thus > should reside in /usr/share. All Java packages with machine dependant > code I have seen (not too much admittedly) had extra *.so files in > /usr/lib. If you are unsure asking on debian-j...@lists.debian.org is the best way to clarify. > Upon review they are pure Java > > > - [ ] binary-without-manpage usr/bin/Trinity > > Same as above. It would be nice to have (even nicer than hardening) > there are cases where it is hard to write a sensible manpage. > I've produced one with help2man. > > - [ ] script-not-executable: several > > Usually this is either easy to fix or contains a hidden problem that > should be fixed. > Fixed > > > - [ ] debian/copyright needs audit > > * lacking "Files: debian/*" paragraph > Fixed. > * `licensecheck -r *` did not uncover anything suspicious to me > * trinity-plugins/GAL_0.2.1: This third party code should be >specified separately with the license that can be found in the >downloadable archive at > http://www.sequenceontology.org/software/GAL_Code/ >However, I'd prefer packaging GAL separately (in the latest >version) > Sure, for another day :-) > * trinity-plugins/Trimmomatic-0.32: Binary without source! >Trimmomatic is packaged in this version anyway - so this should >be simply dropped via Files-Excluded > Done > * trinity-plugins/collectl: Packaged for Debian. Once you are >removing files via Files-Excluded the most easy thing would be >to delete this as well which saves you the work of mentioning >it in d/copyright > Only used via a hidden option. Excluded and added as a 'suggests' > * trinity-plugins/fstrozzi-Fastool-7c3e034f05: While mentioned >properly in d/copyright I'd at least refer to the download >location > https://github.com/fstrozzi/Fastool >in a Comment: field. I'd regard it as the better solution to >create a separate package since it might be considered useful >for people not only using it via trinityrnaseq > I've added the comment. As for packaging it separately I'll leave this to some other motivated individual to do so. There are a lot of bioinformatics libraries that are functionally single use. > * trinity-plugins/parafly/src/ParaFly.cpp: > Authors of this wrapper are MB Couger (mbcouger(AT Symbol)gmail.com, > Matt Stowe mstowe(AT Symbol)okstate.edu >This should at least deserve an extra d/copyright line and you >should also dig for the original download location. I can >not evaluate the sense of a separate package. > Nothing coming up. Probably Broad Foundation employees / interns. I think they are covered by the existing entry. > * trinity-plugins/slclust: Same as for Fasttool - I'd really >love to see a separate package from > http://sourceforge.net/projects/slclust/ See above :-) > > * trinity-plugins/TransDecoder_r20140704.tar.gz: >Same as for Fasttool / slclust: > https://transdecoder.github.io/ Gah, this contains two programs already packaged (cd-hit & ffindex (two versions!)) and another copy of Parafly. Looks like this will require a separate package just to keep the source clean. Trinity can use the Parafly from this (yet to be created) package. > * trinity-plugins/jellyfish-2.1.4.tar.gz: --> Files-Excluded >since we have a separate package > * trinity-plugins/rsem-1.2.19.tar.gz: --> Files-Excluded since >you ITP it as you wrote below > Done. > Please feel free to ask for help here if you agree that Fastool, slclust > and transdecoder should be packaged separately. I could even try to > work in a MoM project with some potential student on these. > > > trinityrnaseq has two unfulfilled dependencies: rsem & express > > > > rsem > > - [ ] lacks manpages > > - [ ] lacks ITP > > > > express: > > - [ ] lacks ITP > > Thanks for sending this kind of status messages. That's really helpful > and enables team input. > Go team!
Re: Packaging rsem and express
On Thu, Feb 12, 2015 at 07:25:25PM +, Michael Crusoe wrote: > > > > Furthermore I did some reasearch about scientific papers and I suspect > > rsem might be related to > > > >http://www.ncbi.nlm.nih.gov/pmc/articles/PMC3875132/ > > > rsem doesn't appear to have its own paper. Close though :-) > > > > > > > > and express to > > > >http://www.ncbi.nlm.nih.gov/pmc/articles/PMC3880119/ > > > Bingo! Both added in Git 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/20150212205220.gb12...@an3as.eu
Re: Packaging rsem and express
On Thu Feb 12 2015 at 10:39:19 AM Andreas Tille wrote: > Hi Michael, > > I had a quick look into your commits. Thanks for working on these. I > did > >cme fix dpkg-control > > on both of them to fix Standards-Version and VCS-fields. Please > gbp-pull. > > Furthermore I did some reasearch about scientific papers and I suspect > rsem might be related to > >http://www.ncbi.nlm.nih.gov/pmc/articles/PMC3875132/ rsem doesn't appear to have its own paper. Close though :-) > > > and express to > >http://www.ncbi.nlm.nih.gov/pmc/articles/PMC3880119/ Bingo! > > > If you confirm this (or suggest better / additional) publications I'd > volunteer to add these (if nobody else might beat me in doing so ;-)). > > The rationale why I'm picky about these metadata (in d/control and > d/upstream/metadata) right from the beginning is that they result in > entries on our tasks pages[1] and if there is some need to contact > upstream it is strengthening our point if we can show that we are really > honest to support their scientific attempt. > > (rsem[1] was added some time ago and I also added express right now > which will show up after the next cron run...) > > Kind regards and thanks for your work on this > > Andreas. > > > [1] http://blends.debian.org/med/tasks/bio#rsem > > -- > 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/20150212083902.gb30...@an3as.eu > >
Bug#778246: ITP: prokka -- rapid annotation of prokaryotic genomes
Package: wnpp Severity: wishlist Owner: Debian Med team X-Debbugs-Cc: debian-de...@lists.debian.org, debian-med@lists.debian.org * Package name: prokka Version : 1.10 Upstream Author : Torsten Seemann * URL : http://www.vicbioinformatics.com/software.prokka.shtml * License : GPL-3+, CC0-1, CC-BY-ND-3 Programming Lang: Perl Description : rapid annotation of prokaryotic genomes A typical 4 Mbp genome can be fully annotated in less than 10 minutes on a quad-core computer, and scales well to 32 core SMP systems. It produces GFF3, GBK and SQN files that are ready for editing in Sequin and ultimately submitted to Genbank/DDJB/ENA. Prokka is a popular bioinformatics program. It will be team maintained by the Debian Med team.
Re: Debian Med Sprint in Montreal @ PyCon 2015?
On Thu, 12 Feb 2015, Michael Crusoe wrote: >Is there interest in having a Debian Med Sprint at PyCon 2015? The dates >are Monday, April 13th 2015 - Thursday, April 16th 2015. >I'll be there running a Sprint for the khmer project but I would be happy >to have Debian folk (both experienced and new contributors) there as well. >Is this a good idea? Who would be interested in co-hosting with me? THAT WOULD BE GREAT! My problem though is that I will be there only for the duration of the conference, so wouldn't be able to stay longer for the sprint. But is there anything I could help with -- let me know. -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Research Scientist,Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- 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/20150212165858.gc7...@onerussian.com
Re: Debian Med Sprint in Montreal @ PyCon 2015?
Hi, On Thu, Feb 12, 2015 at 04:20:26PM +, Michael Crusoe wrote: > Is there interest in having a Debian Med Sprint at PyCon 2015? The dates > are Monday, April 13th 2015 - Thursday, April 16th 2015. > > I'll be there running a Sprint for the khmer project but I would be happy > to have Debian folk (both experienced and new contributors) there as well. > > Is this a good idea? Who would be interested in co-hosting with me? I admit I really like the idea in principle. However, I'm not sure whether we could get some financial support for this. I'd be happy about both - increasing the impact rate as well as making Debian Med more global than just Europe - but I need to evaluate the options for this concerning my own traveling. Thanks a lot for this inspiring suggestion 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/20150212164736.gi30...@an3as.eu
Debian Med Sprint in Montreal @ PyCon 2015?
Is there interest in having a Debian Med Sprint at PyCon 2015? The dates are Monday, April 13th 2015 - Thursday, April 16th 2015. I'll be there running a Sprint for the khmer project but I would be happy to have Debian folk (both experienced and new contributors) there as well. Is this a good idea? Who would be interested in co-hosting with me? Cheers, -- Michael R. Crusoe
Re: Any volunteer to update GNUHealth packages
Hi Mathias, sorry for not answering this issue earlier. On Mon, Feb 09, 2015 at 11:37:09AM +0100, Mathias Behrle wrote: > * Andreas Tille: " Any volunteer to update GNUHealth packages" (Mon, 9 Feb > 2015 > 08:40:47 +0100): > > > GNUHealth 2.8.1 was released which is using tryton 3.4.0. We lost the > > official GNUHealth package recently due to incompatibilities with > > tryton. Any volunteer to prepare a package for exoerimental is more > > than welcome. > > Could you please point out, what's your motivation to call for this work again > in this way Just for clarification: I did not intended to specify any way how the GNUHealth packages are created. My intention was that some work that was done previously should not be thrown away. Any enhancement that might serve our users properly is welcome. > - against the pronounced will of the gnuhealth maintainers (I talked once > again to the gnuhealth maintainers at this years Tryton Unconference in > Leipzig, which are not in favor of having Debian packages but prefer a > distribution agnostic way of installation) Generally speaking I'm careful about "the pronounced will" of a certain representative of a project that is given orally on a conference. I personally met another member of the project at 2011 at Med@Tel who was very keen on packages. It might depend from the time (my information is not as current as yours) and the representative (may be the person I have met is not a technican coming from the Tryton programmers). > - according to [0][1] the moderate interest in the subject I'm not sure that these links are telling something about the moderate interest but I agree that for specific software like software in medicine the interest measured in popcon users is low. I personally do see some sense in delivering packages anyway and I have good reasons for this but I would like to discuss this in a more generic thread like this GNUHealth related one. > - still with the problematic concept of doing *one* package As I said above: I do not insist on this concept. I strongly believe in the Do-O-cracy principle of Debian where the doer decides how things will be done. > - still with the unsolved problem to have gnuhealth modules compatible with > the rest of the Tryton suite inside Debian with a justifiable amount of > effort to do for the maintainer as well as for the release and security team > > I am volunteering to do the gnuhealth packages under the following > prerequistes: > - you give me a number of people interested in Debian gnuhealth packages apart > from you and Emilien ;) (please take this from the humorous side...) I would need to check whether the recipients of the mail to the Debian Med list back in 2011[3] remains and might qualify as "number of people interested" > - gnuhealth packages made by me will be in the well-proven generic way of the > current Tryton modules I have no technical background of Tryton and thus I will simply trust the people who are dealing with this. > - gnuhealth packaging (VCS) will be like for all Tryton modules on alioth +1 > - gnuhealth packages will be made available outside of Debian on > debian.tryton.org (the only way to make them currently available in a clean > and seasoned way to the users with having the relative gnuhealth suite > always > being dedicated to the correct Tryton series and thus being maintainable > without headaches all the time) While I'm not really excited about this I admit that this is better than having no packages at all but outdated packaging code hanging around (as it is currently the case). > It would be very helpful to get those answers instead of just pushing back > always the same idea, that has proven to not being adequate or even not to > work. My intention was not to push back anything but find a sensible solution for potential users of GNUHealth on a Debian system. From a Debian point of view through the eyes of a non-Trytonista like me Emiliens approach looked not bad and seemed to work for a certain period of time. Emilian has declared in [0] that he does not intend to work on this any more and has given reasons for this. He also said in this thread[4] that we would only continue working on this if some consensus can be reached which does not seem to be the case. I can perfectly understand this since for a volunteer its fun to work on technical things but it is not funny to discus conflicting opinions over and over (I obtain from your mail that your agree at least in this point perfectly with Emilien ;-)). In short: If you think you found a proper way to create GNUHealth packages on debian.tryton.org it would probably a nice comfort for some GNUHealth users who intend to run Debian (or one of its derivatives). Kind regards Andreas. > [0] http://lists.gnu.org/archive/html/health-dev/2014-09/msg00053.html > [1] http://lists.gnu.org/archive/html/health-dev/2014-09/msg00057.html [3] https://lists.debian.org/
Re: [Health-dev] OT: gnuhealth distro packaging (was: Should distribution packaging solve the installation/configuration issues our users are having?)
* Emilien Klein: " Re: [Health-dev] OT: gnuhealth distro packaging (was: Should distribution packaging solve the installation/configuration issues our users are having?)" (Thu, 12 Feb 2015 13:36:04 +0100): > 2015-02-12 12:44 GMT+01:00 Mathias Behrle : > > > * Axel Braun: " Re: [Health-dev] Should distribution packaging solve the > > installation/configuration issues our users are having?" (Wed, 11 Feb > > 2015 > > 10:41:43 +0100): > > > > > OpenBuildService is OpenSource and free to use. It builds Debian and > > Ubuntu > > > as well (also on the reference server, build.opensuse.org), and by this > > can > > > use as a common repository. > > > > Axel just asked me per PM, if and why I wouldn't use OBS for Debian > > gnuhealth > > packages and I am also answering here to share with the list. > > > > My points in primarily not using OBS in descending order: > > > > - For the build of Debian packages I am using the Debian toolchain, > > whenever it > > is not possible to use the Debian infrastructure itself. This gives me > > the > > background of a well established and proven build system with extended > > sanity > > tests. > > - I don't know OBS, therefore following remarks may be FUD: > > - The one or two times I wanted to try it was very unresponsive, I > > saved my time in not trying further. > > - I doubt, that the infrastructure as built on debian.tryton.org is > > possible to do on OBS. > > - I doubt, that OBS does the sanity testings (lintian, piuparts), which > > are > > part of the quality process on debian.org. > > - Finally I just trust more in Debian native tools than a third party > > build > > service. > > > > I completely agree with Mathias' points. > OpenSuse's Open Build Service *can* create Debian packages that will > install and provide whatever code/functionality you want, but none of the > QA/conventions that have made Debian so robust and stable over the last 20+ > years are enforced. Just to give an example, there are automated bug > reports that are created when the package is automatically rebuilt on all > the platforms that Debian supports (and those are roughly said the largest > number that any Linux distro supports), which will let you know if your > package, or any of its dependencies, have any problems. > When OBS was introduced at FOSDEM (was it in 2012?), I attended the > original introduction talk, and asked if the packages built would > enforce/use Debian's QA. Answer was just No. > > Plus, the whole point of making a *Debian* package is to be able to install > it with a simple `apt-get install`, on Debian or *any* of its numerous > distributions. (and yes Mathias, this is also why I'm not super excited > about building the package inside debian.tryton.org, which is rougly a > software-specific PPA (in the Ubuntu world) which still requires you to > play with your /etc/apt/sources.list. You don't need to be super excited, I am neither. Just provide me the infrastructure and personal ressources on debian.org to be able to serve our users - a project like Tryton releasing quite more often stable series as well as bugfix releases - a project like Tryton providing bug fix releases up to two years for its releases and I will be the first one to use them. BTW even if we will have on Debian some sort of PPA-like repositories this will still need to play with sources lists. I don't see that point. > Adding back in the debian-med list to have all interested parties up to > date. Will do so as well with my answer on the other email chain. Thanks for using and adding in future rather for all Tryton related discussions in Debian. Cheers, Mathias -- Mathias Behrle MBSolutions Gilgenmatten 10 A D-79114 Freiburg Tel: +49(761)471023 Fax: +49(761)4770816 http://www.m9s.biz UStIdNr: DE 142009020 PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6 pgpHmMYDAcd1e.pgp Description: Digitale Signatur von OpenPGP
Re: dh_python2 extension rename breaking module loading
Thanks Matthias, removing the 'module' infix fixed the problem for me.
export PYBUILD_AFTER_INSTALL := \
mv {destdir}{install_dir}/khmer/_khmermodule.so \
{destdir}{install_dir}/khmer/_khmer.so
On Thu Feb 12 2015 at 10:55:16 AM Matthias Klose wrote:
> On 02/11/2015 04:04 PM, Michael Crusoe wrote:
> > Hello,
> >
> > I'm working on the packaging of the khmer project[0] with the debian-med
> > team[1] and we've run into an odd problem: dh_python2 renames the Python
> > extension shared library from `_khmermodule.so` to a version with a
> > mutliarch triplet: `_khmermodule.x86_64-linux-gnu.so`. This breaks
> module
> > loading: "ImportError: No module named _khmer".
>
> The interpreter doesn't look up the old "module" name with the multiarch
> suffix.
> Best thing would be to rename it manually (removing the "module"
> substring. Of
> course dh_python2 could do that as well.
>
>
Re: Is Churchill revolutionary?
On Thu, Feb 12, 2015 at 11:36:40AM +0100, Roland Fehrenbacher wrote: > > "Andreas" == Andreas Tille writes: > > Andreas> Hi, On Wed, Feb 11, 2015 at 11:24:35AM -0600, Scott > Andreas> Christley wrote: > > >> These are essentially data-parallel solutions. What I’ve found is > >> that most of these workflows utilizing existing software, > >> e.g. BWA for alignment and GATK for variant calling, ... > > Andreas> Anybody interested in packaging GATK > > Andreas>https://github.com/broadgsa/gatk > > Not sure whether their licensing permits redistribution within Debian. > Check https://github.com/broadgsa/gatk/tree/master/licensing Without checking I was assuming we are free to distribute the public part which should be covered by https://github.com/broadgsa/gatk/blob/master/licensing/public_license.txt I admit I have not checked all details but if there is some vital interest by some team members we could try to negotiate with the authors. 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/20150212105148.gc30...@an3as.eu
Re: Is Churchill revolutionary?
> "Andreas" == Andreas Tille writes: Andreas> Hi, On Wed, Feb 11, 2015 at 11:24:35AM -0600, Scott Andreas> Christley wrote: >> These are essentially data-parallel solutions. What I’ve found is >> that most of these workflows utilizing existing software, >> e.g. BWA for alignment and GATK for variant calling, ... Andreas> Anybody interested in packaging GATK Andreas>https://github.com/broadgsa/gatk Not sure whether their licensing permits redistribution within Debian. Check https://github.com/broadgsa/gatk/tree/master/licensing -- Roland --- http://www.q-leap.com / http://qlustar.com --- HPC / Storage / Cloud Linux Cluster OS --- -- 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/21724.6.690063.758...@gargle.gargle.howl
Re: Is Churchill revolutionary?
> "Gert" == Gert Wollny writes: Gert> On Wed, 2015-02-11 at 17:31 +, Jorge Sebastião Soares Gert> wrote: >> Hey, >> >> Maybe this is one more of those articles that have been published >> lately with the intent to verify the attention reviewers and >> journals pay to submissions: Gert> I don't think so, the paper appears in a BMC journal, and so Gert> far all review I got from other journals from this publisher Gert> were quite thorough. Besides, they really applied for a patent Gert> for the method: Gert> http://www.google.com/patents/US20130311106 Gert> I skimmed the paper, and what they claim is that they found a Gert> parallelization strategy that gives close to optimal scaling Gert> which really seems to make a difference when using *lots* of Gert> processors. It's not my field of work, so I can't comment on Gert> the details. Since I'm not a Bioinformtician, I ask myself: Are there tools in DebMed (or otherwise free) to achieve the same results, even if currently not as performing? If so, I'd be interested to look at them and see how they can be optimized to achieve similar performance. If their tasks are data-parallel a lot of the performance gain might come from a great HW setup. What would be needed is some kind of benchmark everyone in the field is familiar with. Cheers, Roland --- http://www.q-leap.com / http://qlustar.com --- HPC / Storage / Cloud Linux Cluster OS --- -- 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/21724.32876.213381.965...@gargle.gargle.howl
Re: dh_python2 extension rename breaking module loading
On 02/11/2015 04:04 PM, Michael Crusoe wrote: > Hello, > > I'm working on the packaging of the khmer project[0] with the debian-med > team[1] and we've run into an odd problem: dh_python2 renames the Python > extension shared library from `_khmermodule.so` to a version with a > mutliarch triplet: `_khmermodule.x86_64-linux-gnu.so`. This breaks module > loading: "ImportError: No module named _khmer". The interpreter doesn't look up the old "module" name with the multiarch suffix. Best thing would be to rename it manually (removing the "module" substring. Of course dh_python2 could do that as well. -- 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/54dc6a6d.7050...@debian.org
Packaging rsem and express
Hi Michael, I had a quick look into your commits. Thanks for working on these. I did cme fix dpkg-control on both of them to fix Standards-Version and VCS-fields. Please gbp-pull. Furthermore I did some reasearch about scientific papers and I suspect rsem might be related to http://www.ncbi.nlm.nih.gov/pmc/articles/PMC3875132/ and express to http://www.ncbi.nlm.nih.gov/pmc/articles/PMC3880119/ If you confirm this (or suggest better / additional) publications I'd volunteer to add these (if nobody else might beat me in doing so ;-)). The rationale why I'm picky about these metadata (in d/control and d/upstream/metadata) right from the beginning is that they result in entries on our tasks pages[1] and if there is some need to contact upstream it is strengthening our point if we can show that we are really honest to support their scientific attempt. (rsem[1] was added some time ago and I also added express right now which will show up after the next cron run...) Kind regards and thanks for your work on this Andreas. [1] http://blends.debian.org/med/tasks/bio#rsem -- 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/20150212083902.gb30...@an3as.eu
