Bug#858361: ITP: golang-gopkg-guregu-null.v3 -- Reasonable handling of nullable SQL and JSON values
Package: wnpp Severity: wishlist Owner: Diego M. Rodriguez * 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#858355: ITP: golang-gopkg-guregu-null.v2 -- Reasonable handling of nullable SQL and JSON values
Package: wnpp Severity: wishlist Owner: Diego M. Rodriguez * 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 * 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#858358: ITP: golang-github-dlclark-regexp2 -- A regex engine for Go based on the .NET engine
Package: wnpp Severity: wishlist Owner: Diego M. Rodriguez * 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#858360: ITP: golang-github-andybalholm-cascadia -- CSS selector library in Go
Package: wnpp Severity: wishlist Owner: Diego M. Rodriguez * 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#858356: ITP: golang-github-gedex-inflector -- Go library that pluralizes and singularizes English nouns.
Package: wnpp Severity: wishlist Owner: Diego M. Rodriguez * 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#858353: ITP: k6 -- A modern load testing tool, using Go and JavaScript
Package: wnpp Severity: wishlist Owner: Diego M. Rodriguez * 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#858357: ITP: golang-github-dop251-goja -- ECMAScript 5.1(+) implementation written in Go
Package: wnpp Severity: wishlist Owner: Diego M. Rodriguez * 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#858359: ITP: golang-github-puerkitobio-goquery -- jQuery-style HTML manipulation in Go
Package: wnpp Severity: wishlist Owner: Diego M. Rodriguez * 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#861825: ITP: golang-github-viki-org-dnscache -- A DNS Cache for Go
Package: wnpp Severity: wishlist Owner: Diego M. Rodriguez * 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#861827: ITP: golang-github-serenize-snaker -- Convert camel cased strings to snake case and back
Package: wnpp Severity: wishlist Owner: Diego M. Rodriguez * 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#868050: ITP: golang-github-shibukawa-configdir -- Configuration directories handling for Go
Package: wnpp Severity: wishlist Owner: Diego M. Rodriguez * 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#806716: ITP: python-jellyfish -- Python library for doing approximate and phonetic matching of strings
Package: wnpp Severity: wishlist Owner: "Diego M. Rodriguez" * Package name: python-jellyfish Version : 0.5.1 Upstream Author : James Turk * 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
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#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: 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#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
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 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#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
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: 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#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#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#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
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#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#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#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#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#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#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#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#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#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#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#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#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#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 -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#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#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#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
