Re: Orthanc 1.1.0
OK, it has just been accepted ;) Sébastien- On 07/11/2016 08:12 AM, Sebastien Jodogne wrote: Hi Andreas, Would it be possible that there was a problem with the upload? It seems that the 1.1.0+dfsg-2 version is not available yet on unstable. Thanks for your support, Sébastien- On 07/09/2016 01:36 PM, Andreas Tille wrote: Uploaded and tagged (sorry for missing to push and tag changes for last version). Thanks for your work on this, Andreas.
Re: Orthanc 1.1.0
Hi, I somehow missed to dput the final build. Its done now. Sorry for the delay, Andreas. On Mon, Jul 11, 2016 at 08:12:16AM +0200, Sebastien Jodogne wrote: > Hi Andreas, > > Would it be possible that there was a problem with the upload? It seems that > the 1.1.0+dfsg-2 version is not available yet on unstable. > > Thanks for your support, > Sébastien- > > > On 07/09/2016 01:36 PM, Andreas Tille wrote: > >Uploaded and tagged (sorry for missing to push and tag changes for last > >version). > >Thanks for your work on this, Andreas. > > > >>I have just pushed an important fix for FTBFS issue #829608: > >>http://anonscm.debian.org/cgit/debian-med/orthanc.git/commit/?id=8d9cbc2f8b4c8d6395ad59cee45ba92adf39b447 > -- http://fam-tille.de
Do you have popularity-contest set to yes?
Hi folks when looking at our tasks pages I'm noticing several package with 0 installations reportet. Assuming that at least the person who uploaded the package has one installation I'm wondering, whether you all have set popularity contest to submit installation data. Since it would be very helpful to get some numbers of installations please make sure you call sudo dpkg-reconfigure popularity-contest and check "yes" in case you have no good reasons to not submit the data. (I'd be interested to hear good reasons not to submit.) Thanks for considering Andreas. -- http://fam-tille.de
Re: Do you have popularity-contest set to yes?
Hi Andreas,
> when looking at our tasks pages I'm noticing several package with 0
> installations reportet.
I looked at one of these that looks familiar to me and that I have been
tracking in my DDPO for quite a while (Artemis), and DDPO shows 16
installations. Could it be that the tasks pages show the numbers for
regularly used ('vote') or recently upgraded ('recent') installations
only? Looking at these numbers for Artemis they indeed are 0.
I guess that for bioinformatics packages using these as the visible
popcon counts on the tasks page might skew the numbers a bit.
I can imagine that one wouldn't use some of these tools every single day
(or even regularly)...
Cheers
Sascha
(And yes, I have popcon reporting enabled on all my machines :))
--
The Wellcome Trust Sanger Institute is operated by Genome Research
Limited, a charity registered in England with number 1021457 and a
company registered in England with number 2742969, whose registered
office is 215 Euston Road, London, NW1 2BE.
Re: Do you have popularity-contest set to yes?
Hi Andreas, on my side I bought a new laptop last year, so for some packages that I uploaded long time ago and that have not been very active or useful recently, I probably do not count in popcon anymore. Have a nice day, Charles -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan
Re: Do you have popularity-contest set to yes?
On Mon, Jul 11, 2016 at 12:06:24PM +0100, Sascha Steinbiss wrote:
> Hi Andreas,
>
> > when looking at our tasks pages I'm noticing several package with 0
> > installations reportet.
>
> I looked at one of these that looks familiar to me and that I have been
> tracking in my DDPO for quite a while (Artemis), and DDPO shows 16
> installations. Could it be that the tasks pages show the numbers for
> regularly used ('vote') or recently upgraded ('recent') installations
> only? Looking at these numbers for Artemis they indeed are 0.
Yes, I think what we really want to know are the regularly used packages.
> I guess that for bioinformatics packages using these as the visible
> popcon counts on the tasks page might skew the numbers a bit.
> I can imagine that one wouldn't use some of these tools every single day
> (or even regularly)...
I think the votes are sensible since by using the metapackages chances
are good that people install a lot of our packages as dependencies. But
what we really want to know is whether software is used in real life
IMHO.
> (And yes, I have popcon reporting enabled on all my machines :))
Very good.
Kind regards
Andreas.
--
http://fam-tille.de
Re: Heads up: bioperl release candidate
Le Thu, Jul 07, 2016 at 10:20:18AM -0400, Michael Crusoe a écrit : > > If someone would like to try updating the Debian package with the release > candidate and testing it that would be useful: > > https://cpan.metacpan.org/authors/id/C/CJ/CJFIELDS/BioPerl-1.007000_003.tar.gz Hi Michael and everybody, I tested the packaging of /BioPerl-1.007000_004.tar.gz, and it went fine. Some regression tests could not be run as not all the optional modules and software were installed on my laptop. Our automated test did not report anything significant. Here is a copy of the typos it found. I: bioperl: spelling-error-in-manpage usr/share/man/man1/bp_biogetseq.1p.gz retrives retrieves I: bioperl: spelling-error-in-manpage usr/share/man/man1/bp_extract_feature_seq.1p.gz specifed specified I: bioperl: spelling-error-in-manpage usr/share/man/man1/bp_hivq.1p.gz retreive retrieve I: bioperl: spelling-error-in-manpage ... use --no-tag-display-limit to see all (or pipe to a file/program) W: bioperl: manpage-has-bad-whatis-entry usr/share/man/man1/bp_netinstall.1p.gz W: bioperl: manpage-has-bad-whatis-entry usr/share/man/man1/bp_search2gff.1p.gz W: bioperl: manpage-has-bad-whatis-entry usr/share/man/man1/bp_seqcut.1p.gz I: libbio-perl-perl: spelling-error-in-manpage usr/share/man/man3/Bio::Align::AlignI.3pm.gz wont won't I: libbio-perl-perl: spelling-error-in-manpage usr/share/man/man3/Bio::AnalysisI.3pm.gz refrence reference I: libbio-perl-perl: spelling-error-in-manpage usr/share/man/man3/Bio::AnalysisI.3pm.gz folowing following I: libbio-perl-perl: spelling-error-in-manpage ... use --no-tag-display-limit to see all (or pipe to a file/program) W: libbio-perl-perl: manpage-has-bad-whatis-entry usr/share/man/man3/Bio::Index::Stockholm.3pm.gz W: libbio-perl-perl: manpage-has-bad-whatis-entry usr/share/man/man3/Bio::OntologyIO::Handlers::BaseSAXHandler.3pm.gz W: libbio-perl-perl: manpage-has-bad-whatis-entry usr/share/man/man3/Bio::OntologyIO::obo.3pm.gz W: libbio-perl-perl: manpage-has-bad-whatis-entry ... use --no-tag-display-limit to see all (or pipe to a file/program) W: libbio-perl-perl: manpage-has-errors-from-man usr/share/man/man3/Bio::SeqIO::bsml.3pm.gz 361: warning [p 4, 0.2i]: can't break line Have a nice day, Charles -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan
Re: [ftpmas...@ftp-master.debian.org: mypy_0.4.1-2_amd64.changes REJECTED]
Yeah, -dev is inappropriate; we aren't compiling a custom module. Something broke with the Python packages in unstable. Using python*-dev leads to I: mypy source: build-depends-on-python-dev-with-no-arch-any N: N:The given package appears to have a Python development package N:(python-dev, python-all-dev or pythonX.Y-dev) listed in its N:Build-Depends or Build-Depends-Indep fields, but only "Architecture: N:all" packages are built by this source package. Python applications and N:modules do not usually require those dev packages, so you should N:consider removing them in favour of python, python-all or pythonX.Y. N: N:If you are building a Python extension instead, you should have N:development packages listed in Build-Depends, but normally there should N:be at least one Architecture: any package. N: N:Severity: minor, Certainty: possible N: N:Check: fields, Type: binary, udeb, source N: I had previously uploaded a 0.4.2-2 but the build failed due to this transient error elsewhere: https://buildd.debian.org/status/package.php?p=mypy How do I request a new build? On Mon, Jul 11, 2016 at 9:04 AM, Andreas Tille wrote: > Hi Michael, > > I'm happy that others are suffering from the same disease to forget to > push latest status. ;-) > > Could you please commit your latest changes and perhaps apply the changes > I did to fix #830743? > > Kind regards > > Andreas. > > - Forwarded message from Debian FTP Masters < > ftpmas...@ftp-master.debian.org> - > > Date: Mon, 11 Jul 2016 13:19:39 + > From: Debian FTP Masters > To: Debian Med Packaging Team < > debian-med-packag...@lists.alioth.debian.org>, Andreas Tille < > ti...@debian.org> > Subject: mypy_0.4.1-2_amd64.changes REJECTED > > > > Version check failed: > Your upload included the source package mypy, version 0.4.1-2, > however unstable already has version 0.4.2-1. > Uploads to unstable must have a higher version than present in unstable. > > === > > Please feel free to respond to this email if you don't understand why > your files were rejected, or if you upload new files which address our > concerns. > > > ___ > Debian-med-packaging mailing list > debian-med-packag...@lists.alioth.debian.org > > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging > > > - End forwarded message - > > -- > http://fam-tille.de > -- Michael R. Crusoe Community Engineer & Co-founder Common Workflow Language project https://impactstory.org/u/-0002-2961-9670 michael.cru...@gmail.com +32 (0) 2 808 25 58 +1 480 627 9108
Re: [ftpmas...@ftp-master.debian.org: mypy_0.4.1-2_amd64.changes REJECTED]
On Mon, Jul 11, 2016 at 10:02:11AM -0500, Michael Crusoe wrote: > Yeah, -dev is inappropriate; we aren't compiling a custom module. Something > broke with the Python packages in unstable. > > Using python*-dev leads to > > I: mypy source: build-depends-on-python-dev-with-no-arch-any > N: > N:The given package appears to have a Python development package > N:(python-dev, python-all-dev or pythonX.Y-dev) listed in its > N:Build-Depends or Build-Depends-Indep fields, but only "Architecture: > N:all" packages are built by this source package. Python applications > and > N:modules do not usually require those dev packages, so you should > N:consider removing them in favour of python, python-all or pythonX.Y. > N: > N:If you are building a Python extension instead, you should have > N:development packages listed in Build-Depends, but normally there > should > N:be at least one Architecture: any package. > N: > N:Severity: minor, Certainty: possible > N: > N:Check: fields, Type: binary, udeb, source > N: I noticed this lintian issue but trading a lintian information for a FTBFS error is fair, isn't it? > I had previously uploaded a 0.4.2-2 but the build failed due to this > transient error elsewhere: > https://buildd.debian.org/status/package.php?p=mypy > > How do I request a new build? Hmmm, is there any need for a new build? If the package builds now fine as is (which I did not tested) I would write this insied the bug report (not reproducible any more). Kind regards Andreas. -- http://fam-tille.de
Re: [ftpmas...@ftp-master.debian.org: mypy_0.4.1-2_amd64.changes REJECTED]
Pe 11 iul. 2016 11:17, "Andreas Tille" a scris: > > On Mon, Jul 11, 2016 at 10:02:11AM -0500, Michael Crusoe wrote: > > Yeah, -dev is inappropriate; we aren't compiling a custom module. Something > > broke with the Python packages in unstable. > > > > Using python*-dev leads to > > > > I: mypy source: build-depends-on-python-dev-with-no-arch-any > > N: > > N:The given package appears to have a Python development package > > N:(python-dev, python-all-dev or pythonX.Y-dev) listed in its > > N:Build-Depends or Build-Depends-Indep fields, but only "Architecture: > > N:all" packages are built by this source package. Python applications > > and > > N:modules do not usually require those dev packages, so you should > > N:consider removing them in favour of python, python-all or pythonX.Y. > > N: > > N:If you are building a Python extension instead, you should have > > N:development packages listed in Build-Depends, but normally there > > should > > N:be at least one Architecture: any package. > > N: > > N:Severity: minor, Certainty: possible > > N: > > N:Check: fields, Type: binary, udeb, source > > N: > > I noticed this lintian issue but trading a lintian information for a > FTBFS error is fair, isn't it? Lintian is correct, so no issue there :-) > > I had previously uploaded a 0.4.2-2 but the build failed due to this > > transient error elsewhere: > > https://buildd.debian.org/status/package.php?p=mypy > > > > How do I request a new build? > > Hmmm, is there any need for a new build? If the package builds now fine > as is (which I did not tested) I would write this insied the bug report > (not reproducible any more). Yes a new build is needed, there are no binary packages; I did a source only upload. It builds for me in an updated pbuilder chroot but I don't know how to trigger the build daemons to try again. > Kind regards > >Andreas. > > -- > http://fam-tille.de >
Re: Daily Report [29.06.16] [GSOC]
Hi Canberk, any success with clustalo? Kind regards Andreas. On Mon, Jul 04, 2016 at 12:27:03PM +0300, Canberk Koç wrote: > Hello Andreas, > > I am going on to work. But this week is official holiday(ramadan feast) in > here so i will be silent for 3 4 days then i double work for weekend. > > Best Regards > > Canberk Koç > www.about.me/canberkkoc > 4 Tem 2016 11:27 tarihinde "Andreas Tille" yazdı: > > > Hi Canberk, > > > > >vcftool > > >phyml > > >dialign > > > > since you succeeded with vcftool I'd like to put the next items on the > > list: > > > > phyml > > dialign > > clustalo(will be moved from SVN to Git soon) > > clustalw > > > > Kind regards > > > >Andreas. > > > > -- > > http://fam-tille.de > > > > -- http://fam-tille.de
