Re: [MoM] ProbABEL packaging
Hi Andreas, On 12-12-13 09:32, Andreas Tille wrote: > Hi Lennart, > > On Thu, Dec 12, 2013 at 09:20:39AM +0100, L.C. Karssen wrote: >> Hi Andreas, >>> Sorry, what is "dquilt" - I only know quilt (without the d in the >>> beginning)? >> >> dquilt is an alias for quilt created in sections 3.1/3.2 of the URL >> mentioned above: >> alias dquilt='quilt --quiltrc=/home/lennart/.quiltrc-dpkg' > > Ahhh, it is a long time ago I've read the docs. ;-) It is always good > to talk to people who did it recently. ;-))) :-). > >>> I restored the original upstream source in commit >>> >>>f102ee1d3141be3bba95e16d90f59bc5e9f9d01c >>> >>> I also have used `cme fix dpkg-control` (see >>> >>>e1c851706593ea122cfb1240c639f7670408e141 >>> >>> ) which I (strongly) recommend to anybody doing some packaging today. It >>> just does "the right thing" (tm) with your d/control file. :-) >> >> And drags in a whole bunch of dependencies, wow :-). I agree d/control >> looks better now. > > While it looks better it actually does not drag something additional in > - just reformatting dependencies to have only one per line. I meant that installing the packages libconfig-model-dpkg-perl libconfig-model-itself-perl also drags in a whole bunch of other packages (at least when using aptitude install, apt-get might have been more restrictive). Anyway, not a big deal. > I think it > is a good idea to settle on this standard. Just learned it myself a > couple of monthes ago and this is the first thing I'm doing with any > old package ... > > >>> By doing so I tried to build the package again but I was running into >>> >>> make check-TESTS >>> make[3]: Entering directory `/tmp/buildd/probabel-0.4.1/checks' >>> make[4]: Entering directory `/tmp/buildd/probabel-0.4.1/checks' >>> /bin/bash: /bin/bash: cannot execute binary file >>> make[4]: *** [check_probabel.pl_chunk.sh.log] Error 126 >>> make[4]: Leaving directory `/tmp/buildd/probabel-0.4.1/checks' >>> make[3]: *** [check-TESTS] Error 2 >>> make[3]: Leaving directory `/tmp/buildd/probabel-0.4.1/checks' >>> make[2]: *** [check-am] Error 2 >>> make[2]: Leaving directory `/tmp/buildd/probabel-0.4.1/checks' >>> make[1]: *** [check-recursive] Error 1 >>> make[1]: Leaving directory `/tmp/buildd/probabel-0.4.1' >>> dh_auto_test: make -j1 check returned exit code 2 >>> make: *** [build] Error 2 >>> dpkg-buildpackage: error: debian/rules build gave error exit status 2 >>> >>> >>> So it seems the change has introduced a problem with the reconfiguration >>> since if you do >>> >>> $ git diff >>> diff --git a/debian/rules b/debian/rules >>> index 4ece2fa..970e910 100755 >>> --- a/debian/rules >>> +++ b/debian/rules >>> @@ -17,7 +17,7 @@ GIT_TAG:= $(subst ~,_,$(VERSION)) >>> # a similar manner are welcome. >>> >>> %: >>> - dh $@ --parallel --with autoreconf >>> + dh $@ --parallel >>> >>> override_dh_installdocs: >>> dh_installdocs >>> >>> >>> the build works again. >>> >>> Hope this gives some useful hints This is caused by using the new automake 1.13, which uses the parallel test-suite by default, instead of the old serial one. I've committed a quick fix, upstream fixed it more extensively. >> >> >> I'll have a look if I can find what's missing. >> >> By the way, when running debuild I get several lines like: >>awk: cmd. line:1: fatal: cannot open file `debian/gbp.conf' for >> reading (No such file or directory) >> I guess this comes from the variable you try to create in the default >> rules file. I guess the d/gbp.conf file is missing in your default SVN >> debian/ dir. What's supposed to be in that file? > > I personally would remove the variables which are not needed in the > rules files which means remove them all except DEBPKGNAME. They are > just inside the template as an option - perhaps I should put them in > comments. I *personally* do not have any debian/gbp.conf file in my > packages because I'm a fan of keeping things as simple as possible and > additional files are not making anything simpler. But as I said git and > git-buildpackage are not my best skills and so I can only quote our team > policy > >http://debian-med.alioth.debian.org/docs/policy.html#debian-gbp.conf > > where this specific paragraph was written by Charles Plessy. > > In short: I would drop all unneeded variables from the rules file and > be done. Feel free to pick a better solution that might fit your > workflow best. Ah, thanks for mentioning Charles' text. I gues I missed it before. For now I've commented the unused variables. Lennart. > > Kind regards > >Andreas. > -- *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* L.C. Karssen Utrecht The Netherlands lenn...@karssen.org http://blog.karssen.org GPG key ID: A88F554A -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*- signature.asc Description: OpenPGP digital signature
Re: Safe Community Conference in Arusha, Tanzania
On 12/12/13 at 15:47 +0100, Andreas Tille wrote: > On Thu, Dec 12, 2013 at 02:43:34PM +0100, Arne Wichmann wrote: > > Ok, this is interesting but problematic. We are a volunteer based > > organization, and as such funding intercontinental flights is difficult. > > I will forward this mail to different subgroups which might be interested > > in helping out. (I myself would probably not afford it but might come if > > funded.) > > Joost is seriously considering joining and I promised support by giving > the needed information but he also needs sponsorship. If anybody has > an idea how to help him, that would be cool. Hi, Could you provide an estimate of how much money would be required? Also, I would be interested in feedback on whether Debian should fund this. For example, from people who know about PeerCorps, and can confirm that this event is likely to be a success, with a high impact. Lucas -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131213083455.ga30...@xanadu.blop.info
Re: [MoM] ProbABEL packaging
Hi Lennart, On Fri, Dec 13, 2013 at 09:26:52AM +0100, L.C. Karssen wrote: > >> And drags in a whole bunch of dependencies, wow :-). I agree d/control > >> looks better now. > > > > While it looks better it actually does not drag something additional in > > - just reformatting dependencies to have only one per line. > > I meant that installing the packages libconfig-model-dpkg-perl > libconfig-model-itself-perl also drags in a whole bunch of other > packages (at least when using aptitude install, apt-get might have been > more restrictive). I think also apt-get drags some perl dependencies ... > >>> $ git diff > >>> diff --git a/debian/rules b/debian/rules > >>> index 4ece2fa..970e910 100755 > >>> --- a/debian/rules > >>> +++ b/debian/rules > >>> @@ -17,7 +17,7 @@ GIT_TAG:= $(subst ~,_,$(VERSION)) > >>> # a similar manner are welcome. > >>> > >>> %: > >>> - dh $@ --parallel --with autoreconf > >>> + dh $@ --parallel > >>> > >>> override_dh_installdocs: > >>> dh_installdocs > >>> > >>> > >>> the build works again. > >>> > >>> Hope this gives some useful hints > > This is caused by using the new automake 1.13, which uses the parallel > test-suite by default, instead of the old serial one. I've committed a > quick fix, upstream fixed it more extensively. At my side even now the test does not pass. Does your current packaging build in pbuilder (and are you sure you pushed everything)? 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: http://lists.debian.org/20131213083853.gm18...@an3as.eu
Re: Safe Community Conference in Arusha, Tanzania
begin quotation from Lucas Nussbaum (in <20131213083455.ga30...@xanadu.blop.info>): > On 12/12/13 at 15:47 +0100, Andreas Tille wrote: > > On Thu, Dec 12, 2013 at 02:43:34PM +0100, Arne Wichmann wrote: > > > Ok, this is interesting but problematic. We are a volunteer based > > > organization, and as such funding intercontinental flights is difficult. > > > I will forward this mail to different subgroups which might be interested > > > in helping out. (I myself would probably not afford it but might come if > > > funded.) > > > > Joost is seriously considering joining and I promised support by giving > > the needed information but he also needs sponsorship. If anybody has > > an idea how to help him, that would be cool. > Could you provide an estimate of how much money would be required? > > Also, I would be interested in feedback on whether Debian should fund > this. For example, from people who know about PeerCorps, and can confirm > that this event is likely to be a success, with a high impact. Ok, first a +1 to Andreas comment - reaching out to the (trustgraphwise) unconnected millions in Africa is a good argument. One question to me is if the one person in Africa could not be made to go to Tanzania - it would not be so far away from him. I do not know about PeerCorps and what this event is. But Africa is the least known Continent to me. So, to relate this to Debian: there is a continent of people there who has little connection to Debian and could possibly use it very well, which might help either Debian and the people there. If this conference is an anchor to change this I would be very willing to go there. If Joost wants to go there even better, as he probably is more central to Debian than me. cu AW -- [...] If you don't want to be restricted, don't agree to it. If you are coerced, comply as much as you must to protect yourself, just don't support it. Noone can free you but yourself. (crag, on Debian Planet) Arne Wichmann (a...@linux.de) signature.asc Description: Digital signature
Re: [MoM] ProbABEL packaging
Hi Andreas, On 13-12-13 09:38, Andreas Tille wrote: > Hi Lennart, > > > $ git diff > diff --git a/debian/rules b/debian/rules > index 4ece2fa..970e910 100755 > --- a/debian/rules > +++ b/debian/rules > @@ -17,7 +17,7 @@ GIT_TAG:= $(subst ~,_,$(VERSION)) > # a similar manner are welcome. > > %: > - dh $@ --parallel --with autoreconf > + dh $@ --parallel > > override_dh_installdocs: > dh_installdocs > > > the build works again. > > Hope this gives some useful hints >> >> This is caused by using the new automake 1.13, which uses the parallel >> test-suite by default, instead of the old serial one. I've committed a >> quick fix, upstream fixed it more extensively. > > At my side even now the test does not pass. Does your current packaging > build in pbuilder (and are you sure you pushed everything)? Ah, my bad. I Ran the wrong pbuilder (Ubuntu). Debian Wheezy doesn't have the new automake yet. Is there a way to tell quilt to skip a patch (instead of removing it)? That way I could test whether not applying the patch to autoconf.ac works on Wheezy. Thanks, Lennart. > > Kind regards > >Andreas. > -- *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* L.C. Karssen Utrecht The Netherlands lenn...@karssen.org http://blog.karssen.org GPG key ID: A88F554A -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*- signature.asc Description: OpenPGP digital signature
Re: [MoM] ProbABEL packaging
Hi Lennart,
On Fri, Dec 13, 2013 at 10:24:41AM +0100, L.C. Karssen wrote:
> > At my side even now the test does not pass. Does your current packaging
> > build in pbuilder (and are you sure you pushed everything)?
>
> Ah, my bad. I Ran the wrong pbuilder (Ubuntu). Debian Wheezy doesn't
> have the new automake yet.
> Is there a way to tell quilt to skip a patch (instead of removing it)?
The only way I see is to comment it out ('#') in debian/patches/series
but this would involve manual editing for different target
distributions.
> That way I could test whether not applying the patch to autoconf.ac
> works on Wheezy.
May be we are now touching the end of my knowledge-stack. If you are
curious about this it usually helps to ask on
debian-ment...@lists.debian.org (and my MoM task is also to introduce
you into this very valuable resource of knowledge).
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: http://lists.debian.org/20131213121701.gp18...@an3as.eu
Re: [MoM] ProbABEL packaging
Hi Lennart, since your last commit probabel builds for me nicely. I think this is a good point in time to create a WNPP bug (using reportbug wnpp). There is also the warning about arch-dep-package-has-big-usr-share 11103kB 91% After having a look into /usr/share/probabel/examples and /usr/share/probabel/tests I think we can clearly see where this comes from. I would split up these both directories into a separate `Architecture: all` package. If the directories might be needed for day to day work these should go into probabel-data and probabel should depend from this package. Alternatively if these are only examples and perhaps a unit test it could go into probabel-examples and probabel should only Suggests this package. If the nature of the directories might be really different you could put examples into an extra probabel-examples package and the tests into probabel-test (or probabel-data). It basically depends from your specific knowledge what might be the best solution here. Hope this helps 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: http://lists.debian.org/20131213130640.gq18...@an3as.eu
Re: [MoM] ProbABEL packaging
Hi Andreas, On 13-12-13 14:06, Andreas Tille wrote: > Hi Lennart, > > since your last commit probabel builds for me nicely. I think this is a > good point in time to create a WNPP bug (using reportbug wnpp). That's good news! I'll do that probably later today. > > There is also the warning about > > arch-dep-package-has-big-usr-share 11103kB 91% > > After having a look into /usr/share/probabel/examples and > /usr/share/probabel/tests I think we can clearly see where this comes > from. I would split up these both directories into a separate > `Architecture: all` package. If the directories might be needed for day > to day work these should go into probabel-data and probabel should > depend from this package. I think it is best to get rid of the tests directory. These are only used when running make check, so not interesting for the end user. The data in the examples directory is of interest to the user. If removing tests is enough, I'll leave it at that. Otherwise I'll try to make a separate probabel-example package. Best, Lennart. > > Alternatively if these are only examples and perhaps a unit test it > could go into probabel-examples and probabel should only Suggests > this package. If the nature of the directories might be really > different you could put examples into an extra probabel-examples > package and the tests into probabel-test (or probabel-data). It > basically depends from your specific knowledge what might be the > best solution here. > > Hope this helps > > Andreas. > -- - L.C. Karssen Utrecht The Netherlands lenn...@karssen.org http://blog.karssen.org Stuur mij aub geen Word of Powerpoint bestanden! Zie http://www.gnu.org/philosophy/no-word-attachments.nl.html -- signature.asc Description: OpenPGP digital signature
Re: [MoM] ProbABEL packaging
Hi Lennart, On Fri, Dec 13, 2013 at 04:05:36PM +0100, L.C. Karssen wrote: > > since your last commit probabel builds for me nicely. I think this is a > > good point in time to create a WNPP bug (using reportbug wnpp). > > That's good news! I'll do that probably later today. :-) > > There is also the warning about > > > > arch-dep-package-has-big-usr-share 11103kB 91% > > > > After having a look into /usr/share/probabel/examples and > > /usr/share/probabel/tests I think we can clearly see where this comes > > from. I would split up these both directories into a separate > > `Architecture: all` package. If the directories might be needed for day > > to day work these should go into probabel-data and probabel should > > depend from this package. > > I think it is best to get rid of the tests directory. These are only > used when running make check, so not interesting for the end user. OK. > The > data in the examples directory is of interest to the user. If removing > tests is enough, I'll leave it at that. Otherwise I'll try to make a > separate probabel-example package. I'd recommend a separate examples package since it is in principle quite easy to create (we have *lots* of examples in Vcs) and there are several advantages to split this from the main program (if you might be curious about these examples I could give a short list). 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: http://lists.debian.org/20131213152609.gb21...@an3as.eu
looking for a review for pycorrfit
Hi All, I am looking for a review for my package pycorrfit [0], ITP #730640. Lintian is clear, but I am pretty sure there are hidden issues :) Also I am not sure what to do with png images in doc-src/Images directory. There are svg files as well, but I haven't managed to correctly convert the svg files to png. It would be great if you would give me ideas or examples. Thanks, Alex [0] http://anonscm.debian.org/gitweb/?p=debian-med/pycorrfit.git;a=summary -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52ab2a57.1040...@biotec.tu-dresden.de
Bug#732082: RM: ugene/experimental -- ROM; Package moves from main to nonfree
Package: ftp.debian.org Severity: normal We uploaded a new vesion of ugene, which moved to non-free. This created a db integrity error when ftp master accepted the package. I have been asked to create a rm bug to remove the package first before getting it accepted in unstable/non-free. I am co-maintainer of the package with the DebianMed team Thanks -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131213173308.8930.99347.report...@debiansid.genouest.org
Re: looking for a review for pycorrfit
Hi Alex, On Fri, Dec 13, 2013 at 04:40:07PM +0100, Alex Mestiashvili wrote: > Hi All, > > I am looking for a review for my package pycorrfit [0], ITP #730640. > Lintian is clear, but I am pretty sure there are hidden issues :) Since I have no idea neither data to use this package I'm probably not the best reviewer. From my perspective it seems OK. > Also I am not sure what to do with png images in doc-src/Images directory. > There are svg files as well, but I haven't managed to correctly > convert the svg files to png. > It would be great if you would give me ideas or examples. I'm not sure what upstream is intending with these files but I would trust that the install mechanism does reasonable things. When starting the program at least the help menu displays an image. There are several different image sizes under /usr/share/icons/hicolor which are used by various desktop systems (which I not use). 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: http://lists.debian.org/20131213223607.gb25...@an3as.eu
bedtools version 2.18.0
Le Fri, Dec 13, 2013 at 12:33:18PM -0500, Aaron Quinlan a écrit : > > It has been over a year since the last bedtools release, and as such, we are > happy to roll out version 2.18. There are several changes in this new release > and the credit for all of the new (the result of a lot of hard work on his > end) and forthcoming functionality goes to Neil Kindlon in my lab. The full > details of the release can be found here: > > http://quinlanlab.org/software-releases/bedtools-2.18.html Hello everybody, today BEDTools version 2.18 was released, this is great news. Anybody, please feel free to update our package. I started to inspect the source, and found that for some PNG images of the documentation, we have the SVG source and for some we have not. Moreover, there is no explanation on how to rebuild the PNG from source. Personally, I have no problem with this. I also have the feeling that a couple of years ago, it would not have been a problem. However, I have the impression that now it is important for Debian that images are rebuild from their source. I am just too tired to do this. Maybe too much years as a packager eroded my motivation. I want to deliver software, not to nitpick on upstream sources. So anybody, please feel free to update our bedtools package. Cheers, -- 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: http://lists.debian.org/20131214015926.gb19...@falafel.plessy.net
Re: bedtools version 2.18.0
Hi Charles, On Sat, Dec 14, 2013 at 10:59:26AM +0900, Charles Plessy wrote: > > Personally, I have no problem with this. I also have the feeling that a > couple > of years ago, it would not have been a problem. However, I have the > impression that now it is important for Debian that images are rebuild from > their source. I do not think that this is a real problem for PNGs. At least I had never personally any problem with PNGs. > I am just too tired to do this. Maybe too much years as a packager eroded my > motivation. I want to deliver software, not to nitpick on upstream sources. > > So anybody, please feel free to update our bedtools package. Assuming we would simply ignore the PNG (non) issue, would you update the package or are there other reasons that keep you away? 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: http://lists.debian.org/20131214074702.gd25...@an3as.eu
