Re: Bug#814000: ITP: cwltool -- Common workflow language reference implementation
Hi, Andreas, على الثلاثاء 19 نيسـان 2016 02:20، كتب Andreas Tille: > > I'd like to come back to this plan: > > On Fri, Mar 18, 2016 at 12:21:47AM -0700, Afif Elghraoui wrote: >>> However, even if we have discussed this before the situation is that if >>> we recommend biologists to install med-bio and med-bio-dev they end up >>> with an installation without cwltool. One way to fix this is to add >>> science-tools to the Dependencies of med-bio. Alternatively I do not >>> see any problem in mentioning cwltool in science-tools *and* med-bio - >>> finally it does not harm to advertise good things in more than one >>> place. What do you think? >>> >> >> This also came up before [1] :). We decided to go with making >> science-tools itself a Suggests by med-bio and med-imaging. I mistakenly >> wrote it as debian-science-tools, which you subsequently fixed in this >> commit: > > I checked why science-tools is not a metapackage (I should have checked > at debian-science upload time :-() and noticed that science/tasks/tools > says: > > Metapackage: false > > and the reason is given in the description of the task: > >Note that there is no according metapackage created since the packages >might be to different to make sense to install all on one machine. > > I think this reason has a point - so we come back to the discussion how > to get a sensible dependency between cwltool and our tasks ... With the current setup, it seems like the answer should be to create another metapackage for workflow management systems. Of the entries currently in science-tools, at least pegasus-wms, snakemake, and cwltool could go directly in there. Then both our tasks and science-tools can refer to this new metapackage. regards Afif -- Afif Elghraoui | عفيف الغراوي http://afif.ghraoui.name
Re: orthanc-imagej 1.1
Hi Sébastien, On Tue, Apr 19, 2016 at 11:30:53AM +0200, Sebastien Jodogne wrote: > >For me the move is not urgent if the issue above is no real problem for > >you. > > OK, so I propose to move the package to Git. Done.[1] > I don't know how to do the move by myself (as I'm not a Debian developer, I > might even not be able to do so) Anybody with commit permissions (so definitely you as well) can do this and is invited to do it. :-) However, since with some experience the process is faster and I have kind of this experience its fine to ping me to do this. > Andreas, would it possible for you to do > the move when you have some sparse time (this is really low-priority)? There is nearly no extra time involved and I'd like to get rid of tasks on my desk that might be forgotten later. Kind regards Andreas. [1] https://anonscm.debian.org/git/debian-med/orthanc-imagej.git -- http://fam-tille.de
Re: Mugsy (Was: Seqan knowledge needed (Was: Help needed in C++ / seqan issue))
Hi Fabian, On Tue, Apr 19, 2016 at 02:59:15PM +0200, Fabian Klötzl wrote: > >>> Cool. Just ping me for sponsering. > >> > >> I guess it makes sense, to move the packaging to git, first. > > > > Huh? Its at > > > > git://anonscm.debian.org/debian-med/mugsy.git > > Yeah, but you ported those tools to the MUMmer package, which is still > on SVN according to https://tracker.debian.org/pkg/mummer Ahhh, you are right - we were talking about mummer. Feel perfectly free to move it to Git or ask me to do so and I'll do in the next couple of hours. Kind regards Andreas. -- http://fam-tille.de
Re: Mugsy (Was: Seqan knowledge needed (Was: Help needed in C++ / seqan issue))
On 19.04.2016 14:53, Andreas Tille wrote: > On Tue, Apr 19, 2016 at 02:40:34PM +0200, Fabian Klötzl wrote: I have some extra patches for those tools, making them up to ten times faster. Will commit in due course. >>> >>> Cool. Just ping me for sponsering. >> >> I guess it makes sense, to move the packaging to git, first. > > Huh? Its at > > git://anonscm.debian.org/debian-med/mugsy.git > Yeah, but you ported those tools to the MUMmer package, which is still on SVN according to https://tracker.debian.org/pkg/mummer
Re: Mugsy (Was: Seqan knowledge needed (Was: Help needed in C++ / seqan issue))
On Tue, Apr 19, 2016 at 02:40:34PM +0200, Fabian Klötzl wrote: > > Yeah, I was lucky that “improving mugsy” was supposed to be my next big > project at work. Little did we know I had to get past “compiling” first. :-) > >> I have some extra patches for those tools, making them up to ten times > >> faster. Will commit in due course. > > > > Cool. Just ping me for sponsering. > > I guess it makes sense, to move the packaging to git, first. Huh? Its at git://anonscm.debian.org/debian-med/mugsy.git > > Once there were patches posted to this list[2] - are you aware of these? > > Yes, I had seen them; But the rest of the code still is abysmal. The > patches are a drop in the ocean, basically. :-( Kind regards Andreas. -- http://fam-tille.de
Re: Mugsy (Was: Seqan knowledge needed (Was: Help needed in C++ / seqan issue))
Hi, On 19.04.2016 14:03, Andreas Tille wrote: > On Tue, Apr 19, 2016 at 12:29:59PM +0200, Fabian Klötzl wrote: >> Hi Andreas, >> >> I spent the last few weeks meandering in the murky marshes of the mugsy >> source code; It is a monstrosity. >> >> [ … lots of whining … ] > > Thanks a lot for the energy you have put into this code. Yeah, I was lucky that “improving mugsy” was supposed to be my next big project at work. Little did we know I had to get past “compiling” first. >>> The current status is: >>> >>> 0. The code seems to be orphaned / unmaintained since 2011. >>> 1. Mugsy contains a *patched* version of MUMmer 3.20. I took over >>> those changes to the Debian MUMmer 3.23 package that sounded >>> sensible >> >> I have some extra patches for those tools, making them up to ten times >> faster. Will commit in due course. > > Cool. Just ping me for sponsering. I guess it makes sense, to move the packaging to git, first. >> It has to be patched first, to provide the same functionality as the >> upstream build (see above). > > Once there were patches posted to this list[2] - are you aware of these? Yes, I had seen them; But the rest of the code still is abysmal. The patches are a drop in the ocean, basically. >>>2. Find some modern replacement that is better regarding code >>> maintenance as well as functionality / speed. >>> I can not really imagine that the last 5 years did not brought >>> up something better. >> >> My advise: drop mugsy entirely. It is just not worth it, waisting any >> more time on it. Also, according to the study [1], mugsy has inferior >> quality to other tools. > > Thanks for the summary I'll foreward for further discussion. Cheers, Fabian >> [1]: http://www.ncbi.nlm.nih.gov/pubmed/25273068 > > [2] https://lists.debian.org/debian-med/2015/04/msg00036.html >
Re: Mugsy (Was: Seqan knowledge needed (Was: Help needed in C++ / seqan issue))
Hi Andreas, I spent the last few weeks meandering in the murky marshes of the mugsy source code; It is a monstrosity. Before answering to your individual points I'd like to stress that I *literally* spend days trying to compile mugsy with seqan 1.3 which comes with Ubuntu 14.04 LTS. A hundred changes in, I gave up. Most of the time, the compiler produces console-filling warnings, overflowing with templates and hiding the actual problems. Next, I built mugsyWGA with the given seqan code, which succeeded. But I have reason to believe the included code is not the one used to produce the binary in the tarball: The seqan library code produces debug output which does not appear in the upstream binary. (Having a library print to std::cerr is extremely fishy.) The "build system" is weird, to say the least. I have nothing against hand-written makefiles per se, but these are simply over-engineered. They try to be platform-agnostic, yet at the same time they include hard-coded paths to locations of libraries on the upstream authors system. Also, the seqan code is piped through a 600-lines-Python-script to produces "forwards". (I don't even …) On 05.04.2016 14:45, Andreas Tille wrote: > On Sat, 25 Apr 2015 08:52:52 +0200 Andreas Tille wrote: >> On Sat, Apr 25, 2015 at 05:30:39AM +0300, johnhom...@gmail.com wrote: >>> I couldn't get it to link, because the authors apparently never heard >>> of autotools. Generally, those handwritten Makefile's just.. made me >>> cry. >> >> +1 +1 (See above) >> >> However, if we really want automake on these old projects we probably >> need to add it ourselves. I did so in the past for living projects and >> it was adapted upstream but I'm not sure here. I am unsure if this is feasible w.r.t. to the weird hacks implemented in the build system. > > The current status is: > > 0. The code seems to be orphaned / unmaintained since 2011. > 1. Mugsy contains a *patched* version of MUMmer 3.20. I took over > those changes to the Debian MUMmer 3.23 package that sounded > sensible I have some extra patches for those tools, making them up to ten times faster. Will commit in due course. > 2. Mugsy also contains a code copy of some files of an old seqan > version. Most of these seem to be not needed and are removed > inside get-orig-source script > > Somehow the removal of the seqan files was a bad idea since when trying > to build against Debian packaged seqan I was running into several errors > which was the reason for my ask for help close to one year ago. For porting mugsy to a newer seqan version you'd need one of the seqan authors from 2011 willing to waste a or two week of their lifes at debugging crazy error messages. > > Since my colleagues stalled the request for the installation of Mugsy I > stopped my effort into this but the topic came up recently again. I > wonder what might be the best way to accomplish the wish to package mugsy: > >1. Go with the seqan code copy? It has to be patched first, to provide the same functionality as the upstream build (see above). >2. Find some modern replacement that is better regarding code > maintenance as well as functionality / speed. > I can not really imagine that the last 5 years did not brought > up something better. > My advise: drop mugsy entirely. It is just not worth it, waisting any more time on it. Also, according to the study [1], mugsy has inferior quality to other tools. Best, Fabian [1]: http://www.ncbi.nlm.nih.gov/pubmed/25273068
Re: orthanc-imagej 1.1
Hello, Thus my personal rule is: If tarball is not identical to download move to Git for packaging. [...] For me the move is not urgent if the issue above is no real problem for you. OK, so I propose to move the package to Git. I don't know how to do the move by myself (as I'm not a Debian developer, I might even not be able to do so): Andreas, would it possible for you to do the move when you have some sparse time (this is really low-priority)? Regards, Sébastien-
Re: Bug#814000: ITP: cwltool -- Common workflow language reference implementation
Hi Afif, I'd like to come back to this plan: On Fri, Mar 18, 2016 at 12:21:47AM -0700, Afif Elghraoui wrote: > > However, even if we have discussed this before the situation is that if > > we recommend biologists to install med-bio and med-bio-dev they end up > > with an installation without cwltool. One way to fix this is to add > > science-tools to the Dependencies of med-bio. Alternatively I do not > > see any problem in mentioning cwltool in science-tools *and* med-bio - > > finally it does not harm to advertise good things in more than one > > place. What do you think? > > > > This also came up before [1] :). We decided to go with making > science-tools itself a Suggests by med-bio and med-imaging. I mistakenly > wrote it as debian-science-tools, which you subsequently fixed in this > commit: I checked why science-tools is not a metapackage (I should have checked at debian-science upload time :-() and noticed that science/tasks/tools says: Metapackage: false and the reason is given in the description of the task: Note that there is no according metapackage created since the packages might be to different to make sense to install all on one machine. I think this reason has a point - so we come back to the discussion how to get a sensible dependency between cwltool and our tasks ... Kind regards Andreas. -- http://fam-tille.de
