Bug#1076732: closed by Debian FTP Masters (reply to Francois Mazen ) (Bug#1076732: fixed in ispc 1.24.0-2)
Hi, On 23-07-2024 7:09 p.m., Debian Bug Tracking System wrote: ispc (1.24.0-2) unstable; urgency=medium . * Limit architectures for migration to testing (Closes: #1076732) Don't forget to ask for removal of the current armhf binaries. They are not automatically removed: $(reportbug ftp.debian.org) Paul OpenPGP_signature.asc Description: OpenPGP digital signature -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1076830: pytango: failed to build from source on arm64: test timeout
Hi, On Tue, 23 Jul 2024 21:38:31 +0200 Paul Gevers wrote: The latest upload of pytango failed to build on the arm64 buildd. Seems like the build is flaky as the error is about a timeout during the test. The same seems to be visible in the autopkgtest history on ci.debian.net for other architectures too. Paul OpenPGP_signature.asc Description: OpenPGP digital signature -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1076830: pytango: failed to build from source on arm64: test timeout
Source: pytango
Version: 9.5.0-4
Severity: serious
Tags: ftbfs
Justification: FTBFS
Hi,
The latest upload of pytango failed to build on the arm64 buildd. Seems
like the build is flaky as the error is about a timeout during the test.
Paul
=== FAILURES
===
___ test_subscribe_data_ready_event[Asyncio]
___
event_device = EventDevice(test/nodb/eventdevice)
def test_subscribe_data_ready_event(event_device):
results_data_ready_event = []
def callback_data_ready(evt):
results_data_ready_event.append(evt.ctr)
# Subscribe to data ready event
eid_data_ready = event_device.subscribe_event(
"attr", EventType.DATA_READY_EVENT, callback_data_ready,
wait=True
)
assert eid_data_ready == 1
# Trigger an event
event_device.command_inout("send_data_ready_event", wait=True)
# Wait for tango event
for retry_count in range(MAX_RETRIES):
event_device.read_attribute("state", wait=True)
if len(results_data_ready_event):
break
time.sleep(DELAY_PER_RETRY)
if retry_count + 1 >= MAX_RETRIES:
timeout_seconds = retry_count * DELAY_PER_RETRY
> pytest.fail(
f"Timeout, waiting for event, after
{timeout_seconds}sec over {MAX_RETRIES} retries. Occasionally happens,
probably due to CI test runtime environment"
)
E Failed: Timeout, waiting for event, after
9.951sec over 200 retries. Occasionally happens, probably
due to CI test runtime environment
tests/test_event.py:151: Failed
Captured stdout setup
-
Ready to accept request
Captured stderr setup
-
Can't create notifd event supplier. Notifd event not available
-- System Information:
Debian Release: trixie/sid
APT prefers testing
APT policy: (990, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 6.9.8-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
OpenPGP_signature.asc
Description: OpenPGP digital signature
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1076732: src:ispc: fails to migrate to testing for too long: installability issue on armhf
Source: ispc Version: 1.23.0-1 Severity: serious Control: close -1 1.24.0-1 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:ispc has been trying to migrate for 34 days [2]. Hence, I am filing this bug. The version of libispcrt-dev can't be installed on armhf because it depends on bin:ispc which isn't available there. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=ispc OpenPGP_signature.asc Description: OpenPGP digital signature -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1076537: src:ucx: fails to migrate to testing for too long: unhandled architecture drop
Source: ucx Version: 1.16.0+ds-5 Severity: serious Control: close -1 1.17.0+ds-2 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Control: affects -1 src:openmpi Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:ucx has been trying to migrate for 31 days [2]. Hence, I am filing this bug. When you drop support for an architecture, this isn't picked up automatically by dak (one might consider that a feature) and you need to file a removal bug manually. I was about to do that for you, but before that removal can be processed, all reverse (build) dependencies need to be resolved too (either also removed, requiring individual bugs) or by dropping their dependency. In this case, src:openmpi still builds libopenmpi3t64 with a Depends on libucx0 on ppc64el, but seeing that other architectures build successfully, the Build-Depends seems optional. If I didn't make a mistake, only src:openmpi is still blocking removal. Given the history with 1.16.0 I guess you're not wanting to wait for upstream and I can understand that. But have you considered contacting the ppc64el porters? Please be aware of our rc-bug policy [3]: """ Packages must be supported on as many architectures as is *reasonably* possible. """ Emphasis in that quote is mine and a very important detail of that policy. I would hope everybody contacts porters before dropping an architecture. Porters commit themselves to help with architectures specific issues. If they don't, the release team wants to know because that's a strong reason to no longer support the architecture. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=ucx [3] https://release.debian.org/testing/rc_policy.txt elbrus@coccia:~$ dak rm --no-action -RB -a ppc64el ucx W: -a/--architecture implies -p/--partial. Will remove the following packages from unstable: libucx-dev | 1.16.0+ds-5 | ppc64el libucx0 | 1.16.0+ds-5 | ppc64el ucx-utils | 1.16.0+ds-5 | ppc64el Maintainer: Debian Science Maintainers --- Reason --- -- Checking reverse dependencies... # Broken Depends: openmpi: libopenmpi3t64 # Broken Build-Depends: adios2: libucx-dev mpich: libucx-dev openmpi: libucx-dev pmix: libucx-dev Dependency problem found. OpenPGP_signature.asc Description: OpenPGP digital signature -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1029789: FTBFS deliberately on 32 bit archs
Hi, On Fri, 27 Jan 2023 19:12:19 +0100 Bastian Germann wrote: The package fails to build on 32 bit architectures due to a false call in debian/rules. Instead of making the 32 bit architectures fail this way the architectures armel, armhf, i386 should be removed from the Architecture list. Or MUCH BETTER, Build-Depend on architecture-is-64-bit (from https://packages.debian.org/unstable/architecture-properties). Rationale: https://lists.debian.org/debian-devel/2022/09/msg00105.html Paul OpenPGP_signature.asc Description: OpenPGP digital signature -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1072271: src:skimage: fails to migrate to testing for too long: FTBFS on mips64el
Source: skimage Version: 0.22.0-3 Severity: serious Control: close -1 0.23.2-1 Tags: sid trixie ftbfs User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:skimage has been trying to migrate for 49 days [2]. Hence, I am filing this bug. The version in unstable failed to build on mips64el. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=skimage OpenPGP_signature.asc Description: OpenPGP digital signature -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1071782: skimage: autopkgtest needs update for new version of pytest on s390x
Source: skimage
Version: 0.22.0-3
Severity: serious
X-Debbugs-CC: pyt...@packages.debian.org
Tags: sid trixie
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:pytest
Dear maintainer(s),
With a recent upload of pytest the autopkgtest of skimage fails in
testing on s390x when that autopkgtest is run with the binary packages
of pytest from unstable. It passes when run with only packages from
testing. In tabular form:
passfail
pytest from testing8.1.2-1
skimagefrom testing0.22.0-3
all others from testingfrom testing
I copied some of the output at the bottom of this report. I'll note that
s390x is our only big endian architecture with autopgktest.
Currently this regression is blocking the migration of pytest to testing
[1]. Of course, pytest shouldn't just break your autopkgtest (or even
worse, your package), but due to the nature of the package pytest I
suspect that your package just needs to update to the new situation.
If this is a real problem in your package (and not only in your
autopkgtest), the right binary package(s) from pytest should really add
a versioned Breaks on the unfixed version of (one of your) package(s).
Note: the Breaks is nice even if the issue is only in the autopkgtest as
it helps the migration software to figure out the right versions to
combine in the tests.
More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
Paul
[1] https://qa.debian.org/excuses.php?package=pytest
https://ci.debian.net/data/autopkgtest/testing/s390x/s/skimage/46978110/log.gz
=== FAILURES
===
300s __ test_imread_handle
__
300s 300s def test_imread_handle():
300s expected = np.load(fetch('data/chessboard_GRAY_U8.npy'))
300s with open(fetch('data/chessboard_GRAY_U16.tif'), 'rb') as fh:
300s img = imread(fh)
300s > assert img.dtype == np.uint16
300s E AssertionError: assert dtype('
300s E+ where dtype('0, 0],\n [255, 255, 255, ..., 0, 0, 0],\n [255, 255,
255, ..., 0, 0, 0],\n ...,\n [ 0, 0, 0, ..., 255,
255, 255],\n [ 0, 0, 0, ..., 255, 255, 255],\n [ 0,
0, 0, ..., 255, 255, 255]], dtype='
300s E+ and= np.uint16
300s 300s
/usr/lib/python3/dist-packages/skimage/io/tests/test_tifffile.py:48:
AssertionError
300s === warnings summary
===
300s filters/tests/test_unsharp_mask.py: 480 warnings
300s
/usr/lib/python3/dist-packages/skimage/filters/tests/test_unsharp_mask.py:26:
RuntimeWarning: invalid value encountered in cast
300s array = ((array + offset) * 128).astype(dtype)
300s 300s io/tests/test_pil.py::test_png_round_trip
300s io/tests/test_pil.py::test_imsave_filelike
300s
/usr/lib/python3/dist-packages/skimage/io/_plugins/pil_plugin.py:105:
DeprecationWarning: The binary mode of fromstring is deprecated, as it
behaves surprisingly on unicode inputs. Use frombuffer instead
300s frame = np.fromstring(frame.tobytes(), dtype)
300s 300s measure/tests/test_fit.py::test_ellipse_parameter_stability
300s /usr/lib/python3/dist-packages/skimage/measure/fit.py:526:
RuntimeWarning: divide by zero encountered in scalar divide
300s phi = 0.5 * np.arctan((2. * b) / (a - c))
300s 300s
transform/tests/test_pyramids.py::test_pyramid_dtype_support[pyramid_gaussian-uint8]
300s
transform/tests/test_pyramids.py::test_pyramid_dtype_support[pyramid_laplacian-uint8]
300s
/usr/lib/python3/dist-packages/skimage/transform/tests/test_pyramids.py:208:
RuntimeWarning: invalid value encountered in cast
300s img = np.random.randn(32, 8).astype(dtype)
300s 300s
../../../../usr/lib/python3/dist-packages/_pytest/cacheprovider.py:446
300s /usr/lib/python3/dist-packages/_pytest/cacheprovider.py:446:
PytestCacheWarning: could not create cache path
/usr/lib/python3/dist-packages/skimage/.pytest_cache/v/cache/nodeids:
[Errno 13] Permission denied:
'/usr/lib/python3/dist-packages/skimage/.pytest_cache'
300s config.cache.set("cache/nodeids", sorted(self.cached_nodeids))
300s 300s
../../../../usr/lib/python3/dist-packages/_pytest/cacheprovider.py:398
300s /usr/lib/python3/dist-packages/_pytest/cacheprovider.py:398:
PytestCacheWarning: could not create cache path
/usr/lib/python3/dist-packages/skimage/.pytest_cache/v/cache/lastfailed:
[Errno 13] Permission denied:
'/usr/lib/python3/dist-packages/skimage/.pytest_cache'
300s config.cache.set("cache/lastfailed", self.lastfailed)
300s 300s ../../../../usr/lib/python3/dist-packages/_pytest/stepwise.py:57
300s /usr/lib/python3/dist-packages/_pytest/stepwise.py:57:
PytestCacheWarning: could not create cache path
Bug#1071397: src:ngspetsc: unsatisfied build dependency in testing: fenicsx
Source: ngspetsc Version: 0.0~git20240318.f83b50a-1 Severity: serious Tags: sid trixie User: debian...@lists.debian.org Usertags: edos-uninstallable Dear maintainer(s), Dose [1] is reporting a build issue with your package, it's missing a build dependency. Obviously your build dependencies shouldn't be removed from testing, but unfortunately there are multiple scenarios where that can happen nevertheless. To uphold our social contract, Debian requires that packages can be rebuild from source in the suite we are shipping them, so currently this is a serious issue with your package in testing. Can you please investigate the situation and figure out how to resolve it? Regularly, if the build dependency is available in unstable, helping the maintainer of your Build-Depends to enable migration to testing is a great way to solve the issue. If your build dependency is gone from unstable and testing, you'll have to fix the build process in some other way. Paul Note: this bug report was sent after some quick manual checks using a template. Please reach out to me if you believe I made a mistake in my process. [1] https://qa.debian.org/dose/debcheck/src_testing_main/latest/amd64.html OpenPGP_signature.asc Description: OpenPGP digital signature -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1069806: spyder: half hidden titles in "configuration per file" window
Package: spyder Version: 5.5.1+ds-1 Severity: minor While I was searching for some option, I stumbled upon the "Configuration per file" window (under the "Run" tab in the menu, or via -F6). The names of the sub windows are half hidden in my setup (I use KDE if that matters and I have adjusted the font size to something bigger than the default). See attachment for clarity. Paul -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (990, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.6.15-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages spyder depends on: ii python3 3.11.6-1 ii python3-spyder 5.5.1+ds-1 spyder recommends no packages. Versions of packages spyder suggests: pn python3-spyder-unittest Versions of packages python3-spyder depends on: ii ipython3 8.20.0-1 ii libjs-jquery 3.6.1+dfsg+~3.5.14-1 ii libjs-mathjax2.7.9+dfsg-1 ii pyflakes33.2.0-1 ii pylint 3.0.3-1 ii python3 [python3-supported-min] 3.11.6-1 ii python3-atomicwrites 1.4.1-1 ii python3-autopep8 2.1.0-1 ii python3-chardet 5.2.0+dfsg-1 ii python3-cloudpickle 3.0.0-2 ii python3-cookiecutter 2.6.0-1 ii python3-diff-match-patch 20230430-1 ii python3-docutils 0.20.1+dfsg-3 ii python3-flake8 7.0.0-1 ii python3-intervaltree 3.0.2-1.1 ii python3-ipython 8.20.0-1 ii python3-jedi 0.19.1+ds1-1 ii python3-jellyfish0.10.0-3 ii python3-jsonschema 4.19.2-2 ii python3-keyring 25.1.0-1 ii python3-mccabe 0.7.0-1 ii python3-nbconvert6.5.3-5 ii python3-numpydoc 1.6.0-2 ii python3-parso0.8.3-1 ii python3-pexpect 4.9-2 ii python3-pickleshare 0.7.5-5 ii python3-pkg-resources68.1.2-2 ii python3-psutil 5.9.8-2 ii python3-pycodestyle 2.11.1-1 ii python3-pydocstyle 6.3.0-1.1 ii python3-pygments 2.17.2+dfsg-1 ii python3-pylint-venv 3.0.2-1 ii python3-pyls-spyder 0.4.0-2 ii python3-pylsp1.10.1-1 ii python3-pylsp-black 2.0.0-4 ii python3-pyqt55.15.10+dfsg-1 ii python3-pyqt5.qtwebengine5.15.6-1 ii python3-qdarkstyle 3.2.3+ds1-1 ii python3-qstylizer0.2.2-2 ii python3-qtawesome1.2.3+dfsg-1 ii python3-qtconsole5.5.1-1 ii python3-qtpy 2.4.1-2 ii python3-rope 1.13.0-1 ii python3-rtree1.2.0-1 ii python3-setuptools 68.1.2-2 ii python3-sphinx 7.2.6-6 ii python3-spyder-kernels 2.5.0-2 ii python3-textdistance 4.6.0-1 ii python3-three-merge 0.1.1-4 ii python3-watchdog 3.0.0-1 ii python3-xdg 0.28-2 ii python3-zmq 24.0.1-5+b1 ii spyder-common5.5.1+ds-1 ii yapf30.33.0-1 python3-spyder recommends no packages. Versions of packages python3-spyder suggests: pn cython3 ii python3-matplotlib 3.6.3-1+b2 ii python3-numpy 1:1.24.2-2 pn python3-pandas ii python3-pil 10.3.0-2 ii python3-scipy 1.11.4-6 ii python3-sympy 1.12-7 Versions of packages python3-pyqt5 depends on: ii libc6 2.37-18 ii libgcc-s1 14-20240330-1 ii libpython3.11 3.11.8-1 ii libqt5core5a [qtbase-abi-5-15-10] 5.15.10+dfsg-7 ii libqt5dbus55.15.10+dfsg-7 ii libqt5designer55.15.10-6 ii libqt5gui5 5.15.10+dfsg-7 ii libqt5help55.15.10-6 ii libqt5network5 5.15.10+dfsg-7 ii libqt5printsupport55.15.10+dfsg-7 ii libqt5test55.15.10+dfsg-7 ii libqt5widgets5 5.15.10+dfsg-7 ii libqt5xml5 5.15.10+dfsg-7 ii libstdc++6 14-20240330-1 ii python33.11.6-1 ii python3-pyqt5.sip 12.13.0-1+b1 -- no debconf information OpenPGP_signature.asc Description: OpenPGP digital signature -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1065412: src:pytables: fails to migrate to testing for too long: old s390x binary left around
Source: pytables Version: 3.7.0-10 Severity: serious Control: close -1 3.9.2-1 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Control: block -1 by 1061661 Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:pytables has been trying to migrate for 64 days [2]. Hence, I am filing this bug. As suggested in bug 1061661, the s390x binary needs to be removed by ftp-master. Somebody needs to request it. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=pytables OpenPGP_signature.asc Description: OpenPGP digital signature -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1064995: fenics-dolfinx: suspicious autopkgtest on s390x seems to use (nearly) all disk space
Hi, On Wed, 28 Feb 2024 20:48:06 +0100 Paul Gevers wrote: Since a couple of days, our workers on s390x are dying because some test is filling up all disk space. It *appears* that fenics-dolfinx is always involved, so I suspect it doing something inappropriate. Yesterday we were in the same (or very similar) situation again despite fenics-dolfinx being on the reject_list for s390x. So, most likely it was not its fault. Paul OpenPGP_signature.asc Description: OpenPGP digital signature -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1065340: src:guidata: unsatisfied build dependency in testing: python3-sip
Source: guidata Version: 3.0.4+dfsg1-1 Severity: serious Tags: sid trixie User: debian...@lists.debian.org Usertags: edos-uninstallable Control: block -1 by 1060742 Dear maintainer(s), Dose [1] is reporting a build issue with your package, it's missing a build dependency. Obviously your build dependencies shouldn't be removed from testing, but unfortunately there are multiple scenarios where that can happen nevertheless. To uphold our social contract, Debian requires that packages can be rebuild from source in the suite we are shipping them, so currently this is a serious issue with your package in testing. Bug #1060742 was filed earlier to warn you about the issue; python3-sip has now been removed from testing due to its RC bug. Can you please investigate the situation and figure out how to resolve it? Paul Note: this bug report was sent after some quick manual checks using a template. Please reach out to me if you believe I made a mistake in my process. [1] https://qa.debian.org/dose/debcheck/src_testing_main/latest/amd64.html OpenPGP_signature.asc Description: OpenPGP digital signature -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1064995: fenics-dolfinx: suspicious autopkgtest on s390x seems to use (nearly) all disk space
Source: fenics-dolfinx Version: 1:0.7.3-5 X-Debbugs-CC: debian...@lists.debian.org User: debian...@lists.debian.org Usertags: issue Dear maintainer(s), Since a couple of days, our workers on s390x are dying because some test is filling up all disk space. It *appears* that fenics-dolfinx is always involved, so I suspect it doing something inappropriate. Basically every spike above 40% in the graph [1] is a moment that we see issues like: Feb 28 05:38:18 ci-worker-s390x-01 debci[1738391]: gzip: /tmp/debci-worker-43383540-cNnbLE372K/autopkgtest-incoming/testing/s390x/f/fenics-dolfinx/43383540/log.gz: No space left on device Feb 28 05:38:18 ci-worker-s390x-01 debci[1424101]: E: Test for package fenics-dolfinx produced no exit code, aborting fenics-dolfinx migrated last night, the amount of failures intensived last night. I know, it's not proof, but do you have any idea what could be going on and how to prevent it? For now I put fenics-dolfinx on the rejectlist for s390x. I'd love to remove it again. [1] https://ci.debian.net/munin/ci-worker-s390x-01/ci-worker-s390x-01/df.html Paul OpenPGP_signature.asc Description: OpenPGP digital signature -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1061661: python3-tables-lib [s390x] -- RoM ANAIS
Hi all, On Sun, 28 Jan 2024 10:52:38 +0100 Antonio Valentino wrote: Package: python3-tables-lib This bug would need to be reassigned to the ftp.debian.org pseudo package to actually do anything. Version: 3.9.2-1 Severity: normal Tags: ftbfs X-Debbugs-Cc: antonio.valent...@tiscali.it Dear Maintainer, the new upstream version of pytables, v3.9.2, depends on c-blosc2 that is not abailable on s390x. Removing the python3-tables-lib binary package from s390x/unstable should allow to pytables v3.9.2 to migrate into testing. Indeed. If nothing happens soon, I'll file an out-of-sync bug report which would lead to autoremoval starting. Paul OpenPGP_signature.asc Description: OpenPGP digital signature -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1063797: src:mathgl: fails to migrate to testing for too long: FTBFS on amd64 and i386
Source: mathgl Version: 8.0.1-4 Severity: serious Control: close -1 8.0.1-5 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Control: block -1 by 1063599 Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:mathgl has been trying to migrate for 34 days [2]. Hence, I am filing this bug. The version in unstable failed to build on amd64 and i386 (and arch:all), as reported in bug #1063599). Apparently now also a lot of other architectures have build problems (build depends not available) If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=mathgl OpenPGP_signature.asc Description: OpenPGP digital signature -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1063796: src:plplot: fails to migrate to testing for too long: patchelf not available on mips64el
Source: plplot Version: 5.15.0+dfsg2-6 Severity: serious Control: close -1 5.15.0+dfsg2-7+deb13u1 X-Debbugs-CC: debian-m...@lists.debian.org Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:plplot has been trying to migrate for 34 days [2]. Hence, I am filing this bug. The package Build-Depends on patchelf, which has a build issue on mips64el (bug #1059752). Unfortunately patchelf is a key package, and saw a new version in the time that mips64el was allowed to be broken, so currently patchelf doesn't exist on mips64el in testing. This is impacting your package. I think that for the time being it's probably easiest to request removal of your package on mips64el. Alternatively you try to help fix the bug in patchelf (I've CC'd the mips porters to draw their attention to the problem too). If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=plplot OpenPGP_signature.asc Description: OpenPGP digital signature -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1063056: dh-fortran-mod: autopkgtest failure: No CMAKE_C_COMPILER could be found.
Control: reassign -1 src:lfortran 0.36 Mea culpa, I made a mistake in calling my tools and filed the issue against the wrong package. On Sun, 4 Feb 2024 19:59:33 +0100 Paul Gevers wrote: Severity: serious User: debian...@lists.debian.org Usertags: fails-always Dear maintainer(s), You recently added an autopkgtest to your package dh-fortran-mod, great. However, it fails. Currently this failure is blocking the migration to testing [1]. Can you please investigate the situation and fix it? Because this package is involved in a big pile with binutils, gcc-13, gcc-14, gcc-defaults, gcc-defaults-ports, gcc-13-cross, gcc-14-cross, gcc-13-cross-ports, gcc-14-cross-ports which I really want to have migrated, I've added a hint, but failing autopkgtest on amd64 and arm64 are considered RC. I copied some of the output at the bottom of this report. More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=dh-fortran-mod https://ci.debian.net/packages/l/lfortran/testing/amd64/42713825/ 25s -- The C compiler identification is unknown 25s -- The Fortran compiler identification is unknown 25s CMake Error at CMakeLists.txt:3 (project): 25s No CMAKE_C_COMPILER could be found. 25s 25s Tell CMake where to find the compiler by setting either the environment 25s variable "CC" or the CMake cache entry CMAKE_C_COMPILER to the full path to 25s the compiler, or to the compiler name if it is in the PATH. 25s 25s 25s -- Detecting Fortran compiler ABI info 25s -- Detecting Fortran compiler ABI info - done 25s -- Check for working Fortran compiler: /usr/bin/lfortran - skipped 25s -- Configuring incomplete, errors occurred! OpenPGP_signature.asc Description: OpenPGP digital signature -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1063056: dh-fortran-mod: autopkgtest failure: No CMAKE_C_COMPILER could be found.
Source: dh-fortran-mod Version: 0.37 Severity: serious User: debian...@lists.debian.org Usertags: fails-always Dear maintainer(s), You recently added an autopkgtest to your package dh-fortran-mod, great. However, it fails. Currently this failure is blocking the migration to testing [1]. Can you please investigate the situation and fix it? Because this package is involved in a big pile with binutils, gcc-13, gcc-14, gcc-defaults, gcc-defaults-ports, gcc-13-cross, gcc-14-cross, gcc-13-cross-ports, gcc-14-cross-ports which I really want to have migrated, I've added a hint, but failing autopkgtest on amd64 and arm64 are considered RC. I copied some of the output at the bottom of this report. More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=dh-fortran-mod https://ci.debian.net/packages/l/lfortran/testing/amd64/42713825/ 25s -- The C compiler identification is unknown 25s -- The Fortran compiler identification is unknown 25s CMake Error at CMakeLists.txt:3 (project): 25s No CMAKE_C_COMPILER could be found. 25s 25s Tell CMake where to find the compiler by setting either the environment 25s variable "CC" or the CMake cache entry CMAKE_C_COMPILER to the full path to 25s the compiler, or to the compiler name if it is in the PATH. 25s 25s 25s -- Detecting Fortran compiler ABI info 25s -- Detecting Fortran compiler ABI info - done 25s -- Check for working Fortran compiler: /usr/bin/lfortran - skipped 25s -- Configuring incomplete, errors occurred! OpenPGP_signature.asc Description: OpenPGP digital signature -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1062356: adios2: flaky autopkgtest (host dependent): times out on big host
Source: adios2 Version: 2.9.2+dfsg1-8 Severity: serious User: debian...@lists.debian.org Usertags: flaky Dear maintainer(s), I looked at the results of the autopkgtest of your package. I noticed that it regularly fails. The failures seem related to the host that runs the test. ci-worker13 is a beefy machine [1], while the other amd64 workers are much more moderate [2]. The tests that time out after 2:50 hours seem to all run on ci-worker13 (so, lots of CPU's and lots of RAM), while the other runs only take below 10 minutes (and seem to run on one of the other hosts. Because the unstable-to-testing migration software now blocks on regressions in testing, flaky tests, i.e. tests that flip between passing and failing without changes to the list of installed packages, are causing people unrelated to your package to spend time on these tests. Don't hesitate to reach out if you need help and some more information from our infrastructure. Paul [1] https://metal.equinix.com/product/servers/m3-large/ [2] https://aws.amazon.com/ec2/instance-types/m5/ OpenPGP_signature.asc Description: OpenPGP digital signature -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1061174: src:gmsh: fails to migrate to testing for too long: causes timeout of pygmsh autopkgtest on i386
Source: gmsh Version: 4.8.4+ds2-3 Severity: serious Control: close -1 4.11.1+ds1-1 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:gmsh has been trying to migrate for 31 days [2]. Hence, I am filing this bug. The version in unstable has arch:all binaries uploaded by the uploader (as reported in bug 1060715) but also causes autopkgtest failure on i386 in the pygmsh package: it times out now after 2:47 hours, while normal runs finish in several minutes. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=gmsh OpenPGP_signature.asc Description: OpenPGP digital signature -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1061123: suitesparse breaks octave autopkgtest: it hangs
Source: suitesparse, octave Control: found -1 suitesparse/1:7.5.1+dfsg-1 Control: found -1 octave/8.4.0-1 Severity: serious Tags: sid trixie User: debian...@lists.debian.org Usertags: breaks needs-update Dear maintainer(s), With a recent upload of suitesparse the autopkgtest of octave fails in testing when that autopkgtest is run with the binary packages of suitesparse from unstable. It passes when run with only packages from testing. In tabular form: passfail suitesparsefrom testing1:7.5.1+dfsg-1 octave from testing8.4.0-1 all others from testingfrom testing I copied some of the output at the bottom of this report. Normally the test only takes a couple of minutes, now it times out after 2:47 hours. I'm notifying you already as this is currently also impacting the perl transition via texinfo. Currently this regression is blocking the migration of suitesparse to testing [1]. Due to the nature of this issue, I filed this bug report against both packages. Can you please investigate the situation and reassign the bug to the right package? More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=suitesparse https://ci.debian.net/data/autopkgtest/testing/amd64/o/octave/41870107/log.gz 94s 94s Integrated test scripts: 94s 94s liboctave/array/Array-base.cc-tst .. pass 21/21 94s liboctave/array/CMatrix.cc-tst . pass 11/11 94s liboctave/array/CSparse.cc-tst . pass 10/10 94s liboctave/array/Sparse.cc-tst .. pass 107/107 94s liboctave/array/dMatrix.cc-tst . pass 10/10 94s liboctave/array/dSparse.cc-tst . pass 12/12 94s liboctave/array/fCMatrix.cc-tst pass 11/11 94s liboctave/array/fMatrix.cc-tst . pass 8/894s liboctave/array/idx-vector.cc-tst .. pass2/294s liboctave/util/oct-inttypes.cc-tst . pass 28/28 94s libinterp/corefcn/Cell.cc-tst .. pass5/594s libinterp/corefcn/__contourc__.cc-tst .. pass 1/194s libinterp/corefcn/__dsearchn__.cc-tst .. pass1/194s libinterp/corefcn/__eigs__.cc-tst .. pass 1/194s libinterp/corefcn/__ichol__.cc-tst . pass1/194s libinterp/corefcn/__ilu__.cc-tst ... pass 1/195s libinterp/corefcn/__isprimelarge__.cc-tst .. pass 10/10 95s libinterp/corefcn/__lin_interpn__.cc-tst ... pass 1/195s libinterp/corefcn/__magick_read__.cc-tst ... pass4/495s libinterp/corefcn/__pchip_deriv__.cc-tst ... pass 4/495s libinterp/corefcn/__qp__.cc-tst pass1/195s libinterp/corefcn/amd.cc-tst ... pass 4/495s libinterp/corefcn/besselj.cc-tst ... pass 200/200 96s libinterp/corefcn/bitfcns.cc-tst ... pass 60/60 100s libinterp/corefcn/bsxfun.cc-tst pass 82/82 100s libinterp/corefcn/call-stack.cc-tst pass 3/3 102s libinterp/corefcn/cellfun.cc-tst ... pass 134/134 102s libinterp/corefcn/chol.cc-tst ..malloc(): invalid size (unsorted) 10094s fatal: caught signal autopkgtest [06:55:22]: ERROR: timed out on command "su -s /bin/bash debci -c set -e; exec /tmp/autopkgtest-lxc.gixhwtgb/downtmp/wrapper.sh --artifacts=/tmp/autopkgtest-lxc.gixhwtgb/downtmp/upstream-testsuite-artifacts --chdir=/tmp/autopkgtest-lxc.gixhwtgb/downtmp/build.byz/src --env=DEB_BUILD_OPTIONS=parallel=64 --env=DEBIAN_FRONTEND=noninteractive --env=LANG=C.UTF-8 --unset-env=LANGUAGE --unset-env=LC_ADDRESS --unset-env=LC_ALL --unset-env=LC_COLLATE --unset-env=LC_CTYPE --unset-env=LC_IDENTIFICATION --unset-env=LC_MEASUREMENT --unset-env=LC_MESSAGES --unset-env=LC_MONETARY --unset-env=LC_NAME --unset-env=LC_NUMERIC --unset-env=LC_PAPER --unset-env=LC_TELEPHONE --unset-env=LC_TIME --script-pid-file=/tmp/autopkgtest_script_pid --source-profile --stderr=/tmp/autopkgtest-lxc.gixhwtgb/downtmp/upstream-testsuite-stderr --stdout=/tmp/autopkgtest-lxc.gixhwtgb/downtmp/upstream-testsuite-stdout --tmp=/tmp/autopkgtest-lxc.gixhwtgb/downtmp/autopkgtest_tmp
Bug#1060151: src:compyle: fails to migrate to testing for too long: autopkgtest issues
Source: compyle Version: 0.8.1-4 Severity: serious Control: close -1 0.8.1-6 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:compyle has been trying to migrate for 34 days [2]. Hence, I am filing this bug. The version in unstable fails its own autopkgtest on armel, ppc64el and s390x and shows failure in pysph (albeit that *might* be due to Python 3.12). If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=compyle OpenPGP_signature.asc Description: OpenPGP digital signature -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1059785: benchmark breaks ABI without SONAME bump
Source: benchmark Control: found -1 benchmark/1.8.3-1 Severity: serious Tags: sid trixie Dear maintainer(s), With a recent upload of benchmark the autopkgtest of pytorch fails in testing when that autopkgtest is run with the binary packages of benchmark from unstable. It passes when run with only packages from testing. In tabular form: passfail benchmark from testing1.8.3-1 pytorchfrom testing2.0.1+dfsg-5 all others from testingfrom testing I copied some of the output at the bottom of this report. This looks very much like benchmark dropped a symbol from its shared library without a SONAME bump. Can you please investigate and clarify? Currently this is blocking the migration of benchmark to testing, as I reported in bug 1056202, but because benchmark is a key package, that didn't lead to its removal. The release team has also received a request to rebuild ros2-performance-test-fixture (bug 1057304), so it seems more packages are affected. Paul [1] https://qa.debian.org/excuses.php?package=benchmark https://ci.debian.net/data/autopkgtest/testing/arm64/p/pytorch/41359814/log.gz 1276s /usr/lib/libtorch-test/c10_intrusive_ptr_benchmark: symbol lookup error: /usr/lib/libtorch-test/c10_intrusive_ptr_benchmark: undefined symbol: _ZN9benchmark8internal9BenchmarkC2EPKc 1276s autopkgtest [08:27:24]: test 44_of_98__cpptest__c10_intrusive_ptr_benchmark OpenPGP_signature.asc Description: OpenPGP digital signature -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1058018: libadios2-common-core-dev has an undeclared file conflict on /usr/lib/x86_64-linux-gnu/cmake/adios2/adios2-config.cmake
Hi Drew, On Mon, 11 Dec 2023 20:24:01 +0100 Drew Parsons wrote: Control: severity -1 important Helmut disagreed with your call here and asked the Release Team on IRC to have a check. Call it teething issues. This is a new package, so I'm trying to avoid making debian/control more verbose than it needs to be by not crowding the fields with the strict specifications needed to avoid this error. I agree with Helmut that under normal circumstances this bug is an RC issue and I think you agree too. I think that adding a versioned Breaks/Replaces that you can drop after the release of trixie isn't too much to ask for something that has been part of trixie already. Having said that, I'm not going to overrule you. Once the new version migrates to testing, I'll close this bug and we can pretend it never happened. For next time, I ask you to consider either using experimental to iron out things like this and/or ensure your package doesn't migrate to testing until you believe you're done. Having said that, unstable does have users. E.g. our derivatives often pull from unstable, so even for those it's nice to do the right thing. I'm sure you don't know of all our derivatives when they freeze, and hence if they happened to have released to their stable the thing that now breaks. Paul OpenPGP_signature.asc Description: OpenPGP digital signature -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1056202: src:benchmark: fails to migrate to testing for too long: triggers autopkgtest issues
Source: benchmark Version: 1.7.1-1 Severity: serious Control: close -1 1.8.3-1 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:benchmark has been trying to migrate for 31 days [2]. Hence, I am filing this bug. The version in unstable causes issues with autopkgtests of reverse test dependencies. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=benchmark OpenPGP_signature.asc Description: OpenPGP digital signature -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1052388: python-sparse: autopkgtest needs update for new version of numba
Source: python-sparse
Version: 0.13.0-1
Severity: serious
X-Debbugs-CC: nu...@packages.debian.org
Tags: sid trixie
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:numba
Dear maintainer(s),
With a recent upload of numba the autopkgtest of python-sparse fails in
testing when that autopkgtest is run with the binary packages of numba
from unstable. It passes when run with only packages from testing. In
tabular form:
passfail
numba from testing0.57.1+dfsg-1
python-sparse from testing0.13.0-1
all others from testingfrom testing
I copied some of the output at the bottom of this report.
Currently this regression is blocking the migration of numba to testing
[1]. Of course, numba shouldn't just break your autopkgtest (or even
worse, your package), but it seems to me that numba isn't going to fix
the situation.
If this is a real problem in your package (and not only in your
autopkgtest), the right binary package(s) from numba should really add a
versioned Breaks on the unfixed version of (one of your) package(s).
Note: the Breaks is nice even if the issue is only in the autopkgtest as
it helps the migration software to figure out the right versions to
combine in the tests.
More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
Paul
[1] https://qa.debian.org/excuses.php?package=numba
https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-sparse/38059394/log.gz
115s === FAILURES
===
115s ___ test_tensordot[coo-gcxs-a_shape1-b_shape1-axes1]
___
115s
115s a_shape = (3, 4), b_shape = (4, 3), axes = (0, 1), a_format = 'coo'
115s b_format = 'gcxs'
115s
115s @pytest.mark.parametrize(
115s "a_shape,b_shape,axes",
115s [
115s [(3, 4), (4, 3), (1, 0)],
115s [(3, 4), (4, 3), (0, 1)],
115s [(3, 4, 5), (4, 3), (1, 0)],
115s [(3, 4), (5, 4, 3), (1, 1)],
115s [(3, 4), (5, 4, 3), ((0, 1), (2, 1))],
115s [(3, 4), (5, 4, 3), ((1, 0), (1, 2))],
115s [(3, 4, 5), (4,), (1, 0)],
115s [(4,), (3, 4, 5), (0, 1)],
115s [(4,), (4,), (0, 0)],
115s [(4,), (4,), 0],
115s ],
115s )
115s @pytest.mark.parametrize(
115s "a_format, b_format",
115s [("coo", "coo"), ("coo", "gcxs"), ("gcxs", "coo"), ("gcxs",
"gcxs")],
115s )
115s def test_tensordot(a_shape, b_shape, axes, a_format, b_format):
115s sa = sparse.random(a_shape, density=0.5, format=a_format)
115s sb = sparse.random(b_shape, density=0.5, format=b_format)
115s
115s a = sa.todense()
115s b = sb.todense()
115s
115s a_b = np.tensordot(a, b, axes)
115s
115s # tests for return_type=None
115s sa_sb = sparse.tensordot(sa, sb, axes)
115s sa_b = sparse.tensordot(sa, b, axes)
115s a_sb = sparse.tensordot(a, sb, axes)
115s
115s assert_eq(a_b, sa_sb)
115s assert_eq(a_b, sa_b)
115s assert_eq(a_b, a_sb)
115s if all(isinstance(arr, COO) for arr in [sa, sb]):
115s assert isinstance(sa_sb, COO)
115s else:
115s assert isinstance(sa_sb, GCXS)
115s assert isinstance(sa_b, np.ndarray)
115s assert isinstance(a_sb, np.ndarray)
115s
115s # tests for return_type=COO
115s sa_b = sparse.tensordot(sa, b, axes, return_type=COO)
115s > a_sb = sparse.tensordot(a, sb, axes, return_type=COO)
115s
115s tests/test_dot.py:58:
115s _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ _ _
115s /usr/lib/python3/dist-packages/sparse/_common.py:198: in tensordot
115s res = _dot(at, bt, return_type)
115s /usr/lib/python3/dist-packages/sparse/_common.py:425: in _dot
115s out = GCXS(
115s
/usr/lib/python3/dist-packages/sparse/_compressed/compressed.py:195: in
__init__
115s self._prune()
115s
/usr/lib/python3/dist-packages/sparse/_compressed/compressed.py:817: in
_prune
115s np.cumsum(np.bincount(coords[0], minlength=row_size),
out=indptr[1:])
115s _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ _ _
115s
115s args = (array([7304680739967889201, 3701732606794297453,
1,
115s 1, 2, 2,
115s 3, 3]),)
115s kwargs = {'minlength': 4}
115s relevant_args = (array([7304680739967889201, 3701732606794297453,
1,
115s 1, 2, 2,
115s 3, 3]), None)
115s
115s > ???
115s E ValueError: array is too big; `arr.size * arr.dtype.itemsize`
is larger than the maximum
Bug#1031414: not fixed Re: libgpuarray: i386 test fail with new pocl
Control: reassign -1 src:libgpuarray Control: found -1 0.7.6-13 On Mon, 21 Aug 2023 07:51:27 +0100 "Rebecca N. Palmer" wrote: Control: severity -1 serious That wasn't a fix - log with pocl 4: https://ci.debian.net/data/autopkgtest/testing/i386/libg/libgpuarray/37023715/log.gz Given that this bug is already linked (blocked) by the root cause of this issue, which doesn't seem to get resolved, I consider this bug to not be a pocl issue anymore, but only a libgpuarray issue: its autopkgtest fails. Of course ideally the issue in llvm gets fixed, but while that is waiting for somebody to pick up the work, I suggest to skip the failing test on i386. If you believe that the autopkgtest shows that libgpuarray (or pocl) isn't usable for most usage on i386, than please have it removed from i386 (and prevent a successful build until the issue is resolved). Paul PS: CC the i386 porter to let him know in case he's not aware yet. OpenPGP_signature.asc Description: OpenPGP digital signature -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1050613: src:numba: fails to migrate to testing for too long: triggers autopkgtest failure
Source: numba Version: 0.56.4+dfsg-2 Severity: serious Control: close -1 0.57.1+dfsg-1 X-Debbugs-CC: python-spa...@packages.debian.org Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Control: affects -1 src:python-sparse Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:numba has been trying to migrate for 31 days [2]. Hence, I am filing this bug. The version in unstable triggers failures in python-sparse on amd64 and ppc64el (the rest regressed already last year). If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=numba OpenPGP_signature.asc Description: OpenPGP digital signature -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1043545: numba: autopkgtest runs no tests
Source: numba Version: 0.57.1+dfsg-1 Severity: important Hi, It looks like something went wrong with the last upload as I don't see mention of dropping all tests, but the last log [1] has: Ran 0 tests in 0.000s So no tests were run. [1] https://ci.debian.net/data/autopkgtest/testing/arm64/n/numba/36688390/log.gz https://ci.debian.net/data/autopkgtest/testing/i386/n/numba/36690497/log.gz https://ci.debian.net/data/autopkgtest/testing/ppc64el/n/numba/36691218/log.gz -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1043529: src:giac: fails to migrate to testing for too long: FTBFS
Source: giac Version: 1.9.0.35+dfsg2-1.1 Severity: serious Control: close -1 1.9.0.57+dfsg2-1 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Control: block -1 by 1040889 Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:giac has been trying to migrate for 32 days [2]. Hence, I am filing this bug. The version in unstable fails to build from source as reported in 1040889. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=giac -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1042485: RM: python3-brial [armel armhf mips64el mipsel ppc64el s390x] -- NBS; uninstallable without sagemath
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: br...@packages.debian.org Control: affects -1 + src:brial brial no longer builds python3-brial on architectures where sagemath isn't available, because it wouldn't be installable. There's cruft in unstable from an older version. I think this is also confusing britney2 because the BTS reports that bug 1034443 is affecting unstable but not testing (because that only has fixed versions) and hence blocks migration of brial. Paul -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1034443: fixed in brial 1.2.11-2.1
Control: fixed -1 1.2.11-2 Hi, On Tue, 09 May 2023 14:33:51 + Debian FTP Masters wrote: brial (1.2.11-2.1) unstable; urgency=medium . * Non-Maintainer upload. * Limit architectures for python3-brial package to architectures where sagemath is available (Closes: #1034443). It seems this change was taken over by the consecutive Maintainer upload, but the changelog entry was not. The BTS reads the changelog to conclude which versions are affected by a certain bug and hence concluded that the version in unstable was affected again. Teaching the BTS that the version in unstable is fine to enable migration of brial to testing. Paul OpenPGP_signature Description: OpenPGP digital signature -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1041659: src:vnlog: fails to migrate to testing for too long: uploader built arch:all binaries
Source: vnlog Version: 1.34-2 Severity: serious Control: close -1 1.35-1 Tags: sid trixie pending User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:vnlog has been trying to migrate for 31 days [2]. Hence, I am filing this bug. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. Your package is only blocked because the arch:all binary package(s) aren't built on a buildd. Unfortunately the Debian infrastructure doesn't allow arch:all packages to be properly binNMU'ed. Hence, I will shortly do a no-changes source-only upload to DELAYED/15, closing this bug. Please let me know if I should delay or cancel that upload. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=vnlog OpenPGP_signature Description: OpenPGP digital signature -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1041657: src:asmjit: fails to migrate to testing for too long: FTBFS on armel, armhf and mips64el
Source: asmjit Version: 0.0~git20221210.5b5b0b3-1 Severity: serious Control: close -1 0.0~git20230427.3577608-1 Tags: sid trixie ftbfs User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:asmjit has been trying to migrate for 31 days [2]. Hence, I am filing this bug. The version in unstable failed to build from source on armel, armhf and mips64el where it built successfully in the past. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=asmjit OpenPGP_signature Description: OpenPGP digital signature -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1041472: src:lmfit-py: fails to migrate to testing for too long: autopkgtest regression on i386
Source: lmfit-py Version: 1.1.0-1 Severity: serious Control: close -1 1.2.1-1 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:lmfit-py has been trying to migrate for 31 days [2]. Hence, I am filing this bug. The autopkgtest of the version in unstable fails on i386, where it passed in the past. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=lmfit-py OpenPGP_signature Description: OpenPGP digital signature -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1041213: src:python-xarray: fails to migrate to testing for too long: FTBFS
Source: python-xarray Version: 2023.01.0-1.1 Severity: serious Control: close -1 2023.06.0-1 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Control: block -1 by 1039871 Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:python-xarray has been trying to migrate for 34 days [2]. Hence, I am filing this bug. The package fails to build from source as reported in bug 1039871. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=python-xarray OpenPGP_signature Description: OpenPGP digital signature -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1040962: src:sympy: fails to migrate to testing for too long: autopkgtest regression
Source: sympy Version: 1.11.1-1 Severity: serious Control: close -1 1.12-2 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Control: block -1 by 1040058 Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:sympy has been trying to migrate for 32 days [2]. Hence, I am filing this bug. The package in unstable causes an autopkgtest regression is sagemath as reported in bug 1040058. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=sympy OpenPGP_signature Description: OpenPGP digital signature -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1040058: sympy breaks sagemath autopkgtest: 371 tests failed, up to 200 failures are tolerated
Source: sympy, sagemath Control: found -1 sympy/1.12-2 Control: found -1 sagemath/9.5-6 Severity: serious Tags: sid bookworm User: debian...@lists.debian.org Usertags: breaks needs-update Dear maintainer(s), With a recent upload of sympy the autopkgtest of sagemath fails in testing when that autopkgtest is run with the binary packages of sympy from unstable. It passes when run with only packages from testing. In tabular form: passfail sympy from testing1.12-2 sagemath from testing9.5-6 all others from testingfrom testing I copied some of the output at the bottom of this report. Currently this regression is blocking the migration of sympy to testing [1]. Due to the nature of this issue, I filed this bug report against both packages. Can you please investigate the situation and reassign the bug to the right package? More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=sympy https://ci.debian.net/data/autopkgtest/testing/amd64/s/sagemath/34968116/log.gz 5574s sage -t --random-seed=12767979073566241725300492934726496 sage/src/sage/tests/gap_packages.py # 1 doctest failed 5574s sage -t --random-seed=12767979073566241725300492934726496 sage/src/sage/tests/cmdline.py # 7 doctests failed 5574s sage -t --random-seed=12767979073566241725300492934726496 sage/src/sage/typeset/ascii_art.py # 7 doctests failed 5574s sage -t --random-seed=12767979073566241725300492934726496 sage/src/sage/typeset/character_art.py # 1 doctest failed 5574s sage -t --random-seed=12767979073566241725300492934726496 sage/src/sage/typeset/unicode_art.py # 3 doctests failed 5574s sage -t --random-seed=12767979073566241725300492934726496 sage/src/sage/typeset/character_art_factory.py # 2 doctests failed 5574s -- 5574s Total time for all tests: 5329.1 seconds 5574s cpu time: 8324.6 seconds 5574s cumulative wall time: 10276.3 seconds 5574s Features detected for doctesting: sage.combinat,sage.geometry.polyhedron,sage.graphs,sage.plot,sage.rings.number_field,sage.rings.real_double,sage.symbolic,sagemath_doc_html,sphinx 5574s Pytest is not installed, skip checking tests that rely on it. 5574s Error: 371 tests failed, up to 200 failures are tolerated 5574s make: *** [debian/tests.mk:56: had-few-failures] Error 1 5575s autopkgtest [21:46:07]: test command1 OpenPGP_signature Description: OpenPGP digital signature -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1039917: gemmi breaks finalcif autopkgtest: causes autopkgtest timeout
Source: gemmi, finalcif Control: found -1 gemmi/0.6.2+ds-2 Control: found -1 finalcif/113+dfsg-2 Severity: serious Tags: sid bookworm User: debian...@lists.debian.org Usertags: breaks needs-update Dear maintainer(s), With a recent upload of gemmi the autopkgtest of finalcif fails in testing when that autopkgtest is run with the binary packages of gemmi from unstable. It passes when run with only packages from testing. In tabular form: passfail gemmi from testing0.6.2+ds-2 finalcif from testing113+dfsg-2 all others from testingfrom testing I copied some of the output at the bottom of this report. After the fifth test, there's no output until autopkgtest aborts after 2:47 hours. Normally the test takes 2 to 3 minutes. Currently this regression is blocking the migration of gemmi to testing [1]. Due to the nature of this issue, I filed this bug report against both packages. Can you please investigate the situation and reassign the bug to the right package? More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=gemmi https://ci.debian.net/data/autopkgtest/testing/amd64/f/finalcif/34924025/log.gz 73s = test session starts == 73s platform linux -- Python 3.11.4, pytest-7.2.1, pluggy-1.0.0+repack 73s rootdir: /tmp/autopkgtest-lxc.pb_ivzjf/downtmp/build.E5g/src 73s collected 312 items 73s 73s tests/test_SADABS.py [ 3%] 73s tests/test_atoms.py .. [ 5%] 81s tests/test_author_templates.py . [ 9%] 81s tests/test_bruker_frame.py .. [ 13%] 81s tests/test_ccdc.py ... [ 14%] 10071s tests/test_changes_cif.py .autopkgtest [10:02:06]: ERROR: timed out on command "su -s /bin/bash debci -c set -e; export USER=`id -nu`; . /etc/profile >/dev/null 2>&1 || true; . ~/.profile >/dev/null 2>&1 || true; buildtree="/tmp/autopkgtest-lxc.pb_ivzjf/downtmp/build.E5g/src"; mkdir -p -m 1777 -- "/tmp/autopkgtest-lxc.pb_ivzjf/downtmp/command1-artifacts"; export AUTOPKGTEST_ARTIFACTS="/tmp/autopkgtest-lxc.pb_ivzjf/downtmp/command1-artifacts"; export ADT_ARTIFACTS="$AUTOPKGTEST_ARTIFACTS"; mkdir -p -m 755 "/tmp/autopkgtest-lxc.pb_ivzjf/downtmp/autopkgtest_tmp"; export AUTOPKGTEST_TMP="/tmp/autopkgtest-lxc.pb_ivzjf/downtmp/autopkgtest_tmp"; export ADTTMP="$AUTOPKGTEST_TMP"; export DEBIAN_FRONTEND=noninteractive; export LANG=C.UTF-8; export DEB_BUILD_OPTIONS=parallel=64; unset LANGUAGE LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT LC_IDENTIFICATION LC_ALL;cd "$buildtree"; exec /tmp/autopkgtest-lxc.pb_ivzjf/downtmp/wrapper.sh --script-pid-file=/tmp/autopkgtest_script_pid --stderr=/tmp/autopkgtest-lxc.pb_ivzjf/downtmp/command1-stderr --stdout=/tmp/autopkgtest-lxc.pb_ivzjf/downtmp/command1-stdout -- bash -ec 'xvfb-run pytest-3' ;" (kind: test) 10071s autopkgtest [10:02:06]: test command1 OpenPGP_signature Description: OpenPGP digital signature -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1038125: src:eln: fails to migrate to testing for too long: new build dependencies not available
Source: eln Version: 1.4.6-1 Severity: serious Control: close -1 1.5.0-2 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:eln has been trying to migrate for 81 days [2] (yes, partially because of the freeze). Hence, I am filing this bug. Your package started to build depend on packages not available on all release architectures. You probably need to request removal of your binaries on those architectures, or fix the problem someway else. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=eln OpenPGP_signature Description: OpenPGP digital signature -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1034443: python3-brial: uninstallable on arcitectures where sagemath is unavailable
Hi Tobias, On Sat, 6 May 2023 10:24:41 + Tobias Hansen wrote: Note that we could also just remove python3-sage and the autopkgtest. I assume you mean python3-brial here. Nothing in Debian depends on it Not true (and it's too late in the freeze to do that [1]): paul@mulciber ~ $ reverse-depends python3-brial Reverse-Recommends == * science-mathematics-dev * singular-data Paul PS: please cc me on reply, I'm not subscribed to this bug. [1] https://release.debian.org/testing/freeze_policy.html#appropriate OpenPGP_signature Description: OpenPGP digital signature -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1034443: python3-brial: uninstallable on arcitectures where sagemath is unavailable, breaks building of singular
Hi, On 23-04-2023 23:01, Peter Michael Green wrote: That does leave the question of how brial with this bug migrated to testing in the first place. Whether there was a recent intentional change in britney, whether there was a bug/glitch, or whether it was forced in (and if-so who forced it). I'm pretty sure that if you look at my hints [1], you'll find who did it. I think that in this case I *thought* it better to let brial move with the fix, obviously shortsightedly overlooking this particular effect. Maybe I was wrong doing that, but I'm still unsure. I really dislike hardcoding of the architectures of dependencies, as it's a maintenance burden forever (until sage builds everywhere). I mean, who is going to regularly check if sage builds on more architectures? Paul [1] https://release.debian.org/britney/hints/elbrus OpenPGP_signature Description: OpenPGP digital signature -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1034443: python3-brial: uninstallable on arcitectures where sagemath is unavailable, breaks building of singular
Hi Peter, On 23-04-2023 21:24, Peter Michael Green wrote: That works in some cases, but it's a bad option here for two reasons. 1. It would create a build-dependency loop between brial and sagemath. Which isn't practical problem as long as there is a proper build profile involved, right? But given point 2, I think both the point and this is argument are moot. 2. It would mean that other binary packages built from the brial source package had their architecture list unnecessarily limited. Aha, I missed that detail. There are more arch: binaries build by src:brial. > Technically I even think that this isn't a bug in python3-brial. One of the criteria (indeed the first on the list) for grave is "makes the package in question unusable or mostly so". I consider that a package that cannot be installed is unusable. If I follow that reasoning than about 850 arch:all binaries also have RC bugs: https://qa.debian.org/dose/debcheck/testing_main/1682226002/some.html My understanding has always been that for source packages that build multiple binaries, the test of "is the package unusable" is applied for each binary package individually and that for packages that are built separately for multiple architectures (not arch all packages) it is applied for each architecture individually. I don't think that is officially written down anywhere though. Can you point to a discussion where we might draw the conclusion that this is common practice or consensus? I *personally* [no hats on] find that distinction a bit weird although I can see how we would come to it and also why. This seems to be your real issue. Why file the bug against python3-brial? When an issue involving multiple packages shows up on my radar, I tend to start by filing a bug with the package where a fix could potentially have the most impact and cc the maintainers of other packages that are involved. Ack. And I agree with this approach. However, we are *also* in the Hard Freeze, so RC bugs reports have more severe results if not treated swiftly. If the maintainer of brial came back and said that the fix for bug 1033878 was wrong, and that python3-brial could in-fact be made usable on all architectures then there would. [missing words?] Yes, sure. However, looking at the stack trace in that bug, I agree that the dependency is the most logical solution. Ensuring python3-brial to be useful without that dependency will require patching the code by the looks of it. Paul OpenPGP_signature Description: OpenPGP digital signature -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1034443: python3-brial: uninstallable on arcitectures where sagemath is unavailable, breaks building of singular
Hi Peter, all, On Sat, 15 Apr 2023 15:33:04 +0100 Peter Green wrote: * The architecture list of python3-brial needs to be limited to architectures where python3-sage is available. I claim this is wrong. Would python3-sage one day build on more architectures, this list would need manual updating. Instead of hard-coding the list, it's better to ensure the build doesn't happen or fails on architectures where python3-sage is not available. E.g. by build-depending (ideally with a build profile indicating that the *build* itself works; I suggest ). Technically I even think that this isn't a bug in python3-brial. Assuming the dependency is real and unavoidable, than being uninstallable is bug in the depending on package, but not an RC one. * The build-dependency of singular on python3-brial needs to be either removed or limited to architectures where python3-sage is available This seems to be your real issue. Why file the bug against python3-brial? * Removal of the old python3-brial packages needs to be requested. Assuming something is done to prevent the binaries from building, then yes, obviously. However, why would we consider arch: uninstallable packages different than arch:all uninstallable packages if the reason is the same: depending on a binary that's not build on some arch. Do our tools have different expectations for them? Paul OpenPGP_signature Description: OpenPGP digital signature -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1033907: numba: autopkgtest regression: segmentation fault on arm64
Source: numba Version: 0.56.4+dfsg-2 Severity: serious Control: tags -1 bookworm-ignore User: debian...@lists.debian.org Usertags: regression Dear maintainer(s), Your package has an autopkgtest, great. However, as mentioned in bug #1020445 message 19 it fails since around September 2022 everywhere except amd64 (where it only finishes before timeout on our most powerful host). Can you please investigate the situation and fix it? I copied some of the output on arm64 at the bottom of this report, other architectures have different issues thought. The release team has announced [1] that failing autopkgtest on amd64 and arm64 are considered RC in testing. [Release Team member hat on] Because we're currently in the hard freeze for bookworm, I have marked this bug as bookworm-ignore. Targeted fixes are still welcome. More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://lists.debian.org/debian-devel-announce/2019/07/msg2.html https://ci.debian.net/data/autopkgtest/testing/arm64/n/numba/32471152/log.gz Fatal Python error: Segmentation fault Current thread 0x946c96e0 (most recent call first): File "/usr/lib/python3.11/unittest/case.py", line 579 in _callTestMethod File "/usr/lib/python3.11/unittest/case.py", line 623 in run File "/usr/lib/python3.11/unittest/case.py", line 678 in __call__ File "/usr/lib/python3/dist-packages/numba/testing/main.py", line 665 in __call__ File "/usr/lib/python3.11/multiprocessing/pool.py", line 125 in worker File "/usr/lib/python3.11/multiprocessing/process.py", line 108 in run File "/usr/lib/python3.11/multiprocessing/process.py", line 314 in _bootstrap File "/usr/lib/python3.11/multiprocessing/popen_fork.py", line 71 in _launch File "/usr/lib/python3.11/multiprocessing/popen_fork.py", line 19 in __init__ File "/usr/lib/python3.11/multiprocessing/context.py", line 281 in _Popen File "/usr/lib/python3.11/multiprocessing/process.py", line 121 in start File "/usr/lib/python3.11/multiprocessing/pool.py", line 329 in _repopulate_pool_static File "/usr/lib/python3.11/multiprocessing/pool.py", line 306 in _repopulate_pool File "/usr/lib/python3.11/multiprocessing/pool.py", line 215 in __init__ File "/usr/lib/python3.11/multiprocessing/context.py", line 119 in Pool File "/usr/lib/python3/dist-packages/numba/testing/main.py", line 742 in _run_inner File "/usr/lib/python3.11/unittest/runner.py", line 217 in run File "/usr/lib/python3/dist-packages/numba/testing/main.py", line 796 in run File "/usr/lib/python3.11/unittest/main.py", line 274 in runTests File "/usr/lib/python3/dist-packages/numba/testing/main.py", line 326 in run_tests_real File "/usr/lib/python3/dist-packages/numba/testing/main.py", line 341 in runTests File "/usr/lib/python3.11/unittest/main.py", line 102 in __init__ File "/usr/lib/python3/dist-packages/numba/testing/main.py", line 168 in __init__ File "/usr/lib/python3/dist-packages/numba/testing/__init__.py", line 54 in run_tests File "/usr/lib/python3/dist-packages/numba/testing/_runtests.py", line 25 in _main File "/usr/lib/python3/dist-packages/numba/runtests.py", line 9 in File "", line 88 in _run_code File "", line 198 in _run_module_as_main Extension modules: numpy.core._multiarray_umath, numpy.core._multiarray_tests, numpy.linalg._umath_linalg, numpy.fft._pocketfft_internal, numpy.random._common, numpy.random.bit_generator, numpy.random._bounded_integers, numpy.random._mt19937, numpy.random.mtrand, numpy.random._philox, numpy.random._pcg64, numpy.random._sfc64, numpy.random._generator, numba.core.typeconv._typeconv, numba._helperlib, numba._dynfunc, numba._dispatcher, numba.core.runtime._nrt_python, numba.np.ufunc._internal, numba.experimental.jitclass._box, scipy._lib._ccallback_c, scipy.linalg._fblas, scipy.linalg._flapack, scipy.linalg._cythonized_array_utils, scipy.linalg._flinalg, scipy.linalg._solve_toeplitz, scipy.linalg._matfuncs_sqrtm_triu, scipy.linalg.cython_lapack, scipy.linalg.cython_blas, scipy.linalg._matfuncs_expm, scipy.linalg._decomp_update, scipy.sparse._sparsetools, _csparsetools, scipy.sparse._csparsetools, scipy.sparse.linalg._isolve._iterative, scipy.sparse.linalg._dsolve._superlu, scipy.sparse.linalg._eigen.arpack._arpack, scipy.sparse.csgraph._tools, scipy.sparse.csgraph._shortest_path, scipy.sparse.csgraph._traversal, scipy.sparse.csgraph._min_spanning_tree, scipy.sparse.csgraph._flow, scipy.sparse.csgraph._matching, scipy.sparse.csgraph._reordering, zmq.backend.cython.context, zmq.backend.cython.message, zmq.backend.cython.socket, zmq.backend.cython._device, zmq.backend.cython._poll, zmq.backend.cython._proxy_steerable, zmq.backend.cython._version, zmq.backend.cython.error, zmq.backend.cython.utils, tornado.speedups, numpy.core._umath_tests, _cffi_backend, scipy.special._ufuncs_cxx,
Bug#1033851: python-pyepsg: autopkgtest regression: xml.etree.ElementTree.ParseError: not well-formed (invalid token)
Source: python-pyepsg
Version: 0.4.0-1
Severity: serious
Control: tags -1 bookworm-ignore
User: debian...@lists.debian.org
Usertags: regression
Dear maintainer(s),
Your package has an autopkgtest, great. However, it fails since about
August 2022. Can you please investigate the situation and fix it? I
copied some of the output at the bottom of this report.
The release team has announced [1] that failing autopkgtest on amd64 and
arm64 are considered RC in testing. [Release Team member hat on] Because
we're currently in the hard freeze for bookworm, I have marked this bug
as bookworm-ignore. Targeted fixes are still welcome.
More information about this bug and the reason for filing it can be
found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
Paul
[1] https://lists.debian.org/debian-devel-announce/2019/07/msg2.html
https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-pyepsg/32471275/log.gz
=== FAILURES
===
___ [doctest] pyepsg.CRS.as_esri_wkt
___
129
130 Return the ESRI WKT string which corresponds to the CRS.
131
132 For example::
133
134 >>> print(get(27700).as_esri_wkt()) # doctest: +ELLIPSIS
UNEXPECTED EXCEPTION: ParseError('not well-formed (invalid token): line
1, column 0')
Traceback (most recent call last):
File "/usr/lib/python3.11/doctest.py", line 1351, in __run
exec(compile(example.source, filename, "single",
File "", line 1, in
File "/usr/lib/python3/dist-packages/pyepsg.py", line 288, in get
root = ET.fromstring(xml)
^^
File "/usr/lib/python3.11/xml/etree/ElementTree.py", line 1338, in XML
parser.feed(text)
xml.etree.ElementTree.ParseError: not well-formed (invalid token): line
1, column 0
/usr/lib/python3/dist-packages/pyepsg.py:134: UnexpectedException
OpenPGP_signature
Description: OpenPGP digital signature
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1033835: polyml: autopkgtest regression: output on stderr
Source: polyml Version: 5.7.1-5 Control: found -1 5.7.1-4 Severity: serious Control: tags -1 bookworm-ignore User: debian...@lists.debian.org Usertags: regression Dear maintainer(s), Your package has an autopkgtest, great. However, it fails since July 2020. Can you please investigate the situation and fix it? I copied some of the output at the bottom of this report. The test itself seems to pass, but there's output on stderr, which without the allow-stderr restriction is considered a failure by autopkgtest. The release team has announced [1] that failing autopkgtest on amd64 and arm64 are considered RC in testing. [Release Team member hat on] Because we're currently in the hard freeze for bookworm, I have marked this bug as bookworm-ignore. Targeted fixes are still welcome. More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://lists.debian.org/debian-devel-announce/2019/07/msg2.html https://ci.debian.net/data/autopkgtest/testing/amd64/p/polyml/32128171/log.gz autopkgtest [19:23:44]: test upstream-polyc: [--- /usr/bin/ld: warning: /tmp/polyobj.2070.o: missing .note.GNU-stack section implies executable stack /usr/bin/ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker Test035.ML => Passed Test162.ML => Passed [...] Test026.ML => Passed autopkgtest [19:24:05]: test upstream-polyc: ---] autopkgtest [19:24:05]: test upstream-polyc: - - - - - - - - - - results - - - - - - - - - - upstream-polyc FAIL stderr: /usr/bin/ld: warning: /tmp/polyobj.2070.o: missing .note.GNU-stack section implies executable stack OpenPGP_signature Description: OpenPGP digital signature -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1033702: freefem++: autopkgtest regression: warnings on stderr
Source: freefem++ Version: 4.11+dfsg1-2 Severity: serious Control: tags -1 bookworm-ignore User: debian...@lists.debian.org Usertags: fails-always Dear maintainer(s), Your package has an autopkgtest, great. However, it started to fail in August 2022 on amd64, armhf and i386. Can you please investigate the situation and fix it? I copied some of the output at the bottom of this report. The release team has announced [1] that failing autopkgtest on amd64 and arm64 are considered RC in testing. [Release Team hat on] Because of the timing (we're in hard freeze) I've marked this bug as bookworm-ignore as the problem is "only" warnings. A targeted fix is still welcome (adding allow-stderr restriction for the test, code fixing needs to wait until the release). More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://lists.debian.org/debian-devel-announce/2019/07/msg2.html https://ci.debian.net/data/autopkgtest/testing/amd64/f/freefem++/32183287/log.gz build-and-run-libFAIL stderr: In file included from /usr/include/freefem++/AFunction.hpp:93, autopkgtest [16:24:09]: test build-and-run-lib: - - - - - - - - - - stderr - - - - - - - - - - In file included from /usr/include/freefem++/AFunction.hpp:93, from /usr/include/freefem++/ff++.hpp:21, from /tmp/autopkgtest-lxc.okwz3yij/downtmp/build.NQ2/src/plugin/seq/myfunction.cpp:30: /usr/include/freefem++/String.hpp:195:19: warning: ‘template_Arg1, class _Arg2, class _Result> struct std::binary_function’ is deprecated [-Wdeprecated-declarations] 195 | struct pairless : binary_function,const char *, bool> | ^~~ In file included from /usr/include/c++/12/string:48, from /usr/include/c++/12/bits/locale_classes.h:40, from /usr/include/c++/12/bits/ios_base.h:41, from /usr/include/c++/12/ios:42, from /usr/include/c++/12/istream:38, from /usr/include/c++/12/fstream:38, from /usr/include/freefem++/ff++.hpp:12: /usr/include/c++/12/bits/stl_function.h:131:12: note: declared here 131 | struct binary_function |^~~ OpenPGP_signature Description: OpenPGP digital signature -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1033589: python3-theano: module 'numpy' has no attribute 'bool'.
Package: python3-theano Version: 1.0.5+dfsg-8 Severity: serious Control: affects -1 deepnano Control: found -1 1.1.2+dfsg-3 Dear maintainer(s), I think the autopkgtest of deepnano points out that theano is using what I believe are removed attibutes from numpy. Paul https://ci.debian.net/data/autopkgtest/unstable/amd64/d/deepnano/32446139/log.gz autopkgtest [19:57:01]: test run-test.sh: [--- #1 - deepnano_basecall /usr/lib/python3/dist-packages/theano/scalar/basic.py:2412: FutureWarning: In the future `np.bool` will be defined as the corresponding NumPy scalar. self.ctor = getattr(np, o_type.dtype) Traceback (most recent call last): File "/usr/share/deepnano/basecall.py", line 4, in from rnn_fin import RnnPredictor File "/usr/share/deepnano/rnn_fin.py", line 1, in import theano as th File "/usr/lib/python3/dist-packages/theano/__init__.py", line 83, in from theano import scalar, tensor File "/usr/lib/python3/dist-packages/theano/scalar/__init__.py", line 1, in from .basic import * File "/usr/lib/python3/dist-packages/theano/scalar/basic.py", line 2460, in convert_to_bool = Cast(bool, name="convert_to_bool") ^^ File "/usr/lib/python3/dist-packages/theano/scalar/basic.py", line 2412, in __init__ self.ctor = getattr(np, o_type.dtype) ^ File "/usr/lib/python3/dist-packages/numpy/__init__.py", line 305, in __getattr__ raise AttributeError(__former_attrs__[attr]) AttributeError: module 'numpy' has no attribute 'bool'. `np.bool` was a deprecated alias for the builtin `bool`. To avoid this error in existing code, use `bool` by itself. Doing this will not modify any behavior and is safe. If you specifically wanted the numpy scalar type, use `np.bool_` here. The aliases was originally deprecated in NumPy 1.20; for more details and guidance see the original release note at: https://numpy.org/devdocs/release/1.20.0-notes.html#deprecations. Did you mean: 'bool_'? autopkgtest [19:57:01]: test run-test.sh: ---] OpenPGP_signature Description: OpenPGP digital signature -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1033584: brial: autopkgtest fails: cannot import name 'getargspec' from 'inspect'
Source: brial
Version: 1.2.11-1
Severity: serious
User: debian...@lists.debian.org
Usertags: regression
Dear maintainer(s),
Your package has an autopkgtest, great. However, it fails. Can you
please investigate the situation and fix it? I copied some of the output
at the bottom of this report.
The release team has announced [1] that failing autopkgtest on amd64 and
arm64 are considered RC in testing. In this case it seems to point out
that the python package is close to useless. (If I am reading the signs
wrong, feel free to mark this bug as bookworm-ignore (Release Team
member hat on).)
More information about this bug and the reason for filing it can be
found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
Paul
[1] https://lists.debian.org/debian-devel-announce/2019/07/msg2.html
https://ci.debian.net/data/autopkgtest/testing/amd64/b/brial/32215813/log.gz
autopkgtest [18:27:16]: test autodep8-python3: [---
Testing with python3.11:
/usr/lib/python3/dist-packages/brial/PyPolyBoRi.py:72: DeprecationWarning:
Importing order_dict from here is deprecated. If you need to use it,
please import it directly from sage.rings.polynomial.pbori.pbori
See https://trac.sagemath.org/30332 for details.
OrderCode = type('OrderCode', (object,), dict(order_dict))
/usr/lib/python3/dist-packages/brial/PyPolyBoRi.py:91: DeprecationWarning:
Importing MonomialFactory from here is deprecated. If you need to use
it, please import it directly from sage.rings.polynomial.pbori.pbori
See https://trac.sagemath.org/30332 for details.
Monomial = MonomialFactory()
/usr/lib/python3/dist-packages/brial/PyPolyBoRi.py:92: DeprecationWarning:
Importing PolynomialFactory from here is deprecated. If you need to use
it, please import it directly from sage.rings.polynomial.pbori.pbori
See https://trac.sagemath.org/30332 for details.
Polynomial = PolynomialFactory()
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python3/dist-packages/brial/__init__.py", line 34, in
from .gbcore import groebner_basis
File "/usr/lib/python3/dist-packages/brial/gbcore.py", line 10, in
from inspect import getargspec
ImportError: cannot import name 'getargspec' from 'inspect'
(/usr/lib/python3.11/inspect.py)
autopkgtest [18:27:17]: test autodep8-python3: ---]
OpenPGP_signature
Description: OpenPGP digital signature
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1020445: numba: autopkgtest regression on ppc64el: inf != 0.625
On Fri, 27 Jan 2023 15:35:29 +0100 Bastian Germann wrote: Control: fixed -1 0.56.4+dfsg-1 This seems to have gone away with the latest upload. But numba now fails everywhere, except on amd64 if run on a very powerful host (most of our hosts, it times out). Paul OpenPGP_signature Description: OpenPGP digital signature -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1032390: src:cppad: fails to migrate to testing for too long: FTBFS building arch:all
Source: cppad Version: 2022.00.00.4-1 Severity: serious Control: close -1 2023.00.00.0-1 Tags: sid bookworm User: release.debian@packages.debian.org Usertags: out-of-sync Control: block -1 by 1027954 Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 60 days as having a Release Critical bug in testing [1]. Your package src:cppad has been trying to migrate for 61 days [2]. Hence, I am filing this bug. Your package failed to build while building arch:all, which was reported in bug 1027954. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and bookworm, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html [2] https://qa.debian.org/excuses.php?package=cppad OpenPGP_signature Description: OpenPGP digital signature -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1031414: clinfo breaks libgpuarray autopkgtest on i386: numerical deltas
Hi, On 16-02-2023 23:34, Andreas Beckmann wrote: @elbrus: Why does britney try to migrate clinfo together with pocl? Honestly, I don't know. The logic that does that *is* rather greedy as often it helps (but not always). IMO clinfo should be able to migrate on its own without causing new regressions in testing. It does not have any (transitive) dependency on pocl. I have scheduled the job with only clinfo from unstable and the test passed. So I think clinfo can just migrate after the information becomes available. Thanks. Paul OpenPGP_signature Description: OpenPGP digital signature -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1031414: clinfo breaks libgpuarray autopkgtest on i386: numerical deltas
Source: clinfo, libgpuarray Control: found -1 clinfo/3.0.23.01.25-1 Control: found -1 libgpuarray/0.7.6-13 Severity: serious Tags: sid bookworm User: debian...@lists.debian.org Usertags: breaks needs-update Dear maintainer(s), With a recent upload of clinfo the autopkgtest of libgpuarray fails in testing when that autopkgtest is run with the binary packages of clinfo from unstable. It passes when run with only packages from testing. In tabular form: passfail clinfo from testing3.0.23.01.25-1 libgpuarrayfrom testing0.7.6-13 versioned deps [0] from testingfrom unstable all others from testingfrom testing I copied some of the output at the bottom of this report. Currently this regression is blocking the migration of clinfo to testing [1]. Due to the nature of this issue, I filed this bug report against both packages. Can you please investigate the situation and reassign the bug to the right package? More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [0] You can see what packages were added from the second line of the log file quoted below. The migration software adds source package from unstable to the list if they are needed to install packages from clinfo/3.0.23.01.25-1. I.e. due to versioned dependencies or breaks/conflicts. [1] https://qa.debian.org/excuses.php?package=clinfo https://ci.debian.net/data/autopkgtest/testing/i386/libg/libgpuarray/31439784/log.gz === FAILURES === __ test_ielemwise2_ops_mixed ___ def test_ielemwise2_ops_mixed(): for op in ioperators2: for dtype in dtypes_test: for elem in elems: ielemwise2_ops_mixed(op, dtype, (50,), elem) /usr/lib/python3/dist-packages/pygpu/tests/test_elemwise.py:173: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ /usr/lib/python3/dist-packages/pygpu/tests/support.py:44: in f func(*args, **kwargs) _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ op = , dtype = 'float32', shape = (50,), elem = 0.3 @guard_devsup def ielemwise2_ops_mixed(op, dtype, shape, elem): incr = 0 if op == operator.isub and dtype[0] == 'u': # array elements are smaller than 10 by default, so we avoid underflow incr = 10 c, g = gen_gpuarray(shape, dtype, incr=incr, ctx=context, cls=elemary) try: out_c = op(c, elem) except TypeError: # TODO: currently, we use old Numpy semantic and tolerate more case. # So we can't test that we raise the same error return out_g = op(g, elem) assert out_g is g assert out_c.shape == out_g.shape assert out_c.dtype == out_g.dtype assert numpy.allclose(out_c, numpy.asarray(out_g)) E assert False E+ where False = 0xf3ad35c8>(array([0.16798985, 0.10199559, 0.00094628, 0.284034 , 0.00356799,\n 0.18276209, 0.06017095, 0.12363595, 0.14555043, 0.06383288,\n 0.27849692, 0.23479545, 0.1120947 , 0.03348678, 0.17435497,\n 0.10784233, 0.15038443, 0.08132076, 0.26949704, 0.28150958,\n 0.08847237, 0.07874835, 0.14240652, 0.22457486, 0.02050698,\n 0.24944574, 0.29784787, 0.03708786, 0.23751181, 0.26554942,\n 0.26809436, 0.02403933, 0.23044948, 0.13133025, 0.29589295,\n 0.05166197, 0.07869713, 0.10319626, 0.07735932, 0.241211 ,\n 0.27668405, 0.16557133, 0.26950228, 0.230201 , 0.2993518 ,\n 0.0713675 , 0.02841425, 0.04263723, 0.194592 , 0.2564727 ],\n dtype=float32), array([0.16798979, 0.10199571, 0.00094652, 0.28403443, 0.00356805,\n 0.1827622 , 0.06017077, 0.12363613, 0.14555037, 0.063833 ,\n 0.2784968 , 0.23479551, 0.11209452, 0.03348672, 0.17435497,\n 0.10784221, 0.1503846 , 0.08132076, 0.26949698, 0.28150946,\n 0.08847237, 0.07874823, 0.14240658, 0.22457486, 0.0205071 ,\n 0.24944574, 0.29784793, 0.0370878 , 0.2375117 , 0.26554942,\n 0.26809436, 0.02403933, 0.23044948, 0.13133001, 0.29589337,\n 0.05166197, 0.07869713, 0.10319638, 0.07735932, 0.24121124,\n 0.276684 , 0.16557115, 0.26950234, 0.230201 , 0.29935163,\n 0.07136726, 0.02841425, 0.04263711, 0.19459194, 0.25647253],\n dtype=float32)) E+where = numpy.allclose E+and array([0.16798979, 0.10199571, 0.00094652, 0.28403443, 0.00356805,\n 0.1827622 , 0.06017077, 0.12363613, 0.14555037, 0.063833 ,\n 0.2784968 , 0.23479551, 0.11209452, 0.03348672, 0.17435497,\n 0.10784221, 0.1503846 , 0.08132076, 0.26949698, 0.28150946,\n 0.08847237, 0.07874823,
Bug#1029109: cimg: build dependency gone after tiff transition
Source: cimg Version: 3.1.6+dfsg-6 Severity: serious User: debian...@lists.debian.org Usertag: edos-uninstallable Dear maintainer(s), Dose [1] is reporting issues with your packages. Normally your build dependencies shouldn't be removed from testing without removal all reverse build dependencies too, nor should a package be allowed to migrate unless all build dependencies are candidate for migration too. However, somehow we ended up in the current state and your source package is missing some Build-Depends for some while now. Not being able to build from source in a suite is an RC bug in that suite. Your package Build-Depends on a particular SONAME of the tiff library, but that was dropped in the last tiff transition. Are you sure you need to Build-Depends on the library, it's already pulled in via the tiff header package. Can you please solve the situation by either helping the maintainer of your Build-Depends to enable migration to testing, or by working around the lack of this build dependency? Paul [1] https://qa.debian.org/dose/debcheck/src_testing_main/index.html OpenPGP_signature Description: OpenPGP digital signature -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1027696: src:cqrlib: fails to migrate to testing for too long: FTBFS on i386
Source: cqrlib Version: 1.1.4-1 Severity: serious Control: close -1 1.1.4-2 Tags: sid bookworm ftbfs User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 60 days as having a Release Critical bug in testing [1]. Your package src:cqrlib has been trying to migrate for 61 days [2]. Hence, I am filing this bug. Your packaged failed to build on i386, while it built successfully there in the past. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and bookworm, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html [2] https://qa.debian.org/excuses.php?package=cqrlib OpenPGP_signature Description: OpenPGP digital signature -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1027460: scipy breaks scikit-learn autopkgtest: Segmentation fault
Source: scipy, scikit-learn Control: found -1 scipy/1.8.1-18 Control: found -1 scikit-learn/1.1.2+dfsg-91 Severity: serious Tags: sid bookworm User: debian...@lists.debian.org Usertags: breaks needs-update Dear maintainer(s), With a recent upload of scipy the autopkgtest of scikit-learn fails in testing when that autopkgtest is run with the binary packages of scipy from unstable. It passes when run with only packages from testing. In tabular form: passfail scipy from testing1.8.1-18 scikit-learn from testing1.1.2+dfsg-91 all others from testingfrom testing I copied some of the output at the bottom of this report. Currently this regression is blocking the migration of scipy to testing [1]. Due to the nature of this issue, I filed this bug report against both packages. Can you please investigate the situation and reassign the bug to the right package? More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=scipy https://ci.debian.net/data/autopkgtest/testing/amd64/s/scikit-learn/29794749/log.gz ../../../../usr/lib/python3/dist-packages/sklearn/decomposition/tests/test_kernel_pca.py::test_kernel_pca_raise_not_fitted_error PASSED ../../../../usr/lib/python3/dist-packages/sklearn/decomposition/tests/test_kernel_pca.py::test_32_64_decomposition_shape PASSEDFatal Python error: Segmentation fault Current thread 0x7ff05b47d040 (most recent call first): File "", line 685 in __setitem__ File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 195 in _update_current_test_var File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 178 in pytest_runtest_teardown File "/usr/lib/python3/dist-packages/pluggy/_callers.py", line 39 in _multicall File "/usr/lib/python3/dist-packages/pluggy/_manager.py", line 80 in _hookexec File "/usr/lib/python3/dist-packages/pluggy/_hooks.py", line 265 in __call__ File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 259 in File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 338 in from_call File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 258 in call_runtest_hook File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 219 in call_and_report File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 131 in runtestprotocol File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 111 in pytest_runtest_protocol File "/usr/lib/python3/dist-packages/pluggy/_callers.py", line 39 in _multicall File "/usr/lib/python3/dist-packages/pluggy/_manager.py", line 80 in _hookexec File "/usr/lib/python3/dist-packages/pluggy/_hooks.py", line 265 in __call__ File "/usr/lib/python3/dist-packages/_pytest/main.py", line 347 in pytest_runtestloop File "/usr/lib/python3/dist-packages/pluggy/_callers.py", line 39 in _multicall File "/usr/lib/python3/dist-packages/pluggy/_manager.py", line 80 in _hookexec File "/usr/lib/python3/dist-packages/pluggy/_hooks.py", line 265 in __call__ File "/usr/lib/python3/dist-packages/_pytest/main.py", line 322 in _main File "/usr/lib/python3/dist-packages/_pytest/main.py", line 268 in wrap_session File "/usr/lib/python3/dist-packages/_pytest/main.py", line 315 in pytest_cmdline_main File "/usr/lib/python3/dist-packages/pluggy/_callers.py", line 39 in _multicall File "/usr/lib/python3/dist-packages/pluggy/_manager.py", line 80 in _hookexec File "/usr/lib/python3/dist-packages/pluggy/_hooks.py", line 265 in __call__ File "/usr/lib/python3/dist-packages/_pytest/config/__init__.py", line 164 in main File "/usr/lib/python3/dist-packages/_pytest/config/__init__.py", line 187 in console_main File "/usr/lib/python3/dist-packages/pytest/__main__.py", line 5 in File "", line 88 in _run_code File "", line 198 in _run_module_as_main Extension modules: sklearn.__check_build._check_build, numpy.core._multiarray_umath, numpy.core._multiarray_tests, numpy.linalg._umath_linalg, numpy.fft._pocketfft_internal, numpy.random._common, numpy.random.bit_generator, numpy.random._bounded_integers, numpy.random._mt19937, numpy.random.mtrand, numpy.random._philox, numpy.random._pcg64, numpy.random._sfc64, numpy.random._generator, scipy._lib._ccallback_c, scipy.sparse._sparsetools, scipy.sparse._csparsetools, scipy.sparse.csgraph._tools, scipy.sparse.csgraph._shortest_path, scipy.sparse.csgraph._traversal, scipy.sparse.csgraph._min_spanning_tree, scipy.sparse.csgraph._flow, scipy.sparse.csgraph._matching, scipy.sparse.csgraph._reordering, sklearn.utils.murmurhash, lz4._version, lz4.frame._frame, scipy.spatial._ckdtree, scipy._lib.messagestream, scipy.spatial._qhull, scipy.spatial._voronoi, scipy.linalg._fblas, scipy.linalg._flapack, scipy.linalg._cythonized_array_utils, scipy.linalg._flinalg,
Bug#1018954: Can't open perl script "/usr/share/vtk9/doxygen//doc_header2doxygen.pl": No such file or directory
Hi, On Fri, 2 Sep 2022 15:15:50 +0200 Mathieu Malaterre wrote: Source: vtk9 Version: 9.1.0+really9.1.0+dfsg2-4 This is yet the same issue again, gdcm will need the file doc_header2doxygen.pl In vtk7 it could be found in two locations: % dpkg -S /usr/share/vtk-7.1/doxygen/doc_header2doxygen.pl libvtk7-dev: /usr/share/vtk-7.1/doxygen/doc_header2doxygen.pl % dpkg -S /usr/share/doc/vtk7/doxygen/doc_header2doxygen.pl.gz vtk7-doc: /usr/share/doc/vtk7/doxygen/doc_header2doxygen.pl.gz Please provide at least one in vtk9* packages. It seems that file has been dropped from the upstream vtk* sources (at least I couldn't find it anymore in vtk9 salsa git archive). So I guess that if gdcm needs it for its build, it's better if gdcm took the copy on board. Paul OpenPGP_signature Description: OpenPGP digital signature -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1026912: hypre: autopkgtest regularly timeouts on armhf
Source: hypre Version: 2.18.2-1 Severity: serious User: debian...@lists.debian.org Usertags: timeout Control: found -1 2.25.0-2 2.26.0-2 2.22.1-3 Dear maintainer(s), Your package has an autopkgtest, great. However, it fails regularly on armhf. What's worse, it regularly fails because it seems to hang and eventually times out due to autopkgtest. Can you please investigate the situation and fix it? I copied some of the output at the bottom of this report. The release team has announced [1] that failing autopkgtest on amd64 and arm64 are considered RC in testing. Also tests that time out (while normally running in much less time) are bad for our infrastructure. I have added your package to our reject_list and will remove it once this bug is closed. More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://lists.debian.org/debian-devel-announce/2019/07/msg2.html https://ci.debian.net/data/autopkgtest/testing/armhf/h/hypre/29021897/log.gz Building ij_mv ... mpicc -o ij_mv ij_mv.o -L/lib -lHYPRE -Wl,-rpath,/lib -L/usr/lib/arm-linux-gnueabihf/openmpi/lib -lmpi -lm mpicc -I/usr/include/hypre -I/usr/include/superlu -I/usr/include/superlu-dist -I/usr/lib/arm-linux-gnueabihf/openmpi/include -I/usr/lib/arm-linux-gnueabihf/openmpi/include/openmpi -c -o ij_mm.o ij_mm.c Building ij_mm ... mpicc -o ij_mm ij_mm.o -L/lib -lHYPRE -Wl,-rpath,/lib -L/usr/lib/arm-linux-gnueabihf/openmpi/lib -lmpi -lm mpicc -I/usr/include/hypre -I/usr/include/superlu -I/usr/include/superlu-dist -I/usr/lib/arm-linux-gnueabihf/openmpi/include -I/usr/lib/arm-linux-gnueabihf/openmpi/include/openmpi -c zboxloop.c -o zboxloop.obj Building zboxloop ... mpicc -o zboxloop zboxloop.obj -L/lib -lHYPRE -Wl,-rpath,/lib -L/usr/lib/arm-linux-gnueabihf/openmpi/lib -lmpi -lm Running tests for HYPRE testing began at Mon Dec 5 09:15:39 CST 2022 running TEST_ams ... autopkgtest [12:02:11]: ERROR: timed out on command "su -s /bin/bash debci OpenPGP_signature Description: OpenPGP digital signature -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1026351: pandas: autopkgtest on i386 needs update for new version of numpy: AssertionError
Source: pandas
Version: 1.3.5+dfsg-6
Severity: serious
X-Debbugs-CC: nu...@packages.debian.org
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:numpy
Dear maintainer(s),
With a recent upload of numpy the autopkgtest of xmds2 fails in testing
on i386 when that autopkgtest is run with the binary packages of numpy
from unstable. It passes when run with only packages from testing. In
tabular form:
passfail
numpy from testing1:1.23.5-2
xmds2 from testing1.3.5+dfsg-6
all others from testingfrom testing
I copied some of the output at the bottom of this report.
Currently this regression is blocking the migration of numpy to testing
[1]. Of course, numpy shouldn't just break your autopkgtest (or even
worse, your package), but it seems to me that the change in numpy was
intended and your package needs to update to the new situation.
If this is a real problem in your package (and not only in your
autopkgtest), the right binary package(s) from numpy should really add a
versioned Breaks on the unfixed version of (one of your) package(s).
Note: the Breaks is nice even if the issue is only in the autopkgtest as
it helps the migration software to figure out the right versions to
combine in the tests.
More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
Paul
[1] https://qa.debian.org/excuses.php?package=numpy
https://ci.debian.net/data/autopkgtest/testing/i386/p/pandas/29451939/log.gz
=== FAILURES
===
_
TestDateRanges.test_date_range_int64_overflow_stride_endpoint_different_signs
_
self = object at 0xebec9538>
@pytest.mark.slow
def
test_date_range_int64_overflow_stride_endpoint_different_signs(self):
# cases where stride * periods overflow int64 and stride/endpoint
# have different signs
start = Timestamp("2262-02-23")
end = Timestamp("1969-11-14")
expected = date_range(start=start, end=end, freq="-1H")
assert expected[0] == start
assert expected[-1] == end
dti = date_range(end=end, periods=len(expected), freq="-1H")
> tm.assert_index_equal(dti, expected)
E AssertionError: Index are different
E
E Index length are different
E [left]: 0, DatetimeIndex([], dtype='datetime64[ns]', freq='-1H')
E [right]: 2562049, DatetimeIndex(['2262-02-23 00:00:00',
'2262-02-22 23:00:00',
E '2262-02-22 22:00:00', '2262-02-22 21:00:00',
E '2262-02-22 20:00:00', '2262-02-22 19:00:00',
E '2262-02-22 18:00:00', '2262-02-22 17:00:00',
E '2262-02-22 16:00:00', '2262-02-22 15:00:00',
E ...
E '1969-11-14 09:00:00', '1969-11-14 08:00:00',
E '1969-11-14 07:00:00', '1969-11-14 06:00:00',
E '1969-11-14 05:00:00', '1969-11-14 04:00:00',
E '1969-11-14 03:00:00', '1969-11-14 02:00:00',
E '1969-11-14 01:00:00', '1969-11-14 00:00:00'],
E dtype='datetime64[ns]', length=2562049, freq='-1H')
/usr/lib/python3/dist-packages/pandas/tests/indexes/datetimes/test_date_range.py:161:
AssertionError
=== warnings summary
===
OpenPGP_signature
Description: OpenPGP digital signature
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1026349: sasview: autopkgtest needs update for new version of numpy: module 'numpy' has no attribute 'asscalar'
Source: sasview
Version: 5.0.5-3
Severity: serious
X-Debbugs-CC: nu...@packages.debian.org
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:numpy
Dear maintainer(s),
With a recent upload of numpy the autopkgtest of sasview fails in
testing when that autopkgtest is run with the binary packages of numpy
from unstable. It passes when run with only packages from testing. In
tabular form:
passfail
numpy from testing1:1.23.5-2
sasviewfrom testing5.0.5-3
all others from testingfrom testing
I copied some of the output at the bottom of this report.
Currently this regression is blocking the migration of numpy to testing
[1]. Of course, numpy shouldn't just break your autopkgtest (or even
worse, your package), but it seems to me that the change in numpy was
intended and your package needs to update to the new situation.
If this is a real problem in your package (and not only in your
autopkgtest), the right binary package(s) from numpy should really add a
versioned Breaks on the unfixed version of (one of your) package(s).
Note: the Breaks is nice even if the issue is only in the autopkgtest as
it helps the migration software to figure out the right versions to
combine in the tests.
More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
Paul
[1] https://qa.debian.org/excuses.php?package=numpy
https://ci.debian.net/data/autopkgtest/testing/amd64/s/sasview/29465796/log.gz
=== FAILURES
===
__ TestBasicComponent.test_iq
__
self = testMethod=test_iq>
def test_iq(self):
"""
Test iq calculation
"""
q = 0.11
v1 = 8.0*math.pi**2/q * self.invertor.d_max
*math.sin(q*self.invertor.d_max)
v1 /= ( math.pi**2 - (q*self.invertor.d_max)**2.0 )
pars = numpy.ones(1)
self.assertAlmostEqual(self.invertor.iq(pars, q), v1, 2)
test/pr_inversion/utest_invertor.py:171: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
/usr/lib/python3/dist-packages/sas/sascalc/pr/invertor.py:315: in iq
return Pinvertor.iq(self, out, q) + self.background
/usr/lib/python3/dist-packages/sas/sascalc/pr/p_invertor.py:339: in iq
return np.asscalar(iq_val)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _
attr = 'asscalar'
def __getattr__(attr):
# Warn for expired attributes, and return a dummy function
# that always raises an exception.
try:
msg = __expired_functions__[attr]
except KeyError:
pass
else:
warnings.warn(msg, DeprecationWarning, stacklevel=2)
def _expired(*args, **kwds):
raise RuntimeError(msg)
return _expired
# Emit warnings for deprecated attributes
try:
val, msg = __deprecated_attrs__[attr]
except KeyError:
pass
else:
warnings.warn(msg, DeprecationWarning, stacklevel=2)
return val
# Importing Tester requires importing all of UnitTest which
is not a
# cheap import Since it is mainly used in test suits, we lazy
import it
# here to save on the order of 10 ms of import time for most users
#
# The previous way Tester was imported also had a side effect
of adding
# the full `numpy.testing` namespace
if attr == 'testing':
import numpy.testing as testing
return testing
elif attr == 'Tester':
from .testing import Tester
return Tester
> raise AttributeError("module {!r} has no attribute "
"{!r}".format(__name__, attr))
E AttributeError: module 'numpy' has no attribute 'asscalar'
/usr/lib/python3/dist-packages/numpy/__init__.py:311: AttributeError
__ TestBasicComponent.test_pr
__
self = testMethod=test_pr>
def test_pr(self):
"""
Test pr calculation
"""
r = 10.0
v1 = 2.0*r*math.sin(math.pi*r/self.invertor.d_max)
pars = numpy.ones(1)
self.assertAlmostEqual(self.invertor.pr(pars, r), v1, 2)
test/pr_inversion/utest_invertor.py:180: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
/usr/lib/python3/dist-packages/sas/sascalc/pr/p_invertor.py:380: in pr
return np.asscalar(pr_val)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _
attr = 'asscalar'
def __getattr__(attr):
# Warn for expired attributes, and return a dummy function
# that always raises an exception.
Bug#1026347: python-dtcwt: autopkgtest needs update for new version of numpy: IndexError
Source: python-dtcwt
Version: 0.12.0-3
Severity: serious
X-Debbugs-CC: nu...@packages.debian.org
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:numpy
Dear maintainer(s),
With a recent upload of numpy the autopkgtest of python-dtcwt fails in
testing when that autopkgtest is run with the binary packages of numpy
from unstable. It passes when run with only packages from testing. In
tabular form:
passfail
numpy from testing1:1.23.5-2
python-dtcwt from testing0.12.0-3
all others from testingfrom testing
I copied some of the output at the bottom of this report.
Currently this regression is blocking the migration of numpy to testing
[1]. Of course, numpy shouldn't just break your autopkgtest (or even
worse, your package), but it seems to me that the change in numpy was
intended and your package needs to update to the new situation.
If this is a real problem in your package (and not only in your
autopkgtest), the right binary package(s) from numpy should really add a
versioned Breaks on the unfixed version of (one of your) package(s).
Note: the Breaks is nice even if the issue is only in the autopkgtest as
it helps the migration software to figure out the right versions to
combine in the tests.
More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
Paul
[1] https://qa.debian.org/excuses.php?package=numpy
https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-dtcwt/29465794/log.gz
=== FAILURES
===
___ test_estimatereg
___
def test_estimatereg():
nlevels = 6
trans = Transform2d()
t1 = trans.forward(f1, nlevels=nlevels)
t2 = trans.forward(f2, nlevels=nlevels)
avecs = estimatereg(t1, t2)
tests/test_registration.py:31: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
/usr/lib/python3/dist-packages/dtcwt/registration.py:368: in estimatereg
qts += dtcwt.sampling.rescale(_boxfilter(x, 3), avecs.shape[:2],
method='bilinear')
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _
X = array([[[ 1.20862440e+05, -6.87922429e+02, 0.e+00, ...,
0.e+00, 0.e+00, 0.000...[
9.03364731e+04, -2.12328587e+03, 8.28084336e+04, ...,
4.19311988e+01, -4.19288899e+01, 4.06605564e+01]]])
kernel_size = 3
def _boxfilter(X, kernel_size):
"""
INTERNAL
A simple box filter implementation.
"""
if kernel_size % 2 == 0:
raise ValueError('Kernel size must be odd')
for axis_idx in xrange(2):
slices = [slice(None),] * len(X.shape)
out = X
for delta in xrange(1, 1+(kernel_size-1)//2):
slices[axis_idx] = dtcwt.utils.reflect(
np.arange(X.shape[axis_idx]) + delta, -0.5,
X.shape[axis_idx]-0.5)
out = out + X[slices]
E IndexError: only integers, slices (`:`), ellipsis
(`...`), numpy.newaxis (`None`) and integer or boolean arrays are valid
indices
/usr/lib/python3/dist-packages/dtcwt/registration.py:439: IndexError
=== warnings summary
===
tests/test_againstmatlab.py: 1 warning
tests/test_colifilt.py: 3 warnings
tests/test_ifm1.py: 12 warnings
tests/test_ifm2.py: 54 warnings
tests/test_xfm1.py: 14 warnings
tests/test_xfm2.py: 26 warnings
tests/test_xfm3.py: 2208 warnings
/usr/lib/python3/dist-packages/dtcwt/numpy/lowlevel.py:236:
DeprecationWarning: `np.int` is a deprecated alias for the builtin
`int`. To silence this warning, use `int` by itself. Doing this will not
modify any behavior and is safe. When replacing `np.int`, you may wish
to use e.g. `np.int64` or `np.int32` to specify the precision. If you
wish to review your current use, check the release note link for
additional information.
Deprecated in NumPy 1.20; for more details and guidance:
https://numpy.org/devdocs/release/1.20.0-notes.html#deprecations
xe = reflect(np.arange(-m2, r+m2, dtype=np.int), -0.5, r-0.5)
tests/test_againstmatlab.py: 1299 warnings
tests/test_colfilter.py: 6 warnings
tests/test_ifm1.py: 12 warnings
tests/test_ifm2.py: 48 warnings
tests/test_registration.py: 12 warnings
tests/test_xfm1.py: 24 warnings
tests/test_xfm2.py: 98 warnings
tests/test_xfm3.py: 7788 warnings
/usr/lib/python3/dist-packages/dtcwt/numpy/lowlevel.py:74:
DeprecationWarning: `np.int` is a deprecated alias for the builtin
`int`. To silence this warning, use `int` by itself. Doing this will not
modify any behavior and is safe. When replacing `np.int`, you may wish
to use e.g. `np.int64` or `np.int32`
Bug#1026346: petsc4py: autopkgtest needs update for new version of numpy: OverflowError: Python int too large to convert to C int
Source: petsc4py Version: 3.18.2-1 Severity: serious X-Debbugs-CC: nu...@packages.debian.org Tags: sid bookworm User: debian...@lists.debian.org Usertags: needs-update Control: affects -1 src:numpy Dear maintainer(s), With a recent upload of numpy the autopkgtest of petsc4py fails in testing when that autopkgtest is run with the binary packages of numpy from unstable. It passes when run with only packages from testing. In tabular form: passfail numpy from testing1:1.23.5-2 petsc4py from testing3.18.2-1 all others from testingfrom testing I copied some of the output at the bottom of this report. Currently this regression is blocking the migration of numpy to testing [1]. Of course, numpy shouldn't just break your autopkgtest (or even worse, your package), but it seems to me that the change in numpy was intended and your package needs to update to the new situation. If this is a real problem in your package (and not only in your autopkgtest), the right binary package(s) from numpy should really add a versioned Breaks on the unfixed version of (one of your) package(s). Note: the Breaks is nice even if the issue is only in the autopkgtest as it helps the migration software to figure out the right versions to combine in the tests. More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=numpy https://ci.debian.net/data/autopkgtest/testing/amd64/p/petsc4py/29469875/log.gz Running petsc4py demos using PETSC_DIR=/usr/lib/petsc Run demos (single processor) with python3 make: Entering directory '/tmp/autopkgtest-lxc.2k3drj0o/downtmp/build.8C2/src/test-demos' make -C petsc-examples make[1]: Entering directory '/tmp/autopkgtest-lxc.2k3drj0o/downtmp/build.8C2/src/test-demos/petsc-examples' make -C ksp make[2]: Entering directory '/tmp/autopkgtest-lxc.2k3drj0o/downtmp/build.8C2/src/test-demos/petsc-examples/ksp' python3 ex2.py - Serial OK mpiexec -n 2 python3 ex2.py - Parallel OK python3 ex23.py - Serial OK mpiexec -n 2 python3 ex23.py - Parallel OK make[2]: Leaving directory '/tmp/autopkgtest-lxc.2k3drj0o/downtmp/build.8C2/src/test-demos/petsc-examples/ksp' make[1]: Leaving directory '/tmp/autopkgtest-lxc.2k3drj0o/downtmp/build.8C2/src/test-demos/petsc-examples' make -C binary-io make[1]: Entering directory '/tmp/autopkgtest-lxc.2k3drj0o/downtmp/build.8C2/src/test-demos/binary-io' python3 matvecio.py rm -f matrix-*.dat* vector-*.dat* rm -f *.py[co] rm -f -r __pycache__ make[1]: Leaving directory '/tmp/autopkgtest-lxc.2k3drj0o/downtmp/build.8C2/src/test-demos/binary-io' make -C kspsolve make[1]: Entering directory '/tmp/autopkgtest-lxc.2k3drj0o/downtmp/build.8C2/src/test-demos/kspsolve' python3 test_mat_cg.py [0]PETSC ERROR: Unable to open display on :0.0 Make sure your COMPUTE NODES are authorized to connect to this X server and either your DISPLAY variable is set or you use the -display name option [0]PETSC ERROR: PETSc unable to use X windows proceeding without graphics iterations: 46 residual norm: 0.000303767 iterations: 46 residual norm: 0.000303767 python3 test_mat_ksp.py [0]PETSC ERROR: Unable to open display on :0.0 Make sure your COMPUTE NODES are authorized to connect to this X server and either your DISPLAY variable is set or you use the -display name option [0]PETSC ERROR: PETSc unable to use X windows proceeding without graphics rm -f *.py[co] rm -f -r __pycache__ make[1]: Leaving directory '/tmp/autopkgtest-lxc.2k3drj0o/downtmp/build.8C2/src/test-demos/kspsolve' make -C bratu2d make[1]: Entering directory '/tmp/autopkgtest-lxc.2k3drj0o/downtmp/build.8C2/src/test-demos/bratu2d' python3 bratu2d.py -impl python [0]PETSC ERROR: Unable to open display on :0.0 Make sure your COMPUTE NODES are authorized to connect to this X server and either your DISPLAY variable is set or you use the -display name option [0]PETSC ERROR: PETSc unable to use X windows proceeding without graphics f2py3 --noarch --f90flags='' -DF2PY_REPORT_ON_ARRAY_COPY=1 -c bratu2df90.f90 -m bratu2df90 running build running config_cc INFO: unifing config_cc, config, build_clib, build_ext, build commands --compiler options running config_fc INFO: unifing config_fc, config, build_clib, build_ext, build commands --fcompiler options running build_src INFO: build_src INFO: building extension "bratu2df90" sources INFO: f2py options: [] INFO: f2py:> /tmp/tmp50_plbq5/src.linux-x86_64-3.10/bratu2df90module.c creating /tmp/tmp50_plbq5/src.linux-x86_64-3.10 Reading fortran codes... Reading file 'bratu2df90.f90' (format:free) Post-processing... Block: bratu2df90 Block: bratu2d Post-processing (stage 2)... Building modules... Building module "bratu2df90"... Generating possibly empty wrappers"
Bug#1026345: libgpuarray: autopkgtest needs update for new version of numpy: KeyError: 'Unknown flag'
Source: libgpuarray Version: 0.7.6-11 Severity: serious X-Debbugs-CC: nu...@packages.debian.org Tags: sid bookworm User: debian...@lists.debian.org Usertags: needs-update Control: affects -1 src:numpy Dear maintainer(s), With a recent upload of numpy the autopkgtest of libgpuarray fails in testing when that autopkgtest is run with the binary packages of numpy from unstable. It passes when run with only packages from testing. In tabular form: passfail numpy from testing1:1.23.5-2 libgpuarrayfrom testing0.7.6-11 all others from testingfrom testing I copied some of the output at the bottom of this report. Currently this regression is blocking the migration of numpy to testing [1]. Of course, numpy shouldn't just break your autopkgtest (or even worse, your package), but it seems to me that the change in numpy was intended and your package needs to update to the new situation. If this is a real problem in your package (and not only in your autopkgtest), the right binary package(s) from numpy should really add a versioned Breaks on the unfixed version of (one of your) package(s). Note: the Breaks is nice even if the issue is only in the autopkgtest as it helps the migration software to figure out the right versions to combine in the tests. More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=numpy https://ci.debian.net/data/autopkgtest/testing/amd64/libg/libgpuarray/29465793/log.gz === FAILURES === __ test_zeros __ def test_zeros(): for shp in [(), (0,), (5,), (0, 0), (1, 0), (0, 1), (6, 7), (0, 0, 0), (1, 0, 0), (0, 1, 0), (0, 0, 1), (4, 8, 9), (1, 8, 9)]: for order in ["C", "F"]: for dtype in dtypes_all: zeros(shp, order, dtype) /usr/lib/python3/dist-packages/pygpu/tests/test_gpu_ndarray.py:224: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ /usr/lib/python3/dist-packages/pygpu/tests/support.py:44: in f func(*args, **kwargs) /usr/lib/python3/dist-packages/pygpu/tests/test_gpu_ndarray.py:231: in zeros check_all(x, y) /usr/lib/python3/dist-packages/pygpu/tests/support.py:108: in check_all check_meta(x, y) /usr/lib/python3/dist-packages/pygpu/tests/support.py:104: in check_meta check_flags(x, y) _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ x = gpuarray.array(0., dtype=float32), y = array(0., dtype=float32) def check_flags(x, y): assert isinstance(x, gpuarray.GpuArray) if y.size == 0 and y.flags["C_CONTIGUOUS"] and y.flags["F_CONTIGUOUS"]: # Different numpy version have different value for # C_CONTIGUOUS in that case. pass elif x.flags["C_CONTIGUOUS"] != y.flags["C_CONTIGUOUS"]: # Numpy 1.10 can set c/f contiguous more frequently by # ignoring strides on dimensions of size 1. assert x.flags["C_CONTIGUOUS"] is True, (x.flags, y.flags) assert x.flags["F_CONTIGUOUS"] is False, (x.flags, y.flags) assert y.flags["C_CONTIGUOUS"] is False, (x.flags, y.flags) # That depend of numpy version. # assert y.flags["F_CONTIGUOUS"] is True, (x.flags, y.flags) else: if not (skip_single_f and x.shape == ()): # Numpy below 1.6.0 does not have a consistent handling of # f-contiguous for 0-d arrays if not any([s == 1 for s in x.shape]): # Numpy 1.10 can set f contiguous more frequently by # ignoring strides on dimensions of size 1. assert x.flags["F_CONTIGUOUS"] == y.flags["F_CONTIGUOUS"], ( x.flags, y.flags) else: assert x.flags["F_CONTIGUOUS"] assert x.flags["WRITEABLE"] == y.flags["WRITEABLE"], (x.flags, y.flags) # Don't check for OWNDATA since it is always true for a GpuArray assert x.flags["ALIGNED"] == y.flags["ALIGNED"], (x.flags, y.flags) assert x.flags["UPDATEIFCOPY"] == y.flags["UPDATEIFCOPY"], (x.flags, y.flags) E KeyError: 'Unknown flag' /usr/lib/python3/dist-packages/pygpu/tests/support.py:85: KeyError _ test_zeros_no_dtype __ def test_zeros_no_dtype(): # no dtype and order param x = pygpu.zeros((), context=ctx) y = numpy.zeros(()) check_meta(x, y) /usr/lib/python3/dist-packages/pygpu/tests/test_gpu_ndarray.py:238: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Bug#1026330: sundials: autopkgtest regression: output on stderr
Source: sundials Version: 6.4.1+dfsg1-1 Severity: serious User: debian...@lists.debian.org Usertags: regression Dear maintainer(s), With a recent upload of sundials the autopkgtest of sundials fails in testing when that autopkgtest is run with the binary packages of sundials from unstable. It passes when run with only packages from testing. In tabular form: passfail sundials from testing6.4.1+dfsg1-1 all others from testingfrom testing I copied some of the output at the bottom of this report. The test of you package itself passes, but it does print output on stderr. By default, without the allow-stderr restriction, autopkgtest treats output on stderr as failure. Currently this regression is blocking the migration to testing [1]. Can you please investigate the situation and fix it? More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=sundials https://ci.debian.net/data/autopkgtest/testing/amd64/s/sundials/29469892/log.gz ../src/ark_heat2D.cpp: In function ‘int main(int, char**)’: ../src/ark_heat2D.cpp:276:40: warning: ‘int SUNLinSolSetPrintLevel_PCG(SUNLinearSolver, int)’ is deprecated: Use SUNLogger interface instead [-Wdeprecated-declarations] 276 | flag = SUNLinSolSetPrintLevel_PCG(LS, 1); | ~~^~~ In file included from ../src/ark_heat2D.cpp:58: /usr/include/sunlinsol/sunlinsol_pcg.h:112:5: note: declared here 112 | int SUNLinSolSetPrintLevel_PCG(SUNLinearSolver LS, int print_level); | ^~ ../src/ark_heat2D.cpp:279:38: warning: ‘int SUNLinSolSetInfoFile_PCG(SUNLinearSolver, FILE*)’ is deprecated: Use SUNLogger_SetInfoFilename instead [-Wdeprecated-declarations] 279 | flag = SUNLinSolSetInfoFile_PCG(LS, diagfp); | ^~~~ /usr/include/sunlinsol/sunlinsol_pcg.h:109:5: note: declared here 109 | int SUNLinSolSetInfoFile_PCG(SUNLinearSolver LS, | ^~~~ ../src/ark_heat2D.cpp:290:42: warning: ‘int SUNLinSolSetPrintLevel_SPGMR(SUNLinearSolver, int)’ is deprecated: Use SUNLogger interface instead [-Wdeprecated-declarations] 290 | flag = SUNLinSolSetPrintLevel_SPGMR(LS, 1); | ^~~ In file included from ../src/ark_heat2D.cpp:59: /usr/include/sunlinsol/sunlinsol_spgmr.h:128:5: note: declared here 128 | int SUNLinSolSetPrintLevel_SPGMR(SUNLinearSolver LS, int print_level); | ^~~~ ../src/ark_heat2D.cpp:293:40: warning: ‘int SUNLinSolSetInfoFile_SPGMR(SUNLinearSolver, FILE*)’ is deprecated: Use SUNLogger_SetInfoFilename instead [-Wdeprecated-declarations] 293 | flag = SUNLinSolSetInfoFile_SPGMR(LS, diagfp); | ~~^~~~ /usr/include/sunlinsol/sunlinsol_spgmr.h:125:5: note: declared here 125 | int SUNLinSolSetInfoFile_SPGMR(SUNLinearSolver LS, | ^~ ../src/ark_heat2D.cpp:397:33: warning: ‘int ARKStepSetDiagnostics(void*, FILE*)’ is deprecated: use SUNDIALS_LOGGER instead [-Wdeprecated-declarations] 397 | flag = ARKStepSetDiagnostics(arkode_mem, diagfp); |~^~~~ In file included from ../src/ark_heat2D.cpp:56: /usr/include/arkode/arkode_arkstep.h:260:5: note: declared here 260 | int ARKStepSetDiagnostics(void *arkode_mem, FILE *diagfp); | ^ build: OK Analytical ODE test problem: lamda = -100 reltol = 1e-06 abstol = 1e-10 ty0y1y2 -- 0.0050 0.70328 0.70627 0.41005 0.0100 0.52267 0.52865 0.05232 0.0150 0.41249 0.42145 -0.16456 0.0200 0.34504 0.35697 -0.29600 0.0250 0.30350 0.31838 -0.37562 0.0300 0.27767 0.29551 -0.42382 0.0350 0.26138 0.28216 -0.45296 0.0400 0.25088 0.27460 -0.47053 0.0450 0.24389 0.27053 -0.48109 0.0500 0.23903 0.26858 -0.48740 -- Final Solver Statistics: Internal solver steps = 67 (attempted = 69) Total RHS evals: Fe = 0, Fi = 693 Total linear solver setups = 22 Total RHS evals for setting up the linear system = 0 Total number of Jacobian evaluations = 3 Total number of Newton iterations = 345 Total number of linear solver convergence failures = 0 Total number of error test failures = 2 run: demo1 OK 2D Heat PDE test problem: - kx = 1 ky = 1 forcing= 1 tf = 1 xu = 1 yu = 1 nx = 32 ny = 32 dx = 0.0322581 dy =
Bug#1026055: lapack breaks openturns autopkgtest: undefined reference to `ztrsyl3_' (and 3 more)
Hi Sébastien, On 13-12-2022 21:59, Sébastien Villemot wrote: The problem is that atlas needs to be recompiled against lapack 3.11.0. Which has been done in atlas 3.10.3-13. But atlas itself cannot migrate to testing because of #1025699. While I understand recompiling "solves" the issue, normally this error "undefined reference" hints at removal of symbols. Normally that should be handled by a SONAME bump which would trigger auto trackers to be generated for the transition. Such trackers notify the release team of transitions and they can trigger rebuilds (you know that drill, including the transition bug filing for coordination). Why do you think that a SONAME bump wasn't the right solution in this case? Paul OpenPGP_signature Description: OpenPGP digital signature -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1026055: lapack breaks openturns autopkgtest: undefined reference to `ztrsyl3_' (and 3 more)
Source: lapack, openturns Control: found -1 lapack/3.11.0-2 Control: found -1 openturns/1.20-5 Severity: serious Tags: sid bookworm User: debian...@lists.debian.org Usertags: breaks needs-update Dear maintainer(s), With a recent upload of lapack the autopkgtest of openturns fails in testing when that autopkgtest is run with the binary packages of lapack from unstable. It passes when run with only packages from testing. In tabular form: passfail lapack from testing3.11.0-2 openturns from testing1.20-5 all others from testingfrom testing I copied some of the output at the bottom of this report. Currently this regression is blocking the migration of lapack to testing [1]. Due to the nature of this issue, I filed this bug report against both packages. Can you please investigate the situation and reassign the bug to the right package? More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=lapack https://ci.debian.net/data/autopkgtest/testing/amd64/o/openturns/29301955/log.gz /usr/bin/ld: /lib/x86_64-linux-gnu/liblapacke.so.3: undefined reference to `ztrsyl3_' /usr/bin/ld: /lib/x86_64-linux-gnu/liblapacke.so.3: undefined reference to `ctrsyl3_' /usr/bin/ld: /lib/x86_64-linux-gnu/liblapacke.so.3: undefined reference to `dtrsyl3_' /usr/bin/ld: /lib/x86_64-linux-gnu/liblapacke.so.3: undefined reference to `strsyl3_' collect2: error: ld returned 1 exit status autopkgtest [01:16:06]: test cxx-Ceres-test OpenPGP_signature Description: OpenPGP digital signature -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1025867: src:spyder: unsatisfied build dependency in testing: python3-qdarkstyle (< 3.1~)
Source: spyder Version: 5.3.3+dfsg-3 Severity: serious Tags: sid bookworm User: debian...@lists.debian.org Usertags: edos-uninstallable Dear maintainer(s), Dose [1] is reporting a build issue with your package, it's missing a build dependency. Obviously your build dependencies shouldn't be removed from testing, but unfortunately there are multiple scenarios where that can happen nevertheless. To uphold our social contract, Debian requires that packages can be rebuild from source in the suite we are shipping them, so currently this is a serious issue with your package in testing. Can you please investigate the situation and figure out how to resolve it? Regularly, if the build dependency is available in unstable, helping the maintainer of your Build-Depends to enable migration to testing is a great way to solve the issue. If your build dependency is gone from unstable and testing, you'll have to fix the build process in some other way. Paul Note: this bug report was sent after some quick manual checks using a template. Please reach out to me if you believe I made a mistake in my process. [1] https://qa.debian.org/dose/debcheck/src_testing_main/latest/amd64.html OpenPGP_signature Description: OpenPGP digital signature -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1025777: qcustomplot: autopkgtest regression: collect2: error: ld returned 1 exit status
Source: qcustomplot Version: 2.1.0+dfsg1-3 Severity: serious User: debian...@lists.debian.org Usertags: regression Dear maintainer(s), With a recent upload of qcustomplot the autopkgtest of qcustomplot fails in testing when that autopkgtest is run with the binary packages of qcustomplot from unstable. It passes when run with only packages from testing. In tabular form: passfail qcustomplotfrom testing2.1.0+dfsg1-3 all others from testingfrom testing I copied some of the output at the bottom of this report. Currently this regression is blocking the migration to testing [1]. Can you please investigate the situation and fix it? More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=qcustomplot https://ci.debian.net/data/autopkgtest/testing/amd64/q/qcustomplot/29128978/log.gz -- The CXX compiler identification is GNU 12.2.0 -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Check for working CXX compiler: /usr/bin/c++ - skipped -- Detecting CXX compile features -- Detecting CXX compile features - done -- Configuring done -- Generating done -- Build files have been written to: /tmp/tmp.nJIgKdAyYp/build [ 16%] Automatic MOC and UIC for target plots [ 16%] Built target plots_autogen [ 33%] Building CXX object CMakeFiles/plots.dir/plots_autogen/mocs_compilation.cpp.o [ 50%] Building CXX object CMakeFiles/plots.dir/main.cpp.o [ 66%] Building CXX object CMakeFiles/plots.dir/mainwindow.cpp.o [ 83%] Building CXX object CMakeFiles/plots.dir/axistag.cpp.o [100%] Linking CXX executable plots /usr/bin/ld: CMakeFiles/plots.dir/mainwindow.cpp.o: in function `MainWindow::MainWindow(QWidget*)': mainwindow.cpp:(.text+0x13e): undefined reference to `QCustomPlot::QCustomPlot(QWidget*)' /usr/bin/ld: mainwindow.cpp:(.text+0x182): undefined reference to `QCPAxis::setTickLabels(bool)' /usr/bin/ld: mainwindow.cpp:(.text+0x1eb): undefined reference to `QCPLayerable::setVisible(bool)' /usr/bin/ld: mainwindow.cpp:(.text+0x203): undefined reference to `QCustomPlot::axisRect(int) const' /usr/bin/ld: mainwindow.cpp:(.text+0x215): undefined reference to `QCPAxisRect::addAxis(QCPAxis::AxisType, QCPAxis*)' /usr/bin/ld: mainwindow.cpp:(.text+0x22d): undefined reference to `QCustomPlot::axisRect(int) const' /usr/bin/ld: mainwindow.cpp:(.text+0x23f): undefined reference to `QCPAxisRect::axis(QCPAxis::AxisType, int) const' /usr/bin/ld: mainwindow.cpp:(.text+0x24c): undefined reference to `QCPAxis::setPadding(int)' /usr/bin/ld: mainwindow.cpp:(.text+0x264): undefined reference to `QCustomPlot::axisRect(int) const' /usr/bin/ld: mainwindow.cpp:(.text+0x276): undefined reference to `QCPAxisRect::axis(QCPAxis::AxisType, int) const' /usr/bin/ld: mainwindow.cpp:(.text+0x283): undefined reference to `QCPAxis::setPadding(int)' /usr/bin/ld: mainwindow.cpp:(.text+0x2a6): undefined reference to `QCustomPlot::axisRect(int) const' /usr/bin/ld: mainwindow.cpp:(.text+0x2b8): undefined reference to `QCPAxisRect::axis(QCPAxis::AxisType, int) const' /usr/bin/ld: mainwindow.cpp:(.text+0x2d5): undefined reference to `QCustomPlot::addGraph(QCPAxis*, QCPAxis*)' /usr/bin/ld: mainwindow.cpp:(.text+0x311): undefined reference to `QCustomPlot::axisRect(int) const' /usr/bin/ld: mainwindow.cpp:(.text+0x323): undefined reference to `QCPAxisRect::axis(QCPAxis::AxisType, int) const' /usr/bin/ld: mainwindow.cpp:(.text+0x340): undefined reference to `QCustomPlot::addGraph(QCPAxis*, QCPAxis*)' /usr/bin/ld: mainwindow.cpp:(.text+0x3b2): undefined reference to `QCPAbstractPlottable::setPen(QPen const&)' /usr/bin/ld: mainwindow.cpp:(.text+0x417): undefined reference to `QCPAbstractPlottable::setPen(QPen const&)' /usr/bin/ld: CMakeFiles/plots.dir/mainwindow.cpp.o: in function `MainWindow::timerSlot()': mainwindow.cpp:(.text+0x884): undefined reference to `QCPGraph::addData(double, double)' /usr/bin/ld: mainwindow.cpp:(.text+0x991): undefined reference to `QCPGraph::addData(double, double)' /usr/bin/ld: mainwindow.cpp:(.text+0x9aa): undefined reference to `QCPAxis::rescale(bool)' /usr/bin/ld: mainwindow.cpp:(.text+0x9cc): undefined reference to `QCPAbstractPlottable::rescaleValueAxis(bool, bool) const' /usr/bin/ld: mainwindow.cpp:(.text+0x9ee): undefined reference to `QCPAbstractPlottable::rescaleValueAxis(bool, bool) const' /usr/bin/ld: mainwindow.cpp:(.text+0xa4a): undefined reference to `QCPAxis::setRange(double, double, Qt::AlignmentFlag)' /usr/bin/ld: mainwindow.cpp:(.text+0xbbf): undefined reference to `QCustomPlot::replot(QCustomPlot::RefreshPriority)' /usr/bin/ld: CMakeFiles/plots.dir/axistag.cpp.o: in function `AxisTag::AxisTag(QCPAxis*)': axistag.cpp:(.text+0xc4): undefined reference to `QCPItemTracer::QCPItemTracer(QCustomPlot*)' /usr/bin/ld: axistag.cpp:(.text+0x100): undefined reference
Bug#1025358: src:python-xarray: fails to migrate to testing for too long: autopkgtest regression
Source: python-xarray Version: 2022.06.0-7 Severity: serious Control: close -1 2022.11.0-2 Tags: sid bookworm User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 60 days as having a Release Critical bug in testing [1]. Your package src:python-xarray has been trying to migrate for 61 days [2]. Hence, I am filing this bug. One of the recent version of your package caused its autopkgtest to fail everywhere. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and bookworm, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html [2] https://qa.debian.org/excuses.php?package=python-xarray OpenPGP_signature Description: OpenPGP digital signature -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1025196: zfp: (autopkgtest) needs update for python3.11: No module named 'zfpy'
Source: zfp Version: 1.0.0-3 Severity: serious Tags: sid bookworm User: debian...@lists.debian.org Usertags: needs-update User: debian-pyt...@lists.debian.org Usertags: python3.11 Control: affects -1 src:python3-defaults Dear maintainer(s), We are in the transition of adding python3.11 as a supported Python version [0]. With a recent upload of python3-defaults the autopkgtest of zfp fails in testing when that autopkgtest is run with the binary packages of python3-defaults from unstable. It passes when run with only packages from testing. In tabular form: passfail python3-defaults from testing3.10.6-3 zfpfrom testing1.0.0-3 all others from testingfrom testing I copied some of the output at the bottom of this report. Currently this regression is blocking the migration of python3-defaults to testing [1]. https://docs.python.org/3/whatsnew/3.11.html lists what's new in Python3.11, it may help to identify what needs to be updated. More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [0] https://bugs.debian.org/1021984 [1] https://qa.debian.org/excuses.php?package=python3-defaults https://ci.debian.net/data/autopkgtest/testing/amd64/z/zfp/28796454/log.gz Testing with python3.11: Traceback (most recent call last): File "", line 1, in ModuleNotFoundError: No module named 'zfpy' autopkgtest [01:18:36]: test autodep8-python3 OpenPGP_signature Description: OpenPGP digital signature -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1025194: tpot: (autopkgtest) needs update for python3.11: module 'inspect' has no attribute 'getargspec'
Source: tpot Version: 0.11.7+dfsg-4 Severity: serious Tags: sid bookworm User: debian...@lists.debian.org Usertags: needs-update User: debian-pyt...@lists.debian.org Usertags: python3.11 Control: affects -1 src:python3-defaults Dear maintainer(s), We are in the transition of adding python3.11 as a supported Python version [0]. With a recent upload of python3-defaults the autopkgtest of tpot fails in testing when that autopkgtest is run with the binary packages of python3-defaults from unstable. It passes when run with only packages from testing. In tabular form: passfail python3-defaults from testing3.10.6-3 tpot from testing0.11.7+dfsg-4 all others from testingfrom testing I copied some of the output at the bottom of this report. Currently this regression is blocking the migration of python3-defaults to testing [1]. https://docs.python.org/3/whatsnew/3.11.html lists what's new in Python3.11, it may help to identify what needs to be updated. More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [0] https://bugs.debian.org/1021984 [1] https://qa.debian.org/excuses.php?package=python3-defaults https://ci.debian.net/data/autopkgtest/testing/amd64/t/tpot/28796450/log.gz == ERROR: Assert that get_params returns the exact dictionary of parameters used by TPOT. -- Traceback (most recent call last): File "/usr/lib/python3/dist-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/tmp/autopkgtest-lxc.aob2cy93/downtmp/autopkgtest_tmp/python3.11/tests/tpot_tests.py", line 480, in test_get_params initializer = inspect.getargspec(TPOTBase.__init__) ^^ AttributeError: module 'inspect' has no attribute 'getargspec' -- Ran 249 tests in 50.080s OpenPGP_signature Description: OpenPGP digital signature -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1025189: spyder: (autopkgtest) needs update for python3.11: Signal sig_response(QString, PyQt_PyObject) not emitted after 30000 ms
Source: spyder
Version: 5.3.3+dfsg-3
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
User: debian-pyt...@lists.debian.org
Usertags: python3.11
Control: affects -1 src:python3-defaults
Dear maintainer(s),
We are in the transition of adding python3.11 as a supported Python
version [0]. With a recent upload of python3-defaults the autopkgtest of
spyder fails in testing when that autopkgtest is run with the binary
packages of python3-defaults from unstable. It passes when run with only
packages from testing. In tabular form:
passfail
python3-defaults from testing3.10.6-3
spyder from testing5.3.3+dfsg-3
all others from testingfrom testing
I copied some of the output at the bottom of this report.
Currently this regression is blocking the migration of python3-defaults
to testing [1]. https://docs.python.org/3/whatsnew/3.11.html lists
what's new in Python3.11, it may help to identify what needs to be updated.
More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
Paul
[0] https://bugs.debian.org/1021984
[1] https://qa.debian.org/excuses.php?package=python3-defaults
https://ci.debian.net/data/autopkgtest/testing/amd64/s/spyder/28806955/log.gz
=== FAILURES
===
__ test_plugin_first_response_request
__
qtbot_module =
completion_receiver =
(0x7fb1231c7a30>,
object at 0x7fb11dcc7910>)
@pytest.mark.order(1)
def test_plugin_first_response_request(qtbot_module,
completion_receiver):
completion, receiver = completion_receiver
# Parameters to perform a textDocument/didOpen request
params = {
'file': 'test2.py',
'language': 'python',
'version': 2,
'text': "# This is some text with some classe\nimport os\n\n",
'response_instance': receiver,
'offset': 1,
'diff': '',
'selection_start': 0,
'selection_end': 0,
'codeeditor': receiver,
'requires_response': False
}
with qtbot_module.waitSignal(receiver.sig_response,
timeout=3) as blocker:
completion.send_request(
'python', CompletionRequestTypes.DOCUMENT_DID_OPEN, params)
params = {
'file': 'test2.py',
'line': 1,
'column': 8,
'offset': 43,
'diff': '',
'response_instance': receiver,
'codeeditor': receiver,
'requires_response': True
}
with qtbot_module.waitSignal(receiver.sig_response,
timeout=3) as blocker:
completion.send_request(
'python', CompletionRequestTypes.DOCUMENT_HOVER, params)
_, response = blocker.args
assert len(response['params']) > 0
E AssertionError: assert 0 > 0
E+ where 0 = len('')
spyder/plugins/completion/tests/test_plugin.py:253: AssertionError
___ test_get_signature[lsp_provider]
___
lsp_client_and_completion =
(object at 0x7fb11da1eb00>,
object at 0x7fb11da1ed40>)
qtbot =
@pytest.mark.order(3)
def test_get_signature(lsp_client_and_completion, qtbot):
client, completion = lsp_client_and_completion
# Parameters to perform a textDocument/didChange request
params = {
'file': 'test.py',
'language': 'python',
'version': 1,
'text': "import os\nos.walk(\n",
'codeeditor': completion,
'requires_response': False
}
# Perform the request
with qtbot.waitSignal(completion.sig_response, timeout=3):
E pytestqt.exceptions.TimeoutError: Signal
sig_response(QString,PyQt_PyObject) not emitted after 3 ms
spyder/plugins/completion/providers/languageserver/tests/test_client.py:76:
TimeoutError
__ test_get_completions[lsp_provider]
__
lsp_client_and_completion =
(object at 0x7fb11da1eb00>,
object at 0x7fb11da1ed40>)
qtbot =
@pytest.mark.order(3)
def test_get_completions(lsp_client_and_completion, qtbot):
client, completion = lsp_client_and_completion
# Parameters to perform a textDocument/didChange request
params = {
'file': 'test.py',
'language': 'python',
'version': 1,
'text': "import o",
'codeeditor': completion,
'requires_response': False
}
# Perform the request
with qtbot.waitSignal(completion.sig_response, timeout=3):
E pytestqt.exceptions.TimeoutError: Signal
sig_response(QString,PyQt_PyObject) not emitted after 3 ms
Bug#1025188: spyder-unittest: (autopkgtest) needs update for python3.11: AssertionError
Source: spyder-unittest
Version: 0.5.1-1
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
User: debian-pyt...@lists.debian.org
Usertags: python3.11
Control: affects -1 src:python3-defaults
Dear maintainer(s),
We are in the transition of adding python3.11 as a supported Python
version [0]. With a recent upload of python3-defaults the autopkgtest of
spyder-unittest fails in testing when that autopkgtest is run with the
binary packages of python3-defaults from unstable. It passes when run
with only packages from testing. In tabular form:
passfail
python3-defaults from testing3.10.6-3
spyder-unittestfrom testing0.5.1-1
all others from testingfrom testing
I copied some of the output at the bottom of this report.
Currently this regression is blocking the migration of python3-defaults
to testing [1]. https://docs.python.org/3/whatsnew/3.11.html lists
what's new in Python3.11, it may help to identify what needs to be updated.
More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
Paul
[0] https://bugs.debian.org/1021984
[1] https://qa.debian.org/excuses.php?package=python3-defaults
https://ci.debian.net/data/autopkgtest/testing/amd64/s/spyder-unittest/28796442/log.gz
=== FAILURES
===
__ test_run_tests_using_unittest_and_display_results
___
qtbot =
widget = 0x7fd5120a29e0>
tmpdir =
local('/tmp/pytest-of-debci/pytest-0/test_run_tests_using_unittest_0')
monkeypatch = <_pytest.monkeypatch.MonkeyPatch object at 0x7fd5120bba10>
def test_run_tests_using_unittest_and_display_results(
qtbot, widget, tmpdir, monkeypatch):
"""Basic check."""
os.chdir(tmpdir.strpath)
testfilename = tmpdir.join('test_foo.py').strpath
with open(testfilename, 'w') as f:
f.write("import unittest\n"
"class MyTest(unittest.TestCase):\n"
" def test_ok(self): self.assertEqual(1+1, 2)\n"
" def test_fail(self): self.assertEqual(1+1, 3)\n")
MockQMessageBox = Mock()
monkeypatch.setattr('spyder_unittest.widgets.unittestgui.QMessageBox',
MockQMessageBox)
config = Config(wdir=tmpdir.strpath, framework='unittest',
coverage=False)
with qtbot.waitSignal(widget.sig_finished, timeout=1,
raising=True):
widget.run_tests(config)
MockQMessageBox.assert_not_called()
model = widget.testdatamodel
assert model.rowCount() == 2
assert model.index(0, 0).data(Qt.DisplayRole) == 'FAIL'
assert model.index(0, 1).data(Qt.DisplayRole) == 't.M.test_fail'
E AssertionError: assert 't.M.test_f.test_fail' == 't.M.test_fail'
E - t.M.test_fail
E + t.M.test_f.test_fail
E ? +++
/tmp/autopkgtest-lxc.6hcp6lhp/downtmp/build.hJ9/src/spyder_unittest/widgets/tests/test_unittestgui.py:210:
AssertionError
OpenPGP_signature
Description: OpenPGP digital signature
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1025183: silx: (autopkgtest) needs update for python3.11: Segmentation fault
Source: silx Version: 1.1.0+dfsg-3 Severity: serious Tags: sid bookworm User: debian...@lists.debian.org Usertags: needs-update User: debian-pyt...@lists.debian.org Usertags: python3.11 Control: affects -1 src:python3-defaults Dear maintainer(s), We are in the transition of adding python3.11 as a supported Python version [0]. With a recent upload of python3-defaults the autopkgtest of silx fails in testing when that autopkgtest is run with the binary packages of python3-defaults from unstable. It passes when run with only packages from testing. In tabular form: passfail python3-defaults from testing3.10.6-3 silx from testing1.1.0+dfsg-3 all others from testingfrom testing I copied some of the output at the bottom of this report. Currently this regression is blocking the migration of python3-defaults to testing [1]. https://docs.python.org/3/whatsnew/3.11.html lists what's new in Python3.11, it may help to identify what needs to be updated. More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [0] https://bugs.debian.org/1021984 [1] https://qa.debian.org/excuses.php?package=python3-defaults https://ci.debian.net/data/autopkgtest/testing/amd64/s/silx/28796438/log.gz Testing with python3.11: = test session starts == platform linux -- Python 3.11.0+, pytest-7.1.2, pluggy-1.0.0+repack rootdir: /tmp/autopkgtest-lxc.btdfxoen/downtmp/autopkgtest_tmp plugins: xvfb-2.0.0 collected 1796 items app/test/test_convert.py [ 0%] app/view/test/test_launcher.py . [ 0%] app/view/test/test_view.py FF [ 2%] gui/data/test/test_arraywidget.py sFFF [ 3%] gui/data/test/test_dataviewer.py FFF [ 5%] FFF [ 5%] gui/data/test/test_numpyaxesselector.py F [ 6%] gui/data/test/test_textformatter.py [ 7%] gui/dialog/test/test_colormapdialog.py FEFEFEFEFEFEFEFEFEFEFEFEFEFEFEFEFE [ 8%] FEFE [ 8%] gui/dialog/test/test_datafiledialog.py F [ 10%] FF [ 10%] gui/dialog/test/test_imagefiledialog.py Fatal Python error: Segmentation fault Current thread 0x7fb29d541040 (most recent call first): File "/usr/lib/python3/dist-packages/silx/gui/utils/testutils.py", line 334 in qWait File "/usr/lib/python3/dist-packages/silx/gui/utils/testutils.py", line 393 in qWaitForDestroy File "/usr/lib/python3/dist-packages/silx/gui/dialog/test/test_imagefiledialog.py", line 124 in _deleteDialog File "/usr/lib/python3/dist-packages/silx/gui/dialog/test/test_imagefiledialog.py", line 151 in tearDown File "/usr/lib/python3.11/unittest/case.py", line 584 in _callTearDown File "/usr/lib/python3.11/unittest/case.py", line 626 in run File "/usr/lib/python3.11/unittest/case.py", line 678 in __call__ File "/usr/lib/python3/dist-packages/_pytest/unittest.py", line 327 in runtest File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 166 in pytest_runtest_call File "/usr/lib/python3/dist-packages/pluggy/_callers.py", line 39 in _multicall File "/usr/lib/python3/dist-packages/pluggy/_manager.py", line 80 in _hookexec File "/usr/lib/python3/dist-packages/pluggy/_hooks.py", line 265 in __call__ File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 259 in File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 338 in from_call File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 258 in call_runtest_hook File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 219 in call_and_report File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 130 in runtestprotocol File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 111 in pytest_runtest_protocol File "/usr/lib/python3/dist-packages/pluggy/_callers.py", line 39 in _multicall File "/usr/lib/python3/dist-packages/pluggy/_manager.py", line 80 in _hookexec File "/usr/lib/python3/dist-packages/pluggy/_hooks.py", line 265 in __call__ File "/usr/lib/python3/dist-packages/_pytest/main.py", line 347 in pytest_runtestloop File "/usr/lib/python3/dist-packages/pluggy/_callers.py", line 39 in _multicall File "/usr/lib/python3/dist-packages/pluggy/_manager.py", line 80 in _hookexec File "/usr/lib/python3/dist-packages/pluggy/_hooks.py", line 265 in __call__ File "/usr/lib/python3/dist-packages/_pytest/main.py", line 322 in _main File "/usr/lib/python3/dist-packages/_pytest/main.py", line 268 in wrap_session File "/usr/lib/python3/dist-packages/_pytest/main.py", line 315 in pytest_cmdline_main File "/usr/lib/python3/dist-packages/pluggy/_callers.py", line 39 in _multicall File "/usr/lib/python3/dist-packages/pluggy/_manager.py", line 80 in _hookexec File
Bug#1025181: qiskit-ibmq-provider: (autopkgtest) needs update for python3.11: module 'asyncio' has no attribute 'coroutine'
Source: qiskit-ibmq-provider
Version: 0.4.6-4
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
User: debian-pyt...@lists.debian.org
Usertags: python3.11
Control: affects -1 src:python3-defaults
Dear maintainer(s),
We are in the transition of adding python3.11 as a supported Python
version [0]. With a recent upload of python3-defaults the autopkgtest of
qiskit-ibmq-provider fails in testing when that autopkgtest is run with
the binary packages of python3-defaults from unstable. It passes when
run with only packages from testing. In tabular form:
passfail
python3-defaults from testing3.10.6-3
qiskit-ibmq-provider from testing0.4.6-4
all others from testingfrom testing
I copied some of the output at the bottom of this report.
Currently this regression is blocking the migration of python3-defaults
to testing [1]. https://docs.python.org/3/whatsnew/3.11.html lists
what's new in Python3.11, it may help to identify what needs to be updated.
More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
Paul
[0] https://bugs.debian.org/1021984
[1] https://qa.debian.org/excuses.php?package=python3-defaults
https://ci.debian.net/data/autopkgtest/testing/amd64/q/qiskit-ibmq-provider/28796435/log.gz
Testing with python3.11:
/usr/lib/python3/dist-packages/qiskit/validation/fields/custom.py:76:
DeprecationWarning: `np.float` is a deprecated alias for the builtin
`float`. To silence this warning, use `float` by itself. Doing this will
not modify any behavior and is safe. If you specifically wanted the
numpy scalar type, use `np.float64` here.
Deprecated in NumPy 1.20; for more details and guidance:
https://numpy.org/devdocs/release/1.20.0-notes.html#deprecations
numpy.integer, numpy.float,
/usr/lib/python3/dist-packages/qiskit/__init__.py:53: RuntimeWarning:
Could not import the Aer provider from the qiskit-aer package. Install
qiskit-aer or check your installation.
warnings.warn('Could not import the Aer provider from the qiskit-aer '
/usr/lib/python3/dist-packages/qiskit/providers/ibmq/api/rest/validation.py:35:
RemovedInMarshmallow4Warning: The 'missing' argument to fields is
deprecated. Use 'load_default' instead.
_status = String(required=False, missing=None)
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python3/dist-packages/qiskit/__init__.py", line 58, in
from qiskit.providers.ibmq import IBMQ
File
"/usr/lib/python3/dist-packages/qiskit/providers/ibmq/__init__.py", line
20, in
from .ibmqfactory import IBMQFactory
File
"/usr/lib/python3/dist-packages/qiskit/providers/ibmq/ibmqfactory.py",
line 21, in
from .accountprovider import AccountProvider
File
"/usr/lib/python3/dist-packages/qiskit/providers/ibmq/accountprovider.py",
line 26, in
from .api.clients import AccountClient
File
"/usr/lib/python3/dist-packages/qiskit/providers/ibmq/api/clients/__init__.py",
line 18, in
from .account import AccountClient
File
"/usr/lib/python3/dist-packages/qiskit/providers/ibmq/api/clients/account.py",
line 35, in
from .websocket import WebsocketClient
File
"/usr/lib/python3/dist-packages/qiskit/providers/ibmq/api/clients/websocket.py",
line 113, in
class WebsocketClient(BaseClient):
File
"/usr/lib/python3/dist-packages/qiskit/providers/ibmq/api/clients/websocket.py",
line 126, in WebsocketClient
@asyncio.coroutine
^
AttributeError: module 'asyncio' has no attribute 'coroutine'. Did you
mean: 'coroutines'?
autopkgtest [01:16:47]: test autodep8-python3
OpenPGP_signature
Description: OpenPGP digital signature
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1025180: qiskit-aer: (autopkgtest) needs update for python3.11: No module named 'qiskit.transpiler.passes.routing.cython.stochastic_swap.utils'
Source: qiskit-aer
Version: 0.4.1-2
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
User: debian-pyt...@lists.debian.org
Usertags: python3.11
Control: affects -1 src:python3-defaults
Dear maintainer(s),
We are in the transition of adding python3.11 as a supported Python
version [0]. With a recent upload of python3-defaults the autopkgtest of
qiskit-aer fails in testing when that autopkgtest is run with the binary
packages of python3-defaults from unstable. It passes when run with only
packages from testing. In tabular form:
passfail
python3-defaults from testing3.10.6-3
qiskit-aer from testing0.4.1-2
all others from testingfrom testing
I copied some of the output at the bottom of this report.
Currently this regression is blocking the migration of python3-defaults
to testing [1]. https://docs.python.org/3/whatsnew/3.11.html lists
what's new in Python3.11, it may help to identify what needs to be updated.
More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
Paul
[0] https://bugs.debian.org/1021984
[1] https://qa.debian.org/excuses.php?package=python3-defaults
https://ci.debian.net/data/autopkgtest/testing/amd64/q/qiskit-aer/28796434/log.gz
Testing with python3.11:
/usr/lib/python3/dist-packages/qiskit/validation/fields/custom.py:76:
DeprecationWarning: `np.float` is a deprecated alias for the builtin
`float`. To silence this warning, use `float` by itself. Doing this will
not modify any behavior and is safe. If you specifically wanted the
numpy scalar type, use `np.float64` here.
Deprecated in NumPy 1.20; for more details and guidance:
https://numpy.org/devdocs/release/1.20.0-notes.html#deprecations
numpy.integer, numpy.float,
/usr/lib/python3/dist-packages/qiskit/__init__.py:53: RuntimeWarning:
Could not import the Aer provider from the qiskit-aer package. Install
qiskit-aer or check your installation.
warnings.warn('Could not import the Aer provider from the qiskit-aer '
/usr/lib/python3/dist-packages/qiskit/__init__.py:60: RuntimeWarning:
Could not import the IBMQ provider from the qiskit-ibmq-provider
package. Install qiskit-ibmq-provider or check your installation.
warnings.warn('Could not import the IBMQ provider from the '
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python3/dist-packages/qiskit/__init__.py", line 67, in
from qiskit.execute import execute
File "/usr/lib/python3/dist-packages/qiskit/execute.py", line 24, in
from qiskit.compiler import transpile, assemble
File "/usr/lib/python3/dist-packages/qiskit/compiler/__init__.py",
line 35, in
from .transpile import transpile
File "/usr/lib/python3/dist-packages/qiskit/compiler/transpile.py",
line 16, in
from qiskit.transpiler import Layout, CouplingMap
File "/usr/lib/python3/dist-packages/qiskit/transpiler/__init__.py",
line 76, in
from .transpile_circuit import transpile_circuit
File
"/usr/lib/python3/dist-packages/qiskit/transpiler/transpile_circuit.py",
line 17, in
from qiskit.transpiler.preset_passmanagers import
(level_0_pass_manager,
File
"/usr/lib/python3/dist-packages/qiskit/transpiler/preset_passmanagers/__init__.py",
line 31, in
from .level0 import level_0_pass_manager
File
"/usr/lib/python3/dist-packages/qiskit/transpiler/preset_passmanagers/level0.py",
line 23, in
from qiskit.transpiler.passes import Unroller
File
"/usr/lib/python3/dist-packages/qiskit/transpiler/passes/__init__.py",
line 116, in
from .routing import BasicSwap
File
"/usr/lib/python3/dist-packages/qiskit/transpiler/passes/routing/__init__.py",
line 19, in
from .stochastic_swap import StochasticSwap
File
"/usr/lib/python3/dist-packages/qiskit/transpiler/passes/routing/stochastic_swap.py",
line 30, in
from .cython.stochastic_swap.utils import nlayout_from_layout
ModuleNotFoundError: No module named
'qiskit.transpiler.passes.routing.cython.stochastic_swap.utils'
autopkgtest [01:17:01]: test autodep8-python3
OpenPGP_signature
Description: OpenPGP digital signature
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1025109: python-memory-profiler: (autopkgtest) needs update for python3.11: cannot import name 'coroutine' from 'asyncio'
Source: python-memory-profiler Version: 0.60-1 Severity: serious Tags: sid bookworm User: debian...@lists.debian.org Usertags: needs-update User: debian-pyt...@lists.debian.org Usertags: python3.11 Control: affects -1 src:python3-defaults Dear maintainer(s), We are in the transition of adding python3.11 as a supported Python version [0]. With a recent upload of python3-defaults the autopkgtest of python-memory-profiler fails in testing when that autopkgtest is run with the binary packages of python3-defaults from unstable. It passes when run with only packages from testing. In tabular form: passfail python3-defaults from testing3.10.6-3 python-memory-profiler from testing0.60-1 all others from testingfrom testing I copied some of the output at the bottom of this report. Currently this regression is blocking the migration of python3-defaults to testing [1]. https://docs.python.org/3/whatsnew/3.11.html lists what's new in Python3.11, it may help to identify what needs to be updated. More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [0] https://bugs.debian.org/1021984 [1] https://qa.debian.org/excuses.php?package=python3-defaults https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-memory-profiler/28750375/log.gz Testing with python3.11: python3.11 -m memory_profiler test/test_func.py Traceback (most recent call last): File "", line 198, in _run_module_as_main File "", line 88, in _run_code File "/usr/lib/python3/dist-packages/memory_profiler.py", line 10, in from asyncio import coroutine, iscoroutinefunction ImportError: cannot import name 'coroutine' from 'asyncio' (/usr/lib/python3.11/asyncio/__init__.py) make: *** [Makefile:6: test] Error 1 autopkgtest [23:14:56]: test command1 OpenPGP_signature Description: OpenPGP digital signature -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1024859: cctbx: (autopkgtest) needs update for python3.11: initialization of scitbx_linalg_ext raised unreported exception
Source: cctbx
Version: 2022.9+ds2+~3.11.2+ds1-4
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
User: debian-pyt...@lists.debian.org
Usertags: python3.11
Control: affects -1 src:python3-defaults
Dear maintainer(s),
We are in the transition of adding python3.11 as a supported Python
version [0]. With a recent upload of python3-defaults the autopkgtest of
cctbx fails in testing when that autopkgtest is run with the binary
packages of python3-defaults from unstable. It passes when run with only
packages from testing. In tabular form:
passfail
python3-defaults from testing3.10.6-3
cctbx from testing2022.9+ds2+~3.11.2+ds1-4
all others from testingfrom testing
I copied some of the output at the bottom of this report.
Currently this regression is blocking the migration of python3-defaults
to testing [1]. https://docs.python.org/3/whatsnew/3.11.html lists
what's new in Python3.11, it may help to identify what needs to be updated.
More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
Paul
[0] https://bugs.debian.org/1021984
[1] https://qa.debian.org/excuses.php?package=python3-defaults
https://ci.debian.net/data/autopkgtest/testing/amd64/c/cctbx/28708326/log.gz
Testing cctbx with python3.11:
Discovering pytest tests for smtbx:
refinement/constraints/tests/test_disorder.py: 1
refinement/constraints/tests/test_occupancies.py: 1
refinement/constraints/tests/test_rigid.py: 9
refinement/constraints/tests/test_same_group.py: 2
ERRORS
___ ERROR collecting refinement/constraints/tests/test_direction.py
/usr/lib/python3.11/importlib/__init__.py:126: in import_module
return _bootstrap._gcd_import(name[level:], package, level)
:1206: in _gcd_import
???
:1178: in _find_and_load
???
:1128: in _find_and_load_unlocked
???
:241: in _call_with_frames_removed
???
:1206: in _gcd_import
???
:1178: in _find_and_load
???
:1128: in _find_and_load_unlocked
???
:241: in _call_with_frames_removed
???
:1206: in _gcd_import
???
:1178: in _find_and_load
???
:1128: in _find_and_load_unlocked
???
:241: in _call_with_frames_removed
???
:1206: in _gcd_import
???
:1178: in _find_and_load
???
:1149: in _find_and_load_unlocked
???
:690: in _load_unlocked
???
:940: in exec_module
???
:241: in _call_with_frames_removed
???
/usr/lib/python3/dist-packages/smtbx/refinement/__init__.py:2: in
from cctbx import xray
/usr/lib/python3/dist-packages/cctbx/xray/__init__.py:4: in
from cctbx.xray.scatterer import *
/usr/lib/python3/dist-packages/cctbx/xray/scatterer.py:3: in
import cctbx.eltbx.xray_scattering
/usr/lib/python3/dist-packages/cctbx/eltbx/xray_scattering/__init__.py:2:
in
import scitbx.math.gaussian # base class for gaussian
/usr/lib/python3/dist-packages/scitbx/math/__init__.py:8: in
import scitbx.linalg.eigensystem
/usr/lib/python3/dist-packages/scitbx/linalg/__init__.py:2: in
from scitbx.linalg.ext import *
/usr/lib/python3/dist-packages/scitbx/linalg/ext.py:3: in
bp.import_ext("scitbx_linalg_ext")
/usr/lib/python3/dist-packages/boost_adaptbx/boost/python.py:22: in
import_ext
try: mod = __import__(name)
E SystemError: initialization of scitbx_linalg_ext raised unreported
exception
OpenPGP_signature
Description: OpenPGP digital signature
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1024164: src:gmsh: unsatisfied build dependency in testing: libgmm++-dev
Source: gmsh Version: 4.8.4+ds2-2 Severity: serious Tags: sid bookworm User: debian...@lists.debian.org Usertags: edos-uninstallable Control: block -1 by 1023788 Dear maintainer(s), Dose [1] is reporting a build issue with your package, it's missing a build dependency. Obviously your build dependencies shouldn't be removed from testing, but unfortunately there are multiple scenarios where that can happen nevertheless. To uphold our social contract, Debian requires that packages can be rebuild from source in the suite we are shipping them, so currently this is a serious issue with your package in testing. Can you please investigate the situation and figure out how to resolve it? Regularly, if the build dependency is available in unstable, helping the maintainer of your Build-Depends to enable migration to testing is a great way to solve the issue. If your build dependency is gone from unstable and testing, you'll have to fix the build process in some other way. In this case, src:getfem took over from src:getfem++ but it is blocked because if fails to build from source on s390x, see bug #1023788. Paul Note: this bug report was sent after some quick manual checks using a template. Please reach out to me if you believe I made a mistake in my process. [1] https://qa.debian.org/dose/debcheck/src_testing_main/latest/amd64.html OpenPGP_signature Description: OpenPGP digital signature -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1024163: src:freefem++: unsatisfied build dependency in testing: libgmm++-dev
Source: freefem++ Version: 4.11+dfsg1-2 Severity: serious Tags: sid bookworm User: debian...@lists.debian.org Usertags: edos-uninstallable Control: block -1 by 1023788 Dear maintainer(s), Dose [1] is reporting a build issue with your package, it's missing a build dependency. Obviously your build dependencies shouldn't be removed from testing, but unfortunately there are multiple scenarios where that can happen nevertheless. To uphold our social contract, Debian requires that packages can be rebuild from source in the suite we are shipping them, so currently this is a serious issue with your package in testing. Can you please investigate the situation and figure out how to resolve it? Regularly, if the build dependency is available in unstable, helping the maintainer of your Build-Depends to enable migration to testing is a great way to solve the issue. If your build dependency is gone from unstable and testing, you'll have to fix the build process in some other way. In this case, src:getfem took over from src:getfem++ but it is blocked because if fails to build from source on s390x, see bug #1023788. Paul Note: this bug report was sent after some quick manual checks using a template. Please reach out to me if you believe I made a mistake in my process. [1] https://qa.debian.org/dose/debcheck/src_testing_main/latest/amd64.html OpenPGP_signature Description: OpenPGP digital signature -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1023788: getfem: fails to build from source on s390x
Source: getfem Version: 5.4.2+dfsg1-1 Severity: serious Tags: ftbfs Dear maintainer, Version 5.4.1+dfsg1-1 built successfully on s390x, but 5.4.2+dfsg1-1 fails to build from source there. This is blocking migration. Can you look into the situation and solve it? Paul -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1023499: src:python-suitesparse-graphblas: fails to migrate to testing for too long: FTBFS on i386
Source: python-suitesparse-graphblas Version: 6.2.4.0-3 Severity: serious Control: close -1 7.2.0.0-1 Tags: sid bookworm ftbfs User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 60 days as having a Release Critical bug in testing [1]. Your package src:python-suitesparse-graphblas has been trying to migrate for 61 days [2]. Hence, I am filing this bug. Your package failed to build on i386 while it built successfully there in the past. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and bookworm, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html [2] https://qa.debian.org/excuses.php?package=python-suitesparse-graphblas OpenPGP_signature Description: OpenPGP digital signature -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1023231: cimg: autopkgtest failure everywhere but on amd64: './libHalf.so': File exists
Source: cimg Version: 3.1.6+dfsg-4 Severity: serious User: debian...@lists.debian.org Usertags: fails-always Dear maintainer(s), You recently added an autopkgtest to your package cimg, great. However, it fails everywhere but on amd64. Currently this failure is blocking the migration to testing [1]. Can you please investigate the situation and fix it? I copied some of the output at the bottom of this report. More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=cimg https://ci.debian.net/data/autopkgtest/testing/arm64/c/cimg/27599388/log.gz make[1]: Entering directory '/tmp/autopkgtest-lxc.1l29kob2/downtmp/autopkgtest_tmp' grep: ../CImg.h: No such file or directory grep: ../CImg.h: No such file or directory grep: ../CImg.h: No such file or directory ** Compiling 'CImg_demo (..)' with 'gcc version 12.2.0 (Debian 12.2.0-3) ' Hack to provide -lIlmImf and -lHalf if [ ! -e ./libHalf.so ] ; then ln -s `find /usr/lib -type l -name "libHalf-2_5.so.*"` ./libHalf.so ; fi ln: failed to create symbolic link './libHalf.so': File exists make[1]: *** [Makefile:322: CImg_demo] Error 1 make[1]: Leaving directory '/tmp/autopkgtest-lxc.1l29kob2/downtmp/autopkgtest_tmp' make: *** [Makefile:459: Mlinux] Error 2 autopkgtest [17:13:51]: test run-unit-test OpenPGP_signature Description: OpenPGP digital signature -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1023222: python-xarray: autopkgtest regression on s390x: segmentation fault
Source: python-xarray
Version: 2022.10.0-1
Severity: serious
User: debian...@lists.debian.org
Usertags: regression
Dear maintainer(s),
With a recent upload of python-xarray the autopkgtest of python-xarray
fails in testing on s390x when that autopkgtest is run with the binary
packages of python-xarray from unstable. It passes when run with only
packages from testing. In tabular form:
passfail
python-xarray from testing2022.10.0-1
all others from testingfrom testing
I copied some of the output at the bottom of this report.
Currently this regression is blocking the migration to testing [1]. Can
you please investigate the situation and fix it?
More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
Paul
[1] https://qa.debian.org/excuses.php?package=python-xarray
https://ci.debian.net/data/autopkgtest/testing/s390x/p/python-xarray/27672266/log.gz
[ 90%]
tests/test_sparse.py::test_variable_property[nbytes] PASSED
[ 90%]
tests/test_sparse.py::test_variable_property[ndim] PASSED
[ 90%]
tests/test_sparse.py::test_variable_property[values] XFAIL (Coercion...)
[ 90%]
tests/test_sparse.py::test_variable_method[obj.all(*(), **{})-False]
Fatal Python error: Segmentation fault
Current thread 0x03ff91575040 (most recent call first):
File "/usr/lib/python3/dist-packages/sparse/_coo/core.py", line 1562
in _grouped_reduce
File "/usr/lib/python3/dist-packages/sparse/_coo/core.py", line 687
in _reduce_calc
File "/usr/lib/python3/dist-packages/sparse/_sparse_array.py", line
360 in reduce
File "/usr/lib/python3/dist-packages/sparse/_sparse_array.py", line
278 in _reduce
File "/usr/lib/python3/dist-packages/sparse/_sparse_array.py", line
307 in __array_ufunc__
File "/usr/lib/python3/dist-packages/sparse/_sparse_array.py", line
490 in all
File "/usr/lib/python3/dist-packages/sparse/_sparse_array.py", line
268 in __array_function__
File "<__array_function__ internals>", line 5 in all
File "/usr/lib/python3/dist-packages/xarray/core/variable.py", line
1901 in reduce
File "/usr/lib/python3/dist-packages/xarray/core/common.py", line 73
in wrapped_func
File "/usr/lib/python3/dist-packages/xarray/tests/test_sparse.py",
line 69 in __call__
File "/usr/lib/python3/dist-packages/xarray/tests/test_sparse.py",
line 231 in test_variable_method
File "/usr/lib/python3/dist-packages/_pytest/python.py", line 192 in
pytest_pyfunc_call
File "/usr/lib/python3/dist-packages/pluggy/_callers.py", line 39 in
_multicall
File "/usr/lib/python3/dist-packages/pluggy/_manager.py", line 80 in
_hookexec
File "/usr/lib/python3/dist-packages/pluggy/_hooks.py", line 265 in
__call__
File "/usr/lib/python3/dist-packages/_pytest/python.py", line 1761 in
runtest
File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 166 in
pytest_runtest_call
File "/usr/lib/python3/dist-packages/pluggy/_callers.py", line 39 in
_multicall
File "/usr/lib/python3/dist-packages/pluggy/_manager.py", line 80 in
_hookexec
File "/usr/lib/python3/dist-packages/pluggy/_hooks.py", line 265 in
__call__
File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 259 in
File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 338 in
from_call
File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 258 in
call_runtest_hook
File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 219 in
call_and_report
File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 130 in
runtestprotocol
File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 111 in
pytest_runtest_protocol
File "/usr/lib/python3/dist-packages/pluggy/_callers.py", line 39 in
_multicall
File "/usr/lib/python3/dist-packages/pluggy/_manager.py", line 80 in
_hookexec
File "/usr/lib/python3/dist-packages/pluggy/_hooks.py", line 265 in
__call__
File "/usr/lib/python3/dist-packages/_pytest/main.py", line 347 in
pytest_runtestloop
File "/usr/lib/python3/dist-packages/pluggy/_callers.py", line 39 in
_multicall
File "/usr/lib/python3/dist-packages/pluggy/_manager.py", line 80 in
_hookexec
File "/usr/lib/python3/dist-packages/pluggy/_hooks.py", line 265 in
__call__
File "/usr/lib/python3/dist-packages/_pytest/main.py", line 322 in _main
File "/usr/lib/python3/dist-packages/_pytest/main.py", line 268 in
wrap_session
File "/usr/lib/python3/dist-packages/_pytest/main.py", line 315 in
pytest_cmdline_main
File "/usr/lib/python3/dist-packages/pluggy/_callers.py", line 39 in
_multicall
File "/usr/lib/python3/dist-packages/pluggy/_manager.py", line 80 in
_hookexec
File "/usr/lib/python3/dist-packages/pluggy/_hooks.py", line 265 in
__call__
File "/usr/lib/python3/dist-packages/_pytest/config/__init__.py",
line 164 in main
File "/usr/lib/python3/dist-packages/_pytest/config/__init__.py",
line 187 in console_main
File
Bug#1022255: python-xarray breaks satpy autopkgtest
Source: python-xarray, satpy
Control: found -1 python-xarray/2022.10.0-1
Control: found -1 satpy/0.37.1-1
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: breaks needs-update
Dear maintainer(s),
With a recent upload of python-xarray the autopkgtest of satpy fails in
testing when that autopkgtest is run with the binary packages of
python-xarray from unstable. It passes when run with only packages from
testing. In tabular form:
passfail
python-xarray from testing2022.10.0-1
satpy from testing0.37.1-1
all others from testingfrom testing
I copied some of the output at the bottom of this report.
Currently this regression is blocking the migration of python-xarray to
testing [1]. Due to the nature of this issue, I filed this bug report
against both packages. Can you please investigate the situation and
reassign the bug to the right package?
More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
Paul
[1] https://qa.debian.org/excuses.php?package=python-xarray
https://ci.debian.net/data/autopkgtest/testing/amd64/s/satpy/27389134/log.gz
TestNIRReflectance.test_no_sunz_no_co2
self = testMethod=test_no_sunz_no_co2>
calculator =
apply_modifier_info = id='139765627664464'>
sza =
@mock.patch('satpy.modifiers.spectral.sun_zenith_angle')
@mock.patch('satpy.modifiers.NIRReflectance.apply_modifier_info')
@mock.patch('satpy.modifiers.spectral.Calculator')
def test_no_sunz_no_co2(self, calculator, apply_modifier_info, sza):
"""Test NIR reflectance compositor with minimal parameters."""
calculator.return_value = mock.MagicMock(
reflectance_from_tbs=self.refl_from_tbs)
sza.return_value = self.da_sunz
from satpy.modifiers.spectral import NIRReflectance
comp = NIRReflectance(name='test')
info = {'modifiers': None}
res = comp([self.nir, self.ir_], optional_datasets=[], **info)
> self.get_lonlats.assert_called()
/usr/lib/python3/dist-packages/satpy/tests/test_modifiers.py:244: _ _ _
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
self =
def assert_called(self):
"""assert that the mock was called at least once
"""
if self.call_count == 0:
msg = ("Expected '%s' to have been called." %
(self._mock_name or 'mock'))
raise AssertionError(msg)
E AssertionError: Expected 'get_lonlats' to have been called.
/usr/lib/python3.10/unittest/mock.py:888: AssertionError
___ TestSceneLoading.test_load_comp4
___
self =
def test_load_comp4(self):
"""Test loading a composite that depends on a composite."""
scene = Scene(filenames=['fake1_1.txt'], reader='fake1')
scene.load(['comp4'])
loaded_ids = list(scene._datasets.keys())
assert len(loaded_ids) == 1
E AssertionError: assert 2 == 1
E+ where 2 = len([DataID(name='comp2'), DataID(name='ds3',
modifiers=())])
/usr/lib/python3/dist-packages/satpy/tests/test_scene.py:1059:
AssertionError
-- Captured log call
---
WARNING satpy.scene:scene.py:1275 The following datasets were not
created and may require resampling to be generated: DataID(name='comp4')
___ TestSceneLoading.test_load_multiple_resolutions
self =
def test_load_multiple_resolutions(self):
"""Test loading a dataset has multiple resolutions available
with different resolutions."""
scene = Scene(filenames=['fake1_1.txt'], reader='fake1')
comp25 = make_cid(name='comp25', resolution=1000)
scene[comp25] = xr.DataArray([], attrs={'name': 'comp25',
'resolution': 1000})
scene.load(['comp25'], resolution=500)
loaded_ids = list(scene._datasets.keys())
assert len(loaded_ids) == 2
E AssertionError: assert 3 == 2
E+ where 3 = len([DataID(name='comp24', resolution=500),
DataID(name='comp25', resolution=1000), DataID(name='ds5',
resolution=500, modifiers=())])
/usr/lib/python3/dist-packages/satpy/tests/test_scene.py:1070:
AssertionError
-- Captured log call
---
WARNING satpy.scene:scene.py:1275 The following datasets were not
created and may require resampling to be generated: DataID(name='comp25')
_ TestSceneLoading.test_load_same_subcomposite
_
self =
def test_load_same_subcomposite(self):
"""Test loading a composite and one of it's subcomposites at
the same time."""
scene = Scene(filenames=['fake1_1.txt'], reader='fake1')
scene.load(['comp24', 'comp25'], resolution=500)
Bug#1021055: asmjit autopkgtest times out
Source: asmjit Version: 0.0~git20211214.2a706fd-1 Severity: serious User: debian...@lists.debian.org Usertags: timeout Dear maintainer(s), Your package has an autopkgtest, great. However, it fails. What's worse, it fails because it seems to hang since recently and eventually times out due to autopkgtest. Can you please investigate the situation and fix it? I copied some of the output at the bottom of this report. The release team has announced [1] that failing autopkgtest on amd64 and arm64 are considered RC in testing. Also tests that time out (while normally running in much less time) are bad for our infrastructure. I have added your package to our reject_list and will remove it once this bug is closed. More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://lists.debian.org/debian-devel-announce/2019/07/msg2.html https://ci.debian.net/packages/a/asmjit/ [ 97%] Built target asmjit_test_instinfo [ 98%] Building CXX object CMakeFiles/asmjit_test_compiler.dir/test/asmjit_test_compiler.cpp.o [ 99%] Building CXX object CMakeFiles/asmjit_test_compiler.dir/test/asmjit_test_compiler_x86.cpp.o [100%] Linking CXX executable asmjit_test_compiler [100%] Built target asmjit_test_compiler Running tests... Test project /tmp/autopkgtest-lxc.zi7__ym3/downtmp/build.EGf/src/build Start 1: asmjit_test_unit autopkgtest [08:30:54]: ERROR: timed out on command OpenPGP_signature Description: OpenPGP digital signature -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1020445: numba: autopkgtest regression on ppc64el: inf != 0.625
Source: numba
Version: 0.52.0-5
Severity: serious
User: debian...@lists.debian.org
Usertags: regression
Dear maintainer(s),
Your package has an autopkgtest, great. However, it recently started
to fail in testing on ppc64el. It also has never passed on armel, armhf
and s390x. I'm not sure what to make of all the recent migration run
failures on amd64, arm64 and i386, but the test *appears* to be flaky.
Paul
https://ci.debian.net/data/autopkgtest/testing/ppc64el/n/numba/26229968/log.gz
==
FAIL: test_ldexp (numba.tests.test_mathlib.TestMathLib)
--
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/numba/tests/test_mathlib.py",
line 648, in test_ldexp
self.assertPreciseEqual(cfunc(*args), pyfunc(*args))
File "/usr/lib/python3/dist-packages/numba/tests/support.py", line
378, in assertPreciseEqual
self.fail("when comparing %s and %s: %s" % (first, second,
failure_msg))
AssertionError: when comparing inf and 0.625: inf != 0.625
==
FAIL: test_ldexp_npm (numba.tests.test_mathlib.TestMathLib)
--
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/numba/tests/test_mathlib.py",
line 651, in test_ldexp_npm
self.test_ldexp(flags=no_pyobj_flags)
File "/usr/lib/python3/dist-packages/numba/tests/test_mathlib.py",
line 648, in test_ldexp
self.assertPreciseEqual(cfunc(*args), pyfunc(*args))
File "/usr/lib/python3/dist-packages/numba/tests/support.py", line
378, in assertPreciseEqual
self.fail("when comparing %s and %s: %s" % (first, second,
failure_msg))
AssertionError: when comparing inf and 0.625: inf != 0.625
OpenPGP_signature
Description: OpenPGP digital signature
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1019533: scipy breaks libflame autopkgtest on i386: Floating point exception
Source: scipy, libflame Control: found -1 scipy/1.8.1-9 Control: found -1 libflame/5.2.0-3 Severity: serious Tags: sid bookworm User: debian...@lists.debian.org Usertags: breaks needs-update Dear maintainer(s), With a recent upload of scipy (1.8.1-9, 1.8.1-7 passed) the autopkgtest of libflame fails in testing when that autopkgtest is run with the binary packages of scipy from unstable. It passes when run with only packages from testing. In tabular form: passfail scipy from testing1.8.1-9 and later libflamefrom testing5.2.0-3 all others from testingfrom testing I copied some of the output at the bottom of this report. Currently this regression is *not* blocking the migration of scipy to testing [1] (because of bug #1019525). Due to the nature of this issue, I filed this bug report against both packages. Can you please investigate the situation and reassign the bug to the right package? More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=scipy https://ci.debian.net/data/autopkgtest/testing/i386/libf/libflame/25855917/log.gz (Please be aware of: WARNING: log file truncated at 20 MB (before compression) First 1MB is presented above, last 19 MB below ) special/tests/test_kolmogorov.py::TestSmirnovi::test_x_equals_0 <- ../../../../../usr/lib/python3/dist-packages/scipy/special/tests/test_kolmogorov.py PASSED [ 83%] special/tests/test_kolmogorov.py::TestSmirnovi::test_x_equals_1 <- ../../../../../usr/lib/python3/dist-packages/scipy/special/tests/test_kolmogorov.py PASSED [ 83%] special/tests/test_kolmogorov.py::TestSmirnovi::test_n_equals_1 <- ../../../../../usr/lib/python3/dist-packages/scipy/special/tests/test_kolmogorov.py PASSED [ 83%] special/tests/test_kolmogorov.py::TestSmirnovi::test_n_equals_2 <- ../../../../../usr/lib/python3/dist-packages/scipy/special/tests/test_kolmogorov.py PASSED [ 83%] special/tests/test_kolmogorov.py::TestSmirnovi::test_n_equals_3 <- ../../../../../usr/lib/python3/dist-packages/scipy/special/tests/test_kolmogorov.py PASSED [ 83%] special/tests/test_kolmogorov.py::TestSmirnovi::test_round_trip <- ../../../../../usr/lib/python3/dist-packages/scipy/special/tests/test_kolmogorov.py PASSED [ 83%] special/tests/test_kolmogorov.py::TestSmirnovi::test_x_equals_0point5 <- ../../../../../usr/lib/python3/dist-packages/scipy/special/tests/test_kolmogorov.py PASSED [ 83%] special/tests/test_kolmogorov.py::TestSmirnovp::test_nan <- ../../../../../usr/lib/python3/dist-packages/scipy/special/tests/test_kolmogorov.py PASSED [ 83%] special/tests/test_kolmogorov.py::TestSmirnovp::test_basic <- ../../../../../usr/lib/python3/dist-packages/scipy/special/tests/test_kolmogorov.py PASSED [ 83%] special/tests/test_kolmogorov.py::TestSmirnovp::test_oneminusoneovern <- ../../../../../usr/lib/python3/dist-packages/scipy/special/tests/test_kolmogorov.py Fatal Python error: Floating point exception Current thread 0xf7ba5700 (most recent call first): File "/usr/lib/python3/dist-packages/scipy/special/_testutils.py", line 213 in eval_func_at_params File "/usr/lib/python3/dist-packages/scipy/special/_testutils.py", line 227 in check File "/usr/lib/python3/dist-packages/scipy/special/tests/test_kolmogorov.py", line 213 in test_oneminusoneovern File "/usr/lib/python3/dist-packages/_pytest/python.py", line 192 in pytest_pyfunc_call File "/usr/lib/python3/dist-packages/pluggy/_callers.py", line 39 in _multicall File "/usr/lib/python3/dist-packages/pluggy/_manager.py", line 80 in _hookexec File "/usr/lib/python3/dist-packages/pluggy/_hooks.py", line 265 in __call__ File "/usr/lib/python3/dist-packages/_pytest/python.py", line 1761 in runtest File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 166 in pytest_runtest_call File "/usr/lib/python3/dist-packages/pluggy/_callers.py", line 39 in _multicall File "/usr/lib/python3/dist-packages/pluggy/_manager.py", line 80 in _hookexec File "/usr/lib/python3/dist-packages/pluggy/_hooks.py", line 265 in __call__ File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 259 in File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 338 in from_call File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 258 in call_runtest_hook File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 219 in call_and_report File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 130 in runtestprotocol File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 111 in pytest_runtest_protocol File "/usr/lib/python3/dist-packages/pluggy/_callers.py", line 39 in _multicall File "/usr/lib/python3/dist-packages/pluggy/_manager.py", line 80 in _hookexec File "/usr/lib/python3/dist-packages/pluggy/_hooks.py",
Bug#1019525: libflame: flaky autopkgtest: numpy-with-libflame times out
Source: libflame Version: 5.2.0-3 Severity: serious User: debian...@lists.debian.org Usertags: flaky Dear maintainer(s), I looked at the results of the autopkgtest of your package. I noticed that it (recently) regularly fails on amd64, arm64, armel, i386, s390x. In the logs I checked it's because numpy-with-libflame times out, so I suspect since a recent numpy update. Because the unstable-to-testing migration software now blocks on regressions in testing, flaky tests, i.e. tests that flip between passing and failing without changes to the list of installed packages, are causing people unrelated to your package to spend time on these tests. It may also lead to packages causing regression (I *suspect* scipy currently, will try to investigate) to slip through. Don't hesitate to reach out if you need help and some more information from our infrastructure. Paul OpenPGP_signature Description: OpenPGP digital signature -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1019511: scipy breaks scikit-learn autopkgtest on ppc64el: precision delta's
Source: scipy, scikit-learn Control: found -1 scipy/1.8.1-14 Control: found -1 scikit-learn/1.1.2+dfsg-5 Severity: serious Tags: sid bookworm User: debian...@lists.debian.org Usertags: breaks needs-update Dear maintainer(s), With a recent upload of scipy the autopkgtest of scikit-learn fails in testing when that autopkgtest is run with the binary packages of scipy from unstable. It passes when run with only packages from testing. In tabular form: passfail scipy from testing1.8.1-14 scikit-learn from testing1.1.2+dfsg-5 all others from testingfrom testing I copied some of the output at the bottom of this report. Currently this regression is blocking the migration of scipy to testing [1]. Due to the nature of this issue, I filed this bug report against both packages. Can you please investigate the situation and reassign the bug to the right package? More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=scipy https://ci.debian.net/data/autopkgtest/testing/ppc64el/s/scikit-learn/25863055/log.gz === FAILURES === __ test_mlp_regressor_dtypes_casting ___ def test_mlp_regressor_dtypes_casting(): mlp_64 = MLPRegressor( alpha=1e-5, hidden_layer_sizes=(5, 3), random_state=1, max_iter=50 ) mlp_64.fit(X_digits[:300], y_digits[:300]) pred_64 = mlp_64.predict(X_digits[300:]) mlp_32 = MLPRegressor( alpha=1e-5, hidden_layer_sizes=(5, 3), random_state=1, max_iter=50 ) mlp_32.fit(X_digits[:300].astype(np.float32), y_digits[:300]) pred_32 = mlp_32.predict(X_digits[300:].astype(np.float32)) > assert_allclose(pred_64, pred_32, rtol=1e-04) E AssertionError: E Not equal to tolerance rtol=0.0001, atol=0 E E Mismatched elements: 1 / 60 (1.67%) E Max absolute difference: 1.77346709e-06 E Max relative difference: 0.0001 Ex: array([-1.624248e-02, 2.327707e+00, 6.674963e-01, 4.904700e-01, E 6.739288e-01, 3.166697e+00, 4.548126e-01, 6.674963e-01, E -3.220949e-02, -6.899952e-01, 6.674963e-01, -6.329127e-01,... Ey: array([-1.624250e-02, 2.327706e+00, 6.674960e-01, 4.904711e-01, E 6.739284e-01, 3.166698e+00, 4.548138e-01, 6.674960e-01, E -3.220773e-02, -6.899955e-01, 6.674960e-01, -6.329128e-01,... /usr/lib/python3/dist-packages/sklearn/neural_network/tests/test_mlp.py:872: AssertionError OpenPGP_signature Description: OpenPGP digital signature -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1018786: numba: autopkgtest needs update for new version of llvmlite: The module `llvmlite.llvmpy` is deprecated
Source: numba Version: 0.55.2+dfsg-1 Severity: serious X-Debbugs-CC: llvml...@packages.debian.org Tags: sid bookworm User: debian...@lists.debian.org Usertags: needs-update Control: affects -1 src:llvmlite Dear maintainer(s), With a recent upload of llvmlite the autopkgtest of numba fails in testing when that autopkgtest is run with the binary packages of llvmlite from unstable. It passes when run with only packages from testing. In tabular form: passfail llvmlite from testing0.39.0-1 numba from testing0.55.2+dfsg-1 all others from testingfrom testing I copied some of the output at the bottom of this report. Currently this regression is blocking the migration of llvmlite to testing [1]. Of course, llvmlite shouldn't just break your autopkgtest (or even worse, your package), but it seems to me that the change in llvmlite was intended and your package needs to update to the new situation. If this is a real problem in your package (and not only in your autopkgtest), the right binary package(s) from llvmlite should really add a versioned Breaks on the unfixed version of (one of your) package(s). Note: the Breaks is nice even if the issue is only in the autopkgtest as it helps the migration software to figure out the right versions to combine in the tests. More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=llvmlite https://ci.debian.net/data/autopkgtest/testing/amd64/n/numba/25502711/log.gz == FAIL: test_no_accidental_warnings (numba.tests.test_import.TestNumbaImport) -- Traceback (most recent call last): File "/usr/lib/python3/dist-packages/numba/tests/test_import.py", line 103, in test_no_accidental_warnings run_in_subprocess(code, flags) File "/usr/lib/python3/dist-packages/numba/tests/support.py", line 1014, in run_in_subprocess raise AssertionError(msg % (popen.returncode, err.decode())) AssertionError: process failed with code 1: stderr follows Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3/dist-packages/numba/__init__.py", line 38, in from numba.core.decorators import (cfunc, generated_jit, jit, njit, stencil, File "/usr/lib/python3/dist-packages/numba/core/decorators.py", line 12, in from numba.stencils.stencil import stencil File "/usr/lib/python3/dist-packages/numba/stencils/stencil.py", line 11, in from numba.core import types, typing, utils, ir, config, ir_utils, registry File "/usr/lib/python3/dist-packages/numba/core/ir_utils.py", line 16, in from numba.core.extending import _Intrinsic File "/usr/lib/python3/dist-packages/numba/core/extending.py", line 19, in from numba.core.pythonapi import box, unbox, reflect, NativeValue # noqa: F401 File "/usr/lib/python3/dist-packages/numba/core/pythonapi.py", line 8, in from llvmlite.llvmpy.core import Type, Constant File "/usr/lib/python3/dist-packages/llvmlite/llvmpy/__init__.py", line 3, in warnings.warn( UserWarning: The module `llvmlite.llvmpy` is deprecated and will be removed in the future. OpenPGP_signature Description: OpenPGP digital signature -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1018074: libflame: flaky autopkgtest on s390x: test_concatenate_int32_overflow Killed
Source: libflame
Version: 5.2.0-3
Severity: serious
User: debian...@lists.debian.org
Usertags: flaky
Dear maintainer(s),
I looked at the results of the autopkgtest of your package because it
was showing up as a regression [0] for the upload of gcc-12. I noticed
that it regularly fails on s390x. (The current failure on i386 seems to
be different [1]).
Because the unstable-to-testing migration software now blocks on
regressions in testing, flaky tests, i.e. tests that flip between
passing and failing without changes to the list of installed packages,
are causing people unrelated to your package to spend time on these
tests.
Don't hesitate to reach out if you need help and some more information
from our infrastructure.
Paul
[0]
https://ci.debian.net/data/autopkgtest/testing/s390x/libf/libflame/25178670/log.gzsparse/tests
/test_construct.py::TestConstructUtils::test_vstack <-
../../../../../usr/lib/python3/dist-packages/scipy/sparse/tests/test_construct.py
PASSED [ 79%]
sparse/tests/test_construct.py::TestConstructUtils::test_hstack <-
../../../../../usr/lib/python3/dist-packages/scipy/sparse/tests/test_construct.py
PASSED [ 79%]
sparse/tests/test_construct.py::TestConstructUtils::test_bmat <-
../../../../../usr/lib/python3/dist-packages/scipy/sparse/tests/test_construct.py
PASSED [ 79%]
sparse/tests/test_construct.py::TestConstructUtils::test_concatenate_int32_overflow
<-
../../../../../usr/lib/python3/dist-packages/scipy/sparse/tests/test_construct.py
bash: line 1: 3095 Killed bash -ec 'python3 -c "import
scipy as sp; sp.test('\''full'\'', verbose=3)"' 2> >(tee -a
/tmp/autopkgtest-lxc.1sf6ne4c/downtmp/scipy-with-libflame-stderr >&2) >
>(tee -a /tmp/autopkgtest-lxc.1sf6ne4c/downtmp/scipy-with-libflame-stdout)
[1]
https://ci.debian.net/data/autopkgtest/testing/i386/libf/libflame/25178325/log.gz
special/tests/test_kolmogorov.py::TestSmirnovp::test_nan <-
../../../../../usr/lib/python3/dist-packages/scipy/special/tests/test_kolmogorov.py
PASSED [ 83%]
special/tests/test_kolmogorov.py::TestSmirnovp::test_basic <-
../../../../../usr/lib/python3/dist-packages/scipy/special/tests/test_kolmogorov.py
PASSED [ 83%]
special/tests/test_kolmogorov.py::TestSmirnovp::test_oneminusoneovern <-
../../../../../usr/lib/python3/dist-packages/scipy/special/tests/test_kolmogorov.py
Fatal Python error: Floating point exception
OpenPGP_signature
Description: OpenPGP digital signature
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1017990: src:pytango: fails to migrate to testing for too long: FTBFS on s390x
Source: pytango Version: 9.3.3-1 Severity: serious Tags: sid bookworm ftbfs User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 60 days as having a Release Critical bug in testing [1]. Your package src:pytango has been trying to migrate for 61 days [2]. Hence, I am filing this bug. Your package failed to build on s390x while it built there successfully in the past and you have two unresolved RC bugs. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html [2] https://qa.debian.org/excuses.php?package=pytango OpenPGP_signature Description: OpenPGP digital signature -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1017402: scikit-learn: autopkgtest times out on powerful hosts
Source: scikit-learn Version: 0.23.2-5 Severity: serious User: debian...@lists.debian.org Usertags: flaky timeout Dear maintainer(s), I looked at the results of the autopkgtest of you package because of the recent issues we had with the package not migrating. I had already put it on the ci.d.n reject list for amd64, armel and armhf a while ago intending to file this bug already earlier. Today I removed the block for amd64 to give the fresh upload a try. However, the autopkgtest fails when run on ci-worker13, which is our powerful amd64 worker. That worker has 64 cores and 256GB RAM, while the other amd64 workers have only 2 cores and 8GB RAM. Also our armel and armhf workers are powerful 16 resp. 160 cores and 26GB resp. 511 GB RAM. I have copied an example of a failing test below, but note that not all timeouts happen on the same location. Because the unstable-to-testing migration software now blocks on regressions in testing, flaky tests, i.e. tests that flip between passing and failing without changes to the list of installed packages, are causing people unrelated to your package to spend time on these tests. On top of that, when a test just hangs that's not good for our infrastructure. Don't hesitate to reach out if you need help and some more information from our infrastructure. Paul https://ci.debian.net/data/autopkgtest/unstable/amd64/s/scikit-learn/24826845/log.gz Fit 150 trees in 561.863 s, (740 total leaves) Time spent computing histograms: 152.240s Time spent finding best splits: 75.432s Time spent applying splits: 202.079s Time spent predicting: 18.902s PASSED ../../../../usr/lib/python3/dist-packages/sklearn/ensemble/_hist_gradient_boosting/tests/test_gradient_boosting.py::test_early_stopping_default[HistGradientBoostingClassifier-X0-y0] PASSED ../../../../usr/lib/python3/dist-packages/sklearn/ensemble/_hist_gradient_boosting/tests/test_gradient_boosting.py::test_early_stopping_default[HistGradientBoostingClassifier-X1-y1] PASSED ../../../../usr/lib/python3/dist-packages/sklearn/ensemble/_hist_gradient_boosting/tests/test_gradient_boosting.py::test_early_stopping_default[HistGradientBoostingRegressor-X2-y2] PASSED ../../../../usr/lib/python3/dist-packages/sklearn/ensemble/_hist_gradient_boosting/tests/test_gradient_boosting.py::test_early_stopping_default[HistGradientBoostingRegressor-X3-y3] PASSED ../../../../usr/lib/python3/dist-packages/sklearn/ensemble/_hist_gradient_boosting/tests/test_gradient_boosting.py::test_should_stop[scores0-1-0.001-False] PASSED ../../../../usr/lib/python3/dist-packages/sklearn/ensemble/_hist_gradient_boosting/tests/test_gradient_boosting.py::test_should_stop[scores1-5-0.001-False] PASSED ../../../../usr/lib/python3/dist-packages/sklearn/ensemble/_hist_gradient_boosting/tests/test_gradient_boosting.py::test_should_stop[scores2-5-0.001-False] PASSED ../../../../usr/lib/python3/dist-packages/sklearn/ensemble/_hist_gradient_boosting/tests/test_gradient_boosting.py::test_should_stop[scores3-5-0.001-False] PASSED ../../../../usr/lib/python3/dist-packages/sklearn/ensemble/_hist_gradient_boosting/tests/test_gradient_boosting.py::test_should_stop[scores4-5-0.0-False] PASSED ../../../../usr/lib/python3/dist-packages/sklearn/ensemble/_hist_gradient_boosting/tests/test_gradient_boosting.py::test_should_stop[scores5-5-0.999-False] PASSED ../../../../usr/lib/python3/dist-packages/sklearn/ensemble/_hist_gradient_boosting/tests/test_gradient_boosting.py::test_should_stop[scores6-5-4.9-False] PASSED ../../../../usr/lib/python3/dist-packages/sklearn/ensemble/_hist_gradient_boosting/tests/test_gradient_boosting.py::test_should_stop[scores7-5-0.0-True] PASSED ../../../../usr/lib/python3/dist-packages/sklearn/ensemble/_hist_gradient_boosting/tests/test_gradient_boosting.py::test_should_stop[scores8-5-0.001-True] PASSED ../../../../usr/lib/python3/dist-packages/sklearn/ensemble/_hist_gradient_boosting/tests/test_gradient_boosting.py::test_should_stop[scores9-5-5-True] PASSED ../../../../usr/lib/python3/dist-packages/sklearn/ensemble/_hist_gradient_boosting/tests/test_gradient_boosting.py::test_absolute_error PASSED ../../../../usr/lib/python3/dist-packages/sklearn/ensemble/_hist_gradient_boosting/tests/test_gradient_boosting.py::test_absolute_error_sample_weight PASSED ../../../../usr/lib/python3/dist-packages/sklearn/ensemble/_hist_gradient_boosting/tests/test_gradient_boosting.py::test_asymmetric_error[0.2] PASSED ../../../../usr/lib/python3/dist-packages/sklearn/ensemble/_hist_gradient_boosting/tests/test_gradient_boosting.py::test_asymmetric_error[0.5] PASSED ../../../../usr/lib/python3/dist-packages/sklearn/ensemble/_hist_gradient_boosting/tests/test_gradient_boosting.py::test_asymmetric_error[0.8] PASSED ../../../../usr/lib/python3/dist-packages/sklearn/ensemble/_hist_gradient_boosting/tests/test_gradient_boosting.py::test_poisson_y_positive[y0] PASSED
Bug#1017363: src:nfft: fails to migrate to testing for too long: unresolved RC bugs
Source: nfft Version: 3.3.2-2 Severity: serious Control: close -1 3.5.3-1 Tags: sid bookworm User: release.debian@packages.debian.org Usertags: out-of-sync Control: block -1 by 1016377 1016378 1016379 Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 60 days as having a Release Critical bug in testing [1]. Your package src:nfft has been trying to migrate for 61 days [2]. Hence, I am filing this bug. Your package has multiple unresolved RC bugs. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and bookworm, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html [2] https://qa.debian.org/excuses.php?package=nfft OpenPGP_signature Description: OpenPGP digital signature -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1017360: src:sentencepiece: fails to migrate to testing for too long: FTBFS on s390x
Source: sentencepiece Version: 0.1.96-1 Severity: serious Control: close -1 0.1.97-1 Tags: sid bookworm ftbfs User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 60 days as having a Release Critical bug in testing [1]. Your package src:sentencepiece has been trying to migrate for 61 days [2]. Hence, I am filing this bug. Your package failed to build from source on s390x where it built successfully in the past. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and bookworm, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html [2] https://qa.debian.org/excuses.php?package=sentencepiece OpenPGP_signature Description: OpenPGP digital signature -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1013939: fixed in python-xarray 2022.06.0-3
Control: reopen -1
Hi,
On Fri, 12 Aug 2022 11:33:53 + Debian FTP Masters
wrote:
python-xarray (2022.06.0-3) unstable; urgency=medium
.
* Depend on scipy >= 1.8.1-8 for fixes. Closes: #1004869, #1013939
But the log [1] that was generated by the migration trial run has the
output below and the runs in unstable fail too (so no missing
*versioned* items).
=== FAILURES
===
___ test_weighted_operations_nonequal_coords
___
def test_weighted_operations_nonequal_coords():
# There are no weights for a == 4, so that data point is ignored.
weights = DataArray(np.random.randn(4), dims=("a",),
coords=dict(a=[0, 1, 2, 3]))
data = DataArray(np.random.randn(4), dims=("a",),
coords=dict(a=[1, 2, 3, 4]))
check_weighted_operations(data, weights, dim="a", skipna=None)
q = 0.5
result = data.weighted(weights).quantile(q, dim="a")
# Expected value computed using code from
https://aakinshin.net/posts/weighted-quantiles/ with values at a=1,2,3
expected = DataArray([0.9308707], coords={"quantile":
[q]}).squeeze()
> assert_allclose(result, expected)
E AssertionError: Left and right DataArray objects are not close
E
E Differing values:
E L
E array(0.058928)
E R
E array(0.930871)
Paul
[1]
https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-xarray/24742527/log.gz
OpenPGP_signature
Description: OpenPGP digital signature
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1017033: scotch: autopkgtest regression on armel, armhf and ppc64el with glibc 2.34: output on stderr
Source: scotch Version: 7.0.1-2 Severity: serious User: debian...@lists.debian.org Usertags: regression Dear maintainer(s), I looked at the results of the autopkgtest of you package because it was showing up as a regression for the upload of glibc [0] on armel, armhf and ppc64el. It seems that it fails due to *warnings* printed on stderr. autopkgtest by default fails on output to stderr, which can be changed by adding a "allow-stderr" restriction to the test. Obviously it's better to prevent the output. Ubuntu already added the restriction because they were seeing this before Debian. Because the unstable-to-testing migration software now blocks on regressions in testing, flaky tests, i.e. tests that flip between passing and failing without changes to the list of installed packages, are causing people unrelated to your package to spend time on these tests. Don't hesitate to reach out if you need help and some more information from our infrastructure. Paul [0] https://ci.debian.net/data/autopkgtest/testing/armel/s/scotch/24593514/log.gz autopkgtest [17:58:43]: test test-scotch: - - - - - - - - - - stderr - - - - - - - - - - test_scotch_graph_induce.c: In function ‘main’: test_scotch_graph_induce.c:134:3: warning: ‘memset’ specified size between 2147483649 and 4294967295 exceeds maximum object size 2147483647 [-Wstringop-overflow=] 134 | memset (orgparttab, 0, orgvertnbr * sizeof (SCOTCH_GraphPart2)); | ^~~ OpenPGP_signature Description: OpenPGP digital signature -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
