#1148460 pandas: FTBFS against python 3.15rc2 as default

Package:
src:pandas
Source:
src:pandas
Submitter:
Maximiliano Curia
Date:
2026-10-07 18:53:03 UTC
Severity:
normal
Tags:
#1148460#5
Date:
2026-09-19 19:41:27 UTC
From:
To:
Hi!

While rebuilding the python related packages against the Python 3.15rc2
as the default version we found that pandas failed to build from source
[1].

The problem is caused by packages that are used as test or documentation
dependencies, that depend on pandas. And these circular dependencies
fail, because pandas-lib depends on Python3 < 3.15

I understand that this is a known problem, as the debian/control file
includes comments about this:

```
    # these are for not having (as many) exception messages in documentation examples
    # so may be temporarily removed if they are broken or to break bootstrap cycles
                      python3-rpy2 <!nodoc>,
                      python3-seaborn <!nodoc>,
    # these are also used in some tests, but depend on pandas, so are in -indep to avoid
    # circular-dependency BD-Uninstallable when arch:all finishes before some of the arch:any start
                      python3-pyreadstat (>= 1.2.8~) <!nocheck> <!nodoc>,
                      python3-statsmodels <!nocheck> <!nodoc>,
                      python3-xarray (>= 2024.10.0~) <!nocheck> <!nodoc>,
```

My suggestion to properly solve this rather than temporarily removing
the dependencies as the comment suggest, is to split the source package
in two: pandas on one side, and pandas-doc on the other. And move the
tests that cause circular dependencies to autopkg tests rather than
build tests.

Please consider applying a fix similar to this to avoid having to remove
this dependencies whenever the default Python version changes.

Setting the severity to important for now. Once Python 3.15 becomes the
default version this bug will become release critical.

Happy hacking,

[1]: https://debusine.debian.net/debian/r-python-python3.15/artifact/4749196/

#1148460#10
Date:
2026-09-30 07:05:53 UTC
From:
To:
That issue isn't a problem for Python version transitions (done the
normal way, i.e. rebuild arch:any not arch:all).

The actual error in that log names the uninstallable package as
python3-pyqt5 (which possibly can't be made optional because of
#1119724), not any of these known-issue packages.  Have you tried
building python3-pyqt5 before pandas?

#1148460#15
Date:
2026-10-02 05:15:47 UTC
From:
To:
Hi Rebecca

Reading through #1119724 that looks like one of the various iterations
of python3-pytestqt's dependencies...

The current situation is that pytestqt needs:

- some sort of Qt library installed (that can be pyqt5, pyqt6 or
   pyside6)

- the relevant split-packages installed for Qt6; these aren't monolithic
   packages any more and that might help avoid pandas having dependencies
   that aren't widely available

- configuration on which of the Qt APIs to use. This can be done either
   via the PYTEST_QT_API environment variable (from d/rules, d/tests/*)
   or by setting the pytest config option qt_api in pytest.ini or
   pyproject.toml.

This last option is particularly important for packaging; many upstreams
that use pytestqt set up their test harness to iterate over the APIs and
so leave it to pytestqt's automatic API detection to work out which one
is installed and use that. That works on CI using tox, but doesn't work
so well in Debian packaging. I'm assuming pandas doesn't really need to
worry about which Qt API is being used in the testing and so any of them
should be fine; if you do need to test with multiple APIs then looping
over the API has become standard in various other qtpy* and pyqt* packages.

The code that actually uses Qt (oi/clipboard/) still talks a lot about
Qt4... that's disturbing. That it's going via qtpy probably means it
just works for Qt6 too though.

(of course the other option is to suppress testing the clipboard functions?)

cheers
Stuart

#1148460#20
Date:
2026-10-07 18:35:43 UTC
From:
To:
Subsequent pandas builds in sid-py315-default appear to have succeeded,
probably because fixing #1148457 made pyqt5 installable.  Hence, I
consider this to be effectively a duplicate of that bug, and fixed.

If I am wrong, please reopen this bug.

It would probably be a good idea to switch to pyqt6 if that works, but
that's unrelated to python3.15.