statsmodels passed NEW...and FTBFS with
dh: unable to load addon sphinxdoc: Can't locate
Debian/Debhelper/Sequence/sphinxdoc.pm in @INC
That file is in the sphinx-common package, which suggests that at least
some of the sphinx dependencies need to be Build-Depends and not just
Build-Depends-
On 29/09/17 23:55, Diane Trout wrote:
I wonder if it's better to filter sphinxdoc out of the dh line, install
sphinx-common, or just always install python3-sphinx?
For local testing of this, use pbuilder --debbuildopts -B
Given earlier messages that we want this working ASAP, always installing
On 30/09/17 16:50, Diane Trout wrote:
I am curious if Rebecca is using pandas on a non-intel architecture
though (was wondering how she noticed pandas hadn't built)
No - I found this email thread and checked
https://buildd.debian.org/status/package.php?p=pandas
Source: sympy
Severity: serious
Control: tags -1 patch
X-Debbugs-Cc: debian-python@lists.debian.org
python3-distutils has been moved out of python3.6 (as of 3.6.5~rc1-2),
so if you need it, please build-depend on it. (Or python3-setuptools,
given that this looks like it might prefer that.)
(
(Sorry if this has been discussed before: it's not obvious how to search
for it)
Policy 12.3 [0] states that documentation for $package should preferably
be packaged as $package-doc but still install to /usr/share/doc/$package
not /usr/share/doc/$package-doc. By default, debhelper implements
grep-dctrl -w -F Depends,Recommends -s Source "python-$module"
/var/lib/apt/lists/*_debian_dists_sid_main_binary-amd64_Packages ;
grep-dctrl -w -s Package "python-$module"
/var/lib/apt/lists/*_debian_dists_sid_main_source_Sources
where python-$module is the *binary* package name.
This finds r
Some Python 2 packages have circular (build-)dependencies, making it
impossible to remove them one at a time without breaking anything.
One such cycle is seaborn, sphinx-gallery and matplotlib2 (#940873); I
have not attempted to systematically check for them.
How should these be dealt with?
[Summary of previous messages: I noted that packages with circular
dependencies can't be removed one at a time without breakage. Replies
were to remove multiple packages at once if necessary, but ask first if
other maintainers' packages are involved.]
I have now checked what cycles we have:
Simon McVittie wrote:
You've listed dbus-python as being part of this cycle, but [it probably
shouldn't be]
Perhaps some of the blocks have been added the wrong way round?
Or perhaps the script is imperfectly guessing which binaries are Python
2? e.g. matplotlib is listed even though it's al
Sandro Tosi wrote:
do we really want to remove from testing (and subsequently from
debian, as mentioned below) if it both has a py2 and a py3k package?
should we limit this to py2-ONLY packages?
Not the whole source package, but we do want to remove the py2 binary.
Maybe there should be two ve
This had a bug: packages with source name = binary name don't have a
Source: field in the binary Packages file, which makes grep-dctrl skip
them when asked to output the Source field.
Fixed version:
grep-dctrl -w -F Pre-Depends,Depends,Recommends -s Package
"python-$module"
/var/lib/apt/list
What should be done with modules where Python 3.8 compatibility requires
moving to a new upstream release that doesn't support Python 2, but the
Python 2 package still has dependencies (so can't be removed yet under
existing rules)?
- Split them into two source packages with different upstream
On 26/10/2019 22:50, Matthias Klose wrote:
Ubuntu already dropped python-pandas, I wasn't involved with that.
This seems to have been done by the "let things break" approach that
isn't allowed in Debian, e.g. they can no longer build python-matplotlib:
https://bugs.debian.org/cgi-bin/bugreport.
Detailed discussion of pandas has moved to #931557 / debian-science.
Summary:
- python-pandas removal looks feasible, but there is one item that needs
ftpmaster or release team authorization: either let pypubsub out of NEW
(preferred), or give us permission to break tnseq-transit.
- 0.23 -> 0
Would it be possible to satisfy both groups by having an option on DDPO
and similar listing tools for "only show team-as-Maintainer packages" vs
"also show team-as-Uploader packages"?
i.e. making it convenient for people to use either of these definitions
of "in the team" as they prefer?
By itself, removing those dependencies reduces the big tangle [0] from
148 packages to 141, the freed ones being: ipywidgets pyqt5 pep8
autopep8 xcffib xlwt cairocffi. (Note that "not in a tangle" means "no
*circular* dependencies", *not* "leaf / can be removed immediately".)
There may also b
I think that just means "numpy hasn't yet been rebuilt for Python 3.8".
(In Python modules that include a C extension, the .py files are shared
but the C part is compiled separately for each Python version.)
As there are ~500 modules requiring such a rebuild
(https://release.debian.org/transit
There are a few other autopkgtest regressions with scipy 1.3, though I
don't know if they're the reason:
https://release.debian.org/britney/pseudo-excuses-experimental.html
Matthias Klose wrote:
On 2/3/20 8:22 PM, Simon McVittie wrote: >> Meanwhile, multiple packages seem to FTBFS on s390x with the new
libgcc_s
(I've just opened the bug for that, so no bug number known yet), which is
going to limit the ability to get things into testing.
please retry your packag
On 16/03/2020 06:28, Sandro Tosi wrote:
Hey Rebecca, do you have an updated list of these cycles?
Warning: this is based on open py2removal bugs, *not* actual package
relationships.
2 crossfire crossfire-maps
2 sugar sugar-pippy-activity
2 rabbyt snowballz
4 python-pysnmp4 pysmi python-pysnm
This warning was added to Lintian today, after being requested in
#958182. It appears on thousands of packages:
https://lintian.debian.org/tags/mailing-list-obsolete-in-debian-infrastructure.html
After build-testing about half of the reverse dependencies, failures
that look new-pandas-related are cfgrib #1000726, joypy #1000727,
python-skbio #1000752, and maybe hyperspy (not filed yet).
python-skbio and hyperspy already FTBFS for unrelated reasons (but fail
more tests with new pandas),
The statsmodels in unstable (though not testing) is already built
against sphinx 4.3, but this sounds like it might affect other packages.
Is that likely, and if so, what should we do about it?
(Background: the pandas + dask transition broke dask.distributed and it
was hence removed from testing; I didn't notice at the time that if we
don't get it back in we lose Spyder.)
On 05/02/2023 21:44, Rebecca N. Palmer wrote:
I currently have this in a state where it sometimes su
I agree that xfailing the tests *may* be a reasonable solution. I'm
only saying that it should be done by someone with more idea than me of
whether these particular tests are important, because blindly xfailing
everything that fails is effectively not having tests.
If we do choose that approa
I don't consider the lack of .xls in pandas worth a freeze exception,
but consider it reasonable for others to disagree with that.
As noted in the bug, there are some (possibly not-technically-valid)
.xlsx files that xlrd 1 can open but openpyxl can't - _pandas_ won't be
able to open those eit
Package: python3-pandas
Version: 2.0.3+dfsg-1
Control: notfound -1 1.5.3+dfsg-4
Control: block 1043240 by -1
python3-pip and similar Python tools usually count system python3-X as
satisfying Python dependencies on X. Hence, upstream build scripts that
attempt to pip install X can usually work
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?
These are broken by pandas 2.x and have a possible (but un
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
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 d
I (rnpalmer-guest) have already contributed to at least ~10 team
packages [0] (often to unblock pandas[1] transitions/uploads), and this
would be a simpler process if I was in the team.
I have read and accept
https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst
[0
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Please upload dateparser (Salsa HEAD =
commit e0f089a654e1ec1d576ed395695e6fb37d696b5e ).
See #1084190 for details.
-BEGIN PGP SIGNATURE-
iQIzBAEBCgAdFiEEZ8sxEAXE7b4yF1MI3uUNDVZ+omYFAmcWyCIACgkQ3uUNDVZ+
omZguQ//Y4nL4lOqX4c1lIKZ7H5as7PIxlaul
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Please upload pydata-sphinx-theme (Salsa HEAD =
commit cf8953146fca5d5c733c08902f2d4294cd3c132b ).
See #1084781 for details.
-BEGIN PGP SIGNATURE-
iQIzBAEBCgAdFiEEZ8sxEAXE7b4yF1MI3uUNDVZ+omYFAmcWyBYACgkQ3uUNDVZ+
omaOCxAAjkomA4G/dfQ8aqItzUNC
33 matches
Mail list logo
