• Re: Python 3.13 addition as a supported Python version started

    From Colin Watson@21:1/5 to Matthias Klose on Mon Dec 16 03:00:01 2024
    XPost: linux.debian.maint.python

    On Wed, Nov 13, 2024 at 10:29:06AM +0100, Matthias Klose wrote:
    python3-defaults in unstable now adds Python 3.13 as a supported Python 3.13 version. You might see some additional build failures, until the binNMUs
    for this addition are done [1]. This might take some days for some architectures. We will most likely also see some more issues once the lower levels of this addition are done.
    [...]
    [1] https://release.debian.org/transitions/html/python3.13-add.html

    While there are a few bits of that transition tracker still red, the
    current target is to work on the list of autopkgtest failures shown on https://tracker.debian.org/pkg/python3-defaults in order to get the
    addition of 3.13 as a supported version into testing. As usual, this
    page can be a little hard to interpret because it shows test failures of
    the versions of those packages in testing, and you have to click through
    to each corresponding package (sometimes through multiple levels of
    failures) to see whether it's been fixed in unstable. But with ~35
    packages left there, it's getting easier to wade through and we're
    getting pretty close.

    Here's the current state, with my comments:

    * audioread: #1082047; apparently needs packaging of a couple of pieces
    removed from the standard library. Reverse-dependencies are eartag,
    puddletag, and python3-acoustid.

    * dask/dask.distributed: #1088234 and #1088286, but also #1085947 in
    sphinx-book-theme. I sank a bunch of time into trying to fix this
    last month and didn't really get anywhere very satisfying. Can
    anyone with more experience with these packages figure this out?

    * datalad-next: #1088038. Probably not too hard if you can figure out
    how that test is supposed to work.

    * deepdiff: #1088239, blocked by orderly-set in NEW. I poked
    #debian-ftp.

    * hyperkitty: #1088312. Should be fairly easy.

    * ipykernel: Fixed in unstable.

    * ironic-python-agent: #1089531. Should be fairly easy; zigo said on
    IRC that this is a leaf package and doesn't need to block migration.

    * jinja2: Fixed in unstable.

    * jupyter-server: Fixed in unstable.

    * mdp: Fixed in unstable.

    * ovn-octavia-provider: #1088762. zigo said on IRC that this is a leaf
    package and doesn't need to block migration.

    * pocketsphinx-python: #1088764. Apparently difficult.

    * pytest-jupyter: Fixed by new ipykernel in unstable.

    * python-attrs: Fixed in unstable; blocked on python-cattrs.

    * python-beartype: #1089017. Apparently fixed upstream, though I don't
    know exactly where.

    * python-cattrs: #1073406/#1086614.

    * python-omegaconf: #1089049.

    * python-oslo.messaging: I believe this is fixed in unstable
    (#1089050) and waiting for python-eventlet to migrate to testing.

    * python-pure-python-adb: #1082251/#1084618; apparently just needs a
    dependency on python3-zombie-telnetlib?

    * python-voip-utils: #1088827 fixed in unstable, but has an autopkgtest
    regression on s390x (#1089826).

    * rich: #1082290; seems to be fixed upstream.

    * smart-open: #1089053; upstream fix in progress.

    * spyder: #1088068/#1089054.

    * twisted: Fixed in unstable, just waiting for matrix-synapse to
    migrate first (which should be soon).

    There are also a number of architecture-specific failures showing up
    there. Some might go away with a few more retries I guess, but we'll
    likely need to work out what to do about the rest. I haven't looked at
    these in any depth.

    Can anyone help with any of the remaining problems here? This would be especially useful for packages that aren't maintained by the Python
    team.

    --
    Colin Watson (he/him) [cjwatson@debian.org]

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Julian Gilbey@21:1/5 to Colin Watson on Tue Dec 17 14:00:01 2024
    XPost: linux.debian.maint.python

    On Mon, Dec 16, 2024 at 01:58:14AM +0000, Colin Watson wrote:
    [...]
    * spyder: #1088068/#1089054.

    I'm struggling with this one; I've asked at https://github.com/spyder-ide/spyder/issues/23074
    for help, but nothing so far. I've just pushed my current work to
    salsa (git@salsa.debian.org:science-team/spyder.git), and if anyone
    has time to look into this, I'd really appreciate it.

    Here's the little I've found so far:

    * I'm trying to update to spyder 6.0.2

    * In an lxc container with Debian unstable and all the test-time
    packages installed, the tests fail in the way described, both with
    Python 3.12 and Python 3.13.

    * In the same lxc container, if I build a virtual Python 3.12 or 3.13
    environment following the upstream testing scripts (in
    .github/workflows) and test the package there, all works smoothly.

    Perhaps it's an updated version of python3-pytestqt or something like
    that?

    Best wishes,

    Julian

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Colin Watson@21:1/5 to Colin Watson on Fri Dec 20 04:40:01 2024
    XPost: linux.debian.maint.python

    On Mon, Dec 16, 2024 at 01:58:14AM +0000, Colin Watson wrote:
    While there are a few bits of that transition tracker still red, the
    current target is to work on the list of autopkgtest failures shown on https://tracker.debian.org/pkg/python3-defaults in order to get the
    addition of 3.13 as a supported version into testing. As usual, this
    page can be a little hard to interpret because it shows test failures of
    the versions of those packages in testing, and you have to click through
    to each corresponding package (sometimes through multiple levels of
    failures) to see whether it's been fixed in unstable. But with ~35
    packages left there, it's getting easier to wade through and we're
    getting pretty close.

    We've dealt with on the order of half of those one way or another, so
    here's an update:

    * audioread: #1082047; apparently needs packaging of a couple of pieces
    removed from the standard library. Reverse-dependencies are eartag,
    puddletag, and python3-acoustid.

    I poked #debian-ftp about maybe getting python-deadlib through NEW.

    * dask/dask.distributed: #1088234 and #1088286, but also #1085947 in
    sphinx-book-theme. I sank a bunch of time into trying to fix this
    last month and didn't really get anywhere very satisfying. Can
    anyone with more experience with these packages figure this out?

    Currently exchanging email with Nilson about the state of
    sphinx-book-theme. It might also be worth somebody seeing if it's
    practical to temporarily detach dask/dask.distributed from its
    documentation theme.

    * datalad-next: #1088038. Probably not too hard if you can figure out
    how that test is supposed to work.

    Fixed.

    * deepdiff: #1088239, blocked by orderly-set in NEW. I poked
    #debian-ftp.

    ftpmaster processed orderly-set through NEW, so Emmanuel fixed this in unstable. There's currently an i386 autopkgtest failure, but Fabian
    fixed rust-associative-cache to build on i386, and that should sort it
    out once it reaches testing.

    * hyperkitty: #1088312. Should be fairly easy.

    No progress - anyone?

    * ironic-python-agent: #1089531. Should be fairly easy; zigo said on
    IRC that this is a leaf package and doesn't need to block migration.

    * ovn-octavia-provider: #1088762. zigo said on IRC that this is a leaf
    package and doesn't need to block migration.

    Thomas fixed these two in unstable.

    * pocketsphinx-python: #1088764. Apparently difficult.

    No progress as far as I know. (I guess we could wait for autoremoval
    from testing, which is currently scheduled for 29 December.)

    * python-attrs: Fixed in unstable; blocked on python-cattrs.

    * python-beartype: #1089017. Apparently fixed upstream, though I don't
    know exactly where.

    * python-cattrs: #1073406/#1086614.

    * python-omegaconf: #1089049.

    No progress on this lot as far as I know.

    * python-oslo.messaging: I believe this is fixed in unstable
    (#1089050) and waiting for python-eventlet to migrate to testing.

    Fixed.

    * python-pure-python-adb: #1082251/#1084618; apparently just needs a
    dependency on python3-zombie-telnetlib?

    Emmanuel fixed this in unstable.

    * python-voip-utils: #1088827 fixed in unstable, but has an autopkgtest
    regression on s390x (#1089826).

    No progress. I poked Edward on IRC.

    * rich: #1082290; seems to be fixed upstream.

    I investigated this (with help from debusine's new reverse-dependency autopkgtest workflow) and concluded that upgrading rich and textual
    should fix it; details in the bug. Waiting for feedback from Sandro.

    * smart-open: #1089053; upstream fix in progress.

    Fixed in unstable.

    * spyder: #1088068/#1089054.

    See replies to this email thread. There's clearly some more work to do
    here, but it looks somewhat tractable.

    * twisted: Fixed in unstable, just waiting for matrix-synapse to
    migrate first (which should be soon).

    Fixed.

    There are also a number of architecture-specific failures showing up
    there. Some might go away with a few more retries I guess, but we'll
    likely need to work out what to do about the rest. I haven't looked at
    these in any depth.

    I chased down a few of these. dipy is fixed in unstable; fenics-basix
    is #1090766; I fixed pytest-forked and pytest-mpi in unstable.

    python-libtmux/s390x (e.g. https://ci.debian.net/packages/p/python-libtmux/testing/s390x/55551127/)
    looks as though it needs investigation.

    statsmodels/armel (e.g. https://ci.debian.net/packages/s/statsmodels/testing/armel/55559166/)
    probably just requires skipping some slow tests, since the test takes
    twice as long while we have two supported Python versions and it's not
    very fast on armel to begin with. Somebody who knows the package better
    than I do can probably make a guess at which tests are most reasonable
    to exclude.

    --
    Colin Watson (he/him) [cjwatson@debian.org]

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Colin Watson@21:1/5 to Julian Gilbey on Fri Dec 20 04:30:01 2024
    XPost: linux.debian.maint.python

    On Tue, Dec 17, 2024 at 12:53:42PM +0000, Julian Gilbey wrote:
    On Mon, Dec 16, 2024 at 01:58:14AM +0000, Colin Watson wrote:
    [...]
    * spyder: #1088068/#1089054.

    I'm struggling with this one; I've asked at https://github.com/spyder-ide/spyder/issues/23074
    for help, but nothing so far. I've just pushed my current work to
    salsa (git@salsa.debian.org:science-team/spyder.git), and if anyone
    has time to look into this, I'd really appreciate it.

    I poked around a bit in pdb. I think the problem is that one plugin is
    calling the icon machinery at class creation time, before a QApplication
    or equivalent has been set up, so font loading doesn't happen. Since
    pytest goes through and loads all the Python files to look for tests,
    this causes it problems.

    This patch helps (borrowed from similar code in a different plugin);
    feel free to send it upstream if you think it makes sense:

    diff --git a/spyder/plugins/preferences/widgets/configdialog.py b/spyder/plugins/preferences/widgets/configdialog.py
    index c3f6bb3..d822431 100644
    --- a/spyder/plugins/preferences/widgets/configdialog.py
    +++ b/spyder/plugins/preferences/widgets/configdialog.py
    @@ -28,11 +28,11 @@ class ConfigDialog(SidebarDialog):

    # Constants
    TITLE = _("Preferences")
    - ICON = ima.icon('configure')
    MIN_WIDTH = 940 if MAC else (875 if WIN else 920)
    MIN_HEIGHT = 700 if MAC else (660 if WIN else 670)

    def __init__(self, parent=None):
    + self.ICON = ima.icon('configure')
    SidebarDialog.__init__(self, parent)

    # Attributes

    With that, the tests are able to actually start up, although there are
    some other failures. It might be worth experimenting with whether
    upgrading yapf to a more recent upstream version would help with the
    rest? And it's a rather slow set of tests so I didn't wait for them to
    finish before sending this email.

    --
    Colin Watson (he/him) [cjwatson@debian.org]

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Julian Gilbey@21:1/5 to Colin Watson on Fri Dec 20 10:50:01 2024
    XPost: linux.debian.maint.python

    On Fri, Dec 20, 2024 at 03:22:57AM +0000, Colin Watson wrote:
    On Tue, Dec 17, 2024 at 12:53:42PM +0000, Julian Gilbey wrote:
    On Mon, Dec 16, 2024 at 01:58:14AM +0000, Colin Watson wrote:
    [...]
    * spyder: #1088068/#1089054.

    I'm struggling with this one; I've asked at https://github.com/spyder-ide/spyder/issues/23074
    for help, but nothing so far. I've just pushed my current work to
    salsa (git@salsa.debian.org:science-team/spyder.git), and if anyone
    has time to look into this, I'd really appreciate it.

    I poked around a bit in pdb. I think the problem is that one plugin is calling the icon machinery at class creation time, before a QApplication
    or equivalent has been set up, so font loading doesn't happen. Since
    pytest goes through and loads all the Python files to look for tests,
    this causes it problems.
    [...]

    Hi Colin,

    That's amazing, thank you! I'm still curious why it succeeds with the
    upstream version in a virtual environment but not with our setup.
    I'll try it out when I'm better and submit it upstream. (And in the
    meantime, spyder has an autorm date of 2024-12-25, if I recall
    correctly, so this should not hold up the Python 3.13 transition.)

    Also, I'm used to having lots of new test failures with newer versions
    of Spyder, so what you observed about several tests failing doesn't
    surprise me!

    Best wishes,

    Julian

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)