Re: MIA maintainers and RC-buggy packages
> human maintainer". 1 was "why are you asking me, I am only an > uploader, > the package is team maintained" even though that person was the only > actual uploader (since 2002 till 2012). I've sent the list of my > pings to > the MIA team. I don't like the way you are picturing this. The question is absolutely valid, but maybe I should rephrase it to "Why are you contacting the uploader only and not the team as well?" > * Also: what should we do with packages that are marked as team- > maintained > but are really orphaned? Which is defined how? Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL signature.asc Description: This is a digitally signed message part
Re: MIA maintainers and RC-buggy packages
On Fri, Dec 02, 2016 at 10:56:07PM +0500, Andrey Rahmatullin wrote: > * So, the first question is: should I spend my time on getting these > packages back to testing so they would be a part of the next release? Or > should I spend my time on other RC bugs fixing which will help release > stretch faster? IMHO, ponder popcon, you're personal feeling on what the package is, the actual issue, and then see what's better. Though I believe that if they arrived at this point they are not worth much of your time, but of course that's entirely up to you! [reflowing] > 1 was "should > be orphaned, though we don't have a standard method to orphan team > packages". > 1 was "why are you asking me, I am only an uploader, > the package is team maintained" even though that person was the only > actual uploader (since 2002 till 2012). sigh. Yes, we don't have a standard method. But if the team *is* the uploader (as often is the case), then there is only so much you can do. Probably before orphaning you can email the team ML, but of course contacting the single uploader (that is the de-facto maintainer), before writing to a public ML that you are proposing to wrestle a package out of the uploader only seems nice? > 1 was "I will move to a team" and I answered "a package needs a > human maintainer". sigh². > I've sent the list of my pings to the MIA team. Thanks. You've already received a reply from us. > * So: is it a real problem that there are packages that should be marked > as orphaned but they aren't? Should we spend any effort on marking more > orphaned packages? If yes, how should we do that? There surely are a lot of packages that are de-facto orphaned around here. Thorsten Alteholz writes on his blog about adopting orphaned packages (http://blog.alteholz.eu/2016/11/my-debian-activities-in-october-2016/), and as he noticed the number of orphaned packages is steadily increasing. We're now at 1007 packages as of yesterday wnpp report https://lists.debian.org/debian-devel/2016/12/msg00023.html (I wonder if we have any graph?) Since the MIA team restarted their efforts earlier this year the number of orphaned packages has been increasing, I'm not sure if that's for the worse of the better, but it did... > * Also: what should we do with packages that are marked as team-maintained > but are really orphaned? I suggest: contact uploaders to check if they are fine, then contact team and seek ack, then file the bug (this is assuming they reply, if they don't, then it's harder). > When fixing the RC bugs I always looked through other bugs in the same > package and applied trivial patches to the packaging. I've added > debian/source/format where it was missing. In some cases I've completely > replaced the packaging with 4-line d/rules. In at least two cases I fixed > empty -dbgsym packages. I did such things too, and even received thanks, regardless of the fact that NMUs are not supposed to do any of that. > * So, the final question: how much time should pass since the last > maintainer upload (since removal from testing, since the first still > unfixed RC bug, how many NMUs should exist since the last maintainer > upload) to be able to just do a QA upload (without changing the Maintainer > field as it's prohibited on the https://wiki.debian.org/Teams/MIA page) > instead of finely-crafting minimal diffs and fixing only things allowed by > devref 5.11.1? We discussed several times internally in the MIA team during the year how to just "declare" a maintainer gone based on the current state (last upload, gpg key ok, number of RCs, number of NMUs, etc), but the consensus has been that it's just plain hard/impossible to give an appropriate answer good for all cases. We shall discuss this again at DebConf instead. And: you're suggesting to do a QA upload without changing maintainer field? That seems ridiculous to me: QA uploads are uploads where maintainer is QA, right? You're suggesting to change the meaning to "big NMU", basically? Let's just call them NMU. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: MIA maintainers and RC-buggy packages
On 03/12/16 11:42, Mattia Rizzolo wrote: > On Fri, Dec 02, 2016 at 10:56:07PM +0500, Andrey Rahmatullin wrote: >> * So, the final question: how much time should pass since the last >> maintainer upload (since removal from testing, since the first still >> unfixed RC bug, how many NMUs should exist since the last maintainer >> upload) to be able to just do a QA upload (without changing the Maintainer >> field as it's prohibited on the https://wiki.debian.org/Teams/MIA page) >> instead of finely-crafting minimal diffs and fixing only things allowed by >> devref 5.11.1? > > We discussed several times internally in the MIA team during the year > how to just "declare" a maintainer gone based on the current state > (last upload, gpg key ok, number of RCs, number of NMUs, etc), but the > consensus has been that it's just plain hard/impossible to give an > appropriate answer good for all cases. We shall discuss this again at > DebConf instead. I would suggest to come up with some algorithm to determine if a package is effectively unmaintained, and implement it in an automatic way that gives maintainers prior notice and a chance to react, like we do with auto-removals. Then if nothing happens in a reasonable time frame, the package gets orphaned. I think we should also have an auto-removals-from-sid[1] (the crowd applauded when I mentioned that in my Debconf talk), which would solve/help your high number of orphaned packages. Cheers, Emilio [1] With a *very* conservative criteria. We don't want to remove a package from the archive after 30 days because of 1 RC bug.
Re: MIA maintainers and RC-buggy packages
On Sat, Dec 03, 2016 at 12:23:17PM +0100, Emilio Pozuelo Monfort wrote: > I would suggest to come up with some algorithm to determine if a package is > effectively unmaintained, and implement it in an automatic way that gives > maintainers prior notice and a chance to react, like we do with auto-removals. > Then if nothing happens in a reasonable time frame, the package gets orphaned. > > I think we should also have an auto-removals-from-sid[1] (the crowd applauded > when I mentioned that in my Debconf talk), which would solve/help your high > number of orphaned packages. > [1] With a *very* conservative criteria. We don't want to remove a package > from > the archive after 30 days because of 1 RC bug. every word fully seconded, those are two very nice ideas, I hope to applaud their implementations soon :) -- cheers, Holger signature.asc Description: Digital signature
Re: Bug#846633: ITP: iterum -- Iterum is a multiprotocol chat bot
On Fri, Dec 02, 2016 at 10:03:07PM +0200, Kyle Robbertze wrote: > Package: wnpp > > * Package name: iterum > Version : 0.1 > Upstream Author : Kyle Robbertze > * URL : http://iterum.io/ > * License : MIT/X/Expat > Programming Lang: Python > Description : Iterum is a multi-protocol chat bot > > Development on ibid seems to have stalled and myself and > a few others decided to fork it and continue development. Please learn from that. Make it possible that over some years other people take takeover development / maintenance of "iterum". > I plan on maintaining it within the PAPT. I will need a > sponsor. I don't know what PAPT is. I did found https://launchpad.net/iterum Also http://bazaar.launchpad.net/~iterum-core/iterum/trunk/files/head:/docs/ I think it would be good to have the .rst files rendered into .html somewhere on-line. Other thing I couldn't find: the "debian directory" Groeten Geert Stappers DD -- Leven en laten leven
Re: MIA maintainers and RC-buggy packages
On Sat, Dec 03, 2016 at 12:23:17PM +0100, Emilio Pozuelo Monfort wrote: > I would suggest to come up with some algorithm to determine if a package is > effectively unmaintained, and implement it in an automatic way that gives > maintainers prior notice and a chance to react, like we do with auto-removals. > Then if nothing happens in a reasonable time frame, the package gets orphaned. Yes, totally agree. That's what I was trying to say, sorry if I didn't convey it properly. But I'm very conservative in trying to avoing disputes and flames, and I'd like to come up with an algorithm good for everyone, that covers as many cases as possible. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: MIA maintainers and RC-buggy packages
On Sat, Dec 03, 2016 at 11:42:02AM +0100, Mattia Rizzolo wrote: > And: you're suggesting to do a QA upload without changing maintainer > field? That seems ridiculous to me: QA uploads are uploads where > maintainer is QA, right? You're suggesting to change the meaning to > "big NMU", basically? Let's just call them NMU. Yes, of course I've meant an upload without the usual restrictions of a NMU. -- WBR, wRAR signature.asc Description: PGP signature
Re: MIA maintainers and RC-buggy packages
On Sat, Dec 03, 2016 at 12:23:17PM +0100, Emilio Pozuelo Monfort wrote: > I think we should also have an auto-removals-from-sid[1] (the crowd applauded > when I mentioned that in my Debconf talk), which would solve/help your high > number of orphaned packages. What real problems will this solve apart from having less bad packages in the archive? -- WBR, wRAR signature.asc Description: PGP signature
https://manpages.debian.org/man/1/uscan
Hi, The URL https://manpages.debian.org/man/1/uscan gives me a 403 error. This e-mail is to report that issue. Is there a better place then ML d-devel@l.d.o to report? What I did myself: replaced httpS into http (same HTTP 403 error) Where the link was found: https://wiki.debian.org/debian/watch Groeten Geert Stappers -- Leven en laten leven signature.asc Description: Digital signature
Re: https://manpages.debian.org/man/1/uscan
On Sat, Dec 03, 2016 at 02:33:44PM +0100, Geert Stappers wrote: > The URL https://manpages.debian.org/man/1/uscan gives me a 403 error. https://manpages.debian.org/ gives me "The service you have requested is currently disabled." Googling for "manpages.debian.org" gives me https://wiki.debian.org/manpages.debian.org which says "The current manpages.debian.org service has been disabled by Teams/DSA because of performance issues.". -- WBR, wRAR signature.asc Description: PGP signature
Bug#846815: ITP: tendermint-go-config -- Simple Go configuration tool
Package: wnpp Severity: wishlist Owner: Alessio Treglia * Package name: tendermint-go-config Version : 0.0~git20160626.0.e64b424 Upstream Author : Tendermint Project * URL : http://www.tendermint.com * License : Apache-2.0 Programming Lang: Golang Description : Simple Go configuration tool This package provides a simple configuration tool that is being used by several Tendermint components. . Tendermint Core is Byzantine Fault Tolerant (BFT) middleware that takes a state transition machine, written in any programming language, and replicates it on many machines.
Re: Bug#846633: ITP: iterum -- Iterum is a multiprotocol chat bot
On Sat, Dec 03, 2016 at 02:01:10PM +0100, Geert Stappers wrote: > > I plan on maintaining it within the PAPT. I will need a > > sponsor. > > I don't know what PAPT is. https://wiki.debian.org/Teams/PythonAppsPackagingTeam > Other thing I couldn't find: the "debian directory" That's probably fine for a package that doesn't exist yet. -- WBR, wRAR signature.asc Description: PGP signature
Re: MIA maintainers and RC-buggy packages
On Sat, Dec 03, 2016 at 06:23:17PM +0500, Andrey Rahmatullin wrote: > > I think we should also have an auto-removals-from-sid[1] (the crowd > > applauded > > when I mentioned that in my Debconf talk), which would solve/help your high > > number of orphaned packages. > What real problems will this solve apart from having less bad packages in > the archive? is this question ment as a reference to "what have the Romans done for us"? Having many bad packages in the archive is a real problem. Removing some of these packages is part of the solution to that, another part is fixing some others. -- cheers, Holger signature.asc Description: Digital signature
Re: https://manpages.debian.org/man/1/uscan
On 03/12/16 14:40, Andrey Rahmatullin wrote: > On Sat, Dec 03, 2016 at 02:33:44PM +0100, Geert Stappers wrote: >> The URL https://manpages.debian.org/man/1/uscan gives me a 403 error. > https://manpages.debian.org/ gives me "The service you have requested is > currently disabled." > Googling for "manpages.debian.org" gives me > https://wiki.debian.org/manpages.debian.org which says "The current > manpages.debian.org service has been disabled by Teams/DSA because of > performance issues.". Also see https://db.debian.org/machines.cgi?host=glinka Emilio
Re: Looking for new maintainer(s) for net-snmp
Hi, On Fri, 2 Dec 2016 10:55:23 +0100 Raphael Hertzog wrote: > Hideki, would you sponsor a new maintainer if s/he does not have upload > rights? (bccing debian-mentors in case new contributors are interested in > taking it over) Of course, I'll sponsor it, and hope someone can step up to new maintainer. -- Regards, Hideki Yamane henrich @ debian.or.jp/org http://wiki.debian.org/HidekiYamane
Re: MIA maintainers and RC-buggy packages
On Sat, Dec 03, 2016 at 09:25:11AM +0100, Michael Meskes wrote: > > human maintainer". 1 was "why are you asking me, I am only an > > uploader, > > the package is team maintained" even though that person was the only > > actual uploader (since 2002 till 2012). I've sent the list of my > > pings to > > the MIA team. > > I don't like the way you are picturing this. Sorry, I must have misunderstood you. > The question is absolutely valid, but maybe I should rephrase it to "Why > are you contacting the uploader only and not the team as well?" Because it's the first step. > > * Also: what should we do with packages that are marked as team- > > maintained > > but are really orphaned? > Which is defined how? I can define that as "nobody actually cares about the package". -- WBR, wRAR signature.asc Description: PGP signature
Re: https://manpages.debian.org/man/1/uscan
On Sat, Dec 03, 2016 at 03:31:17PM +0100, Emilio Pozuelo Monfort wrote: > On 03/12/16 14:40, Andrey Rahmatullin wrote: > > On Sat, Dec 03, 2016 at 02:33:44PM +0100, Geert Stappers wrote: > >> The URL https://manpages.debian.org/man/1/uscan gives me a 403 error. > > https://manpages.debian.org/ gives me "The service you have requested is > > currently disabled." > > Googling for "manpages.debian.org" gives me > > https://wiki.debian.org/manpages.debian.org which says "The current > > manpages.debian.org service has been disabled by Teams/DSA because of > > performance issues.". > > Also see https://db.debian.org/machines.cgi?host=glinka Which says | purposes of this server: | archive.debian.org - historical debian releases | bugs-search.debian.org | cdimage-search.debian.org | manpages.debian.org - disabled because it breaks the host and we are waiting on the maintainer to move it to a new host | mirror-master.debian.org | misc services So it is a known issue. And the blocking issue seems to be "manpages group access and dependencies install". Which seems to be documented at RT#6485. I did visit https://rt.debian.org/ Needed another websearch. Found https://wiki.debian.org/rt.debian.org Then choose to proceed with the uscan thing I'm dealing with. Groeten Geert Stappers -- Leven en laten leven
Re: https://manpages.debian.org/man/1/uscan
On Sat, Dec 03, 2016 at 06:22:18PM +0100, Geert Stappers wrote: > > >> The URL https://manpages.debian.org/man/1/uscan gives me a 403 error. > > > https://manpages.debian.org/ gives me "The service you have requested is > > > currently disabled." > > > Googling for "manpages.debian.org" gives me > > > https://wiki.debian.org/manpages.debian.org which says "The current > > > manpages.debian.org service has been disabled by Teams/DSA because of > > > performance issues.". > > > > Also see https://db.debian.org/machines.cgi?host=glinka > > Which says > | purposes of this server: > | archive.debian.org - historical debian releases > | bugs-search.debian.org > | cdimage-search.debian.org > | manpages.debian.org - disabled because it breaks the host and we are > waiting on the maintainer to move it to a new host > | mirror-master.debian.org > | misc services > > So it is a known issue. > > And the blocking issue seems to be "manpages group access and dependencies > install". Which seems to be documented at RT#6485. > > I did visit https://rt.debian.org/ > Needed another websearch. > Found https://wiki.debian.org/rt.debian.org I don't think you need to do all of that just to read uscan(1), it's available in the package. Certainly if you need to use uscan you need to install it, installing the manpage in the process? -- WBR, wRAR signature.asc Description: PGP signature
debian-keyring not updated?
Hi, debian-keyring git changelog shows 2016.11.13 as the latest, even the tags reflect this. https://anonscm.debian.org/cgit/keyring/keyring.git/tree/debian/changelog But https://tracker.debian.org/pkg/debian-keyring shows 2016.09.04 as the latest version. apt-cache policy debian-keyring debian-keyring: Installed: 2016.09.04 Candidate: 2016.09.04 Is this intentional? signature.asc Description: OpenPGP digital signature
Re: debian-keyring not updated?
On Sat, Dec 03, 2016 at 11:21:26PM +0530, Pirate Praveen wrote: > debian-keyring git changelog shows 2016.11.13 as the latest, even the > tags reflect this. > https://anonscm.debian.org/cgit/keyring/keyring.git/tree/debian/changelog > > But https://tracker.debian.org/pkg/debian-keyring shows 2016.09.04 as > the latest version. > > Is this intentional? Yes, the package is not updated every time there is a keyring push. What's tagged is what is live on the debian.org infrastructure, not what's in the package (and probably you shouldn't rely on that either if you need an up-to-date keyring locally). -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: debian-keyring not updated?
On ശനി 03 ഡിസംബര് 2016 11:26 വൈകു, Mattia Rizzolo wrote: > Yes, the package is not updated every time there is a keyring push. > What's tagged is what is live on the debian.org infrastructure, not > what's in the package (and probably you shouldn't rely on that either if > you need an up-to-date keyring locally). > Thanks for the info. Previous uploads were more frequent so I wondered if there was an issue. signature.asc Description: OpenPGP digital signature
Re: MIA maintainers and RC-buggy packages
> > The question is absolutely valid, but maybe I should rephrase it to > > "Why > > are you contacting the uploader only and not the team as well?" > > Because it's the first step. Would have been nice to know. Anyway, I can see your point. > > > * Also: what should we do with packages that are marked as team- > > > maintained > > > but are really orphaned? > > > > Which is defined how? > > I can define that as "nobody actually cares about the package". Sure, but then it would be nice if you'd tried finding out if nobody cares. As usual the real world is neither white not black, but some shade of gray. The problem with the package is that the new version does not build on my system but I lack the time to debug, could be minor but still. I'd like to keep the package around, if it still has the same functionality. Upstreams docs are not absolutely clear about this and I cannot check without building it. If anyone wants to help, the package is tora. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL signature.asc Description: This is a digitally signed message part
Bug#846881: ITP: libsip-api-java -- SIP API for Java
Package: wnpp Severity: wishlist Owner: Ingo Bauersachs * Package name: libsip-api-java Version : 1.2 Upstream Author : Daniel Pocock * URL : https://github.com/opentelecoms-org/java-sip-api * License : Apache 2.0 Programming Lang: Java Description : SIP API for Java SIP API Specification of JSR 32 The SIP API is an extended Java API used by a couple of projects, e.g. ice4j, Jitsi, Apache Camel and others. The JSR hasn't been updated for many years and this package mostly consists of interfaces, it won't involve much maintenance, if any.
Bug#846883: ITP: libsdp-api-java -- SDP API for Java
Package: wnpp Severity: wishlist Owner: Ingo Bauersachs * Package name: libsdp-api-java Version : 1.0 Upstream Author : Daniel Pocock * URL : https://github.com/opentelecoms-org/java-sdp-api * License : Apache 2.0 Programming Lang: Java Description : SDP API for Java SDP API Specification of JSR 141 The SDP API is an extended Java API used by a couple of projects, e.g. ice4j, Jitsi, Apache Camel and others. The JSR hasn't been updated for many years and this package mostly consists of interfaces, it won't involve much maintenance, if any.
Re: debian-keyring not updated?
On Sun, Dec 4, 2016 at 2:09 AM, Pirate Praveen wrote: > Previous uploads were more frequent so I wondered if there was an issue. Probably best to talk to keyring maint than debian-devel. -- bye, pabs https://wiki.debian.org/PaulWise
Bug#846903: ITP: node-has-gulplog -- Check if gulplog is available before attempting to use it
Package: wnpp Severity: wishlist Owner: Pirate Praveen X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-has-gulplog Version : 0.1.0 Upstream Author : Blaine Bublitz (http://iceddev.com) * URL : https://github.com/gulpjs/has-gulplog#readme * License : Expat Programming Lang: JavaScript Description : Check if gulplog is available before attempting to use it signature.asc Description: OpenPGP digital signature
Bug#846904: node-glogg -- Global logging utility
Package: wnpp Severity: wishlist Owner: Pirate Praveen X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-glogg Version : 1.0.0 Upstream Author : Blaine Bublitz (http://iceddev.com/) * URL : https://github.com/undertakerjs/glogg#readme * License : Expat Programming Lang: JavaScript Description : Global logging utility signature.asc Description: OpenPGP digital signature
Bug#846905: ITP: node-fancy-log -- Log things, prefixed with a timestamp
Package: wnpp Severity: wishlist Owner: Pirate Praveen X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-fancy-log Version : 1.2.0 Upstream Author : Blaine Bublitz (http://iceddev.com) * URL : https://github.com/phated/fancy-log#readme * License : Expat Programming Lang: JavaScript Description : Log things, prefixed with a timestamp signature.asc Description: OpenPGP digital signature
