Re: [MoM] dwv
Hi list, Getting there... * ssh is all set, * I created the repository ( http://anonscm.debian.org/cgit/debian-med/dwv-orthanc-plugin.git) using the setup-repository script, * I had troubles with uscan and the watch file, uscan stops, complaining about the missing changelog file so I downloaded the tar.gz manually from github, * I ran a: git import-orig --pristine-tar /path/to/dwv-orthanc-plugin-0.3.0.tar.gz * and pushed it all on the server So what's next? On 10 March 2015 at 10:25, Andreas Tille andr...@an3as.eu wrote: Hi Yves, On Tue, Mar 10, 2015 at 09:58:36AM +0100, Yves wrote: Password-less access: I attached my public key to my alioth account. Will see at my first commit if I did it properly. In principle yes. A `ssh alioth.debian.org` before might show any potential problems - specifically if something occures the '-v' option might be enlightening. When you say 'use the http://git.debian.org/git/debian-med', do you mean create a dwvexplorer folder in the debian-med repo? Are they any naming rules? From what I read it seams I can do it, should I? I'm not sure I get the paragraph about 'social git' ( http://debian-med.alioth.debian.org/docs/policy.html#git-repository-structures ), is it possible to use git submodules to avoid having to copy the github repo? Its advisable to use the script /git/debian-med/setup-repository which is mentioned in the link above. I can not give an educated answer about submodules since I never used this and thus can not give proper advise. I personally strongly relay on the workflow to obtain a tarball from a github first using the template for a watch file given here: https://anonscm.debian.org/viewvc/debian-med/trunk/package_template/watch?view=markup Simply remove everything except version=3 https://github.com/#GITHUBUSER#/#PACKAGE#/releases .*/archive/#PREFIX#(\d[\d.-]+)\.(?:tar(?:\.gz|\.bz2)?|tgz) fill in the placeholders and fetch a tarball using uscan --verbose --force-download Once you have the tarball you can import it into the Debian packaging Git repository using git import-orig --pristine-tar /path/to/package_version.orig.tar.gz I know that from a Git perspective it sounds a bit cumbersome since you have the code in Git yet. However, the idea behind this is that you are maintaining *packaging* code here - not upstream code - and this approach also works for all kind of software (even what is not (yet ;-)) maintained in Git). I hope that this advise is clear enouth and does not tweak your mind too much from an upstream maintainers perspective on his own source code. 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/20150310092520.gd31...@an3as.eu
Re: best practice to move a package to team maintainership
Hi Ghis, I do completely support your intention to push packages under a team maintenance. Several times I contacted maintainer directly and proposed him to move the package under the team. Usually people are agreed to do it. You just have to say to maintainer, that he will be able to work on a package as before not to scare him to loose the control under the package. Cheers Anton 2015-03-11 10:34 GMT+01:00 Ghislain Vaillant ghisv...@gmail.com: Hi everyone, I'd like your opinion regarding the following matter. There is a package I need an update for (h5py), which is now particularly outdated. It is currently being maintained by a solo Debian maintainer, who I contacted regarding this but has yet to reply. So I worked on my own, fixed the packaging for the latest upstream version and tested locally on my work machines. My understanding is that, If the package were team-maintained (like hdf5 for instance), I could provide these changes and contribute to updating the package in an easier way. I am not even sure how I can forward my changes to the Debian maintainer, I am just so used to the comfort of working in Debian-science / Debian-med I guess. My question is the following: is there a good practice for suggesting a move to team-maintainership to a solo Debian maintainer ? Via a bug report ? Mailing-list ? Direct email contact ? Also, would that actually make sense, or am I just plain silly here ? Cheers, Ghis
best practice to move a package to team maintainership
Hi everyone, I'd like your opinion regarding the following matter. There is a package I need an update for (h5py), which is now particularly outdated. It is currently being maintained by a solo Debian maintainer, who I contacted regarding this but has yet to reply. So I worked on my own, fixed the packaging for the latest upstream version and tested locally on my work machines. My understanding is that, If the package were team-maintained (like hdf5 for instance), I could provide these changes and contribute to updating the package in an easier way. I am not even sure how I can forward my changes to the Debian maintainer, I am just so used to the comfort of working in Debian-science / Debian-med I guess. My question is the following: is there a good practice for suggesting a move to team-maintainership to a solo Debian maintainer ? Via a bug report ? Mailing-list ? Direct email contact ? Also, would that actually make sense, or am I just plain silly here ? Cheers, Ghis
Re: best practice to move a package to team maintainership
Hi Ghislain, On Wed, Mar 11, 2015 at 09:34:33AM +, Ghislain Vaillant wrote: Hi everyone, I'd like your opinion regarding the following matter. There is a package I need an update for (h5py), which is now particularly outdated. It is currently being maintained by a solo Debian maintainer, who I contacted regarding this but has yet to reply. So I worked on my own, fixed the packaging for the latest upstream version and tested locally on my work machines. Thanks for working on this. My understanding is that, If the package were team-maintained (like hdf5 for instance), I could provide these changes and contribute to updating the package in an easier way. I am not even sure how I can forward my changes to the Debian maintainer, I am just so used to the comfort of working in Debian-science / Debian-med I guess. My question is the following: is there a good practice for suggesting a move to team-maintainership to a solo Debian maintainer ? Via a bug report ? Mailing-list ? Direct email contact ? I guess this is your example case: https://lists.debian.org/debian-med/2015/02/msg7.html You might replace collab-maint by debian-science (since the package belongs to Debian Sciense as you correctly noticed above). When you write a comparable mail please also mention: If I do not hear from you in time - I'd suggest one week I assume your accept the team maintenance in Debian Science. Thus you are not blocked by no answer. I know the maintainer Soeren Sonnenburg (not in person but from his work in Debian Med). He is nice and I think he will most probably agree - just a bit busy and thus I team-hijacked an other package from him into Debian Med (seqan). Also, would that actually make sense, or am I just plain silly here ? This makes perfectly sense and is not silly at all. Thanks for your effort Andreas. PS: Feel free to quote me if you prefer to hide behind an older DD. :-) -- 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/20150311094409.gh28...@an3as.eu
Re: Tried to create libcolt-free-java.git (Was: Please help freeing libcolt-java)
Le 10/03/2015 18:23, Andreas Tille a écrit : So I obviously did not understand the description of your experiment. As I said, I removed the files from src/hep/aida/bin and made the necessary changes to ensure the package still compiles. I didn't try to replace the other files under src/hep/aida with the ones properly licensed from jaida. Would you mind sending me the source package of your experiment to enable me understanding / reproducing what you really did. I could continue with testing the reverse dependencies. I simply want to push this forward even with my limited skills. Here it is: https://github.com/ebourg/colt-debian Emmanuel Bourg -- 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/55002d72.8080...@apache.org
