Bug#1070452: ITP: pytest-lazy-fixtures -- pytest plugin to use fixtures in @pytest.mark.parametrize
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org, 1063...@bugs.debian.org * Package name: pytest-lazy-fixtures Version : 1.0.7 Upstream Contact: Petrov Anton * URL : https://github.com/dev-petrov/pytest-lazy-fixtures * License : Expat Programming Lang: Python Description : pytest plugin to use fixtures in @pytest.mark.parametrize This plugin was inspired by pytest-lazy-fixture; that plugin is incompatible with pytest 8.x, so this can be used as a replacement. . Improvements that have been made in this project: . * You can use fixtures in any data structures * You can access the attributes of fixtures * You can use functions in fixtures This will allow those packages using pytest-lazy-fixture (which is now unusable in debian/testing) in their tests to migrate to this maintained alternative. (See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1063957) It will be maintained within the Debian Python Team, and I will be listed as an Uploader.
Bug#958024: Package available on Salsa
On Tue, Feb 02, 2021 at 11:03:43AM +0100, Adam Cecile wrote: > Hello, > > I already had a package for this, sadly not uploaded to Salsa. > > I just did: > https://salsa.debian.org/python-team/packages/openapi-spec-validator > > Feel free to get it uploaded into the archive in interested in! > > Regards, Adam. Thanks Adam! I'll pick this one up over the next week or two. Best wishes, Julian
Bug#761152: python-strict-rfc3339: changing from ITP to RFP
retitle 761152 ITP: python-strict-rfc3339 -- Strict, simple, lightweight RFC3339 functions owner 761152 ! thanks On Sun, Dec 27, 2015 at 01:16:59PM +0100, Lucas Nussbaum wrote: > retitle 761152 RFP: python-strict-rfc3339 -- Strict, simple, lightweight > RFC3339 functions > noowner 761152 > tag 761152 - pending > thanks > [...] I've updated Adam Cecile's packaging work on salsa for this package and uploaded it to NEW. (It's a test-time dependency of some of the jupyter* packages or their dependencies.)
Bug#1068553: ITP: python-overrides -- Python decorator to verify that expected overrides are maintained
Oh, oops. Not sure what to suggest at this point; perhaps I could drop a note to the ftpmasters? There's not much difference between them (except that I used pytest to get autopkgtest to work and my package description was much less detailed). Whichever one is accepted, we should certainly drop or archive the salsa repo for the other! I don't have any views either way. Best wishes, Julian On Mon, Apr 08, 2024 at 04:59:13PM +0200, Roland Mas wrote: > overrides is already in NEW, with packaging hosted on > https://salsa.debian.org/python-team/packages/overrides. Sorry, I should > have filed an ITP for that. > > Roland. > > Le 07/04/2024 à 11:02, Julian Gilbey a écrit : > > Package: wnpp > > Severity: wishlist > > Owner: Julian Gilbey > > X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org > > > > * Package name: python-overrides > >Version : 7.7.0 > >Upstream Author : Copyright: Mikko Korpela > > * URL : https://github.com/mkorpela/overrides > > * License : Apache-2.0 > >Programming Lang: Python > >Description : Python decorator to verify that expected overrides are > > maintained > > Provides a decorator @override that verifies that a method that > > should override an inherited method actually does it. Python has no > > standard mechanism by which to guarantee that (1) a method that > > previously overrode an inherited method continues to do so, and (2) a > > method that previously did not override an inherited will not > > override now. This package allows this to be addressed in an automated > > manner. > > > > This package is a (recursive) dependency of the new version of > > jupyter-server. > > > > It will be team-maintained within the Debian Python Team. The Debian > > packaging is on salsa at > > https://salsa.debian.org/python-team/packages/python-overrides > > > Julian
Bug#1068557: ITP: sphinxcontrib-openapi -- Sphinx extension to generate API docs from OpenAPI spec
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org * Package name: sphinxcontrib-openapi Version : 0.8.4 Upstream Author : Ihor Kalnytskyi * URL : https://github.com/sphinx-contrib/openapi * License : BSD-2-clause Programming Lang: Python Description : Sphinx extension to generate API docs from OpenAPI spec This extension generates API documentation for reStructuredText documentation using the Sphinx system. It also depends on `sphinxcontrib.httpdomain` that provides an HTTP domain for describing RESTful HTTP APIs. This package is a (recursive) dependency of the new version of jupyter-server. It will be team-maintained within the Debian Python Team. The Debian packaging is on salsa at https://salsa.debian.org/python-team/packages/sphinxcontrib-openapi
Bug#1068556: ITP: sphinxcontrib-emojicodes -- Sphinx extension to use emoji codes in Sphinx documentation
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org * Package name: sphinxcontrib-emojicodes Version : 0.3.1 Upstream Author : Copyright: The Sphinx Emoji Codes contributors * URL : https://github.com/sphinx-contrib/emojicodes * License : BSD-3-clause Programming Lang: Python Description : Sphinx extension to use emoji codes in Sphinx documentation This extension allows one to write things like |:smile:| in Sphinx documentation. This package is a (recursive) dependency of the new version of jupyter-server. It will be team-maintained within the Debian Python Team. The Debian packaging is on salsa at https://salsa.debian.org/python-team/packages/sphinxcontrib-emojicodes
Bug#1068554: ITP: rfc3339-validator -- RFC 3339 validator (Python library)
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org * Package name: rfc3339-validator Version : 0.1.4 Upstream Author : Nicolas Aimetti * URL : https://github.com/naimetti/rfc3339-validator * License : Expat Programming Lang: Python Description : RFC 3339 validator (Python library) This package provides a validator for date-time strings to determine whether they conform to the Internet Engineering Task Force (IETF) Internet Date/Time Format (RFC 3339). This package is a (recursive) dependency of the new version of jupyter-server. It will be team-maintained within the Debian Python Team. The Debian packaging is on salsa at https://salsa.debian.org/python-team/packages/rfc3339-validator
Bug#1068555: ITP: rfc3986-validator -- RFC 3986 validator (Python library)
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org * Package name: rfc3986-validator Version : 0.1.1 Upstream Author : Nicolas Aimetti * URL : https://github.com/naimetti/rfc3986-validator * License : Expat Programming Lang: Python Description : RFC 3986 validator (Python library) This package provides a validator for URIs to determine whether they conform to the Internet Engineering Task Force (IETF) specification (RFC 3986). This package is a (recursive) dependency of the new version of jupyter-server. It will be team-maintained within the Debian Python Team. The Debian packaging is on salsa at https://salsa.debian.org/python-team/packages/rfc3986-validator
Bug#1068553: ITP: python-overrides -- Python decorator to verify that expected overrides are maintained
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org * Package name: python-overrides Version : 7.7.0 Upstream Author : Copyright: Mikko Korpela * URL : https://github.com/mkorpela/overrides * License : Apache-2.0 Programming Lang: Python Description : Python decorator to verify that expected overrides are maintained Provides a decorator @override that verifies that a method that should override an inherited method actually does it. Python has no standard mechanism by which to guarantee that (1) a method that previously overrode an inherited method continues to do so, and (2) a method that previously did not override an inherited will not override now. This package allows this to be addressed in an automated manner. This package is a (recursive) dependency of the new version of jupyter-server. It will be team-maintained within the Debian Python Team. The Debian packaging is on salsa at https://salsa.debian.org/python-team/packages/python-overrides
Bug#1068552: ITP: python-isoduration -- Operations with ISO 8601 durations (Python 3 package)
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org * Package name: python-isoduration Version : 20.11.0+git20211126.ae0bd61 Upstream Author : Víctor Muñoz * URL : https://github.com/bolsote/isoduration * License : ISC Programming Lang: Python Description : Operations with ISO 8601 durations (Python 3 package) ISO 8601 supports time durations in string format, for example "P3Y6M4DT12H30M5S" represents a duration of 3 years, 6 months, 4 days, 12 hours, 30 minutes, and 5 seconds. This package supports working with such durations, addressing the shortcomings of the isodate package. This package is a (recursive) dependency of the new version of jupyter-server. It will be team-maintained within the Debian Python Team. The Debian packaging is on salsa at https://salsa.debian.org/python-team/packages/python-isoduration
Bug#1068548: ITP: picobox -- Opinionated Python dependency injection framework
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org * Package name: picobox Version : 4.0.0 Upstream Author : Ihor Kalnytskyi * URL : https://github.com/ikalnytskyi/picobox * License : Expat Programming Lang: Python Description : Opinionated Python dependency injection framework Picobox is designed to be clean, pragmatic and with Python in mind. No complex graphs, no implicit injections, no type bindings - just picoboxes and explicit demands. . It is a small, thread-safe, pure Python library with no dependencies. This package is a (recursive) dependency of the new version of jupyter-server. It will be team-maintained within the Debian Python Team. The Debian packaging is on salsa at https://salsa.debian.org/python-team/packages/picobox
Bug#1068551: ITP: python-fqdn -- Python library to validate fully qualified domain names (FQDNs)
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org * Package name: python-fqdn Version : 1.5.1 Upstream Author : ypcrts * URL : https://github.com/ypcrts/fqdn * License : MPL-2.0 Programming Lang: Python Description : Python library to validate fully qualified domain names (FQDNs) This package validates FQDNs conforming to the Internet Engineering Task Force (IETF) specification (RFC 1123 in particular). The design intent is to validate that a string would be traditionally acceptable as a public Internet hostname to RFC-conforming software. Configuration options can be used to obtain more relaxed checks. This package is a (recursive) dependency of the new version of jupyter-server. It will be team-maintained within the Debian Python Team. The Debian packaging is on salsa at https://salsa.debian.org/python-team/packages/python-fqdn
Bug#1068550: ITP: pytest-mypy-testing -- Plugin to test mypy output with pytest
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org * Package name: pytest-mypy-testing Version : 0.1.3 Upstream Author : Copyright: David Fritzsche * URL : https://github.com/davidfritzsche/pytest-mypy-testing * License : CC0-1.0 Programming Lang: Python Description : Plugin to test mypy output with pytest This plugin provides a way to test that mypy produces a given output. As mypy can be told to display the type of an expression, this allows one to check mypy's type interference. This package is a test-time dependency of the new version of traitlets; the current version in unstable has the relevant tests ignored at present, but it would be good to be able to include these tests in the autopkgtest suite. It will be team-maintained within the Debian Python Team. The Debian packaging is on salsa at https://salsa.debian.org/python-team/packages/pytest-mypy-testing
Bug#1068549: ITP: pytest-console-scripts -- Pytest plugin for running Python scripts from within tests
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org * Package name: pytest-console-scripts Version : 1.4.1 Upstream Author : Vasily Kuznetsov * URL : https://github.com/kvas-it/pytest-console-scripts * License : Expat Programming Lang: Python Description : Pytest plugin for running Python scripts from within tests This plugin is quite similar to `subprocess.run()`, but it also has an in-process mode, where the scripts are executed by the interpreter that's running `pytest` (using some amount of sandboxing). . In-process mode significantly reduces the run time of the test suites that run many external scripts. This is speeds up development. In a CI environment subprocess mode can be used to make sure the scripts also work (and behave the same) when run by a fresh interpreter. This package is a (recursive) dependency of the new version of jupyter-server. It will be team-maintained within the Debian Python Team. The Debian packaging is on salsa at https://salsa.debian.org/python-team/packages/pytest-console-scripts
Bug#1068546: ITP: async-asgi-testclient -- Python async client for testing ASGI web applications
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org * Package name: async-asgi-testclient Version : 1.4.11 Upstream Author : Jordi Masip * URL : https://github.com/vinissimus/async-asgi-testclient * License : Expat Programming Lang: Python Description : Python async client for testing ASGI web applications This library is used for testing ASGI (Asynchronous Server Gateway Interface) applications. It is designed to be a common testing library for such applications that does not depend on the specific web framework being used. . It works by calling the ASGI app directly rather than via a web server. This package is a (recursive) dependency of the new version of jupyter-server. (More precisely, it is a test-time dependency of a currently unreleased version of picobox.) It will be team-maintained within the Debian Python Team. The Debian packaging is on salsa at https://salsa.debian.org/python-team/packages/async-asgi-testclient
Bug#1068547: ITP: jupyter-server-terminals -- Jupyter server extension providing support for terminals
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org * Package name: jupyter-server-terminals Version : 0.5.3 Upstream Author : Jupyter Development Team * URL : https://github.com/jupyter-server/jupyter_server_terminals * License : BSD-3-clause Programming Lang: Python Description : Jupyter server extension providing support for terminals This package allows Jupyter servers to interface to terminals via Tornado websockets. This package is a (recursive) dependency of the new version of jupyter-server. It will be team-maintained within the Debian Python Team. The Debian packaging is on salsa at https://salsa.debian.org/python-team/packages/jupyter-server-terminals
Bug#1057870: RFP: sphinx-mdinclude -- Sphinx extension for including or writing pages in Markdown format
retitle 1057870 ITP: sphinx-mdinclude -- Sphinx extension for including or writing pages in Markdown format owner 1057870 j...@debian.org thanks On Sat, Dec 09, 2023 at 09:37:47PM +, Martin wrote: > Package: wnpp > Severity: wishlist > > * Package name: sphinx-mdinclude > Version : v0.5.3 > Upstream Author : Hiroyuki Takagi etc. > * URL or Web page : https://github.com/omnilib/sphinx-mdinclude > * License : MIT > Programming Lang: Python > Description : Sphinx extension for including or writing pages in > Markdown format > > sphinx-mdinclude is a simple Sphinx extension that enables including > Markdown documents from within reStructuredText. It provides the .. > mdinclude:: directive, and automatically converts the content of > Markdown documents to reStructuredText format. > > sphinx-mdinclude is a fork of m2r and m2r2, focused only on providing a > Sphinx extension. I'll take this one! Best wishes, Julian
Bug#1060128: ITP: python-sphinxcontrib-github-alt -- Sphinx extension for easy GitHub links
On Fri, Mar 22, 2024 at 07:42:12AM +, Julian Gilbey wrote: > [...] > Thanks for this ITP! Two things: > > (1) I recommend that this package is called > python-sphinxcontrib.github-alt with a dot after "sphinxcontrib" to > keep it in line with the names of all the other sphinxcontrib packages > in Debian. Ah, it turns out that I'm wrong about this; the other packages are called "sphinxcontrib.foo" because that is the name of the Python module; here the module is literally called sphinxcontrib_github_alt, so your proposed package name is correct. I'm planning to package it today. Best wishes, Julian
Bug#970021: Seeking a small group to package Apache Arrow (was: Bug#970021: RFP: apache-arrow -- cross-language development platform for in-memory analytics)
Hi Diane, On Sat, Mar 30, 2024 at 08:59:39PM -0700, Diane Trout wrote: > Hi Julian, > > On Sat, 2024-03-30 at 20:22 +0000, Julian Gilbey wrote: > > Lovely to hear from you, and oh wow, that's amazing, thank you! > > > > I can't speak for anyone else, but I suggest that pushing your > > updates > > to the science-team package would be very sensible; it would be silly > > for someone else to have to redo your work. > > > > What more is needed for it to be ready for unstable? > > > The things I think are kind of broken are: > > We've got 7.0.0 and upstreams current version is 15.0.2. Yes, that does seem a little less than ideal! > the pyarrow 7.0.0 tests fail because it depends on a python test > library that breaks with pytest 8.0. Either I need to disable the > python tests or upgrade to a newer version. It may well be that newer versions would work with pytest 8.x. I don't think it's worth spending time trying to patch such a relatively old version. > My upgrade didn't go smoothly because uscan found also upstreams debian > watch file which is too loose and matches some other tar balls on their > distribution site. > > (Though I don't know why uscan keeps looking for watch files after > finding one in debian/watch) Oh dear. uscan(1) does say: Unless --watchfile is given, uscan looks recursively for valid source trees starting from the current directory (see the below section "Directory name checking" for details). and then: For each valid source tree found, typically the following happens: [...] so yes, it will look at more than one location. > And you were probably right in that arrow needs to be a team, because I > have no idea how to get other the other languages interfaces packaged. I suggest that without anyone else volunteering to do those other language interfaces (perhaps it's not a pressing need for people working with language X), I wonder whether it's worth just packaging the Python (and presumably C++) interfaces for now, and then if others want to join the effort to support language X later on, a new version of the Debian package can be uploaded with a new binary package for language X. It does mean more trips through the NEW queue if and when that happens, but given that no-one's shown interest in language X for the last several years, this is unlikely to be much of an issue. Version 7.0 provided support (it seems) for: GLib (seems that a draft framework for building this is already in the Debian package, and it can then be used in lots of languages), C++ (this is the core libraries), C# (not of interest to us), Go, Java, JavaScript, Julia, Matlab (not of interest to us), Python, R, Ruby. > Oh and I probably need to get the pyarrow installed somewhere, since it > was stopping at the tests I hadn't run into dh_missing errors yet. Oh. Would pybuild do that automatically (perhaps specifying PYBUILD_PACKAGE)? Best wishes, Julian
Bug#970021: Seeking a small group to package Apache Arrow (was: Bug#970021: RFP: apache-arrow -- cross-language development platform for in-memory analytics)
Hi Diane, On Fri, Mar 29, 2024 at 11:49:07AM -0700, Diane Trout wrote: > On Mon, 2024-03-25 at 18:17 +0000, Julian Gilbey wrote: > > > > > > So this is a plea for anyone looking for something really helpful to > > do: it would be great to have a group of developers finally package > > this! There was some initial work done (see the RFP bug report for > > details: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970021), > > but that is fairly old now. As Apache Arrow supports numerous > > languages, it may well benefit from having a group of developers with > > different areas of expertise to build it. (Or perhaps it would make > > more sense to split the upstream source into a collection of > > different > > Debian source packages for the different supported languages. I > > don't > > know.) Unfortunately I don't have the capacity to devote any time to > > it myself. > > > > Thanks in advance for anyone who can step forward for this! > > I've been maintain dask and anndata and saw that apache arrow was > getting increasingly popular. > > I took the current science-team preliminary packaging 7.0.0 packaging > and managed to get it to build through a combination of patches and > turning off features. > > I even mostly managed to get pyarrow to build. (Though some tests fail > due to pytest lazy-fixture being abandoned). > > I pushed my current work in progress to. > > https://salsa.debian.org/diane/arrow.git > > Was anyone else planning on working on it or should I push my updates > to the science-team package? Lovely to hear from you, and oh wow, that's amazing, thank you! I can't speak for anyone else, but I suggest that pushing your updates to the science-team package would be very sensible; it would be silly for someone else to have to redo your work. What more is needed for it to be ready for unstable? Best wishes, Julian
Bug#970021: Seeking a small group to package Apache Arrow (was: Bug#970021: RFP: apache-arrow -- cross-language development platform for in-memory analytics)
Hi all, [NB: sent to d-science, d-python, d-devel and the RFP bug; reply-to set to d-science and the RFP bug only] An update on Apache Arrow, and in particular the Python library PyArrow. For those who don't know: Apache Arrow is a development platform for in-memory analytics. It contains a set of technologies that enable big data systems to process and move data fast. It specifies a standardized language-independent columnar memory format for flat and hierarchical data, organized for efficient analytic operations on modern hardware. The project is developing a multi-language collection of libraries for solving systems problems related to in-memory analytical data processing. This includes such topics as: * Zero-copy shared memory and RPC-based data movement * Reading and writing file formats (like CSV, Apache ORC, and Apache Parquet) * In-memory analytics and query processing (from: https://arrow.apache.org/docs/index.html) Pandas has announced that Pandas 3.x will depend on PyArrow in a critical way (it will back the "string" datatype), and it is due to be released imminently. So this is a plea for anyone looking for something really helpful to do: it would be great to have a group of developers finally package this! There was some initial work done (see the RFP bug report for details: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970021), but that is fairly old now. As Apache Arrow supports numerous languages, it may well benefit from having a group of developers with different areas of expertise to build it. (Or perhaps it would make more sense to split the upstream source into a collection of different Debian source packages for the different supported languages. I don't know.) Unfortunately I don't have the capacity to devote any time to it myself. Thanks in advance for anyone who can step forward for this! Best wishes, Julian
Bug#1060128: ITP: python-sphinxcontrib-github-alt -- Sphinx extension for easy GitHub links
On Sat, Jan 06, 2024 at 07:31:22AM +, Dale Richards wrote: > Package: wnpp > Severity: wishlist > Owner: Dale Richards > X-Debbugs-Cc: debian-de...@lists.debian.org, d...@dalerichards.net > > * Package name: python-sphinxcontrib-github-alt > Version : 1.2 > Upstream Contact: Jupyter Development Team > * URL : https://github.com/jupyter/sphinxcontrib_github_alt > * License : BSD 2-clause > Programming Lang: Python > Description : Sphinx extension for easy GitHub links > > Link to GitHub issues, pull requests, commits and users for a particular > project. > > I intend to maintain this package within the Debian Python Team. Hi Dale, Thanks for this ITP! Two things: (1) I recommend that this package is called python-sphinxcontrib.github-alt with a dot after "sphinxcontrib" to keep it in line with the names of all the other sphinxcontrib packages in Debian. (2) Have you had any time to work on this? I will probably need this package soon for another Jupyter package (latest version of jupyter-notebook), so I'd be happy to upload it to NEW when I get there if you don't have a chance. Best wishes, Julian
Bug#1067248: ITP: pytest-jupyter -- Pytest plugins for Jupyter libraries and extensions
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org * Package name: pytest-jupyter Version : 0.9.1 * URL : https://github.com/jupyter-server/pytest-jupyter * License : BSD-3-clause and Expat Programming Lang: Python Description : Pytest plugins for Jupyter libraries and extensions This set of pytest plugins are used for testing Jupyter. It includes an echo kernel to speed up testing. It uses pytest-tornasync internally for async test suite running, and may not be compatible with pytest-asyncio. This package is a new requirement for the package tests for jupyter-client and jupyter-server (newer versions of these packages that have not yet been packaged). It will be maintained within the Debian Python Team.
Bug#1065327: ITA: python-levenshtein
On Fri, Mar 15, 2024 at 10:03:44AM -0400, Louis-Philippe Véronneau wrote: > Ah, great news then, happy to let you have it :) > > I'll be happy to contribute punctually if needed if you do indeed keep it in > the DPT. Thanks! Quick update, having taken a peek at the package: the version currently in unstable is quite old - it is a version that did not require rapidfuzz. So I will leave it as-is until rapidfuzz makes it into testing (which may be some time), and then it can be updated. Best wishes, Julian > On 2024-03-15 07:01, Julian Gilbey wrote: > > On Thu, Mar 14, 2024 at 10:40:38AM -0400, Louis-Philippe Véronneau wrote: > > > retitle 1065327 ITA: python-levenshtein -- extension for computing string > > > similarities and edit distances (Python 3) > > > owner 1065327 Louis-Philippe Véronneau > > > thanks > > > > > > I need this package for sublime-music and since it's being orphaned, I'm > > > planning to adopt it. > > > > > > If someone else wants to maintain this package though, I won't fight you > > > for it :) > > > > > > Cheers (and thanks to morph for the work so far), > > > > Hi Louis-Philippe, > > > > Both Jelmer and I are also willing to take it on. I wrote to the > > Python list in response to Jelmer (before I saw your ITA): > > > >I've just taken a look at python-levenshtein, as I remember the name > >now: it might make more sense for me to take it as it depends on > >rapidfuzz and rapidfuzz-cpp, which I've just packaged and are sitting > >in NEW. But if you want to take it, please feel free to do so! (Once > >rapidfuzz makes it into unstable, a lot of debian/rules could probably > >also be simplified.) > > > > So happy whoever wants to take it; we just won't be able to do much > > until rapidfuzz, rapidfuzz-cpp and taskflow make it to unstable. > > > > I do suggest that we keep it within the DPT, though. > > > > Best wishes, > > > > Julian
Bug#1065327: ITA: python-levenshtein
On Thu, Mar 14, 2024 at 10:40:38AM -0400, Louis-Philippe Véronneau wrote: > retitle 1065327 ITA: python-levenshtein -- extension for computing string > similarities and edit distances (Python 3) > owner 1065327 Louis-Philippe Véronneau > thanks > > I need this package for sublime-music and since it's being orphaned, I'm > planning to adopt it. > > If someone else wants to maintain this package though, I won't fight you for > it :) > > Cheers (and thanks to morph for the work so far), Hi Louis-Philippe, Both Jelmer and I are also willing to take it on. I wrote to the Python list in response to Jelmer (before I saw your ITA): I've just taken a look at python-levenshtein, as I remember the name now: it might make more sense for me to take it as it depends on rapidfuzz and rapidfuzz-cpp, which I've just packaged and are sitting in NEW. But if you want to take it, please feel free to do so! (Once rapidfuzz makes it into unstable, a lot of debian/rules could probably also be simplified.) So happy whoever wants to take it; we just won't be able to do much until rapidfuzz, rapidfuzz-cpp and taskflow make it to unstable. I do suggest that we keep it within the DPT, though. Best wishes, Julian
Bug#1019431: Bug#1019435: ITP: rapidfuzz - rapid fuzzy string matching
rename 1019431 ITP: rapidfuzz-cpp -- C-API of the Python RapidFuzz package thanks On Sat, Mar 02, 2024 at 08:27:00PM +, Julian Gilbey wrote: > merge 1019435 1019431 1019436 > thanks > > The rapidfuzz-capi and jarowinkler packages have been merged into > rapidfuzz, so I am merging these three ITPs into a single ITP. > >Julian On second thoughts, it doesn't make that much sense to bundle the C++ header file package with the Python package; it became clear as I was writing debian/rules that they really are two separate packages. Also renaming the package as rapidfuzz-cpp, following upstream. Julian
Bug#1019435: ITP: rapidfuzz - rapid fuzzy string matching
On Sat, Mar 02, 2024 at 08:27:00PM +, Julian Gilbey wrote: > merge 1019435 1019431 1019436 > thanks > > The rapidfuzz-capi and jarowinkler packages have been merged into > rapidfuzz, so I am merging these three ITPs into a single ITP. > >Julian On second thoughts, I'll package rapidfuzz-cpp separately, so unmerging these bugs again. Julian
Bug#1019435: ITP: rapidfuzz - rapid fuzzy string matching
merge 1019435 1019431 1019436 thanks The rapidfuzz-capi and jarowinkler packages have been merged into rapidfuzz, so I am merging these three ITPs into a single ITP. Julian
Bug#1064473: ITP: taskflow -- Parallel and Heterogeneous Task Programming System for C++
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: taskflow Version : 3.6.0+git20240218.9616467 Upstream Contact: Dr. Tsung-Wei Huang * URL : https://taskflow.github.io/ * License : Expat Programming Lang: C++ Description : Parallel and Heterogeneous Task Programming System for C++ Taskflow helps you quickly write parallel and heterogeneous task programs with high performance and simultaneous high productivity. It is faster, more expressive, with fewer lines of code, and easier for drop-in integration than many of existing task programming libraries. It is provided as a collecion of C++ header files, using C++17. This package is a dependency of rapidfuzz, which is a C++ and Python library for rapid string distance calculations. In turn, rapidfuzz is a dependency of newer versions of other Python packages. It is also a great package in itself, providing a library that can be used to great effect, as described in several papers and conference presentations. I don't think it fits within the Debian Python Team's remit, yet it is needed by them. So my proposal is to have myself as maintainer for now but for the Debian Python Team to be listed as an Uploader.
Bug#1009970: retitle 1009970 to ITP: memray -- Python memory profiler
On Tue, Jan 02, 2024 at 11:10:03PM +0100, Gürkan Myczko wrote: > On 31.12.2023 18:16, Julian Gilbey wrote: > > On Mon, Nov 06, 2023 at 04:27:35PM +0100, G��rkan Myczko wrote: > > > retitle 1009970 ITP: memray -- Python memory profiler > > > thanks > > > > Hi G��rkan (and unfortunately your name got corrupted in your email > > message), > > Hi Julian > > (i failed to find you on irc, you're maybe not using it?) Hi! No, I don't tend to use irc. > > Have you made any progress on this? > > Yes and no, here's the short summary: > https://sid.ethz.ch/debian/memray/ > 1.10.0 seems to build and work? > 1.11.0 doesn't seem to build. Oh :( Could it perhaps be to do with versions of dependencies? (I haven't looked at your packages, so I'm just guessing here.) > > It is now used in the new > > upstream version of dask.distributed, which we need to use to fix some > > Python 3.12 issues. (I see that memray does depend on some other > > stuff which has either not been packaged or needs to be updated, so > > it's not a completely trivial task.) > > You know more than I. Please go ahead if you have better packaging of it, > take over the ITP. I don't have the capacity to do it, unfortunately; it also turned out that I can just skip those tests with dask.distributed. If you are able to package memray, then we can re-enable those tests. Thanks! Julian
Bug#1059855: ITP: node-sortable-tablesort -- Tiny plain JavaScript table sorter
retitle 1059855 ITP: sortable-tablesort.js -- Tiny plain JavaScript table sorter thanks On Tue, Jan 02, 2024 at 12:52:27PM +, Julian Gilbey wrote: > Package: wnpp > Severity: wishlist > Owner: Julian Gilbey > X-Debbugs-Cc: debian-de...@lists.debian.org > > * Package name: node-sortable-tablesort > Version : 3.1.0 > Upstream Author : Jonas Earendel > * URL : https://github.com/tofsjonas/sortable > * License : Unlicense > Programming Lang: JavaScript > Description : Tiny plain JavaScript table sorter >A JavaScript library for making tables sortable with minimal effort: >just add class="sortable" to the table header. There are a small >number of other features, such as making a specific field >non-sortable. > >Node.js is an event-based server-side JavaScript engine. > > This package has recently been vendored into dask.distributed, so is > being uploaded to become a build-time dependency of dask.distributed > (rather than vendoring it within that package). > > I am a member of the Debian JavaScript maintainers team, and it will > be maintained within that team. I've realised that as this is a browser-only JS module, and not a NodeJS module, it is better to follow the (old?) JS team policy of naming the source package *.js. Julian
Bug#1059855: ITP: node-sortable-tablesort -- Tiny plain JavaScript table sorter
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: node-sortable-tablesort Version : 3.1.0 Upstream Author : Jonas Earendel * URL : https://github.com/tofsjonas/sortable * License : Unlicense Programming Lang: JavaScript Description : Tiny plain JavaScript table sorter A JavaScript library for making tables sortable with minimal effort: just add class="sortable" to the table header. There are a small number of other features, such as making a specific field non-sortable. Node.js is an event-based server-side JavaScript engine. This package has recently been vendored into dask.distributed, so is being uploaded to become a build-time dependency of dask.distributed (rather than vendoring it within that package). I am a member of the Debian JavaScript maintainers team, and it will be maintained within that team.
Bug#1009970: retitle 1009970 to ITP: memray -- Python memory profiler
On Mon, Nov 06, 2023 at 04:27:35PM +0100, G��rkan Myczko wrote: > retitle 1009970 ITP: memray -- Python memory profiler > thanks Hi G��rkan (and unfortunately your name got corrupted in your email message), Have you made any progress on this? It is now used in the new upstream version of dask.distributed, which we need to use to fix some Python 3.12 issues. (I see that memray does depend on some other stuff which has either not been packaged or needs to be updated, so it's not a completely trivial task.) Thanks! Julian
Bug#1042443: ITP: pathos -- Framework for heterogeneous parallel computing
Hi Agathe, On Fri, Sep 01, 2023 at 09:46:00AM +0200, Agathe Porte wrote: > Hi Julian, > > 2023-07-28 10:59 CEST, Julian Gilbey: > > Package: wnpp > > Severity: wishlist > > Owner: Julian Gilbey > > X-Debbugs-Cc: debian-de...@lists.debian.org, Debian Python Team > > > > > > * Package name: pathos > > Version : 0.3.1 > > Upstream Contact: Mike McKerns > > * URL : https://github.com/uqfoundation/pathos > > * License : BSD-3-clause > > Programming Lang: Python > > Description : Framework for heterogeneous parallel computing > > > > […] > > > > > > This is a package I've started using; it provides a very effective > > framework for parallel computing, allowing for constructs that the > > standard Python library does not support. > > > > I will maintain it within the Debian Python Team. > > Like python-ppft, this was already packaged in the Python team but not > uploaded: https://salsa.debian.org/python-team/packages/python-pathos > > Maybe you can find inspiration in it. I think we should only keep one of > the two repos in the DPT because it can be confusing to have the same > package twice. Oh! I had not realised. I didn't see an ITP for this package, and so I went ahead and did it myself. So yes, let's delete or archive the duplicate repos for this and ppft; would you be able to do that? Now I'm just waiting on upgrades to python3-multiprocessing and python3-dill before I can upload a source-only version of these new packages. Best wishes, Julian
Bug#1042442: ITP: mystic -- Constrained nonlinear optimization
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-de...@lists.debian.org, Debian Python Team * Package name: mystic Version : 0.4.1 Upstream Contact: Mike McKerns * URL : https://github.com/uqfoundation/mystic * License : BSD-3-clause Programming Lang: Python Description : Constrained nonlinear optimization The mystic framework provides a collection of optimization algorithms and tools that allows the user to more robustly (and easily) solve hard optimization problems for machine learning, uncertainty quantification and AI. mystic gives the user fine-grained power to both monitor and steer optimizations as the fit processes are running. Users can customize optimizer stop conditions, where both compound and user-provided conditions may be used. Optimizers can save state, can be reconfigured dynamically, and can be restarted from a saved solver or from a results file. All solvers can also leverage parallel computing, either within each iteration or as an ensemble of solvers. . mystic provides a stock set of configurable, controllable solvers with: * a common interface * a control handler with: pause, continue, exit, and callback * ease in selecting initial population conditions: guess, random, etc * ease in checkpointing and restarting from a log or saved state * the ability to leverage parallel & distributed computing * the ability to apply a selection of logging and/or verbose monitors * the ability to configure solver-independent termination conditions * the ability to impose custom and user-defined penalties and constraints . mystic is part of pathos, a Python framework for heterogeneous computing. It is part of the pathos framework which I am packaging. Nonlinear optimisation is a core task for ML/AI, and use of this pathos plugin is demonstrated in several examples in the pathos package. I will maintain it within the Debian Python Team.
Bug#1042444: ITP: klepto -- Persistent caching to memory, disk or database
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-de...@lists.debian.org, Debian Python Team * Package name: klepto Version : 0.2.4 Upstream Contact: Mike McKerns * URL : https://github.com/uqfoundation/klepto * License : BSD-3-clause Programming Lang: Python Description : Persistent caching to memory, disk or database klepto extends Python's lru_cache to utilise different keymaps and alternate caching algorithms. This package also has archiving capabilities for longer-term storage. It uses a simple dictionary-style interface for all caches and archives, and all caches can be applied to any Python function as a decorator. . klepto is intended to be used for distributed and parallel computing, where the keymaps serialize the stored objects, and the caches and archives are intended to be read/write accessible from different threads and processes. . klepto is part of pathos, a Python framework for heterogeneous computing. This is a plugin for the pathos package, which I am ITP'ing. I will maintain it within the Debian Python Team.
Bug#1042443: ITP: pathos -- Framework for heterogeneous parallel computing
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-de...@lists.debian.org, Debian Python Team * Package name: pathos Version : 0.3.1 Upstream Contact: Mike McKerns * URL : https://github.com/uqfoundation/pathos * License : BSD-3-clause Programming Lang: Python Description : Framework for heterogeneous parallel computing Pathos provides a consistent high-level interface for configuring and launching parallel computations across heterogeneous resources. It provides configurable launchers for parallel and distributed computing, where each launcher contains the syntactic logic to configure and launch jobs in an execution environment. Examples of launchers include: "pyina", a queue-less MPI-based launcher; "pathos", an ssh-based launcher; "multiprocess", a multi-process launcher. . It provides a consistent interface for parallel and/or distributed versions of "map" and "apply" for each launcher; the guiding design principle is that "map" and "apply" should be drop-in replacements in otherwise serial code, reducing the time to conver a code to parallel, but also enabling a single code-base to be maintained instead of requiring serial, parallel and distributed versions of code. . The "pathos" framework consists of several interoperating packages: * "dill": serialize all of Python (python3-dill) * "pox": utilities for filesystem exploration and automated builds (python3-pox) * "klepto": persistent caching to memory, disk, or database (python3-klepto) * "multiprocess": better multiprocessing and multithreading in Python (python3-multiprocess) * "ppft": distributed and parallel Python (python3-ppft) * "pyina": MPI parallel "map" and cluster scheduling (python3-pyina) * "pathos": graph management and execution in heterogeneous computing (python3-pathos) This is a package I've started using; it provides a very effective framework for parallel computing, allowing for constructs that the standard Python library does not support. I will maintain it within the Debian Python Team.
Bug#1042441: ITP: pox -- Utilities for filesystem exploration and automated builds
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-de...@lists.debian.org, Debian Python Team * Package name: pox Version : 0.3.3 Upstream Contact: Mike McKerns * URL : https://github.com/uqfoundation/pox * License : BSD-3-clause Programming Lang: Python Description : Utilities for filesystem exploration and automated builds This package is particular useful when exploring a filesystem on a remote host, where queries such as "what is the root of the filesystem?", "what is the user's name?", and "what login shell is preferred?" become essential in allowing a remote user to function as if they were logged in locally. . pox is part of pathos, a Python framework for heterogeneous computing. This is a dependency of pathos, which I am packaging. I will maintain it within the Debian Python Team.
Bug#1042440: ITP: pyina -- MPI parallel map and cluster scheduling
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-de...@lists.debian.org, Debian Python Team * Package name: pyina Version : 0.2.8 Upstream Contact: Mike McKerns * URL : https://github.com/uqfoundation/pyina * License : BSD-3-clause Programming Lang: Python Description : MPI parallel map and cluster scheduling The pyina package provides several basic tools to make MPI-based parallel computing more accessible to the end user. The goal of pyina is to allow the user to extend their own code to MPI-based parallel computing with minimal refactoring. . pyina provides a highly configurable parallel map interface to running MPI jobs, with: . * a map interface that extends the Python map standard * the ability to submit batch jobs to a selection of schedulers * the ability to customize node and process launch configurations * the ability to launch parallel MPI jobs with standard Python * ease in selecting different strategies for processing a work list . pyina is part of pathos, a Python framework for heterogeneous computing. This is a core plugin for the pathos system, which I am packaging. I cannot test it myself, though, as I don't have an MPI setup, but I am packaging it for those who use pathos and do have such a system. I will maintain it within the Debian Python Team.
Bug#1042439: ITP: ppft -- Distributed and parallel Python
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-de...@lists.debian.org, Debian Python Team * Package name: ppft Version : 1.7.6.7+dfsg Upstream Contact: Mike McKerns * URL : https://github.com/uqfoundation/ppft * License : BSD-3-clause Programming Lang: Python Description : Distributed and parallel Python ppft is a friendly fork of Parallel Python. It provides: . * parallel execution of Python code on SMP and clusters * easy-to-understand job-based parallelization * automatic detection of the number of effective processors * dynamic processor allocation (at runtime) * low overhead for jobs with the same function (through transparent caching) * dynamic load balancing (jobs are distributed at runtime) * fault-tolerance (if a node fails, tasks are rescheduled on the others) * auto-discovery of computational resources * dynamic allocation of computational resources * SHA based authentication for network connections * enhanced serialization, using dill.source . ppft is part of pathos, a Python framework for heterogeneous computing. It is a dependency of pathos, which is a useful framework that I've started using. I will maintain it within the Debian Python Team.
Bug#1040433: RFA: anki - flashcard learning program, has migrated to Rust/Python/JavaScript combination
Package: wnpp Severity: normal X-Debbugs-Cc: debian-r...@lists.debian.org Anki is a superb flashcard system for learning anything. It used to be a straightforward Python package with some JavaScript for the front end. But over the last couple of years, it has migrated to a combination of Rust, Python and JavaScript (using node). (It went via the unpackaged Bazel package building system, but it's now migrated away from that.) I do not have the capacity to maintain this lovely package now that it has become significantly more complex. It is currently in unstable at version 2.1.15, which was a Python-only version (plus a bit of JavaScript). It no longer builds on testing, and did not make it into bookworm; upstream is now at 2.1.65. I have had several requests to update the package and bring it back into Debian, both via the BTS and via personal emails. If anyone would like to pick up where I left off, please do let me know. I'd be happy to share with you what I learnt from the Python version, but how relevant that will be for the new Rust/Python/JavaScript incarnation, I do not know. (And I don't know how many other dependencies will need to be packaged from scratch, unfortunately. And one further complication is that Cargo.toml also lists three forked crates) Many thanks! Julian
Bug#969482: Update golang-github-xanzy-go-gitlab from 0.73 to 0.85
Dear Nicolas, On Mon, Jun 12, 2023 at 11:37:47AM +0200, Nicolas Schier wrote: > Dear go-packaging-team, > > for packaging the 'glab' CLI tool [1] we need golang-github-xanzy-go-gitlab >= > 0.83. For my local packaging test I prepared an update to 0.85 and created > corresponding merge-requests: Thanks! That sounds like good work (and very up-to-date :). I haven't looked at this package in a very long time, so don't feel able to comment on it. Would whoever uploads it be able to remove me from the Uploaders field? Hopefully Anthony (who did the last upload) might be able to do this upload. Best wishes, Julian
Bug#1025513: Bug#1024047: python-line-profiler
Just an FYI: though ubelt is a requirement for running the tests, a much more serious problem is that python-line-profiler requires an alpha version of Cython 3.0.0 to compile, and that is not (yet?) packaged for Debian. Hopefully at some point over the next two years, Cython 3.0 will mature enough to actually be released, and then it will be possible to upgrade python-line-profiler. Best wishes, Julian
Bug#1026800: ITP: node-webfont -- Generate icon fonts from SVG icons
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-de...@lists.debian.org, pkg-javascript-de...@lists.alioth.debian.org * Package name: node-webfont Version : 11.4.0 Upstream Contact: https://github.com/itgalaxy/webfont/issues * URL : https://github.com/itgalaxy/webfont * License : Expat Programming Lang: Javascript (Node.js) Description : Generate icon fonts from SVG icons Webfont converts sets of SVG files into an icon font, in any of the formats: woff2, woff, eot, ttf and svg. These can then be used in a browser. It has both a Node.js interface and a simple command-line interface (webfont). This package is needed to build a DFSG version of the Material Design Icons font (in the fonts-materialdesignicons-webfont package). It will be maintained within the Debian Javascript Maintainers team, with me taking the lead on it. The package will includes a number of Javascript dependencies that are not currently packaged; they will all be Provided by the package. They are as follows: * node-is-eot (= 1.0.0) * node-is-svg (= 4.3.2) * node-is-ttf (= 0.2.2) * node-is-woff (= 1.0.3) * node-is-woff2 (= 1.0.0) * node-neatequal (= 1.0.0) * node-svg-pathdata (= 6.0.3) * node-svgicons2svgfont (= 12.0.0) * node-ttf2eot (= 3.1.0) * node-ttf2woff (= 3.0.0) * node-varstream (= 0.3.2) * node-wawoff2 (= 2.0.1)
Bug#1023796: ITP: pylint-venv -- Pylint hook to use same pylint with different virtual envs
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org * Package name: pylint-venv Version : 2.3.0 Upstream Author : Jan Gosmann , Federico Jaramillo * URL : https://github.com/jgosmann/pylint-venv * License : MIT (Expat) Programming Lang: Python Description : Pylint hook to use same pylint with different virtualenvs Pylint does not respect the currently activated virtualenv if it is not installed in every virtual environment individually. This module provides a Pylint init-hook to use the same Pylint installation with different virtual environments. This package is a new dependency of spyder (version 5.4.0) which I'm currently preparing to upload. It is a single short Python module (about 90 lines excluding initial comments). It will be maintained within the Debian Python team, with me as the primary maintainer.
Bug#1019435: ITP: rapidfuzz -- rapid fuzzy string matching
On Fri, Sep 09, 2022 at 10:00:49AM +0100, Julian Gilbey wrote: > Package: wnpp > Severity: wishlist > Owner: Julian Gilbey > X-Debbugs-Cc: debian-de...@lists.debian.org, debian-de...@lists.debian.org, > debian-pyt...@lists.debian.org > > * Package name: rapidfuzz > Version : 2.6.1 > Upstream Author : Max Bachmann > * URL : https://github.com/maxbachmann/RapidFuzz > * License : MIT > Programming Lang: Python > Description : rapid fuzzy string matching > > RapidFuzz is a fast string matching library for Python and C++, which > uses the string similarity calculations from > [FuzzyWuzzy](https://github.com/seatgeek/fuzzywuzzy). However there > are a couple of aspects that set RapidFuzz apart from FuzzyWuzzy: > 1) It is MIT licensed so it can be used whichever License you might want to > choose for your project, while you're forced to adopt the GPL license when > using FuzzyWuzzy > 2) It provides many string_metrics like hamming or jaro_winkler, which are > not included in FuzzyWuzzy > 3) It is mostly written in C++ and on top of this comes with a lot of > Algorithmic improvements to make string matching even faster, while still > providing the same results. For detailed benchmarks check the > [documentation](https://maxbachmann.github.io/RapidFuzz/fuzz.html) > 4) Fixes multiple bugs in the `partial_ratio` implementation > > This is a dependency of the latest upstream release of > python3-textdistance. > > There are also two C++ libraries contained within this package, > managed as separate GitHub subrepositories. One is rapidfuzz-cpp, and > I am not sure whether to bundle this as a single package or whether to > package this independently. The other is taskflow > (https://github.com/taskflow/taskflow)), a C++ header-only package; I > think this should probably be packaged separately. > > This package will be maintained within the Python Packaging Team. I should have added: this package depends on Cython >= 3.0.0a7, so this cannot be packaged until we have the new version of Cython available. The same applies for the JaroWinkler package. Julian
Bug#1019436: ITP: jarowinkler -- fast approximate string matching using Jaro(-Winkler) similarity
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org * Package name: jarowinkler Version : 1.2.1 Upstream Author : Max Bachmann * URL : https://github.com/maxbachmann/JaroWinkler * License : MIT Programming Lang: Python Description : Fast approximate string matching using Jaro(-Winkler) similarity JaroWinkler is a Python library to calculate the Jaro and Jaro-Winkler similarity. It is easy to use, is much faster than other comparable libraries, and is designed to integrate seemingless with RapidFuzz. There is also a C++ library contained within this package, managed as a separate GitHub subrepository. This is jarowinkler-cpp, and I am not sure whether to bundle this as a single package or whether to package this independently. This is a dependency of python3-rapidfuzz, which is a new dependency of the latest upstream release of python3-textdistance. This package will be maintained within the Python Packaging Team.
Bug#1019435: ITP: rapidfuzz -- rapid fuzzy string matching
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-de...@lists.debian.org, debian-de...@lists.debian.org, debian-pyt...@lists.debian.org * Package name: rapidfuzz Version : 2.6.1 Upstream Author : Max Bachmann * URL : https://github.com/maxbachmann/RapidFuzz * License : MIT Programming Lang: Python Description : rapid fuzzy string matching RapidFuzz is a fast string matching library for Python and C++, which uses the string similarity calculations from [FuzzyWuzzy](https://github.com/seatgeek/fuzzywuzzy). However there are a couple of aspects that set RapidFuzz apart from FuzzyWuzzy: 1) It is MIT licensed so it can be used whichever License you might want to choose for your project, while you're forced to adopt the GPL license when using FuzzyWuzzy 2) It provides many string_metrics like hamming or jaro_winkler, which are not included in FuzzyWuzzy 3) It is mostly written in C++ and on top of this comes with a lot of Algorithmic improvements to make string matching even faster, while still providing the same results. For detailed benchmarks check the [documentation](https://maxbachmann.github.io/RapidFuzz/fuzz.html) 4) Fixes multiple bugs in the `partial_ratio` implementation This is a dependency of the latest upstream release of python3-textdistance. There are also two C++ libraries contained within this package, managed as separate GitHub subrepositories. One is rapidfuzz-cpp, and I am not sure whether to bundle this as a single package or whether to package this independently. The other is taskflow (https://github.com/taskflow/taskflow)), a C++ header-only package; I think this should probably be packaged separately. This package will be maintained within the Python Packaging Team.
Bug#1019431: ITP: rapidfuzz-capi -- C-API of the Python RapidFuzz package
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org * Package name: rapidfuzz-capi Version : 1.0.5 Upstream Author : Max Bachmann * URL : https://github.com/maxbachmann/rapidfuzz_capi * License : MIT Programming Lang: Python Description : C-API of the Python RapidFuzz package, used to build rapidfuzz This package provides the C API of RapidFuzz. It can be used inside `pyproject.toml` to compile an extension module extending RapidFuzz. Providing this C API in a separate package simplifies the build process. . This package is only needed for building packages such as python3-rapidfuzz and python3-jarowinkler; it is not needed at runtime. This is a dependency of python3-rapidfuzz and python3-jarowinkler, string-matching packages which are new (recursive) dependencies of the latest upstream release of python3-textdistance. This package will be maintained within the Python Packaging Team.
Bug#1013425: ITP: wnpp -- Python Airspeed is a powerful templating engine compatible with Velocity for Java
On Thu, Jun 23, 2022 at 02:00:21PM +0200, Felix Moessbauer wrote: > Package: wnpp > Severity: wishlist > Owner: Felix Moessbauer > X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org > > * Package name: wnpp > Version : 0.5.19 > [...] > * URL : https://github.com/purcell/airspeed > [...] > Description : Airspeed is a powerful and easy-to-use templating engine > for Python that aims for a high level of compatibility with the popular > Velocity library for Java. Hi Felix, I'm not sure why you'd want to call this package "wnpp" rather than "airspeed" or "python-airspeed". Please could you change the title of this wnpp! Best wishes, Julian
Bug#866334: About Bug#866334: RFP: lean -- theorem prover from Microsoft Research
On Fri, May 20, 2022 at 10:59:35PM +0530, Nilesh Patra wrote: > On 5/20/22 8:31 PM, Bill Allombert wrote: > > On Mon, Sep 16, 2019 at 08:39:56PM +0100, Julian Gilbey wrote: > > > I've just started looking at lean. One of the issues around packaging > > > it is that different lean "scripts" (not sure the correct word here) > > > require different versions of lean. There is a script available which > > > downloads the required version of lean for any particular script, and > > > so keeps a local set of lean versions. > > > > > > If we were to package lean for Debian, what exactly would we package? > > > The current stable version, or a script such as this? See > > > https://github.com/leanprover-community/mathlib/blob/master/docs/install/debian_details.md > > > for a little more on this. > > > > > > Thoughts would be appreciated! > > > > Lean is now the theorem prover with the largest community, so it would > > be nice to have it in Debian. However I do not know how usable it is > > outside the visual studio IDE. Debian now has the package "elan" which handles installation of Lean; this might be sufficient. Best wishes, Julian
Bug#1005701: ITP: python-untangle -- Convert XML to a Python object
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org * Package name: python-untangle Version : 1.1.1+git20200807.fb916a9 Upstream Author : Christian Stefanescu * URL : https://github.com/stchris/untangle * License : MIT Programming Lang: Python Description : Convert XML to a Python object Untangle has a very simple API for converting XML to a Python object: you just call the "parse" function on either a string, a filename or a URL. This package is used in the tests for pydevd, which I am currently working on packaging (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933070). It will be maintained within the Debian Python Team. Best wishes, Julian
Bug#1005267: ITP: python-bytecode -- Python module to generate, modify and optimize Python bytecode
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org * Package name: python-bytecode Version : 0.13.0 Upstream Author : Victor Stinner and Matthieu C. Dartiailh * URL : https://github.com/MatthieuDartiailh/bytecode * License : MIT Programming Lang: Python Description : Python module to generate, modify and optimize Python bytecode The bytecode module can be used to write Python bytecode directly and then convert it into executable Python statements. It also provides a pure Python implementation of the Peephole Optimizer introduced in CPython 3.6. This Python module was vendored by the pydevd developers, and having a standalone version of the module will avoid having the embedded module in pydevd. (And pydevd turns out to be a recursive dependency of Spyder) The Debian version of this package will therefore require the pydevd patch; this enhances the bytecode functionality if it is used (via an optional argument) but has no effect otherwise. It will be maintained within the Debian Python Team.
Bug#933070: Bug#933190: ITP: ptvsd -- Python debugger package for use with Visual Studio and Visual Studio Code
Hi William, Thanks for your super-quick response! And I reread my initial email - I'm sorry I didn't sound more positive about your initial packaging work, which I really appreciated! Best wishes, Julian On Thu, Feb 03, 2022 at 06:24:17AM -0300, William Grzybowski wrote: > Hello, > You can take it over. Thank you. > On Thu, Feb 3, 2022, 03:39 Julian Gilbey wrote: > > On Sat, Jul 27, 2019 at 09:18:36AM -0300, William Grzybowski wrote: > > Package: wnpp > > Severity: wishlist > > Owner: William Grzybowski > > > > * Package name : ptvsd > > Version : 4.3.0 > > [...] > > > * Package name : pydevd > > Version : 1.6.1 > > > The Python Visual Studio Debugger engine implements the Visual Studio Code > > debug protocol and is used as the debug engine in Visual Studio and Visual > > Studio Code. > > > > I use it myself and plan maintaining it within DPMT. > > Hi William, > > I see you made a start on packaging this pair of packages about 2.5 > years ago. It turns out they are also expected by Spyder, which I am > now maintaining. Are you planning on continuing this work, or would > you be happy for me to take over from you, picking up on your initial > packaging work? I'd ideally like to have them uploaded to NEW within > the next 3-4 weeks, and if I don't hear from you, I'll go ahead and > work on it myself. (The two packages do seem a bit challenging > because of the vendoring of third-party packages in both!) > > Also, ptvsd was renamed as "debugpy" in January 2020, so I would > rename the salsa repository to debugpy. > > Best wishes, > > Julian
Bug#933070: Bug#933190: ITP: ptvsd -- Python debugger package for use with Visual Studio and Visual Studio Code
On Sat, Jul 27, 2019 at 09:18:36AM -0300, William Grzybowski wrote: > Package: wnpp > Severity: wishlist > Owner: William Grzybowski > > * Package name: ptvsd > Version : 4.3.0 > [...] > * Package name: pydevd > Version : 1.6.1 > The Python Visual Studio Debugger engine implements the Visual Studio Code > debug protocol and is used as the debug engine in Visual Studio and Visual > Studio Code. > > I use it myself and plan maintaining it within DPMT. Hi William, I see you made a start on packaging this pair of packages about 2.5 years ago. It turns out they are also expected by Spyder, which I am now maintaining. Are you planning on continuing this work, or would you be happy for me to take over from you, picking up on your initial packaging work? I'd ideally like to have them uploaded to NEW within the next 3-4 weeks, and if I don't hear from you, I'll go ahead and work on it myself. (The two packages do seem a bit challenging because of the vendoring of third-party packages in both!) Also, ptvsd was renamed as "debugpy" in January 2020, so I would rename the salsa repository to debugpy. Best wishes, Julian
Bug#978149: ITP: pyenv -- Simple Python version management
On Wed, Dec 22, 2021 at 07:22:54PM +0530, karthek wrote: > On Wed, Dec 22, 2021, 6:03 PM Julian Gilbey wrote: > > That makes sense, then. Good luck packaging this! > > Thanks. > I need a sponser though Good luck! I'm afraid I can't take it on though - I'm too overloaded already. Best wishes, Julian
Bug#978149: ITP: pyenv -- Simple Python version management
On Wed, Dec 22, 2021 at 05:22:46PM +0530, karthek wrote: > I see that #978476 has been closed; are you still thinking of > packaging this? > > Yes > > I'm not clear why this would be helpful in Debian, > better than, say, using a virtual env or chroot? > > It gives you the freedom of having multiple python versions(not different > module > versions) with easy switching > > If you're working in > a LTS version of some distro, surely you're better off in a chroot > anyway, as that gives you the exact setup of the distro you're working > in. > > Chroot , debootstrap are only required when we need a completely new system > but > not when we only need to use multiple different python versions for different > projects > And they don't give you the python version you want , we have to install them > manually. That makes sense, then. Good luck packaging this! Best wishes, Julian
Bug#978149: ITP: pyenv -- Simple Python version management
On Sat, Dec 26, 2020 at 10:38:40PM +0530, karthek wrote: > Package: wnpp > Severity: wishlist > Owner: karthek > X-Debbugs-Cc: debian-de...@lists.debian.org, m...@karthek.com > > * Package name: pyenv > Version : 1.2.21 > Upstream Author : 2013 Yamashita, Yuu > * URL : https://github.com/pyenv/pyenv > * License : Expat > Programming Lang: shell script > Description : Simple Python version management > > pyenv lets you easily switch between multiple versions of Python. It's > simple, unobtrusive, and follows the UNIX tradition of single-purpose > tools that do one thing well. > pyenv does: > * Let you change the global Python version on a per-user basis. > * Provide support for per-project Python versions. > * Allow you to override the Python version with an environment > * variable. > * Search commands from multiple versions of Python at a > time. This may be helpful to test across Python versions with tox. > > It is useful when youre working on a project where they expect you to > work in a LTS version of some distro (like Ubuntu LTS) and they dont > bother mainataining aompatibility with newer python versions. > > I plan to mantain it and need a sponsor I see that #978476 has been closed; are you still thinking of packaging this? I'm not clear why this would be helpful in Debian, better than, say, using a virtual env or chroot? If you're working in a LTS version of some distro, surely you're better off in a chroot anyway, as that gives you the exact setup of the distro you're working in. Best wishes, Julian
Bug#934258: Experimentations on packaging jupyterlab
On Tue, Dec 14, 2021 at 08:22:16AM +0100, Julien Puydt wrote: > I'm still struggling with the javascript part. > [...] > > Once esbuild is clear, I'll see if that solves csso ; if it does, I'll > see if it solves svgo ; if it does, I'll see if it solves... you get > the point! Oh, Julien, I feel for you! These are so annoying. I'm in a somewhat similar situation with Spyder (but not quite as bad, it seems). Good luck! Julian
Bug#992494: ITP: pytest-ordering -- order execution of build-tests with pytest
On Sun, Dec 12, 2021 at 09:02:18PM +, Julian Gilbey wrote: > On Thu, Aug 19, 2021 at 12:54:45PM +0200, Steffen Moeller wrote: > > Package: wnpp > > Severity: wishlist > > > > Subject: ITP: pytest-ordering -- order execution of build-tests with pytest > > Package: wnpp > > Owner: Steffen Moeller > > Severity: wishlist > > > > * Package name: pytest-ordering > > Version : 0.6 > > Upstream Author : Copyright: Frank Tobia > > * URL : https://github.com/ftobia/pytest-ordering/ > > [...] > >https://salsa.debian.org/python-team/pacakges/pytest-ordering > > (Corrected URL: > https://salsa.debian.org/python-team/packages/pytest-ordering) > > Hi Steffen, > > Unfortunately, this package is broken and unmaintained upstream: > https://github.com/ftobia/pytest-ordering/issues/73 > > So I suggest that unless upstream starts working on it again or > someone takes over responsibility for it, we don't actually let it > into Debian. > > In the meantime, I'm intending to make an ITP for python-order to > support the new version of Spyder; see the discussion here: > https://github.com/spyder-ide/spyder/pull/14935 > > Best wishes, > >Julian Quick update: it turns out that pytest-order is actually a maintained fork of pytest-ordering - see https://github.com/pytest-dev/pytest-order My ITP is Bug#1001627 (https://bugs.debian.org/1001627). Best wishes, Julian
Bug#1001627: ITP: pytest-order -- A pytest plugin to order test execution
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-de...@lists.debian.org, Debian Python Team * Package name: pytest-order Version : 1.1.0 Upstream Author : Frank Tobia * URL : https://github.com/pytest-dev/pytest-order * License : MIT Programming Lang: Python Description : A pytest plugin to order test execution pytest-order is a pytest plugin that allows you to customize the order in which your tests are run. It uses the marker order that defines when a specific test shall run, either by using an ordinal number, or by specifying the relationship to other tests. This package is required to run the tests supplied with the Spyder package (at build-time and for autopkgtest). It will be maintained within the Debian Python Team, with me as the Uploader. Best wishes, Julian
Bug#992494: ITP: pytest-ordering -- order execution of build-tests with pytest
On Thu, Aug 19, 2021 at 12:54:45PM +0200, Steffen Moeller wrote: > Package: wnpp > Severity: wishlist > > Subject: ITP: pytest-ordering -- order execution of build-tests with pytest > Package: wnpp > Owner: Steffen Moeller > Severity: wishlist > > * Package name: pytest-ordering > Version : 0.6 > Upstream Author : Copyright: Frank Tobia > * URL : https://github.com/ftobia/pytest-ordering/ > [...] >https://salsa.debian.org/python-team/pacakges/pytest-ordering (Corrected URL: https://salsa.debian.org/python-team/packages/pytest-ordering) Hi Steffen, Unfortunately, this package is broken and unmaintained upstream: https://github.com/ftobia/pytest-ordering/issues/73 So I suggest that unless upstream starts working on it again or someone takes over responsibility for it, we don't actually let it into Debian. In the meantime, I'm intending to make an ITP for python-order to support the new version of Spyder; see the discussion here: https://github.com/spyder-ide/spyder/pull/14935 Best wishes, Julian
Bug#934258: Experimentations on packaging jupyterlab
On Thu, Dec 09, 2021 at 07:49:18PM +, Julian Gilbey wrote: > On Sat, Nov 27, 2021 at 11:52:25AM +0100, Julien Puydt wrote: > > Hi, > > > > I tried my hand at experimental packaging for jupyterlab. > > Hi Julien, > > Thanks for your work on this! One more thing: the docs/environment.yml file lists jsx-lexer as a dependency; I packaged this when I looked at jupyterlab last year (but ran out of time to get much further). I haven't made an ITP for it, but the draft package is available at https://salsa.debian.org/python-team/packages/jsx-lexer Best wishes, Julian
Bug#934258: Experimentations on packaging jupyterlab
On Sat, Nov 27, 2021 at 11:52:25AM +0100, Julien Puydt wrote:
> Hi,
>
> I tried my hand at experimental packaging for jupyterlab.
Hi Julien,
Thanks for your work on this!
> For the Python part, it lacks nbclassic, it's ITP bug #1000667, this
> will be done in no time.
Thanks for doing that package too!
> The JavaScript part is another story entirely. I made experiments
> compiling by hand a few of the packages in packages/.
> [...]
I am looking at packaging spyder-notebook in the not-too-distant
future (ITP #871261), but it's waiting on some upstream work first.
Its tests (I think it's only the tests) use the jupyterlab JavaScript,
for example in spyder_notebook/server/src/tooltip.js:
import { CodeEditor } from '@jupyterlab/codeeditor';
So when you do successfully manage to package jupyterlab, will you
make these bits of JavaScript (or perhaps it's TypeScript) available
in a (or the) package?
Thanks!
Julian
Bug#871261: RFP: spyder-notebook -- Jupyter notebook integration with Spyder
retitle 871261 ITP: spyder-notebook -- Jupyter notebook integration with Spyder owner 871261 ! block 871261 by 934258 thanks On Sat, Nov 10, 2018 at 04:19:57PM +, Bart Martens wrote: > retitle 871261 RFP: spyder-notebook -- Jupyter notebook integration with > Spyder > noowner 871261 > stop > > ITP 871261 has no visible progress for a long time, so retitling to RFP. I will do this once the following three things have happened: - I have uploaded spyder 5.2 to unstable (it's mostly just waiting for a couple of packages in the NEW queue to be accepted) - The notebook plugin has been updated upstream for spyder 5.2 - jupyterlab is packaged (as it appears that spyder-notebook makes use of the JavaScript in that package) - see bug#934258 Julian
Bug#859880: retitle to RFP: spyder-terminal -- plugin to display a virtual terminal within the Spyder IDE
retitle 859880 ITP: spyder-terminal -- plugin to display a virtual terminal within the Spyder IDE owner 859880 ! unblock 859880 by 780187 859879 thanks On Thu, Jul 12, 2018 at 04:19:56PM +, Bart Martens wrote: > retitle 859880 RFP: spyder-terminal -- plugin to display a virtual terminal > within the Spyder IDE > noowner 859880 > stop > > ITP 859880 has no visible progress for a long time, so retitling to RFP. I'll aim to do this one when I've finished packaging Spyder 5.2; it's waiting for a couple of packages in the NEW queue to be accepted first. Julian
Bug#1000940: ITP: python-scss -- Python binding for libsass
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: python-sass Version : 2.3 Upstream Author : Sergey Kirillov * URL : https://github.com/pistolero/python-scss * License : Apache 2.0 Programming Lang: Python Description : Python binding for libsass This Python package provides a Python binding for libsass, providing the single method compile_string() to compile Sass strings to CSS. This package is a dependency of qtsass, which is itself a (recursive) dependency of the new version of Spyder. It will be maintained within the Python Packaging Team. Best wishes, Julian
Bug#1000903: ITP: qtsass -- Python package to bridge the gap between SASS and Qt-CSS
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: qtsass Version : 0.3.0+git20200324.06f1519 Upstream Author : Spyder Project Contributors * URL : https://github.com/spyder-ide/qtsass * License : MIT Programming Lang: Python Description : Python package to bridge the gap between SASS and Qt-CSS SASS brings countless amazing features to CSS. Besides being used in web development, CSS is also the way to stylize Qt-based desktop applications. However, Qt's CSS has a few variations that prevent the direct use of SASS compiler. The purpose of this tool is to fill the gap between SASS and Qt-CSS by handling those variations. The goal of QtSASS is to be able to generate a Qt-CSS stylesheet based on a 100% valid SASS file. This package is a (recursive) dependency of the new version of Spyder. It will be maintained within the Debian Python Team. Best wishes, Julian
Bug#1000809: ITP: qstylizer -- Python package to help with the construction of PyQt/PySide stylesheets
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: qstylizer Version : 0.2.1 Upstream Author : Brett Lambright * URL : https://github.com/blambright/qstylizer * License : MIT Programming Lang: Python Description : Python package to help with the construction of PyQt/PySide stylesheets This package allows for both the construction of new stylesheets and the easy modification of existing ones. This package is a dependency of the new version of Spyder (python3-spyder). It will be maintained within the Debian Python Team.
Bug#963605: ITP: python-language-server -- Python implementation of the Language Server Protocol
Hi Pablo, Here's something you might want to look into if you have time, and it's possible upstream would appreciate it. python-language-server does not yet support jedi 0.18 or parso 0.8, but both of these are now in Debian. Getting support for these into python-language-server would be really great! Best wishes, Julian On Mon, Dec 28, 2020 at 03:14:31PM -0300, Pablo Mestre wrote: > Hi, > > I will work on it. Sadly the Covid situation keep me away from work and > packaging > > I will review all the changes on the pkg and the last upstream version > > Regards > pablo
Bug#979204: ITP: textdistance -- Python library for calculating distances between sequences
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: textdistance Version : 4.2.0 Upstream Author : orsinium * URL : https://github.com/life4/textdistance * License : MIT Programming Lang: Python Description : Library for calculating distances between sequences This Python library can calculate the distance between sequences or strings using over 30 algorithms. It is a pure Python implementation, but can make use of other libraries (listed as Suggests, some of which have compiled extensions) for increased speed. This package is a dependency of the new Spyder 4.x series, hence the need to package it. This package will be maintained within the Debian Python Team.
Bug#979203: ITP: pyls-spyder -- Spyder plugin for the Python Language Server
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: pyls-spyder Version : 0.3.0 Upstream Author : Spyder Project Contributors / Spyder IDE * URL : https://github.com/spyder-ide/pyls-spyder * License : MIT Programming Lang: Python Description : Spyder plugin for the Python Language Server This package provides a plugin required by Spyder. This package is a dependency of the new Spyder 4.x series, hence the need to package it. This package will be maintained within the Debian Python Team.
Bug#979202: ITP: pyls-black -- Black plugin for the Python Language Server
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: pyls-black Version : 0.4.6 Upstream Author : Rupert Bedford * URL : https://github.com/rupert/pyls-black * License : MIT Programming Lang: Python Description : Black plugin for the Python Language Server This package provides a plugin to support the Black formatter in editors that support the Python Language Server. . It is recommended by the author to not have python3-yapf or python3-autopep8 installed when using this plugin, as that might lead to unexpected results. This package is a dependency of the new Spyder 4.x series, hence the need to package it. This package will be maintained within the Debian Python Team.
Bug#979201: ITP: abydos -- Python NLP/IR library of phonetic algorithms, string distances and more
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: abydos Version : 0.5.0+git20200210.9ec3824 Upstream Author : Christopher C. Little * URL : https://github.com/chrislit/abydos * License : GPL-3+; one file has different parts which are identified as GPL-3+, BSD-3-clause and freely-redistributable Programming Lang: Python Description : NLP/IR library of phonetic algorithms, string distances and more Abydos is a Python library containing about 40 phonetic algorithms, 35 string distance measures & metrics, 10 stemmers, and 10 string fingerprinters. . Some of the algorithms require installation of the suggested packages. This package is a (recursive) dependency of the new Spyder 4.x series, hence the need to package it. This package will be maintained within the Debian Python Team.
Bug#979200: ITP: three-merge -- Perform a 3-way merge between strings at a character level (Python library)
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: three-merge Version : 0.1.1 Upstream Author : Spyder IDE * URL : https://github.com/spyder-ide/three-merge * License : MIT Programming Lang: Python Description : Perform a 3-way merge between strings at a character level This library is based on the diff-match-patch library. This library performs merges at a character level, as opposed to most VCS systems, which opt for a line-based approach. This package is a dependency of the new Spyder 4.x series, hence the need to package it. This package will be maintained within the Debian Python Team.
Bug#979199: ITP: py-stringmatching -- Library of string tokenizers and similarity measures
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: py-stringmatching Version : 0.4.2+git20201204.6a7fb57 Upstream Author : anhaidgroup, py_stringmatching Team * URL : https://github.com/anhaidgroup/py_stringmatching * License : BSD-3-clause Programming Lang: Python Description : Library of string tokenizers and similarity measures This project seeks to build a Python software package that consists of a comprehensive and scalable set of string tokenizers (such as alphabetical tokenizers, whitespace tokenizers) and string similarity measures (such as edit distance, Jaccard, TF/IDF). This package is a (recursive) dependency of the new Spyder 4.x series, hence the need to package it. This package will be maintained within the Debian Python Team.
Bug#979198: ITP: pyxdameraulevenshtein -- Fast Damerau-Levenshtein (DL) edit distance implementation
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: pyxdameraulevenshtein Version : 1.6.1 Upstream Author : Geoffrey Fairchild * URL : https://github.com/gfairchild/pyxDamerauLevenshtein * License : BSD-3-clause Programming Lang: Python (and Cython) Description : Fast Damerau-Levenshtein (DL) edit distance implementation This Python library for computing the Damerau-Levenshtein (DL) edit distance for sequences has been developed using Cython for speed. This package is a (recursive) dependency of the new Spyder 4.x series, hence the need to package it. This package will be maintained within the Debian Python Team.
Bug#979197: ITP: distance -- Python library for comparing sequences
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: distance Version : 0+git20131122.ad7f9dc Upstream Author : Michaël Meyer * URL : https://github.com/doukremt/distance * License : GPL-3+, public-domain, BSD-1-clause Programming Lang: Python (with a disabled C library) Description : Python library for comparing sequences This package provides helpers for computing similarities between arbitrary sequences. Included metrics are Levenshtein, Hamming, Jaccard, and Sorensen distance, plus some bonuses. The distance computations are implemented in pure Python. This package is needed as a build dependency for python3-textdistance, which is a much more comprehensive Python package for calculating the distance between sequences. This package is a (recursive) dependency of the new Spyder 4.x series, hence the need to package it. There is an included C library which is optional but broken and so has been disabled. This package will be maintained within the Debian Python Team.
Bug#979196: ITP: paq -- Python library for the paq9a compression algorithm
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: paq Version : 0.1.1+git20170722.9c5d493 Upstream Author : Jingchao Hu * URL : https://github.com/observerss/paq * License : MIT, GPL-3+ (different files with different licenses) Programming Lang: Python (with a C extension) Description : Python library for the paq9a compression algorithm This Python library supports compression and decompression using the paq9a algorithm. This package is a (recursive) dependency of the new Spyder 4.x series, hence the need to package it. This package will be maintained within the Debian Python Team.
Bug#979195: ITP: pylzss -- Python library for the LZSS compression algorithm
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: pylzss Version : 0+git20200722.871ef5a Upstream Author : Guillaume Tucker * URL : https://github.com/yyogo/pylzss * License : LGPL-3+, MIT, Free-Use (different files are under different licenses). The Free-Use license is reproduced below. Programming Lang: Python (with C extension) Description : Python library for the LZSS compression algorithm This Python library supports compression and decompression using the LZSS algorithm. The Free-Use license reads: Use, distribute, and modify this program freely. Please send me your improved versions. This package is a (recursive) dependency of the new Spyder 4.x series, hence the need to package it. This package will be maintained within the Debian Python Team.
Bug#979194: ITP: syllabipy -- Collection of universal syllabification algorithms (Python library)
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: syllabipy Version : 0.2 Upstream Author : Alex Estes and Christopher Hench * URL : https://github.com/henchc/syllabipy * License : MIT Programming Lang: Python Description : Collection of universal syllabification algorithms This package provides two syllabification algorithms: SonoriPy and LegaliPy. There will be no further updates to this package: SonoriPy has been incorporated into the NLTK library (python3-nltk) and that should be used in preference to this package. Both algorithms have also been incorporated into the Talisman NLP library for JavaScript. This package is a (recursive) dependency of the new Spyder 4.x series, hence the need to package it. This package will be maintained within the Debian Python Team.
Bug#963605: Bug#946451: spyder: work on new upstream release
Dear Drew and everyone,
(This message is Bcc'd to the two ITPs for python-language-server
(#963605) and python-jsonrpc-server (#964497), but it makes sense for
the discussion to remain on one report only. I've also cc'd Otto -
see below.)
I was frustrated that I couldn't use Spyder 3 any more because of some
fatal bug (#976966), and I really want to use Spyder 3. So I decided
over the last few days to package the new (4.2.1) Spyder dependencies
and see where I got to. So this is a long email giving the state of
play after my experiments.
tl;dr - I still can't run Spyder and I don't know why not. But I have
built all of the dependencies and they are all on salsa; I haven't yet
submitted ITPs for them but they are all ready to go. (I also haven't
checked whether anyone else has already done so, except for the
repository that already existed in the Python teams project salsa.)
Should I submit ITPs and upload what I have done so far?
Long version
Here is the dependency chain for Spyder 4.2.1 (only listing packages
not yet in the archive); source packages are named first, and the
relevant binary packages listed in parentheses afterwards:
Level 1 (can be built entirely within the current sid environment)
---
python-jsonrpc-server (python3-pyls-jsonrpc) - already has ITP #964497
syllabipy (python3-syllabipy)
pylzss (python3-lzss)
paq (python3-paq)
distance (python3-distance)
pyxdameraulevenshtein (python3-pyxdameraulevenshtein)
py-stringmatching (python3-py-stringmatching)
three-merge (python3-three-merge)
wurlitzer (python3-wurlitzer) - already has ITP #942829
Level 2 (depends on at least one Level 1 package)
---
python-language-server (python3-pyls) - already has ITP #963605
- depends:
python3-pyls-jsonrpc
abydos (python3-abydos)
- depends:
python3-syllabipy
python3-lzss
python3-paq
spyder-kernels [upgrade]
- depends:
python3-wurlitzer
Level 3 (depends on at least one Level 2 package)
---
pyls-black (python3-pyls-black)
- depends: python3-pyls
pyls-spyder (python3-pyls-spyder)
- depends: python3-pyls
textdistance (python3-textdistance)
- depends:
python3-abydos
python3-distance
python3-pylev (in NEW)
python3-pyxdameraulevenshtein
python3-py-stringmatching
Level 4 (depends on at least one Level 3 package)
---
spyder [upgrade]
- depends:
python3-pyls-black
python3-pyls-spyder
python3-spyder-kernels (>= 1.10.1)
python3-textdistance
python3-three-merge
Notes on this chain:
* All of these packages are available on salsa as
https://salsa.debian.org/python-team/packages/PKG
I have included myself and Otto Kekäläinen as
uploaders - I included Otto just because he is already listed on the
python-language-server packages. Happy to hand any of these over to
anyone else who wants them!
* python3-jedi has been upgraded to version 0.18. This introduced
incompatible changes that have broken at least python3-ipython,
python3-pyls and those packages that depend on them.
* python3-parso has been upgraded to version 0.8.1. This has had a
similarly problematic effect.
* syllabipy is a deprecated package. There is a very recent pull
request on nltk to incorporate the rest of the functionality of
syllabipy into nltk. Once that happens, there can be a request to
abydos to remove its dependency on syllabipy (it already depends on
nltk) and syllabipy can be dropped completely.
* I have forked the spyder-kernels and spyder repositories on Salsa
and pushed my work to the experimental (and upstream and
pristine-tar) branches.
OK, so where are we now?
Well, it's not very good news, unfortunately.
I try running spyder and this is what I get:
euler:~ $ spyder
Traceback (most recent call last):
File "/usr/bin/spyder", line 33, in
sys.exit(load_entry_point('spyder==4.2.1', 'gui_scripts', 'spyder')())
File "/usr/lib/python3/dist-packages/spyder/app/start.py", line 213, in main
mainwindow.main(options, args)
File "/usr/lib/python3/dist-packages/spyder/app/mainwindow.py", line 3624, in
main
mainwindow = create_window(app, splash, options, args)
File "/usr/lib/python3/dist-packages/spyder/app/mainwindow.py", line 3482, in
create_window
main.setup()
File "/usr/lib/python3/dist-packages/spyder/app/mainwindow.py", line 514, in
setup
self, icon=ima.icon('close_pane'),
File "/usr/lib/python3/dist-packages/spyder/utils/icon_manager.py", line 421,
in icon
return qta.icon(*args, **kwargs)
File "/usr/lib/python3/dist-packages/qtawesome/__init__.py", line 125, in icon
return _instance().icon(*names, **kwargs)
File "/usr/lib/python3/dist-packages/qtawesome/iconic_font.py", line 259, in
icon
parsed_options.append(self._parse_options(specific_options,
File "/usr/lib/python3/dist-packages/qtawesome/iconic_font.py", line 308, in
_parse_options
prefix, chars = self._get_prefix_chars(names)
File
Bug#942829: wurlitzer package
On Mon, Nov 18, 2019 at 01:10:27PM +0200, mer...@debian.org wrote: > On 2019-11-18 12:56, MARIE Alexandre wrote: > > It worked ! Pristine-tar and v2.0.0 are now on the salsa.debian git. > > Glad this helped! > > Best, > Andrius Hi all, I need this package in order to build the new version of Spyder. I didn't realise there was already an ITP, so I built my own package, only to discover the work has already been done! I'm happy to push a small tweak to the packaging, so it runs the test suite during build, and then would it be OK if I upload it to NEW? It's been sitting on salsa for over a year now. Best wishes, Julian
Bug#963605: ITP: python-language-server -- Python implementation of the Language Server Protocol
Hi Pablo, I've just committed a working package, ready for uploading to unstable, to the new repository: https://salsa.debian.org/python-team/packages/python-language-server g...@salsa.debian.org:python-team/packages/python-language-server.git If you're happy with this package and with python-jsonrpc-server, I can upload them to unstable (though of course they will have to go through NEW first). Best wishes, Julian On Mon, Dec 28, 2020 at 03:14:31PM -0300, Pablo Mestre wrote: > Hi, > > I will work on it. Sadly the Covid situation keep me away from work and > packaging > > I will review all the changes on the pkg and the last upstream version > > Regards > pablo > > El 28/12/20 a las 12:25, Julian Gilbey escribió: > > Hi Pablo, > > > > What is the current status of your ITP for python-language-server? It > > seems to be needed to get Spyder 4 into unstable. If you no longer > > have interest in working on this package (or on > > python-jsonrpc-server), that's not a problem - please just say so! > > > > Best wishes, > > > >Julian
Bug#964497: Info received (ITP: python-jsonrpc-server -- JSON-RPC is a stateless, light-weight remote procedure call (RPC) protocol)
On Mon, Dec 28, 2020 at 04:06:21PM -0300, Pablo Mestre wrote: > > El 28/12/20 a las 12:11, Julian Gilbey escribió: > > On Fri, Nov 06, 2020 at 11:43:25PM +0200, Otto Kekäläinen wrote: > >> Thanks! > >> > >> I will update the changelog and upload current > >> https://salsa.debian.org/python-team/packages/python-jsonrpc-server/-/commits/debian/master > >> unless Boyuan or Jochen have something more to add/review about the > >> packaging. > > Hi all, > > > > I just rebuilt this package with the latest upstream version using a > > Debian testing system and had no problem at all. > > > > Would you like me to commit my changes to > > https://salsa.debian.org/python-team/packages/python-jsonrpc-server? > > > > Best wishes, > > > >Julian > Yes please... Hi Pablo, I've pushed my changes. The package now builds perfectly with sbuild, so I'd be happy to upload it to unstable. Best wishes, Julian
Bug#964497: Info received (ITP: python-jsonrpc-server -- JSON-RPC is a stateless, light-weight remote procedure call (RPC) protocol)
On Fri, Nov 06, 2020 at 11:43:25PM +0200, Otto Kekäläinen wrote: > Thanks! > > I will update the changelog and upload current > https://salsa.debian.org/python-team/packages/python-jsonrpc-server/-/commits/debian/master > unless Boyuan or Jochen have something more to add/review about the packaging. Hi all, I just rebuilt this package with the latest upstream version using a Debian testing system and had no problem at all. Would you like me to commit my changes to https://salsa.debian.org/python-team/packages/python-jsonrpc-server? Best wishes, Julian
Bug#963605: ITP: python-language-server -- Python implementation of the Language Server Protocol
Hi Pablo, What is the current status of your ITP for python-language-server? It seems to be needed to get Spyder 4 into unstable. If you no longer have interest in working on this package (or on python-jsonrpc-server), that's not a problem - please just say so! Best wishes, Julian
Bug#968823: ITP: maturin -- ITP: maturin - Build and publish crates with pyo3, rust-cpython and cffi bindings as well as rust binaries as python packages
close 968823 thanks On Fri, Aug 21, 2020 at 07:30:05PM +0100, Julian Gilbey wrote: > Package: wnpp > Severity: wishlist > Owner: Julian Gilbey > X-Debbugs-Cc: debian-de...@lists.debian.org > > * Package name: maturin > Version : 0.8.3 > Upstream Author : Konstin > * URL : https://github.com/pyo3/maturin > * License : MIT OR Apache-2.0 > Programming Lang: Rust and Python > Description : ITP: maturin - Build and publish crates with pyo3, > rust-cpython and cffi bindings as well as rust binaries as python packages > > This project is meant as a zero configuration replacement for > setuptools-rust and milksnake. It supports building wheels for python > 3.5+ on windows, linux, mac and freebsd, can upload them to pypi and > has basic pypy support. > > This will be maintained within the Rust Packaging Team. It is a > build-dependency for recent versions of Anki. I later realised that this creates wheels, which are not actually used in Debian. Furthermore, anki has moved away from maturin. So I'm closing this ITP but not packaging the software. Julian
Bug#968823: ITP: maturin -- ITP: maturin - Build and publish crates with pyo3, rust-cpython and cffi bindings as well as rust binaries as python packages
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: maturin Version : 0.8.3 Upstream Author : Konstin * URL : https://github.com/pyo3/maturin * License : MIT OR Apache-2.0 Programming Lang: Rust and Python Description : ITP: maturin - Build and publish crates with pyo3, rust-cpython and cffi bindings as well as rust binaries as python packages This project is meant as a zero configuration replacement for setuptools-rust and milksnake. It supports building wheels for python 3.5+ on windows, linux, mac and freebsd, can upload them to pypi and has basic pypy support. This will be maintained within the Rust Packaging Team. It is a build-dependency for recent versions of Anki.
Bug#898246: git-lab requires golang-github-xanzy-go-gitlab
On Fri, Jan 24, 2020 at 02:23:48PM -0800, Felix Lechner wrote: > Hi Julian, > > On Fri, Jan 24, 2020 at 3:39 AM Julian Gilbey wrote: > > > > The version of xanzy in debian/sid on salsa is very out of date - the > > upstream version is now 0.22, but debian/sid is lagging on 0.15. > > State of package on Mentors (based on upstream's version 0.22) was > pushed to the golang team repo. Ah, sorry, my pull didn't seem to update my local repository correctly. Best wishes, Julian
Bug#898246: git-lab requires golang-github-xanzy-go-gitlab
On Thu, Jan 23, 2020 at 04:01:34PM -0800, Felix Lechner wrote: > Hi, > > On Sun, Dec 15, 2019 at 7:46 AM Dominique Dumont wrote: > > > > Felix, could you resume packaging this software ? > > Do you know anyone with upload privileges? :) Please feel free to > upload the required prerequisite > > golang-github-xanzy-go-gitlab > > in #947304. My RFS had no takers for a month. I will package git-lab > for you afterwards. Hi Felix, I looked at git-lab but got completely stuck on the dependencies: they are very specific, and in particular, go.mod includes the override line: replace github.com/spf13/cobra => github.com/rsteube/cobra v0.0.1-zsh-completion-custom How do you propose to handle that? I couldn't think of a way to do so, unless you are able to package the replacement cobra as well. The version of xanzy in debian/sid on salsa is very out of date - the upstream version is now 0.22, but debian/sid is lagging on 0.15. Best wishes, Julian
Bug#866334: About Bug#866334: RFP: lean -- theorem prover from Microsoft Research
I've just started looking at lean. One of the issues around packaging it is that different lean "scripts" (not sure the correct word here) require different versions of lean. There is a script available which downloads the required version of lean for any particular script, and so keeps a local set of lean versions. If we were to package lean for Debian, what exactly would we package? The current stable version, or a script such as this? See https://github.com/leanprover-community/mathlib/blob/master/docs/install/debian_details.md for a little more on this. Thoughts would be appreciated! Best wishes, Julian
Bug#472802: Limesurvey packaging was moved from SVN to Git
On Thu, Feb 01, 2018 at 11:46:11AM +0100, Andreas Tille wrote: > Hi Julian, > > On Thu, Feb 01, 2018 at 09:33:10AM +0000, Julian Gilbey wrote: > > > https://anonscm.debian.org/git/collab-maint/limesurvey.git > > > > > > Please note: I'm NOT interested on working on the package in the > > > foreseable future but once I had a look into limesurvey and there is a > > > vague chance that I become interested in a far future again. So please > > > do not consider me as an active contributor to the package but I hope > > > you like the move to Git. > > > > Hi Andreas, > > > > Thanks for this. I'm a little confused though: you've moved it from > > SVN on Alioth to Git on Alioth, so it'll still disappear? > > As far as I know some automatic conversion will be done. > > > Would it > > not make more sense to move it to salsa? > > That's correct but I did not found any collab-maint project on Salsa > yet. As far as I'm aware there is some automatic method to move whole > projects from Alioth to Salsa and that will happen at some point in > time. If you know how to move the project to Salsa feel free to do > so since this should be easy now. > > Kind regards > > Andreas. Thanks Andreas! OK, I've now done that. I'm not aware of any plans to migrate Alioth git repositories wholesale to salsa, though individual teams (such as the Go packaging team) are planning to migrate groups of respositories. Some information about migration is available at https://wiki.debian.org/Salsa/Doc - in particular, the collab-maint is now the Debian/ namespace. Limesurvey now lives at Vcs-Browser: https://salsa.debian.org/debian/limesurvey Vcs-Git: https://salsa.debian.org/debian/limesurvey.git Best wishes, Julian
Bug#472802: Limesurvey packaging was moved from SVN to Git
On Thu, Feb 01, 2018 at 09:27:15AM +0100, Andreas Tille wrote: > Hi, > > I've checked what packages I'm interested in were remaining in SVN. The > upcoming closing down of Alioth should not affect this code and thus I > took the freedom to move limesurvey to > > https://anonscm.debian.org/git/collab-maint/limesurvey.git > > Please note: I'm NOT interested on working on the package in the > foreseable future but once I had a look into limesurvey and there is a > vague chance that I become interested in a far future again. So please > do not consider me as an active contributor to the package but I hope > you like the move to Git. Hi Andreas, Thanks for this. I'm a little confused though: you've moved it from SVN on Alioth to Git on Alioth, so it'll still disappear? Would it not make more sense to move it to salsa? Best wishes, Julian
Bug#852362: ITP: send2trash -- Python module for sending file to trash natively
Package: wnpp Severity: wishlist Owner: Julian Gilbey <j...@debian.org> * Package name: send2trash Version : 1.3.0 Upstream Author : Hardcoded Software <hs...@hardcoded.net> * URL : http://github.com/hsoft/send2trash * License : BSD Programming Lang: Python Description : Python module for sending file to trash natively This module sends a file to the trash using either the Glib system for handling a desktop trash file or its own home-grown system if python-gi is not installed. It is a very simple module; it works on Python 2 and 3, and will be needed by the new version of Anki (2.1.0-alpha), as this module is no longer bundled within the Anki distribution.
Bug#842111: ITP: jigsaw-generator -- Mathematical jigsaw creation software
Package: wnpp Severity: wishlist Owner: Julian Gilbey <j...@debian.org> * Package name: jigsaw-generator Version : 0.2.1 Upstream Author : Julian Gilbey <j...@debian.org> * URL : https://github.com/juliangilbey/jigsaw-generator.git * License : GPL Programming Lang: Python Description : Mathematical jigsaw creation software This software is designed to create Tarsia Formulator type mathematical jigsaws using LaTeX. The puzzle data is stored in a YAML file, and the software turns it into a printable jigsaw. This software makes it reasonably straightforward to create multiple jigsaw-style puzzles. I am the upstream author; I presented it at a TUG Conference a couple of years ago, but have not yet packaged it for Debian. It is now mature enough to release. There is no Linux package like it that I am aware of.
Bug#718273: #718273 ITP: go-fuse -- FUSE bindings for Go
On Sun, Sep 13, 2015 at 07:45:08PM +1000, Dmitry Smirnov wrote: > On Saturday 12 September 2015 21:54:44 Julian Gilbey wrote: > > Yes, I would love some help! > > Thank you. I've committed few minor corrections to the repository... :) Thanks! > > Vcs-Browser: > > https://anonscm.debian.org/cgit/pkg-go/packages/golang-github-hanwen-go-fu > > se.git Vcs-Git: > > git://anonscm.debian.org/pkg-go/packages/golang-github-hanwen-go-mtpfs.git > > Nice. :) I've corrected Vcs-Git URL too. ;) Sweet! > > I haven't managed to get to the bottom of this. I could disable the > > tests (as I needed to do for the go-mtpfs package), but that seems to > > be avoiding the problem. > > > > If you have any idea of the cause of this, it would be great! > > I do not know why unionfs test is failing. However I believe we have to > ignore test failures anyway as tests rely on "fuse" and "modprobe fuse" hence > they will be failing on build servers and in pbuilder... Ah, that is true. But there is no point having -dh_auto_test in debian/rules, then, as people are unlikely to look at the detailed test output if it doesn't cause build failures. > I think go-fuse is ready for upload. OK, will do. > Personally I would add "watch" file even though upstream do not tag releases > yet. Maybe you could ask upstream to produce a formal release? Sounds a good idea. Though I'll only add a watch file if there are releases or tags. Thanks for your help! Julian
Bug#718273: #718273 ITP: go-fuse -- FUSE bindings for Go
I did get an error when pushing: remote: /home/groups/pkg-go/meta/pkg-go-post-receive: 10: /home/groups/pkg-go/meta/pkg-go-post-receive: cannot create hooks/reflog: Permission denied Hmm. Who takes responsibility for things like that - do you happen to know? Anyway, packages now uploaded. Thanks, Julian
Bug#718273: #718273 ITP: go-fuse -- FUSE bindings for Go
On Sat, Sep 12, 2015 at 07:11:50AM +1000, Dmitry Smirnov wrote: > Hi Julian, > > How is the progress with "go-fuse"? > > Packaging seems to be trivial and license is clear. Do you need any help? Yes, I would love some help! I have a package at Vcs-Browser: https://anonscm.debian.org/cgit/pkg-go/packages/golang-github-hanwen-go-fuse.git Vcs-Git: git://anonscm.debian.org/pkg-go/packages/golang-github-hanwen-go-mtpfs.git It built fine a couple of weeks ago, when I submitted the ITP. I decided to wait a week in case there were any objections before uploading it to sid. But in that week, I upgraded my testing machine and also tried building on sid, and now both fail on two of the unionfs tests: --- FAIL: TestExplicitScan (0.03s) autounion_test.go:218: Should have workspace backing1: lstat /tmp/764464878/mnt/backing1: no such file or directory --- FAIL: TestUnionFsDropDeletionCache (0.09s) unionfs_test.go:1039: Lstat() should have succeeded lstat /tmp/unionfs541255389/mnt/file: no such file or directory I haven't managed to get to the bottom of this. I could disable the tests (as I needed to do for the go-mtpfs package), but that seems to be avoiding the problem. If you have any idea of the cause of this, it would be great! Julian
Bug#795301: ITP: golang-github-hanwen-usb -- CGO bindings for libusb.
Package: wnpp Severity: wishlist Owner: Julian Gilbey j...@debian.org * Package name: golang-github-hanwen-usb Version : 0.0~git20141217.0.69aee45-1 Upstream Author : Han-Wen Nienhuys * URL : https://github.com/hanwen/usb * License : BSD-3-clause Programming Lang: Go Description : CGO bindings for libusb. These are GO bindings for libusb, created and tested on Linux. This package is a dependency of go-mtpfs (for which an ITP has been filed).
