Bug#1071455: python-html-sanitizer: python3-lxml-html-clean is now a separate package
Package: python-html-sanitizer Version: 2.2-1 lxml.html.clean has been moved from python3-lxml to a new package python3-lxml-html-clean (as discussed in https://bugs.launchpad.net/lxml/+bug/1958539). This package uses lxml.html.clean but only declares a relationship on python3-lxml. I don't know how central the functionality that requires lxml.html.clean is, and hence whether Depends, Recommends or Suggests is appropriate. In the longer term, if you are using lxml.html.clean for security against code injection, be aware that it is not a very secure approach. lxml upstream recommend moving to something stronger e.g. python3-bleach or nh3.
Bug#1071454: html-text: python3-lxml-html-clean is now a separate package
Package: html-text Version: 0.5.2-2 lxml.html.clean has been moved from python3-lxml to a new package python3-lxml-html-clean (as discussed in https://bugs.launchpad.net/lxml/+bug/1958539). This package uses lxml.html.clean but only declares a relationship on python3-lxml. I don't know how central the functionality that requires lxml.html.clean is, and hence whether Depends, Recommends or Suggests is appropriate. In the longer term, if you are using lxml.html.clean for security against code injection, be aware that it is not a very secure approach. lxml upstream recommend moving to something stronger e.g. python3-bleach or nh3.
Bug#1071453: napari: python3-lxml-html-clean is now a separate package
Source: napari Version: 0.5.0~a1-6 lxml.html.clean has been moved from python3-lxml to a new package python3-lxml-html-clean (as discussed in https://bugs.launchpad.net/lxml/+bug/1958539). This package uses lxml.html.clean but only declares a relationship on python3-lxml. I don't know how central the functionality that requires lxml.html.clean is, and hence whether Depends, Recommends or Suggests is appropriate. In the longer term, if you are using lxml.html.clean for security against code injection, be aware that it is not a very secure approach. lxml upstream recommend moving to something stronger e.g. python3-bleach or nh3.
Bug#1071438: uscan: no longer finds tarballs hosted on gitlab
Package: devscripts Version: 2.23.4+deb12u1 (locally; also occurs at https://qa.debian.org/cgi-bin/watch, I don't know what version that uses) Gitlab (probably all up-to-date instances, not just gitlab.com) now places its tarball download links inside Javascript, which breaks simple d/watch files: Uscan failed: In debian/watch no matching files for watch line https://foss.heptapod.net/openpyxl/openpyxl/-/tags .*/openpyxl-(?:[-_]?v?(\d[\-+\.:\~\da-zA-Z]*)).tar.gz A fix is to use the downloadurlmangle option, i.e. this line in d/watch (based on David Steele's solution for git*hub* in #1019696): opts="downloadurlmangle=s#tags/([0-9.]+)#archive/\1/openpyxl-\1.tar.gz#g" \ https://foss.heptapod.net/openpyxl/openpyxl/-/tags .*/tags/@ANY_VERSION@ Switching to the git repository instead of the tarball (mode=git) would probably also work, but I haven't tried that. Codesearch suggests that the following packages are currently trying to use such a watch file (this search is imperfect, but checking a few suggests that at least most of them are broken): qemu-web-desktop emerald kissplice libdecor-0 pmccabe hyphen-indic xdrawchem osmctools appmenu-registrar libqtdbustest simple-ccsm ruby-spamcheck python-duniterpy python-procset libpappsomspp cif2hkl django-iconify python-stem pandoc-filter-diagram libvdpau node-puka libei librtpi coq-interval sane-frontends libqtdbusmock taurus gitlab-ci-multi-runner tone-generator linaro-bcb-util qoi simple-revision-control dogtail alberta medialibrary gitlab-agent coq-stdpp libaccounts-glib openpyxl pd-hexloader python-libevdev librist blueprint-compiler onedriver pd-comport sxiv-el nheko pd-zexy promod3 fusion-icon vdpauinfo librem-ec-acpi compiz-plugins-experimental migrationtools btrfs-assistant sfcgal beads cppgir emerald-themes eztrace-contrib make-dynpart-mappings caps2esc lib2geom i2masschroq last-align vala-panel-appmenu compiz-boxmenu camlimages coquelicot qcumber lmdb xdg-utils glab mirage switcheroo-control libstringprep-java ruby-gollum-rugged-adapter libsignon-glib colored carburetor golang-gitlab-golang-commonmark-puny kasts compizconfig-python rust-roadmap fonts-atarist pan tractor lcalc armagetronad eclipse-titan lsb-release-minimal powersupply-gtk libudfread eztrace go-sendxmpp roger-router ruby-six libqrtr-glib syncevolution gmsh
Bug#1070359: tabulate 0.9.0
Control: tags -1 patch My 0.9 package (see above link) passed reverse dependencies testing: https://launchpad.net/~rebecca-palmer/+archive/ubuntu/tabulate0p9 Note that this is only a build test, not autopkgtest, and azure-cli, pymatgen and python-django-ca are excluded as they do not exist in Ubuntu. Hence, I now do recommend uploading it.
Bug#1070359: tabulate 0.9.0
I have an 0.9.0 package that builds, but I haven't finished testing it yet, so do _not_ recommend uploading it right now: https://salsa.debian.org/rnpalmer-guest/python-tabulate/-/tree/fix1070359?ref_type=heads
Bug#1070360: new upstream release
On 15/05/2024 23:49, Alexandre Detiste wrote: The only change code-wise is the patch that was already in 1.3.5+ds1-3 Having now had time to look, I agree. This implies that changing the minimum bottleneck version in pandas would work. However, as bottleneck also has other reverse dependencies, updating bottleneck probably scales better in the long run. Some of this duplicates what you've already done (sorry), but you may still want the salsa-ci.yml and d/copyright: https://salsa.debian.org/python-team/packages/bottleneck/-/merge_requests/4
Bug#1071123: influxdb-python: FTBFS with pandas 2.2
Control: tags -1 patch https://salsa.debian.org/python-team/packages/influxdb-python/-/merge_requests/2 Not *obviously* known upstream.
Bug#1069792: pandas 2.2
Control: affects 1070359 src:camelot-py Control: affects 1070360 src:glueviz As expected from the version number, this looks easier than the last one: there are only 4 remaining failures and they all look easy to fix. These are: augur (#1071122) camelot-py (tabulate too old #1070359) glueviz (bottleneck too old #1070360) influxdb-python (#1071123) statsmodels 0.14.1 (Ubuntu, due to LP#2064928) fails but 0.14.2 (Debian) doesn't. Build test results: https://launchpad.net/~rebecca-palmer/+archive/ubuntu/pandas2p2/+builds?build_text=_state=failed Autopkgtest results: https://qa.debian.org/excuses.php?experimental=1=pandas Already broken but probably not worse with pandas 2.2: domdf-python-tools python-cooler (dask #1068422) python-workalender (#1060939, package removed from Debian) Not fully tested as already broken: dask.distributed (dask #1068422) igdiscover pychopper pydevd pytorch-geometric qiime Not build-tested as already BD-Uninstallable: python-fastparquet q2-* spopt umap-learn Not build-tested as not in Ubuntu: epigrass intake keras poliastro pymatgen python-cogent python-loompy spaghetti tpot xraylarch
Bug#1071123: influxdb-python: FTBFS with pandas 2.2
Source: influxdb-python Version: 5.3.1-6 Severity: wishlist Control: block 1069792 by -1 This package's tests fail with pandas 2.2, currently in experimental. https://launchpadlibrarian.net/728496862/buildlog_ubuntu-oracular-amd64.influxdb-python_5.3.1-6_BUILDING.txt.gz == ERROR: Test write points from df w/escaped tag in TestDataFrameClient. -- Traceback (most recent call last): File "/<>/influxdb/tests/dataframe_client_test.py", line 338, in test_write_points_from_dataframe_with_tag_escaped index=pd.period_range(now, freq='H', periods=5), ^ File "/usr/lib/python3/dist-packages/pandas/core/indexes/period.py", line 611, in period_range data, freq = PeriodArray._generate_range(start, end, periods, freq) ^^ File "/usr/lib/python3/dist-packages/pandas/core/arrays/period.py", line 340, in _generate_range freq = Period._maybe_convert_freq(freq) File "pandas/_libs/tslibs/period.pyx", line 1765, in pandas._libs.tslibs.period._Period._maybe_convert_freq File "pandas/_libs/tslibs/offsets.pyx", line 4924, in pandas._libs.tslibs.offsets.to_offset FutureWarning: 'H' is deprecated and will be removed in a future version, please use 'h' instead. --
Bug#1071122: augur: FTBFS with pandas 2.2
Source: augur Version: 24.3.0-1 Severity: wishlist Control: block 1069792 by -1 This package's tests fail with pandas 2.2, currently in experimental. https://ci.debian.net/packages/a/augur/unstable/amd64/46551367/ https://launchpadlibrarian.net/728496766/buildlog_ubuntu-oracular-amd64.augur_24.3.0-1_BUILDING.txt.gz === FAILURES === ___ TestParse.test_fix_dates ___ self = capsys = <_pytest.capture.CaptureFixture object at 0x7fe8582e7ce0> def test_fix_dates(self, capsys): full_date = "4-5-2020" > assert parse.fix_dates(full_date) == "2020-05-04" tests/test_parse.py:14: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ d = '4-5-2020', dayfirst = True def fix_dates(d, dayfirst=True): ''' attempt to parse a date string using pandas date parser. If ambiguous, the argument 'dayfirst' determines whether month or day is assumed to be the first field. Incomplete dates will be padded with XX. On failure to parse the date, the function will return the input. ''' try: > from pandas.core.tools.datetimes import parsing E ImportError: cannot import name 'parsing' from 'pandas.core.tools.datetimes' (/usr/lib/python3/dist-packages/pandas/core/tools/datetimes.py) augur/parse.py:34: ImportError
Bug#1069792: pandas 2.2
I now have a 2.2 package that builds (but installs test_stata.dta somewhere it shouldn't - reminder to self: fix that before uploading to unstable).
Bug#1070361: blosc: too old for pandas
Package: python3-blosc Version: 1.11.1+ds1-2 Severity: wishlist Control: affects -1 python3-pandas Some pandas functionality is currently unavailable because Debian blosc is too old; it requires >= 1.21.
Bug#1070360: bottleneck: too old for pandas 2.2
Package: python3-bottleneck Version: 1.3.5+ds1-3 Severity: wishlist Control: block 1069792 by -1 (Not actually a hard block as it's not a hard Depends, but I'd prefer not to lose the functionality that does require it.) I would like to upgrade pandas to 2.2.x, but this will only use bottleneck if it is >= 1.3.6. (I don't know whether pandas has an actual reason to care about the micro version, such as a relevant bug fix, or just arbitrarily chose minimum versions that were current as of X time before the pandas release. However, keeping packages reasonably up to date is also more generally a good thing.)
Bug#1068422: can't import dask.dataframe - TypeError: descriptor '__call__' for 'type' objects doesn't apply to a 'property' object
Control: forwarded -1 https://github.com/dask/dask/pull/11035 Control: tags -1 fixed-upstream patch Thanks and probably yes (but I haven't tested that fix myself), as while it didn't happen in 3.11.8, it *does* happen in 3.11.9: https://ci.debian.net/packages/d/dask/unstable/amd64/46185892/
Bug#1070359: tabulate: too old for pandas 2.2
Package: python3-tabulate Version: 0.8.10-1 Severity: wishlist Control: block 1069792 by -1 (Not actually a hard block as it's not a hard Depends, but I'd prefer not to lose the functionality that does require it.) I would like to upgrade pandas to 2.2.x, but this will only use tabulate if it is >= 0.9. Caution - I have _not_ checked whether upgrading tabulate would break any other packages that use it.
Bug#1069792: transition: pandas 2.1 -> 2.2
Package: python3-pandas Version: 2.1.4+dfsg-7 Severity: wishlist Upstream have released pandas 2.2. (Filing this now to have a bug number - I haven't actually uploaded to experimental yet.) Reverse dependencies to be tested: abinit astropy augur azure-kusto-python bmtk bqplot busco camelot-py cfgrib changeo cnvkit dask dask.distributed debian-astro debian-pan debian-science dials dioptas dipy domdf-python-tools drms dxchange dyda edlio emperor epigrass esda extra-data flox folium glueviz guidata harmonypy hdmf hickle igdiscover influxdb-python intake ipython jitterdebugger joypy jsonpickle keras libpysal lmfit-py loki-ecmwf macsyfinder mapclassify matplotlib mcaller mdtraj metaphlan metpy metview-python mirtop mlpack monty nanofilt napari nbsphinx openpyxl optuna orange3 osmnx pairtools parmed partd patsy pdb2pqr pint-xarray plasmidid pointpats poliastro poretools presto psychopy pybel pychopper pycoqc pydevd pyensembl pymatgen pymecavideo pynwb pyodc pyranges pyreadstat pyrle pytest-regressions python-aioinflux python-airr python-altair python-anndata python-apptools python-bioframe python-biom-format python-cgelib python-clevercsv python-cobra python-cogent python-cooler python-datacache python-django-pint python-fastparquet python-feather-format python-fluids python-geopandas python-geotiepoints python-gsd python-gtfparse python-hypothesis python-igraph python-influxdb-client python-iow python-loompy python-lsp-server python-nanoget python-nanomath python-ncls python-numpy-groupies python-pandas-flavor python-parsl python-pauvre python-peakutils python-pomegranate python-pyani python-pybedtools python-pymeasure python-pyomop python-pyproj python-rdata python-skbio python-streamz python-tablib python-throttler python-treetime python-ulmo python-upsetplot python-vega-datasets python-workalendar python-xarray python-xrt pytorch-geometric pyxnat q2-cutadapt q2-demux q2-diversity-lib q2-emperor q2-metadata q2-quality-control q2-quality-filter q2-taxa q2-types q2templates qiime r-bioc-mofa rapidfuzz rdkit recan refnx rickslab-gpu-utils sarsen scikit-learn scikit-rf seaborn sentineldl sherlock skimage sklearn-pandas skorch skyfield slm snakemake sorted-nearest spaghetti spopt spyder spyder-kernels statsmodels stimfit sunpy topplot tpot tqdm traittypes umap-learn umis xarray-safe-s1 xarray-sentinel xpore xraylarch yanagiba
Bug#1069608: topplot: missing test-depends on python3-all
Source: topplot Version: 0.2.2+repack-1 Tags: patch Severity: serious Justification: blocks testing migration of other packages topplot tries to run its autopkgtest in all versions of Python (which is good), but does not test-depend on all those versions of Python. This previously worked because numpy depended on them. However, this has now been removed (see #945824), causing topplot's autopkgtests to fail. Adding python3-all to the Depends in debian/*tests*/control should fix this bug, but I have not actually tested this.
Bug#1068422: possibly caused by python 3.12.3 Re: Bug#1068422: can't import dask.dataframe - TypeError: descriptor '__call__' for 'type' objects doesn't apply to a 'property' object
This bug is not *obviously* known to dask upstream, but their CI is failing and I haven't checked why. It happens only in Python 3.12, not 3.11: https://ci.debian.net/packages/d/dask/unstable/amd64/45013666/ and still doesn't happen in testing, but does happen in mostly-testing with src:python3-defaults,src:db5.3,src:keras,src:nodejs,src:openssl,src:python3-stdlib-extensions,src:python3.11,src:python3.12,src:readline,src:udisks2,src:viagee from unstable: https://ci.debian.net/packages/d/dask/testing/amd64/45564690/ This suggests that the trigger may be the upgrade of Python itself (3.12.2-1 in testing -> 3.12.3-1 in unstable). *Possibly* related items from the upstream Python changelog: https://github.com/python/cpython/issues/101293 https://github.com/python/cpython/issues/117110
Bug#1068349: nbsphinx/nbconvert broken by lxml 5.2: lxml.html.clean
Control: unblock 1068104 by -1 Control: unblock 1068104 by 1068422 To avoid being blocked by this bug, the pandas version I just uploaded temporarily disables the documentation. This is also an option for any other affected packages that urgently need to be uploaded. (I don't know whether the other two listed Blocks/Affects are that urgent.)
Bug#1068422: can't import dask.dataframe - TypeError: descriptor '__call__' for 'type' objects doesn't apply to a 'property' object
Package: python3-dask Version: 2023.12.1+dfsg-2 Severity: serious Control: affects -1 src:pandas Control: block 1068104 by -1 Importing dask.dataframe currently fails with the error TypeError: descriptor '__call__' for 'type' objects doesn't apply to a 'property' object amd64 https://salsa.debian.org/science-team/pandas/-/jobs/5543041 https://ci.debian.net/packages/d/dask/unstable/arm64/44706021/ i386 https://salsa.debian.org/science-team/pandas/-/jobs/5543042 This appears to have started recently, as this log from 2024-03-31 doesn't have it, and to occur in unstable but not testing: https://tests.reproducible-builds.org/debian/rb-pkg/unstable/armhf/pandas.html As the version of dask has not changed in this time, the cause is probably a change in some other package; I don't know which one.
Bug#1068349: nbsphinx/nbconvert broken by lxml 5.2: lxml.html.clean
Control: tags -1 patch Control: severity -1 serious (probably makes nbconvert/nbsphinx unusable) xml-html-clean is in NEWhttps://ftp-master.debian.org/new/lxml-html-clean_0.1.0-1.html Thanks - that and adding it to the Depends of python3-nbconvert should fix this bug. From codesearch, other packages that may need such a Depends are html-text, extruct, python-html-sanitizer, napari, readability, calibre, python-webob.
Bug#1068349: nbsphinx/nbconvert broken by lxml 5.2: lxml.html.clean
Package: python3-nbconvert,python3-lxml Version: 6.5.3-4,5.2.0-1 Control: affects -1 src:pandas Control: affects -1 python3-nbsphinx Control: block 1068104 by -1 The pandas documentation fails to build in current unstable with: Running Sphinx v7.2.6 nbconvert not installed. Skipping notebooks. Extension error: Could not import extension nbsphinx (exception: lxml.html.clean module is now a separate project lxml_html_clean. Install lxml[html_clean] or lxml_html_clean directly.) Full log: https://salsa.debian.org/science-team/pandas/-/jobs/5538806 This probably makes nbconvert and nbsphinx fail to import at all, and started when lxml was upgraded to 5.2, but I haven't actually tested either of those: https://sources.debian.org/src/nbconvert/6.5.3-4/nbconvert/exporters/templateexporter.py/?hl=25#L25 https://sources.debian.org/src/lxml/5.2.0-1/PKG-INFO/?hl=83#L83 The obvious fix would be to package lxml_html_clean.
Bug#1068104: pandas: FTBFS on 32-bit architectures with -D_TIME_BITS=64
Thanks - I plan to look at this tomorrow.
Bug#1063959: pandas and pytest 8
Control: reopen -1 Control: tags -1 pending Control: tags 1066801 pending Control: tags 1064384 pending Sorry, that wasn't actually a fix, but what's now in Salsa should be.
Bug#1066801: pandas: FTBFS: /usr/lib/python3/dist-packages/dateutil/zoneinfo/__init__.py:26: UserWarning: I/O error(2): No such file or directory
Control: retitle -1 pandas: test-failing warning with new xarray This is a warning being treated as an error, but the one in test_to_xarray (probably due to the new version of xarray), not the zoneinfo one. This is a FutureWarning, so it should be OK to *use* the current pandas with the new xarray. The same warning happens in autopkgtest but isn't treated as an error there, so didn't block the new xarray. I intend to try fixing this later.
Bug#1064368: python-xarray: intermittent segfault in test_open_mfdataset_manyfiles[netcdf4-20-True-*-5]
Control: forwarded -1 https://github.com/pydata/xarray/issues/7079 (actually found independently) The above upstream report suggests that this is because netcdf-python is no longer thread-safe. The 3 random-autopkgtest-fail bugs (this, #1064326 and #1064370) together seem to be more common in pandas 2. It's possible that some of them are actually the same underlying bug.
Bug#1043240: transition: pandas 1.5 -> 2.1
Remaining blockers for testing migration: - python-ulmo #1044057: has a patch, please upload - pydevd #1063274: unclear whether my patch breaks something else, please leave alone for now Status unclear: - python-xarray: autopkgtest has failed 3 times, but all 3 are (different) failures that have occurred without pandas 2, apparently at random - q2-*: autopkgtest fails in "fixed" versions, but possibly because they're not all being tested together
Bug#1063274: pydevd: autopkgtest-failing warning with pandas 2.1
Is that a yes to>> Does just the patch (not the new upstream) also break debugpy?or have you not tried specifically that? (I'm looking for a quick fix for the autopkgtest fail to unblock the pandas 2.x transition. I agree that upgrading to a new upstream is a good idea in the long run.) the bytecode version in pydevd is behind that in Debian, This is currently true (Debian has python3-bytecode 0.15.1, upstream pydevd 2.10.0 vendors 0.13.0.dev), but if it were a problem I'd expect it to mean that pydevd/debugpy were *already* buggy, not that my patch makes them worse.
Bug#1064370: python-xarray: intermittent fail in TestOpenMFDatasetWithDataVarsAndCoordsKw
Package: python3-xarray Version: 2023.12.0-3 The xarray autopkgtest sometimes (~20% of the time) fails with RuntimeError: NetCDF: Not a valid ID in tests/test_backends.py::TestOpenMFDatasetWithDataVarsAndCoordsKw Unlike the other random failures, this seems to be amd64-specific. Exactly which test case fails varies: test_open_mfdataset_does_same_as_concat[left-different-by_coords-None] https://ci.debian.net/packages/p/python-xarray/testing/amd64/43085145/ test_open_mfdataset_dataset_combine_attrs[drop] https://ci.debian.net/packages/p/python-xarray/testing/amd64/42861417/ test_open_mfdataset_does_same_as_concat[right-minimal-nested-t] + test_open_mfdataset_does_same_as_concat[right-minimal-by_coords-None] https://ci.debian.net/packages/p/python-xarray/testing/amd64/42753466/ test_open_mfdataset_does_same_as_concat[outer-minimal-by_coords-None] https://ci.debian.net/packages/p/python-xarray/testing/amd64/43021198/
Bug#1064368: python-xarray: intermittent segfault in test_open_mfdataset_manyfiles[netcdf4-20-True-*-5]
Package: python3-xarray Version: 2023.12.0-3 xarray sometimes (~10% of the time) segfaults in tests/test_backends.py::test_open_mfdataset_manyfiles, usually [netcdf4-20-True-None-5] but sometimes [netcdf4-20-True-5-5]. This has happened in both Python 3.11 and 3.12, and on various architectures: https://ci.debian.net/packages/p/python-xarray/testing/amd64/43068287/ https://ci.debian.net/packages/p/python-xarray/testing/armhf/42545225/ https://ci.debian.net/packages/p/python-xarray/testing/s390x/43076980/ https://ci.debian.net/packages/p/python-xarray/testing/ppc64el/42673240/
Bug#1064326: python-xarray: intermittent hang in test_roundtrip_coordinates
Package: python3-xarray Version: 2023.12.0-3 The xarray autopkgtest sometimes (~10% of the time) hangs in test_roundtrip_coordinates, and hence fails with a timeout. Example failure log (but this is _not_ specific to pandas 2.x): https://ci.debian.net/packages/p/python-xarray/testing/amd64/43065828/
Bug#1063274: pydevd: autopkgtest-failing warning with pandas 2.1
Thank you for caring about not breaking other packages, and yes, that's a good reason to not upload that new upstream for now. Does just the patch (not the new upstream) also break debugpy? (It shouldn't be able to, since it only touches test code.)
Bug#1063274: pydevd: autopkgtest-failing warning with pandas 2.1
This has been merged but not uploaded - is there a reason it shouldn't be, or have you just not had time?
Bug#1044057: python-ulmo and pandas 2
Control: tags -1 patch
This should fix this (and as the filename suggests, also re-adds spme
older fixes that seem to have been dropped by mistake between -1.1 and
-2), but has not been tested: the relevant tests aren't run by default
and there vaguely might be legal issues around ulmo's tests.Description: Don't fail on malformed or changed test data
CDEC has malformed lines that pandas 1.4+ errors out on
(I'm not sure why earlier pandas didn't do the same);
GHCN has simply changed at the source.
Author: Rebecca N. Palmer (but upstream independently came up with the on_bad_lines part)
Bug-Debian: https://bugs.debian.org/1017573 https://bugs.debian.org/1044057
Forwarded: partly no, partly not-needed, partly https://github.com/ulmo-dev/ulmo/pull/214
--- a/test/cdec_historical_test.py
+++ b/test/cdec_historical_test.py
@@ -9,7 +9,7 @@ def test_get_stations():
stations_file = 'cdec/historical/all_stations.csv'
with test_util.mocked_urls(stations_file):
stations = ulmo.cdec.historical.get_stations()
-assert 2000 < len(stations)
+assert 1900 < len(stations)
assert u'PRA' in stations.index
--- a/test/ghcn_daily_test.py
+++ b/test/ghcn_daily_test.py
@@ -10,12 +10,12 @@ import test_util
test_stations = [
{
'country': 'US',
-'elevation': 286.5,
+'elevation': 325.8,
'gsn_flag': 'GSN',
'hcn_flag': 'HCN',
'id': 'USW3870',
-'latitude': 34.8831,
-'longitude': -82.2203,
+'latitude': 34.8833,
+'longitude': -82.2197,
'name': 'GREER',
'network': 'W',
'network_id': '3870',
--- a/ulmo/cdec/historical/core.py
+++ b/ulmo/cdec/historical/core.py
@@ -74,9 +74,9 @@ def get_stations():
# I haven't found a better list of stations, seems pretty janky
# to just have them in a file, and not sure if/when it is updated.
url = 'http://cdec.water.ca.gov/misc/all_stations.csv'
-# the csv is malformed, so some rows think there are 7 fields
-col_names = ['id','meta_url','name','num','lat','lon','junk']
-df = pd.read_csv(url, names=col_names, header=None, quotechar="'",index_col=0)
+# the csv is malformed, so some rows think there are 7-8 fields
+col_names = ['id','meta_url','name','num','lat','lon']
+df = pd.read_csv(url, names=col_names, header=None, quotechar="'",index_col=0,on_bad_lines='skip')
return df
@@ -170,7 +170,7 @@ def get_station_sensors(station_ids=None, sensor_ids=None, resolutions=None):
sensor_list.columns = ['sensor_id', 'variable', 'resolution','timerange']
except:
sensor_list.columns = ['variable', 'sensor_id', 'resolution', 'varcode', 'method', 'timerange']
-sensor_list[['variable', 'units']] = sensor_list.variable.str.split(',', 1, expand=True)
+sensor_list[['variable', 'units']] = sensor_list.variable.str.split(',', n=1, expand=True)
sensor_list.resolution = sensor_list.resolution.str.strip('()')
station_sensors[station_id] = _limit_sensor_list(sensor_list, sensor_ids, resolutions)
Bug#1044071: feather and pandas 2.0
Control: tags -1 patch It does sometimes happen that fixing "can't import the tests" reveals "the tests fail". Fixed in the Salsa merge request.
Bug#1063274: pandas 2.x fixes
Control: tags -1 patch See the Salsa merge request.
Bug#1063273: seaborn: autopkgtest fail on i386 - probable rounding error
Control: tags -1 pending This appears to be fixed in Salsa (before I reported it) - is there any reason not to upload this now?
Bug#1063435: geopandas: test fail with pandas 2.x on 32 bit - int32 vs int64 mismatch
Package: python3-geopandas Version: 0.14.3-1 Severity: serious Control: block 1043240 by -1 In pandas 2.x (now in unstable), there are a few places where geopandas uses native-size int but the plain pandas objects used as test references are always int64, failing the test: https://ci.debian.net/packages/p/python-geopandas/testing/armhf/42777226/ Probably a reasonable response is to ignore this (check_index_type=False/check_dtype=False) but I haven't looked carefully.
Bug#1063325: mdanalysis: random autopkgtest hangs
Package: python3-mdanalysis Version: 2.5.0+dfsg1-2 The autopkgtest sometimes hangs at the 85% point, causing it to time out and fail. (This is probably a hang and not just slowness, because when it doesn't fail, this test doesn't take anywhere near that long.) https://ci.debian.net/packages/m/mdanalysis/testing/i386/42756824/ https://ci.debian.net/packages/m/mdanalysis/testing/armel/42726120/ https://ci.debian.net/packages/m/mdanalysis/testing/amd64/42461650/
Bug#1043240: transition: pandas 1.5 -> 2.1
Control: block -1 by 1063274 Thank you for uploading those fixes. Note to self: pandas will need another upload, to remove the numba B-D and skip those tests (because numba is not in testing), and do something about 'ignoredtests' being slow enough to time out in i386 and arm64.
Bug#1063274: pydevd: autopkgtest-failing warning with pandas 2.1
Source: pydevd Severity: serious Tags: patch A pydevd test uses DataFrame.applymap(), and fails because this now raises a FutureWarning. Replacing it with DataFrame.map() as this message suggests would probably fix it.
Bug#1063273: seaborn: autopkgtest fail on i386 - probable rounding error
Package: python3-seaborn Version: 0.13.2-1 Severity: serious seaborn's autopkgtest failed on i386, with differences small enough that they are plausibly rounding error (i.e. should be ignored, by using *almost_equal instead of exact comparisons), but I haven't looked carefully.
Bug#1044073: Sorry Re: python-altair and pandas 2.0
On 03/02/2024 22:01, Andreas Tille wrote: The point I was making in my mail was that I had trouble running the tests in **latest** upstream version (5.2.0). Sorry - I'd misread your previous message as you having tried 5.x, found that it didn't work due to the missing dependency, and decided to try 4.x with tests skipped instead. I think we should strive for latest upstream in general Agreed, assuming that doing so doesn't break things.
Bug#1061761: snakemake issues with Python 3.12
It looks like this is at least two issues: - Tests mix tabs and spaces, which is no longer allowed = upstream 2459 - Assumes f-strings are not tokenized, which they now are = upstream 2485/2588/2649 Fix in progress on the debian-v7 branch. (The main branch has 8.x, which doesn't work due to missing dependencies.)
Bug#1044073: python-altair and pandas 2.0
Please don't skip/xfail tests - my suggestion above is an actual fix: https://salsa.debian.org/rnpalmer-guest/python-altair/-/tree/fix1044073?ref_type=heads (In a fork because, despite its description, this is not actually a debian-science package. The Salsa CI "fail" is because the *old* version is uninstallable due to Breaks: in pandas and the piuparts upgrade test counts this as a fail.)
Bug#1044076: influxdb-python and pandas 2.1
My fixes are pushed to Salsa, but they're in a fork because this isn't a debian-science package: https://salsa.debian.org/rnpalmer-guest/influxdb-python
Bug#1043240: transition: pandas 1.5 -> 2.1 - please upload fixes
seaborn has now been fixed. I intend to look at python-altair later.
Bug#1044076: influxdb-python and pandas 2.1
Note that this uncertainty is only around whether this is a complete fix - even in the case where it's not, it *wouldn't* be actively worse than doing nothing, though it would be hiding the problem.
Bug#1043240: transition: pandas 1.5 -> 2.1 - please upload fixes
I intend to upload pandas 2.x to unstable soon. These packages have a patch in their bug - please upload them (I'm a DM, I can't do that), or if you think this patch won't work or isn't a good idea, tell me why: dials influxdb-python python-altair python-feather-format seaborn tqdm In particular, I'd like the seaborn fix uploaded before pandas, so I can set Breaks for it. (The pandas documentation build-depends on seaborn.)
Bug#1044076: influxdb-python and pandas 2.1
Some looking through the code suggests that the precision is user-set and hence constant within a single query, and hence that this fix is OK, but I'm not entirely certain of that. There are ways to make pandas 2.x accept mixed time format, but I think they're 2.x _only_ and/or slow.
Bug#1053946: tqdm and pandas 2.1 / python 3.12
That turned out to be easier than it looked - fixing the easy one also made the others go away. Please upload this: https://salsa.debian.org/rnpalmer-guest/tqdm
Bug#1053946: tqdm and pandas 2.1 / python 3.12
Control: retitle 1058160 tqdm: tests failing/hanging in Python 3.12 That works for #1053946 (pandas 2.x), but #1058160 (python 3.12) is more than a single hanging test, and it's not immediately obvious what should be done. Attempted fix (caution, currently just skips the hanging test) and failure logs: https://salsa.debian.org/rnpalmer-guest/tqdm
Bug#1053945: seaborn: test-failing warning in pandas 2.1
The above by itself wasn't enough, but what I have now pushed to Salsa is. Please upload it.
Bug#1044076: influxdb-python and pandas 2.1
That's not the only problem: some of the tests mix timestamps in slightly different formats (with and without fractional seconds), which is no longer allowed by default: https://pandas.pydata.org/pandas-docs/version/2.1.4/whatsnew/v2.0.0.html#datetimes-are-now-parsed-with-a-consistent-format The fix I currently have at https://salsa.debian.org/rnpalmer-guest/influxdb-python avoids this by changing the test data format, but I don't know enough about influxdb-python to say whether this is something that would come up in actual use.
Bug#1043240: transition: pandas 1.5 -> 2.1
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.) 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.) (Unless pandas 1.5 is preventing the transition, that is.) It isn't.
Bug#1044076: pandas 2.x
What, if anything, blocks the above fix from being applied now? tqdm, influxdb-python and seaborn are the highest-popcon packages broken by pandas 2.x.
Bug#1043240: transition: pandas 1.5 -> 2.1
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. dask, python-skbio and python-upsetplot have been fixed since the previous discussion, but that still leaves the above 25. 6 of these have a known-to-me fix (dials influxdb-python python-altair python-feather-format seaborn tqdm - see their bugs for details). Hence, doing this transition now would involve breaking some reverse dependencies with no known fix, but given the number of packages involved, trying to wait until they're all fixed is rather likely to instead end in pandas 1.5 being broken by a new Python/numpy/etc.
Bug#1044057: python-ulmo: test failure with pandas 2.0
These tests are now skipped in Debian (for unrelated reasons), so this bug is no longer caught by the autopkgtest, but probably does still exist.
Bug#1060374: RM: libgpuarray - RoM; abandoned upstream, RC-buggy
Package: ftp.debian.org User: ftp.debian@packages.debian.org Usertags: remove libgpuarray has been de facto abandoned upstream since 2018, and is unused in Debian since theano was removed (#1042574). It currently has what may or may not be a wrong-answer bug (#1031414), and two broken-by-transition bugs. (The latter two _might_ be easy to fix - I haven't tried because I've already mostly given up on it.) Removal was previously suggested in those bugs, without response.
Bug#1056828: Severity / marking of "uses cython3-legacy" bugs
pandas and statsmodels are currently using cython3-legacy. I left their cython 3.0 bugs open when I made this change, as I do want to actually switch them to cython 3.x at some point. These bugs have now been raised to RC. Is this an intentional attempt to remove cython3-legacy (which seems unlikely as there is no such bug on cython3-legacy itself), or have they been mistaken for packages that still depend on plain cython3 but don't build with cython3 3.x (which would be an active FTBFS and hence RC)? If the second, how should such bugs be marked to make them less confusing? Is removing the usertag enough?
Bug#1058662: pymatgen: slow (sometimes timing out) autopkgtest
Package: python3-pymatgen Version: 2023.06.23+dfsg1-2 This autopkgtest, and particularly test_rotor_search_wrs, is slow enough that it sometimes times out and fails. I think this is varying hardware speed and not a random hang because failure seems to correlate with the earlier tests taking longer. This could be fixed by skipping some slow tests (-k 'not test_rotor_search_wrs'). Alternatively, if these tests are important it _may_ be possible to increase the time limit.
Bug#1058661: dipy: slow (sometimes timing out) autopkgtest
Package: python3-dipy Version: 1.7.0-4 This autopkgtest, and particularly test_reconstruct_rumba, is slow enough that it sometimes times out and fails. I think this is varying hardware speed and not a random hang because failure seems to correlate with the earlier tests taking longer. This could be fixed by skipping some slow tests (-k 'not test_reconstruct_rumba'). Alternatively, if these tests are important it _may_ be possible to increase the time limit.
Bug#1043240: transition: pandas 1.5 -> 2.1
On 10/12/2023 20:16, Julian Gilbey wrote: > [...]I'd be in favour of doing the pandas > transition now, which will allow Cython 3.0 to move into unstable. Cython 3 is already in unstable; pandas is currently using cython-legacy. And yes, my list of packages broken by pandas 2.x is those identified by builds and autopkgtests. On 11/12/2023 17:31, Matthias Klose wrote: On 11.12.23 08:12, Matthias Klose wrote: up to the maintainers. But please wait at least until the current pandas and numpy migrated to testing, e.g. that the autopkg tests of pandas and numpy triggered by python3-defaults pass. I just nmued pyrle and sorted-nearest, having dependencies on cython3-legacy, letting the pyranges autopkg tests fail. Once this succeeds, pandas should be able to migrate. pandas' testing migration is also blocked by its build-dependency on python-xarray, and xarray's on python-sparse and cfgrib. If necessary, pandas can be built without xarray, but this skips some tests and probably adds some error messages to the documentation (the examples are run at build time).
Bug#1055848: cfgrib failing to find eccodes
Control: retitle -1 cfgrib: test failure - can't find eccodes Because we now enforce that build-depends of testing must be in testing, this bug is blocking python-xarray and hence pandas from testing, so is more important than this package's popcon would suggest. I consider it likely that the real bug is in ecmwflibs, specifically this function, but haven't actually tested that: https://sources.debian.org/src/ecmwflibs/2%3A0.5.7-1/ecmwflibs/__init__.py/#L118
Bug#1055847: python-sparse crash on arm64 (and possibly other non-x86)
At least on arm64, this appears to be a crash in a @numba.jit function. Given numba's known issues on non-x86 (e.g. #1033907), this suggests that actually fixing it _may_ not be reasonable. In pandas I don't recommend/build/test-depend on numba on the problem architectures, but python-sparse has a hard Depends on numba so that doesn't appear to be an option here. A potential option is to disable the tests on these architectures and display a warning on import (for an example, see https://salsa.debian.org/science-team/statsmodels/-/commit/a64430166b1e48135c58ec41330e3ce9b2206b46 ).
Bug#1056504: python-sparse in Python 3.12
Control: tags -1 fixed-upstream This was fixed upstream by https://github.com/pydata/sparse/commit/266af7307b5232a37daa1d7659f02faf6a42e46e . It still exists here because debian/patches/fix-test-fails-on-i386.patch effectively reverses that fix, possibly by accident.
Bug#1031414: Proposed RM: libgpuarray - abandoned, RC-buggy
libgpuarray has been de facto abandoned upstream since 2018, and is currently unused in Debian. (Its original user was theano, which was removed in #1042574.) It currently has what may or may not be a wrong-answer bug (#1031414), and two broken-by-transition bugs. (The latter two _might_ be easy to fix - I haven't tried because I've already mostly given up on it.) Hence, I intend to request removal.
Bug#1056828: pandas and Cython 3
Control: block -1 by 1043240 Control: tags -1 fixed-upstream fixed-in-experimental pandas 2.1.4 in experimental uses Cython 3, without known issues. We are currently discussing (in #1043240) whether to move that version to unstable, given that it would cause other breakage.
Bug#1043240: transition: pandas 1.5 -> 2.1
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 untested) fix in their bug - please test and apply it: dask(?) dials influxdb-python* python-altair python-feather-format python-upsetplot seaborn tqdm* (* = this package is currently also broken for a non-pandas reason, probably Python 3.12, that I don't have a fix for) These are broken by pandas 2.x and have no known-to-me fix: 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 Some generic things to try are pandas.util.testing -> pandas.testing, .iteritems() -> .items(), and if one exists, a more recent upstream version. Is this an acceptable amount of breakage or should we continue to wait? Bear in mind that if we wait too long, we may be forced into it by some transition further up the stack (e.g. a future Python or numpy) that breaks pandas 1.x. Build logs: https://launchpad.net/~rebecca-palmer/+archive/ubuntu/pandas2p1/+builds?build_text=_state=failed https://launchpad.net/~rebecca-palmer/+archive/ubuntu/pandas2p1n/+builds?build_text=_state=failed (The second is more recent, but includes fewer packages.) Autopkgtest logs: https://qa.debian.org/excuses.php?experimental=1=pandas (Because of the Python 3.12 transition, this may currently be wrong about what is a regression and what is not.)
Bug#1044050: intake: can't handle newlines in error messages
Control: unblock 1043240 by 1044050 Control: severity 1044050 serious Control: merge 1044050 1050623 Control: retitle -1 intake: newlines in error messages Control: tags -1 patch On closer inspection, that's not pandas 2.x related, it's the previously seen failure to handle error messages containing newlines (which some of dask's now do), https://github.com/dask/dask/issues/9813 / https://github.com/intake/intake/pull/699 , reappearing because the temporary fix was removed from dask without updating intake to a version with the permanent fix.
Bug#1044053: pandas 2.x test failures
Control: severity -1 important (We would like to transition to pandas 2.1 fairly soon.) These packages are attempting to use .iteritems() on pandas objects, which no longer exists. This can probably be fixed by using .items() instead.
Bug#1044069: pandas 2.x test failures
Control: severity -1 important (We would like to transition to pandas 2.1 fairly soon.) Replacing all instances of pandas.util.testing with pandas.testing should fix the currently visible bug, but I haven't tried it so I don't know whether there are also other bugs.
Bug#1053946: tqdm and pandas 2.1
Control: severity -1 important (We would like to transition to pandas 2.1 fairly soon.) Ignoring these warnings would probably work for now. This is not obviously known upstream, but updating to a newer upstream version might still be worth trying.
Bug#1053947: dask and pandas 2.1
Control: severity -1 important (We would like to transition to pandas 2.1 fairly soon.) This *might* be fixed by https://github.com/dask/dask/pull/10439 and/or https://github.com/dask/dask/pull/10531 It might be best to update to a new upstream version, which would include those and also what they say is Python 3.12 compatibility (#1056239).
Bug#1044076: influxdb-python and pandas 2.1
Control: severity -1 important (We would like to transition to pandas 2.1 fairly soon.) This bug can probably be fixed by replacing all 3 instances of pandas.util.testing with pandas.testing. There are also some (unrelated) Python 3.12 issues: self.assertRaisesRegexp -> self.assertRaisesRegex and one I haven't investigated.
Bug#1055801: pandas: test failures with Python 3.12
Control: severity -1 normal Control: retitle -1 pandas/pytables: ignored test fails with Python 3.12 Control: found -1 2.1.3+dfsg-1 Control: tags 1057805 pending In 1.5.3+dfsg-8, these are ignored, so are no longer an FTBFS but are still a bug. I don't know whether they're a pandas bug or a pytables bug; they don't appear to be known to either upstream. (The build failure on armhf, #1057805, was because this xfail took precedence over the existing run=False xfail and hence exposed a long-known crash, #790925. This should be fixed in -9.) If the 'affects' is because you were trying to test those reverse dependencies in Python 3.12, this should now be possible.
Bug#1055579: pytables and python 3.12
That might not be enough: some of pandas' pytables-using tests are still failing in Python 3.12 (see salsa-ci). However, I don't know whether upgrading pytables to a newer upstream would break anything else.
Bug#1055801: pandas: test failures with Python 3.12
Control: unblock -1 by 1043240 The remaining test failures (all pytables-related) exist in both pandas 1.5 and 2.1, and do not appear to be known upstream. If they are all crashes rather than wrong answers (which I think they are), I intend to ignore them for now to unblock this, but still consider them bugs.
Bug#1053945: seaborn: test-failing warning in pandas 2.1
Control: tags -1 fixed-upstream patch Control: severity -1 important (Raising severity because pandas 2.x is currently blocking Python 3.12) This looks like the upstream fix (I haven't tried it in Debian): https://github.com/mwaskom/seaborn/pull/3355 Upgrading to upstream 0.13 would probably also work, and would be a good idea if it doesn't break anything else, but I haven't checked whether it does.
Bug#1055801: pandas: test failures with Python 3.12
Control: reopen -1 That doesn't actually fix them all (and it's now unclear why I ever thought it did - possibly mistaking 'has a python3.12 package' for 'tests with python3.12 by default'?), but at least the ones that are left all look like exceptions not wrong answers. I intend to look into this further.
Bug#1056891: statsmodels and cython 3.0
This is also known as LP#2043284; upstream #8961 attempts to fix it, but isn't enough by itself (see salsa-ci for logs).
Bug#1056828: pandas and cython 3.0
Control: severity -1 wishlist Switched to cython3-legacy for now. I do want to actually fix this at some point, but it probably makes sense for that to be after the pandas 2.x transition.
Bug#1053700: xarray test failure on s390x
I retried the arm64 test and it passed, so it's probably just a random hang (I've seen those before in pytest). Hence, I now _do_ suggest uploading current Salsa.
Bug#1053700: xarray test failure on s390x
This fix worked but the new upstream version added another similar issue, so s390x failed again. I have pushed a fix for this, and enabled allow-stderr to fix armel (error output from an already-xfailed test). I don't know what's causing the hang on arm64, so please do _not_ upload this just yet.
Bug#1050854: xarray test failure on amd64
I have added what should be fixes for #1053700 and #1044869, but they are currently untested as salsa-ci only runs the autopkgtest on amd64. #1050854 appears to have been fixed (or at least xfailed - it passed on salsa-ci but they say it's flaky) by upstream.
Bug#1053700: xarray test failure on s390x
Control: tags -1 patch
These all come from xarray/tests/test_coding_times.py, and are probably
fixable by replacing both instances of ("M8[ns]" if
sys.byteorder=='big' else "haven't actually tried that.
Bug#1050854: xarray test failure on amd64
This bug is now a crash (not the original error message): https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-xarray/39962554/log.gz I don't know whether the same patch still works. The Salsa repository now appears to be up to date. You probably also want to include the fixes for the other two RC bugs (see there).
Bug#1044869: xarray test failure on i386
Control: tags -1 patch This patch has been probably-by-accident dropped again, and hence this bug has reappeared again: https://ci.debian.net/data/autopkgtest/testing/i386/p/python-xarray/39962705/log.gz Re-adding it would probably work, but I haven't actually tried that.
Bug#1055801: pandas: test failures with Python 3.12
Package: python3-pandas Version: 1.5.3+dfsg-6 Tags: fixed-upstream fixed-in-experimental User: debian-pyt...@lists.debian.org Usertags: python3.12 Control: block -1 by 1043240 Control: forwarded -1 https://github.com/pandas-dev/pandas/issues/53665 (actually found independently) pandas 1.5 FTBFS with Python 3.12 with multiple test failures: https://launchpadlibrarian.net/696823773/buildlog_ubuntu-noble-amd64.pandas_1.5.3+dfsg-6build1_BUILDING.txt.gz The above upstream report suggests that this is fixed in pandas 2.1 (currently in experimental). Given the number of test failures, upgrading to that may be the only reasonable solution. However, as noted in #1043240, this will break other packages.
Bug#1053984: xlsxwriter: too old for pandas 2.1
Package: python3-xlsxwriter Version: 3.0.2-2 Severity: wishlist Tags: fixed-upstream Upstream pandas 2.1 will only use xlsxwriter >= 3.0.3. Nothing obviously breaks if I override this to accept Debian's 3.0.2, but it might be better to actually update xlsxwriter.
Bug#1043240: transition: pandas 1.5 -> 2.1
astropy isn't actually a regression (i.e. it's probably _a_ bug, but unrelated to pandas 2.x), and python-hypothesis appears to be fixed (by upstream, in 6.83.1). I have filed individual bugs for the others.
Bug#1053948: patsy: FTBFS with pandas 2.1
Package: src:patsy Version: 0.5.3-1 Control: block 1043240 by -1 patsy fails to build with pandas 2.1, currently in experimental. Log: https://launchpad.net/~rebecca-palmer/+archive/ubuntu/pandas2p1/+build/26770725/+files/buildlog_ubuntu-mantic-amd64.patsy_0.5.3-1_BUILDING.txt.gz A common source of failures is new pandas FutureWarnings in tests that are set to fail on unexpected warnings.
Bug#1053946: tqdm: FTBFS with pandas 2.1
Package: src:tqdm Version: 4.64.1-1 Control: block 1043240 by -1 tqdm fails to build with pandas 2.1, currently in experimental. Log: https://launchpad.net/~rebecca-palmer/+archive/ubuntu/pandas2p1/+build/26770822/+files/buildlog_ubuntu-mantic-amd64.tqdm_4.64.1-1_BUILDING.txt.gz A common source of failures is new pandas FutureWarnings in tests that are set to fail on unexpected warnings.
Bug#1053947: dask: test failure with pandas 2.1
Package: src:dask Version: 2023.8.0+dfsg-2 Control: block 1043240 by -1 dask fails its autopkgtest with pandas 2.1, currently in experimental. Log: https://ci.debian.net/data/autopkgtest/unstable/amd64/d/dask/38997774/log.gz A common source of failures is new pandas FutureWarnings in tests that are set to fail on unexpected warnings.
Bug#1053945: seaborn: test failure with pandas 2.1
Package: src:seaborn Version: 0.12.2-1 Control: block 1043240 by -1 seaborn fails its tests with pandas 2.1, currently in experimental. Logs: https://ci.debian.net/data/autopkgtest/unstable/amd64/s/seaborn/38997875/log.gz https://launchpad.net/~rebecca-palmer/+archive/ubuntu/pandas2p1/+build/26770797/+files/buildlog_ubuntu-mantic-amd64.seaborn_0.12.2-1_BUILDING.txt.gz A common source of failures is new pandas FutureWarnings in tests that are set to fail on unexpected warnings.
Bug#1053944: q2-types: test failure with pandas 2.1
Package: src:q2-types Version: 2023.7.0-1 Control: block 1043240 by -1 q2-types fails its autopkgtest with pandas 2.1, currently in experimental. Log: https://ci.debian.net/data/autopkgtest/unstable/amd64/q/q2-types/38997869/log.gz A common source of failures is new pandas FutureWarnings in tests that are set to fail on unexpected warnings.
Bug#1053943: q2-taxa: test failure with pandas 2.1
Package: src:q2-taxa Version: 2023.7.0+dfsg-1 Control: block 1043240 by -1 q2-taxa fails its autopkgtest with pandas 2.1, currently in experimental. Log: https://ci.debian.net/data/autopkgtest/unstable/amd64/q/q2-taxa/38997868/log.gz A common source of failures is new pandas FutureWarnings in tests that are set to fail on unexpected warnings.
Bug#1053942: q2-demux: test failure with pandas 2.1
Package: src:q2-demux Version: 2023.7.0+dfsg-1 Control: block 1043240 by -1 q2-demux fails its autopkgtest with pandas 2.1, currently in experimental. Log: https://ci.debian.net/data/autopkgtest/unstable/amd64/q/q2-demux/38997862/log.gz A common source of failures is new pandas FutureWarnings in tests that are set to fail on unexpected warnings.
Bug#1053941: python-geopandas: test failure with pandas 2.1
Package: src:python-geopandas Version: 0.14.0-1 Control: block 1043240 by -1 python-geopandas fails its autopkgtest with pandas 2.1, currently in experimental. Log: https://ci.debian.net/data/autopkgtest/unstable/amd64/p/python-geopandas/38997837/log.gz A common source of failures is new pandas FutureWarnings in tests that are set to fail on unexpected warnings.
