tophat: embedded samtools copy
Dear Maintainer, Tophat 2.0.13 started to include a convience copy of samtools 0.1.18, I believe this is technically a violation of Debian policy. Though I'm not sure how hard it would be properly fix the issue. Diane Trout Hi Diane, Please see this thread for more details: https://lists.debian.org/debian-med/2014/10/msg4.html Until we have a solution we need to ship samtools 0.1.18 with tophat. Regards, Alex -- 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/5512bcdb.4000...@biotec.tu-dresden.de
Re: SVN - GIT mass conversion
Hi Roland, On Tue, Mar 24, 2015 at 09:04:23PM +0100, Roland Fehrenbacher wrote: A No objection from my side. However, I personally do not see the A gain to port all packages. While I think we have some people who A remain in the SVN age I simply would consider my time wasted to A do a mass conversion without any obvious profit. we won't do all packages anyway, just those relevant for clustering (Bio, Bio-Dev, NGS, Phylo, IMG, IMG-Dev tasks). It won't be time wasted, because we will do it anyway for our internal use, so it's just a question whether DebMed wants to profit as well. Well, if you do it *anyway* this is what I consider a good reason. :-) A I would not stop anybody from doing this but standardisation on A its own would be no value in itself. In general I think it is, since you don't need to be expert in two VSC tools/packaging workflows and hence save time - higher productivity. It'll be quite a bit easier to help each other out with bug fixes in packages not maintained by oneself. While I agree that it is easier to be an expert in only one VCS you need to consider that we also have SVN experts (believe it or not ;-)). I'd consider it a shame if we would loose a packager since the person has only knowledge in Git and does not spend its time to learn something else. That's why I'd hesitate to force Git on all team members. A Specifically if I think about several R packages which have only A tiny bits in SVN but may be large chunks of data in Git we just A fill up disk space at alioth on local disks and bandwidth for no A obvious win. For some packages, it indeed might make not so much sense, that's why I'd put them up for discussion. OK. A Do you have some stronger arguments for the move which would A rectify this? I don't want to get into flame wars or a deeper discussion about this here, but for me the advantages of GIT are overwhelming and discussed at every corner on the net. We all know that there is a really large migration process from SVN to Git and I'll do not join a flame war about this. I simply ask whether my time for conversion is larger than just carrying two hand full of files in a common SVN. On the other hand, I definitely don't want to force anything on any maintainer. That's exactly my point. Suggestions, comments etc. are obviously welcome. A As I said I'm not against progress so if you do some move please A make sure to drop a file according to the example in Atrunk/packages/clustalx/trunk/README.status OK. Another hint. I have assembled some authors file at https://anonscm.debian.org/viewvc/blends/projects/0svn2git/blends-authors?view=markup which probably covers several authors from Debian Med. Please make sure you do not waste your time on assembling these authors again and also commit the authors file at some decent place (may be in some infrastructure Git (or just commit it to SVN :-P) to make sure other people will not need to redo the work that was just done. 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/20150325142347.ga22...@an3as.eu
Re: tophat: embedded samtools copy
Hi Alex, On Wed, Mar 25, 2015 at 02:49:15PM +0100, Alex Mestiashvili wrote: Dear Maintainer, Tophat 2.0.13 started to include a convience copy of samtools 0.1.18, I believe this is technically a violation of Debian policy. Though I'm not sure how hard it would be properly fix the issue. Diane Trout Hi Diane, Please see this thread for more details: https://lists.debian.org/debian-med/2014/10/msg4.html Until we have a solution we need to ship samtools 0.1.18 with tophat. Is there some ongoing discussion with upstream (since otherwise I do not see any solution). Despite the Debian perspective I think from a scientific perspective we should also avoid running different versions of the same algorithm on our data (when using different tools for comparison for instance). 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/20150325142751.gb22...@an3as.eu
Re: How to upload to Debian Med PPA
Hi Lennart, On Wed, Mar 25, 2015 at 04:36:18PM +0100, L.C. Karssen wrote: Maybe a bit late, but I didn't see any reply to your mail, so just to be sure. Yes, I was simply missing to upload my GPG key. I tried to summarise all things I learned yesterday in four Q-A pairs in our FAQ: https://wiki.debian.org/DebianMed/HowToGet#Q._How_can_I_install_packages_from_Bio-Linux_PPA_to_a_default_Ubuntu_trusty_system.3F Simply to remember myself and possibly help others. Looking at the PPA webpage [1] it seems that your upload worked and the package was created. Yes. Everything works now as I need it. :-) Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150325161204.gb26...@an3as.eu
Re: How to upload to Debian Med PPA
Hi Andreas, Maybe a bit late, but I didn't see any reply to your mail, so just to be sureL On 23-03-15 13:29, Andreas Tille wrote: [People who successfully did where I failed in CC] Hi, I'd like to upload some packages created for Trusty to Debian Med PPA[1]. I was able to create a Trusty cowbuilder chroot[2] and to build a package (bambamc) successfully. I've created a dput config file For me this looks like a successful upload. However after 2.5 hours I did not got any message (for Debian uploads I get an e-mail about a successful upload) nor is bambamc visible on the PPA web interface. Anything else I could check? In my experience the PPA upload doesn't generate a confirmation e-mail. Looking at the PPA webpage [1] it seems that your upload worked and the package was created. Lennart. Kind regards Andreas. [1] https://launchpad.net/~debian-med [2] How to create the Trusto cowbuilder chroot on a Debian machine: sudo apt-get install ubuntu-archive-keyring echo 'COMPONENTS=main universe' ~/.pbuilderrc-ubuntu sudo cowbuilder --create --basepath /var/cache/pbuilder/trusty.cow --mirror http://de.archive.ubuntu.com/ubuntu/ --distribution trusty \ --debootstrapopts --keyring=/usr/share/keyrings/ubuntu-archive-keyring.gpg \ --configfile ~/.pbuilderrc-ubuntu -- *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* L.C. Karssen Utrecht The Netherlands lenn...@karssen.org http://blog.karssen.org GPG key ID: A88F554A -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*- signature.asc Description: OpenPGP digital signature
Re: SVN - GIT mass conversion
A == Andreas Tille andr...@an3as.eu writes: Hi Andreas, A I would not stop anybody from doing this but standardisation on A its own would be no value in itself. In general I think it is, since you don't need to be expert in two VSC tools/packaging workflows and hence save time - higher productivity. It'll be quite a bit easier to help each other out with bug fixes in packages not maintained by oneself. A While I agree that it is easier to be an expert in only one VCS A you need to consider that we also have SVN experts (believe it or A not ;-)). I'd consider it a shame if we would loose a packager A since the person has only knowledge in Git and does not spend its A time to learn something else. That's why I'd hesitate to force A Git on all team members. I think enforcement would definitely be the wrong approach. But declaring a preferred workflow might make sense. That way newcomers without preference won't need to make up their mind ... Just realize it's hard to write about this without showing bias :) A Do you have some stronger arguments for the move which would A rectify this? I don't want to get into flame wars or a deeper discussion about this here, but for me the advantages of GIT are overwhelming and discussed at every corner on the net. A We all know that there is a really large migration process from A SVN to Git and I'll do not join a flame war about this. I simply A ask whether my time for conversion is larger than just carrying A two hand full of files in a common SVN. Sure. Of course we have automated the process as much as possible, so it's essentially no extra work for us (at least for most packages). A Another hint. I have assembled some authors file at A https://anonscm.debian.org/viewvc/blends/projects/0svn2git/blends-authors?view=markup A which probably covers several authors from Debian Med. Please A make sure you do not waste your time on assembling these authors A again and also commit the authors file at some decent place (may A be in some infrastructure Git (or just commit it to SVN :-P) to A make sure other people will not need to redo the work that was A just done. I'll check this out. Best, 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/21779.6036.164791.157...@gargle.gargle.howl
Re: SVN - GIT mass conversion
C == Charles Plessy ple...@debian.org writes: Hi Charles, thanks for your comments. C Le Tue, Mar 24, 2015 at 06:02:49PM +0100, Roland Fehrenbacher a C écrit : while porting DebMed packages to Qlustar, we started a mass conversion of SVN to GIT package repositories. Since at the St. Malo sprint I got the impression that having as much as possible of the DebMed stuff managed via GIT would be desirable in general, we'd also start creating new repos for these packages on alioth that would allow to fully switch to GIT for these packages at a certain date. The goal of this is to standardize DebianMed on GIT entirely. C there is also an effor to propose a standard layout in Debian in C general. It is work in progress, but you can have a look at C http://dep.debian.net/deps/dep14/ and at mailing list archives C after searching with DEP-14 (or variations with/without hyphen C etc.) as a keyword. C (In my understanding, here standard means normalising minor C difference between similar layouts, not forcing everybody to use C the same layout.) Good to know. As far as I can see, the standard git-buildpackage structure is not incompatible with the proposal, even though the branch names are slightly different. Should be fairly straightforward to adjust to an agreed upon debian-wide standard later on. Would wait until that will have appeared. C In Debian Med, I have experimented on alternative layouts that C follow directly upstream's Git repository instead of usign the C source tarball as an intermediate. I prefer that way, but I will C be short of time to keep all my packages up to date just by C myself in the near future, so if my Git layout is on your way to C do good team work, do not hesitate to migrate it to a more C standard one. I've already noticed. We do something similar and I think that's the way to go for upstream managed by GIT projects. When I'll get around thinking some more about this I'll post my ideas, so maybe we can agree upon a common structure/workflow. C (Two main reasons why I will lack time are a) still being a young C parent and b) still spending most of my Debian time learning C Haskell to rewrite the Umegaya system in a hopefully bug-free C way.) Enjoy the time with your kids :) Best, 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/21779.5400.92745.849...@gargle.gargle.howl
Re: SVN - GIT mass conversion
Le Wed, Mar 25, 2015 at 03:23:47PM +0100, Andreas Tille a écrit : Another hint. I have assembled some authors file at https://anonscm.debian.org/viewvc/blends/projects/0svn2git/blends-authors?view=markup which probably covers several authors from Debian Med. Please make sure you do not waste your time on assembling these authors again and also commit the authors file at some decent place (may be in some infrastructure Git (or just commit it to SVN :-P) to make sure other people will not need to redo the work that was just done. Hi all, how about the following URL :) https://anonscm.debian.org/viewvc/debian-med/trunk/community/infrastructure/comitters?view=markup Have a nice day, Charles -- 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: https://lists.debian.org/20150325234341.gb16...@falafel.plessy.net
