Re: reopening bugs closed by removal after package reintroduction?
On 2020-05-12, Paul Wise wrote: > On Tue, May 5, 2020 at 7:15 AM Paul Wise wrote: > >> Should we be automatically reopening these bugs? > > enrico suggested on IRC that we should be doing this. I think in general it should be decided on a case by case basis. if it was removed yesterday and reintroduced with almost same version today, then probably yes. If it was a 0.0.git-2005-01-20 removed in 2010 and version 2.0 reintroduced today, probably not. But I guess it also depends on if it is one bug that needs work, or a "Thanks for your contribution to Debian by maintainig this package. Now also walk thru these 1000 old crap that probably is irellevant today"-experience /Sune
Bug#960472: ITP: python-readchar -- Python library to portable read single characters and key-strokes
Package: wnpp Severity: wishlist Owner: Kienan Stewart * Package name: python-readchar Version : 2.0.0 Upstream Author : Miguel Ángel García * URL : https://github.com/magmax/python-readchar * License : MIT Programming Lang: Python Description : Python library to portable read single characters and key-strokes The library provides a small class which sets up the key id for various platforms to provide a unified interface for developers to use when reading keystrokes in Python. This package is a dependency of python-inquirer. I will need to find a sponsor for the upload of this package.
Bug#960471: ITP: prophet -- Tool for producing high quality forecasts for time series data that has multiple seasonality with linear or non-linear growth.
Package: wnpp Severity: wishlist Owner: Mo Zhou * Package name: prophet Upstream Author : Facebook * URL : https://github.com/facebook/prophet * License : MIT Programming Lang: Py, R Description : Tool for producing high quality forecasts for time series data that has multiple seasonality with linear or non-linear growth. Time series analysis tool. Will be maintained by debian science team.
Bug#960470: ITP: python-inquirer -- Collection of common interactive command line user interfaces in python
Package: wnpp Severity: wishlist Owner: Kienan Stewart * Package name: python-inquirer Version : 2.6.3 Upstream Author : Miguel Ángel García * URL : https://github.com/magmax/python-inquirer * License : MIT Programming Lang: Python Description : Collection of common interactive command line user interfaces in python This package provides a library of common interactive CLI interfaces based on Inquirer.js. This library should ease the process of asking end user questions, parsing, validating answers, managing hierarchical prompts and providing error feedback. I will need to find a sponsor to upload this package.
Bug#960460: ITP: wys -- A daemon to bring up and take down PulseAudio loopbacks for phone call audio
Package: wnpp Severity: wishlist Owner: Henry-Nicolas Tourneur * Package name: wys Version : 0.1.7 Upstream Author : Bob Ham * URL : https://source.puri.sm/Librem5/wys/ * License : GPL Programming Lang: C Description : A daemon to bring up and take down PulseAudio loopbacks for phone call audio A daemon to bring up and take down PulseAudio loopbacks for phone call audio. Wys was written to manage call audio in the Librem 5 phone with a Gemalto PLS8. It may be useful for other systems. Wys is pronounced "weece" to rhyme with "fleece". Packaging this software is aimed at improving Librem5 support in Debian.
Bug#960434: ITP: varlink -- point-to-point IPC protocol and interface description format
Package: wnpp Severity: wishlist Owner: Jason Francis * Package name: varlink Version : 19 Upstream Author : Kay Sievers * URL : https://www.varlink.org/ * License : Apache-2.0 Programming Lang: C Description : point-to-point IPC protocol and interface description format Varlink is an interface description format and protocol that aims to make services accessible to both humans and machines in the simplest feasible way. A varlink interface combines the classic UNIX command line options, STDIN/OUT/ERROR text formats, man pages, service metadata and provides the equivalent over a single file descriptor, a.k.a. “FD3”. Varlink is plain-text, type-safe, discoverable, self-documenting, remotable, testable, easy to debug. Varlink is accessible from any programming environment. --- Submission Notes: Varlink is a small IPC protocol intended to be a very simple peer-to-peer alternative to D-Bus. A minimal implementation has already been adopted by the systemd project and integrated into their codebase; however I am submitting this ITP in order to package the official C reference implementation that includes a shared library and command line utility. Another package named "kanshi" that I contribute to upstream is looking at using this library, and it would be nice to have it ready in Debian for when a new version is published. I'm not sure what package team this would fall under, but I've been testing some Debian packaging already which is up on my github: https://github.com/cyclopsian/libvarlink/tree/debian-19/debian
Bug#960443: ITP: purple-xmpp-http-upload -- HTTP File Upload plugin for libpurple
Package: wnpp Severity: wishlist Owner: Arnaud Ferraris * Package name: purple-xmpp-http-upload Version : 0.2.1 Upstream Author : Dmitry Kosenkov * URL : https://github.com/Junker/purple-xmpp-http-upload * License : GPL Programming Lang: C Description : HTTP File Upload plugin for libpurple purple-xmpp-http-upload is a libpurple plugin implementing HTTP File Upload (XEP-0363 specification) for the XMPP protocol. I intend to maintain this package.
Re: [Fwd: Bug#959057: RFS: dh-cmake/0.4 [ITP] -- Debhelper programs for CMake projects]
Hi Alastair, On Tue, 2020-05-12 at 10:47 +0100, Alastair McKinstry wrote: > Dear Kyle, > > I'm willing to sponsor this. Thank you very much for the sponsorship offer - I gladly accept! :) So what's next? I am new to Debian development, and this is my first time submitting a package. > It overlaps /complements a package I maintain "ecbuild", which is a > set > of cmake macros and wrappers used by ECMWF (www.ecmwf.int) for their > software stack. > At the moment ecbuild provides some standard flags, etc when > --buildsystem=ecbuild is used but the plan is to expand this for > other > cmake fragments and dependencies similar to work here Packages in the > ECMWF stack typically include cmake fragments in > /usr/lib/$arch/cmake/$package/* which define for example which > libraries > and headers are needed; eg. when something at the botttom of the > stack > is built with libjemalloc, packages throughout the stack now need to > link against it and include libjemalloc-dev in the dependencies for > their libX-dev packages. ; Very nice. It's always interesting to see the CMake frameworks that people have developed. Would you have any interest in sharing it on the CMake Discourse server? We may be able to offer some feedback. https:// discourse.cmake.org/c/community Kyle
Bug#960428: ITP: blingfire -- Bing's Finite State machine and REgular expression manipulation library
Package: wnpp Severity: wishlist Owner: Mo Zhou * Package name: blingfire Upstream Author : Microsoft * URL : https://github.com/microsoft/BlingFire * License : MIT Programming Lang: C++, python Description : Bing's Finite State machine and REgular expression manipulation library useful as a preprocessing tool for computational linguistics. This library will be maintained by Debian Deep Learning Team.
Bug#960423: ITP: takari-polyglot-maven -- modules to enable Maven usage in others JVM languages
Package: wnpp Severity: wishlist Owner: Sudip Mukherjee X-Debbugs-CC: debian-j...@lists.debian.org * Package name: takari-polyglot-maven Version : 0.4.5 Upstream Author : * URL : https://github.com/takari/polyglot-maven * License : EPL-1.0 Programming Lang: Java Description : modules to enable Maven usage in others JVM languages Polyglot Maven harnesses the power of Maven through modern implementations of the JVM language like Groovy, Scala, Clojure and JRuby. The old package "polyglot-maven" is already in Debian, the new update has changed the package name. If we update Debian version of polyglot-maven then that will break the build of many other packages. So, as discussed in https://lists.debian.org/debian-java/2020/05/msg00017.html, this ITP is to package the new version as a separate package so that other packages which needs new polyglot-maven can use this (like #792149). I can maintain this under the umbrella of java-team. -- Regards Sudip
Bug#960417: ITP: purple-mm-sms -- libpurple plugin for SMS
Package: wnpp Severity: wishlist Owner: Arnaud Ferraris * Package name: purple-mm-sms Version : 0.1.4 Upstream Author : Andrea Schaefer * URL : https://source.puri.sm/Librem5/purple-mm-sms * License : GPL Programming Lang: C Description : libpurple plugin for SMS purple-mm-sms is a libpurple plugin which adds the ability to communicate via SMS using ModemManager. This package is useful for mobile phone and/or 4G modem users, most notably those using the Phosh "ecosystem". It will be maintained inside the DebianOnMobile team.
Re: [Fwd: Bug#959057: RFS: dh-cmake/0.4 [ITP] -- Debhelper programs for CMake projects]
Dear Kyle, I'm willing to sponsor this. It overlaps /complements a package I maintain "ecbuild", which is a set of cmake macros and wrappers used by ECMWF (www.ecmwf.int) for their software stack. At the moment ecbuild provides some standard flags, etc when --buildsystem=ecbuild is used but the plan is to expand this for other cmake fragments and dependencies similar to work here Packages in the ECMWF stack typically include cmake fragments in /usr/lib/$arch/cmake/$package/* which define for example which libraries and headers are needed; eg. when something at the botttom of the stack is built with libjemalloc, packages throughout the stack now need to link against it and include libjemalloc-dev in the dependencies for their libX-dev packages. ; this can be managed better with work in ecbuild or dh-cmake. Best regards Alastair On 11/05/2020 18:56, Kyle Edwards wrote: > Forwarded Message > From: Kyle Edwards > Reply-to: Kyle Edwards , > 959...@bugs.debian.org > To: Debian Bug Tracking System > Subject: Bug#959057: RFS: dh-cmake/0.4 [ITP] -- Debhelper programs for > CMake projects > Date: Tue, 28 Apr 2020 20:54:33 + > >> Package: sponsorship-requests >> Severity: wishlist >> >> Dear mentors, >> >> I am looking for a sponsor for my package "dh-cmake": >> >> * Package name: dh-cmake >> Version : 0.4 >> Upstream Author : Kyle Edwards >> * URL : https://gitlab.kitware.com/debian/dh-cmake >> * License : BSD-3 >> * Vcs : https://gitlab.kitware.com/debian/dh-cmake.git >> Section : devel >> >> It builds those binary packages: >> >> dh-cmake - Debhelper programs for CMake projects >> >> To access further information about this package, please visit the >> following URL: >> >> https://gitlab.kitware.com/debian/dh-cmake >> >> Regards, >> >> -- >> Kyle Edwards -- Alastair McKinstry, email: alast...@sceal.ie, matrix: @alastair:sceal.ie, phone: 087-6847928 Green Party Councillor, Galway County Council
Re: reopening bugs closed by removal after package reintroduction?
HELO, On 12.05.20 09:26, Paul Wise wrote: > On Tue, May 12, 2020 at 7:15 AM Ulrike Uhlig wrote: > >> Can you explain a bit better which issues this could cause to >> maintainers? About how many cases per year are we talking for example? > > The issue is the extra work that triaging old bugs involves, vs just > ignoring the old bugs that may or may not still apply. > > The latest dd-list I posted had 22 cases of packages reintroduced > since buster that still have bugs marked as closed with a version that > ends in +rm. I think it makes sense to reopen these bugs automatically. >> I don't understand the question. Do you mean, that when these bugs are >> automatically reopened, maintainers would be required to triage them >> manually? If this is what you mean, it seems like what maintainers do >> anyway. Looking at your questions below, this is probably not what you mean. > > That is what I mean. Based on the 22 cases I posted in the dd-list, > I'm not sure folks doing package reintroductions are aware of the need > to reopen the old bugs. For the people I've approached about this so > far (before this thread), they hadn't noticed the devref section about > it. Ulrike
Re: reopening bugs closed by removal after package reintroduction?
On Tue, May 12, 2020 at 7:15 AM Ulrike Uhlig wrote: > Can you explain a bit better which issues this could cause to > maintainers? About how many cases per year are we talking for example? The issue is the extra work that triaging old bugs involves, vs just ignoring the old bugs that may or may not still apply. The latest dd-list I posted had 22 cases of packages reintroduced since buster that still have bugs marked as closed with a version that ends in +rm. > I don't understand the question. Do you mean, that when these bugs are > automatically reopened, maintainers would be required to triage them > manually? If this is what you mean, it seems like what maintainers do > anyway. Looking at your questions below, this is probably not what you mean. That is what I mean. Based on the 22 cases I posted in the dd-list, I'm not sure folks doing package reintroductions are aware of the need to reopen the old bugs. For the people I've approached about this so far (before this thread), they hadn't noticed the devref section about it. -- bye, pabs https://wiki.debian.org/PaulWise
Re: reopening bugs closed by removal after package reintroduction?
Hi, On 05.05.20 09:14, Paul Wise wrote: > One of the tasks needed when reintroducing packages after they have > been removed is that the bugs that were closed by the removal need to > be triaged and either reopened or version closing information added: > > https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#reintroducing-packages > > Should we be automatically reopening these bugs? On first thought it makes a lot of sense. It also seems useful to automate this: if we rely on the maintainers to do it manually, there is a big chance that it will be forgotten, most of the time. Can you explain a bit better which issues this could cause to maintainers? About how many cases per year are we talking for example? > Should triaging these bugs be required of maintainers? I don't understand the question. Do you mean, that when these bugs are automatically reopened, maintainers would be required to triage them manually? If this is what you mean, it seems like what maintainers do anyway. Looking at your questions below, this is probably not what you mean. > Does anyone think that triaging these bugs is a bad idea? > > Does anyone want to help triage these bugs (see attached dd-list)? > Should we also be triaging the bugs filed against removed versioned > source packages like golang-1.9 or python3.6? > > The attached script provided by Stuart Prescott detects reintroduced > packages and a loop around `curl | grep -F +rm` detects bugs needing > triage. I'll attempt to run this and triage bugs when I can. Ulrike
Re: reopening bugs closed by removal after package reintroduction?
On Tue, May 12, 2020 at 6:08 AM Paul Wise wrote: > I made a mistake when running the loop (binary vs source packages), > here is the updated dd-list. Thanks to Jochen Sprickerhof for pointing > out my mistake. Sigh, attached the wrong one. Here is the correct one. -- bye, pabs https://wiki.debian.org/PaulWise dd-list Description: Binary data
