Bug#1081510: RM: distance -- ROM; unmaintained upstream and no longer needed

2024-09-12 Thread Julian Gilbey
Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: dista...@packages.debian.org, debian-python@lists.debian.org
Control: affects -1 + src:distance

distance was a dependency of textdistance, but with the migration of
4.6.3-4 of that package to testing, there is no dependency on distance
any longer in unstable or testing.

distance is ancient, it's C-extension no longer compiles with recent
Python versions, and its functionality is available in other
(maintained) packages.



Re: Bug#1024971: pybuild: should fail when the result of running tests is "Ran 0 tests in 0.000s"

2024-09-09 Thread Julian Gilbey
On Mon, Sep 09, 2024 at 08:31:52AM +, Stefano Rivera wrote:
> > Hi Julian (2024.09.08_21:33:49_+)
> > > I built 6440 packages build-depending on dh-python in one way or
> > > another. 1483 failed, and 1124 of them say "NO TESTS RAN" in the logs.
> > 
> > My guess is that most of these 1124 have no tests at all, rather than
> > having a misconfigured setup.  A unittest is the pybuild default test
> > framework, unittest is used and fails to find any tests, hence all of
> > these failures.
> 
> Yes, almost certainly.
> [...]
> 
> I would leave unittest as the default runner, but without missing test
> detection.
> 
> That's a slightly unexpected behaviour, but it makes the default case
> work.
> 
> Downside is that you have to opt-in to missing test detection. Maybe we
> can have a lintian tag for that?

That seems a bit heavy to ask for.

Is there any way of identifying those packages that do genuinely use
unittest?  If there are not that many of them, then implementing a
--test-unittest option would be a good way to go.  I would imagine the
following timeline:

(1) --test-unittest is introduced as an option to explicitly select
unittest as the test framework.  When --test-unittest is specified,
the test will fail if no tests are found.  unittest is still used as a
fallback test framework; in this case, the dh_auto_test call will
succeed if no tests are run.

(2) Add some sort of warning for pybuild-using packages that run
dh_auto_test but haven't specified a test framework and for which
autodetection of the test framework fails.  If there aren't any tests
to run, an empty override_dh_auto_test target should be specified.

(3) Stop using unittest as the default test framework, and fail if no
test framework has been specified or autodetected.

But that might be overkill for something which may not actually be
much of a problem.

Best wishes,

   Julian



Re: Is it OK to include CSS files via a Debian patch to patch out cloudflare links?

2024-09-09 Thread Julian Gilbey
On Mon, Sep 09, 2024 at 03:39:18PM +0300, Dmitry Shachnev wrote:
> Hi all,
> 
> On Mon, Sep 09, 2024 at 02:06:21PM +0200, Salvo Tomaselli wrote:
> > Yes please remove tracking!
> >
> > In typedload I have a makefile target that replaces it.
> 
> FWIW, dh_mkdocs has code which should take care of that [1], there is no need
> to replace it manually.
> 
> [1]: 
> https://sources.debian.org/src/python-mkdocs/1.5.3%2Bdfsg-1/debian/scripts/dh_mkdocs/#L146

Oh, amazing - I didn't know about this script!  Thanks for writing it,
Dmitry!  Now I should run off and use it in all my mkdocs-using
packages

Best wishes,

   Julian



Re: Bug#1024971: pybuild: should fail when the result of running tests is "Ran 0 tests in 0.000s"

2024-09-08 Thread Julian Gilbey
On Sun, Sep 08, 2024 at 03:43:33PM +0200, Stefano Rivera wrote:
> [...]
> We've implemented the feature in Python 3.12, unittest's runner now
> exits with return value 5 if no tests were discovered, like pytest does.
> https://github.com/python/cpython/issues/113661
> [...]
> 
> I built 6440 packages build-depending on dh-python in one way or
> another. 1483 failed, and 1124 of them say "NO TESTS RAN" in the logs.

My guess is that most of these 1124 have no tests at all, rather than
having a misconfigured setup.  A unittest is the pybuild default test
framework, unittest is used and fails to find any tests, hence all of
these failures.

> To fix these build failures, package maintainers would have these
> options:
> 
> 1. Get the build to run some unit tests (assuming they exist),
> 2. override_dh_auto_test with something noop,
> 3. export PYBUILD_DISABLE=test,
> 4. We could make this failure opt-in in dh-python. Maybe via an explicit
>--test-unittest option that selects the unittest runner. If you don't
>explicitly select this runner, you'd get an attempt to run tests by
>with unittest, and no failure if no tests are found.

I like option 4 for the above reason.  But implementing this would
mean that all of the packages that currently *do* use unittest
(intentionally, but without having to code it explicitly as it's the
default) would suddenly not have any tests running until they
proactively add --test-unittest or set PYBUILD_TEST_UNITTEST = 1 or
similar.  This seems like an unfortunate consequence.

Is there a way of looking at the logs of the packages that passed the
build to identify which ones successfully passed tests using unittest?
There is also the issue of packages that use unittest (as the default)
via autopkgtest-pkg-pybuild but override dh_auto_test during the
build, though that will be much rarer.

Best wishes,

   Julian



Re: Python3.12 and a half

2024-08-23 Thread Julian Gilbey
On Fri, Aug 23, 2024 at 09:55:17AM +0200, Matthias Klose wrote:
> On 22.08.24 21:37, Alexandre Detiste wrote:
> > Hi,
> > 
> > Would it be possible to remove 2to3 from Python3.12 without waiting for 
> > 3.13 ?
> > 
> > I see in the meantime a new usage was brought back.
> > 
> > I'll check if this "slimit" package can be easily switched to 
> > python3-fissix;
> > which is a 2to3 fork that is already used to keep python3-nose
> > artificially alive.
> 
> I'd like to avoid addressing a single module. 3.13 has a whole bunch of
> modules that are removed in the standard library.
> 
> What's the status of filing bug reports for all these removed modules?
> 
> Matthias

Lintian does do a check for them: uses-deprecated-python-stdlib
but beware of false positives, in particular for uu and crypt; see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1077324 (which is
now pending an upload).  (There used to be a website
lintian.debian.org where you could search reports by tag, but that
doesn't seem to exist any more, and I haven't had any luck searching
with UDD.)

Best wishes,

   Julian



Re: Moving default branch after project creation

2024-08-07 Thread Julian Gilbey
On Thu, Aug 08, 2024 at 05:50:38AM +0200, Carsten Schoenert wrote:
> Am 07.08.24 um 22:33 schrieb Julian Gilbey:
> 
> > The candidate DEP-14 (https://dep-team.pages.debian.net/deps/dep14/)
> > currently reads:
> > 
> >In Debian this means that uploads to unstable and experimental
> >should be prepared either in the debian/latest branch or
> >respectively in the debian/unstable and debian/experimental
> >branches.
> > 
> > I'm not sure where you got debian/master from?
> 
> From the Team Policy?
> 
> https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst#branch-names

The OP specifically said they got it from DEP-14.  Thanks also to
Nicholas for reminding me of the DEP-14 history!

Best wishes,

   Julian



Re: Moving default branch after project creation

2024-08-07 Thread Julian Gilbey
On Wed, Aug 07, 2024 at 08:27:33PM +0300, Alexandru Mihail wrote:
> Hi, I've recently created
> https://salsa.debian.org/python-team/packages/psrecord following
> previous ITP. The main branch was set to main and I'd like to move it
> to DEP compliant debian/master and delete the main branch. 

The candidate DEP-14 (https://dep-team.pages.debian.net/deps/dep14/)
currently reads:

  In Debian this means that uploads to unstable and experimental
  should be prepared either in the debian/latest branch or
  respectively in the debian/unstable and debian/experimental
  branches.

I'm not sure where you got debian/master from?

> (Maybe I screwed up by forgetting to uncheck the Readme.md first commit
> ?)
> I cannot delete the default branch as expected, but Salsa doesn't let
> me move it to debian/master either. I think I don't have the required
> permissions.
> remote: GitLab: The default branch of a project cannot be deleted.
> To salsa.debian.org:python-team/packages/psrecord.git
>  ! [remote rejected] main (pre-receive hook declined)
> error: failed to push some refs to 'salsa.debian.org:python-
> team/packages/psrecord.git'

Have you tried using the web interface to change the default?
(Settings > Repository) Create a new branch called debian/latest,
branched from master, then set the default branch to debian/latest
(and perhaps unprotect the master branch on the same page).

Best wishes,

   Julian



Re: Policy Change Proposal: Running the upstream test suite

2024-07-30 Thread Julian Gilbey
On Tue, Jul 30, 2024 at 01:30:57PM +0500, Andrey Rakhmatullin wrote:
> > Maybe we should  install only the python binaries and the dependencies 
> > marked .
> 
> In a typical simple case all B-Ds except sphinx stuff will be 
> as you don't need anything beyond the build system to "build" a pure
> Python module.

Erm, no, you need to B-D on all runtime dependencies so they are
correctly included in the computed python3:Depends substvar, unless
you list these runtime dependencies explictly by hand.

Best wishes,

   Julian



Re: Policy Change Proposal: Running the upstream test suite

2024-07-29 Thread Julian Gilbey
On Mon, Jul 29, 2024 at 12:07:27PM +, Scott Kitterman wrote:
> I understand the theory and why it's a good idea to run the test suite.  I 
> don't think it ought to be a hard requirement.  I have several packages where 
> there's a test suite, but I don't run it:
> [...]

Here's another case: the package has to be fully installed for the
test suite to work.  So the tests can't be run at build time, only at
autopkgtest time.

Best wishes,

   Julian



Re: Seeking help with packaging Home Assistant dependencies

2024-07-23 Thread Julian Gilbey
On Tue, Jul 23, 2024 at 04:38:47PM +0200, Salvo Tomaselli wrote:
> Is there no way, especially in the beginig, to patch out funcionality?
> 
> Stuff like volvo on call doesn't seem very vital to run the thing.
> 
> I'd focus on identifying the real dependencies and prioritize rest later on, 
> when you can get the minimal thing running perhaps.

Hi Edward,

Can I add: the larger task is not the initial packaging (though that
itself is a very large task); it's the ongoing maintenance of these
666 packages.  Who is going to do that work (including ensuring that
any resulting updates don't break anything higher up the dependency
chain)?  Until that question has an answer, I would strongly recommend
following Salvo's suggestions.  Then if someone really wants feature
XYZ, that would be a good time to package the relevant module.

It might be that HomeAssistant is too big a task for Debian to take on
unless there's a small group of interested maintainers able to do it;
perhaps there could be a HomeAssistant Team?

Best wishes,

   Julian

> In data martedì 23 luglio 2024 13:25:53 CEST, Edward Betts ha scritto:
> > Hello,
> > 
> > I am proposing the addition of Home Assistant, a Python-based smart home
> > platform, to Debian. Home Assistant requires extensive hardware integrations
> > and thus has a significant number of Python module dependencies.
> > 
> > Upon review, I've identified 666 Python modules required by Home Assistant
> > that are not yet available in Debian. As I am attending DebConf in Busan,
> > South Korea, I have chosen this as my DebCamp project. While it's a massive
> > undertaking and may seem ambitious, any contributions to this effort would
> > be greatly appreciated.
> > 
> > You can find the list of these dependencies here:
> > 
> > https://people.debian.org/~edward/ha/
> > 
> > I encourage anyone interested to join in helping to package these
> > dependencies.
> > 
> > Thank you!



Re: Bug#1076698: ITP: haversine -- Geographic distance calculation library for Python

2024-07-22 Thread Julian Gilbey
What a delightful package name!  You might enjoy reading
https://undergroundmathematics.org/trigonometry-triangles-to-functions/lost-but-lovely-the-haversine

Best wishes,

   Julian

On Mon, Jul 22, 2024 at 04:20:49AM +0100, Edward Betts wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Edward Betts 
> X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@lists.debian.org
> 
> * Package name: haversine
>   Version : 2.8.1
>   Upstream Author : Julien Deniau 
> * URL : https://github.com/mapado/haversine
> * License : MIT
>   Programming Lang: Python
>   Description : Geographic distance calculation library for Python
> 
>   The Haversine library provides functions to calculate the distance between 
> two
>   points on Earth from their latitude and longitude. Suitable for various
>   applications in geospatial analyses, navigation, and travel optimization, 
> the
>   library supports distance calculations in multiple units such as kilometres,
>   meters, miles, nautical miles, feet, and inches, as well as in radians and
>   degrees for angular distances.
> 
> I plan to maintain this package as part of the Python team.
> 
> 


   Julian



Re: pybuild and setuptools_scm

2024-07-19 Thread Julian Gilbey
On Fri, Jul 19, 2024 at 11:06:46AM +, Stefano Rivera wrote:
> [...]
> > May be pybuild doesn't handle correctly a version string like 0.10.0+dfsg-1?
> 
> Yeah, you shouldn't have to export that because pybuild does. But,
> right, it's not removing +dfsg. Now that PEP-440 versions are strongly
> enforced, that's no good.
> 
> Committed:
> https://salsa.debian.org/python-team/tools/dh-python/-/commit/ae0facfd1216fd25185aa5f1db9f12b26e3dbcf1

But PEP-440 allows "+dfsg" as the "Local version identifier", so I
don't understand why this must be removed.

Best wishes,

   Julian



Bug#1076422: RM: python-bytecode -- ROM; No longer needed for debugpy

2024-07-15 Thread Julian Gilbey
Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: python-bytec...@packages.debian.org, 
debian-python@lists.debian.org
Control: affects -1 + src:python-bytecode

python-bytecode was packaged purely to avoid having a vendored version
embedded in pydevd.  In turn, pydevd was packaged purely to avoid
having a vendored version of the package embedded in debugpy.  debugpy
has now diverged from the upstream pydevd in an incompatible way, and
there is no prospect of the two merging again (see
https://github.com/microsoft/debugpy/discussions/1611 for more
details).  I have therefore reverted to using the vendored version in
debugpy.  This renders both the pydevd and python-bytecode packages
unnecessary.  I have already requested the removal of pydevd
(#1076421), and there are no other reverse dependencies in unstable
besides this.



Bug#1076421: RM: pydevd -- ROM; No longer needed for debugpy

2024-07-15 Thread Julian Gilbey
Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: pyd...@packages.debian.org, debian-python@lists.debian.org
Control: affects -1 + src:pydevd

pydevd was packaged purely to avoid having a vendored version of the
package embedded in debugpy.  debugpy has now diverged from the
upstream pydevd in an incompatible way, and there is no prospect of
the two merging again (see
https://github.com/microsoft/debugpy/discussions/1611 for more
details).  I have therefore reverted to using the vendored version in
debugpy.  This renders the pydevd package unnecessary.  There are also
no other reverse dependencies in unstable.



Re: pybuild and setuptools_scm

2024-07-13 Thread Julian Gilbey
On Fri, Jul 12, 2024 at 11:29:51PM +, Stefano Rivera wrote:
> Hi Thomas (2024.07.12_12:53:54_+)
> > The way to deal with it, is simply something like this:
> > 
> > export SETUPTOOLS_SCM_PRETEND_VERSION=$(shell dpkg-parsechangelog -SVersion
> > | sed -e 's/^[[:digit:]]*://' -e 's/[-].*//' -e 's/~git.*//' -e 's/~/.0/' -e
> > 's/+dfsg1//' -e 's/+ds1//' | head -n 1)
> > 
> > and then setuptools-scm knows what version to use without using the Git
> > history.
> > 
> > Probably pybuild does that automatically under the hood (I tend to not use
> > pybuild, and so I do the above ...).
> 
> It does.

Assuming your package Build-Depends: python3-setuptools-scm

   Julian



Proposed removal of pydevd and python-bytecode packages

2024-07-04 Thread Julian Gilbey
Hi all,

I'm just uploaded debugpy 1.8.2, which uses a vendored version of
pydevd rather than depending on the Debian python3-pydevd package.

This is necessary, as upstream debugpy has now diverged from upstream
pydevd, whereas until recently, they used to develop the upstream
pydevd in-house, so pydevd was alway in-sync with debugpy - more
details here: https://github.com/microsoft/debugpy/discussions/1611

The only reason I packaged pydevd and its dependency bytecode was to
be able to package debugpy without embedding vendored versions of
these packages.  There are no other packages depending on either of
these in unstable.

I plan to ask ftpmaster to remove these two packages (pydevd and
python-bytecode) once debugpy 1.8.2 makes it to testing, unless there
are any objections.

Best wishes,

   Julian



Re: python3-lazy-fixture removal / prettytable

2024-07-04 Thread Julian Gilbey
Hi Sandro,

And just to note that prettytable is stuck in unstable: the dependency
of pytest-lazy-fixture causes its tests to fail, so it cannot build,
let alone migrate.

Best wishes,

   Julian

On Thu, Jul 04, 2024 at 09:01:39AM +0200, Alexandre Detiste wrote:
> Hi Sandro,
> 
> Please upload a new prettytable.
> 
> It is the last package hindering the removal of pytest-lazy-fixture.
> The live fork is now pytest-lazy-fixtures with an extra "s".
> 
> https://lists.debian.org/debian-python/2024/05/msg00081.html
> 
> Greetings
> 
> >Le lun. 13 mai 2024 à 22:59, Scott Kitterman  a écrit :
> > > I suggest that we soon ask ftpmaster to drop pytest-lazy-fixture from
> > > Debian unstable.
> > Please transition all the rdepends first.
> > Asking before that's done just creates more work for everyone.
> > Scott K



Re: newer dask release

2024-06-17 Thread Julian Gilbey
On Sun, Jun 16, 2024 at 10:57:22PM +0200, Étienne Mollier wrote:
> Thank you for your help with dask documentation, took time to
> polish what I could and uploaded dask.  dask.distributed upload
> is coming soon, just the time for the last pass of local build
> and tests to finish.
> 
> Have a nice day,  :)

Hi Étienne,

Unfortunately, the new dask.distributed FTBFS:
https://buildd.debian.org/status/package.php?p=dask.distributed

:-(

   Julian



Bug#1073531: ITS: python-parse: abandoned package needs upgrading

2024-06-16 Thread Julian Gilbey
Source: python-parse
Version: 1.19.0-0.2
Severity: important
X-Debbugs-Cc: Debian Python Team , 
m...@qa.debian.org

This package was last upgraded in 2021 as an NMU; there has only been
a single upload by the Maintainer - the initial upload in 2013 - and
every other upload has been an NMU.

I intend to salvage this package, and bring it under the
maintainership of the Debian Python Team.

The recently released version 1.20.2 fixes a bug which breaks another
package's tests that I am currently working on (python-openapi-core),
so I am looking to upload the 1.20.2 version.



Bug#1073496: ITP: requests-mock -- Python module to stub HTTP requests in testing code

2024-06-16 Thread Julian Gilbey
Package: wnpp
Severity: wishlist
Owner: Julian Gilbey 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@lists.debian.org

* Package name: requests-mock
  Version : 1.12.1
  Upstream Author : Jamie Lennox
* URL : https://github.com/jamielennox/requests-mock
* License : Apache-2.0
  Programming Lang: Python
  Description : Python module to stub HTTP requests in testing code
 This module creates a custom adapter that allows one to predefine responses
 when certain URIs are called when using the `requests` module.

This package is a (recursive) dependency of the new version of
jupyter-notebook (including its testsuite and docs).

It will be team-maintained within the Debian Python Team.  The Debian
packaging is on salsa at
   https://salsa.debian.org/python-team/packages/requests-mock



Bug#1073495: ITP: pathable -- Python module to traverse and access resources like paths

2024-06-16 Thread Julian Gilbey
Package: wnpp
Severity: wishlist
Owner: Julian Gilbey 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@lists.debian.org

* Package name: pathable
  Version : 0.4.3
  Upstream Author : Copyright: Artur Maciag 
* URL : https://github.com/p1c2u/pathable
* License : Apache-2.0
  Programming Lang: Python
  Description : Python module to traverse and access resources like paths
 This module provides a class DictPath to turn a dictionary into a
 path-like structure, allowing one to traverse them in a similar way to
 using pathlib.

This package is a (recursive) dependency of the new version of
jupyter-notebook (including its testsuite and docs).

It will be team-maintained within the Debian Python Team.  The Debian
packaging is on salsa at
   https://salsa.debian.org/python-team/packages/pathable



Bug#1073494: ITP: openapi-schema-validator -- Validate schema against the OpenAPI Schema Specifications

2024-06-16 Thread Julian Gilbey
Package: wnpp
Severity: wishlist
Owner: Julian Gilbey 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@lists.debian.org

* Package name: openapi-schema-validator
  Version : 0.6.2
  Upstream Author : Artur Maciag 
* URL : https://github.com/python-openapi/openapi-schema-validator
* License : BSD-3-clause
  Programming Lang: Python
  Description : Validate schema against the OpenAPI Schema Specifications
 This Python module validates schema against the OpenAPI Schema Specification
 version 3.0 or 3.1.

This package is a (recursive) dependency of the new version of
jupyter-notebook (including its testsuite and docs).

It will be team-maintained within the Debian Python Team.  The Debian
packaging is on salsa at
   https://salsa.debian.org/python-team/packages/pathable



Bug#1073493: ITP: openapi-core -- Client- and server-side support for OpenAPI specification

2024-06-16 Thread Julian Gilbey
Package: wnpp
Severity: wishlist
Owner: Julian Gilbey 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@lists.debian.org

* Package name: openapi-core
  Version : 0.19.1
  Upstream Author : Artur Maciag
* URL : https://github.com/python-openapi/openapi-core
* License : BSD-3-clause
  Programming Lang: Python
  Description : Client- and server-side support for OpenAPI specification
 This Python library adds client-side and server-side support for the
 OpenAPI v3.0 and v3.1 specification. It offers:
 .
   * validation and unmarshalling of request and response data (including
 webhooks)
   * integration with popular libraries (Requests and Werkzeug) and
 frameworks (Django, Falcon, Flask, Starlette)
   * customization with media type deserializers and format unmarshallers
   * security data providers (API keys, Cookie, Basic and Bearer HTTP
 authentications)

This package is a (recursive) dependency of the new version of
jupyter-notebook (including its testsuite and docs).

It will be team-maintained within the Debian Python Team.  The Debian
packaging is on salsa at
   https://salsa.debian.org/python-team/packages/openapi-core



Bug#1073491: ITP: autodoc-traits -- Sphinx extension to document classes with Traitlets-based config

2024-06-16 Thread Julian Gilbey
Package: wnpp
Severity: wishlist
Owner: Julian Gilbey 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@lists.debian.org

* Package name: autodoc-traits
  Version : 1.2.2
  Upstream Author : Copyright: Project Jupyter Contributors, all rights reserved
* URL : https://github.com/jupyterhub/autodoc-traits
* License : BSD-3-clause
  Programming Lang: Python
  Description : Sphinx extension to document classes with Traitlets-based 
config
 This is a Sphinx extension that builds on sphinx.ext.autodoc to better
 document classes with Traitlets-based configuration.  It provides
 Sphinx directives `autoconfigurable` (use with classes) and `autotrait`
 (use with the traitlets based configuration options), yielding documentation
 that takes account of Traitlets.

This package is a (recursive) dependency of the new version of
jupyter-notebook (including its testsuite and docs).

It will be team-maintained within the Debian Python Team.  The Debian
packaging is on salsa at
   https://salsa.debian.org/python-team/packages/autodoc-traits



Bug#1073492: ITP: jsonschema-path -- Python module for object-oriented JSONSchema

2024-06-16 Thread Julian Gilbey
Package: wnpp
Severity: wishlist
Owner: Julian Gilbey 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@lists.debian.org

* Package name: jsonschema-path
  Version : 0.3.2
  Upstream Author : Artur Maciag 
* URL : https://github.com/p1c2u/jsonschema-path
* License : Apache-2.0
  Programming Lang: Python
  Description : Python module for object-oriented JSONSchema
 This module provides a class SchemaPath to turn JSON Schema into
 path-like structures, allowing one to traverse them in a similar way to
 using pathlib.

This package is a (recursive) dependency of the new version of
jupyter-notebook (including its testsuite and docs).

It will be team-maintained within the Debian Python Team.  The Debian
packaging is on salsa at
   https://salsa.debian.org/python-team/packages/jsonschema-path



Bug#1073490: ITP: aioitertools -- Python itertools, builtins and more for AsyncIO

2024-06-16 Thread Julian Gilbey
Package: wnpp
Severity: wishlist
Owner: Julian Gilbey 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@lists.debian.org

* Package name: aioitertools
  Version : 0.11.0
  Upstream Author : Amethyst Reese
* URL : https://github.com/omnilib/aioitertools
* License : Expat
  Programming Lang: Python
  Description : Python itertools, builtins and more for AsyncIO
 This Python module shadows the standard library whenever possible to
 provide asynchronous versions of itertools, builtins and other familiar
 functions.  It's fully compatible with standard iterators and async
 iterators alike, providing a single unified, familiar interface for
 interacting with iterable objects.

This package is a (recursive) dependency of the new version of
jupyter-notebook (including its testsuite and docs).

It will be team-maintained within the Debian Python Team.  The Debian
packaging is on salsa at
   https://salsa.debian.org/python-team/packages/aioitertools



Re: newer dask release

2024-06-16 Thread Julian Gilbey
On Sat, Jun 15, 2024 at 10:50:17AM +0200, Étienne Mollier wrote:
> > Historically it was pretty important to dask and dask.distributed to be
> > released together, upstream intends them to be matching versions, but I
> > didn't know how to set the the dependnecy version strings to require
> > that.
> 
> It makes sense.  The construction pretty much looks like the
> latter is supposed to be a Python submodule of the former.

You could do something like this in the dask.distributed source
package:

Source: dask.distributed
Build-Depends: python3-dask (>> 2024.5.2), python3-dask (<< 2024.5.3~)

and in the binary python3-dask.distributed package similarly:

Depends: python3-dask (>> 2024.5.2), python3-dask (<< 2024.5.3~)

This forces the dask version to match the dask.distributed version.  I
don't know how tight the version numbers need to be, but this works to
keep the packages in step with each other, and will prevent an updated
dask package from migrating if the dask.distributed package has not
been updated in parallel.  Probably more effective than adding
something to README.source (though that will certainly help a bit).

Best wishes,

   Julian



Re: Bug#1063957: python-pytest-lazy-fixture: autopkgtest regression with pytest 8

2024-05-29 Thread Julian Gilbey
On Tue, May 28, 2024 at 06:13:59PM +0300, Ileana Dumitrescu wrote:
> [...]
> > python-limits:
> > Maintainer: Debian Python Team 
> >Last upload: Ileana Dumitrescu 
> >(signed by Jeroen Ploemen ) on 19 Oct 2023;
> >upstream is still using pytest-lazy-fixture
> 
> I have updated python-limits in salsa, so it should be ready for someone
> else to look over those changes and upload to unstable.

Thanks Ileana!  I see that Alexandre has now done this - thanks
Alexandre!

Best wishes,

   Julian



Re: Bug#1063957: python-pytest-lazy-fixture: autopkgtest regression with pytest 8

2024-05-19 Thread Julian Gilbey
(Trimming To/Cc list to debian-python and the maintainers involved)

Ileana - this email relates to python-limits, for which you made the
  last change
Sandro - this email relates to your package prettytable

On Tue, May 14, 2024 at 08:47:24AM +0200, Alexandre Detiste wrote:
> [...]
> I made a mistake in my attempt too..., here's the real list:
> 
> 
> Package: prettytable
> 
> Maintainer: Debian Python Team 
> Package: python-limits

Alexandre has kindly fixed some more of these packages, so there are
only two packages still (build-)depending on
python3-pytest-lazy-fixture:

python-limits:
Maintainer: Debian Python Team 
  Last upload: Ileana Dumitrescu 
  (signed by Jeroen Ploemen ) on 19 Oct 2023;
  upstream is still using pytest-lazy-fixture

prettytable:
Maintainer: Sandro Tosi 
  Last upload: 2024-03-02 (version 3.6.0-2): build failed because it
  depends on python3-lazy-fixture (which crashes with pytest 8)

Ileana - would you be able to look at python-limits?
Sandro - would you be able to look at prettytable?

Best wishes,

   Julian



Re: Bug#1063957: python-pytest-lazy-fixture: autopkgtest regression with pytest 8

2024-05-19 Thread Julian Gilbey
On Thu, May 16, 2024 at 06:55:50AM +0200, Antonio Valentino wrote:
> Dear Alexandre
> [...]
> > 
> > I made a mistake in my attempt too..., here's the real list:
> > 
> > Maintainer: Sandro Tosi 
> > Package: prettytable
> > 
> > Maintainer: Debian GIS Project
> >  -> CC'ing Antonio
> > Package: pycoast
> > Package: pyresample
> 
> 
> Thanks a lot.
> Yesterday I have uploaded the new version of pycoast and pyresample

Thanks Antonio!

Best wishes,

   Julian



Re: Bug#1063957: python-pytest-lazy-fixture: autopkgtest regression with pytest 8

2024-05-13 Thread Julian Gilbey
On Mon, May 13, 2024 at 11:07:54PM +0200, Alexandre Detiste wrote:
> Le lun. 13 mai 2024 à 22:59, Scott Kitterman  a écrit :
> > >I suggest that we soon ask ftpmaster to drop pytest-lazy-fixture from
> > >Debian unstable.
> >
> > Please transition all the rdepends  first.  Asking before that's done just 
> > creates more work for everyone.
> >
> > Scott K
> 
> It looks like for this one package it's already clear.
> 
> @Julian: here it looks you forgot to check build-depends:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067200

Oh, gosh, I thought I had done so (this is cython3-legacy), but I
clearly made a serious mistake in my attempt!

> I don't know what's the best way to check this, I use this template hereunder

Thanks Alexandre!

> #!/bin/sh
> Sources=/var/lib/apt/lists/ftp.*.debian.org_debian_dists_unstable_*_source_Sources
> Packages=/var/lib/apt/lists/ftp.*.debian.org_debian_dists_unstable_*_binary-amd64_Packages
> 
> ben query '.build-depends ~ "python3-lazy-fixture"' $Sources -s
> Package,Maintainer
> ben query '.build-depends-indep ~ "python3-lazy-fixture"' $Sources -s
> Package,Maintainer
> ben query '.depends ~ "python3-lazy-fixture"' $Packages -s Package,Maintaine

As you say, though, in this case, pytest-lazy-fixture itself has an
unfixable RC bug, so all of the rdepends need to be fixed (and by
"soon", I was thinking "once all these packages no longer depend on
it, but I should have said that explicitly ;-)

Best wishes,

   Julian



Advice about pydevd and debugpy

2024-05-13 Thread Julian Gilbey
Hi!

Background:

debugpy vendors pydevd (which in turn vendors an old version of
bytecode).

Until version 1.8.0 of debugpy (currently in testing), the vendored
copy of pydevd was (almost) identical to the separately published
pydevd, so I had replaced the vendored version of pydevd with the
Debian-packaged version.

pydevd now has an FTBFS, so needs fixing or updating.

But now I've found that the version of pydevd published separately
(now bumped from version 2.10.0 to 3.0.x) has started diverging fairly
significantly from the vendored version in debugpy (as it moved from
version 1.8.0 to 1.8.1): both are being modified, but along different
paths.  Trying to use pydevd 3.0.3 with debugpy 1.8.1 leads to
multiple test failures.

My thought is that at this point, seeing that these two packages are
now diverging sufficiently that tests break, that for debugpy, I
should stop trying to use a separately-packaged version of pydevd and
instead switch to using the vendored version shipped with debugpy.

If we do this, then at some point (probably after trixie, if nothing
changes with the forked debugpy - pydevd relationship), I will suggest
that we remove the pydevd package from Debian, as debugpy is the only
package that depends on it, and I doubt that anyone else is using
pydevd directly.

(A separate issue is that the chances are that the pydevd tests that
have started failing with the separately packaged pydevd will fail
with the vendored version in debugpy as well, but they are not being
run in the upstream test suite, and I'm not sure they would be able to
run in this vendored environment anyway.)

Does anyone have any comments on my plan?

Best wishes,

   Julian



Re: Bug#1063957: python-pytest-lazy-fixture: autopkgtest regression with pytest 8

2024-05-13 Thread Julian Gilbey
On Wed, Apr 03, 2024 at 03:58:21PM -0400, Jeremy Bícha wrote:
> I noticed one package affected by this issue, prettytable, has
> switched to a fork, pytest-lazy-fixtures (note the s at the end of the
> name).
> 
> Would someone like to package this for Debian to fix several packages
> failing to build?
> 
> https://github.com/dev-petrov/pytest-lazy-fixtures
> 
> Thank you,
> Jeremy Bícha

Dear all affected by pytest-lazy-fixture: pytest-lazy-fixtures is now
in testing and unstable; in many cases, it can be used as a drop-in
replacement for pytest-lazy-fixture (though not all, it turns out).

I suggest that we soon ask ftpmaster to drop pytest-lazy-fixture from
Debian unstable.

Best wishes,

   Julian



Bug#1070452: ITP: pytest-lazy-fixtures -- pytest plugin to use fixtures in @pytest.mark.parametrize

2024-05-05 Thread Julian Gilbey
Package: wnpp
Severity: wishlist
Owner: Julian Gilbey 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@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#1068557: ITP: sphinxcontrib-openapi -- Sphinx extension to generate API docs from OpenAPI spec

2024-04-07 Thread Julian Gilbey
Package: wnpp
Severity: wishlist
Owner: Julian Gilbey 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@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

2024-04-07 Thread Julian Gilbey
Package: wnpp
Severity: wishlist
Owner: Julian Gilbey 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@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#1068555: ITP: rfc3986-validator -- RFC 3986 validator (Python library)

2024-04-07 Thread Julian Gilbey
Package: wnpp
Severity: wishlist
Owner: Julian Gilbey 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@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#1068554: ITP: rfc3339-validator -- RFC 3339 validator (Python library)

2024-04-07 Thread Julian Gilbey
Package: wnpp
Severity: wishlist
Owner: Julian Gilbey 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@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#1068553: ITP: python-overrides -- Python decorator to verify that expected overrides are maintained

2024-04-07 Thread Julian Gilbey
Package: wnpp
Severity: wishlist
Owner: Julian Gilbey 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@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)

2024-04-07 Thread Julian Gilbey
Package: wnpp
Severity: wishlist
Owner: Julian Gilbey 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@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#1068550: ITP: pytest-mypy-testing -- Plugin to test mypy output with pytest

2024-04-07 Thread Julian Gilbey
Package: wnpp
Severity: wishlist
Owner: Julian Gilbey 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@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#1068551: ITP: python-fqdn -- Python library to validate fully qualified domain names (FQDNs)

2024-04-07 Thread Julian Gilbey
Package: wnpp
Severity: wishlist
Owner: Julian Gilbey 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@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#1068549: ITP: pytest-console-scripts -- Pytest plugin for running Python scripts from within tests

2024-04-07 Thread Julian Gilbey
Package: wnpp
Severity: wishlist
Owner: Julian Gilbey 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@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#1068547: ITP: jupyter-server-terminals -- Jupyter server extension providing support for terminals

2024-04-07 Thread Julian Gilbey
Package: wnpp
Severity: wishlist
Owner: Julian Gilbey 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@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#1068548: ITP: picobox -- Opinionated Python dependency injection framework

2024-04-07 Thread Julian Gilbey
Package: wnpp
Severity: wishlist
Owner: Julian Gilbey 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@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#1068546: ITP: async-asgi-testclient -- Python async client for testing ASGI web applications

2024-04-07 Thread Julian Gilbey
Package: wnpp
Severity: wishlist
Owner: Julian Gilbey 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@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



Re: morph's abandoned packages (list)

2024-03-31 Thread Julian Gilbey
On Sun, Mar 31, 2024 at 02:16:39PM +0200, tho...@goirand.fr wrote:
> The bug is about the --pristine-tar option of bgp...
>>   It turns out that doing pristine-tar by hand often gives different
>>   results, as I discovered:
>>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065445

Yes, indeed; the original poster was talking about using pristine-tar
by hand rather than using the --pristine-tar option of gbp.

Best wishes,

   Julian



Re: morph's abandoned packages (list)

2024-03-31 Thread Julian Gilbey
On Sat, Mar 30, 2024 at 10:21:06PM +0100, Thomas Goirand wrote:
> [...]
> > [0]: https://wiki.debian.org/Python/GitPackaging#Creating_a_new_package
> > [1]: https://wiki.debian.org/Python/GitPackaging#New_upstream_release
> I would not do this way, but use gbp import-orig instead. I'm not sure why
> the wiki recommends, IMO wrongly, to do things by hand. Indeed, all of this:

It turns out that doing pristine-tar by hand often gives different
results, as I discovered:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065445

So I don't know what best to recommend, personally.  Anyway, once this
bug is fixed, definitely using gbp import-orig is the way to go (and
probably even before it is).

Best wishes,

   Julian



Re: Seeking a small group to package Apache Arrow (was: Bug#970021: RFP: apache-arrow -- cross-language development platform for in-memory analytics)

2024-03-31 Thread Julian Gilbey
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



Re: Seeking a small group to package Apache Arrow (was: Bug#970021: RFP: apache-arrow -- cross-language development platform for in-memory analytics)

2024-03-30 Thread Julian Gilbey
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



Re: Pytest 8.x bug? "Permission denied: '/tmp/systemd-private-...-systemd-logind.service-.../__init__.py'"

2024-03-27 Thread Julian Gilbey
On Wed, Mar 27, 2024 at 11:36:55AM +0100, Timo Röhling wrote:
> Hi,
> 
> Am 27. März 2024 10:59:46 MEZ schrieb Julian Gilbey :
> >I'm stymied by a pytest-related bug.  I thought it was a bug in a
> >particular pytest plugin (pytest-order), but it's now shown up in
> >another pytest plugin as well, so I wonder if either there's a bug in
> >pytest 8.x or something subtle has changed that requires a
> >modification to the plugins.  I couldn't see anything obvious on the
> >pytest changelog page, and the error message itself is mysterious to
> >me.  The bug does not show with pytest 7.4.4, so it is certainly
> >related to the new pytest version.
> I wasn't able to pinpoint the cause yet, but I noticed that the failing 
> sessions have "rootdir: /tmp" instead of the usual 
> /tmp/autopkgtest-lxc.*/downtmp/autopkgtest_tmp/build

Ah, I think you've hit the nail on the head!!

https://github.com/pytest-dev/pytest/issues/11781

And then pytest looks for any __init__.py file it can find, including
in unreadable directories...

Unfortunately, changing the argument from str(tmpdir) to
f"--rootdir={tmpdir}" caused my computer to crash (CPU usage went
through the roof until the computer became unresponsive) - clearly
there's something not quite right here yet!!

Best wishes,

   Julian



Re: Pytest 8.x bug? "Permission denied: '/tmp/systemd-private-...-systemd-logind.service-.../__init__.py'"

2024-03-27 Thread Julian Gilbey
On Wed, Mar 27, 2024 at 11:36:55AM +0100, Timo Röhling wrote:
> Hi,
> 
> Am 27. März 2024 10:59:46 MEZ schrieb Julian Gilbey :
> >I'm stymied by a pytest-related bug.  I thought it was a bug in a
> >particular pytest plugin (pytest-order), but it's now shown up in
> >another pytest plugin as well, so I wonder if either there's a bug in
> >pytest 8.x or something subtle has changed that requires a
> >modification to the plugins.  I couldn't see anything obvious on the
> >pytest changelog page, and the error message itself is mysterious to
> >me.  The bug does not show with pytest 7.4.4, so it is certainly
> >related to the new pytest version.
> I wasn't able to pinpoint the cause yet, but I noticed that the failing 
> sessions have "rootdir: /tmp" instead of the usual 
> /tmp/autopkgtest-lxc.*/downtmp/autopkgtest_tmp/build
> 
> 
> Cheers
> Timo

Hi Timo,

Oh, that is interesting!  Good spot, thank you!  I wonder whether
tmpdir is creating a weird location?  BTW, this problem appears when
running autopkgtest under lxc.  In my other package, the tests passed
when running under sbuild but not with autopkgtest under lxc, which
suggests that there's something weird about the lxc setup.

Best wishes,

   Julian



Pytest 8.x bug? "Permission denied: '/tmp/systemd-private-...-systemd-logind.service-.../__init__.py'"

2024-03-27 Thread Julian Gilbey
I'm stymied by a pytest-related bug.  I thought it was a bug in a
particular pytest plugin (pytest-order), but it's now shown up in
another pytest plugin as well, so I wonder if either there's a bug in
pytest 8.x or something subtle has changed that requires a
modification to the plugins.  I couldn't see anything obvious on the
pytest changelog page, and the error message itself is mysterious to
me.  The bug does not show with pytest 7.4.4, so it is certainly
related to the new pytest version.

It occurs when running a script from within a test, and the error is
when collecting the tests.  Here is an example, taking from the report
I filed at https://github.com/pytest-dev/pytest-order/issues/110

__ ERROR collecting . __
/usr/lib/python3/dist-packages/pluggy/_hooks.py:501: in __call__
return self._hookexec(self.name, self._hookimpls.copy(), kwargs, 
firstresult)
/usr/lib/python3/dist-packages/pluggy/_manager.py:119: in _hookexec
return self._inner_hookexec(hook_name, methods, kwargs, firstresult)
/usr/lib/python3/dist-packages/_pytest/python.py:211: in 
pytest_collect_directory
if pkginit.is_file():
/usr/lib/python3.12/pathlib.py:894: in is_file
return S_ISREG(self.stat().st_mode)
/usr/lib/python3.12/pathlib.py:842: in stat
return os.stat(self, follow_symlinks=follow_symlinks)
E   PermissionError: [Errno 13] Permission denied: 
'/tmp/systemd-private-2dd08cf217854d6285343c302b696375-systemd-logind.service-qOgrXp/__init__.py'


(That page also has the full autopkgtest log.)  I have no idea why it
is looking at this private systemd directory; it's running under
autopkgtest so HOME should be sane.

Any ideas would be much appreciated, as I would be able to use it to
fix the tests on the other plugin I'm working on as well.

Best wishes,

   Julian



Seeking a small group to package Apache Arrow (was: Bug#970021: RFP: apache-arrow -- cross-language development platform for in-memory analytics)

2024-03-25 Thread Julian Gilbey
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



Changing hatchling shared-data installation directory: /usr/etc -> /etc

2024-03-24 Thread Julian Gilbey
I'm trying to package jupyter-server-terminals, and have hit a snag.
The pyproject.toml file includes the lines:

[tool.hatch.build.targets.wheel.shared-data]
"jupyter-config" = "etc/jupyter/jupyter_server_config.d"

but the resulting file is installed at
/usr/etc/jupyter/jupyter_server_config.d

Now, I can obviously move this to its correct location in debian/rules
(either directly or using an appropriate dh-recognised file in
debian/), but I wonder whether there is a "better" way to do this.  Is
there a way to tell hatchling that shared-data should be installed in
/ rather than in /usr?  Or if I tell hatchling to use / as the base
directory, would that mess everything else up?

I couldn't figure it out from a quick skim of the hatchling docs, so
any thoughts or pointers would be welcome.

Thanks!

   Julian



Bug#1067248: ITP: pytest-jupyter -- Pytest plugins for Jupyter libraries and extensions

2024-03-20 Thread Julian Gilbey
Package: wnpp
Severity: wishlist
Owner: Julian Gilbey 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@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#1067200: RM: cython-legacy -- ROM; Legacy transition package no longer needed

2024-03-19 Thread Julian Gilbey
Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: debian-python@lists.debian.org

cython-legacy was introduced as a transitional measure until cython
version 3.x was supported by all source packages using cython.

There are now no source packages in unstable or testing (main)
depending on cython3-legacy and no binary packages either, so this
legacy package can be removed.  (It also has an RC bug against it, and
doesn't really work with Python 3.12.)

Best wishes,

   Julian



Re: Salsa: Setup tokens

2024-03-19 Thread Julian Gilbey
Hi Christian,

On Tue, Mar 19, 2024 at 01:29:55PM +0100, Joost van Baal-Ilić wrote:
> Hi Christian,
> 
> Thanks for working on the documentation!
> 
> Op Tue, Mar 19, 2024 at 10:54:43AM + schreef c.bu...@posteo.jp:
> > Hello,
> > [...]
> 
> I can answer some of your questions, but not all of them.  What I usually do:
> 
> Get a personal access token "somesecret" from the salsa web interface.  Then:
> 
>  $ touch ~/.salsa-token
>  $ chmod og-r ~/.salsa-token
>  $ echo somesecret > ~/.salsa-token
>  $ SALSA_TOKEN=`cat ~/.salsa-token`
> 
> For some actions, the salsa(1) tool (and/or gitlab on salsa.d.o) seems to need
> such a token.  An SSH key is not always enough.
> 
> HTH, Bye,
> 
> Joost

Might also be worth taking a look at
https://wiki.debian.org/Javascript/Tutorial
which has a whole discussion about using salsa and tokens.

Best wishes,

   Julian



Re: morph's abandoned packages (list)

2024-03-15 Thread Julian Gilbey
On Fri, Mar 15, 2024 at 10:04:42AM +, Jelmer Vernooij wrote:
> On Thu, Mar 14, 2024 at 06:20:11AM +0000, Julian Gilbey wrote:
> > [...]
> Thanks for collecting the list of packages. I'm planning to adopt these:
> 
> > #1065327 O: python-levenshtein -- extension for computing string 
> > similarities and edit distances
> > #1065223 O: pysimplesoap -- simple and lightweight SOAP Library

Hi Jelmer,

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.)

Best wishes,

   Julian



morph's abandoned packages (list)

2024-03-13 Thread Julian Gilbey
Dear all (and Bcc-ing the RM bugs),

For information, here is a list of packages that morph has either
requested removal of or orphaned.  If you are interested in taking one
or more of them on, that would be great!

Removal requested:

#1066146 RM: flask-basicauth -- ROM; RC buggy, dead upstream, leaf package
#1065141 RM: gmplot -- ROM; leaf package
#1064947 RM: nb2plots -- ROM; leaf package
#1065200 RM: overpass -- ROM; leaf package
#1065199 RM: pprintpp -- ROM; leaf package
#1065045 RM: pyannotate -- ROM; leaf package
#1065201 RM: python-overpy -- ROM; leaf package
#1065202 RM: python-ppmd -- ROM; leaf package
#1064946 RM: sphinx-a4doc -- ROM; leaf package

Recently-orphaned packages (removing those in wnpp which have been
retitled "ITA") sorted alphabetically; these could, of course, be
brought into team maintenance.

#1065235 O: basemap -- matplotlib toolkit to plot on map projections
#1065243 O: colorspacious -- library for doing colorspace conversions
#1065151 O: commonmark -- Python parser for the CommonMark Markdown spec
#1065246 O: contourpy -- Python library for calculating contours of 2D 
quadrilateral grids
#1065248 O: cppy -- C++ headers for (Python) C extension development
#1065139 O: dot2tex -- Graphviz to LaTeX converter
#1065140 O: fastkml -- fast KML processing
#1065142 O: html5lib -- HTML parser/tokenizer based on the WHATWG HTML5 
specification
#1065244 O: kiwisolver -- fast implementation of the Cassowary constraint 
solver
#1065238 O: lazy-object-proxy -- Python 3 fast and thorough lazy object 
proxy
#1065037 O: m2crypto -- Python wrapper for the OpenSSL library
#1065325 O: matplotlib -- Python based plotting system
#1065143 O: mkautodoc -- AutoDoc for MarkDown
#1065042 O: mpl-sphinx-theme -- documentation for the mpl-sphinx-theme 
Python library
#1065220 O: mpmath -- library for arbitrary-precision floating-point 
arithmetic
#1065224 O: mysql-connector-python -- pure Python implementation of MySQL 
Client/Server protocol
#1065198 O: networkx -- tool to create, manipulate and study complex 
networks
#1065329 O: numpy -- Fast array facility to the Python 3 language
#1065221 O: py7zr -- pure Python 7-zip library
#1065222 O: pychm -- Python binding for CHMLIB
#1065231 O: pydot -- Python interface to Graphviz's dot
#1065152 O: pygeoif -- basic implementation of the __geo_interface__
#1065036 O: pyopenssl -- Python wrapper around the OpenSSL library
#1065149 O: pyproject-metadata -- Dataclass for PEP 621 metadata with 
support for [core metadata] generation
#1065223 O: pysimplesoap -- simple and lightweight SOAP Library
#1064977 O: python-cryptography-vectors -- Test vectors for 
python-cryptography
#1065327 O: python-levenshtein -- extension for computing string 
similarities and edit distances
#1065025 O: sphinx-book-theme -- clean book theme for scientific 
explanations and documentation with Sphinx
#1065026 O: sphinx-bootstrap-theme -- bootstrap theme for Sphinx
#1065030 O: sphinxcontrib-log-cabinet -- Organize changelog directives in 
Sphinx docs
#1065027 O: sphinx-copybutton -- sphinx extension to add a "copy" button to 
code blocks
#1065028 O: sphinx-gallery -- extension that builds an HTML gallery of 
examples from Python scripts
#1065029 O: sphinx-panels -- documentation for the sphinx-panels Python 
library
#1065043 O: sphinxtesters -- utilities for testing Sphinx extensions
#1064948 O: texext -- sphinx extensions for working with LaTeX math

There's also an old ITP that was closed:

#1015231 ITP: sphinx-theme-builder -- tool for authoring Sphinx themes with 
a simple (opinionated) workflow

Best wishes,

   Julian




Re: "Fatal Python error: Aborted" errors for Python/Qt packages

2024-03-12 Thread Julian Gilbey
On Tue, Mar 12, 2024 at 07:55:55AM +0100, Roland Mas wrote:
> Hi Julian, Ghislain, list,
> 
> I'm working on various Qt-related Python packages, and I'm seeing strange
> errors when building in cowbuilder chroots (with git-buildpackage). They
> don't seem to happen when building out-of-chroot. So far I managed to track
> them down to qtpy, but I'm stumped as to the why and how to fix. For
> instance, when building from commit
> b360a9defbb470fe6ab1793371d16487e52b548b, I get the following output during
> the testsuite:

Hi Roland,

I wonder whether it's related to the current t64 library changes in
unstable?  These are causing all sorts of issues during the transition
period.  Do the packages build OK in a testing chroot?

Best wishes,

   Julian



Re: Suggesting change in DPT Policy

2024-03-09 Thread Julian Gilbey
On Sat, Mar 09, 2024 at 06:46:52PM +0100, Anton Gladky wrote:
> Same for me. Thanks for proposal. +1
> Anton
> Am Sa., 9. März 2024 um 17:51 Uhr schrieb Nilesh Patra :
> 
>   I am late to the party but I agree with the policy change.

Following on from some earlier discussions, I've been thinking about
the relationship between the DPT (presumably a group of developers who
work together) and salsa (could there be packages in the
python-team/packages area which are not team maintained?).  I reread
much of the policy at
https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst
and discovered something quite strange.  The introduction begins:

---
Introduction:

The Debian Python Team (DPT) aims to improve the Python packages
situation in Debian, by packaging available modules and applications
that may be useful and providing a central location for packages
maintained by a team, hence improving responsiveness, integration, and
standardization.

The DPT is hosted at salsa.debian.org, the Debian GitLab
installation. We currently have a Git repository and a mailing list
whose email address can be used in the Maintainer or Uploaders fields
on co-maintained packages.
---

If the DPT is a team (a group of maintainers/developers/helpful
others), what does "The DPT is hosted at salsa" mean - how can a
"team" be hosted?  (And in the first paragraph, "maintained by a team"
seems a little strange too.)

Perhaps something like the following would be better (shifting the
focus from the tools to the people), and would also separate concerns
more clearly:

---
Introduction:

The Debian Python Team (DPT) is a group of maintainers who are jointly
responsible for a large number of Python packages in Debian.  They
package and support available Python modules and applications that may
be useful.

By using a central location on salsa.debian.org, the Debian GitLab
instance, for these team-maintained packages, the DPT are able to
improve responsiveness, integration, and standardization.
---

Then the details of how to mark a package as being team-maintained can
be left to the Maintainership section.

We could then include a statement along the lines of the following
(though I'm not sure where would be best):

---
Python module packages which are not team-maintained by the DPT can
also be stored in the python-team/packages namespace on salsa in order
to benefit from the integration and standardization tools such as
Janitor.  Manual changes to these packages by someone other than the
package's maintainer should be proposed via salsa merge requests or
comments in the BTS (or using NMUs if appropriate) as for any other
individually-maintained package.
---

It would be good to say something about Uploaders in the
Maintainership section.  Perhaps something like this:

---
A package maintained within the team must have the name of the team in
the Maintainer field:

Maintainer: Debian Python Team 

This enables the team to have an overview of its packages on the
DDPO_website.

If a particular developer wishes to take primary responsibility for a
package, they should put their name in the Uploaders field.  [*** What
does this mean though?  Maybe something like: In this case, any DPT
member is still welcome to make changes to the package, though it is
polite to contact the developer(s) named in the Uploaders field
first. ***]

If there are complications in the packaging of the module, for
example, if certain modules are interdependent and need to be updated
together, this should be documented in debian/README.source [*** or
somewhere else ***]
---

Best wishes,

   Julian



Please delete two empty salsa repositories

2024-03-02 Thread Julian Gilbey
Hello,

Please could someone with the required permissions delete the
following two empty salsa repositories; due to an upstream
reorganisation of the package, they will no longer be needed, and will
instead be part of the rapidfuzz package:

https://salsa.debian.org/python-team/packages/jarowinkler
https://salsa.debian.org/python-team/packages/rapidfuzz-capi

Thanks,

   Julian



Re: Suggesting change in DPT policy

2024-02-29 Thread Julian Gilbey
Hi Jeroen,

On Thu, Feb 29, 2024 at 08:48:33PM +0100, Jeroen Ploemen wrote:
> On Tue, 27 Feb 2024 18:32:54 +
> Scott Kitterman  wrote:
> 
> > While I do take advantage of this for a few packages, I don't
> > personally care much either way.  I suspect that packages will be
> > removed from team maintenance as a result though and I think that's
> > a bad idea.
> > 
> > I'd prefer the current approach over people removing packages from
> > the team, so I think it's important that anyone who feels strongly
> > enough about this to do so, speak up.
> 
> For me, the weaker collaboration option that the DPT provides is key
> to putting my packages under a team umbrella.
> 
> As I find myself completely AFK for up to a month at a time for both
> work and private reasons, having a knowledgeable bunch of developers
> around with full access to my packages (VCS and CI included) is a
> definite plus, if only out of a strong sense of responsibility. The
> same goes for benefiting from the shared knowledge of the team,
> including routine fixes and similar minor changes being rolled out
> across all packages in the team.

These are really interesting points.  Under the proposed system, I
presume that one could leave "privately maintained" packages within
the python-team area of salsa and still benefit from these automatic
changes without giving automatic permission to other developers to
make manual changes.  Being part of the team is a relationship between
developers; it surely doesn't say anything about a specific package's
maintenance, just as one can ask questions on debian-devel without
saying "anyone can do anything to my packages without asking me".

> That said, I'm very careful not to spend more time on volunteer
> efforts than I can afford to, and not looking to offload the full
> maintenance of any of my packages. Upstream involvement often gives
> me advance knowledge of upcoming releases, their compatibility issues
> and other quirks, which in turn helps avoid problems on the Debian
> end. I do not share the optimism that documenting such details
> somewhere in individual packages - as suggested elsewhere in this
> thread - would be effective to avoid trouble; more so considering
> that the inability to stick to a single, concise, and rather clear
> team policy is ultimately what triggered this whole discussion in the
> first place.

I don't think it's a binary choice: "offload the full maintenance" of
a package versus "keep the full maintenance".  As far as I understand
it, a package maintained by the team will typically have a main person
who does the day-to-day work on it (few people have the time to start
doing serious work on lots of other packages), but anyone on the team
could work on it.  In the cases mentioned, there are RC bugs in
packages which have not been addressed in a timely fashion and are
holding up transitions or similar.  In some of "my" packages, other
developers on the team have uploaded more regular updates (thanks!).
In most cases, updates are routine and I'm very appreciative of it.

While documenting quirks might not fully avoid trouble, it's much
better than not documenting them.  After all, this is detailed
knowledge of a package or collection of packages that has been gained
over time, and in addition to helping anyone stepping in to do a team
upload, documenting it will help whoever ends up taking over the
package one day (as well as helping the maintainer themselves!).

The question for your quirky packages then becomes: what does the
current team maintenance position offer that having the package solely
maintained by yourself would not provide?  I can see very little;
anyone wanting to help with a package outside of the team can still
offer to do an NMU (and push their changes to salsa).

> As for the inclusion of codes of conduct or similar wording,
> documenting common sense just feels unnecessary. While being on the
> receiving end of a compliment for bug-squashing work is certainly
> nice, the lack thereof isn't a measure of disrespect. I cannot recall
> any discussion on the team's IRC channel or mailing list crossing
> that line.

As far as I understand, this thread was started not because Andreas
did not receive a compliment, but because he received quite unpleasant
emails "telling him off" for doing it.  These were not public
communications, so you would not have seen them.  I don't think anyone
is suggesting that every team upload requires a compliment (though
such things are, of course, nice and appreciated!).

Best wishes,

   Julian



Re: Suggesting change in DPT policy

2024-02-28 Thread Julian Gilbey
On Tue, Feb 27, 2024 at 09:05:44AM +0100, Andreas Tille wrote:
> Hi,
> 
> [...]

+1 from me, too.  I had completely forgotten this paragraph in the
Python policy and it doesn't make that much sense.  I personally
generally do send an email to anyone in the "Maintainers" field or the
last uploader just as a matter of courtesy before working on
something, and then wait for a day before doing anything; for all I
know, they may already be working on a patch, especially if it's a
very new bug.  But if the model of team maintainership is made much
stronger and clearer, though I would still encourage sending an email
to the "main maintainer" for anything non-trivial, even if just to let
them know the situation.

In response to other comments, I suggest that those maintainers who do
not wish other team members to help work on their packages under this
new approach should just remove DPT from the Maintainer and Uploader
fields, and regard any offers of help as an NMU or merge request.

One tweak to Andreas's patch:

> diff --git a/policy.rst b/policy.rst
> index 27bf6f3..7185d6d 100644
> --- a/policy.rst
> +++ b/policy.rst
> @@ -48,20 +48,14 @@ Maintainership
>  ==
>  
>  A package maintained within the team should have the name of the team either

this should be:

- A package maintained within the team should have the name of the team either
+ A package maintained within the team should have the name of the team

> -in the ``Maintainer`` field or in the ``Uploaders`` field.
> +in the ``Maintainer``.

Best wishes,

   Julian



Re: Breaking changes in pytest 8

2024-01-25 Thread Julian Gilbey
Hi Timo,

And the transition is now complete :-)

Best wishes,

   Julian

On Tue, Jan 09, 2024 at 05:45:04PM +, Julian Gilbey wrote:
> Hi Timo,
> 
> Please can we hold back on uploading pytest 8 to unstable until the
> current Python 3.12 transition is complete?  It is entirely possible
> that several of the packages that currently break with pytest 8
> already have newer upstream versions that address these issues, but
> it's probably not wise to mix that in with the current transition.
> 
> Best wishes,
> 
>Julian
> 
> On Mon, Jan 08, 2024 at 11:32:29PM +0100, Timo Röhling wrote:
> > Hi,
> > 
> > I recently uploaded the pre-release pytest 8.0.0~rc1 to experimental as an
> > early warning for the breaking changes which typically happen on major
> > version bumps.
> > 
> > I've attached a dd-list of packages which exhibit autopkgtest regressions
> > [1], with the intent of MBF'ing (with separate announcement) once pytest 8
> > is released.
> > 
> > Typically, packages will fail if they
> > - have deprecation warnings of type PytestRemovedIn8Warning, or
> > - assume a particular pytest stdout/stderr output which might have
> > changed, or
> > - rely on the precise order in which pytest collects tests,   especially the
> > behavior of the pytest.Package collector.
> > 
> > Please refer to the upstream changelog [2] for a complete list of breaking
> > changes.
> > 
> > 
> > Cheers
> > Timo
> > 
> > [1] https://qa.debian.org/excuses.php?experimental=1&package=pytest
> > [2] https://docs.pytest.org/en/latest/changelog.html



Re: Bug#1043240: transition: pandas 1.5 -> 2.1

2024-01-25 Thread Julian Gilbey
On Fri, Jan 26, 2024 at 08:43:03AM +0200, Graham Inggs wrote:
> Hi
> 
> On Tue, 23 Jan 2024 at 14:38, Julian Gilbey  wrote:
> > We're nearly there (the transition page says it's 99% done), and when
> > this transition is complete, then python3-defaults 3.11.6+ will be
> > able to migrate to testing.
> 
> python3-defaults/3.11.6-1 with Python 3.12 as a supported version is
> now in testing [1].

Wonderful news!  Congratulations to everyone who helped to make this
happen!

Best wishes,

   Julian



Re: Bug#1043240: transition: pandas 1.5 -> 2.1

2024-01-23 Thread Julian Gilbey
On Mon, Jan 22, 2024 at 08:50:55PM +, Rebecca N. Palmer wrote:
> On 22/01/2024 11:51, Julian Gilbey wrote:
> > Please could we wait until the "Python 3.12 is a supported version"
> > transition is completed?
> 
> How are you defining that?  python3-defaults 3.11.6+ in testing?  (I was
> previously told 3.12-supporting pandas and numpy in testing, which has
> happened.  I don't think any of these 25 packages are on
> https://qa.debian.org/excuses.php?package=python3-defaults , but I haven't
> checked carefully, and at least influxdb-python and tqdm do have what I
> suspect are Python 3.12 related issues.)

https://release.debian.org/transitions/html/python3.12-add.html

We're nearly there (the transition page says it's 99% done), and when
this transition is complete, then python3-defaults 3.11.6+ will be
able to migrate to testing.

I don't fully understand the problem with transitions, but there was a
request to hold back with significant upgrades until a
python3.12-supporting python3-defaults has reached testing.

> > Adding another 25 or so RC bugs at this
> > point will just slow down that transition.
> 
> What exactly do you want not done until then?   Just not uploading pandas
> 2.x to unstable, or is it also a problem to have these bugs marked as RC in
> the BTS?  (In all 22 cases that are in testing at all, the bug is also
> present in the version in testing, so it being RC shouldn't block
> migration.)

Yes - please don't upload it to unstable yet.  Uploading to
experimental is fine.

> > (Unless pandas 1.5 is
> > preventing the transition, that is.)
> 
> It isn't.

Good!

   Julian



Re: Bug#1043240: transition: pandas 1.5 -> 2.1

2024-01-22 Thread Julian Gilbey
On Sun, Jan 21, 2024 at 03:29:21PM +, Rebecca N. Palmer wrote:
> Control: severity 1053943 1053939 1053942 1044053 1044056 serious
> Control: severity 1044074 1053946 1044078 1044079 1044077 serious
> Control: severity 1044071 1044067 1044068 1044055 1044060 serious
> Control: severity 1044072 1044073 1044064 1053945 1044054 serious
> Control: severity 1044076 1053940 1044057 1053944 1050144 serious
> 
> As previously discussed in this bug, I'd like to move pandas 2.x into
> unstable reasonably soon.  I'm aiming to get it in before the Ubuntu 24.04
> freeze (in about a month), but I am open to disagreement on whether this is
> a good idea.

Please could we wait until the "Python 3.12 is a supported version"
transition is completed?  Adding another 25 or so RC bugs at this
point will just slow down that transition.  (Unless pandas 1.5 is
preventing the transition, that is.)

Best wishes,

   Julian



Re: Breaking changes in pytest 8

2024-01-09 Thread Julian Gilbey
Hi Timo,

Please can we hold back on uploading pytest 8 to unstable until the
current Python 3.12 transition is complete?  It is entirely possible
that several of the packages that currently break with pytest 8
already have newer upstream versions that address these issues, but
it's probably not wise to mix that in with the current transition.

Best wishes,

   Julian

On Mon, Jan 08, 2024 at 11:32:29PM +0100, Timo Röhling wrote:
> Hi,
> 
> I recently uploaded the pre-release pytest 8.0.0~rc1 to experimental as an
> early warning for the breaking changes which typically happen on major
> version bumps.
> 
> I've attached a dd-list of packages which exhibit autopkgtest regressions
> [1], with the intent of MBF'ing (with separate announcement) once pytest 8
> is released.
> 
> Typically, packages will fail if they
> - have deprecation warnings of type PytestRemovedIn8Warning, or
> - assume a particular pytest stdout/stderr output which might have
> changed, or
> - rely on the precise order in which pytest collects tests,   especially the
> behavior of the pytest.Package collector.
> 
> Please refer to the upstream changelog [2] for a complete list of breaking
> changes.
> 
> 
> Cheers
> Timo
> 
> [1] https://qa.debian.org/excuses.php?experimental=1&package=pytest
> [2] https://docs.pytest.org/en/latest/changelog.html



Re: sphinx-build module not found in sbuild

2024-01-08 Thread Julian Gilbey
On Mon, Jan 08, 2024 at 01:22:54PM +0100, Jérémy Lal wrote:
> Hi,
> I'm stuck at this odd behavior:
> when I build a package in my current environment (debian/testing),
> sphinx-build ... works correctly.
> when building in sbuild, sphinx-build doesn't find current module:
> ModuleNotFoundError: No module named 'xxx'
> in docs/conf.py at
> from xxx import __version__
> I don't understand which other debian package is modifying that outcome.
> Any idea ?

Perhaps your local build is importing from a globally-installed
version of the package?  (For example, you're building version 1.3 of
python3-foo, but you already have version 1.2 of python3-foo
installed.)

Best wishes,

   Julian



Working on dask and dask.distributed update

2024-01-01 Thread Julian Gilbey
FYI: I'm most of the way through updating dask and dask.distributed to
fix their FTBFS bug reports.  I hope to upload either tomorrow or
Wednesday.  I haven't pushed anything to salsa yet.

Happy new year!

   Julian



Re: cython 3.x (for Python 3.12)

2023-12-12 Thread Julian Gilbey
On Sat, Nov 25, 2023 at 04:23:46PM +, Stefano Rivera wrote:
> As part of preparing for Python 3.12 in Debian, I've uploaded cython 3
> to experimental.
> [...]
> 
> So, that's 71 regressions with cython3. dd-list below. Please help us
> port to cython 3. If this isn't possible, Graham is preparing a
> cython-legacy package, to help the stragglers. But we're expecting that
> this won't have great Python 3.12 support...
> https://ftp-master.debian.org/new/cython-legacy_0.29.36-1~exp1.html

Here's an update on cython-legacy.  I just tried running autopkgtest
on cython-legacy with Python 3.12, and unfortunately it fails.  I
can't quite work out how many tests fail (I don't understand the
format of the test output), but there are 25 lines containing the
string "FAIL" in the output of autopkgtest with the latest version of
cython-legacy (0.29.36-2, uploaded today).

We could just skip these tests - some of them are probably harmless -
but they probably indicate incompatibilty (unsurprisingly) with Python
3.12, though some of these incompatibilties may be restricted to the
tests themselves rather than the underlying Cython 0.x code.

I'd be happy to try uploading a version with these tests skipped - I
just wanted to check here first what the thoughts on this are.  (Note
that it is much better to modify other packages to work with Cython
3.x!)

Best wishes,

   Julian



Re: cython 3.x (for Python 3.12)

2023-12-11 Thread Julian Gilbey
On Mon, Dec 11, 2023 at 08:06:41PM +0100, Matthias Klose wrote:
> > [...]
> > Excellent - I didn't know about that.  Are you OK for me to upload
> > versions of cython and cython-legacy which depend on this to fix the
> > Python 3.12 breakage?
> 
> not for cython, which won't need that soonish for 3.0.x.  and if you have to
> update the b-d to cython3-legacy, why not add the zombie-imp dependency as
> well manually for the few packages that need it?

The problem is not with other packages importing imp (which need to
be fixed in such a case), rather that pyximport (in
cython/cython-legacy) imports imp.  So it's cython that needs to be
patched.

I'm wondering what the provisional timescale for cython 3.0.x is?
Should I just leave my package with an autopkgtest failure until
cython 3.0.x is in unstable or ideally testing?  That's why I was
thinking of also patching cython in the short term until we are ready
for cython 3.0.x to enter unstable.

Best wishes,

   Julian



Re: cython 3.x (for Python 3.12)

2023-12-11 Thread Julian Gilbey
On Mon, Dec 11, 2023 at 04:34:17PM +0100, Matthias Klose wrote:
> On 11.12.23 16:19, Julian Gilbey wrote:
> > On Mon, Dec 11, 2023 at 08:09:31AM +0100, Matthias Klose wrote:
> > > [...]
> > > You could package a non-conflicting cython-legacy, however that would
> > > require more changes, also how to build it.
> > 
> > Hi Matthias,
> > 
> > Unfortunately, at least some of cython3-legacy doesn't currently work
> > with Python 3.12, and is the primary cause of (at least) #1056531.
> > cython3 provides the pyximport module, and that uses the imp module
> > which has been removed from Python 3.12.
> > 
> > Two possible ways forward on this particular bug:
> > 
> > - Disable all of the cython tests for this package for the time being,
> >until cython 3.x migrates to testing - this is simple and effective.
> > 
> > - Patch cython3-legacy to use importlib rather than imp.  This is
> >probably a good thing to do anyway.  (It may also be good to do this
> >with cython3 version 0.x currently in testing/unstable until cython
> >3.x is able to be uploaded to unstable.)  Then have my package's
> >autopkgtest depend on cython3-legacy (unless cython3 0.x is also
> >patched).
> 
> I won't working on this. Have you tried to depend on the python3-zombie-imp
> instead?

Excellent - I didn't know about that.  Are you OK for me to upload
versions of cython and cython-legacy which depend on this to fix the
Python 3.12 breakage?

Best wishes,

   Julian



Re: cython 3.x (for Python 3.12)

2023-12-11 Thread Julian Gilbey
On Mon, Dec 11, 2023 at 08:09:31AM +0100, Matthias Klose wrote:
> [...]
> You could package a non-conflicting cython-legacy, however that would
> require more changes, also how to build it.

Hi Matthias,

Unfortunately, at least some of cython3-legacy doesn't currently work
with Python 3.12, and is the primary cause of (at least) #1056531.
cython3 provides the pyximport module, and that uses the imp module
which has been removed from Python 3.12.

Two possible ways forward on this particular bug:

- Disable all of the cython tests for this package for the time being,
  until cython 3.x migrates to testing - this is simple and effective.

- Patch cython3-legacy to use importlib rather than imp.  This is
  probably a good thing to do anyway.  (It may also be good to do this
  with cython3 version 0.x currently in testing/unstable until cython
  3.x is able to be uploaded to unstable.)  Then have my package's
  autopkgtest depend on cython3-legacy (unless cython3 0.x is also
  patched).

Thoughts?

   Julian



Re: cython 3.x (for Python 3.12)

2023-12-11 Thread Julian Gilbey
On Mon, Dec 11, 2023 at 08:09:31AM +0100, Matthias Klose wrote:
> [...]
> > > > I find that there's also a significant issue with relying on
> > > > cython3-legacy: it conflicts with cython3, meaning that it will be
> > > > impossible to simultaneously install packages depending on cython3 and
> > > > cython3-legacy.  Once cython 3.x moves from experimental to unstable
> > > > to testing and packages start depending on it, this will become a
> > > > significant issue.  I assume that the aim will be for everything to be
> > > > ported to cython 3.x and for cython3-legacy to be dropped from testing
> > > > before the trixie freeze?
> [...]
> You could package a non-conflicting cython-legacy, however that would
> require more changes, also how to build it.

I had a very quick look at the packaged cython3-legacy.  One could
change the name of the module to Cython_legacy or probably better,
Cython0, and cython.py to cython0.py, pyximport to pyximport0.  Just a
handful of changes would be needed, I'm guessing.  Then it would be
co-installable with Cython 3.x, and any packages that actually need
cython3-legacy rather than Cython 3.x would have to be patched to call
the legacy version.  It's probably easier to just patch them for
Cython 3.x ;-)

Best wishes,

   Julian



Re: pandas 1.5 -> 2.1?

2023-12-11 Thread Julian Gilbey
Hi Kingsley,

On Sun, Dec 10, 2023 at 12:55:43PM -0800, Kingsley G. Morse Jr. wrote:
> Hi Rebecca, Julian and all science minded pythonistas of debian, great and 
> small!
> 
> I like your correspondence about upgrading from
> version 1.5 of pandas to 2.1.
> 
> It's open, scientific and explores the ideal of
> proceeding wisely in a matter of public interest.
> 
> My humble thoughts are:
> 
> 1.) Rebecca: *Why* did you write that you'd like
> to move forward with the pandas 1.5 -> 2.1
> transition? What's your reason?

A thought from me on this: pandas 2.1 has many improvements over
pandas 1.5.  And increasingly, other packages will be requiring these
new features.  So why would one not want to move forward with it?

> 2.) What may be the advantage of migrating to
> version 3.0 of Cython?

It is compatible with Python 3.12, whereas the current version of
Cython in Debian (0.29.x) is not really.  (For example, it has an
"import imp" in it, and this breaks with Python 3.12, which has
removed this deprecated module.)  As Cython 0.29.x is no longer
maintained upstream, having been superseded by Cython 3.x after many
years of development, our options are to either continue to patch
Cython 0.29.x within Debian to keep it working with Python 3.12 or to
upgrade to Cython 3.x.  As there is also software which now depends on
Cython 3.x to build, the former option seems unappealing.  (At best,
we might wish to keep the cython-legacy package around for building
packages which can't yet use Cython 3.x, but that should be a
short-term thing, not a long-term one.)

> 3.) The following one-liner suggests 44 debian
> packages might be affected by the breaks
> Rebecca said would be caused by pandas 2.x:
> 
> $ for s in augur cnvkit dyda emperor esda mirtop pymatgen pyranges 
> python-anndata python-biom-format python-cooler python-nanoget python-skbio 
> python-ulmo q2-quality-control q2-demux q2-taxa q2-types q2templates 
> sklearn-pandas ; do apt-cache search "$s" ; done | less

This does not seem like a particularly helpful one-liner; it picks up
packages such as python3-dyda-pipeline-config which are not in the
original list.  Instead, you perhaps want to count the number of
packages depending on these packages.  But what Rebecca is looking at
(I think) is how many packages would need fixing by the pandas
upgrade.

(But it is probably worse than this: I'm guessing these are only the
packages which fail to build with pandas 2.x or whose autopkgtest
fails with pandas 2.x.  But there may well be other breakage caused by
the upgrade which is not detectable in this way.  That is an issue
which will have to be handled by individual packages as they are
discovered, and the timing of the pandas upgrade is not related to
this problem.)

> 4.) The break that worries me the most is
> sklearn-pandas, because it seems to me that
> sklearn is 
> 
> popular and 
> 
> fundamental.

It seems that sklearn-pandas is abandoned; there were just two commits
in 2022, and prior to that was May 2021.  There has been no activity
since.  If someone is willing to patch it for Pandas 2.x, great
(perhaps you might help the maintainer to do this?), otherwise it
might have to drop out of Debian.

Best wishes,

   Julian



Re: Bug#1043240: transition: pandas 1.5 -> 2.1

2023-12-10 Thread Julian Gilbey
On Sun, Dec 10, 2023 at 01:06:01PM +, Rebecca N. Palmer wrote:
> I'd like to move forward with the pandas 1.5 -> 2.1 transition reasonably
> soon.
> 
> Given that pandas 2.x is *not* required for Python 3.12 (but is required for
> Cython 3.0), should we wait for the Python 3.12 transition to be done first?

Well, I have seen at least one package that has an RC bug for the
Python 3.12 transition that might be because it's still using an old
version of cython3 :(  So it's a bit of chicken-and-egg - having Cython
3.0 might be very helpful.  But then there is this list of 28 packages
broken by pandas 2.x.  On the other hand, these will need fixing at
some point soon anyway, so I'd be in favour of doing the pandas
transition now, which will allow Cython 3.0 to move into unstable.

Just my 2 cents' worth...

Best wishes,

   Julian



Re: cython 3.x (for Python 3.12)

2023-12-10 Thread Julian Gilbey
On Sat, Nov 25, 2023 at 04:23:46PM +, Stefano Rivera wrote:
> As part of preparing for Python 3.12 in Debian, I've uploaded cython 3
> to experimental.
> [...]
> 
> So, that's 71 regressions with cython3. dd-list below. Please help us
> port to cython 3. If this isn't possible, Graham is preparing a
> cython-legacy package, to help the stragglers. But we're expecting that
> this won't have great Python 3.12 support...
> https://ftp-master.debian.org/new/cython-legacy_0.29.36-1~exp1.html

I find that there's also a significant issue with relying on
cython3-legacy: it conflicts with cython3, meaning that it will be
impossible to simultaneously install packages depending on cython3 and
cython3-legacy.  Once cython 3.x moves from experimental to unstable
to testing and packages start depending on it, this will become a
significant issue.  I assume that the aim will be for everything to be
ported to cython 3.x and for cython3-legacy to be dropped from testing
before the trixie freeze?

Best wishes,

   Julian



Re: cython 3.x (for Python 3.12)

2023-11-30 Thread Julian Gilbey
On Sat, Nov 25, 2023 at 04:23:46PM +, Stefano Rivera wrote:
> [...]
> So, that's 71 regressions with cython3. dd-list below. Please help us
> port to cython 3. If this isn't possible, Graham is preparing a
> cython-legacy package, to help the stragglers. But we're expecting that
> this won't have great Python 3.12 support...
> https://ftp-master.debian.org/new/cython-legacy_0.29.36-1~exp1.html

Indeed; there's already one Python 3.12 related bug in the legacy
version: it tries to import imp in pyximport.py.

Best wishes,

   Julian



Re: Uncleaned egg-info directory giving lots of bugs about failing to build after successful build

2023-09-07 Thread Julian Gilbey
On Wed, Sep 06, 2023 at 08:05:45AM -0700, Soren Stoutner wrote:
> As a followup question, I have noticed that a lot of packages (including
> electrum, which I have recently started maintaining) ship the egg-info
> directory.  Looking through /usr/lib/python3/dist-packages/, this is common 
> but
> not universal.  Is there any reason to ship this directory or should it be
> removed from the binary packages?

Lots of packages depend on the egg-info directory being present.

$ grep EASY-INSTALL-ENTRY-SCRIPT /usr/bin/*

will give a (probably very long) list of executables that depend on an
egg-info (or equivalent) directory being present.

Best wishes,

   Julian



Re: Bug#1042443: ITP: pathos -- Framework for heterogeneous parallel computing

2023-09-01 Thread Julian Gilbey
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



Re: Uncleaned egg-info directory giving lots of bugs about failing to build after successful build

2023-08-18 Thread Julian Gilbey
On Fri, Aug 18, 2023 at 09:23:17AM -0400, Scott Talbert wrote:
> On Fri, 18 Aug 2023, Andreas Tille wrote:
> 
> > Am Fri, Aug 18, 2023 at 01:42:53PM +0100 schrieb Julian Gilbey:
> > > I'm sure I'm not the only one who received a whole bunch of bugs
> > > entitled "Fails to build source after successful build" last weekend.
> > > There was one theme common to most of them: the presence of a
> > > *.egg-info directory which was not cleaned by debian/rules clean.
> > > [...]
> 
> It is being worked on:
> https://salsa.debian.org/python-team/tools/dh-python/-/merge_requests/46

Amazing!

Thanks,

   Julian



Uncleaned egg-info directory giving lots of bugs about failing to build after successful build

2023-08-18 Thread Julian Gilbey
I'm sure I'm not the only one who received a whole bunch of bugs
entitled "Fails to build source after successful build" last weekend.
There was one theme common to most of them: the presence of a
*.egg-info directory which was not cleaned by debian/rules clean.

I know the bug report said that this policy is currently under
discussion, but I did get thinking about it.  I imagine that this
particular directory should be the responsibility of dh-python to
clean up, but it may not be sensible to always delete *.egg-info
directories, as they may be present in the orig.tar.gz file.  One
could handle it by manually adding this directory to debian/clean in
each package, but perhaps this should be the default behaviour of
dh-python?

Any thoughts?

Best wishes,

   Julian



Re: dask.distributed RC bug #1042135

2023-08-12 Thread Julian Gilbey
Hi Diane,

On Fri, Aug 11, 2023 at 10:05:53AM -0700, Diane Trout wrote:
> > > 
> > 
> > Thanks so much!  I see you've already started on dask :)
> > 
> > I took at quick look at arrow - yikes!  There is potentially work
> > afoot on this though:
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970021
> > 
> 
> Dask & dask.distributed 2023.8.0 was easier to update than some of the
> other versions they had between 2022.12 and now.
> 
> Dask would still benifit from pyarrow, by I added enough
> pytest.importorskip to avoid triggering the tests that depend on
> pyarrow.
> 
> It also looks like it builds for me and the debian builder so I closed
> 1042135.
> 
> Hopefully that helps. (And it looks like it's got some code for pandas
> 2.0 so hopefully that'll help Rebecca Palmer.

That's fantastic - thank you so much!

:-)

   Julian



Re: dask.distributed RC bug #1042135

2023-08-06 Thread Julian Gilbey
Hi Diane (and cc'ing the correct mailing list - oops!),

On Fri, Aug 04, 2023 at 09:37:48AM -0700, Diane Trout wrote:
> On Fri, 2023-08-04 at 14:02 +0100, Julian Gilbey wrote:
> > Hi Diane,
> > 
> > I just got emails telling me that some of my packages would be
> > removed
> > from testing because they (recursively) (build-)depend on
> > dask.distributed: https://bugs.debian.org/1042135
> > 
> > Are you able to take a look at this soon, or would you like someone
> > to
> > do a team upload?
> > 
> > There is also a newer version available: 2023.7.1, which may well
> > resolve this.
> 
> Last time I tried updating pyarrow wasn't properly optional and we
> don't have it packaged. (And it's actually in a single repository that
> builds multiple language modules)
> 
> Dask has updated their build system some, and let me see if it'll
> update.
> 
> If I don't manage to get to it, make sure that if you try you have to
> update both dask and dask.distributed together, and it's best to makes
> sure that you run the dask.distributed tests using the updated dask.
> 
> That's where why it's usually been difficult to update.

Thanks so much!  I see you've already started on dask :)

I took at quick look at arrow - yikes!  There is potentially work
afoot on this though:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970021

Best wishes,

   Julian



Re: #!/usr/bin/python3 vs virtualenv

2023-03-05 Thread Julian Gilbey
On Fri, Mar 03, 2023 at 04:22:11PM -0500, Jorge Moraleda wrote:
> Jeremy, Thank you for your quick reply!
> 
> I did not know about `sudo pip install --break-system-packages foo` or  `sudo 
> rm
> /usr/lib/python3.11/EXTERNALLY-MANAGED` (Frankly I only knew about this issue
> what I have read on this discussion). This is very helpful and it really 
> changes
> my outlook on this topic.

The --break-system-packages option is noted in
/usr/share/doc/python3.11/README.venv, and this file is mentioned in
the NEWS file for python3.11.  The
/usr/lib/python3.11/EXTERNALLY-MANAGED file is not mentioned there; I
personally think that having to type --break-system-packages every
time one installs a package via pip globally or on a per-user basis is
safer, as it reminds you that you run risks doing so.

Best wishes,

   Julian



Re: Python 3.10 in bookworm

2023-02-07 Thread Julian Gilbey
On Tue, Feb 07, 2023 at 12:31:23PM +0100, Joost van Baal-Ilić wrote:
> Op Tue, Feb 07, 2023 at 05:52:21AM + schreef Danial Behzadi دانیال بهزادی:
> > Does it worth trying to package pyenv for Debian? Ain't it against any 
> > rules?
> 
> See "ITP pyenv" @ http://bugs.debian.org/978149 .

Oh, how embarrassing - I already knew about this software a year ago!

Best wishes,

   Julian



Re: Python 3.10 in bookworm

2023-02-06 Thread Julian Gilbey
Hi Andrey,

On Mon, Feb 06, 2023 at 11:53:33AM +0100, Andrey Rakhmatullin wrote:
> On Sun, Feb 05, 2023 at 01:50:34PM +0000, Julian Gilbey wrote:
> > Our social contract #4 says "Our priorities are our users and free
> > software".  What benefits would having the python3.10 base packages in
> > bookworm bring for our users (as I point out, for some users, this is
> > a necessity) and what disadvantages would it bring (none that I can
> > think of)?  Why would we tell a whole bunch of our users: "Don't
> > upgrade to Debian 12 until all of the critical packages you use from
> > PyPI are upgraded to support Python 3.11, or fix those packages
> > yourself"?
> The next obvious step for these use cases is to just install 3.10 with
> pyenv.

Oh, that's brilliant!  I didn't know about this tool (and I note it's
not currently in Debian).

This solution for users who need Python 3.10, together with the
support burden of having python3.10 in bookworm (which I hadn't
appreciated), I withdraw my objection to the removal of python3.10.

Best wishes,

   Julian



Re: Python 3.10 in bookworm

2023-02-05 Thread Julian Gilbey
Hi Michael,

On Sun, Feb 05, 2023 at 02:29:10PM +0100, Michael Kesper wrote:
> Hi Julian,
> 
> Am 05.02.23 um 11:38 schrieb Julian Gilbey:
> > Why is the current intention not to ship the python3.10 package in
> > bookworm?
> 
> Because it would amount to about double the work for all those involved.

I doubt it would be double the work, but as Scott points out in his
email, it would require paying attention to security issues in the
Python interpreter for both the 3.10 and 3.11 interpreters.  I had not
considered that.

> Besides, Python 3.11 has some points for it:
> - Real performance gains for real workloads
> - It will be supported one year longer (so EOL is expected to be around the
> time bookworm will be out of stable, too).

I'm not proposing that we revert to Python 3.10 as default for
bookworm, only that we have the python3.10 package itself in
bookworm.

> > I was trying to run some experiments in a virtual environment a few
> > days ago, and it turns out that several of the Python packages I
> > needed do not yet run on Python 3.11.  I was saved by being able to
> > run in a Python 3.10 venv and download all the required packages from
> > PyPI.  If bookworm shipped without python3.10, I would not have been
> > able to do my work.  Removing python3.10 from bookworm will seriously
> > affect many of our users in a similar situation to me.
> ...
> > P.S. We should also fix #1036268 if we do keep python3.10 in bookworm;
> > I'm happy to do an NMU if needed.
> 
> Maybe you could sponsor a "backport" of Python3.11?

I don't understand this suggestion.  #1036268 says that running
"python3.10 -m venv envname" if the python3.10-venv package is not
installed should output a meaningful error message rather than crash
with an "undefined variable" error.

Best wishes,

   Julian



Re: Python 3.10 in bookworm

2023-02-05 Thread Julian Gilbey
On Sun, Feb 05, 2023 at 02:41:08PM +, Stefano Rivera wrote:
> Hi Julian (2023.02.05_10:38:23_+)
> 
> > Why is the current intention not to ship the python3.10 package in
> > bookworm?
> 
> Because we aim to have a single Python release supported in every stable
> release.

I am not suggesting that we revert to having Python 3.10 as a
"supported version" (that would be a whole separate discussion); I am
suggesting that we keep just the Python 3.10 interpreter and
python3.10-venv in bookworm, so that users can use it to run a virtual
environment if they need to do so.

> > I was trying to run some experiments in a virtual environment a few
> > days ago, and it turns out that several of the Python packages I
> > needed do not yet run on Python 3.11.  I was saved by being able to
> > run in a Python 3.10 venv and download all the required packages from
> > PyPI.  If bookworm shipped without python3.10, I would not have been
> > able to do my work.  Removing python3.10 from bookworm will seriously
> > affect many of our users in a similar situation to me.
> 
> By the time bookworm releases, that probably won't be the case any more.

I honestly don't know if that will be the case or not; some packages
will be much slower to adapt than others.  That's why I'm suggesting
we leave the python3.10 and python3.10-venv packages in bookworm.

> But anything that gets removed from Debian, because it isn't ready yet
> obviously gets hurt in the process...

I'm not sure what you mean here?

Best wishes,

   Julian



Re: Python 3.10 in bookworm

2023-02-05 Thread Julian Gilbey
Our social contract #4 says "Our priorities are our users and free
software".  What benefits would having the python3.10 base packages in
bookworm bring for our users (as I point out, for some users, this is
a necessity) and what disadvantages would it bring (none that I can
think of)?  Why would we tell a whole bunch of our users: "Don't
upgrade to Debian 12 until all of the critical packages you use from
PyPI are upgraded to support Python 3.11, or fix those packages
yourself"?

And may I politely remind you, Thomas, that you are very
concerned about breaking things for people:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=973617#40
This is likely a far greater impact than the discussion there on many
more people.

Best wishes,

   Julian

On Sun, Feb 05, 2023 at 12:25:18PM +0100, Thomas Goirand wrote:
> How about fixing the 3.11 issues if you hit them ? How about using Buster and 
> 3.9 if 3.11 doesn't work (yet) for you ?
> 
> Thomas Goirand (zigo)
> On Feb 5, 2023 11:38, Julian Gilbey  wrote:
> >
> > Why is the current intention not to ship the python3.10 package in 
> > bookworm? 
> >
> > I was trying to run some experiments in a virtual environment a few 
> > days ago, and it turns out that several of the Python packages I 
> > needed do not yet run on Python 3.11.  I was saved by being able to 
> > run in a Python 3.10 venv and download all the required packages from 
> > PyPI.  If bookworm shipped without python3.10, I would not have been 
> > able to do my work.  Removing python3.10 from bookworm will seriously 
> > affect many of our users in a similar situation to me. 
> >
> > Best wishes, 
> >
> >    Julian 
> >
> > P.S. We should also fix #1036268 if we do keep python3.10 in bookworm; 
> > I'm happy to do an NMU if needed. 



Python 3.10 in bookworm

2023-02-05 Thread Julian Gilbey
Why is the current intention not to ship the python3.10 package in
bookworm?

I was trying to run some experiments in a virtual environment a few
days ago, and it turns out that several of the Python packages I
needed do not yet run on Python 3.11.  I was saved by being able to
run in a Python 3.10 venv and download all the required packages from
PyPI.  If bookworm shipped without python3.10, I would not have been
able to do my work.  Removing python3.10 from bookworm will seriously
affect many of our users in a similar situation to me.

Best wishes,

   Julian

P.S. We should also fix #1036268 if we do keep python3.10 in bookworm;
I'm happy to do an NMU if needed.



Re: Old generated binary dependencies after renaming psycopg

2023-01-17 Thread Julian Gilbey
On Tue, Jan 17, 2023 at 09:08:01AM +0100, Tomasz Rybak wrote:
> Hello.
> After fixing #1016031 "psycopg3: binary package name should be python3-
> psycopg"
> (I renamed package names, full changes:
> * python3-psycopg3 -> python3-psycopg
> * python3-psycopg3-pool -> python3-psycopg-pool
> * python-psycopg3-doc -> python3-psycopg-doc)
> I tried to rebuild reverse dependencies,
> i.e. pgcli and python3-pgspecial.
> Rebuild went without problems, new packages are the same
> as old ones, but their binary packages still depend on python3-
> psycopg3,
> even though they build-depend on python3-psycopg.

Nope, pgcli does not build-depend on it, rather it explicitly
specifies Depends: python3-psycopg3.  Likewise, python-pgspecial
specifies the same Depends (though it also has a Build-Depends:
python3-psycopg3).  These packages will need their dependencies
updating.  (You might also consider making python3-psycopg Provides:
python3-psycopg3 and likewise for the other two binary packages for
bookworm.)

Best wishes,

   Julian



Re: How to create multi-source tarball with different submodules for scipy

2023-01-16 Thread Julian Gilbey
On Mon, Jan 16, 2023 at 05:05:39PM +0100, Andreas Tille wrote:
> Hi,
> 
> I tried to create a multi-source tarball for scipy in its experimental
> branch[1].  Upstream includes a set of git submodules in its build
> process.  I intended to merge all these submodules in a single
> scipy_1.10.0.orig-submodules.tar.gz.  This tarball is created with a
> script[2] which makes sure that the exact directory structure as it is
> used by upstream is conserved.  This directory layout is needed in the
> build process.  Unfortunately `dpkg-source -x` extracts the content of
> the submodules tarball into a subdirectory submodules/.
> 
> Is there any trick to unpack this tarball right into the root?
> Otherwise I need to do some symlinks workaround in d/rules to provide
> all files where these are needed.

Not that I know of; this is the design of the multi-source tarball
setup: each component tarball is extracted into a directory with the
name of the component.

Best wishes,

   Julian



Re: Policy Proposal python3-supported-(min|max) virtual packages

2023-01-14 Thread Julian Gilbey
On Sat, Jan 14, 2023 at 07:34:59PM +, Scott Kitterman wrote:
> Typically though doesn't the python interpreter package provide modules that 
> are now incorporated?  If python3.11 provides python3-tomli, won't that mess 
> this up?

In this case, it doesn't; the Python 3.11 standard library module is
called tomllib, presumably to avoid conflicting with the toml or tomli
library.  (And I'm guessing the package in question imports tomllib if
using 3.11 or higher and tomli otherwise.)

Best wishes,

   Julian



Re: eric and jquery.js to a symbolic link

2023-01-05 Thread Julian Gilbey
On Thu, Jan 05, 2023 at 07:14:40PM +, Guðjón Guðjónsson wrote:
> Hi list
> I am working on eric and I do have a problem with the lintian requirement to
> replace the jquery.js file with the debian provided jquery.js file.
> The upstream author pointed out that it doesn't work as well and I have 
> verified
> the behavior.
> If you run eric7_browser and press ==->Bookmarks->Speed Dial it doesn't show 
> the
> links when using the debian jquery.js file.
> Is it ok to keep the original jquery files and add a lintian-override in this
> case?
> Regards
> Gudjon

Hi Gudjon,

Looking at it, the problem seems to be that eric is using an ancient
version of jQuery (1.7.1, released Nov 22, 2011; 1.7.2 was released on
Mar 21, 2012).  jQuery-UI 1.8.16 is similarly old (released Aug 15,
2011, 1.8.17 was released on Nov 29, 2011).  You could embed it (but
not the minimised version in the upstream eric sources, but rather the
original source from github.com/jquery/{jquery,jquery-ui}, but it
would be far from ideal - who knows how many bugs or possible security
issues there are in such an old version?  A much better solution, if
feasible, is to ask the eric upstream to switch to a recent version of
jQuery and jQuery UI, and to update the code depending on it
accordingly.  If upstream won't do that, then we should.

Best wishes,

   Julian



Re: Python 3.11 for bookworm?

2022-12-19 Thread Julian Gilbey
Hi Jochen,

On Mon, Dec 19, 2022 at 04:53:58PM +0100, Jochen Sprickerhof wrote:
> Hi Julian,
> 
> * Julian Gilbey  [2022-12-19 09:41]:
> > Quick update: with the updating of python3-bytecode from 0.13 to 0.14
> > in unstable/testing, which allows it to handle Python 3.11, something
> > has changed and now pydevd doesn't even pass the tests on Python
> > 3.10.  The python3-bytecode underwent a major restructuring, so it is
> > entirely possible that something has changed that wasn't part of the
> > advertised API or something like that.  But that's for upstream pydevd
> > developers to deal with.
> 
> I've uploaded 0.14.0-2 that should fix this. As far as I've found that was
> only a minor fix in the Debian specific offset patch, sorry for the trouble.

Phew!  I didn't think to check that.  Unfortunately, though, there are
still numerous pydevd test errors even with 0.14.0-2, so I think
something has changed in bytecode that the pydevd maintainers will
have to adapt to.  So either I skip 14 newly failing tests on Python
3.10 (they're mostly skipped on 3.11 as the current pydevd version
skips bytecode tests on Python 3.11) or wait for a new version of
pydevd.  Hmmm.

Anyway, thanks so much for all your work updating this package - it's
been really helpful, as I've been a bit overloaded and Spyder 5.4.0
together with the Python 3.11 transition has been a lot to handle.  I
also learnt a lot from your changes!

Best wishes,

   Julian



Re: Python 3.11 for bookworm?

2022-12-19 Thread Julian Gilbey
On Sun, Dec 18, 2022 at 06:02:58PM +, Julian Gilbey wrote:
> On Thu, Dec 15, 2022 at 04:10:05PM +0100, Thomas Goirand wrote:
> > On 12/13/22 13:34, Julian Gilbey wrote:
> > > If Python 3.11 is the default, then it is highly likely that Spyder
> > > will not be included: debugpy, which is a dependency of Spyder and
> > > python3-ipykernel (and lots of things that depend on that) seems to
> > > require major work upstream to make it fully compatible with Python
> > > 3.11.  This is work in progress, but I don't know whether it will be
> > > ready in time for the freeze.  At the moment, I have worked around
> > > this problem by just skipping the failing tests, but that is far from
> > > an ideal solution.
> > 
> > It's probably ok if it's a *TEMPORARY* solution until upstream fixes
> > everything in time for the release (which is months after the freeze). The
> > question is: do you believe this may happen for let's say next March?
> 
> The truth is that I don't know.  Upstream is very good, but the Python
> 3.11 internal changes are very significant, and debugpy (along with
> pydevd, which is part of debugpy) are deeply affected by this, as they
> work at the level of Python's internals.  So I don't know how long it
> will take them to make the required changes (and it's far beyond my
> capability or capacity to do myself).  I can hope they'll do it in
> time for the freeze, but I wouldn't like to place a bet on it.

Quick update: with the updating of python3-bytecode from 0.13 to 0.14
in unstable/testing, which allows it to handle Python 3.11, something
has changed and now pydevd doesn't even pass the tests on Python
3.10.  The python3-bytecode underwent a major restructuring, so it is
entirely possible that something has changed that wasn't part of the
advertised API or something like that.  But that's for upstream pydevd
developers to deal with.

One possibility is that we revert to the situation in bullseye if
pydevd is not ready in time for the freeze.  Bullseye didn't have
bytecode/pydevd/debugpy, and it meant that debugging was limited in
Spyder: we remove python3-debugpy from the dependencies of
python3-ipykernel and then the rest of the dependency chain will be
OK.  It's certainly not an ideal solution, but it may be the best we
can do if we're sticking with Python 3.11.  It may actually be worth
doing that at this point so that Spyder can stay in testing for the
time being, even though pydevd and debugpy won't.

Best wishes,

   Julian



  1   2   3   >