[MoM] Re: ITP: r-cran-igraph -- GNU R package for igraph
Dear Alba, On Thu, May 14, 2015 at 12:20:04PM +0100, Alba Crespi wrote: I have seen one repository created by the user albac-guest with the name pkg.git. It seems you literally followed: ssh git.debian.org cd /git/debian-med ./setup-repository pkg 'Packaging of pkg in Debian' while this pkg was just a placeholder for your package. I now tried to enhance the syntax to ./setup-repository pkg 'Packaging of pkg in Debian' That sound much clear to me! Thanks :) :-) Since we are now diving into the details of the Debian Med team and I would really encourage you to keep on asking even if the questions you might come up might sound simple I suggest we follow the formalism I established in the Debian Med team which is called Mentoring of the Month: https://wiki.debian.org/DebianMed/MoM These mail exchanges are exactly what MoM is about and so I took the freedom without asking you to add an according row to the MoM students table and tagged the subject [MoM]. This has the advantage that other potential newcomers will be able to easily spot this type of conversation while people who are just keen on discussing medical software might skip this. You might have noticed that I have put you into the June slot. The reason is that one one hand May is just occupied but I'll be basically offline in June and I would really get you up and running quite quickly. Since you are quite advanced and I assume not much mentoring will be needed any more (same with the other student Afif I hope to be able to work with you both at the same time and the usual mentoring quality (in terms of speedy response and detailed explanations). I hope you like this. We are really happy about hints like this. However, the problem is from a perspective of a senior developer it is sometimes hard to feel like a newcomer and what needs to be mentioned in what detail. Any hint you might like to give how to enhance the documentation after you understood things due to some explanation here on the list would be welcome. As you said, once I understand better, I will This would be really welcome. BTW, the policy document remains in SVN[1] which might a show stopper for some Git users. We might consider moving the document (and the other files in the community dir to Git) if others agree. In any case you also have commit permissions to SVN. (and here replace pkg by r-cran-fastmatch) via git push --all --set-upstream git push --tags Done it! Great. I just pulled it. Yes, I am subscribed to the list. OK, so I only write to the list. Here are my comments to the r-cran-fastmatch packaging. Our policy says that we are using a workflow that includes a pristine-tar branch. You can create this as written in policy by using git import-orig --pristine-tar /path/to/package_version.orig.tar.gz You can do this also now in the current state of the repository. The rationale behind this branch is that it contains the necessary metadata to recreate a md5 sum identical tarball. This makes sure we are working both on the very same tarball without the need to download anything in addition. So could you please import and push this? Regarding debian/changelog you have created three different paragraphs which might describe your changes. This is not necessary for not yet uploaded files. I guess you have uploaded these revisions to mentors.d.n but this is irrelevant for the final upload since neither 1.0-4-1 nor (1.0-4-2 were really uploaded to unstable the changelog might be confusing. Moreover the ITP bug is closed in an outdated changelog paragraph - so it will not effectively closed by the upload. Finally ftpmaster who needs to accept the package does not like long uninteresting stories. In short: Please strip down the changelog to only r-cran-fastmatch (1.0-4-1) unstable; urgency=medium * Initial release. (Closes: #784264) -- Alba Crespi crespialba+deb...@gmail.com Mon, 04 May 2015 18:56:30 +0100 ... perhaps by updating the timestamp. Regarding debian/control: You mention Testsuite: autopkgtest This is probably a cut-n-pasto since no testsuite is actually provided. While we try to approach test suites for each package the upstream code does not seem to provide anything that might be useful for this. In any case you can even drop this field since it is automatically added by dpkg-buildpackage if a test suite is found. The file debian/gbp.conf could be dropped IMHO. It doese not specify anything non standard and unneeded files might add noise. BTW, it specifies pristine-tar = True which is wrong at the moment. Everything else looks fine to me. Thank you very much! You are welcome. :-) Welcome in the Debian Med team Andreas. [1] https://anonscm.debian.org/viewvc/debian-med/trunk/community/website/docs/policy.xml?view=markup -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of
Re: fastq status?
On Thu, May 14, 2015 at 08:57:43AM +0200, olivier.sal...@codeless.fr wrote: Debian Science team. In other words: While you stated that what we need is probably a different code base than we need for fastqc the package might need some love independently. I may package it independently but how should we do that ? It would in a way conflict with official hdf5 lib. How should we name /describe it ? Or should it be a kinda libjava-fastq-hdf5 package ? I do not think that fastqc is the important point but may be libjava-hdf5-ethz since it was developed at ethz. Does this sound logical? 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/20150514162201.ga30...@an3as.eu
Re: Plastimatch ready for upload
Hi Gregory, On Wed, May 13, 2015 at 04:42:36PM -0400, Gregory Sharp wrote: In any case I need to say that I have some bad feelings about the code copy of Lua inside plastimatch and the delivered patches for itk are something that should be avoided in the long run. I'm just telling you this as upstream developer - may be you might get some solution for this in one of your next releases. So far, I could fix the following issues: - fix regression test failure on i386 - use shared library build for debian package - remove patched version of lua Cool! Thanks for these interesting changes! It was not clear to me whether it also fixes bug #778066 and thus I did not closed it. The one I couldn't solve was to remove the patched ITK files. The patch is still relevant for the less popular platforms where ITK4 is not available. OK. Thank you, 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/20150514165834.gd30...@an3as.eu
Re: Group Policy for Creating Standalone Metapackages
Hi Afif, On Thu, May 14, 2015 at 01:43:33AM -0700, Afif Elghraoui wrote: Is it fine to put an equivs configuration file in the Debian Med VCS repository for the metapackage instead of the full Debian directory? I didn't find any examples of this kind of situation within Debian Med. I'm sorry, but I'm afraid I do not understand what exactly you want to approach. Equivs and metapackages are different things and I have no idea in how far both would solve your problem. The context is as follows: While waiting for upstream on kmer, I thought I would start working on the components of smrtanalysis. Just before this, I wanted to create the metapackage to keep everything in perspective as I work on them. What exactly should a metapackage do in this situation? 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/20150514170138.ge30...@an3as.eu
Re: ITP: r-cran-igraph -- GNU R package for igraph
Hi Andreas, I think at this part of the policy are the helpful hints: https://debian-med.alioth.debian.org/docs/policy.html#git-tips If you have some more specific question where you might get struck please give more details where you specifically might need any help. Sorry, but I find the information rather confusing. I created an ssh key, I copied to my alioth acount and ssh to git.debian.org and setup the repository. I have seen one repository created by the user albac-guest with the name pkg.git. It seems you literally followed: ssh git.debian.org cd /git/debian-med ./setup-repository pkg 'Packaging of pkg in Debian' while this pkg was just a placeholder for your package. I now tried to enhance the syntax to ./setup-repository pkg 'Packaging of pkg in Debian' That sound much clear to me! Thanks :) Do you think this is better? Since I did not know with what exact package you wanted to start I did on git.debian.org now: ./setup-repository r-cran-fastmatch 'Packaging of r-cran-fastmatch in Debian' Please do so for the other packages you want to create. Perfect :) (I would like to comment that for new members it is quite hard find how to do all this steps, maybe a good improvement for debian-med would be to have a simplier instrucctions and step by step, even the most obvious ones for the seniors developers could be a great advantage to get started!) We are really happy about hints like this. However, the problem is from a perspective of a senior developer it is sometimes hard to feel like a newcomer and what needs to be mentioned in what detail. Any hint you might like to give how to enhance the documentation after you understood things due to some explanation here on the list would be welcome. As you said, once I understand better, I will From here on I don't understand how to use git to upload my packages: I understand that somewhere I need to create a directory where to upload the package? How? Where? You do not upload any package from the Git repository. You just commit your packaging to the repository and the sponsor will pull from there, check and upload. You should push your local packaging repository after git remote add origin git+ssh://git.debian.org/git/debian-med/pkg.git (and here replace pkg by r-cran-fastmatch) via git push --all --set-upstream git push --tags Done it! Do I have to build the package in the repository or locally and then upload it? The repository is just to develop the packaging. There is no direct upload process done from the Git repository. Thank you very much, Hope this helps - feel free to keep on asking Andreas. PS: If you could confirm that you are subscribed to the Debian Med mailing list I would stop CCing you - which is the usual list policy. Yes, I am subscribed to the list. Thank you very much! Alba
Re: [MoM] Re: ITP: r-cran-igraph -- GNU R package for igraph
Hi Alba, On Thu, May 14, 2015 at 10:34:28PM +0100, Alba Crespi wrote: Since you are quite advanced and I assume not much mentoring will be needed any more (same with the other student Afif I hope to be able to work with you both at the same time and the usual mentoring quality (in terms of speedy response and detailed explanations). I hope you like this. It sounds great! :-) Our policy says that we are using a workflow that includes a pristine-tar branch. You can create this as written in policy by using git import-orig --pristine-tar /path/to/package_version.orig.tar.gz Apparently, import-orig is not an option for my version of git? It doesn't appear in the list of possible commands... git import-orig --pristine-tar r-cran-fastmatch_1.0-4.orig.tar.gz git: 'import-orig' is not a git command. See 'git --help'. However, I could do by doing: gbp import-orig --pristine-tar /path/.orig.tar.gz. Is that ok? Aaaarg, for sure that's OK. My bad! Git-buildpackage recently changed its interface and droped the deprecated git in favour of consistently using gbp. I had assumed that I changed every occurance in the policy but I did not and even worse copied it blindly. Sorry for this - its fixed now. You can do this also now in the current state of the repository. The rationale behind this branch is that it contains the necessary metadata to recreate a md5 sum identical tarball. This makes sure we are working both on the very same tarball without the need to download anything in addition. So could you please import and push this? Sorry, I'm not sure what exactly I have to push? git push --all --set-upstream git push --tags * Initial release. (Closes: #784264) -- Alba Crespi crespialba+deb...@gmail.com Mon, 04 May 2015 18:56:30 +0100 ... perhaps by updating the timestamp. done Regarding debian/control: You mention Testsuite: autopkgtest This is probably a cut-n-pasto since no testsuite is actually provided. While we try to approach test suites for each package the upstream code does not seem to provide anything that might be useful for this. In any case you can even drop this field since it is automatically added by dpkg-buildpackage if a test suite is found. Ok, deleted it. (When I was doing this, I followed the instructions on the debian-med web page) The file debian/gbp.conf could be dropped IMHO. It doese not specify anything non standard and unneeded files might add noise. BTW, it specifies pristine-tar = True which is wrong at the moment. Drop it. Fine. I guess if you push for pristine-tar I will be able to see all this. Everything else looks fine to me. Excellent news then! :) Just one more question for now: once I have done the changes, and re-build the package, I have to commit the package in the same way as I did the first time or do I need to use a different set of commands? Just `git push`. 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/20150515054100.ga14...@an3as.eu
Fwd: Re: fastq status?
CC'ing list... Forwarded Message Subject:Re: fastq status? Date: Thu, 14 May 2015 08:57:43 +0200 From: olivier.sal...@codeless.fr olivier.sal...@codeless.fr To: Andreas Tille andr...@an3as.eu On 05/13/2015 10:43 AM, Andreas Tille wrote: Hi Olivier, On Wed, May 13, 2015 at 05:58:41AM +, olivier sallou wrote: could you fix/get info about the hdf5 lib issue (not being complete s needed one in fastq) to get fastq build? No response from the libjhdf5-java maintainers. :-( This does not come unexpected since Sylvestre officially resigned from Debian Science team. In other words: While you stated that what we need is probably a different code base than we need for fastqc the package might need some love independently. I may package it independently but how should we do that ? It would in a way conflict with official hdf5 lib. How should we name /describe it ? Or should it be a kinda libjava-fastq-hdf5 package ? Olivier Hope you will be able to sort things out. Kind regards Andreas. -- gpg key id: 4096R/326D8438 (keyring.debian.org) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438
Group Policy for Creating Standalone Metapackages
Hello, Is it fine to put an equivs configuration file in the Debian Med VCS repository for the metapackage instead of the full Debian directory? I didn't find any examples of this kind of situation within Debian Med. The context is as follows: While waiting for upstream on kmer, I thought I would start working on the components of smrtanalysis. Just before this, I wanted to create the metapackage to keep everything in perspective as I work on them. Each module in this suite has its own repository on github and the top-level repository has almost nothing in it [2]. Thanks and regards Afif 1. https://github.com/PacificBiosciences 2. https://github.com/PacificBiosciences/SMRT-Analysis -- 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/55546035.1040...@ghraoui.name
