Bug#1008625: RFH: qiskit-terra
Hello Andreas, I concur: the most reasonable course of action would be to remove the package(s) [1] [2] [3] from Debian. My availability and skills for working on the packages is at the same level or lower than at the time of the RFH, and the amount of effort has increased since then. Best, [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008625 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008627 [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008626 --- Diego M. Rodriguez
Bug#1001105: RFP: pyvista -- 3D plotting and mesh analysis
Control: retitle 1001105 RFP: pyvista -- 3D plotting and mesh analysis Control: noowner 1001105 Hello, regrettably, I'm no longer able / interested in packaging this software. I'm attempting to officially signal it by removing my ownership, in the hopes it can be picked up by other contributor (specially in light of the recent blocking dependency from python-scooby). Best, and thanks Drew for the collaboration that led to the initial ITP, --- Diego M. Rodriguez
Bug#995581: ITP: python-oauthenticator -- OAuth authenticator for JupyterHub
Control: noowner 995581 Control: close 995581 Hello, I am no longer interested in packaging this module. Best, --- Diego M. Rodriguez
Bug#1008625: RFH: qiskit-terra
Package: wnpp Severity: normal X-Debbugs-Cc: debian-de...@lists.debian.org Control: affects -1 src:qiskit-terra Hello, I request help with maintaining this package. With upstream moving faster than originally anticipated and with my co-maintainer and mentor retiring from Debian, I no longer have the bandwidth and skills to realistically maintain the packaging effort on par with the latest upstream releases by myself. One of the challenges in order to bring back the package to speed is packaging additional dependencies (~3 required, some of them not pure Python) into Debian. The package also has a strong relationship with (also RFH-ed) qiskit-aer, and ideally help would also be needed with the latter (potentially expanding to other future qiskit-related packages). Best, --- Diego M. Rodriguez
Bug#1008627: RFA: qiskit-ibmq-provider
Package: wnpp
Severity: normal
Control: affects -1 src:qiskit-ibmq-provider
Hello,
I request adoption (or likely removal) of this package. Upstream is phasing out
this package [1] in favor of similar alternatives, and I no longer have the
bandwidth and energy to maintain the packaging effort.
One of the new packages that will replace the current one
("qiskit-ibm-provider") shares many similarities with the current package -
ideally, the new maintainer would be able to reuse most of the current effort.
Please note that this package has a strong relationship with (RFH-ed)
qiskit-terra, and help/coordination would be encouraged/needed.
Best,
[1] https://github.com/Qiskit/qiskit-ibmq-provider/issues/1042
---
Diego M. Rodriguez
Bug#1008626: RFH: qiskit-aer
Package: wnpp Severity: normal X-Debbugs-Cc: debian-de...@lists.debian.org Control: affects -1 src:qiskit-aer Hello, I request help with maintaining this package. With upstream moving faster than originally anticipated and with my co-maintainer and mentor retiring from Debian, I no longer have the bandwidth and skills to realistically maintain the packaging effort on par with the latest upstream releases by myself. Since the version currently packaged in Debian, upstream has included usage of conan along with a number of dependencies and changes. The package also has a strong relationship with (also RFH-ed) qiskit-terra, and ideally help would also be needed with the latter (potentially expanding to other qiskit-related packages). Best, --- Diego M. Rodriguez
Bug#1001105: RFP: pyvista -- 3D plotting and mesh analysis
Control: retitle -1 ITP: pyvista -- 3D plotting and mesh analysis
Control: owner -1 !
Hello,
On Sat, 04 Dec 2021 12:51:13 +0100 Drew Parsons wrote:
> Well suited to team maintenance under the Debian Python Team, but
> could be adopted by more specialized teams such as the Debian Science
> Team.
I intend to package this software, along with its unpackaged
dependencies ("scooby"), under the umbrella of the Debian Python Team.
Best,
--
Diego M. Rodriguez
Bug#1002318: python-nest-asyncio: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.10 3.9" returned exit code 13
Control: tag -1 pending Hello Lucas, thanks for the bug report - I have prepared an upload of a new upstream version that includes a fix [2] for Python 3.10 support. Best, [1] https://salsa.debian.org/python-team/packages/python-nest-asyncio [2] https://github.com/erdewit/nest_asyncio/commit/245dd5bd5902c724cd5478c865769f69c154f609 -- Diego M. Rodriguez
Bug#1001424: python-nest-asyncio: (autopkgtest) needs update for python3.10: TypeError: gather() got an unexpected keyword argument 'loop'
Control: tag -1 pending Hi Paul, thanks for the bug report - I have prepared an upload of a new upstream version that includes a fix [2] for Python 3.10 support. Best, [1] https://salsa.debian.org/python-team/packages/python-nest-asyncio [2] https://github.com/erdewit/nest_asyncio/commit/245dd5bd5902c724cd5478c865769f69c154f609 -- Diego M. Rodriguez
Bug#994266: pyjwt breaks azure-cli autopkgtest: Could not deserialize key data. The data may be in an incorrect format or it may be encrypted with an unsupported algorithm.
On Tue, 14 Sep 2021 22:30:24 +0200 Paul Gevers wrote: > Currently this regression is blocking the migration of pyjwt to testing > [1]. Due to the nature of this issue, I filed this bug report against > both packages. Can you please investigate the situation and reassign the > bug to the right package? As part of the "investigate" part - this might be related to a hotfix introduced in azure-cli 2.26.1 [1], which includes a change on how the "jwt.decode()" call related to the "verify" parameter [2]. pyjwt seems to have deprecated it in its 2.0 release [3] (and a number of similar in its upstream repo also point to that parameter). [1] https://github.com/MicrosoftDocs/azure-docs-cli/blob/master/docs-ref-conceptual/release-notes-azure-cli.md#storage-2 [2] https://github.com/Azure/azure-cli/pull/18811 [3] https://github.com/jpadilla/pyjwt/blob/master/CHANGELOG.rst#dropped-deprecated-verify_expiration-param-in-jwtdecode -- Diego M. Rodriguez
Bug#995581: ITP: python-oauthenticator -- OAuth authenticator for JupyterHub
Package: wnpp X-Debbugs-Cc: lola...@debian.org Owner: "Diego M. Rodriguez" Severity: wishlist * Package name: python-oauthenticator Version : 14.2.0 Upstream Author : Jupyter Development Team * URL : https://github.com/jupyterhub/oauthenticator * License : BSD-3-clause Programming Lang: Python Description : OAuth authenticator for JupyterHub Provides plugins for JupyterHub to use common OAuth providers, as well as base classes for writing custom authenticators with any OAuth 2.0 provider. This package is an optional dependency of ITP "jupyterhub" [1]. My intent is to package this software under the umbrella of the Debian Python Team. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988775 -- Diego M. Rodriguez
Bug#994975: xsmid: Please make another source-only upload to allow testing migration
Package: xsmid Version: 7.5.0-1 Severity: wishlist Dear Maintainer, thanks for packaging xsmid for Debian - it was a pleasant surprise to see it already on track while working on packaging pythran [1], which has it as a dependency. Would it be possible to make a source-only upload, in order to allow it to progress to testing eventually? Thanks in advance, [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991143 -- Diego M. Rodriguez
Bug#993499: RFS: python-marshmallow-polyfield/5.10-1 -- marshmallow extension for polymorphic fields
On Sat, 18 Sep 2021 05:06:59 +0200 Jeroen Ploemen wrote: > It does. Copyrights have expiry dates too, so the most recent year matters. Thanks - I updated the copyright line in order to include the most recent year as well, along with the comment. -- Diego M. Rodriguez
Bug#993460: RFS: python-jellyfish/0.8.8-1 -- Library for approximate and phonetic matching of strings
Control: tag -1 - moreinfo Hello Jeroen, > copyright: > * various copyright holders listed in d/copyright don't have their names >appear anywhere in the sources. Please refresh and/or add comment >fields detailing what the affected entries are based on. The extra copyright holders were added during the initial ITP review [1], and it seems they corresponded to the upstream git contributors to each individual file by the time of the 0.5-3 release. I have refreshed d/copyright to ensure it matches the authors explicitly mentioned in upstream current LICENSE file and other headers. > Please remove the moreinfo tag (and CC me directly) once you have an > updated package ready. Pinging back after tackling the rest of the issues too - thanks (once again)! [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=807432#27 -- Diego M. Rodriguez
Bug#993499: RFS: python-marshmallow-polyfield/5.10-1 -- marshmallow extension for polymorphic fields
On Fri, 17 Sep 2021 11:30:24 +0200 Jeroen Ploemen wrote: > In that case, for lack of a better option, the upstream git commits could > serve as a basis for the years. Noted - in this instance, 2015 is also the date of the initial git commit in the upstream repo. Could you let me know if your mention of "years" implies also declaring the year of the last commit for this release in d/copyright (ie. 2015-2021)? Thanks, -- Diego M. Rodriguez
Bug#993499: RFS: python-marshmallow-polyfield/5.10-1 -- marshmallow extension for polymorphic fields
Control: tags -1 - moreinfo Hello Jeroen, and thanks for the review! > copyright: where does the 2015 upstream copyright year come from? I think it was added during the initial packaging based on the year of the first upstream public release, but indeed there is no explicit mention of 2015 in the upstream sources. I have added a comment to d/copyright, but I'm not sure if this is the best approach - any guidance would be welcome. > control: > * why hardcode the dependency on python3-marshmallow for the binary pkg? Unintentional - and fixed. > * the build-dep on the same also seems unneeded (at least unless/until > tests are re-enabled, see watch) > > watch: consider using github for upstream releases, as the files > published there include the upstream testsuite missing on pypi. And then > put those tests to good use, of course :) Switched to using github releases, re-enabling the tests during build and also adding autopkgtests. Thanks, -- Diego M. Rodriguez
Bug#993933: RFS: python-gast/0.5.2-1 [ITP] -- compatibility layer for the AST of various Python versions
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "python-gast": * Package name: python-gast Version : 0.5.2-1 Upstream Author : Serge Guelton * URL : https://github.com/serge-sans-paille/gast * License : BSD-3-clause-gast * Vcs : https://salsa.debian.org/python-team/packages/python-gast Section : python It builds those binary packages: python3-gast - compatibility layer for the AST of various Python versions (Python3 version) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/python-gast/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/p/python-gast/python-gast_0.5.2-1.dsc Changes for the initial release: python-gast (0.5.2-1) UNRELEASED; urgency=medium . * Initial release (Closes: #993800) Regards, -- Diego M. Rodriguez
Bug#993346: pytest-mock: please upgrade to latest upstream release
Hello Sandro, On Mon, 6 Sep 2021 22:20:29 -0400 Sandro Tosi wrote: > debian/changelog misses several of your changes, please update and > i'll then sponsor it Thanks - just pushed an update to debian/changelog. -- Diego M. Rodriguez
Bug#993800: ITP: python-gast -- compatibility layer for the AST of various Python versions
Package: wnpp X-Debbugs-Cc: debian-pyt...@lists.debian.org Owner: "Diego M. Rodriguez" Severity: wishlist * Package name: python-gast Version : 0.5.2 Upstream Author : Serge Guelton * URL : https://github.com/serge-sans-paille/gast * License : BSD Programming Lang: Python Description : compatibility layer for the AST of various Python versions Provides an homogeneous API over the Abstract Syntax Trees of various Python versions (including Python 2 and Python 3), which itself is compatible with the standard library "ast" module API. This package is a dependency of ITP "pythran" [1] (and also of ITP "beniget" [2], another dependency itself). My intent is to package this software under the umbrella of the Debian Python team. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991143 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=993797 --- Diego M. Rodriguez
Bug#993797: ITP: python-beniget -- collection of compile-time Python AST analyzers
Package: wnpp X-Debbugs-Cc: debian-pyt...@lists.debian.org, debian-scie...@lists.debian.org Owner: "Diego M. Rodriguez" Severity: wishlist * Package name: python-beniget Version : 0.4.1 Upstream Author : Serge Guelton * URL : https://github.com/serge-sans-paille/beniget * License : BSD Programming Lang: Python Description : collection of compile-time Python AST analyzers Collection of compile-time analyzers of Python Abstract Syntax Trees that can be used as building blocks to write static analyzers or compilers: * Ancestors: map a node to the list of its enclosing nodes * DefUseChains: map a node to the list of definition points in that node * UseDefChains: map a node to its list of potential definitions This package is a dependency of ITP "pythran" [1]. My intent is to package this software under the umbrella of the Debian Python team. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991143 --- Diego M. Rodriguez
Bug#991143: RFP: pythran -- an ahead of time compiler for Python
Control: retitle ITP: pythran -- an ahead of time compiler for Python Hello, I intend to package this software, preferably under the umbrella of the Debian Python Team (on the basis of being useful to a general Python audience)- if the Debian Science Team has a stronger interest or preference, please let me know, I'm fine with that approach as well. On Thu, 15 Jul 2021 17:27:05 +0200 Drew Parsons wrote: > It may require some dependencies to be packaged: > gast > beniget Indeed, it seems to be the case! I'll be filing ITPs for the dependencies accordingly. Best, -- Diego M. Rodriguez
Bug#993499: RFS: python-marshmallow-polyfield/5.10-1 -- marshmallow extension for polymorphic fields
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "python-marshmallow-polyfield": * Package name: python-marshmallow-polyfield Version : 5.10-1 Upstream Author : Matt Bachmann * URL : https://github.com/Bachmann1234/marshmallow-polyfield * License : Apache-2.0 * Vcs : https://salsa.debian.org/python-team/packages/python-marshmallow-polyfield Section : python It builds those binary packages: python3-marshmallow-polyfield - marshmallow extension for polymorphic fields To access further information about this package, please visit the following URL: https://mentors.debian.net/package/python-marshmallow-polyfield/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/p/python-marshmallow-polyfield/python-marshmallow-polyfield_5.10-1.dsc Changes since the last upload: python-marshmallow-polyfield (5.10-1) UNRELEASED; urgency=medium . [ Ondřej Nový ] * d/control: Update Maintainer field with new Debian Python Team contact address. * d/control: Update Vcs-* fields with new Debian Python Team Salsa layout. . [ Diego M. Rodriguez ] * New upstream version 5.10 * d/watch: version 4, use signature * d/control: bump Standards-Version to 4.6.0 (no changes needed) * d/control: set architecture to all Regards, -- Diego M. Rodriguez
Bug#993460: RFS: python-jellyfish/0.8.8-1 -- Library for approximate and phonetic matching of strings
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "python-jellyfish": * Package name: python-jellyfish Version : 0.8.8-1 Upstream Author : James Turk * URL : https://github.com/jamesturk/jellyfish * License : BSD-2-clause * Vcs : https://salsa.debian.org/python-team/packages/python-jellyfish Section : python It builds those binary packages: python-jellyfish-doc - Library for approximate and phonetic matching of strings (documentation) python3-jellyfish - Library for approximate and phonetic matching of strings (Python 3) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/python-jellyfish/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/p/python-jellyfish/python-jellyfish_0.8.8-1.dsc Changes since the last upload: python-jellyfish (0.8.8-1) UNRELEASED; urgency=medium . [ Ondřej Nový ] * d/control: Update Maintainer field with new Debian Python Team contact address. * d/control: Update Vcs-* fields with new Debian Python Team Salsa layout. . [ Debian Janitor ] * Apply multi-arch hints. + python-jellyfish-doc: Add Multi-Arch: foreign. . [ Diego M. Rodriguez ] * d/watch: bump version to 4 * New upstream version 0.8.8 * d/control: bump Standards-Version to 4.6.0 (no changes needed) Regards, -- Diego M. Rodriguez
Bug#993346: pytest-mock: please upgrade to latest upstream release
Control: tags 993346 pending Hello Sandro, On Tue, 31 Aug 2021 00:29:37 -0400 Sandro Tosi wrote: > Please upgrade pytest-mock to the latest version; if you're short on time, > please let me know and i can take care of the upgrade & upload. I have prepared a 3.6.1-1 release in salsa [1] (it seems the existing patches are no longer needed thanks to the work with upstream, and most of the changes were adjustments related to the tests). Still requires review and upload, though. [1] https://salsa.debian.org/python-team/packages/pytest-mock -- Diego M. Rodriguez
Bug#990235: RFS: python-pylatexenc/2.10-1 [ITP] -- Simple LaTeX parser providing conversion to/from unicode
Control: tags 990235 - moreinfo Hello Jeroen, thanks for the review and detailed reply: On Fri, Aug 27, 2021, at 12:59, Jeroen Ploemen wrote: > * The lintian hits on the binary pkg deserve an override: Added two overrides - they are more vague than I would have liked, as it seems that the order in which the offending files are displayed in the warnings is not deterministic. The other alternative seemed to be adding 3x2 individual ones, but resulted in "mismatched-override" warnings. > * Changelog: just the 'Initial release' line closing the ITP bug will do > for a new package. Fixed the changelog, leaving the "Initial release" line. > * Control: why the old compat level 12? Likely it was the one I added when starting packaging a long time ago - bumped to 13. > * Copyright: there's no mention of any copyright later than 2019 held by > Philippe Faist, yet grepping the upstream sources shows entries as > recent as 2021 for that person. Thanks for catching these as well. I added explicit lines to d/copyright for the files that declare a copyright year different than the one declared in LICENSE.txt. > * Rules: what is the override of dh_auto_clean trying to achieve? Helping me clean up the package locally in previous iterations :) Removed, as indeed it was a leftover. > * Rules: the help2man target seems to require an installed package in > order to succeed. Any way to make this work with just the extracted > source package? If not, a comment documenting the requirement would be > useful. I could not find a sensible way to make it work - updated the comment in d/rules in the hopes of making it more explicit. > * Tests: please add non-trivial autopkgtests, based on the upstream > testsuite. Added, thanks again for the example. > Please remove the moreinfo tag (and CC me directly) once you have an > updated package ready. Ditto - hopefully the latest version in salsa is ready for a new review. Best, --- Diego M. Rodriguez
Bug#935395: RFP: python3-anytree -- Tree data library
Hello Simon, On Thu, 22 Aug 2019 10:32:26 +0100 Simon McVittie wrote: > For now I've replaced its use in gtk-doc-tools with a simple > reimplementation (it's a tree data structure, it isn't rocket science), > but in the long term either someone should package anytree, or someone > needs to ask the upstream maintainer of gtk-doc to use a different tree > implementation instead of depending on anytree (in which case this bug > can be closed as wontfix). I think you managed to solve it via the second approach [1], and thus the bug can be indeed be closed? For context, I'm doing a round for trying to work on some RFP packages, and currently attempting to identify the ones with the higher chance of helping improve existing packages. [1] https://gitlab.gnome.org/GNOME/gtk-doc/-/merge_requests/56 -- Diego M. Rodriguez
Bug#985024: python3-num2words: SyntaxWarning during package installation
On Thu, 11 Mar 2021 22:01:47 +0100 Andreas Beckmann wrote: > during a test with piuparts I noticed your package emits a SyntaxWarning > during installation: > [...] The bug seems to have been fixed upstream [1], and is part of a newer 0.5.10 release [2] (which coincidentally seems that is not currently picked up by uscan, likely due to the GitHub URL changes a while back). [1] https://github.com/savoirfairelinux/num2words/pull/240 [2] https://github.com/savoirfairelinux/num2words/releases/tag/v0.5.10 -- Diego M. Rodriguez
Bug#990235: RFS: python-pylatexenc/2.10-1 [ITP] -- Simple LaTeX parser providing conversion to/from unicode
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "python-pylatexenc": * Package name: python-pylatexenc Version : 2.10-1 Upstream Author : Philippe Faist * URL : https://github.com/phfaist/pylatexenc * License : Expat, Expat and W3C, W3C * Vcs : https://salsa.debian.org/python-team/packages/python-pylatexenc Section : python For context, the issues that I most struggled with were: 1. declaring the d/copyright correctly: hopefully this is addressed thanks to the help of the helpful folks of the debian-legal list [1], which involved switching to using GitHub releases as upstream and incorporating their suggestions. 2. including manpages for the 3 executables (as setup.py console_scripts)in the package: initially I attempted to generate them dynamically at build time, but I switched to using a custom target as recommended in [2]. As a side effect of 1, I was able to include a documentation package (rendered from sphinx sources) - I'm unsure if rendering the full documentation as a manpage would be preferred over having individual help2man-generated entries. Any help and further review is more than welcome - the package is maintained at salsa [3]. It builds those binary packages: python3-pylatexenc - Simple LaTeX parser providing conversion to/from unicode python-pylatexenc-doc - Simple LaTeX parser providing conversion to/from unicode (Documentation) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/python-pylatexenc/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/p/python-pylatexenc/python-pylatexenc_2.10-1.dsc Changes for the initial release: python-pylatexenc (2.10-1) UNRELEASED; urgency=medium . [ Diego M. Rodriguez ] * Initial release (Closes: #950664) . [ Ondřej Nový ] * d/control: Update Maintainer field with new Debian Python Team contact address * d/control: Update Vcs-* fields with new Debian Python Team Salsa layout Regards, [1] https://lists.debian.org/debian-legal/2021/06/msg6.html [2] https://wiki.debian.org/ManualPage/help2man [3] https://salsa.debian.org/python-team/packages/python-pylatexenc -- Diego M. Rodriguez
Bug#950664: ITP: pylatexenc -- Simple LaTeX parser providing conversion to/from unicode
Hello Sebastian, and apologies for the long delay in replying. On Wed, Dec 9, 2020, at 13:52, Sebastian Ramacher wrote: > I'd be interested in the package. Have you been able to make any > progress on it? I did some groundwork at salsa [1] for the 2.1 upstream version. The main items that were left unresolved after that initial effort are: 1. seek advice and finalize d/copyright, as there was one particular file [2] where I was unsure how to reflect the licensing. 2. verify that the use of help2man is acceptable for generating the manpages for the scripts (and act accordingly, ie. dropping the help2man invocation in d/rules or create the documentation manually). I still have the intent of continuing the work - any help is appreciated! Best, [1] https://salsa.debian.org/python-team/packages/python-pylatexenc [2] https://github.com/phfaist/pylatexenc/blob/master/tools/unicode.xml --- Diego M. Rodriguez
Bug#954079: magic-wormhole: Fails to send with a type error
Hi Antoine and Guillem, > I've reassigned this bug accordingly. It seems that upgrading the > automat package would fix this. I have prepared an upload of the latest automat version (20.2.0) in salsa [1] that hopefully will go through once a sponsor is found. Best, [1] https://salsa.debian.org/python-team/modules/automat -- Diego M. Rodriguez signature.asc Description: OpenPGP digital signature
Bug#959532: python-nest-asyncio FTBFS: test failures
On Sun, 03 May 2020 14:16:47 +0300 Adrian Bunk wrote: > Version 1.3.2 seems to be fixed. Indeed - thanks for the report and the hint, Adrian. I have just updated salsa [1] with the latest upstream version (1.3.3) and asked for sponsorship for a new upload. [1] https://salsa.debian.org/python-team/modules/python-nest-asyncio -- Diego M. Rodriguez signature.asc Description: OpenPGP digital signature
Bug#951961: androguard: FTBFS: dh_auto_test: error: pybuild --test --test-nose -i python{version} -p "3.8 3.7" returned exit code 13
Hi, > > Failure: ModuleNotFoundError (No module named 'asn1crypto') ... ERROR > > ... I have attempted a fix as merge requests in salsa [1], as it seems to be a dependencies issue. [1] https://salsa.debian.org/python-team/modules/androguard/-/merge_requests/2 Best, -- Diego M. Rodriguez signature.asc Description: OpenPGP digital signature
Bug#950664: ITP: pylatexenc -- Simple LaTeX parser providing conversion to/from unicode
Package: wnpp Severity: wishlist Owner: "Diego M. Rodriguez" * Package name: python-pylatexenc Version : 2.1 Upstream Author : Philippe Faist * URL : https://github.com/phfaist/pylatexenc * License : Expat Programming Lang: Python Description : Simple LaTeX parser providing conversion to/from unicode Provides a "unicode_to_latex()" function which converts a unicode string into LaTeX text and escape sequences, and a module with a series of routines that parse the LaTeX structure of given LaTeX code and return a logical structure of objects suitable for converting into another format such as plain text. The functionality is also exposed via command-line scripts (latexencode, latex2text, latexwalker). This package is an optional dependency for updating the existing qiskit-terra package to its newest version [1]. My intent is to maintain this package under the umbrella of the Debian Python Modules Team. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933060 -- Diego M. Rodriguez signature.asc Description: OpenPGP digital signature
Bug#950072: python-asttokens FTBFS with Python 3.8 as supported version
It seems the issues were also identified upstream and fixed (via [1] and other 3.8-related commits), and made it into a new upstream release (the 2.x line [2]) - I have updated the VCS preparing the new version. [1] https://github.com/gristlabs/asttokens/pull/36 [2] https://github.com/gristlabs/asttokens/releases -- Diego M. Rodriguez signature.asc Description: OpenPGP digital signature
Bug#949531: ITP: qiskit-aer -- Quantum Information Science Kit (Qiskit): Aer
Package: wnpp Severity: wishlist Owner: "Diego M. Rodriguez" User: debian-scie...@lists.debian.org Usertags: field..science * Package name: qiskit-aer Version : 0.3.4 Upstream Author : Qiskit Development Team * URL : https://github.com/Qiskit/qiskit-aer * License : Apache-2.0 Programming Lang: Python, C++ Description : Quantum Information Science Kit (Qiskit): Aer Qiskit (Quantum Information Science Kit) is a collection of software developed by IBM Research for working with short depth quantum circuits and building near term applications and experiments on quantum computers. . This package contains Aer, the element that contains high-performance quantum computing simulators with realistic noise models. I intend to package this software under the umbrella of the Debian Science team. In the same spirit as a recent ITP for qiskit-ibmq-provider [0], this module was previously included in the upstream Qiskit terra package, and is now available as a standalone module (more details about the splitting of the currently packaged version into smaller packages can be found at #933060 [1], along with recent updates to the qiskit-terra debian repository [2]). [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=949383 [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933060 [2] https://salsa.debian.org/science-team/qiskit-terra -- Diego M. Rodriguez signature.asc Description: OpenPGP digital signature
Bug#949383: ITP: qiskit-ibmq-provider -- Quantum Information Science Kit (Qiskit): IBM Q Provider
Package: wnpp Severity: wishlist Owner: "Diego M. Rodriguez" User: debian-scie...@lists.debian.org Usertags: field..science * Package name: qiskit-ibmq-provider Version : 0.4.5 Upstream Author : Qiskit Development Team * URL : https://github.com/Qiskit/qiskit-ibmq-provider * License : Apache-2.0 Programming Lang: Python Description : Quantum Information Science Kit (Qiskit): IBM Q Provider Qiskit (Quantum Information Science Kit) is a collection of software developed by IBM Research for working with short depth quantum circuits and building near term applications and experiments on quantum computers. . This package contains a provider that allows accessing the online IBM Q quantum devices and simulators. I intent to package this software under the umbrella of the Debian Science team. This module was previously included in the upstream Qiskit terra package, and is now available as a standalone module (more details about the splitting of the currently packaged version into smaller packages can be found at #933060 [1], along with recent updates to the qiskit-terra debian repository [2]). [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933060 [2] https://salsa.debian.org/science-team/qiskit-terra -- Diego M. Rodriguez signature.asc Description: OpenPGP digital signature
Bug#942132: ITP: python-nest-asyncio -- Patch asyncio to allow nested event loops
On 10/10/19 9:04 PM, Sam Hartman wrote: > The above description should be improved. Thanks for your prompt feedback, Sam - I resorted to keeping the same description present in the project's documentation, not being aware that the 3.4 policy actually discourages it explicitly. I'll revise the description during packaging in the hopes of producing a more accurate summary. Best, -- Diego M. Rodriguez signature.asc Description: OpenPGP digital signature
Bug#942136: python-marshmallow: Consider packaging new upstream version (3.2.1)
Package: python-marshmallow Severity: wishlist Dear Maintainer, a few weeks ago, marshmallow published its first non-RC release of the 3.x branch [1], followed up by a number of releases. Would it be possible to update the package accordingly, in order to ensure all the changes in previous RC versions are received and be closer to the stable version? Best regards, [1] https://github.com/marshmallow-code/marshmallow/releases/tag/3.0.0 -- Diego M. Rodriguez signature.asc Description: OpenPGP digital signature
Bug#942133: ITP: python-marshmallow-polyfield -- A marshmallow extension for polymorphic fields
Package: wnpp Severity: wishlist Owner: "Diego M. Rodriguez" * Package name: python-marshmallow-polyfield Version : 5.7 Upstream Author : Matt Bachmann * URL : https://github.com/Bachmann1234/marshmallow-polyfield * License : Apache-2.0 Programming Lang: Python Description : A marshmallow extension for polymorphic fields marshmallow extension that adds a custom field designed for polymorphic types, allowing defining schemas that say "this field accepts anything of type X". This field should support the same properties as other marshmallow fields, including "required", "allow_none", and "many". This package is a dependency for updating the existing qiskit-terra package to its newest version. The intent is to maintain this package under the umbrella of the Debian Python Modules Team. -- Diego M. Rodriguez signature.asc Description: OpenPGP digital signature
Bug#942132: ITP: python-nest-asyncio -- Patch asyncio to allow nested event loops
Package: wnpp Severity: wishlist Owner: "Diego M. Rodriguez" * Package name: python-nest-asyncio Version : 1.2.0 Upstream Author : Ewald R. de Wit * URL : https://github.com/erdewit/nest_asyncio * License : BSD-2-clause Programming Lang: Python Description : Patch asyncio to allow nested event loops By design asyncio does not allow its event loop to be nested. This presents a practical problem: When in an environment where the event loop is already running it's impossible to run tasks and wait for the result. This module patches asyncio to allow nested use of asyncio.run and loop.run_until_complete. This package is a dependency for updating the existing qiskit-terra package to its newest version. The intent is to maintain this package under the umbrella of the Debian Python Modules Team. -- Diego M. Rodriguez signature.asc Description: OpenPGP digital signature
Bug#933060: qiskit-terra: Consider packaging new upstream version (0.8.2/0.11.1)
Package: qiskit-terra Severity: wishlist Dear Maintainer, a new upstream version (0.8.2 for qiskit-terra [1]) is available, which would be great to package in order to take advantage of the new features. Please note as that along with the 0.7.0 upstream release [2], the initial "qiskit" package was renamed to "qiskit-terra" and split into different components, each of them resulting in a pip-installable package in separate upstream repositories (plus a parent "qiskit" package [3] that includes them as dependencies). In order to keep the debian packages in sync with upstream, a proposal would be to: * keep this debian package as the package for the "qiskit-terra" upstream component (dropping the current binaries and instead producing "python3-qiskit-terra"). * gradually package the rest of the components in new debian packages (for example, the current binary "qasm-simulator-cpp" is superseeded by "qiskit-aer"). * conclude by creating another package that mimics the "qiskit" upstream dependency package and produces also the documentation. Best, [1] https://github.com/Qiskit/qiskit-terra/releases/tag/0.8.2 [2] https://github.com/Qiskit/qiskit-terra/releases/tag/0.7.0 [3] https://github.com/Qiskit/qiskit/releases/tag/0.11.1 -- Diego M. Rodriguez
Bug#932435: RFS: python-jellyfish/0.6.1-1
Hello Adam, thanks for your prompt review and detailed comments. Shortly after your reply, Ondřej Nový helpfully added some commits in salsa and after some exchange, the package was sponsored with the additional improvements - apologies for the confusion and the timing. Nevertheless: > Looks good to me. Not uploading, per the request in the changelog > (or did you forget to unmark it as UNRELEASED?). It was indeed an unintended omission on my part - noted for future changes and requests :) > Unless your point is to do two uploads, to ease review and help bisect > regressions -- a noble goal (for me, especially the part about easing review > :p), but you'd need to drop the py2 build later anyway. Correct - the uploading of 0.6.1 was intended to be followed-up by a 0.7.2 version eventually, partly because I was not confident about the amount of changes and would benefit from a more digestible review, and also partly under the (wrong) assumption that a recent py2 version might have been useful somehow. In the end, the python-jellyfish (Python2) package was dropped [1] during this upload already, in accordance to the recent DPMT policies. Again - many thanks! [1] https://salsa.debian.org/python-team/modules/python-jellyfish/commit/935c8249b66c2938f2146c1de3f8a9442ab23c32 -- Diego M. Rodriguez
Bug#932435: RFS: python-jellyfish/0.6.1-1
Package: sponsorship-requests
Severity: normal
Dear mentors,
I am looking for a sponsor for my package "python-jellyfish"
* Package name: python-jellyfish
Version : 0.6.1-1
Upstream Author : James Turk
* URL : https://github.com/jamesturk/jellyfish
* License : BSD-2-clause
Section : python
It builds those binary packages:
python-jellyfish - Library for approximate and phonetic matching of strings
(Python 2)
python3-jellyfish - Library for approximate and phonetic matching of strings
(Python 3)
python-jellyfish-doc - Library for approximate and phonetic matching of strings
(documentation)
To access further information about this package, please visit the following
URL:
https://mentors.debian.net/package/python-jellyfish
Alternatively, one can download the package with dget using this command:
dget -x
https://mentors.debian.net/debian/pool/main/p/python-jellyfish/python-jellyfish_0.6.1-1.dsc
More information about python-jellyfish can be obtained from
https://github.com/jamesturk/jellyfish.
Changes since the last upload:
[ Ondřej Nový ]
* d/control: Set Vcs-* to salsa.debian.org
[ Jelmer Vernooij ]
* Remove unnecessary X-Python{,3}-Version field in debian/control.
[ Diego M. Rodriguez ]
* Refresh patches after git-dpm to gbp pq conversion
* d/control: update python3-sphinx build-depends
* d/watch: update URL to https
* New upstream release
* Bump Standards-Version to 4.3.0
* d/control: update maintainer email address
Please note that the version is not the latest upstream release in an attempt
to package the last version with Python 2 support. From the official
documentation [1]:
> Jellyfish >= 0.7 only supports Python 3, if you need Python 2 please use
> 0.6.x.
Overall, this upload is an attempt to revive the jellyfish package that I
previously uploaded, an includes a number of changes as a result (including a
change in my email address, contributions by other helpful maintainers in order
to tidy up the package, and several bumps to the standards version).
[1] https://github.com/jamesturk/jellyfish/blob/master/README.rst
Regards,
---
Diego M. Rodriguez
Bug#872340: RFS: golang-github-dlclark-regexp2/1.1.6-1
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "golang-github-dlclark-regexp2" * Package name: golang-github-dlclark-regexp2 Version : 1.1.6-1 Upstream Author : Douglas Clark <doug.cl...@concur.com> * URL : https://github.com/dlclark/regexp2 * License : Expat Section : devel It builds those binary packages: golang-github-dlclark-regexp2-dev - Regex engine for Go based on the .NET engine To access further information about this package, please visit the following URL: https://mentors.debian.net/package/golang-github-dlclark-regexp2 Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/g/golang-github-dlclark-regexp2/golang-github-dlclark-regexp2_1.1.6-1.dsc Changes since the last upload: * new upstream version. Regards, Diego M. Rodriguez
Bug#872320: RFS: golang-github-dop251-goja/0.0~git20170430.0.d382686-2
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "golang-github-dop251-goja" * Package name: golang-github-dop251-goja Version : 0.0~git20170430.0.d382686-2 Upstream Author : Dmitry Panov <d...@itoolabs.com> * URL : https://github.com/dop251/goja * License : Expat Section : devel It builds those binary packages: golang-github-dop251-goja-dev - ECMAScript 5.1(+) implementation written in Go To access further information about this package, please visit the following URL: https://mentors.debian.net/package/golang-github-dop251-goja Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/g/golang-github-dop251-goja/golang-github-dop251-goja_0.0~git20170430.0.d382686-2.dsc More information about hello can be obtained from https://www.example.com. Changes since the last upload: * Mark as autopkgtest-able, add tzdata build-depend (Closes: #871203) * Bump Standards-Version to 4.0.0 Regards, Diego M. Rodriguez
Bug#869198: RFS: golang-github-shibukawa-configdir/0.0~git20170330.0.e180dbd-1 [ITP]
Package: sponsorship-requests Severity: normal [important for RC bugs, wishlist for new packages] Dear mentors, I am looking for a sponsor for my package "golang-github-shibukawa-configdir" * Package name: golang-github-shibukawa-configdir Version : 0.0~git20170330.0.e180dbd-1 Upstream Author : Yoshiki Shibukawa * URL : https://github.com/shibukawa/configdir * License : Expat Section : devel It builds those binary packages: golang-github-shibukawa-configdir-dev - Configuration directories handling for Go To access further information about this package, please visit the following URL: https://mentors.debian.net/package/golang-github-shibukawa-configdir Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/g/golang-github-shibukawa-configdir/golang-github-shibukawa-configdir_0.0~git20170330.0.e180dbd-1.dsc Or on the following repository: https://anonscm.debian.org/cgit/pkg-go/packages/golang-github-shibukawa-configdir.git Changes since the last upload: * Initial release. (Closes: #868050) Regards, Diego M. Rodriguez
Bug#868050: ITP: golang-github-shibukawa-configdir -- Configuration directories handling for Go
Package: wnpp Severity: wishlist Owner: Diego M. Rodriguez <diego.pl...@gmail.com> * Package name: golang-github-shibukawa-configdir Version : 0.0~git20170330.0.e180dbd-1 Upstream Author : Yoshiki Shibukawa * URL : https://github.com/shibukawa/configdir * License : Expat Programming Lang: Go Description : Configuration directories handling for Go configdir is a library for transparently accessing files under configuration directories or cache directories regardless of the operative system's convention.
Bug#862768: golang-github-mattn-go-isatty: Please package newer upstream v0.0.2
Source: golang-github-mattn-go-isatty Severity: wishlist Dear Maintainer, the version in debian is 0.0.1-1, while the latest upstream is 0.0.2 [1]. Would it be possible to package the newer upstream version? This request spawned from the work on packaging another Go application for Debian [2] which requires a new version of golang-github-fatih-color [3] which in turn depends on the newest version of this package. Thanks a lot in advance, [1] https://github.com/mattn/go-isatty/releases/tag/v0.0.2 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=858353 [3] https://packages.qa.debian.org/g/golang-github-fatih-color.html -- Diego M. Rodriguez 36B3 42A9 9F2F 2CFB F79B FF9B B6C4 B901 06BC E232 signature.asc Description: Digital signature
Bug#862767: golang-github-fatih-color: Please package newer upstream v1.4.1
Source: golang-github-fatih-color Severity: wishlist Dear Maintainer, the version in Debian is 1.1.0-1, while the latest upstream is 1.4.1 [1]. Would it be possible to package the newer upstream version (or at least a version higher or equal than 1.3.0)? This request spawned from the work on packaging another Go application for Debian [2] which unfortunately makes use of the newer Sprint* functions introduced in the aforementioned version. There seems to be no extra modifications or patches for the new version compared to the version existing on the repositories, other than also updating golang-github-mattn-go-isatty [3] in the process. Thanks in advance, [1] https://github.com/fatih/color/releases/tag/v1.4.0 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=858353 [3] https://packages.qa.debian.org/g/golang-github-mattn-go-isatty.html -- Diego M. Rodriguez 36B3 42A9 9F2F 2CFB F79B FF9B B6C4 B901 06BC E232 signature.asc Description: Digital signature
Bug#861832: RFS: golang-github-serenize-snaker/0.0~git20170425.0.1c7f653-1 [ITP]
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "golang-github-serenize-snaker" * Package name: golang-github-serenize-snaker Version : 0.0~git20170425.0.1c7f653-1 Upstream Author : Serenize UG <i...@serenize.com> * URL : https://github.com/serenize/snaker * License : Expat Section : devel It builds those binary packages: golang-github-serenize-snaker-dev - Convert camel cased strings to snake case and back To access further information about this package, please visit the following URL: https://mentors.debian.net/package/golang-github-serenize-snaker Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/g/golang-github-serenize-snaker/golang-github-serenize-snaker_0.0~git20170425.0.1c7f653-1.dsc Changes since the last upload: * Initial release (Closes: #861827) Regards, Diego M. Rodriguez
Bug#861831: RFS: golang-github-viki-org-dnscache/0.0~git20130720.0.c70c1f2-1 [ITP]
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "golang-github-viki-org-dnscache" * Package name: golang-github-viki-org-dnscache Version : 0.0~git20130720.0.c70c1f2-1 Upstream Author : Viki Inc. <engineer...@viki.com> * URL : https://github.com/viki-org/dnscache * License : Expat Section : devel It builds those binary packages: golang-github-viki-org-dnscache-dev - DNS cache for Go To access further information about this package, please visit the following URL: https://mentors.debian.net/package/golang-github-viki-org-dnscache Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/g/golang-github-viki-org-dnscache/golang-github-viki-org-dnscache_0.0~git20130720.0.c70c1f2-1.dsc Or on the following repository: https://anonscm.debian.org/cgit/pkg-go/packages/golang-github-viki-org-dnscache.git Changes since the last upload: * Initial release (Closes: #861825) Regards, Diego M. Rodriguez
Bug#861827: ITP: golang-github-serenize-snaker -- Convert camel cased strings to snake case and back
Package: wnpp Severity: wishlist Owner: Diego M. Rodriguez <diego.pl...@gmail.com> * Package name: golang-github-serenize-snaker Version : 0.0~git20170425.0.1c7f653-1 Upstream Author : Serenize UG * URL : https://github.com/serenize/snaker * License : Expat Programming Lang: Go Description : Convert camel cased strings to snake case and back This is a small Go library to convert camel cased strings to snake case and back, except some defined words such as common acronyms and initialisms). This library is being packaged as a build dependency of loadimpact/k6 (loadimpact/k6 -> serenize/snaker).
Bug#861825: ITP: golang-github-viki-org-dnscache -- A DNS Cache for Go
Package: wnpp Severity: wishlist Owner: Diego M. Rodriguez <diego.pl...@gmail.com> * Package name: golang-github-viki-org-dnscache Version : 0.0~git20130720.0.c70c1f2-1 Upstream Author : Viki Inc. * URL : https://github.com/viki-org/dnscache * License : Expat Programming Lang: Go Description : A DNS cache for Go A thread-safe DNS cache for the Go programming language that refreshes the DNS entries in the background at configurable intervals, reducing the risk of blocked/leaking Go routines. This library is being packaged as a build dependency of loadimpact/k6 (loadimpact/k6 -> viki-org/dnscache).
Bug#861823: RFS: golang-github-manyminds-api2go/1.0-RC2+git20161229.31.dc368bb-1 [ITP]
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "golang-github-manyminds-api2go" * Package name: golang-github-manyminds-api2go Version : 1.0-RC2+git20161229.31.dc368bb-1 Upstream Author : Manyminds <n.wagenson...@manyminds.de> * URL : https://github.com/manyminds/api2go * License : Expat Section : devel It builds those binary packages: golang-github-manyminds-api2go-dev - JSONAPI.org implementation for Go To access further information about this package, please visit the following URL: https://mentors.debian.net/package/golang-github-manyminds-api2go Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/g/golang-github-manyminds-api2go/golang-github-manyminds-api2go_1.0-RC2+git20161229.31.dc368bb-1.dsc Or on the following repository: https://anonscm.debian.org/cgit/pkg-go/packages/golang-github-manyminds-api2go.git Changes since the last upload: * Initial release (Closes: #858354) Regards, Diego M. Rodriguez
Bug#861811: RFS: golang-github-dop251-goja/0.0~git20170430.0.d382686-1 [ITP]
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "golang-github-dop251-goja" * Package name: golang-github-dop251-goja Version : 0.0~git20170430.0.d382686-1 Upstream Author : Dmitry Panov <d...@itoolabs.com> * URL : https://github.com/dop251/goja * License : Expat Section : devel It builds those binary packages: golang-github-dop251-goja-dev - ECMAScript 5.1(+) implementation written in Go To access further information about this package, please visit the following URL: https://mentors.debian.net/package/golang-github-dop251-goja Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/g/golang-github-dop251-goja/golang-github-dop251-goja_0.0~git20170430.0.d382686-1.dsc Or on the following repository: https://anonscm.debian.org/cgit/pkg-go/packages/golang-github-dop251-goja.git Changes since the last upload: * Initial release (Closes: #858357) Regards, Diego M. Rodriguez
Bug#861805: RFS: golang-github-puerkitobio-goquery/1.1.0+git20170324.3.ed7d758-1 [ITP]
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "golang-github-puerkitobio-goquery" * Package name: golang-github-puerkitobio-goquery Version : 1.1.0+git20170324.3.ed7d758-1 Upstream Author : Martin Angers <martin.n.ang...@gmail.com> * URL : https://github.com/PuerkitoBio/goquery * License : BSD-3-clause Section : devel It builds those binary packages: golang-github-puerkitobio-goquery-dev - jQuery-style HTML manipulation in Go To access further information about this package, please visit the following URL: https://mentors.debian.net/package/golang-github-puerkitobio-goquery Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/g/golang-github-puerkitobio-goquery/golang-github-puerkitobio-goquery_1.1.0+git20170324.3.ed7d758-1.dsc Or on the following repository: https://anonscm.debian.org/cgit/pkg-go/packages/golang-github-puerkitobio-goquery.git Changes since the last upload: * Initial release (Closes: #858359) Regards, Diego M. Rodriguez
Bug#860185: RFS: golang-github-andybalholm-cascadia/0.0~git20161224.0.349dd02-1 [ITP]
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "golang-github-andybalholm-cascadia" * Package name: golang-github-andybalholm-cascadia Version : 0.0~git20161224.0.349dd02-1 Upstream Author : Andy Balholm <a...@balholm.com> * URL : https://github.com/andybalholm/cascadia * License : BSD-2-clause Section : devel It builds those binary packages: golang-github-andybalholm-cascadia-dev - CSS selector library in Go To access further information about this package, please visit the following URL: https://mentors.debian.net/package/golang-github-andybalholm-cascadia Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/g/golang-github-andybalholm-cascadia/golang-github-andybalholm-cascadia_0.0~git20161224.0.349dd02-1.dsc Or on the following repository: https://anonscm.debian.org/cgit/pkg-go/packages/golang-github-andybalholm-cascadia.git Regards, Diego M. Rodriguez
Bug#860184: RFS: golang-github-gedex-inflector/0.0~git20170307.0.16278e9-1 [ITP]
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "golang-github-gedex-inflector" * Package name: golang-github-gedex-inflector Version : 0.0~git20170307.0.16278e9-1 Upstream Author : Akeda Bagus <ad...@gedex.web.id> * URL : https://github.com/gedex/inflector * License : BSD-2-clause Section : devel It builds those binary packages: golang-github-gedex-inflector-dev - Go library that pluralizes and singularizes English nouns To access further information about this package, please visit the following URL: https://mentors.debian.net/package/golang-github-gedex-inflector Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/g/golang-github-gedex-inflector/golang-github-gedex-inflector_0.0~git20170307.0.16278e9-1.dsc Or on the following repository: https://anonscm.debian.org/cgit/pkg-go/packages/golang-github-gedex-inflector.git Regards, Diego M. Rodriguez
Bug#860181: RFS: golang-github-dlclark-regexp2/1.1.4+git20170331.0.902a5ce-1 [ITP]
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "golang-github-dlclark-regexp2" * Package name: golang-github-dlclark-regexp2 Version : 1.1.4+git20170331.0.902a5ce-1 Upstream Author : Douglas Clark <doug.cl...@concur.com> * URL : https://github.com/dlclark/regexp2 * License : Expat Section : devel It builds those binary packages: golang-github-dlclark-regexp2-dev - Regex engine for Go based on the .NET engine To access further information about this package, please visit the following URL: https://mentors.debian.net/package/golang-github-dlclark-regexp2 Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/g/golang-github-dlclark-regexp2/golang-github-dlclark-regexp2_1.1.4+git20170331.0.902a5ce-1.dsc Or on the following repository: https://anonscm.debian.org/cgit/pkg-go/packages/golang-github-dlclark-regexp2.git Regards, Diego M. Rodriguez
Bug#860174: RFS: golang-gopkg-guregu-null.v3/3.1+git20160228.0.41961ce-1 [ITP]
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "golang-gopkg-guregu-null.v3" * Package name: golang-gopkg-guregu-null.v3 Version : 3.1+git20160228.0.41961ce-1 Upstream Author : Greg Roseberry <g...@toki.waseda.jp> * URL : https://github.com/guregu/null * License : BSD-2-clause Section : devel It builds those binary packages: golang-gopkg-guregu-null.v3-dev - Reasonable handling of nullable SQL and JSON values To access further information about this package, please visit the following URL: https://mentors.debian.net/package/golang-gopkg-guregu-null.v3 Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/g/golang-gopkg-guregu-null.v3/golang-gopkg-guregu-null.v3_3.1+git20160228.0.41961ce-1.dsc Or on the following repository: https://anonscm.debian.org/cgit/pkg-go/packages/golang-gopkg-guregu-null.v3.git Regards, Diego M. Rodriguez
Bug#860173: RFS: golang-gopkg-guregu-null.v2/2.2+git20150913.0.4ac4f00-1 [ITP]
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "golang-gopkg-guregu-null.v2" * Package name: golang-gopkg-guregu-null.v2 Version : 2.2+git20150913.0.4ac4f00-1 Upstream Author : Greg Roseberry <g...@toki.waseda.jp> * URL : https://github.com/guregu/null * License : BSD-2-clause Section : devel It builds those binary packages: golang-gopkg-guregu-null.v2-dev - Reasonable handling of nullable SQL and JSON values To access further information about this package, please visit the following URL: https://mentors.debian.net/package/golang-gopkg-guregu-null.v2 Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/g/golang-gopkg-guregu-null.v2/golang-gopkg-guregu-null.v2_2.2+git20150913.0.4ac4f00-1.dsc Or on the following repository: https://anonscm.debian.org/cgit/pkg-go/packages/golang-gopkg-guregu-null.v2.git Regards, Diego M. Rodriguez
Bug#858353: ITP: k6 -- A modern load testing tool, using Go and JavaScript
Package: wnpp Severity: wishlist Owner: Diego M. Rodriguez <diego.pl...@gmail.com> * Package name: k6 Version : 0.12.1+git20170316.24.c8b5234-1 Upstream Author : Load Impact * URL : https://github.com/loadimpact/k6 * License : AGPL-3.0 Programming Lang: Go Description : A modern load testing tool, using Go and JavaScript k6 is a modern load testing tool built in Go and Javascript. It provides a clean, approachable scripting API, distributed and cloud execution, and orchestration via a REST API. . k6 works with the concept of configurable virtual users (VUs, essentially parallel loops) which run scripts written using JavaScript, as ES6 modules, allowing larger tests to be broken into smaller or reusable pieces.
Bug#858361: ITP: golang-gopkg-guregu-null.v3 -- Reasonable handling of nullable SQL and JSON values
Package: wnpp Severity: wishlist Owner: Diego M. Rodriguez <diego.pl...@gmail.com> * Package name: golang-gopkg-guregu-null.v2 Version : 3.1+git20160228.0.41961ce-1 Upstream Author : Greg Roseberry * URL : http://gopkg.in/guregu/null.v3 * License : BSD-2-clause Programming Lang: Go Description : Reasonable handling of nullable SQL and JSON values This library contains SQL types that consider zero input and null input as separate values, with convenient support for JSON and text marshaling in Go. This library is being packaged as a build dependency of loadimpact/k6 (loadimpact/k6 -> guregu/null.v3).
Bug#858360: ITP: golang-github-andybalholm-cascadia -- CSS selector library in Go
Package: wnpp Severity: wishlist Owner: Diego M. Rodriguez <diego.pl...@gmail.com> * Package name: golang-github-andybalholm-cascadia Version : 0.0~git20161224.0.349dd02-1 Upstream Author : Andy Balholm * URL : https://github.com/andybalholm/cascadia * License : BSD-2-clause Programming Lang: Go Description : CSS selector library in Go This package implements CSS selectors for use with the parse trees produced by the html package. This library is being packaged as a build dependency of loadimpact/k6 (loadimpact/k6 -> puerkitobio/goquery -> andybalhom/cascadia).
Bug#858358: ITP: golang-github-dlclark-regexp2 -- A regex engine for Go based on the .NET engine
Package: wnpp Severity: wishlist Owner: Diego M. Rodriguez <diego.pl...@gmail.com> * Package name: golang-github-dlclark-regexp2 Version : 1.1.3+git20170219.0.3f97b6a-1 Upstream Author : Doug Clark * URL : https://github.com/dlclark/regexp2 * License : Expat Programming Lang: Go Description : A regex engine for Go based on the .NET engine Feature-rich regular expression engine for Go ported from the .NET framework's System.Text.RegularExpressions.Regex engine. It does not have constant time guarantees like the built-in regexp package, but it allows backtracking and is compatible with Perl5 and .NET. This library is being packaged as a build dependency of loadimpact/k6 (loadimpact/k6 -> dop251/goja -> dlclark/regexp2).
Bug#858356: ITP: golang-github-gedex-inflector -- Go library that pluralizes and singularizes English nouns.
Package: wnpp Severity: wishlist Owner: Diego M. Rodriguez <diego.pl...@gmail.com> * Package name: golang-github-gedex-inflector Version : 0.0~git20170307.0.16278e9-1 Upstream Author : Akeda Bagus * URL : https://github.com/gedex/inflector * License : BSD-2-clause Programming Lang: Go Description : Go library that pluralizes and singularizes English nouns. This library provides two functions for pluralizing and singularizing English nouns, inspired by CakePHP's inflector. This library is being packaged as a build dependency of loadimpact/k6 (loadimpact/k6 -> manyminds/api2go -> gedex/inflector).
Bug#858359: ITP: golang-github-puerkitobio-goquery -- jQuery-style HTML manipulation in Go
Package: wnpp Severity: wishlist Owner: Diego M. Rodriguez <diego.pl...@gmail.com> * Package name: golang-github-puerkitobio-goquery Version : 1.1.0+git20170308.2.c641b87-1 Upstream Author : Martin Angers * URL : https://github.com/puerkitobio/goquery * License : BSD-3-clause Programming Lang: Go Description : jQuery-style HTML manipulation in Go goquery brings a syntax and a set of features similar to jQuery (http://jquery.com/) to the Go language, based on Go's net/html package and the CSS Selector library cascadia. . Syntax-wise, it is as close as possible to jQuery, with the same function names when possible, and a chainable interface. This library is being packaged as a build dependency of loadimpact/k6 (loadimpact/k6 -> puerkitobio/goquery).
Bug#858357: ITP: golang-github-dop251-goja -- ECMAScript 5.1(+) implementation written in Go
Package: wnpp Severity: wishlist Owner: Diego M. Rodriguez <diego.pl...@gmail.com> * Package name: golang-github-dop251-goja Version : 0.0~git20170315.0.c99b0db-1 Upstream Author : Dmitry Panov * URL : https://github.com/dop251/goja * License : Expat Programming Lang: Go Description : ECMAScript 5.1(+) implementation written in Go Full ECMAScript 5.1(+) implementation (including regex and strict mode) in Go. . It is not a replacement for V8 or SpiderMonkey or any other general-purpose JavaScript engine as it is much slower. It can be used as an embedded scripting language where the cost of making a lot of cgo calls may outweigh the benefits of a faster JavaScript engine or as a way to avoid having non-Go dependencies. This library is being packaged as a build dependency of loadimpact/k6 (loadimpact/k6 -> dop251/goja).
Bug#858355: ITP: golang-gopkg-guregu-null.v2 -- Reasonable handling of nullable SQL and JSON values
Package: wnpp Severity: wishlist Owner: Diego M. Rodriguez <diego.pl...@gmail.com> * Package name: golang-gopkg-guregu-null.v2 Version : 2.2+git20150913.0.4ac4f00-1 Upstream Author : Greg Roseberry * URL : http://gopkg.in/guregu/null.v2 * License : BSD-2-clause Programming Lang: Go Description : Reasonable handling of nullable SQL and JSON values This library contains SQL types that consider zero input and null input as separate values, with convenient support for JSON and text marshaling in Go. This library is being packaged as a build dependency of loadimpact/k6 (loadimpact/k6 -> manyminds/api2go -> guregu/null.v2).
Bug#858354: ITP: golang-github-manyminds-api2go -- JSONAPI.org implementation for Go
Package: wnpp Severity: wishlist Owner: Diego M. Rodriguez <diego.pl...@gmail.com> * Package name: golang-github-manyminds-api2go Version : 1.0-RC2+git20161229.31.dc368bb-1 Upstream Author : Manyminds * URL : https://github.com/manyminds/api2go * License : Expat Programming Lang: Go Description : JSONAPI.org implementation for Go An implementation of the JSON API (http://jsonapi.org) standard for the Go programming language. This library is being packaged as a build dependency of loadimpact/k6 (loadimpact/k6 -> manyminds/api2go).
Bug#839640: beets: add python-jellyfish dependency
Source: beets
Severity: wishlist
Dear Maintainer,
as the naming conflicts with the jellyfish packages has been resolved
and finally python-jellyfish is available on Debian [1], would it be
possible to drop the "no-jellyfish" patch and introduce a proper
dependency instead for future releases?
I'm including a very tiny svn diff against the current revision. Thanks
as well for your patience during the process, and for the workaround,
[1] https://packages.qa.debian.org/p/python-jellyfish.html
--
Diego M. Rodriguez
36B3 42A9 9F2F 2CFB F79B FF9B B6C4 B901 06BC E232
Index: debian/control
===
--- debian/control (revision 13609)
+++ debian/control (working copy)
@@ -13,6 +13,7 @@
python-bs4,
python-enum34 (>= 1.0.4),
python-flask,
+ python-jellyfish,
python-mock,
python-mpd,
python-munkres,
Index: debian/patches/no-jellyfish
===
--- debian/patches/no-jellyfish (revision 13609)
+++ debian/patches/no-jellyfish (working copy)
@@ -1,86 +0,0 @@
-Description: Bundle levenshtein_distance from jellyfish
- Debian already has a Python library called jellyfish. While we resolve that
- problem, let's avoid the need for re-packaging jellyfish.
-Bug-Debian: https://bugs.debian.org/806716
-Author: Stefano Rivera <stefa...@debian.org>
-
a/beets/autotag/hooks.py
-+++ b/beets/autotag/hooks.py
-@@ -25,7 +25,7 @@
- from beets import config
- from beets.util import as_string
- from beets.autotag import mb
--from jellyfish import levenshtein_distance
-+from beets.util._jellyfish import levenshtein_distance
- from unidecode import unidecode
-
- log = logging.getLogger('beets')
/dev/null
-+++ b/beets/util/_jellyfish.py
-@@ -0,0 +1,56 @@
-+# Borrowed from Jellyfish (https://github.com/jamesturk/jellyfish)
-+# Copyright (c) 2015, James Turk
-+# Copyright (c) 2015, Sunlight Foundation
-+#
-+# All rights reserved.
-+#
-+# Redistribution and use in source and binary forms, with or without
-+# modification, are permitted provided that the following conditions are met:
-+#
-+# * Redistributions of source code must retain the above copyright notice,
-+# this list of conditions and the following disclaimer.
-+# * Redistributions in binary form must reproduce the above copyright
-+# notice, this list of conditions and the following disclaimer in the
-+# documentation and/or other materials provided with the distribution.
-+#
-+# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
-+# AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
-+# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
-+# ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
-+# LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
-+# CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
-+# SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
-+# INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
-+# CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
-+# ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
-+# POSSIBILITY OF SUCH DAMAGE.
-+
-+_range = xrange
-+_no_bytes_err = 'expected unicode, got str'
-+
-+
-+def levenshtein_distance(s1, s2):
-+if isinstance(s1, bytes) or isinstance(s2, bytes):
-+raise TypeError(_no_bytes_err)
-+
-+if s1 == s2:
-+return 0
-+rows = len(s1)+1
-+cols = len(s2)+1
-+
-+if not s1:
-+return cols-1
-+if not s2:
-+return rows-1
-+
-+prev = None
-+cur = range(cols)
-+for r in _range(1, rows):
-+prev, cur = cur, [r] + [0]*(cols-1)
-+for c in _range(1, cols):
-+deletion = prev[c] + 1
-+insertion = cur[c-1] + 1
-+edit = prev[c-1] + (0 if s1[r-1] == s2[c-1] else 1)
-+cur[c] = min(edit, deletion, insertion)
-+
-+return cur[-1]
a/setup.py
-+++ b/setup.py
-@@ -92,7 +92,6 @@
- 'unidecode',
- 'musicbrainzngs>=0.4',
- 'pyyaml',
--'jellyfish',
- ] + (['colorama'] if (sys.platform == 'win32') else []),
-
- tests_require=[
Index: debian/patches/series
===
--- debian/patches/series (revision 13609)
+++ debian/patches/series (working copy)
@@ -1,5 +1,4 @@
fix-test_hidden
-no-jellyfish
fix-test_mediafile_edge
fix-test_nonexistent_file
skip-test_query-path-tests
signature.asc
Description: Digital signature
Bug#837193: beets: apt and beets disagree on beets version
Hello ryan, I'm just chiming in to note that it seems to be basically a "cosmetic" issue already noted in upstream [1], as the upstream 1.3.19 release did not update the string used by "beets version", which hopefully will be corrected in the next upstream release. [1] https://github.com/beetbox/beets/issues/2086 -- Diego M. Rodriguez 36B3 42A9 9F2F 2CFB F79B FF9B B6C4 B901 06BC E232 signature.asc Description: Digital signature
Bug#838677: python-jellyfish: FTBFS: dh: unable to load addon sphinxdoc
Hello Aaron, thanks a lot for reporting the bug and for the hint on how to solve the issue, it's much appreciated! It seems my pbuilder-based setup was not properly tuned to detect the issue during my first round of packaging, but I have switched to sbuild (--no-arch-all) and have been able to replicate the problem. As mentioned on the auto-generated mail, I'm preparing a new release with hopefully includes a fix for this bug [1]. Best regards, [1] https://anonscm.debian.org/cgit/python-modules/packages/python-jellyfish.git/commit/?id=a5915aabd07f8fe8ce396c59298c791942ff625c -- Diego M. Rodriguez 36B3 42A9 9F2F 2CFB F79B FF9B B6C4 B901 06BC E232 signature.asc Description: Digital signature
Bug#807432: RFS: python-jellyfish/0.5.1-1 [ITP]
Hello Gianfranco, > > a ping when the other package is renamed and in testing even better. > I'm finally making effective the ping, as the long-standing naming conflict has been solved on the latest "jellyfish" version (2.2.6-1) [1] (which entered testing on 2016-09-06) by the renaming of its binary package to "python3-dna-jellyfish", thanks to the efforts by Andreas Tille. I have also moved development to Alioth [2] in order to conform to the DPMT procedures, and also built the package from that repository and uploaded a new version to mentors [3]. Thanks again for your patience and your time, [1] https://packages.qa.debian.org/j/jellyfish.html [2] https://anonscm.debian.org/cgit/python-modules/packages/python-jellyfish.git/ [3] https://mentors.debian.net/package/python-jellyfish -- Diego M. Rodriguez 36B3 42A9 9F2F 2CFB F79B FF9B B6C4 B901 06BC E232 signature.asc Description: Digital signature
Bug#806716: Bug#819016: jellyfish: Rename python bindings module name
Hello Andreas, > at first thanks a lot for all your patches and specifically the patience > you had since I was simply waiting for the next upstream version to take > action on this issue. Since upstream has now released 2.2.6 I was > updating the package, applied the patches and uploaded (but it will need > to pass new queue due to the package name change). I'm glad the patches were useful and that the new release is on its way, thanks a lot for your help and cooperation on solving the issue. I'll wait until the package passes the new queue and the dust settles to take further action on this package, but it's great to finally be close to being able to mark this issue completed. > Well, the test was passing in the new upstream version. May be the > issue to run in the right sequence was solved? At least I have not > noticed any problem. At a first glance, I couldn't pinpoint what exactly caused the test order issue to be solved, but it seems to be the case. In any case, if it reappears please ping me back and I'd be more than happy to lend a hand. > > I'm also wondering if it would be a good time to try to contact upstream > > again in the hopes of eventually fixing the conflict upstream, maybe > > via github? I'd be willing to do so, provided you find it acceptable! > > As I said I think its an acceptable solution. I have reported the issue > upstream[1]. Thanks as well for doing so! I'll be keeping an eye on the github issue, in the hopes of reaching a more "universal" solution. Again, thanks a lot, Andreas! -- Diego M. Rodriguez 36B3 42A9 9F2F 2CFB F79B FF9B B6C4 B901 06BC E232 signature.asc Description: Digital signature
Bug#819016: jellyfish: Rename python bindings module name
Hello Andreas,
following the latest discussion at #806716 [1], I'm attaching a patch
that is intended to replace the "update-debian-rules-dh_clean.patch" on
the first message of this bug report, and be used in conjunction with
the "rename-python-module-to-dna_jellyfish.patch".
Hopefully both of them accomplish the renaming of the python module
(to "dna_jellyfish", as per the upstream's author light suggestion on
the mailing list some time ago), and of the Debian binary package (to
"python3-dna-jellyfish").
There is still the issue of running the Python tests to be solved (ie.
they are currently not run in the unpatched version, and the patches
above still don't change the situation). I have been trying to find a
better solution than the one proposed on message #25, still with no
luck. I'm wondering if you could provide input on whether the approach
on #25 is acceptable, or some hints or ideas on how to better solve the
test running issue?
I'm also wondering if it would be a good time to try to contact upstream
again in the hopes of eventually fixing the conflict upstream, maybe
via github? I'd be willing to do so, provided you find it acceptable!
Best regards, and thanks again,
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806716#109
--
Diego M. Rodriguez
36B3 42A9 9F2F 2CFB F79B FF9B B6C4 B901 06BC E232
diff --git a/debian/control b/debian/control
index 8f55e6a..8ab8176 100644
--- a/debian/control
+++ b/debian/control
@@ -90,7 +90,7 @@ Description: count k-mers in DNA sequences (development files of jellyfish)
This package contains the development files (static library and
header files)
-Package: python3-jellyfish
+Package: python3-dna-jellyfish
Architecture: any-amd64
Section: python
Depends: ${python3:Depends},
diff --git a/debian/rules b/debian/rules
index 790ad39..7be0f55 100755
--- a/debian/rules
+++ b/debian/rules
@@ -22,8 +22,8 @@ override_dh_auto_install:
override_dh_install:
# dh_install -X*.a -X*.la -Xpkgconfig
- dh_install -ppython3-jellyfish
- pybuild -d swig/python --name jellyfish
+ dh_install -ppython3-dna-jellyfish
+ pybuild -d swig/python --name dna-jellyfish
dh_auto_configure --sourcedirectory=swig/perl5
dh_auto_build --sourcedirectory=swig/perl5
@@ -55,7 +55,7 @@ override_dh_clean:
rmdir debian/tmp_save_tests ; \
fi
rm -f tests/compat.sh
- rm -f swig/python/jellyfish*
+ rm -f swig/python/jellyfish* swig/python/dna_jellyfish.py
override_dh_auto_build:
mkdir -p debian/tmp_save_tests
signature.asc
Description: Digital signature
Bug#806716: ITP: python-jellyfish -- Python library for doing approximate and phonetic matching of strings
Hello Carl and Andreas, On Sun, Jun 26, 2016 at 07:27:58AM +0200, Andreas Tille wrote: > > While renaming _this_ package was the proposed solution during most of > > the ITP discussions, please be aware that the most recent (~2 months) > > recommendation from #debian-python [1][2] would be to rename _the Python > > DNA package_ instead. I'm still trying to find out Andrea's point of > > view on this recommendation [3], though. > > My point is that I agree. If somebody would commit patches for DNA > Jellyfish this could speed up the action. > > Sorry for not setting the proper priority on this issue Thanks for stating your point of view, Andreas, and no worries in regards to the priority - I fully understand time is a scarce resource! I'll try to retake the work on the existing DNA Jellyfish patches at #819016 (for renaming the module) and append the relevant patches for renaming the binary package in the next days. On Sun, Jun 26, 2016 at 13:02:47 +1000, Carl Suster wrote: > The name src:jellyfish is surely off-limits anyway so this package will need a > different source package name in any case. Since the only consideration is the > binary package name which is fairy painless to rename later, then my > suggestion > would be: > ... Thanks for the reasonable suggestion! However, taking into account Andreas' answer, would it be reasonable to wait a sensible amount of time and see if we manage to fully rename DNA's python-jellyfish before going through with your suggestion, basically for avoiding the renaming "dance" for this package and focusing my efforts in the hopefully final solution? I'm not familiar enough with the full process, though, and cannot estimate how long it would take nor if that would be sensible in regards to the beets' package needs, so I'd basically trust your criteria if you feel the DNA renaming seems to far in the future. Best regards, -- Diego M. Rodriguez 36B3 42A9 9F2F 2CFB F79B FF9B B6C4 B901 06BC E232 signature.asc Description: Digital signature
Bug#806716: ITP: python-jellyfish -- Python library for doing approximate and phonetic matching of strings
Hello Carl, > Has there been any progress on this? As far as I know, unfortunately this issue is still stalled due to waiting on a decision (and action) about the naming conflicts. > Since python3-jellyfish from the DNA package has been in the archive for a > little while, it seems like it would be a bad idea to use that name and hence > the only real option is to differ from upstream here. Maybe > python*-jellyfish-strings (or -matching)? While renaming _this_ package was the proposed solution during most of the ITP discussions, please be aware that the most recent (~2 months) recommendation from #debian-python [1][2] would be to rename _the Python DNA package_ instead. I'm still trying to find out Andrea's point of view on this recommendation [3], though. The details are a bit scattered among the RFS, ITP, etc., but a short recap would be that, for this bug to move forward it would be needed to: 1) rename the existing python3-jellyfish Python bindings *module* name (in progress at [4]) 2) make a decision on which package is to be renamed (this one vs DNA) 3) proceed with the actually renaming of the package I'll be a bit short on time during next week, but I intend to update the package to the newest upstream version (released this week) early next month, and also do my best to try to give another push to getting this ITP forward - any suggestions, comments and help would be much appreciated. Best regards, [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=807432#80 [2] http://paste.debian.net/432489 [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819016#30 [4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819016 -- Diego M. Rodriguez 36B3 42A9 9F2F 2CFB F79B FF9B B6C4 B901 06BC E232 signature.asc Description: Digital signature
Bug#806716: ITP: python-jellyfish -- Python library for doing approximate and phonetic matching of strings
Just a note to reflect that I have just uploaded a new package to mentors (0.5.4-1) [1] as a result of a new upstream release, which fixes a minor problem on the README examples [2], among other changes. [1] https://mentors.debian.net/package/python-jellyfish [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=807432#70 -- Diego M. Rodriguez 36B3 42A9 9F2F 2CFB F79B FF9B B6C4 B901 06BC E232 signature.asc Description: Digital signature
Bug#807432: RFS: python-jellyfish/0.5.1-1 [ITP]
control: block -1 by 819016 Hello Giafranco, > FWIW adding "u" to the strings indeed fixed the issue > e.g. 'string' becomes u'string' (IIRC forcing unicode) thanks, it's been confirmed by upstream and promptly fixed on the upstream repository [1]. > BTW, the Python policy is something like > "python-foo" means "import foo" works. > Adding str migth deviate from the policy, you might want to ask #-python > about this specific issue (and quote the conversation here) thanks for letting me know about the potential Policy issue with the package name. After discussing it at #debian-python [2], it seems that the deviation would be acceptable, however it was suggested that the conflicts as a whole would be better solved by renaming the *existing* package: there are 2 reported installations of python3-jellyfish on popcon - I'd rename the other python3-jellyfish now (module and binary package) and a then upload yours with python3-jellyfish name > thanks, I'll wait for your action, I have commented on #819016 in the hopes of discussing the new approach with the maintainer of the existing jellyfish package, and I'll ping you back once the situation is sorted out. Again, thanks a lot, [1] https://github.com/jamesturk/jellyfish/issues/51 [2] http://paste.debian.net/432489 -- Diego M. Rodriguez 36B3 42A9 9F2F 2CFB F79B FF9B B6C4 B901 06BC E232 signature.asc Description: Digital signature
Bug#819016: jellyfish: Rename python bindings module name
Hello Andreas, I dropped by #debian-python yesterday in order to clarify conformance to Python Policy 3.3 as suggested during a review on the ITP [1], and the conversation derived into a suggestion about revisiting the decision we made about the package names (excerpt from the log [2]): Apr 12 17:56:45 there are 2 reported installations of python3-jellyfish on popcon - I'd rename the other python3-jellyfish now (module and binary package) and a then upload yours with python3-jellyfish name I'm wondering if you could share your thoughts on this issue and if you would be open to this change, even if it is quite a deviation from our envisaged solution? I'd be happy to move the discussion to other channels if needed, and again, thanks a lot for your patience on this issue. Best regards, [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=807432#85 [2] http://paste.debian.net/432489 -- Diego M. Rodriguez 36B3 42A9 9F2F 2CFB F79B FF9B B6C4 B901 06BC E232 signature.asc Description: Digital signature
Bug#807432: RFS: python-jellyfish/0.5.1-1 [ITP]
Thanks Paul and Gianfranco for your clarification in regards to the style patches, I was confused by the mention of the check-all-things commands on your initial reply and I appreciate your explanation! > Just a question: > the code in README file, works for python3 but not for python. > However I think its a README fault, not a code fault. I'm quite certain that it is indeed a problem with the README (the library was initially only available on Python 2, and the README.rst has not gone through significant changes since then, even if Python 3 support was introduced around 0.3.2). I'll follow up on upstream, hopefully resulting in a quick fix indeed. > I changed the target to unstable, bumped std-version to 3.9.8 (it got bumped > after my previous review), and uploaded on unstable. ... > https://packages.debian.org/sid/python3-jellyfishoops > > so you have to rename/move it. My apologies if I should have explicitely mentioned it earlier: the conflicts with the existing "jellyfish" Debian package were noticed earlier on [1], and a recent discussion on the ITP bug [2] resulted on an agreement with the jellyfish maintainer that basically should result in: - the *existing* python-jellyfish should have its python module name renamed (work in progress at [3]). - this package should indeed be renamed to something else ( "python-jellyfishstr" being the most likely candidate), and keep the python "jellyfish" module name. I was waiting on #819016 being closed before making the changes to this package (renaming + uploading to the debian-python git + adding the VCS control fields) - again, sorry if it should have been stated more clearly that the package was not ready for uploading yet due to the naming/module conflicts. I'd be happy to proceed with the renaming right away, if that's ok - in regards to the BTS, would it be preferable to use the control tags (reopen, retitle, block on #819016?) or just submit a new ITP+RFS entirely? Best regards, and thanks again, [1] https://lists.debian.org/debian-python/2016/01/msg1.html [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806716#54 [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819016 -- Diego M. Rodriguez 36B3 42A9 9F2F 2CFB F79B FF9B B6C4 B901 06BC E232 signature.asc Description: Digital signature
Bug#807432: RFS: python-jellyfish/0.5.1-1 [ITP]
Thanks for the review, Gianfranco. I have just uploaded a new version of the package to mentors [1] that fixes some of the issues, although I'd appreciate some further clarification or guidance on a few others: > $ codespell --quiet-level=3 > > $ pyflakes . > > $ pyflakes3 . > > $ pep8 --ignore W191 . On my earlier attempts (<=0.5.1-1) I did include some patches that were aimed towards fixing pep8/flake8 warnings, although I dropped them on the 0.5.3 package. The reason was that upstream has expressed his willingness to ignore E501 and E226 [2], and after a brief discussion at #debian-python I was under the impression that I should "patch it only if you must, pep8 is not a must", favouring closeness to upstream over style fixes. I'm wondering if you could provide a definitive answer on whether to patch or not patch those issues, as I'm a bit unsure and I'd be happy to proceed with either solution. > one license seems missing > ./.run_with_env.cmd::: License: CC0 1.0 Universal: > http://creativecommons.org/publicdomain/zero/1.0/ This might be related to the github vs pypi issue raised by Víctor on a previous comment: the PyPI package [3] does not seem to contain the aforementioned file, but the github release does. The intent was to use the PyPI packages during the building process (specially after 0.5.3, as they now include the docs/ and test/ files) as declared in debian/watch, although I left references to the github repository in debian/control (Homepage:) and debian/copyright (Source) as I felt they better reflected the "official" homepage of the package. > please run wrap-and-sort Done. > std-version is 3.9.7 Done. > python-all (>= 2.6.6-3~), > this seems satisfied even in oldstable This is basically a result of following the Python Library Style Guide at [4], and feels rather conservative indeed. I'm not sure if you are suggesting dropping the version specification entirely, or any other measures? > isn't sphinx a build-depends-indep? This was also a result of following [4] - although in this case sphinx it is only used for building the documentation package indeed. As a result, I have moved sphinx and python-docutils to build-depends-indep as you suggested. Again, thanks a lot for the review! [1] https://mentors.debian.net/package/python-jellyfish [2] https://github.com/jamesturk/jellyfish/pull/50 [3] https://pypi.python.org/pypi/jellyfish/0.5.3 [4] https://wiki.debian.org/Python/LibraryStyleGuide#Build-Depends -- Diego M. Rodriguez 36B3 42A9 9F2F 2CFB F79B FF9B B6C4 B901 06BC E232 signature.asc Description: Digital signature
Bug#819016: jellyfish: Rename python bindings module name
Hello Andreas,
> I need to admit I'm in favour of running any test at build time as well
> as in an autopkgtest (see Debian Continuous Integration) as far as it is
> sensible. So if it turns out that parts of the test suite can not
> sensibly be run under every condition only this part should be excluded.
I see your point, although I was actually not suggesting to skip the
tests entirely at build time, but rather to move their execution from
pybuild to another dh stage, with the reasoning being that "as long as
the tests are executed, there is some leeway in deciding which tool
invokes them".
Perhaps running "pybuild ... --disable test/python3" within
override_dh_auto_build, and then relying on the main makefile to
actually perform tests/swig_python.sh during dh_auto_test would be an
option? I haven't tried that approach yet, and some mangling would
probably be needed to make dh_auto_test aware that the python extension
is available and compiled, but might be doable and have the benefit that
(hopefully) all the tests would be run.
> I have not yet found time to dive into python-jellyfish yet so I'm just
> saying what I would try to approach: If it is easily possible to
> deactivate this part of the test suite that seems troublesome I would
> go for it.
I have tried using the "--pattern" argument to unittest discover [1] to
exclude the problematic test_mer_file.py file, as in:
export PYBUILD_TEST_ARGS=${CURDIR}/swig/python/test_string_mers.py -p
"test_[!m]*.py"
but unfortunately ran into another problem: it seems the test results
depends on the order they are run:
$ python3 -m unittest test_hash_counter.py test_string_mers.py
..F.
==
FAIL: test_all_mers (test_string_mers.TestStringMers)
--
Traceback (most recent call last):
File "/tmp/x/test_string_mers.py", line 21, in test_all_mers
self.assertTrue(good)
AssertionError: False is not true
--
Ran 4 tests in 0.048s
FAILED (failures=1)
$ python3 -m unittest test_string_mers.py test_hash_counter.py
--
Ran 4 tests in 0.049s
OK
I'm still not familiar with jellyfish, but I'm guessing that this is
by design and the library shares some "global" state of sorts (which the
current python test suite has been designed around)?
To work around this issue, I'm including a patch that runs the tests
individually using pybuild (and performs the rpath modification
mentioned on #15 - its only purpose is making libjellyfish-2.0.so
available during the tests, there might be a better way of achieving
it). It should work, but I'm not really happy with the solution and
would be more than willing to help trying to find a better approach if
needed.
Best regards, and thanks a lot for taking the time to look into the
issue,
[1]
https://docs.python.org/3/library/unittest.html#cmdoption-unittest-discover-p
--
Diego M. Rodriguez
36B3 42A9 9F2F 2CFB F79B FF9B B6C4 B901 06BC E232
diff --git a/debian/rules b/debian/rules
index 5d9557e..3fbb357 100755
--- a/debian/rules
+++ b/debian/rules
@@ -13,6 +13,7 @@ export PKG_CONFIG_LIBDIR=${CURDIR}
export PKG_CONFIG_ALLOW_SYSTEM_LIBS=true
export PKG_CONFIG_SYSROOT_DIR=${CURDIR}/debian/tmp/
export PERL_MM_OPT=INSTALLDIRS=vendor
+export PYBUILD_BUILD_ARGS=build_ext --rpath "${CURDIR}/debian/tmp/usr/lib/${DEB_HOST_MULTIARCH}"
%:
dh $@ --with autoreconf,python3 #--parallel
@@ -23,7 +24,10 @@ override_dh_auto_install:
override_dh_install:
# dh_install -X*.a -X*.la -Xpkgconfig
dh_install -ppython3-jellyfish
- pybuild -d swig/python --name jellyfish
+ pybuild -d swig/python --name jellyfish --disable test/python3
+ pybuild -d swig/python --name jellyfish --test --test-args "${CURDIR}/swig/python/ test_string_mers.py"
+ pybuild -d swig/python --name jellyfish --test --test-args "${CURDIR}/swig/python/ test_hash_counter.py"
+ chrpath --delete debian/python3-jellyfish/usr/lib/python*/dist-packages/_dna_jellyfish*.so
dh_auto_configure --sourcedirectory=swig/perl5
dh_auto_build --sourcedirectory=swig/perl5
signature.asc
Description: Digital signature
Bug#819016: jellyfish: Rename python bindings module name
After some more testing, I'm wondering if it would be sensible to just
*not* aim for having the python tests run during pybuild, and instead
stick to running them on a separate stage (or during autopkgtest, which
I have not ventured into yet). The main reason is that one of the tests
(swig/python/test_mer_file.py) seems not really be meant to be executed
using the standard unittest module, as it relies on a "data" variable
created during __main__(), plus some hard-coded references to files
generated during tests/swig_python.sh.
I made some attempts to running the tests during pybuild by:
* building the extension with rpath, removing it with chrpath --delete
right afterwards (kind of negating the "drop-rpath" patch temporarily):
export PYBUILD_BUILD_ARGS=build_ext --rpath
"${CURDIR}/debian/tmp/usr/lib/${DEB_HOST_MULTIARCH}"
...
pybuild ...
chrpath --delete ...
* patching the tests to provide a valid value for the "data" variable
when run via unittest.
* using PYBUILD_BEFORE_TEST and PYBUILD_AFTER_TEST to generate the files
required by the test and place them in a reachable directory, cleaning
up afterwards.
While it seems doable (and probably prone to be refined), it feels
rather unorthodox and introducing some extra complexity for a seamingly
small gain - I'm still not that familiar with the package's build system
and specifics, but suspect that there are better ways to tackle this
issue, and I'd appreciate some hints or thoughts on the best course of
action.
Best regards,
--
Diego M. Rodriguez
36B3 42A9 9F2F 2CFB F79B FF9B B6C4 B901 06BC E232
signature.asc
Description: Digital signature
Bug#819016: jellyfish: Rename python bindings module name
An update on the python tests running, not as exhaustive as I'd like due
to having less time available than initially expected: upon closer
inspection, I believe that indeed the python tests at
swig/python/test*.py are not being currently run during the build, as
hinted on the previous message.
I have tried passing the location of the test folder to unittest using:
export PYBUILD_TEST_ARGS=${CURDIR}/swig/python/
and the tests are picked up during pybuild, although they are erroring
probably due to the library not being still available at that point:
ImportError: libjellyfish-2.0.so.2: cannot open shared object file: No such
file or directory
--
Diego M. Rodriguez
36B3 42A9 9F2F 2CFB F79B FF9B B6C4 B901 06BC E232
signature.asc
Description: Digital signature
Bug#819016: jellyfish: Rename python bindings module name
Source: jellyfish
Severity: wishlist
Dear Maintainer,
after a discussion with Andreas Tille [1], I'm wondering if it would be
possible to rename the python module of the python bindings from
"jellyfish" to "dna_jellyfish", in order to avoid conflicts with an
existing PyPI [2] package, which is also in the process of being
packaged into Debian [3].
A short background on the nature of this change (more details can be
found following he linked discussions, and I'd be happy to provide more
specific pointers if needed), according to my understanding:
* both packages define a "jellyfish" module.
* a consensus in regards to the package names and the module names has
been seeked with moderate results (the most likely being that the
current DNA-jellyfish bindings should retain the "python-jellyfish"
Debian package name, but the actual Python module should be renamed).
* the upstream DNA-jellyfish author has already expressed his
willingness to rename the Python module [4] as it is still not too
widespread, although unfortunately it seems that there has not been too
much movement in this regard in the upstream repository yet.
I'm attaching two patches that would therefore solve this issue on the
Debian end, hoping we can eventually tackle the issue at the upstream
level. As for the new name, the patch uses "dna_jellyfish" since it was
the first alternative suggested by upstream - I'd be happy to switch to
another name if preferred.
Both patches are the output of plain "git diff" against the patched
Debian sources:
rename-python-module-to-dna_jellyfish.patch:
* setup.py: invokes swig using the "-module" argument [5]
* setup.py: renames the Extension and the package name, and updates the
older check to reference the new filename.
* test_*.py: replaces the references to the "jellyfish" module with
"dna_jellyfish".
update-debian-rules-dh_clean.patch:
* debian/rules: updates override_dh_clean to remove the swig generated
.py file.
I still need to do another round to ensure no further changes are
needed: in particular, I still have to confirm that the python tests
are actually executed (debuild output):
---
make check-TESTS
...
SKIP: tests/swig_python.sh
...
running install_egg_info
Writing
/tmp/buildd/jellyfish-2.2.5/debian/python3-jellyfish/usr/lib/python3.5/dist-packages/dna_jellyfish-0.0.1.egg-in
fo
I: pybuild base:184: cd
/tmp/buildd/jellyfish-2.2.5/.pybuild/pythonX.Y_3.5/build; python3.5 -m unittest
discover -v
--
Ran 0 tests in 0.000s
OK
...
---
The same "SKIP: tests/swig_python.sh" and "Ran 0 tests ..." lines also
seem to be present on the current 2.2.5-1 debuild log, so it might not
be an issue after all and a result of me not having gone through all
the details about the testing yet.
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806716#79
[2] https://pypi.python.org/pypi/jellyfish
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806716
[4] https://lists.debian.org/debian-python/2015/12/msg00107.html
[5] http://www.swig.org/Doc3.0/SWIGDocumentation.html#SWIG_nn2
--
Diego M. Rodriguez
36B3 42A9 9F2F 2CFB F79B FF9B B6C4 B901 06BC E232
diff --git a/swig/python/setup.py b/swig/python/setup.py
index b980b87..1edd509 100644
--- a/swig/python/setup.py
+++ b/swig/python/setup.py
@@ -12,13 +12,13 @@ from distutils.core import setup, Extension
swig_time = os.path.getmtime('../jellyfish.i')
older = True
try:
-older = os.path.getmtime('jellyfish_wrap.cxx') < swig_time or os.path.getmtime('jellyfish.py') < swig_time
+older = os.path.getmtime('jellyfish_wrap.cxx') < swig_time or os.path.getmtime('dna_jellyfish.py') < swig_time
except FileNotFoundError:
older = True
if older:
-print("Running swig: swig -c++ -python -o jellyfish_wrap.cxx ../jellyfish.i")
-os.system("swig -c++ -python -o jellyfish_wrap.cxx ../jellyfish.i")
+print("Running swig: swig -c++ -python -module dna_jellyfish -o jellyfish_wrap.cxx ../jellyfish.i")
+os.system("swig -c++ -python -module dna_jellyfish -o jellyfish_wrap.cxx ../jellyfish.i")
jf_include = [re.sub(r'-I', '', x) for x in os.popen("pkg-config --cflags-only-I jellyfish-2.0").read().rstrip().split()]
jf_cflags = os.popen("pkg-config --cflags-only-other jellyfish-2.0").read().rstrip().split()
@@ -28,7 +28,7 @@ jf_libdir = [re.sub(r'-L', '', x) for x in os.popen("pkg-config --libs-only-L j
jf_ldflags = os.popen("pkg-config --libs-only-other jellyfish-2.0").read().rstrip().split()
-jellyfish_module = Extension('_jellyfish',
+jellyfish_module = Extension('_dna_jellyfish',
sources = ['jellyfish_wrap.cxx'],
include_dirs = jf_include,
libraries = jf_libs,
@
Bug#806716: Jellyfish name conflicts
Helo Andreas, > I think if we did not managed a sufficient amount of opinions once there > was a good time to react I think it is a waste of time if you try > afterwards. I learned in Free Software that asking for opinion is > really hard - even if naming discussions usually gather a fair amount of > opinions (keyword bike shedding). The best way is to do something. So > either you tell me: "I'm not happy with the current situation and I'll > send you a patch that renames the DNA jellyfish" - I'd be positive to > aks ftpmaster to let the package pass again the Debian new queue. This > should be done *quickly* before people might adapt to the new package. > If you do not do this we should simply live with the current situation. taking action it is then! I hope it is still not too late for confirming you that I'm indeed willing to work on a patch for renaming the DNA jellyfish python module in the hopes of improving the current situation, and it would be great if you could make the appropiate request to the ftpmaster team. As a matter of fact I hopefully have the basic changes ready and I'll submit a wishlist bug with the patch shortly, aiming for having it fully polished and ready during tomorrow. Thanks again! -- Diego M. Rodriguez 36B3 42A9 9F2F 2CFB F79B FF9B B6C4 B901 06BC E232 signature.asc Description: Digital signature
Bug#806716: Jellyfish name conflicts
Hello Andreas,
> H, ftpmaster was fast - now python-jellyfish is accepted. This only
> leaves us option 2 without fiddling around to much.
I noticed - and feels like yet another argument in favour of option 2.
If there is something I can do to help with the renaming of the DNA
jellyfish python module (collaborating on the upstream repository,
gathering more opinions on the matter, or anything else) I'd be willing
to lend a hand, just let me know!
> > With this in mind, I'm wondering if this would be a good time to rename
> > this ITP and the RFS (and the mentors package, etc) to the hopefully
> > final Debian package name ("python-jellyfishstr"?)?
>
> The latter sounds sensible. Sorry for all the confusion and leaving you
> alone a bit with this issue.
Thanks for sharing your thoughts on the package renaming issue, and no
worries at all - I really apreciate your guidance and efforts on helping
move this issue forward.
Best regards,
--
Diego M. Rodriguez
36B3 42A9 9F2F 2CFB F79B FF9B B6C4 B901 06BC E232
signature.asc
Description: Digital signature
Bug#806716: Jellyfish name conflicts
Hello Andreas,
> This was not really intended but now it happened. We now need to
> decide about the two options:
>
> 1. Cancel the upload to new and drop the python3-jellyfish package
> 2. Just leave this as is and follow the advise of the jellyfish
> author quoted on top of this mail to the python list[4] to
> rename just the Python module.
>
> I think option 2. is better for all parts and if you agree I'd
> immediately cancel the upload to new.
thanks for the detailed clarification on the events surrounding the
package and the prompt response!
I would be happy to go with either option (personally leaning towards
option 2 as well), and basically rely on your expertise - the upstream
string-jellyfish author has explicitely mentioned that he has no strong
opinion on the Debian package name and I don't have either.
With this in mind, I'm wondering if this would be a good time to rename
this ITP and the RFS (and the mentors package, etc) to the hopefully
final Debian package name ("python-jellyfishstr"?)?
Best regards,
--
Diego M. Rodriguez
36B3 42A9 9F2F 2CFB F79B FF9B B6C4 B901 06BC E232
signature.asc
Description: Digital signature
Bug#807432: RFS: python-jellyfish/0.5.1-1 [ITP]
Thanks a lot for the feedback and help, Víctor! > # d/patch > > Please upstream them (in case they aren't already in 0.5.2). > ... > # lintian > > there's a spelling error in manpage: accomodate accommodate (upstream > the fix). I have forwarded both those issues upstream [1], which combined with your pull request will hopefully result in being able to use the tarball directly and indeed remove the extra complexity caused by the use of git submodules once a new version is released. I'll work on the remaining issues (debian/control, debian/copyright) in the meantime, and once the new version is released will make sure that all references to the github repository are removed in favour of the PyPi tarball, and get everything ready for a final cleanup. [1] https://github.com/jamesturk/jellyfish/pull/50 -- Diego M. Rodriguez 36B3 42A9 9F2F 2CFB F79B FF9B B6C4 B901 06BC E232 signature.asc Description: Digital signature
Bug#806716: ITP: python-jellyfish -- Python library for doing approximate and phonetic matching of strings
An update in regards to the Debian package name conflict (ie. not the Python module name conflict discussed on [1]): the upstream author has confirmed that it has "no real preference" over the chosen Debian package name, and we temptatively agreed on using something similar to "python-jellyfishstr" (or a similar variation that hints that the package is string-matching related) if needed. [1] https://lists.debian.org/debian-python/2015/12/msg00107.html -- Diego M. Rodriguez 36B3 42A9 9F2F 2CFB F79B FF9B B6C4 B901 06BC E232 signature.asc Description: Digital signature
Bug#806716: ITP: python-jellyfish -- Python library for doing approximate and phonetic matching of strings
Hello Andreas, > Thanks for your understanding and as said above - some name different > from python-jellyfish would be helpful. Sure thing, and thanks for the clarification on the intent of enabling the bindings on the original package. I fully understand and agree that coming up with a new name seems like the sensible thing to do, and one that would be better handled at this stage before the package is released indeed. I will contact upstream in the hopes of picking a reasonable name for this package, and update the bug and files accordingly. Again, thanks for raising awereness to this issue! Best regards, -- Diego M. Rodriguez 36B3 42A9 9F2F 2CFB F79B FF9B B6C4 B901 06BC E232 signature.asc Description: Digital signature
Bug#806716: ITP: python-jellyfish -- Python library for doing approximate and phonetic matching of strings
Hello Andreas, > I'd leave it to your opinion whether you think there is a chance for > really confusing the packages or whether an additional hint might add > confusion. May be README.Debian would be a less noisy place to mention > this. Thanks again for your feedback and tips, they are most welcome. After taking another look at the situation, I am fairly confident that the risk of conflicts should indeed be minimal, and opted for the README.Debian route. The latest version of the package on mentors and the preliminary VCS has been updated. My only minor doubt comes from the fact that the upstream DNA jellyfish package seems to provide binding to several languages [1], Python being among them. It seems the bindings are currently not being included in Debian as an individual package, but I'm wondering if it would be advisable to preemptively reserve the "python-jellyfish" name for them, just in case they are included in the future. Again, thanks for your comments, and I'd be happy to make any further changes if needed! [1] https://github.com/gmarcais/Jellyfish/tree/develop#binding-to-script-languages -- Diego M. Rodriguez 36B3 42A9 9F2F 2CFB F79B FF9B B6C4 B901 06BC E232 signature.asc Description: Digital signature
Bug#807432: RFS: python-jellyfish/0.5.1-1 [ITP]
Hello Nicholas,
> I believe the package also needs Build-Depends on libpython-all-dev and
> libpython3-all-dev, or the C extensions fail (nonfatally) to compile in a
> clean
> chroot environment.
thanks for the hint - the Build-Depends are indeed needed for successfully
building the C extensions, my apologies for the oversight. I'll make sure to
use a clean chroot for building in the future.
> Unfortunately, the tests also fail - it appears that pytest is not
> successfully
> picking up any tests to run:
thanks as well for pointing it out. It seems that upstream is not strictly
following the standard pytest naming convention for test files, and relying
instead of on some setup.py magic for running the unit tests. I have appended
the following lines to debian/rules, pointing pytest to the right file and
making the testdata .csv files available during testing:
export PYBUILD_BEFORE_TEST = cp -R {dir}/testdata {build_dir}
export PYBUILD_AFTER_TEST = rm -R {build_dir}/testdata
export PYBUILD_TEST_ARGS = jellyfish/test.py
This seemed a bit less intrusive than renaming the jellyfish/test.py file. The
package on mentors and the temporary CVS repository [1] have been updated with
these two changes, as well as including a README.Debian file with some
clarifications about the naming after some discussion at [2].
Additionally, I noticed that the tests result in an error if using the pytest
version at Debian jessie (2.6.3-2):
ERRORS
__ ERROR collecting jellyfish/test.py __
/usr/lib/python3/dist-packages/_pytest/runner.py:139: in __init__
self.result = func()
...
/usr/lib/python3/dist-packages/_pytest/python.py:824: in parametrize
if ids and len(ids) != len(argvalues):
E TypeError: object of type 'type' has no len()
=== 1 error in 0.08 seconds
but they do pass using the pytest version at stretch and above. The culprit
seems to be the usage of the "ids" parameter of the parametrize decorator,
which is set to the built-in "str" on a handful of cases:
jellyfish/test.py:38
@pytest.mark.parametrize("s1,s2,value", _load_data('jaro_winkler'), ids=str)
Older versions of pytest seem to require that the "ids" parameters is strictly
a list or None, not handling callables properly.
I'm wondering what would be the recommended way to deal with situation: would
simply modifying the pytest build-depend so it requires a specific version or
above suffice (even if it might make testing on a stable chroot impossible)?
After some light inspection, it seems that this could probably be solved as
well by a patch that replaces "str" with a valid value (or drops it), and I'd
be happy to follow that path as well, or further inspect the situation.
Again, thanks a look for your insights and taking a look at the package!
[1] https://github.com/diego-plan9/python-jellyfish-mentors
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806716#12
--
Diego M. Rodriguez
36B3 42A9 9F2F 2CFB F79B FF9B B6C4 B901 06BC E232
signature.asc
Description: Digital signature
Bug#806716: ITP: python-jellyfish -- Python library for doing approximate and phonetic matching of strings
Hello Andreas, and thanks for the heads up! I did notice the potential naming conflict and the existence of the DNA-related package you mention on your reply, and opted for simply prepending the "python-" prefix to this package (as upstream also chose just "jellyfish" as the official name of the software). I'd be happy to make the differentiation more obvious, although I could not find the official Debian guidelines for solving these cases. Would it be desirable to rename the package to something less prone to confusion, or would it be enough to include some clarification string on the package description? Best regards, On Wed, Dec 23, 2015 at 09:19:47AM +0100, Andreas Tille wrote: > Hi, > > sorry for the late response. I just want to note that we have a > (non-Python) jellyfish inside Debian which is developed at > https://github.com/gmarcais/Jellyfish. > > I do not see a name conflict but I wonder whether some hint might > be sensible. > > Kind regards > > Andreas. -- Diego M. Rodriguez 36B3 42A9 9F2F 2CFB F79B FF9B B6C4 B901 06BC E232 signature.asc Description: Digital signature
Bug#807432: RFS: python-jellyfish/0.5.1-1 [ITP]
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "python-jellyfish" * Package name: python-jellyfish Version : 0.5.1-1 Upstream Author : James Turk <james.p.t...@gmail.com> * URL : https://github.com/jamesturk/jellyfish * License : BSD-2-clause Section : python It builds those binary packages: python-jellyfish - Library for approximate and phonetic matching of strings (Python 2) python-jellyfish-doc - Library for approximate and phonetic matching of strings (documentation) python3-jellyfish - Library for approximate and phonetic matching of strings (Python 3) To access further information about this package, please visit the following URL: http://mentors.debian.net/package/python-jellyfish Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/p/python-jellyfish/python-jellyfish_0.5.1-1.dsc More information about python-jellyfish can be obtained from https://github.com/jamesturk/jellyfish. Regards, Diego M. Rodriguez signature.asc Description: Digital signature
Bug#806716: ITP: python-jellyfish -- Python library for doing approximate and phonetic matching of strings
Package: wnpp Severity: wishlist Owner: "Diego M. Rodriguez" <diego.pl...@gmail.com> * Package name: python-jellyfish Version : 0.5.1 Upstream Author : James Turk <james.p.t...@gmail.com> * URL : https://github.com/jamesturk/jellyfish * License : BSD-2-clause Programming Lang: Python Description : Python library for doing approximate and phonetic matching of strings Jellyfish is a python library for doing approximate and phonetic matching of strings. Includes algorithms for string comparison (Levenshtein Distance, Damerau-Levenshtein Distance, Jaro Distance, Jaro-Winkler Distance, Match Rating Approach Comparison, Hamming Distance) and phonetic encoding (American Soundex, Metaphone, NYSIIS, Match Rating Codex). This package is a dependency on the latest versions of the "beets" package, as noted in a recent bug report [1]. Jellyfish itself has no external dependencies, and includes an optional C implementation of its algorithms compiled using the distutils build_ext command [2]. Ideally I'd love to maintain this package under the umbrella and hopefully guidance of the Debian Python Modules Team. Please note that this package is unrelated to the existing "jellyfish" debian package [3]. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775719#10 [2] https://github.com/jamesturk/cjellyfish [3] https://packages.debian.org/jessie/jellyfish -- Diego M. Rodriguez 36B3 42A9 9F2F 2CFB F79B FF9B B6C4 B901 06BC E232 signature.asc Description: Digital signature
