Bug#851468: ITP: python-galaxyxml -- XML Generation libraries for Galaxy Tool/ToolDeps XML
Package: wnpp Severity: wishlist Owner: anton.kho...@ukr.net * Package name: python-galaxyxml Version : 0.1 Upstream Author : Eric Rasche * URL : https://github.com/erasche/galaxyxml * License : Apache-2.0 Programming Lang: Python Description : XML Generation libraries for Galaxy Tool/ToolDeps XML Galaxy XML Generation Libraries support building of Tool XML and Tool Dependencies XML. The package is the dependency for argparse2tool. Remark: This package will be maintained bz the Debian Med team at https://anonscm.debian.org/git/debian-med/python-galaxyxml.git
Bug#851476: ITP: mate-calc -- MATE desktop calculator
Package: wnpp Severity: wishlist Owner: Mike Gabriel * Package name: mate-calc Version : 1.17.0 Upstream Author : Martin Wimpress * URL : https://git.mate-desktop.org/mate-calc/ * License : GPL-2+ Programming Lang: C Description : MATE desktop calculator mate-calc is a powerful graphical calculator with financial, logical and scientific modes. It uses a multiple precision package to do its arithmetic to give a high degree of accuracy. . MATE calc had for a long time been substituted by GNOME's calcular application. For upcoming MATE 2.0, MATE resurrected the original calculator support, ported it to GTK-3 and now ships its own calculator with the MATE desktop environment. . The package will be maintained by the Debian MATE Packaging Team and the Ubuntu MATE Team.
Re: Bug#851306: ITP: freebayes -- Bayesian haplotype-based polymorphism discovery and genotyping
Hi Scott, On Fri, Jan 13, 2017 at 04:09:01PM -0500, Scott Kitterman wrote: > > "freebayes" seems like a very generic name for something specific to such a > narrow field. Maybe freebayes-genetic-variance or some such instead. I fully agree with your generic name consideration. The software is well known in this work field anyway so I'm hesitating a bit to rename it. Would you consider this a strong issue that needs to be discussed with upstream or is it in a "not nice but acceptable" status? Kind regards Andreas. -- http://fam-tille.de
Re: Debian Installer Stretch RC 1 release
On 15.01.2017 05:21, Cyril Brulebois wrote: > The Debian Installer team[1] is pleased to announce the first release > candidate of the installer for Debian 9 "Stretch". > > > Important changes in this release of the installer > == > > * [...] > * As noted in the Stretch Alpha 6 release announcement, Debian Pure >Blends appeared in the Software selection screen. Unfortunately, >concerns voiced back then weren't worked on until after the freeze >started, and a freeze isn't the time where critical screens should >be revamped. Support was disabled accordingly. Since this is still an open discussion in #846002, I would have preferred if you would not try to force your own preference here before the CTTE made its decision. IMO your solution is not in any way cooperative and tries to make the CTTE decision useless. I therefore would ask the CTTE to make a final decision about the inclusion of the blends selection in the Stretch installer. In principle these are *two* decisions: 1. Appearance of the blends in the installer: Please decide, whether * the blends shall be shown in their current (alpha-8) form * The installer is extended to show the desktop and the blends only optionally (as propagated by Phil, and opposed by Cyril) * the blends should not appear in the Stretch installer at all. 2. Maintenance of the blends tasks appearing in the installer: * in a separate package maintained by the blends team * integrated into tasksel and maintained by d-i * be removed completely from the installation process Best regards Ole
Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS
Steve Langasek writes: > On Sat, Jan 14, 2017 at 11:05:48AM +0100, Ole Streicher wrote: >> > One other thing that I can envision (but maybe to early to agree on or >> > set in stone) is that we lower the NMU criteria for fixing (or >> > temporarily disabling) autopkgtest in ones reverse dependencies. In >> > the end, personally I don't think this is up to the "relevant >> > maintainers" but up to the release team. And I assume that badly >> > maintained autopkgtest will just be a good reason to kick a package >> > out of testing. > >> I already brought an example where autopkgtest ist well maintained but >> keeps failing. > >> And I think that it is the package maintainers who have the experience >> of whether a CI test failure is critical or not. > > If the failure of the test is not critical, then it should not be used as a > gate for CI. Which means you, as the package maintainer who knows that this > test failure is not critical, should fix your autopkgtest to not fail when > the non-critical test case fails. Again: astropy (as an example) has 9000 tests, designed by a quite large upstream team. There is no realistic way to proactively decide which of these is critical and which not. At the end I would have to decide whether to make any of those tests fail, or none. > Quite to the contrary of the claims in this thread that gating on > autopkgtests will create a bottleneck in the release team for overriding > test failures, this will have the effect of holding maintainers accountable > for the state of their autopkgtest results. CI tests are only useful if you > have a known good baseline. If your tests are flaky, or otherwise produce > failures that you think don't matter, then those test results are not useful > than anyone but yourself. Please help us make the autopkgtests useful for > the whole project. I use autopkgtests for the majority of my packages, and they are very useful. Just to bring my experience from the last days: I uploaded a new upstream version of astropy, also removed an internal version of pytest (2.X) that was accidentally overseen before. This caused a number of rdependent failures: 1. the new astropy version ignores the "remote_data" option in its test infrastructure, which causes rdeps to fail if they have (optional) remote tests which previously were disabled by this option. This bug is clearly a regression of astropy. However since it does not affect the normal work of the package but only the test infrastructure, and there is a workaround for the affected packages, it is not really RC. 2. Since now the Debian version of pytest is to be used (which is 3.0.5), deprecation warnings appear for the packages that use the astropy test framework, causing the tests to fail. This is not a regression of astropy, but also not RC for the affected rdeps: I am even not sure whether one should allow-stderr here, since this would just hide the problem. Instead, I would prefer creating bugs upstream. Since in the specific case they don't expect the switch to 3.0.5, this may take some time. In the meantime, the packages are perfectly usable, until pytest upstream decided to remove the deprecated stuff. >From my experience, a large amount of CI test failures are not due to bugs in the package itself, but in the test code. Then, especially if one runs a large test suite, many of the tests check some corner cases which rarely appear in the ordinary work of the package. Sure, both needs to be fixed, but it is not RC: the package will work fine for most people -- at least, in Debian we don't have a policy that *any* identified bug is RC. I prefer to have CI tests as an indicator of *possible* problems with the package, so they should start to ring a bell *before* something serious happens. > And the incentive for maintainers to keep their autopkgtests in place > instead of removing them altogether is that packages with succeeding > autopkgtests can have their testing transition time decreased from the > default. (The release team agreed to this policy once upon a time, but I'm > not sure if this is wired up or if that will happen as part of Paul's > work?) Hmm. Often the CI tests are more or less identical with the build time tests, so that passing CI tests is not really a surprise. And we are discussion here a different case: that rdependencies need to have passing CIs. > The result of the autopkgtest should be whatever you as the maintainer think > is the appropriate level for gating. Frankly, I think it's sophistry to > argue both that you care about seeing the results of the tests, and that you > don't want a failure of those tests to gate because they only apply to > "special cases". I just want to keep the possibilities as they are for other reported problems: reassing to the correct package, change severity, forward to upstream, keep the discussion etc. I just want them as ordinary bugs. Again: we have a powerful system that shows what is needed to do with a package, an
Re: "not authorised" doing various desktoppy things [and 1 more messages]
tl;dr
TYVM to Michael Biebl
I intend QA upload of systemd-shim with Michael's wrapper
Michael Biebl writes ("Re: "not authorised" doing various desktoppy things [and
1 more messages]"):
> Am 05.01.2017 um 19:56 schrieb Michael Biebl:
> > Then copy the attached wrapper script to /usr/lib/x86_64-linux-gnu/
> > and make it executable.
>
> Obviously, the wrapper script should start systemd-shim.orig.
Well, I only previously glanced at this script. I thought it was a
way to collect more information. Now that I sit down to deal with
this problem properly, I discover that actually it fixes the problem!
Thank you very much (and I'm sorry now that I was a bit avoidant about
trying this, thinking that it would be part of a big and stressy
debugging and spelunking session).
Correct me if I'm wrong, but I think the right thing is probably to do
is ship this comaptibility workaround in stretch. I looked on my
system and filesystems of type cgroup are not mounted anywhere else.
And I'm not sure what is using /sys/fs/cgroup/systemd but it doesn't
seem to be systemd-shim. I guess then that this is something that
used to be done by one bit of systemd and is now done by another bit,
so that it now has to also be done by systemd-shim ?
So my plan is to do a QA upload of systemd-shim which includes a
variant of your wrapper script (perhaps with set -e added...). I
looked at the code in systemd-shim and implementing this code in its C
code doesn't look very convenient. (It's also possible that this
should be done in an init script but I haven't considered that
properly.)
I haven't decided whether to put give the wrapper the name
`/usr/lib/x86_64-linux-gnu/systemd-shim' as you did, or alternatively
whether to give it a new name and change the reference in
/usr/share/dbus-1/system-services/org.freedesktop.systemd1.service
Unless anyone has an opinion I'll do whatever is easier.
More news later today.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Bug#851488: ITP: python-gffutils -- Work with GFF and GTF files in a flexible database framework
Package: wnpp Severity: wishlist Owner: Debian Med team * Package name: python-gffutils Version : 0.8.7.1 Upstream Author : Ryan Dale * URL : http://daler.github.io/gffutils/ * License : MIT Programming Lang: Python Description : Work with GFF and GTF files in a flexible database framework A Python package for working with and manipulating the GFF and GTF format files typically used for genomic annotations. Files are loaded into a sqlite3 database, allowing much more complex manipulation of hierarchical features (e.g., genes, transcripts, and exons) than is possible with plain-text methods alone. Dependency of bcbio, to be team maintained by Debian Med
Re: Bug#851306: ITP: freebayes -- Bayesian haplotype-based polymorphism discovery and genotyping
On January 15, 2017 7:32:32 AM EST, Andreas Tille wrote: >Hi Scott, > >On Fri, Jan 13, 2017 at 04:09:01PM -0500, Scott Kitterman wrote: >> >> "freebayes" seems like a very generic name for something specific to >such a >> narrow field. Maybe freebayes-genetic-variance or some such instead. > >I fully agree with your generic name consideration. The software is >well known in this work field anyway so I'm hesitating a bit to rename >it. Would you consider this a strong issue that needs to be discussed >with upstream or is it in a "not nice but acceptable" status? I think it should be discussed with upstream, but we have broader namespace considerations that they may not understand or care about. As long as a package search for freebayes returns this in the result set, I don't think it's critical to have the package name match exactly the upstream name. Not wearing my FTP team hat for this, consider it as a comment from another DD. Scott K
Re: "not authorised" doing various desktoppy things [and 1 more messages]
Ian Jackson writes ("Re: "not authorised" doing various desktoppy things [and 1
more messages]"):
> More news later today.
I have just uploaded systemd-shim 10-3~exp1 to experimental. I seems
to fix the problem for me. Depending on feedback, I will upload this
to sid in the next few days.
Thanks,
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: Bug#851306: ITP: freebayes -- Bayesian haplotype-based polymorphism discovery and genotyping
Hi Scott, On Sun, Jan 15, 2017 at 04:34:40PM +, Scott Kitterman wrote: > >I fully agree with your generic name consideration. The software is > >well known in this work field anyway so I'm hesitating a bit to rename > >it. Would you consider this a strong issue that needs to be discussed > >with upstream or is it in a "not nice but acceptable" status? > > I think it should be discussed with upstream, but we have broader namespace > considerations that they may not understand or care about. Definitely. > As long as a package search for freebayes returns this in the result set, I > don't think it's critical to have the package name match exactly the upstream > name. Do you care only about the *package* name or do you care as well about the name binary /usr/bin/freebayes? > Not wearing my FTP team hat for this, consider it as a comment from another > DD. Both is welcome. Kind regards Andreas. -- http://fam-tille.de
Re: Test instance of our infrastructure
On 2017-01-14 10:55:14 +0100 (+0100), Bálint Réczey wrote: [...] > Providing a puppet module could be a criterion for accepting new > services [...] This is how we do it for the OpenStack community infrastructure. If you're proposing a new service, automate its deployment with a Puppet module or convince someone with an interest in the proposed service to help you write one which does. Most of our Infra team regulars are too busy to do that sort of work on request, and it's really not that much extra overhead for the proposer. It also increases the number of community members familiar with how we maintain the services they use, and so broadens the pool of potential future contributors to related efforts. -- Jeremy Stanley signature.asc Description: Digital signature
Re: Trademark issues (Was: kronatools_2.7+dfsg-1_amd64.changes REJECTED)
Hi again,
I admit I feel a bit blocked. Should I simply upload with another
possibly improperly choosen name and wait for ftpmaster comments to the
upload in new? It seems this topic does not deserve any additional
input and thus I might take this potential detour without further
discussion. :-(
Kind regards
Andreas.
On Fri, Dec 16, 2016 at 09:21:06PM +0100, Andreas Tille wrote:
> Hi Ian,
>
> On Fri, Dec 16, 2016 at 12:43:37AM +, Ian Jackson wrote:
> > Andreas Tille writes ("Re: kronatools_2.7+dfsg-1_amd64.changes REJECTED"):
> > >
> > > Thanks for your torough checking. As discussed long ago[2]
> > >
> > > "KronaTools" may work, since the actual trademark is just
> > > "Krona". You could also use "Radiant", which was the original name
> > > (and still in SourceForge with a redirect). We avoided Radiant so
> > > our name could be trademarked, but you wouldn't have that problem
> > > I'm guessing.
> >
> > The upstream you are dealing with, here, clearly don't really
> > understand trademarks very well.
>
> ... which makes a perfect match between me and upstream. I naively
> assumed that the argument given by upstream should be valid to combine
> two quite generic words is something else than a trademarked word.
>
> > If "krona" is trademarked (and that
> > DHS page claims it is) then "kronatools" would clearly be a breach.
> >
> > You'll have to call it something without the word "krona" in.
>
> I simply have to trust your insight here.
>
> > > It would help to hear other opinions before trying another upload to
> > > new: What name do you think is a proper name for this project in Debian.
> >
> > I haven't been able to figure out what this program does. Your links
> > don't give your own Description and the upstream say:
> >
> > Krona Tools is a set of scripts to create Krona charts from several
> > Bioinformatics tools as well as from text and XML files.
>
> The ITPed package description reads:
>
> Description: explore hierarchical metagenomic data with zoomable pie charts
> Krona allows hierarchical data to be explored with zoomable pie charts.
> Krona charts include support for several bioinformatics tools and raw
> data formats. The charts can be viewed with a recent version of any
> major web browser.
>
> The Wiki page[1] has some enlightening examples.
>
> > Either this is circular, or "Krona chart" was a medical (or
> > medico-informatical) term before this software existed and it
> > shouldn't have been trademarked (although I doubt anyone wants to
> > fight that).
>
> I do not think that there was an older term before that should have
> preventing the trademark (and even if I personally would not midn
> fighting these horrible law fights).
>
> > radiant-diagnostic or something maybe ? (I see there is also a Ruby
> > CMS called "radiant".)
>
> I think radiant-graphs might come closer even if I doubt that there is
> much confusion between the CMS and this tool and if its not packaged
> there should be no clash.
>
> I'd like to hear a word from ftpmaster if I rename the source and binary
> package as well as the Git archive - would this be accepted for the next
> upload. Some kind of confirmation in advance would be helpful to do
> more negotions right now and not after another round in the new queue.
>
> Kind regards
>
> Andreas.
>
> [1] https://github.com/marbl/Krona/wiki
>
> --
> http://fam-tille.de
>
>
--
http://fam-tille.de
Re: Bug#851306: ITP: freebayes -- Bayesian haplotype-based polymorphism discovery and genotyping
On January 15, 2017 12:35:57 PM EST, Andreas Tille wrote: >Hi Scott, > >On Sun, Jan 15, 2017 at 04:34:40PM +, Scott Kitterman wrote: >> >I fully agree with your generic name consideration. The software is >> >well known in this work field anyway so I'm hesitating a bit to >rename >> >it. Would you consider this a strong issue that needs to be >discussed >> >with upstream or is it in a "not nice but acceptable" status? >> >> I think it should be discussed with upstream, but we have broader >namespace considerations that they may not understand or care about. > >Definitely. > >> As long as a package search for freebayes returns this in the result >set, I don't think it's critical to have the package name match exactly >the upstream name. > >Do you care only about the *package* name or do you care as well about >the name binary /usr/bin/freebayes? I think they are both important. Scott K >> Not wearing my FTP team hat for this, consider it as a comment from >another DD. > >Both is welcome. > >Kind regards > > Andreas.
Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS
Hello Steve, On Sat, Jan 14, 2017 at 10:15:15AM -0800, Steve Langasek wrote: > If the failure of the test is not critical, then it should not be used > as a gate for CI. Which means you, as the package maintainer who > knows that this test failure is not critical, should fix your > autopkgtest to not fail when the non-critical test case fails. If we make it so that the only way to mark a test failure as non-critical is to hack the test suite to exit zero anyway, we would make it much less convenient to run non-critical tests on ci.debian.net. Maintainers could no longer look for 'fail' to see whether their non-critical tests have failed: they would have to open up the test output. I agree with the principle that test failures should be RC by default. I think we need an additional field in d/tests/control to mark individual tests as non-critical (this wouldn't really help Ole's 9000 tests package though). -- Sean Whitton signature.asc Description: PGP signature
Bug#851542: ITP: jenkins-job-builder-pipelin -- pipeline job generation plugin for jenkins-job-builder
Package: wnpp Severity: wishlist Owner: "Andrew Lee (李健秋)" * Package name: jenkins-job-builder-pipelin Version : 20160912+bd1bae Upstream Author : rusty * URL : https://github.com/rusty-dev/jenkins-job-builder-pipeline * License : Same as jenkins-job-builder Programming Lang: Python Description : pipeline job generation plugin for jenkins-job-builder This is a plugin for jenkins-job-builder to support pipeline job generation.
Re: Bug#851306: ITP: freebayes -- Bayesian haplotype-based polymorphism discovery and genotyping
Scott Kitterman dijo [Sun, Jan 15, 2017 at 04:34:40PM +]: > >> "freebayes" seems like a very generic name for something specific to > >such a > >> narrow field. Maybe freebayes-genetic-variance or some such instead. > > > >I fully agree with your generic name consideration. The software is > >well known in this work field anyway so I'm hesitating a bit to rename > >it. Would you consider this a strong issue that needs to be discussed > >with upstream or is it in a "not nice but acceptable" status? > > I think it should be discussed with upstream, but we have broader > namespace considerations that they may not understand or care about. > > As long as a package search for freebayes returns this in the result > set, I don't think it's critical to have the package name match > exactly the upstream name. > > Not wearing my FTP team hat for this, consider it as a comment from > another DD. As Scott is not "officially" speaking from the FTP team but just as a DD, I'll chime in here. I think the package name should indicate the field for which it is meant (freebayes-genetic-variance), but I don't think the program name should deviate from upstream; we have had issues such as when node.js was introduced (that 'node' was a name already taken by another program), but I don't think 'freebayes' will be such a contentious program name.
