Looking for new maintainer(s) for net-snmp
Hello everybody, the net-snmp source package is looking for a new maintainer: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=835654 It is currently affected by 3 release critical bugs and has many reverse dependencies so it really needs to be well maintained. Uptsream seems to be reasonably responsive (as shown by https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=828449#21). 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) Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/
Bug#846577: ITP: python-portpicker -- Python module to find unused network ports to bind to
Package: wnpp Severity: wishlist Owner: Sascha Steinbiss * Package name: python-portpicker Version : 1.1.1 Upstream Author : Google * URL : https://github.com/google/python_portpicker * License : Apache-2.0 Programming Lang: Python Description : Python module to find unused network ports to bind to Portpicker provides an API to find and return an available network port for an application to bind to. Ideally suited for use from unittests or for test harnesses that launch local servers. This package will be provided for Python 2 and 3 and is being packaged as a dependency of the GRR Rapid Response server component.
Re: Looking for new maintainer(s) for net-snmp
❦ 2 décembre 2016 10:55 +0100, Raphael Hertzog : > the net-snmp source package is looking for a new maintainer: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=835654 > > It is currently affected by 3 release critical bugs and has many reverse > dependencies so it really needs to be well maintained. > Uptsream seems to be reasonably responsive (as shown by > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=828449#21). > > 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) It's not a good time for me to adopt the package, but I can offer sponsorship or join a team. I am somewhat familiar with NetSNMP but not involved in its packaging. -- Keep it right when you make it faster. - The Elements of Programming Style (Kernighan & Plauger) signature.asc Description: PGP signature
Bug#846582: ITP: python-codegen -- extension to ast that allows AST -> Python code generation
Package: wnpp Severity: wishlist Owner: Sascha Steinbiss * Package name: python-codegen Version : 1.0 Upstream Author : Armin Ronacher * URL : https://github.com/andreif/codegen * License : BSD Programming Lang: Python Description : extension to ast that allows AST -> Python code generation The codegen module converts a abstract syntax tree (AST) back into Python source code. This is useful for debugging purposes, especially when dealing with custom ASTs not generated by Python itself. This package will be provided for Python 2 and is being packaged as a dependency of the Rekall memory forensics framework.
Bug#846584: ITP: python-flask-sockets -- elegant WebSockets for your Flask apps
Package: wnpp Severity: wishlist Owner: Sascha Steinbiss * Package name: python-flask-sockets Version : 0.2.1 Upstream Author : Kenneth Reitz * URL : https://github.com/kennethreitz/flask-sockets * License : MIT Programming Lang: Python Description : elegant WebSockets for your Flask apps This package provides Flask-Sockets, a websocket library to be used with Flask. It is based on gevent-websocket and supports Flask Blueprints. This package will be provided for Python 2 and is being packaged as a dependency of the Rekall memory forensics framework.
Bug#846595: ITP: wok -- Webserver Originated from Kimchi
Package: wnpp Severity: wishlist Owner: Lucio Correia * Package name: wok Version : 2.3.0 Upstream Author : 2013-2016 International Business Machines Corporation and others * URL : https://github.com/kimchi-project/wok * License : LGPL-2.1+ and Apache-2.0 Programming Lang: Python Description : Webserver Originated from Kimchi Wok is a cherrypy-based web framework with HTML5 support that is extended by plugins which expose functionality through REST APIs. Examples of such plugins are Kimchi (Virtualization Management) and Ginger (System Administration). Wok comes with a sample plugin for education purposes. Wok runs through wok service. In order to update kimchi and ginger packages to their latest upstream versions (2.3), wok package is needed as a dependency. Wok is a split out of kimchi's web framework. Kimchi is now focused on virtualization functionality and became a plugin of Wok. Most of Wok code was already being analyzed as part of Kimchi ITP at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=772823 and RFS at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=800966. We intend to provide Wok along with Kimchi, Ginger and Ginger-Base plugins every Debian release. We look for a sponsor.
Bug#846598: ITP: ginger-base -- Basic host management for Kimchi and Ginger
Package: wnpp Severity: wishlist Owner: Lucio Correia * Package name: ginger-base Version : 2.2.1 Upstream Author : 2013-2016 International Business Machines Corporation and others * URL : https://github.com/kimchi-project/gingerbase * License : LGPL-2.1+ and Apache-2.0 Programming Lang: Python Description : Basic host management for Kimchi and Ginger Ginger Base is an open source base host management plugin for Kimchi and Ginger plugins of Wok. It provides an intuitive web panel with common tools for monitoring and updating Linux systems. In order to update kimchi and ginger packages to their latest upstream versions (2.3), ginger-base package is needed as a dependency. Ginger Base is a split out of Kimchi and Ginger basic functionality. We intend to update Ginger Base along with Kimchi, Ginger and Wok every Debian release. We look for a sponsor.
F
Powered by Cricket Wireless.
MIA maintainers and RC-buggy packages
Hello. During the last week or two I've spent some time looking through the packages with RC bugs, mostly those that are removed from testing, have popcon 100+ and don't have recent activity on the bug report. I skipped bugs like "depends on obsolete piece of software" or "crashes in some circumstances", most of the bugs were FTBFSes caused by obsolete packaging or incompatibilities of the old code with the current environment. Unsurprisingly, most of these packages didn't have a maintainer upload since e.g. 2012 and have the RC bug open for last 3+ months. Some of them have some team in the Maintainer header, some have people in Uploaders who never made an upload. Some of them had 3 NMUs in last 3 years. * 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? Next, I contacted all maintainers or such packages, telling them that their package X had its last maintaner upload on X and has an RC bug #X since X, asking them to orphan the package if they are not interested in it anymore and to also orphan other their packages they are not interested in. I've sent about 30 emails in last 6 days. I've got 9 immediate answers. 3 were "should be orphaned". 2 were "I will try to fix this". 1 was "I will fix the package" but about a different package. 1 was "should be orphaned, though we don't have a standard method to orphan team packages". 1 was "I will move to a team" and I answered "a package needs a 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. * 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? * Also: what should we do with packages that are marked as team-maintained but are really orphaned? 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. * 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? -- WBR, wRAR signature.asc Description: PGP signature
Re: MIA maintainers and RC-buggy packages
Andrey Rahmatullin writes ("MIA maintainers and RC-buggy packages"):
> * 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?
No, I think this is a waste of time. It it easy to see (eg from the
BTS and tracker) that a package is effectively orphaned.
> * Also: what should we do with packages that are marked as team-maintained
> but are really orphaned?
The same thing we should do with any package.
> 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.
Your diligence is commendable.
Frankly, I would have been tempted to let a lot of those packages slip
out of stretch. It depends what they were, of course.
> * 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?
Any package that got autoremoved from testing without response from
the maintainer should be treated as orphaned. Likewise any package
with an RC bug with no action for months.
In the absence of bugs that "ought to have been dealt with" (which
would include RC bugs and bugs containing good patches, but not
necessarily any other kind of bug) I don't think lack of uploads
necessarily proves very much.
Likewise "only NMU uploads" doesn't necessarily prove very much.
Maybe the nominal maintainer is actively reviewing the NMUs even, but
sees no need to intervene.
If the package is not clearly orphaned I think the best approach is a
QA upload to DELAYED. How about adding the QA team to Uploaders while
you're at it ? :-)
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: MIA maintainers and RC-buggy packages
On Fri, Dec 02, 2016 at 06:58:55PM +, Ian Jackson wrote: > > * 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? > > No, I think this is a waste of time. It it easy to see (eg from the > BTS and tracker) that a package is effectively orphaned. Even if we don't apply the letter of our rules about NMUs and hijacking to effectively orphaned packages, there are wnpp-alert and how-can-i-help that directly use our official wnpp marks to show the packages in need of help. There is also a filter on the UDD bug list and maybe other places. There can be (or there are?) some metrics about the archive state. > Frankly, I would have been tempted to let a lot of those packages slip > out of stretch. It depends what they were, of course. I was following an advice received on IRC: if a package has a popcon of even 20 then most likely there are 20 people who will benefit from the fix. > In the absence of bugs that "ought to have been dealt with" (which > would include RC bugs and bugs containing good patches, but not > necessarily any other kind of bug) I don't think lack of uploads > necessarily proves very much. > > Likewise "only NMU uploads" doesn't necessarily prove very much. > Maybe the nominal maintainer is actively reviewing the NMUs even, but > sees no need to intervene. That sounds correct. -- WBR, wRAR signature.asc Description: PGP signature
Re: MIA maintainers and RC-buggy packages
Andrey Rahmatullin writes ("Re: MIA maintainers and RC-buggy packages"):
> On Fri, Dec 02, 2016 at 06:58:55PM +, Ian Jackson wrote:
> > Frankly, I would have been tempted to let a lot of those packages slip
> > out of stretch. It depends what they were, of course.
>
> I was following an advice received on IRC: if a package has a popcon of
> even 20 then most likely there are 20 people who will benefit from the
> fix.
I think the advice you got on IRC was good. Thank you, and thanks for
(effectively) correcting me.
Keep up the good work!
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#846633: ITP: iterum -- Iterum is a multiprotocol chat bot
Package: wnpp Severity: wishlist Owner: Kyle Robbertze * 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 Iterum is a multi-protocol chat bot written in Python. It is a fork of ibid wth the goal of continuing development and adding new features. Development on ibid seems to have stalled and myself and a few others decided to fork it and continue development. I plan on maintaining it within the PAPT. I will need a sponsor.
Bug#846643: ITP: sagenb -- The standalone Sage Notebook
Package: wnpp Severity: wishlist Owner: Ximin Luo * Package name: sagenb Version : 0.13 Upstream Author : SageNB contributors * URL : https://github.com/sagemath/sagenb * License : GPL-3+ Programming Lang: Python, JS Description : The standalone Sage Notebook The Sage Notebook is a web-based graphical user interface for mathematical software. Sage is a different approach to mathematics software. It makes it easy for you to use most mathematics software together. Sage includes GAP, GP/PARI, Maxima, and Singular, and dozens of other open source math packages. It aims to be a viable open source alternative to Magma, Maple, Mathematica, and MATLAB. With the Sage Notebook anyone can create, collaborate on, and publish interactive worksheets. In a worksheet, one can write code using Sage, Python, and other software included in Sage. You can write programs that combine serious mathematics with anything else. Most of the notebook does not depend on having Sage installed. Only a few miscellaneous functions are imported from Sage.
Bug#846646: ITP: tendermint-go-rpc -- HTTP RPC server supporting calls over websockets
Package: wnpp Severity: wishlist Owner: Alessio Treglia * Package name: tendermint-go-rpc Version : 0.0~git20161021.0.e6e3853 Upstream Author : The Tendermint Project * URL : http://github.com/tendermint/go-rpc * License : Apache-2.0 Programming Lang: Golang Description : RPC server in Go supporting multiple request formats HTTP RPC server supporting calls via URI params, JSON-RPC and jsonrpc over websockets Client Requests Suppose we want to expose the rpc function HelloWorld(name string, num int). . 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. . This package is used by the Tendermint Core component.
Bug#846651: ITP: muparserx -- mathematical expression parser library
Package: wnpp Severity: wishlist Owner: Andreas Bombe * Package name: muparserx Version : 4.0.7 Upstream Author : Ingo Berg * URL : http://articles.beltoforion.de/article.php?a=muparserx&hl=en * License : BSD-2-clause Programming Lang: C++ Description : mathematical expression parser library The evaluation of a mathematical expression is a standard task required in many applications. It can be solved by either using a standard math expression parser such as muparser or by embedding a scripting language such as Lua. There are however some limitations: Although muparser is pretty fast it will only work with scalar values and although Lua is very flexible it does neither support binary operators for arrays nor complex numbers. So if you need a math expression parser with support for arrays, matrices and strings muparserx may be able to help you. It was originally based on the original muparser engine but has since evolved into a standalone project with a completely new parsing engine. I am packaging this because it is the dependency of pothos, which I will also package.
Bug#846663: ITP: pybigwig -- module for quick access to bigBed and bigWig files
Package: wnpp Severity: wishlist Owner: Diane Trout * Package name: pybigwig Version : 0.3.2 Upstream Author : Devon Ryan * URL : https://github.com/dpryan79/pyBigWig * License : Expat Programming Lang: Python Description : module for quick access to bigBed and bigWig files This is a Python extension, written in C, for quick access to bigBed files, and access to and creation of bigWig files. I was planning on submitting this under the debian-med team. We found it as a dependency for deepTools https://deeptools.github.io/ though I haven't investigated packaging deepTools. bigBed and bigWig files are quite common in bioinformatics, it'd be nice to be able to use them directly. The one odd thing about the package is that upstream has the C code seperately available to build a library, but they also includes directly include in their python package and just add the C code to the setup.py code to build the extension.
