Bug#1072781: ITP: python-cmake-build-extension -- Setuptools extension to build and package CMake projects
Package: wnpp Severity: wishlist Owner: Timo Röhling X-Debbugs-Cc: debian-de...@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: python-cmake-build-extension Version : 0.6.0 Upstream Author : Diego Ferigo * URL : https://github.com/diegoferigo/cmake-build-extension * License : BSD-3-clause, Expat Programming Lang: Python, C++ Description : Setuptools extension to build and package CMake projects This extension aims to simplify the integration of C++ projects based on CMake with Python packaging tools. CMake provides out-of-the-box support to either SWIG and pybind11, that are two among the most used projects to create Python bindings from C++ sources. If you have any experience with these hybrid projects, you know the challenges to make packaging right! This project takes inspiration from pre-existing examples (pybind/cmake_example, among many others) and provides a simple, flexible, and reusable setuptools extension with the following features: * Bridge between CMake projects and Python packaging * Configure and build the CMake project from setup.py * Install the CMake project in the resulting Python package * Allow passing custom CMake options * Allow creating a top-level __init__.py * Expose C++ executables to the Python environment * Provide a context manager to import CPython modules reliably on all major OSs * Disable the C++ extension in editable installations (requiring to manually call CMake to install the C++ project) The package will be team-maintained under the umbrella of the Debian Python Team at https://salsa.debian.org/python-team/packages/cmake-build-extension -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEmwPruYMA35fCsSO/zIxr3RQD9MoFAmZjY4YACgkQzIxr3RQD 9MqGvg//VlaEUgFyHvAoIv37IPVMvDRj3nUt+IO210T0sSeqowswdQC/qVPz2wj4 nk2WXEfjgPUO98caa/YYKjHCW68rg9KgAFu+Ypiizu5Tw5xQ4SFIf5gbonBqetSw acqmGzZPhh9VsI1cRICsRFsO8JDdZ6HNVbliWqRaFd3nQJFiLxeCh/5Rw5XxEmQU f86h23XdeMi9N/qiRhTNQsYIoxvXSpCvJLsn+u+yt7Xizz1k2ufGMHKJPe8EuO6F Mkh8hYLfCPugDpy6TGB/DCpxs4f7IG1/oUZBCWqRDGzK3uwyUrLFK6DRrMLigURT sqbhT/XzHn+4d8j/kGp1ZnV8Wm92W3gl3DPI6hRyM6qS8fmYiROU8F+eNDZJs8fk 6QxCQroesk6lJ9Be5Zx2DTvosAY2p9/ythUPXr+y44CBcu7MyZuHU1C3aeVVPDPx wOFPob8/ePLAM+vfVX7bgROt6ggwK9tEGwrjwtadtbSslIs/F1g54ScNfmqB1Zfm whubrSpbupFatEospoz9K6owVenVb4XDb2XCs9DPrsDnEr8iIpE9GxcV6JliAsPU 3+Xm8fjM0WGqJ+c/AhcUL7G0ff9CvkyDA5t+0qOt+7Jifpx4u+WASRh1F6tYsJa/ U6POUN7T9VpLrYdqu2m8Ld17XYWLFfqmbQfuePrcak2plipiDBU= =zIQr -END PGP SIGNATURE-
Bug#1072738: ITP: manif -- Lie theory library for state estimation
Package: wnpp Severity: wishlist Owner: Timo Röhling X-Debbugs-Cc: debian-de...@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: manif Version : 0.0.4 Upstream Author : Jeremie Deray * URL : https://github.com/artivis/manif * License : BSD-2-clause, CC0, Expat Programming Lang: Python, C++ Description : Lie theory library for state estimation manif is a Lie theory library for state estimation targeted at robotics applications. It is developed as a header-only C++11 library with Python 3 wrappers. The package will be team-maintained under the umbrella of the Debian Robotics Team at https://salsa.debian.org/robotics-team/manif -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEmwPruYMA35fCsSO/zIxr3RQD9MoFAmZi2G8ACgkQzIxr3RQD 9MoEjQ//YlC8VOUto9V5su74dvEwivEoEDv8no2ZtcLvbMRA8dQVU7BwkEYjlyUf EHS9slB3U8etfi5LMPfjVNGsfVwrY9650ULOkf/zTkzPebIjWCx3ufLMRNfdA3MC HQE+k4ihk2jemFv7DHrUe8zuGbaN0Ka9g16xWpU/MakN0x6bUB2dWseVdFS63ldP H74wqVLFKq/91Ka9LkAB/g0mLKy5UOuMNDpuVeJ6wL4nQkNhPi2j0JKAJDjvvCXf /OO+LYmSBdhMQZqak7jf1pxhZXeP/eDQHOs3K2enZ08/A0/DX+BBgQeCgFG7fLcG rTpAfJ1Pxds6EkCuLhMj4x68MAb/R0lvJXo5XozizOQ3RGxGeVDd0B3SZT+RF1Ef ZZjdHdYq/wQCE8MnWy3OEmGj+5e0yh77l7f8lOss/T6jvUyyBEDQLcuZ5BKSoGCf bGOHqIzRAULy3EkcZBU3iJ2VIRDuzsA0DPIomIYmcA5npbWIcTT7TGEKjz+EFM5q WrLGvrqugY1hYFx7thP+Sp3IMraktbNDQedIvxfZLaI17bEVBWJITwsScurK7Ife r7YQvDp/YIhz3KPS6TFzbSSL4bHGOBtgos6FKictrFMDLCgaDlnxpXOUtg/8IMps ImvQ61/V10dR0yltO+DeCg7gRt+F+8a91XrQG2fuGn6LMzAf/Ag= =ydle -END PGP SIGNATURE-
Bug#1072183: fenics-dolfinx: FTBFS with nanobind 2.0
Hi Francesco, * Francesco Ballarin [2024-06-06 10:51]: Can you try adding the following Breaks to python3-nanobind = Breaks: python3-basix (<< 0.8.0-3), python3-dolfinx (<< 1:0.8.0-8) python3-dolfinx-real (<< 1:0.8.0-8) python3-dolfinx-complex (<< 1:0.8.0-8) = I just uploaded nanobind 2.0.0-2 with your suggested Breaks. It feels very hackish, though. I hope we can come up with a more elegant solution for future ABI breaks. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭────╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Bug#1072684: ITP: tl-optional -- C++11/14/17 std::optional with functional-style extensions
Package: wnpp Severity: wishlist Owner: Timo Röhling X-Debbugs-Cc: debian-de...@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: tl-optional Version : 1.1.0 Upstream Author : Sy Brand * URL : https://github.com/TartanLlama/optional * License : CC0, Expat Programming Lang: C++ Description : C++11/14/17 std::optional with functional-style extensions std::optional is the preferred way to represent an object which may or may not have a value. Unfortunately, chaining together many computations which may or may not produce a value can be verbose, as empty-checking code will be mixed in with the actual programming logic. This implementation provides a number of utilities to make coding with optional cleaner. The package will be maintained by Timo Röhling at https://salsa.debian.org/debian/tl-optional -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEmwPruYMA35fCsSO/zIxr3RQD9MoFAmZhvxUACgkQzIxr3RQD 9Mpxbw//QA6mWkPqESGuOdq0etTY5tKCtfTuDt45ZgI5DnbyVi2nGfJIaVddpe5W smX9YOaW+2YJaXzaP6+BC6deltrQh9I4nq80bnW7BfmAoCILfk3u+KzuPi8EdwN+ R01dTBHmsdeG5yea3E0apazcGOL0reV/R3ZexfmJc04B5DM0Qp8YSAVAzVno/E7u aVQBATb7ccbhVxc90MihFGpTvLNUIhazueLlyAo8Lt3qZ/VuBnUSms+fy61IE7Mz CURNTYO6SrODHHx82i2wqG52GGDxDnEzOZLeIc1JiU1fgTqVsKh4GgY9nrQf3csg 3UPC0+AGVSEUonuQhSF0DOaZODAv0LAxwlVDUDbkIUD5ULwYsXlXq6hbWLTRcUof CA7hrPCFQQu+jQzjldPghxYM9z4XjsCVXSAOTtv35PGJ40wW6/zvmHLPBqp/+EGP YMWF28VG0D4hdbwRg1qJ2h6EnCXieiSqNZkuo6igOw3VVbvvf/R84bt6+lLYu1CH x1Z4vLAyAl+lA5RFkyYIaalf1doQ5Zdd0eopf46UyXRKc81iyuIdH71dj8n0YoDu I2bYfvu4hYBgUDdvJ7kBrIat9xMtkWX1lflcZlH730E6kM0hRm/UgMDwVVPdfMoZ aRaSruBDhEqyWJq90vGbMbIaGa4SuZ7o0A58NOFD2PQGCa4RdkE= =dj3T -END PGP SIGNATURE-
Bug#1072312: azure-cli: autopkgtest regression with pytest 8.2
Source: azure-cli Version: 2.61.0-1 Severity: serious Tags: upstream Control: forwarded -1 https://github.com/Azure/azure-cli/issues/28848 -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dear maintainer, the azure-cli package misuses the __init__ method in unittest.TestCase subclasses to setup tests. This was never officially supported and recently stopped working with pytest 8.2 as test runner. AFAICT upstream is working on a fix already [1]. Cheers Timo [1] https://github.com/Azure/azure-cli/pull/28849 -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEmwPruYMA35fCsSO/zIxr3RQD9MoFAmZaNvoACgkQzIxr3RQD 9Mp6Yw//VN1fk6v6bXdBaM0W8tiCounWq/L/XkuI2VKImMq7063p/gYvpPefxHhT AZDN3qA2lx/JlnkZyNyCdF0YjkjfqheDDt++1tXNBPxqNAamK0N71ozn7q9Ehf3R fv0xLUgZez/4XTFEg1N/VuELxgbhCsoD5SJwIqHPdX771by4mmcmBWrJkrumoFBi zUCtrPnqjaiJarPwO2A/QkWWxBlugr9o8pu37hhh5iElDlnJBKuKVBWHjPkHIPTI Db9EPFZXpM4VnMAPA6eO1zUxNS4sF273VxBjO6PJSUld4FTMcMJXm1Ung7PmXEEG uBaRzo9/50MoEaB4rJ+DE6Isxum9M7Yt2LJ9YeMiWushXVP9iXQc1RmkzuKr43Iq XxCetj7fbIV4veLWTfIqp1NY9L+psUkVZgGhmMam50k5QtFUeHHRr1i29PcI5Fe2 hF6cSLG5peKYnpaQc/HQVsRaVXQtaftcpjGdtXPkpwehl6KGOd5lZh9oID5P7U6N p5mbR5qVkgVtYWiMpxWzhStjpGsnUhRFyvZ5h06w3j1Mx+YtJuXL+IO7OLYRGtdd gowbfxtgGZhnsTKp7Gx1k2Xn1USFfcjG6UWb8fWmqKLJltbHTFLCJ7Lms1SXNczL DGLJC3ibVdynDhaE34SIYVsbzHovtQ9634onaoPEVB/CK2ujZyU= =PyAy -END PGP SIGNATURE-
Bug#1072246: libcloud: regression with pytest 8.2
Source: libcloud
Version: 3.8.0+repack-1
Severity: serious
Tags: ftbfs patch
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Dear maintainer,
pytest 8.2 has begun relying on the fact that unittest.TestCase objects should
be instantiable with (empty) default arguments, which does not work for the
MockHttp subclasses which also derive from unittest.TestCase.
Find attached a hackish workaround.
Cheers
Timo
-BEGIN PGP SIGNATURE-
iQIzBAEBCgAdFiEEmwPruYMA35fCsSO/zIxr3RQD9MoFAmZY7woACgkQzIxr3RQD
9Mo9kQ//W+gee44uApzOH4KCdKKCLcshUJPY45b4m4hy91zTrwgnZ1/xVba0luk3
q8p+RgCOAlNO4LoPhEIbnD7jbOwqjbppf0t5sF5GuWKV4aptuNGS7lnGiW26ndcu
7FubV7R3F1wddT01cSvkJNLFsvsURBMzCZMbudvCiUUmaEPiLR6v1sZY/jD1Sg+C
04R6/fHlh7FDBPTbxjYWbNKVslg4J3lk4sEfjzTSEqgWmNx19vHEYPg3+SEs8Sxm
8w261csUDHGXGtMpS5SrLngB2eUR/X36QHdPmuwzBXL5nNrvsUGcHnvfAG+PMdPs
qLaMKyjRCpDJoyxddusB/f3CacHOR/QYsvpCSh1+KFHPFyqQ9wxf3RlFo/A0BzaZ
0ypFQzh32Vw7nJmeESe77uV0EOZuKFZn2scxRIelG6eNrsnMSB7SJbHSyr2IzD+P
k5yMslySlMQRjN4WbJCfQ6q0uste56GgHcw+8wvStnmIFvg0gI5w4YnfCsj/sv5u
ag8Lhknb9u1ICvliYn00i5yif4yJUwB8IhjAOM5qPCbcytOoco5ZDuCro921sk0Y
K+RI9fBltVUBEu1mjpEUNleL8EaysHIuCmcJWQ7BX7fPiTgAUqi95jzSEIke9CFp
Hj254WgYoYs4oW/hxoDtlgcB2lVhhHy5d/rbomedqHCTyPt5bHk=
=GhfF
-END PGP SIGNATURE-
From: =?utf-8?q?Timo_R=C3=B6hling?=
Date: Thu, 30 May 2024 23:20:42 +0200
Subject: Workaround for pytest 8.2
---
libcloud/test/__init__.py | 4
1 file changed, 4 insertions(+)
diff --git a/libcloud/test/__init__.py b/libcloud/test/__init__.py
index 37a74b2..e3b2fd1 100644
--- a/libcloud/test/__init__.py
+++ b/libcloud/test/__init__.py
@@ -108,6 +108,10 @@ class MockHttp(LibcloudConnection):
# within a response
if isinstance(self, unittest.TestCase):
unittest.TestCase.__init__(self, "__init__")
+# Workaround for empty unittest.TestCase instantiation
+if len(args) < 2 and ("host" not in kwargs or "port" not in
kwargs):
+args = []
+kwargs = {"host": "dummy", "port": 9}
super().__init__(*args, **kwargs)
def _get_request(self, method, url, body=None, headers=None):
Bug#1072183: fenics-dolfinx: FTBFS with nanobind 2.0
Source: fenics-dolfinx Version: 1:0.8.0-6 Severity: serious Tags: patch -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dear maintainer, upgrading to nanobind 2.0 made your package FTBFS. I am sorry that I did not check this before uploading to unstable, that is on me. I have seen that Francesco has already fixed the issue upstream [1]. Depending on how far away the next upstream release is, maybe you can backport that fix? Cheers Timo [1] https://github.com/FEniCS/dolfinx/commit/42c43485e81ada306f0b3f1dc735d95539174cbc -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEmwPruYMA35fCsSO/zIxr3RQD9MoFAmZXnqYACgkQzIxr3RQD 9MoXDQ/8DwVCja0oy6uOKmPj6O4OO87042AQMVEzcFKWvn88I+ORD1eSdUFvesgE 88ocsjLmR2YiUNN7vgEzobe/BGuFYizuKvHITpTVAG3Iwmnoh5UBzh2AMhGXEubO TpuX84DG2k6nQjp5qTJrxCIOCgmzjy8iHjyN70csoX6Mjj5lAN+HSmMmBVym8Tmn EIbAFCRB1qJwmMyGXlAN9pCqQg5SmV6ikpyIfcB+T4XBdGS5F8LSF4T6qsWpHtyq HrEgZoubY9DQxEHMUsS+UPzZBj509box1ldl7DuaPJ7JG0/PvEOuzpmuNhOmivPy 69SNnbWjVI/Y7xDH9vYaBNW2H78kybjB6oOKdEw9t/S+yN1gaLK+Jjj1Ifec1iI/ 5XZ5vBo8yqF5ORpJ/dDd9LQrEukqiE+89xCa0/i6jcDSmMWwsymk11HsqDs9SxBv +y1fINhM9C0LtvUXCJbkhFwnYoRF6q5g/GmZ7XNAJHJZTaSJfF3skLYY+5tWLv0o h+XlcS/zyApl9dMR/uE6Az7DqpcQi0rJNseyd17j69svjChyJSSw9wAjaYYtrwrA 0aRzR58oIEfW1NVJObAlWwgmukOlGQJeZ2yRJgO8Utx1hKKbl5D3cCx4LyBEFGuH k1ShEvxa0LPDPsrVtotY6UeGIrVKBMzfXSjXkxLbVWsPPHth8wY= =+PF7 -END PGP SIGNATURE-
Bug#1072153: python3-tornado: unable to instantiate an empty AsyncTestCase
Package: python3-tornado Version: 6.4.0-1 Severity: serious Tags: patch User: debian-pyt...@lists.debian.org Usertags: pytest-8 Control: affects -1 src:python-tenacity src:terminado -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dear maintainer, unittest.TestCase has a feature where it allows instantiating MyTestClass() with the default method name runTest even if a runTest method doesn't actually exist. This is documented in TestCase's docs under "Changed in version 3.2" [0]. Since version 8.2, pytest relies on this, and started breaking on Tornado's AsyncTestCase [1]. Find attached a patch (submitted to upstream [2]) that resolves the issue. Cheers Timo [0] https://docs.python.org/3/library/unittest.html#unittest.TestCase [1] https://github.com/pytest-dev/pytest/issues/12263 [2] https://github.com/tornadoweb/tornado/pull/3374 -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEmwPruYMA35fCsSO/zIxr3RQD9MoFAmZXBNUACgkQzIxr3RQD 9MpHCxAAhX5aHeyUNaO6Zn1Beex96vffhC8r72FQnu0IUw1Ty9tLW8erwX6sdoxm EYft79iBL03nQdyucRgr4cglB1jly/0KOuns9VwqBk8nEwjBvCg9TO0CgryH8eip N8A9Yf0j6A4tW95dbS0Ovs1XfQR4NJ66grDj08vmlTcseBIN9EgrFVEVaOv5QuPm q8Z78jIqmHDc2YBpHEegxOQD4UtkJZofsQwzjGZhwvz9Zlnuv69PBp4r4XxLQEmm iErjajRU9mjBMVEosL89xkl1Fb5AQp/IFvTXNsPhbFfKfwcE0hs5EmUO0WhQOJWr HjiYm8te9QEGhKB1oLad+mg30B9FAMXrdq1qsw/yaZeUaVM9Dpq2LJ2zEGlQKTSX yauPcxxFeAtVmsq94JdBHT7ag/v8fsJ4MO+hAVZikPh21oT4yA/fixFd4dORJIFy LFISGojbAjxFnCDnls5JLK0I+QGGnyVQxYu/wEAG6KkA2+1lDFtU2IiTGy1+EOro FfXde94WF386DlOr0806/4ts4u0qYFcXpwh3SAvJH7Y6ikyt3kgyR+YLkglWeoKM bEcpsPVn/a2jzyXI5o0TRuIOwLyjxJSbKZYm4QECNQneGez38vmiNjaZZXitlkCR fTytpm1DIxAN39ah8yt/NG12yKBidQK824595JmOx/gFV5DRQ5w= =v71Z -END PGP SIGNATURE- commit c851aa8a949524b35f72c82b45a52353aa3c0558 Author: Ran Benita Date: Sun Apr 28 14:17:54 2024 +0300 testing: allow to instantiate an empty AsyncTestCase `unittest.TestCase` has a feature where it allows instantiating `MyTestClass()` with the default method name `runTest` even if a `runTest` method doesn't actually exist. This is documented in `TestCase`'s docs under "Changed in version 3.2"[0]. Since version 8.2, pytest relies on this, and started breaking on Tornado's `AsyncTestCase`[1]. Change `AsyncTestCase` to allow empty instatiation, by matching the upstream code. [0] https://docs.python.org/3/library/unittest.html#unittest.TestCase [1] https://github.com/pytest-dev/pytest/issues/12263 diff --git a/tornado/test/testing_test.py b/tornado/test/testing_test.py index 0429feee..8e2b8db4 100644 --- a/tornado/test/testing_test.py +++ b/tornado/test/testing_test.py @@ -61,6 +61,15 @@ class AsyncTestCaseTest(AsyncTestCase): self.io_loop.add_timeout(self.io_loop.time() + 0.2, self.stop) self.wait(timeout=0.4) +def test_empty_instantation_is_allowed(self): +""" +Test that empty instatiation of an AsyncTestCase is allowed. + +unittest.TestCase docs guarantee this working, and pytest's unittest +support relies on it. +""" +AsyncTestCaseTest() + class LeakTest(AsyncTestCase): def tearDown(self): diff --git a/tornado/testing.py b/tornado/testing.py index bdbff87b..9455411a 100644 --- a/tornado/testing.py +++ b/tornado/testing.py @@ -177,7 +177,17 @@ class AsyncTestCase(unittest.TestCase): # the test will silently be ignored because nothing will consume # the generator. Replace the test method with a wrapper that will # make sure it's not an undecorated generator. -setattr(self, methodName, _TestMethodWrapper(getattr(self, methodName))) +try: +test_method = getattr(self, methodName) +except AttributeError: +if methodName != "runTest": +# We allow instantiation with no explicit method name +# but not an *incorrect* or missing method name. +raise ValueError( +"no such test method in %s: %s" % (self.__class__, methodName) +) +else: +setattr(self, methodName, _TestMethodWrapper(test_method)) # Not used in this class itself, but used by @gen_test self._test_generator = None # type: Optional[Union[Generator, Coroutine]]
Bug#1072057: python3-pytest-asyncio: AttributeError: 'FixtureDef' object has no attribute 'unittest'
Package: python3-pytest-ayncio Version: 0.20.3-1.2 Severity: serious Tags: patch -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dear maintainer, pytest-asyncio has a regression with pytest 8.2. For your convenience, find attached a backported patch that will resolve the issue. Alternatively, you may want to upgrade to upstream version 0.21.2. Cheers Timo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEmwPruYMA35fCsSO/zIxr3RQD9MoFAmZU+SAACgkQzIxr3RQD 9Mp8pBAAq+PAf003L28cueSvIx2gqn4NN6gCTT4KVWalorjf1x5pMreMjQnbaX/I sj/4QaVyLzpUzkL6tVdRqqA0Sb4Ck+ylBdgxYxXgcSEA47bkEWPvNNjBQJuD0CQI W/zLnVDeVPyXg/x8SfZ4MzbHgbuzfG6+bUzd5uLHo1s0Sp9sfOks/HC4jLnTuT+N K2N4R3hUeTE2YpCHvWxMedaCSBvIS8xVvR/6MydX1pY10jWCl/h+G+jP/fT7FeZT 1220Oy9TbaWfJ+RNB81fJnRORjza8PkJ+bEuy6ZnOuR3V3vNdinLgY7h9D2v8+HP fQc/hOlOGZQoCfXIaEnQJd/P02xhpl7Hl/hAO3ycwB2ExsbkP2wpIQ0Wuc4lIppc AevPCWaJR9tlswS2wL0Sw3ysyI9ieEWhIiZ0lT48ySI/dOyADVcP5MNkzrwC+yeN 3K4Oefh6EUM9MMLq3S33dQoR7uu1MZ+KqVxdXdATjnQ5mvVtAytKCSdgxcUB2fwN rhhOPzG+NgtAuUF0HIq9qG9TxCC5QAs61iOssFCXyyjXtrmyntqOLTO0MuE3CCmH 9H8qu7xa+OxKeSPMnZZ5xlFLmONOezLH6S6MoicqRQafjaqD/4ZrV6F99vbtr57L 1Hn8Pi6upWrfHq9xTyld7HY+3W3Hwn4vvDngbY96jCokauwp0n4= =SLRf -END PGP SIGNATURE- diff --git a/pytest_asyncio/plugin.py b/pytest_asyncio/plugin.py index 403d814..b29b755 100644 --- a/pytest_asyncio/plugin.py +++ b/pytest_asyncio/plugin.py @@ -272,9 +272,8 @@ def _wrap_asyncgen_fixture(fixturedef: FixtureDef) -> None: def _asyncgen_fixture_wrapper( event_loop: asyncio.AbstractEventLoop, request: SubRequest, **kwargs: Any ): -func = _perhaps_rebind_fixture_func( -fixture, request.instance, fixturedef.unittest -) +unittest = False if pytest.version_tuple >= (8, 2) else fixturedef.unittest +func = _perhaps_rebind_fixture_func(fixture, request.instance, unittest) gen_obj = func(**_add_kwargs(func, kwargs, event_loop, request)) async def setup(): @@ -310,9 +309,8 @@ def _wrap_async_fixture(fixturedef: FixtureDef) -> None: def _async_fixture_wrapper( event_loop: asyncio.AbstractEventLoop, request: SubRequest, **kwargs: Any ): -func = _perhaps_rebind_fixture_func( -fixture, request.instance, fixturedef.unittest -) +unittest = False if pytest.version_tuple >= (8, 2) else fixturedef.unittest +func = _perhaps_rebind_fixture_func(fixture, request.instance, unittest) async def setup(): res = await func(**_add_kwargs(func, kwargs, event_loop, request))
Bug#1072052: djangorestframework: regression with pytest 8.2 due to invalid config key
Source: djangorestframework Version: 3.15.1-1 Severity: serious Tags: patch -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dear maintainer, djangorestframework has an error in its setup.cfg, using the invalid key testspath instead of testpaths. Starting with pytest 8.2, this is no longer ignored but raises an exception. I suggest removing the invalid key, as it is obviously not needed. Alternatively, you can rename it to testpaths. Cheers Timo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEmwPruYMA35fCsSO/zIxr3RQD9MoFAmZU8hsACgkQzIxr3RQD 9MqXkhAAo7etxr5VDmR6TAWq0r2rofVe9cya8aYV+MXw4Xg7Ipf/dmhqtzxxykgt OcoGnz7J2l4nzage24f+2QyGC4403zhxYT6L1qA07y6aFq5L5Tem3PhbYzH2w/Uq FGlrCLOcmZSWobEyftedsh2t4LM++fjub+d2cBJYd3xh0a8q/PSpIn5DPPJDLCgu PTwjLnDCT9CRzIr4zv2H6JOllp1JOhI+Xiro+dD0GDt1TvFjm+ueVhbSJr52v/wQ rIwujgMaVlrTXbNZfgFMFgdiFuBSD3AzA1Ba61SOKh23yhJsubMkQrNlBkfhaujj 6u9IHHLvlfTrxirr7uzzLp3C7Tkk9xxuZYtnsnJQugM4H99a4ucGJQU9H7WCq4jq b34dV2klxLuA3g+5+5mI76BsMokVs/W+u/1Lvu47Ct3yD08KfCO0XZr0/wW5uodk 2dqJbFQnr7ymU6hW0p74JJL+8QkP3R7ZCu1JheKccEHZy7E+JsAtEENRWCvngiUs j56LRcBtFruGtXSLN1vnQiXbEMEA2JOJGmKyKgqBCXi3Q8QuyKMewwrv1X6TltDB VT02MV3tbCRCKuEN63rPKMgkQHCI0eWcXC/XbTsQcKKForGn4F5ZHW+1VOdOC96b Z31PsmLtJfuYpv33NCnGdzLELpFYBng8rh6vRSgjqXKTAmYowBw= =SJnC -END PGP SIGNATURE-
Bug#1071561: python-gnupg: DPT as package maintainer?
Source: python-gnupg Version: 0.5.2-1 Severity: wishlist -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dear maintainer, I noticed that your package uses the so-called "weak team maintainer" model, where the Debian Python Team is listed as uploader instead of as maintainer. According to Team Policy, that means that other team members must not upload your package at all without asking you first, even for trivial changes. Is this a deliberate decision or merely an artifact of some packaging helper tool such as py2dsc, which generated the initial d/control that way? If it is the latter, would you be willing to switch Maintainer and Uploader and thereby further open up your package for (reasonable) team uploads? Thank you for considering this. Feel free to close the bug and/or tag it wontfix if you do not wish to apply this change. Cheers Timo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEmwPruYMA35fCsSO/zIxr3RQD9MoFAmZMa8kACgkQzIxr3RQD 9MoQGxAAyR5fW+Z43OtucHXoZH255Hz0UkQ+4GzyjtyejBLQdsbPwJKA/2Oq+Evd LtcDuE8Lgv2cNnHozJiYkgJDiMLc3alit7wEoqwhgmOwb2e99CO7Fb5jHnGY6Td8 8/Zhla0ioSTims93tv8t+J3yRNh+rzXu2R61k0dSiy2WjM1xOoN+hcKGmFkz0mkF 61Jad4tPmcKRSRWy9tqEVlFAgWakqnH82A0bfT2UO47VkvsXNmQdVi15YBAHUwR6 t1GaIsTWtkFgfeokHSmWabPFRqPei8xNAo4GenEKJ/3cVq+0fmyGjHImOLwGNqWn Di3qnu1Au0PWkQ+g0H+zzKni8QVqItuMqMiqybGpJ3VBGaHFvjH2ndDBYXcKew3p yJT1cAPm17wOHXIt6P/AwKnyb74iNUbByX7muGpS4MnGX8IE8+klYnGTD7G1/DC5 Y73bO4FgvVSRWJ6LWeC+4PRLcHhLHcw05QVOWzXtAQ9gcnnl7hZBCo5npXLuRp7L k++mxXdwoVzN/jGXfAJ28tPabQz3PeoABXau85mCVVcCz/wOITr8GFOUE7Dk7GGl vSiv7lT7EsS6TU7Q8tZQZzEOrwHvpQfuOBZdhGoTpfj7TODOC7LLHgVGXvmY7Rai 8X5cfyblNM2wTZ5UZm+jP8V/YlV89uiMEzew3Q3dMYL/4c8dvfk= =W3vP -END PGP SIGNATURE-
Bug#918454: Remove libtool from vim build
Hi James, attached is a patch to remove libtool from the libvterm build in vim, which allows you to drop the Build-Depends on libtool-bin. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ From: =?utf-8?q?Timo_R=C3=B6hling?= Date: Mon, 20 May 2024 23:22:43 +0200 Subject: Remove libtool --- src/libvterm/Makefile | 28 ++-- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/src/libvterm/Makefile b/src/libvterm/Makefile index 94ca409..bedc69c 100644 --- a/src/libvterm/Makefile +++ b/src/libvterm/Makefile @@ -25,8 +25,8 @@ endif CFILES=$(sort $(wildcard src/*.c)) HFILES=$(sort $(wildcard include/*.h)) -OBJECTS=$(CFILES:.c=.lo) -LIBRARY=libvterm.la +OBJECTS=$(CFILES:.c=.o) +LIBRARY=libvterm.a BINFILES_SRC=$(sort $(wildcard bin/*.c)) BINFILES=$(BINFILES_SRC:.c=) @@ -55,10 +55,10 @@ MAN3DIR=$(MANDIR)/man3 all: $(LIBRARY) $(BINFILES) $(LIBRARY): $(OBJECTS) - $(LIBTOOL) --mode=link --tag=CC $(CC) -rpath $(LIBDIR) -version-info $(VERSION_CURRENT):$(VERSION_REVISION):$(VERSION_AGE) -o $@ $^ $(LDFLAGS) + $(AR) rcs $@ $^ -src/%.lo: src/%.c $(HFILES_INT) - $(LIBTOOL) --mode=compile --tag=CC $(CC) $(CFLAGS) -o $@ -c $< +src/%.o: src/%.c $(HFILES_INT) + $(CC) $(CFLAGS) -o $@ -c $< src/encoding/%.inc: src/encoding/%.tbl perl -CSD tbl2inc_c.pl $< >$@ @@ -66,16 +66,16 @@ src/encoding/%.inc: src/encoding/%.tbl src/fullwidth.inc: @perl find-wide-chars.pl >$@ -src/encoding.lo: $(INCFILES) +src/encoding.o: $(INCFILES) bin/%: bin/%.c $(LIBRARY) - $(LIBTOOL) --mode=link --tag=CC $(CC) $(CFLAGS) -o $@ $< -lvterm $(LDFLAGS) + $(CC) $(CFLAGS) -o $@ $^ $(LDFLAGS) -t/harness.lo: t/harness.c $(HFILES) - $(LIBTOOL) --mode=compile --tag=CC $(CC) $(CFLAGS) -o $@ -c $< +t/harness.o: t/harness.c $(HFILES) + $(CC) $(CFLAGS) -o $@ -c $< -t/harness: t/harness.lo $(LIBRARY) - $(LIBTOOL) --mode=link --tag=CC $(CC) $(CFLAGS) -o $@ $^ $(LDFLAGS) -static +t/harness: t/harness.o $(LIBRARY) + $(CC) $(CFLAGS) -o $@ $^ $(LDFLAGS) -static .PHONY: test test: $(LIBRARY) t/harness @@ -83,9 +83,9 @@ test: $(LIBRARY) t/harness .PHONY: clean clean: - $(LIBTOOL) --mode=clean rm -f $(OBJECTS) $(INCFILES) - $(LIBTOOL) --mode=clean rm -f t/harness.lo t/harness - $(LIBTOOL) --mode=clean rm -f $(LIBRARY) $(BINFILES) + rm -f $(OBJECTS) $(INCFILES) + rm -f t/harness.o t/harness + rm -f $(LIBRARY) $(BINFILES) .PHONY: install install: install-inc install-lib install-bin signature.asc Description: PGP signature
Bug#1071527: ros2-osrf-testing-tools-cpp: unreproducible on arm64 due to CMake config variance
Source: ros2-osrf-testing-tools-cpp
Version: 2.1.0+ds-1
Severity: normal
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
- ---
/srv/reproducible-results/rbuild-debian/r-b-build.Yi493i0G/b1/ros2-osrf-testing-tools-cpp_2.1.0+ds-1_armhf.changes
+++
/srv/reproducible-results/rbuild-debian/r-b-build.Yi493i0G/b2/ros2-osrf-testing-tools-cpp_2.1.0+ds-1_armhf.changes
├── Files
│ @@ -1,5 +1,5 @@
│
│ 6faf8edfca069d81833ab4890196de8a 652996 debug optional
libosrf-memory-tools0d-dbgsym_2.1.0+ds-1_armhf.deb
│ 571d2445535c4e3f5fca553a222cda58 35440 libs optional
libosrf-memory-tools0d_2.1.0+ds-1_armhf.deb
│ db5865b534d8b4361205a343046cd114 123452 debug optional
libosrf-testing-tools-cpp-dev-dbgsym_2.1.0+ds-1_armhf.deb
│ - 6d372e8bc5ad65c1ae49c1bb72b88fa1 25784 libdevel optional
libosrf-testing-tools-cpp-dev_2.1.0+ds-1_armhf.deb
│ + dc4921c05caa401d35235e4034a96755 25784 libdevel optional
libosrf-testing-tools-cpp-dev_2.1.0+ds-1_armhf.deb
├── libosrf-testing-tools-cpp-dev_2.1.0+ds-1_armhf.deb
│ ├── control.tar.xz
│ │ ├── control.tar
│ │ │ ├── ./md5sums
│ │ │ │ ├── ./md5sums
│ │ │ │ │┄ Files differ
│ ├── data.tar.xz
│ │ ├── data.tar
│ │ │ ├── file list
│ │ │ │ @@ -21,15 +21,15 @@
│ │ │ │ drwxr-xr-x 0 root (0) root (0)0 2024-04-28
22:34:04.00 ./usr/lib/arm-linux-gnueabihf/
│ │ │ │ drwxr-xr-x 0 root (0) root (0)0 2024-04-28
22:34:04.00 ./usr/lib/arm-linux-gnueabihf/osrf_testing_tools_cpp/
│ │ │ │ drwxr-xr-x 0 root (0) root (0)0 2024-04-28
22:34:04.00 ./usr/lib/arm-linux-gnueabihf/osrf_testing_tools_cpp/cmake/
│ │ │ │ -rw-r--r-- 0 root (0) root (0) 1013 2024-04-28
22:34:04.00
./usr/lib/arm-linux-gnueabihf/osrf_testing_tools_cpp/cmake/memory_toolsExport-none.cmake
│ │ │ │ -rw-r--r-- 0 root (0) root (0) 4780 2024-04-28
22:34:04.00
./usr/lib/arm-linux-gnueabihf/osrf_testing_tools_cpp/cmake/memory_toolsExport.cmake
│ │ │ │ -rw-r--r-- 0 root (0) root (0) 1093 2024-04-28
22:34:04.00
./usr/lib/arm-linux-gnueabihf/osrf_testing_tools_cpp/cmake/memory_tools_interposeExport-none.cmake
│ │ │ │ -rw-r--r-- 0 root (0) root (0) 5612 2024-04-28
22:34:04.00
./usr/lib/arm-linux-gnueabihf/osrf_testing_tools_cpp/cmake/memory_tools_interposeExport.cmake
│ │ │ │ --rw-r--r-- 0 root (0) root (0) 2716 2024-04-28
22:34:04.00
./usr/lib/arm-linux-gnueabihf/osrf_testing_tools_cpp/cmake/osrf_testing_tools_cppConfig.cmake
│ │ │ │ +-rw-r--r-- 0 root (0) root (0) 2664 2024-04-28
22:34:04.00
./usr/lib/arm-linux-gnueabihf/osrf_testing_tools_cpp/cmake/osrf_testing_tools_cppConfig.cmake
│ │ │ │ -rw-r--r-- 0 root (0) root (0) 367 2024-04-28
22:34:04.00
./usr/lib/arm-linux-gnueabihf/osrf_testing_tools_cpp/cmake/osrf_testing_tools_cppConfigVersion.cmake
│ │ │ │ -rw-r--r-- 0 root (0) root (0) 972 2024-04-28
22:34:04.00
./usr/lib/arm-linux-gnueabihf/osrf_testing_tools_cpp/cmake/test_runnerExport-none.cmake
│ │ │ │ -rw-r--r-- 0 root (0) root (0) 4562 2024-04-28
22:34:04.00
./usr/lib/arm-linux-gnueabihf/osrf_testing_tools_cpp/cmake/test_runnerExport.cmake
│ │ │ │ -rwxr-xr-x 0 root (0) root (0)18120 2024-04-28
22:34:04.00 ./usr/lib/arm-linux-gnueabihf/osrf_testing_tools_cpp/test_runner
│ │ │ │ drwxr-xr-x 0 root (0) root (0)0 2024-04-28
22:34:04.00 ./usr/share/
│ │ │ │ drwxr-xr-x 0 root (0) root (0)0 2024-04-28
22:34:04.00 ./usr/share/doc/
│ │ │ │ drwxr-xr-x 0 root (0) root (0)0 2024-04-28
22:34:04.00 ./usr/share/doc/libosrf-testing-tools-cpp-dev/
│ │ │ ├──
./usr/lib/arm-linux-gnueabihf/osrf_testing_tools_cpp/cmake/osrf_testing_tools_cppConfig.cmake
│ │ │ │ @@ -33,23 +33,23 @@
│ │ │ │ define_property(TARGET
│ │ │ │PROPERTY LIBRARY_PRELOAD_ENVIRONMENT_IS_AVAILABLE
│ │ │ │BRIEF_DOCS "Indicator of whether memory_tools is available in the
current build configuration."
│ │ │ │FULL_DOCS "Indicator of whether memory_tools is available in the
current build configuration."
│ │ │ │ )
│ │ │ │ string(REPLACE
│ │ │ │"memory_tools" "osrf_testing_tools_cpp::memory_tools"
│ │ │ │ - memory_tools_extra_test_env
"LD_PRELOAD=$")
│ │ │ │ + memory_tools_extra_test_env "")
│ │ │ │ if(NOT memory_tools_extra_test_env)
│ │ │ │# On Windows, for example, this might be empty.
│ │ │ │set(memory_tools_extra_test_env "NO_LIBRARY_PRELOAD=1")
│ │ │ │ endif()
│ │ │ │ set_target_properties(osrf_testing_tools_cpp::memory_tools PROPERTIES
│ │ │ │LIBRARY_PRELOAD_ENVIRONMENT_VARIABLE ${memory_tools_extra_test_env})
│ │ │ │ set_target_properties(osrf_testing_tools_cpp::memory_tools PROPERTIES
│ │ │ │ - LIBRARY_PRELOAD_ENVIRONMENT_IS_AVAILABLE "TRUE")
│ │ │ │ +
Bug#1071463: pygmsh: autopkgtest regression with pytest 8 on i386
Source: pygmsh Version: 7.1.17-4 Severity: serious User: debian-rele...@lists.debian.org Usertags: bsp-2024-05-mdc-ber -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dear maintainer, your package starting hanging in the autopkgtest on i386 with pytest 8, resulting in a timeout. See https://ci.debian.net/packages/p/pygmsh/testing/i386/46854179/ as example. Cheers Timo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEmwPruYMA35fCsSO/zIxr3RQD9MoFAmZKLIsACgkQzIxr3RQD 9MpR0g//WVf5f11r+XYrCspMB2fxm+Z3JNaPh0F+s5zb7Rhwalrjd9k5V+wFy4YO ebwczCSDHDcg+QTp2ShCj1AZ0LtNi9rVuiGuKoiWou3Up4xYNBjtQ2AnzgVK0gOO /kWWIwIgFqK7n1mMNRQlEQHl4WEKvkg5yTVVF/YmJ4PDwgbhZRjsGjupM5uv7uVO 4wopGPU4nC/IpBbpiNaQQdou+JpRQbHJZztgQnNR000SIVdy2OJSfaSLlkmGRGxb vipw1AoCIugJV+6r9rJh6Zn+flZtqdz1eN4Zc/nsaSX2r+WF8CSnTHVw7RIOG8iT NTI0HDhZelSb2s2q+Awb/yqOXzbEnqszZ1rN6mPME7z9STu2PXIwKhxzMM67p2Ky GMiknL1v/51AnhNKZxB5iDPsoEnvEK/lJB/fB94AnWW1SjrhnzZxLGIj1e00RkS1 AHJnI6v7epPHSQzT6t1kJVR/VjOn7ptOr3CvhyhzXLr85a9QrTaaEY/ybToTMZ1C 95btUQeCkWMhOC5PXFlkN+1Nx6G5FAvzx2wy5oEfiLbXAL+6X8LUFOxWDG2E4loa wHlGj/mMrmuWw/UvL3Aw2WLO+Hts4OYdSbWv6z2hLl/YF/ZLGaEyLrmPqya/7SAL Il/0wMuJ8zk6NV5rWLsOcBNvWvFQsIwudyaXKqMVySscO0PFS0s= =yFnQ -END PGP SIGNATURE-
Bug#1071461: nibabel: nose-style setup/teardown is no longer supported in pytest 8
Source: nibabel Version: 5.2.1-1 Severity: serious User: debian-rele...@lists.debian.org Usertags: bsp-2024-05-mdc-ber -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dear maintainer, your package uses setup() and teardown() functions which used to be part of the nose compatibility layer in pytest. However, these functions have been deprecated since pytest 7.2 and support for nose has been permanently removed as of pytest 8: https://docs.pytest.org/en/8.1.x/deprecations.html#setup-teardown You can probably just replace setup() and teardown() by setup_method() and teardown_method(), respectively. Cheers Timo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEmwPruYMA35fCsSO/zIxr3RQD9MoFAmZKK00ACgkQzIxr3RQD 9MoL0Q//SQhorKZGmcLjv2ObqEbVIrD2OFMzfTtaE0XoarNIhSlr17e/odtfv3Ua rtzqkVyF3TruaD2rjMnwGsK6fAGG+La8xVDDmSe2vAIqhZespaxSoatVqtdH9gMN dxexaq944j+mvOP0kkSsmf1K1xmEr2TlmdkVJ5zGYFrkTVvdIzuqxODhu7eb5qah eZINi2Ht+MNM/mW851XZWMuDCLJsw14JmzFl3S0CRMABJYudS+9cNJYsrACOa7Sl sPdUbsA6d+SQVOCVgLD1qfMcOuKhRLTqIi1K09YEGaFc5QmDX/sd0pVHeCZ6+o/K fSwc0Q+dFqmPzo2m4eBuxjCjjHUQKtpbIXI7fwD1oyLbI80OVE9GWS0Ll45K2xzw kWmxBIARpXrhvbzEBOcntR5pyh9MsDRJQzNnPe/c5d80YDUfORPwi0fuRpC1rxbr ktBVuI8wo55J2Vt3cN47v6NLlRPKaVU9UX3ePoRdNDk/HkvBa5J8iSNpaUqHu4an 66HyGf1LaLOWF+CYD78JMvu1rYiihD/CY9h6KuKF2gFjPhSaqoS4UopmZRPQV+4E MlFLjmJli5GpvHTHjPRQULjvN8EgX1Xrha7UAxt/Ffe0PWcMBokvH8lqIFyzZ2oO ThInCbz+XBOkpYtGgjLYuAZNfzg8JOpcqgzvCJuW9EiihHzW2QU= =VeVj -END PGP SIGNATURE-
Bug#1071448: dipy: FTBFS on 32 bit archs with ArrayMemoryError
Source: dipy Version: 1.9.0-2 Severity: serious Tags: ftbfs User: debian-rele...@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dear maintainer, your package does not build on armhf, armel, and i386 because one tests allocates a rather large array (which fails on the buildd machines): > data = 255 * rng.random((197, 233, 189, 15)) E numpy.core._exceptions._ArrayMemoryError: Unable to allocate 993. MiB for an array with shape (197, 233, 189, 15) and data type float64 Cheers Timo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEmwPruYMA35fCsSO/zIxr3RQD9MoFAmZKAkUACgkQzIxr3RQD 9Moqnw//QjkAG+RG9VH78jKUefxRe2eNmmH/zSChSdTAMzit4UrY/TcFgP1H/nIF ZhbsjlDPNvu3Wxsf7zLORHgN+trRV69Na3RLECKqxb+ImHIShMZKPd3IYKcKRPC/ XysUUGozWSixnNiD+PfhK8Eo2kh4odpwz9WiygAy0cH0oVGP+S6z6y7/BkKDjrxE 45aVDrCCDcbjsSoXOrGh6AIEYQxQ27sxoLptU+M2fS1WMd+TWmnQ3J4rJSf/0psa SetJ2Vm87kdgfIvPLjYY7XmFJ6dTcalt54Z0KTLQfBb0fO81THPDKm5AJX0dtimy QMCSDQYh9j+HO5LmhR3y4bswf3jxrDDCeOQ21QXln+UVG/q+nDjtQIwWyA6cj6za V9T2ERS5e+eMK13VkxVHLE3SEy/bwhoctj271m2370pLI6guYeLMO5bMdoeikyFg voH3peV08RWz22wOfymX3DK8DmcwWUDcQf8BVIv5MAv8mWVVaqzUnn5pt4o4h5aL Ul9WgFaGoCLi+Sp0VSIsFzQEzrO4hWRB+RaDeaAklRHTeAdSjg+/9959j36ZwkIy A2bDtVWtAEhYEuNj3LUUjzs0OR8gu4uTdt6Tjpb0HM2jSL3CyiIddLs+tw1Fe7ev GweUn20QAa3HF40GfWXaUS75pwap2BpyG5IQcyjWtD7W7ihDIbY= =SYkm -END PGP SIGNATURE-
Bug#1069065: gcc-14: should -for-host builds move from cross-toolchain build to DEB_STAGE=rtlibs?
Hi,
On Mon, 15 Apr 2024 18:10:16 +0200 Helmut Grohne
wrote:
Which gcc builds should emit -for-host packages?
[...]
I have added this patch to rebootstrap now and it has generally
improved bootstrapping. In particular, gcc-N-for-host is
practically coinstallable.
I find your reasoning convincing and had a look at the patch. The
patch also looks reasonably sane to me. There is a typo near the end
("disbaled" instead of "disabled"), which does not influence runtime
behavior because the variable is only checked for equality with
"yes".
Moving build logic to binary-forhost.mk gets rid of quite a lot of
code duplication (the do_for_host_package macro becomes the
authoritative source), which I consider a Good Thing. Ultimately, it
is the maintainer's judgement call whether they want it like this or
would rather change the conditional inclusion logic to have the
-for-host package build logic reside with the respective language
addon Makefiles.
Cheers
Timo
--
⢀⣴⠾⠻⢶⣦⠀ ╭────╮
⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │
⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄ ╰╯
signature.asc
Description: PGP signature
Bug#1071225: python-ase: FTBFS because of deprecated pytest.warns(None) usage
Source: python-ase Version: 3.22.1-4 Severity: serious Tags: patch ftbfs User: debian-pyt...@lists.debian.org Usertags: pytest-8 User: debian-rele...@lists.debian.org Usertags: bsp-2024-05-mdc-ber -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dear maintainer, the python-ase fails to build with pytest 8+ because the deprecated pytest.warns(None) idiom has been removed. See the attached patch for an easy fix. Cheers Timo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEmwPruYMA35fCsSO/zIxr3RQD9MoFAmZGHy8ACgkQzIxr3RQD 9Mqm6xAArJlt0P2e5z/kvuQSkXiQpQSQ+pcAva6pC7q/T4RywOqBD18Ds6RzGL+V xhXb4hOjHtNYgfuM3UKeUQPUsw+sYrLTnMYvXpzlnW96UKdBpSlhmspKZa3ks81h cfLTXquZrux6cw0Fjq6FUvqZ1y+FOg+2skge5BADE3LWvjerSsqSxcf4f55x1sV+ 6tnCP43z8DNh2ZpwC+ioLoLy5hFeF0imdSBXoI1AXHvilYj0//xiB+HwB18V7tME zM3OXu4OV+M7sHqAYE3Z1YpVicXt/Hb81+W9BINLowVPrW/CJYO37M8lFtUM8dCe l4uXdHPWR0FiXTIwH3SNu79oW5Tsjw9+zQvYBBdRhrk0KD5bvmofk8CKsHNyqAia W85EECZpSo5fhxPIvxJxMQtJvHChRvXPag19jBYfc4GBfFHEy1782AsQxx/6WzK5 XEBQquHUXCRireZ2LKh4RGyZswa5drsfxEItLP2JGBcXQrKKC3qkSbmmtYbj4Qpx UKmdSDEaswk+2GBe1WUzMnskYti+WzsTBHIxsO94CkIQv4/WKJcp3dnIQMEGcrIs pYZN5jSlSkPldhsqnw9pOCiaCkDs1WAwc0LPB4R5Z21CSecGsU++zlHX1YgJqz0j IFBxyaela++n53Qh9szB/bQxmArK4yxV6bL+yDozfOpJYE+inLg= =4UTB -END PGP SIGNATURE- From: =?utf-8?q?Timo_R=C3=B6hling?= Date: Thu, 16 May 2024 16:43:29 +0200 Subject: Fix deprecated pytest.warns(None) --- ase/test/fio/test_netcdftrajectory.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ase/test/fio/test_netcdftrajectory.py b/ase/test/fio/test_netcdftrajectory.py index c51f385..9ecaa6e 100644 --- a/ase/test/fio/test_netcdftrajectory.py +++ b/ase/test/fio/test_netcdftrajectory.py @@ -100,7 +100,7 @@ def test_netcdftrajectory(co): # File is not created before first write co.set_pbc([True, False, False]) d = co.get_distance(0, 1) -with pytest.warns(None): +with pytest.warns(): t.write(co) del t # Check pbc
Bug#1071149: socklog-run: replace dh-sysuser with sysusers.d
Package: socklog-run Version: 2.1.0+repack-5 Severity: wishlist Tags: patch X-Debbugs-Cc: hel...@subdivi.de -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dear maintainer, the dh-sysuser package has not gained much traction in the past 7 years and has multiple deficiencies. The systemd sysusers.d format has alternative implementations independent from systemd now, so we should settle on that standard and drop dh-sysuser althogether (there are only 6 reverse dependencies left anyway, including yours). Find attached a patch that updates your package to use the sysusers.d config to create the necessary users for socklog-run. Cheers Timo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEmwPruYMA35fCsSO/zIxr3RQD9MoFAmZEe4UACgkQzIxr3RQD 9MoeCw//Z+ZpXql14GSjpeKme5443JNcLaz1tZkvjsQGp/CQtxTtvM6lTs3NDQY/ S+9RAAMumWB1MRxd0ohZ4+9gebcQ7KOPF+/4EsTV6Yd7VKzk4/wtlJqcy6A6sdHC K4dOPz4+rz4pnQTssPUWBMfcX5VoaJza7Vb3bLM3fszyPIGRJmp6Al5D2+634tuN i3sGO6CLKqhMRq+z6YunwqCxn5kSoaTBtEgVWvSkGAYKNTRX0DxQrZscXowEndae KDlCO5lO8V6yc5NDs5mxS87nExbvhPxKxa2Dz4asG6+qTrMotd/aHZ2Z/lSTVO7m vi+/aHizH2Oduv63W/XaJLgWI1il8AbjLfN1HwTraQ2fVNEFAP1IsA4GvFhWkeYK ZTo8qdZen1vqIpsr6SOFdn7Yv6JwXAcjYWzaHQOgRsZtNkMvp1ioM7HC3+EDOv6k ZsYcSHo1jd0KyNq/9u7U6g0P3bLG1lskczUDGO2A7NTstjqfUhvuWy0d+9Q/ZDjM Kxhbc2DcMw4Kjv6ZMn0DiN42qeig1Q+yPa+nhc5y8dcruyPhIsIZHUEkk0XyeyeC qm24uvT0pkqyA1vj2/xER0wQ4sTwerDz54RUpfieAeIO0wBtM1QuOsNXWVm7HfUR reNkedDdwvcyYvn9BwjgC4+vWYl0uagL2GoGfrmzIbhrGcK6Wx4= =qsRP -END PGP SIGNATURE- diff --git a/debian/control b/debian/control index 1037dfb..178300a 100644 --- a/debian/control +++ b/debian/control @@ -8,8 +8,8 @@ Vcs-Git: https://salsa.debian.org/debian/socklog.git Standards-Version: 4.6.2 Homepage: http://smarden.org/socklog Build-Depends: debhelper-compat (= 13), + debhelper (>= 13.3), dh-runit, - dh-sysuser, doc-base Rules-Requires-Root: no diff --git a/debian/rules b/debian/rules index a507185..e2c024f 100755 --- a/debian/rules +++ b/debian/rules @@ -8,7 +8,7 @@ CONF_CC = src/conf-cc CONF_LD = src/conf-ld %: - dh $@ --with runit,sysuser + dh $@ --with runit override_dh_auto_clean: rm -rf compile command @@ -32,3 +32,6 @@ endif override_dh_installchangelogs: dh_installchangelogs package/CHANGES + +execute_after_dh_installinit: + dh_installsysusers diff --git a/debian/socklog-run.sysuser b/debian/socklog-run.sysuser deleted file mode 100644 index 4bd6dac..000 --- a/debian/socklog-run.sysuser +++ /dev/null @@ -1,5 +0,0 @@ -_socklog-unix defaults -_socklog-klog defaults -_socklog-inet defaults -_socklog-ucspi-tcp defaults -_socklog-notify defaults diff --git a/debian/socklog-run.sysusers b/debian/socklog-run.sysusers new file mode 100644 index 000..8cf6fe8 --- /dev/null +++ b/debian/socklog-run.sysusers @@ -0,0 +1,6 @@ +u _socklog-unix - "Socklog unix user" +u _socklog-klog - "Socklog klog user" +u _socklog-inet - "Socklog inet user" +u _socklog-ucspi-tcp - "Socklog ucspi-tcp user" +u _socklog-notify - "Socklog notify user" +
Bug#1070445: numpy: Proposal to bring back the python-numpy-doc package
Hi Michael, * Michael R. Crusoe [2024-05-05 15:30]: I would like to bring back the python-numpy-doc binary package as part of my personal interest in seeing high quality -doc packages in the Python scientific/research computing area. You beat me to the punch :) Thanks for your work! Here are my proposed changes: https://salsa.debian.org/python-team/packages/numpy/-/tree/debian/experimental?ref_type=heads Looks good to me, except for a few minor issues and personal preferences, which I pushed to the branch. If you approve of re-introducing the python-numpy-doc binary package, then I'll make a team upload to the NEW queue in the 'experimental' distribution. Once that is accepted by the FTP team, then I'll merge my changes into the 'debian/unstable' branch for the next upload of the numpy source package. Yes, please go ahead, but note that the debian/unstable branch is stale and main development happens on the master branch at the moment. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Bug#1070425: bookworm-pu: package numpy/1:1.24.2-1+deb12u1
Package: release.debian.org
Severity: normal
Tags: bookworm
X-Debbugs-Cc: nu...@packages.debian.org
Control: affects -1 + src:numpy
User: release.debian@packages.debian.org
Usertags: pu
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
[ Reason ]
python3-numpy has an undeclared file conflict on /usr/bin/f2py with
python-numpy. Even though python-numpy is gone, it is possible to have that
package linger on systems, which will affect the upgrade to bookworm
(#1053649).
Note that python3-numpy in bullseye did *not* yet with the conflicting file,
so it possible for python-numpy to coexist on a fully upgraded bullseye
installation, only triggering this issue with the upgrade to bookworm.
[ Impact ]
Users who upgrade to bookworm and still have python-numpy installed will
experience an unpack error during the upgrade.
[ Tests ]
I did not test the upgrade scenario because I consider the change trivial and
the regression risk non-existent.
[ Risks ]
The fix declares a package conflict with a package that is no longer part of
bookworm (or bullseye, for that matter), so it will have no effect on new or
existing bookworm installs.
[ Checklist ]
[x] *all* changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in (old)stable
[ ] the issue is verified as fixed in unstable
[ Changes ]
The binary package python3-numpy will now declare a conflict on python-numpy.
This will ensure that python-numpy is uninstalled during the bookworm upgrade.
[ Other info ]
Regarding a potential fix for unstable:
As the python-numpy package is no longer shipped, it cannot be reintroduced
after a proper upgrade to bookworm, which is why I decided to not declare the
conflict in trixie/sid.
There is a remote possibility that another package will gain a new dependency
on python3-numpy going from bookworm to trixie, so technically, a python-numpy
package could survive the bookworm upgrade and then conflict with the trixie
upgrade. If that is a concern, I will add the conflict in trixie/sid as well.
-BEGIN PGP SIGNATURE-
iQIzBAEBCgAdFiEEmwPruYMA35fCsSO/zIxr3RQD9MoFAmY3Q7oACgkQzIxr3RQD
9Mr3nxAAycMncFSAnDkiqT/Cu1AWs5RtECLt94UZ862GUi3WkkhSBMEbkxpI5ums
2CvpfA2CRAp2FkoaNY23YmL+yo8JpN5iAHHEvVKsabvNytV+PDkM4bXLe58O9llp
87TIxohuMUAjsW7huizYRJlvNTqPcwSYLDaM/V6Cr2tbeV8cSFdoUfCIoR+10F6q
B9Whp9x+kJaXiNMJ6tIG3uvK0C2FsHMArqNUBVrqDXOakjFgBajwJcuh9fs6/cLQ
Ur2ZlW8clTbIdltZGGmU+pc3Syg5QTUTHQ7JQP59MrLs7AqqqN1N7VssEetOJikS
bnjc9oiVlYzCQVKCabaYJWm/2qw0fUESSyBxH47RAZqTZ5U/NvSgRyWVnumDBYpT
3tkgVcRDJQwksKH07IdCBlOXjlGsm6awa7O45j1Gz0UMXLR7/zhBX3STm4+cF/78
Jk+tNREQ/UGZkjxwhWC910/JcdxsSN4iUXZKWhdMipJSqmBHeAKdBILB4A7ShFuH
dSneIl2vTOo/kC8dhdXSXN2Gzs1t4JuNrQRAs5hKLtj9ABwFwea9FzEDiWJHnygs
MK+o+ILto3c6DS/p24DgkyoGrxw7NlHAxl0Jl1WBnFv4YeuOtJoCVLNHbY4pSbyt
jOklCDgF81Ib2o7nxUXw5I8euRCq/NSpfEgXhGhEFFnUCt/lowI=
=IcBC
-END PGP SIGNATURE-
diff --git a/debian/changelog b/debian/changelog
index 9953311b..776d076f 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+numpy (1:1.24.2-1+deb12u1) bookworm; urgency=medium
+
+ * Declare conflict with python-numpy due to f2py (Closes: #1053649)
+
+ -- Timo Röhling Sun, 05 May 2024 09:56:59 +0200
+
numpy (1:1.24.2-1) unstable; urgency=medium
* New upstream release
diff --git a/debian/control b/debian/control
index 6d723b4a..92fd0f24 100644
--- a/debian/control
+++ b/debian/control
@@ -37,6 +37,7 @@ Provides: dh-sequence-numpy3,
python3-numpy-dev,
${numpy3:Provides},
${python3:Provides},
+Conflicts: python-numpy
Description: Fast array facility to the Python 3 language
Numpy contains a powerful N-dimensional array object, sophisticated
(broadcasting) functions, tools for integrating C/C++ and Fortran
diff --git a/debian/gbp.conf b/debian/gbp.conf
new file mode 100644
index ..69a939b5
--- /dev/null
+++ b/debian/gbp.conf
@@ -0,0 +1,4 @@
+[DEFAULT]
+debian-branch = bookworm
+upstream-branch =
+
Bug#1070112: ipykernel: nose-style setup/teardown is no longer supported in pytest 8
Source: ipykernel Version: 6.29.3-1 Severity: serious Tags: patch -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dear maintainer, your package uses setup() and teardown() functions which used to be part of the nose compatibility layer in pytest. However, these functions have been deprecated since pytest 7.2 and support for nose has been permanently removed as of pytest 8: https://docs.pytest.org/en/8.1.x/deprecations.html#setup-teardown You can probably just replace setup() and teardown() by setup_method() and teardown_method(), respectively. Cheers Timo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEmwPruYMA35fCsSO/zIxr3RQD9MoFAmYwxPkACgkQzIxr3RQD 9MpmdA//QJJ0rP8SwT2BDr+p2tTDDbn7LLxna1KUThQQAHbOA6telFy3+LCrvB35 GQhA+00so2IWvgXK0P0WNyvpkBcCaUx+7Dwoyx1GWFz+La+2erMsIXeGdBuZ8S0e rr6iDdfSq3urZ/FnW0Lj0DtHW2u8x10AVIl6f3u1S5wEDf4GCG6IKH6NZqeM59Ee N4hKcl8aWFW+3/j2k67pmY9GntY4hSZw99hibrWDlZMu4v/zQNbsS8OhQYqBQ8kR axGfL5tasprIOD9nqtSTiUrYWtUh/Neu9P6w0KaVZcmP0jJ03GE67P8y5srCVo4s PVYLTQ+NzRX1f0CajaWFGyP47bBfpOX89mGt383lFPkVYeDOowLM68iv7POGqmWs xcNzeD+4f3pN/nlgaQfPdl6Q+700njiQCwaCpLpH/HTwA+L7fFash4HBeQX2pjYv Z9GOzrwPccjfKXRhe8Wy87pYJZ8Zp0mccL1ItYK7XSDdTqduKHqvfxY08dPJTxqs MlntK4Bnp77hWLXVejBIN9cFHWWHOBjFcsKnlfuTkrS3gKerl8ObPFcHSgHOduOj cWVcZF1JJBnCTKgCxgvvrUX/MPeKA+nZwgtbrtuyDuY+RHGE4a5GfzBP6O3vAx5A chzTjOft7gyKyHksB2O2Nsj7D7437x/hmhhM50hyaTf1IA/ZEq8= =s0ox -END PGP SIGNATURE-
Bug#1069890: Resignation & call for votes to elect the Chair
* Sean Whitton [2024-04-26 14:04]: ===BEGIN A: Christoph Berg B: Matthew Garrett C: Helmut Grohne D: Stefano Rivera E: Timo Röhling F: Craig Small G: Matthew Vernon H: Sean Whitton ===END I vote H > ABCDEG > F Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Bug#1065810: New appointments for the Debian Technical Committee: csmall
* Andreas Tille [2024-04-26 14:22]: The Technical Committee now consists of: * Sean Whitton (chair) * Simon McVittie * Christoph Berg * Helmut Grohne * Matthew Vernon * Matthew Garrett * Stefano Rivera * Timo Röhling * Craig Small Correct me if I'm wrong, but I think Simon McVitie's term has ended already. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Bug#1069770: elementpath: please update to latest upstream release
Hi, * SZ Lin (林上智) [2024-04-24 22:03]: I'm not currently using this package. The original maintainer is MIA, and I'm considering whether to orphan it directly. Would you be interested in taking over? Sure! I'll move it to the Debian Python Team and maintain it there. Thanks for the quick reply! Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Bug#1069770: elementpath: please update to latest upstream release
Source: elementpath Version: 3.0.2-1 Severity: wishlist Control: affects -1 src:python-xmlschema -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dear maintainer, I'd like to update python-xmlschema, but this needs to be coordinated with elementpath. Could you please update elementpath? Cheers Timo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEmwPruYMA35fCsSO/zIxr3RQD9MoFAmYpARMACgkQzIxr3RQD 9MpCrA/7BNJIB7+w7k/ImJY0i06BDhfT6HTITaxHjoqL6+i43nsTRUASel2cbhvM B+inRa03W8/QlQr0TkI7gurrIZwujerP0Ux3z1OBQAIGflGFU3yTQuSwj1WVXJU8 PIJ71fDhTegYqUA65R9QT3KOvVkCq+5P87TFy8hl2AVOvBsxkK9rGsut6KlFconf +fYzbJEtaBQmMSKVt0ZzRVxpXcWVuH5T3JWclwdpZTREquLj4sb5iN+sCKK7m7k2 cGlm/1egm26jWk2O5YlxZGR1PldnEeJ2DaYobbz8SbRQMJmEoGhnH4GyH4YdYFBz o3i3y2O44NUniV7jM63hQDCuYQ6CUROxe+2kce2tfsIJNc84CH4Q88bHAXGo5AYw cfVmzYSppyQshYYAWz0FMxN3n0x2itB0EsBpHT+niDdxWLQj28IH0Dhprlprmx3E ujAXi9nJnQexkWxUzMH1S5Q3gx+xYMI/WJF1dJ4BCV8heR85LUvJQQmmWP8inTiJ LHfbrAsV13R+mjywFo4UvoyY97GvoGGECKXjrz0LXplbvoV6vQFrQ8QQgNu5zFQs zgjkyYGJqwuHczan2aGMF/EnvfYTGxaH7ZeoLiuov+fSwbTITA59b+cgzoJ1u0HK T3NR11xcBJdtvHVWmsEe7/18VDd4c3uDW38EN6viyPbCO5b2Gpk= =j4DF -END PGP SIGNATURE-
Bug#1068502: Dead upstream and broken, remove or switch to a fork?
Hi, I have uploaded a patch that fixes the FTBFS bug with flake8 >= 7, so we have a bit of breathing room for now. The pytest-flake8 fork has been archived already; the author states [1]: I am no longer invested into the flake8 as a tool, as I have moved to using ruff. And I strongly recommend running QC tools as a separate step. Integrating flake8 into the unittest framework looks like a false economy to me nowdays. I tend to agree and think we should work towards removing this package. There are only five reverse dependencies anyway: $ build-rdeps python3-pytest-flake8 Reverse Build-depends in unstable/main: --- cvise pytest-pylint python-cssselect2 python-tinycss2 rpmlint Found a total of 5 reverse build-depend(s) for python3-pytest-flake8. Cheers Timo [1] https://github.com/VRGhost/pytest-flake8 -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Bug#1069551: numpy: FTBFS on armel: dh_auto_test: error: pybuild --test -i python{version} -p "3.12 3.11" returned exit code 13
Hi Lucas,
* Lucas Nussbaum [2024-04-20 15:21]:
Relevant part (hopefully):
self =
@pytest.mark.skipif(IS_WASM, reason="fp errors don't work in wasm")
@pytest.mark.skipif(arm_softfloat,
reason='platform/cpu issue with FPU (gh-413,-15562)')
def test_invalid(self):
This test is supposed to be skipped on armel, as arm_softfloat is
initialized with
hosttype = sysconfig.get_config_var('HOST_GNU_TYPE')
arm_softfloat = False if hosttype is None else hosttype.endswith('gnueabi')
Can you help me figure out why this did not work with your rebuild?
Judging from the configuration output,
libdir : lib/arm-linux-gnueabi
I would have expected that arm_softfloat is True. Maybe
sysconfig.get_config_var('HOST_GNU_TYPE') returns None?
Cheers
Timo
--
⢀⣴⠾⠻⢶⣦⠀ ╭╮
⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │
⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄ ╰╯
signature.asc
Description: PGP signature
Bug#1023237: openjdk-11: Keep out of testing and stable
Control: affects -1 + fastddsgen Hi, On Mon, 31 Oct 2022 21:55:24 +0100 Emmanuel Bourg wrote: openjdk-17 is now the default JDK, but openjdk-11 is still required for bootstrapping JVM-based languages like Kotlin or Scala in unstable. Therefore the package should no longer migrate to testing or stable anymore. FastDDSGen currently depends on OpenJDK 11 (or more precisely, any OpenJDK before 15) because it needs the Nashorn JavaScript engine, so could OpenJDK 11 be kept in trixie for the time being? Alternatively, someone could help me package the standalone version: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1038142 Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Bug#1064730: stdgpu: FTBFS: type_traits.h:736:1: error: expected type-specifier before ‘template’
* Gianfranco Costamagna [2024-04-16 09:06]: I agree with Cory, to me looks also a regression in thrust I'm trying some hacky patch, lets see Description: Reintroduce fallback lost in https://github.com/ROCm/rocThrust/commit/2b80e29803d60f01701a67bc57ef06dacfe8af8b Author: Gianfranco Costamagna Last-Update: 2024-04-16 --- rocthrust-5.7.1.orig/thrust/detail/type_traits.h +++ rocthrust-5.7.1/thrust/detail/type_traits.h @@ -731,6 +731,8 @@ using invoke_result_t = #else // 2017+ ::cuda::std::invoke_result_t; #endif +#else + std::invoke_result_t; #endif template Thanks for the patch and upstream PR. If that does not pan out, I could split stdgpu into two separate (source) packages to have the openmp backend built against libthrust-dev. I prefer your solution, though. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Bug#1052028: please update to pydantic 2.x
Hi Alexandre, * Alexandre Detiste [2024-04-14 16:12]: Now that pydantic-core is available, I started packaging v2.7. pydantic-core in Debian is not the latest release, because anything above 2.11.0 requires an additional Rust dependency (jiter), which in turns needs several other Rust dependencies packaged. According to the listed requirements, I would expect pydantic 2.4.2 to be compatible, so I suggest we start there and upgrade to the latest release as soon as pydantic-core gains its missing dependencies and can be upgraded, too. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Bug#1068868: ITP: python3-pyzmq -- Python bindings for 0MQ
* Cody Scott [2024-04-12 09:35]: * Package name: python3-pyzmq Version : 25.1.2 [...] There doesn't appear to be any other Python bindings for ZeroMQ. It seems like you missed https://tracker.debian.org/pkg/pyzmq but you are very welcome to contribute to the existing package! :) Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Bug#1068647: python-pot: autopkgtest regression on i386 with NumPy 1.26.4
Source: python-pot
Version: 0.9.3+dfsg-1
Severity: serious
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Dear maintainer,
your package has a autopkgtest regression on i386 with NumPy 1.26.4.
Hopefully relevant excerpt from test log at
https://ci.debian.net/data/autopkgtest/testing/i386/p/python-pot/45030103/log.gz
follows:
207s === FAILURES
===
207s ___ test_solve_sample_methods[numpy-{'method': 'gaussian'}]
207s
207s nx =
207s method_params = {'method': 'gaussian'}
207s
207s @pytest.mark.parametrize("method_params",
lst_method_params_solve_sample)
207s def test_solve_sample_methods(nx, method_params):
207s
207s n_samples_s = 20
207s n_samples_t = 7
207s n_features = 2
207s rng = np.random.RandomState(0)
207s
207s x = rng.randn(n_samples_s, n_features)
207s y = rng.randn(n_samples_t, n_features)
207s a = ot.utils.unif(n_samples_s)
207s b = ot.utils.unif(n_samples_t)
207s
207s xb, yb, ab, bb = nx.from_numpy(x, y, a, b)
207s
207s sol = ot.solve_sample(x, y, **method_params)
207s solb = ot.solve_sample(xb, yb, ab, bb, **method_params)
207s
207s # check some attributes (no need )
207s assert_allclose_sol(sol, solb)
207s
207s sol2 = ot.solve_sample(x, x, **method_params)
207s if method_params['method'] not in ['factored', 'lowrank']:
207s > np.testing.assert_allclose(sol2.value, 0)
207s
207s test/test_solvers.py:419:
207s _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _
207s
207s args = (.compare at 0xf0b37e88>,
array(8.8817842e-16), array(0))
207s kwds = {'equal_nan': True, 'err_msg': '', 'header': 'Not equal to
tolerance rtol=1e-07, atol=0', 'verbose': True}
207s
207s @wraps(func)
207s def inner(*args, **kwds):
207s with self._recreate_cm():
207s > return func(*args, **kwds)
207s E AssertionError:
207s E Not equal to tolerance rtol=1e-07, atol=0
207s E
207s E Mismatched elements: 1 / 1 (100%)
207s E Max absolute difference: 8.8817842e-16
207s E Max relative difference: inf
207s Ex: array(8.881784e-16)
207s Ey: array(0)
207s
207s /usr/lib/python3.12/contextlib.py:81: AssertionError
Cheers
Timo
-BEGIN PGP SIGNATURE-
iQIzBAEBCgAdFiEEmwPruYMA35fCsSO/zIxr3RQD9MoFAmYT6yAACgkQzIxr3RQD
9MoOQQ/+N1NSlnHlih5jhMBGkClnHTDpLmz8UBBdjnYoqEjQnz/SoBazuViOLd6Z
+eLeUJ8N26fsfe67eiNoVqD4ugEfMNItAq74BMQF2XF2vYVqPztLmxUwQpBrGVkD
oUOQTWos/iJCn8ITMLj+8cYl7EW99UYgh/4shhnbIhKvsKui0fnNqN+sri7gfiAX
om6UJddYkTsQmEGCTkqKgqGqZc70N9Se+mpGFngfhQXFEgQblWIn/HkahnBBp3fJ
dGTbjlT401snZ+81E/h2Ltdz3a0pQ05lN7KoJv03hy18UlToYZDcjDZMc4xIwQNG
SetjCn5+Lfm2NeXwrJ+iYNB+yc3Z4/P03VljuMJfo9pZAeNMnkyMJzQxSDLpeluV
3DeI7KQjAs/y5B/LDtvjPCUcDOoKesYcTDOyDAXRgs1Pu3WwUU5Yi7HmPgKJefmz
UXbnvsOdWgB1UQBX9rh5CKK0VHEb8ZhSZK3EuWjbiel467xml8ic2UYhr3iKadYt
a5H3nfjau1wxoGt2lkH6oOUC19A+iJXQYEZXCM9BWIZC12A6SGsBRrfcxS0jrTGs
Dg5ddnoEreJ7hAWyJHZPbbob/ITLsEKh62js7OH5zLhg2nzT/qXQCwKiDla1lhGY
jn9KxRMnV23CDMGjU2JPeImN9ha2ifVZ1zo/RRzXTu2bw3sHrVs=
=ypga
-END PGP SIGNATURE-
Bug#1068646: pyorbital: autopkgtest regression on i386 with NumPy 1.26.4
Source: pyorbital
Version: 1.8.2-1
Severity: serious
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Dear maintainer,
the pyorbital package has an autopkgtest regression on i386 only with
NumPy 1.26.4. Hopefully relevant excerpt from test log at
https://ci.debian.net/data/autopkgtest/testing/i386/p/pyorbital/45030100/log.gz
follows:
127s === FAILURES
===
127s _ TestGetObserverLook.test_basic_dask
__
127s
127s self =
127s
127s def test_basic_dask(self):
127s """Test with dask array inputs"""
127s from pyorbital import orbital
127s import dask.array as da
127s sat_lon = da.from_array(self.sat_lon, chunks=2)
127s sat_lat = da.from_array(self.sat_lat, chunks=2)
127s sat_alt = da.from_array(self.sat_alt, chunks=2)
127s lon = da.from_array(self.lon, chunks=2)
127s lat = da.from_array(self.lat, chunks=2)
127s alt = da.from_array(self.alt, chunks=2)
127s azi, elev = orbital.get_observer_look(sat_lon, sat_lat,
127s sat_alt, self.t,
127s lon, lat, alt)
127s > np.testing.assert_allclose(azi.compute(), self.exp_azi)
127s
127s /usr/lib/python3/dist-packages/pyorbital/tests/test_orbital.py:259:
127s _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _
127s
127s args = (.compare at 0xf0c0cf28>,
array([[331.00275902, 330.95954165, 180., 86.4354...00275902,
330.95954165, 180., 86.435411 ],
127s[330.91642994, 180., 0., 273.232073 ]]))
127s kwds = {'equal_nan': True, 'err_msg': '', 'header': 'Not equal to
tolerance rtol=1e-07, atol=0', 'verbose': True}
127s
127s @wraps(func)
127s def inner(*args, **kwds):
127s with self._recreate_cm():
127s > return func(*args, **kwds)
127s E AssertionError:
127s E Not equal to tolerance rtol=1e-07, atol=0
127s E
127s E Mismatched elements: 1 / 8 (12.5%)
127s E Max absolute difference: 14.03624347
127s E Max relative difference: 0.07797913
127s Ex: array([[331.002759, 330.959542, 180. , 86.435411],
127s E [330.91643 , 165.963757, 0. , 273.232073]])
127s Ey: array([[331.002759, 330.959542, 180. , 86.435411],
127s E [330.91643 , 180. , 0. , 273.232073]])
127s
127s /usr/lib/python3.11/contextlib.py:81: AssertionError
127s _ TestGetObserverLook.test_basic_numpy
_
127s
127s self =
127s
127s def test_basic_numpy(self):
127s """Test with numpy array inputs"""
127s from pyorbital import orbital
127s azi, elev = orbital.get_observer_look(self.sat_lon, self.sat_lat,
127s self.sat_alt, self.t,
127s self.lon, self.lat,
self.alt)
127s > np.testing.assert_allclose(azi, self.exp_azi)
127s
127s /usr/lib/python3/dist-packages/pyorbital/tests/test_orbital.py:243:
127s _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _
127s
127s args = (.compare at 0xf0abaf28>,
array([[331.00275902, 330.95954165, 180., 86.4354...00275902,
330.95954165, 180., 86.435411 ],
127s[330.91642994, 180., 0., 273.232073 ]]))
127s kwds = {'equal_nan': True, 'err_msg': '', 'header': 'Not equal to
tolerance rtol=1e-07, atol=0', 'verbose': True}
127s
127s @wraps(func)
127s def inner(*args, **kwds):
127s with self._recreate_cm():
127s > return func(*args, **kwds)
127s E AssertionError:
127s E Not equal to tolerance rtol=1e-07, atol=0
127s E
127s E Mismatched elements: 1 / 8 (12.5%)
127s E Max absolute difference: 14.03624347
127s E Max relative difference: 0.07797913
127s Ex: array([[331.002759, 330.959542, 180. , 86.435411],
127s E [330.91643 , 165.963757, 0. , 273.232073]])
127s Ey: array([[331.002759, 330.959542, 180. , 86.435411],
127s E [330.91643 , 180. , 0. , 273.232073]])
127s
127s /usr/lib/python3.11/contextlib.py:81: AssertionError
127s __ TestGetObserverLook.test_xarray_with_dask
___
127s
127s self =
127s
127s def test_xarray_with_dask(self):
127s """Test with xarray DataArray with dask array as inputs"""
127s from pyorbital import orbital
127s import dask.array as da
127s import xarray as xr
127s
127s def _xarr_conv(input):
127s
Bug#1063982: setuptools-scm: autopkgtest regression with pytest 8
* Andrey Rakhmatullin [2024-04-07 17:13]: This works in a current sid chroot, both build-time tests and autopkgests. Timo, do you think we can close this or does something else need to be checked? pytest 8.1 fixed a few regressions, so it is likely that either that or another fix in a dependent package has repaired the tests. Please go ahead and close the bug. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Bug#1067085: nanobind-dev not in python path and without distribution info
Hi, On Mon, 18 Mar 2024 08:16:33 + Francesco Ballarin wrote: 1) The user guide at https://nanobind.readthedocs.io/en/latest/building.html#finding-nanobind states that the downstream user should query python3 -m nanobind --cmake_dir to determine where nanobind is installed. The `python3 -m nanobind --cmake_dir` call is only needed for the pip/conda package because it installs the CMake config in a location that is not searched by default. It is not necessary for the Debian package -- find_package(nanobind) works out of the box -- but does not hurt (much) either. 2) Downstream users or packages may have a pyproject.toml file which contains [build-system] requires = ["nanobind"] I added a new binary package python3-nanobind, which provides the nanobind module for this use case. Technically, it is not needed for the reason outlined above, but if it makes life easier for downstream users, that's good enough for me. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Bug#1063965: pytest-services: autopkgtest regression with pytest 8
Control: reassign -1 python3-pytest 8.0.1-1 Control: close -1 8.1.1-1 It looks like this issue was caused by a regression in pytest 8.0 and is fixed now. On Thu, 15 Feb 2024 11:36:07 +0100 roehl...@debian.org wrote: Package: pytest-services Version: 2.2.1+ds-3 Severity: important User: debian-pyt...@lists.debian.org Usertags: pytest-8 Dear maintainer, your package has a autopkgtest regression with pytest 8. Typically, packages will start failing if they - have deprecation warnings of type PytestRemovedIn8Warning, or - assume a particular pytest stdout/stderr output which might have changed, or - rely on implementation details of the pytest test collector, in particular the pytest.Package class, which has been redesigned for pytest 8. Please refer to the upstream changelog [1] for a complete list of breaking changes and the pytest (pseudo-)excuses [2] related to your package for details of the regression. It is possible that the autopkgtest regression is not directly caused by pytest-services, but by one of its dependencies. In that case, feel free to reassign the bug and mark your package as affected, but do not close the bug until the autopkgtest passes. Cheers Timo [1] https://docs.pytest.org/en/8.0.x/changelog.html#pytest-8-0-0rc1-2023- 12-30 [2] https://qa.debian.org/excuses.php?experimental=1=pytest -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Bug#1063964: fixed in pytest-arraydiff 0.6.1-2
Control: reopen -1 On Thu, 29 Feb 2024 23:40:47 + Debian FTP Masters - New Use-valid-test-module-names.patch (Closes: #1063964) Unfortunately, this did not work. -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Bug#1063960: python-b2sdk: autopkgtest regression with pytest 8
Control: reassign -1 python3-pytest 8.0.1-1 Control: close -1 8.1.1-1 As it turns out, there was a regression in pytest 8.0 which has been fixed in pytest 8.1 Cheers Timo On Thu, 15 Feb 2024 11:36:15 +0100 roehl...@debian.org wrote: Package: python-b2sdk Version: 1.17.3-2 Severity: important User: debian-pyt...@lists.debian.org Usertags: pytest-8 Dear maintainer, your package has a autopkgtest regression with pytest 8. Typically, packages will start failing if they - have deprecation warnings of type PytestRemovedIn8Warning, or - assume a particular pytest stdout/stderr output which might have changed, or - rely on implementation details of the pytest test collector, in particular the pytest.Package class, which has been redesigned for pytest 8. Please refer to the upstream changelog [1] for a complete list of breaking changes and the pytest (pseudo-)excuses [2] related to your package for details of the regression. It is possible that the autopkgtest regression is not directly caused by python-b2sdk, but by one of its dependencies. In that case, feel free to reassign the bug and mark your package as affected, but do not close the bug until the autopkgtest passes. Cheers Timo [1] https://docs.pytest.org/en/8.0.x/changelog.html#pytest-8-0-0rc1-2023- 12-30 [2] https://qa.debian.org/excuses.php?experimental=1=pytest -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Bug#1063951: fixed in barectf 3.1.2-2
Control: reopen -1 Control: notfixed -1 3.1.2-2 On Fri, 15 Mar 2024 21:44:05 + Debian FTP Masters wrote: * [2375fb4] Disable pytest8 deprecation warnings (Closes: #1063951) - Also (Closes: #1066742) built with pytest8 Unfortunately, this was not a permanent solution, because the features which PytestRemovedIn8Warning has been warning about, have been actually removed now (pytest 8.1). Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Bug#946189: python-numpy: blas -> blis
Control: tags -1 + moreinfo Hi, On Thu, 05 Dec 2019 01:50:06 +0100 =?utf-8?q?Nico_Schl=C3=B6mer?= wrote: The first one available on Debian is BLIS, so perhaps it's time to think about replacing the BLAS dependency with BLIS. While it is certainly possible to change the BLAS/LAPACK implementation which is used during package build, I'm not sure how useful that is, given that python3-numpy already has a dependency Depends: ..., libblas3 | libblas.so.3, ..., liblapack3 | liblapack.so.3, ... which is satisfiable by any BLAS/LAPACK implementation available in Debian. For example, I have libopenblas0-openmp installed, which has Provides: libblas.so.3, liblapack.so.3 Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Bug#1067398: python3-numpy: Missing /usr/include/python3.11/numpy link breaks builds
Hi Dima, * Dima Kogan [2024-03-21 07:23]: My feeling is that being confused by that symlink is a bug, but I didn't read #998084 in great detail, so maybe I'm missing some nuance. So let's make this work. My understanding is that /usr/include/pythonX.Y as Python header directory will be made available from inside a venv if you use the system interpreter (which venv does by default). Now, the system NumPy headers will leak into the venv, regardless of the NumPy package that is actually installed there, causing conflicts. Proposal: if pkg-config files will be added in the near future, can we wait until those are available before removing the symlink? Or, can you backport them into the current package? Backporting sounds like a reasonable approach. If that does not work as expected, I'll restore the symlink. But if something was confused by the symlink, would it also be confused by the .pc file? Very good question. I suspect the answer is yes, but there is a pull request that would make it work as expected [1]. [1] https://github.com/pypa/virtualenv/issues/2637 Currently the Makefile launches Python and imports sysconfig, which is relatively fast. As we can see, importing numpy also, is MUCH slower. All I want is the include path; I shouldn't need to initialize all of numpy to do that. I understand and I would not want to do that either. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Bug#1067398: python3-numpy: Missing /usr/include/python3.11/numpy link breaks builds
Hi Dima, * Dima Kogan [2024-03-20 18:23]: Can we get that symlink back, please? I removed that symlink in the latest release, because it is not created by upstream but a Debian specific patch, and according to #998084 [1], it can badly interfere with venv setups. I would very much prefer if other Debian packages used the canonical way of discovering NumPy include directories, i.e., numpy.get_include(). Starting with NumPy 2.0, there will be a pkgconf file available, too. That being said, I can temporarily reinstate the symlinks if you cannot fix the issue on your side in a timely manner, but I'd like them gone for the trixie release. How do you wish to proceed? Cheers Timo [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=998084 -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Bug#1067234: symfit: autopkgtest regression with NumPy 1.26
Source: symfit
Version: 0.5.6-2
Severity: serious
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Dear maintainer,
your package has an autopkgtest regression with NumPy 1.26.
Hopefully relevant excerpt from the test log:
130s # Should no longer raise warnings, because internally we practice
130s # what we preach.
130s fit_custom = BFGS(chi_squared, [a, b])
130s > assert len(recwarn) == 0
130s E assert 1 == 0
130s E+ where 1 = len(WarningsRecorder(record=True))
130s
130s tests/test_minimizers.py:120: AssertionError
130s === warnings summary
===
130s symfit/core/operators.py:48
130s
/tmp/autopkgtest-lxc.jjpx74xp/downtmp/build.gp1/src/symfit/core/operators.py:48:
SyntaxWarning: invalid escape sequence '\*'
130s """
130s
130s symfit/core/support.py:296
130s
/tmp/autopkgtest-lxc.jjpx74xp/downtmp/build.gp1/src/symfit/core/support.py:296:
SyntaxWarning: invalid escape sequence '\*'
130s """
130s
130s symfit/core/printing.py:13
130s
/tmp/autopkgtest-lxc.jjpx74xp/downtmp/build.gp1/src/symfit/core/printing.py:13:
DeprecationWarning: pkg_resources is deprecated as an API. See
https://setuptools.pypa.io/en/latest/pkg_resources.html
130s import pkg_resources
130s
130s
../../../../../usr/lib/python3/dist-packages/pkg_resources/__init__.py:2871
130s /usr/lib/python3/dist-packages/pkg_resources/__init__.py:2871:
DeprecationWarning: Deprecated call to
`pkg_resources.declare_namespace('mpl_toolkits')`.
130s Implementing implicit namespace packages (as specified in PEP 420) is
preferred to `pkg_resources.declare_namespace`. See
https://setuptools.pypa.io/en/latest/references/keywords.html#keyword-namespace-packages
130s declare_namespace(pkg)
130s
130s symfit/core/fit.py:32
130s
/tmp/autopkgtest-lxc.jjpx74xp/downtmp/build.gp1/src/symfit/core/fit.py:32:
SyntaxWarning: invalid escape sequence '\_'
130s """
130s
130s symfit/core/minimizers.py:211
130s
/tmp/autopkgtest-lxc.jjpx74xp/downtmp/build.gp1/src/symfit/core/minimizers.py:211:
SyntaxWarning: invalid escape sequence '\*'
130s '''
130s
130s symfit/core/minimizers.py:327
130s
/tmp/autopkgtest-lxc.jjpx74xp/downtmp/build.gp1/src/symfit/core/minimizers.py:327:
SyntaxWarning: invalid escape sequence '\*'
130s """
130s
130s symfit/core/minimizers.py:793
130s
/tmp/autopkgtest-lxc.jjpx74xp/downtmp/build.gp1/src/symfit/core/minimizers.py:793:
SyntaxWarning: invalid escape sequence '\*'
130s """
130s
130s symfit/core/fit_results.py:29
130s
/tmp/autopkgtest-lxc.jjpx74xp/downtmp/build.gp1/src/symfit/core/fit_results.py:29:
SyntaxWarning: invalid escape sequence '\*'
130s """
130s
130s symfit/core/objectives.py:389
130s
/tmp/autopkgtest-lxc.jjpx74xp/downtmp/build.gp1/src/symfit/core/objectives.py:389:
SyntaxWarning: invalid escape sequence '\c'
130s """
130s
130s ../../../../../usr/lib/python3/dist-packages/dateutil/tz/tz.py:37
130s /usr/lib/python3/dist-packages/dateutil/tz/tz.py:37:
DeprecationWarning: datetime.datetime.utcfromtimestamp() is deprecated and
scheduled for removal in a future version. Use timezone-aware objects to
represent datetimes in UTC: datetime.datetime.fromtimestamp(timestamp,
datetime.UTC).
130s EPOCH = datetime.datetime.utcfromtimestamp(0)
130s
130s tests/test_auto_fit.py: 3 warnings
130s tests/test_constrained.py: 14 warnings
130s tests/test_finite_difference.py: 1 warning
130s tests/test_fit_result.py: 5 warnings
130s tests/test_general.py: 16 warnings
130s tests/test_minimizers.py: 2 warnings
130s tests/test_objectives.py: 1 warning
130s tests/test_ode.py: 1 warning
130s
/tmp/autopkgtest-lxc.jjpx74xp/downtmp/build.gp1/src/symfit/core/fit.py:278:
DeprecationWarning: `product` is deprecated as of NumPy 1.25.0, and will be
removed in NumPy 2.0. Please use `prod` instead.
130s cov_matrix = self._covariance_matrix(best_fit_params,
130s
130s tests/test_auto_fit.py: 2 warnings
130s tests/test_constrained.py: 13 warnings
130s tests/test_finite_difference.py: 2 warnings
130s tests/test_fit_result.py: 1 warning
130s tests/test_general.py: 12 warnings
130s tests/test_global_opt.py: 3 warnings
130s tests/test_ode.py: 7 warnings
130s
/tmp/autopkgtest-lxc.jjpx74xp/downtmp/build.gp1/src/symfit/core/fit.py:301:
DeprecationWarning: `product` is deprecated as of NumPy 1.25.0, and will be
removed in NumPy 2.0. Please use `prod` instead.
130s cov_matrix = self._covariance_matrix(best_fit_params,
130s
130s tests/test_general.py::test_likelihood_fitting_exponential
130s /usr/lib/python3/dist-packages/_pytest/python.py:194:
DeprecationWarning: `product` is deprecated as of NumPy 1.25.0, and will be
removed in NumPy 2.0. Please use `prod` instead.
130s result = testfunction(**testargs)
130s
130s --
Bug#1067233: python-pomegranate: autopkgtest regression with NumPy 1.26
Source: python-pomegranate Version: 0.14.8-4 Severity: serious -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dear maintainer, your package has an autopkgtest regression with NumPy 1.26. Hopefully relevent excerpt from the test log: 52s > ??? 52s E ValueError: The truth value of an array with more than one element is ambiguous. Use a.any() or a.all() 52s 52s pomegranate/kmeans.pyx:232: ValueError 52s === warnings summary === 52s ../../../../usr/lib/python3/dist-packages/dateutil/tz/tz.py:37 52s /usr/lib/python3/dist-packages/dateutil/tz/tz.py:37: DeprecationWarning: datetime.datetime.utcfromtimestamp() is deprecated and scheduled for removal in a future version. Use timezone-aware objects to represent datetimes in UTC: datetime.datetime.fromtimestamp(timestamp, datetime.UTC). 52s EPOCH = datetime.datetime.utcfromtimestamp(0) 52s 52s tests/test_custom_distributions.py: 29600 warnings 52s tests/test_hmm.py: 375 warnings 52s /usr/lib/python3/dist-packages/joblib/parallel.py:1792: DeprecationWarning: Conversion of an array with ndim > 0 to a scalar is deprecated, and will error in future. Ensure you extract a single element from your array before performing this operation. (Deprecated NumPy 1.25.) 52s res = func(*args, **kwargs) 52s 52s tests/test_custom_distributions.py: 40 warnings 52s /tmp/autopkgtest-lxc.qczb1z7m/downtmp/autopkgtest_tmp/tests/test_custom_distributions.py:223: DeprecationWarning: Conversion of an array with ndim > 0 to a scalar is deprecated, and will error in future. Ensure you extract a single element from your array before performing this operation. (Deprecated NumPy 1.25.) 52s assert_array_almost_equal(model1.log_probability(X), model2.log_probability(X)) 52s 52s tests/test_custom_distributions.py: 400 warnings 52s /tmp/autopkgtest-lxc.qczb1z7m/downtmp/autopkgtest_tmp/tests/test_custom_distributions.py:232: DeprecationWarning: Conversion of an array with ndim > 0 to a scalar is deprecated, and will error in future. Ensure you extract a single element from your array before performing this operation. (Deprecated NumPy 1.25.) 52s assert_array_almost_equal(model1.log_probability(X), model2.log_probability(X)) 52s 52s tests/test_custom_distributions.py: 200 warnings 52s /tmp/autopkgtest-lxc.qczb1z7m/downtmp/autopkgtest_tmp/tests/test_custom_distributions.py:345: DeprecationWarning: Conversion of an array with ndim > 0 to a scalar is deprecated, and will error in future. Ensure you extract a single element from your array before performing this operation. (Deprecated NumPy 1.25.) 52s assert_array_almost_equal(model1.log_probability(X), model2.log_probability(X)) 52s 52s tests/test_custom_distributions.py: 200 warnings 52s /tmp/autopkgtest-lxc.qczb1z7m/downtmp/autopkgtest_tmp/tests/test_custom_distributions.py:359: DeprecationWarning: Conversion of an array with ndim > 0 to a scalar is deprecated, and will error in future. Ensure you extract a single element from your array before performing this operation. (Deprecated NumPy 1.25.) 52s assert_array_almost_equal(model1.predict(X), model2.predict(X)) 52s 52s tests/test_custom_distributions.py: 200 warnings 52s /tmp/autopkgtest-lxc.qczb1z7m/downtmp/autopkgtest_tmp/tests/test_custom_distributions.py:373: DeprecationWarning: Conversion of an array with ndim > 0 to a scalar is deprecated, and will error in future. Ensure you extract a single element from your array before performing this operation. (Deprecated NumPy 1.25.) 52s assert_array_almost_equal(model1.predict_proba(X), model2.predict_proba(X)) 52s 52s tests/test_custom_distributions.py: 200 warnings 52s /tmp/autopkgtest-lxc.qczb1z7m/downtmp/autopkgtest_tmp/tests/test_custom_distributions.py:387: DeprecationWarning: Conversion of an array with ndim > 0 to a scalar is deprecated, and will error in future. Ensure you extract a single element from your array before performing this operation. (Deprecated NumPy 1.25.) 52s assert_array_almost_equal(model1.predict_log_proba(X), model2.predict_log_proba(X)) 52s 52s tests/test_custom_distributions.py: 200 warnings 52s /tmp/autopkgtest-lxc.qczb1z7m/downtmp/autopkgtest_tmp/tests/test_custom_distributions.py:402: DeprecationWarning: Conversion of an array with ndim > 0 to a scalar is deprecated, and will error in future. Ensure you extract a single element from your array before performing this operation. (Deprecated NumPy 1.25.) 52s assert_array_almost_equal(model1.log_probability(X), model2.log_probability(X)) 52s 52s tests/test_custom_distributions.py: 2000 warnings 52s /tmp/autopkgtest-lxc.qczb1z7m/downtmp/autopkgtest_tmp/tests/test_custom_distributions.py:411: DeprecationWarning: Conversion of an array with ndim > 0 to a scalar is deprecated, and will error in future. Ensure you extract a single element from your array before performing
Bug#1067231: pysatellites: autopkgtest regression with NumPy 1.26
Source: pysatellites Version: 2.7-1 Severity: serious -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dear maintainer, your package has an autopkgtest regression with NumPy 1.26. Hopefully relevant excerpt from the test log: 81s debian/tests/test_gui.py Traceback (most recent call last): 81s File "/usr/lib/python3/dist-packages/matplotlib/backends/backend_qt.py", line 454, in _draw_idle 81s self.draw() 81s File "/usr/lib/python3/dist-packages/matplotlib/backends/backend_agg.py", line 408, in draw 81s super().draw() 81s File "/usr/lib/python3/dist-packages/matplotlib/backends/backend_qt.py", line 423, in draw 81s self.update() 81s RuntimeError: wrapped C/C++ object of type MyMplCanvas has been deleted Cheers Timo -BEGIN PGP SIGNATURE- iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmX7CJ8ACgkQ+C8H+466 LVmqAgv/VL0O1TheFz7AWlNyEmGiPHC/UxK5fmxdBE6If7RFjmaMVqt66uti0tN2 JNM74Ak+bcX2oqRBoEAr9ffQCZgc5IDuRghsAcnbycixuyF6Bc573nL6BK33e4Eu kerZ+C5j6xgm7rW+75pxaiFRrqrQ8jomI98Gp133/7nKsB+FpcV3UodDVwpG0YY+ aQ0UKwm0hf2VMx9gHO7dX3m49zDjX9gWqjOJHWnR6s5HhUflc+3vwem1cOpLZYXs paJzzujOmzTNpQFx75YgxaTYVcZSWNAuEb2KFFuGIA502ZlwWBmO5091wEsTAyJo tQIb1AAqisViTW2xfr4CMn2ydBJpZYtS5o/MHNzzeSXRbJyIQJVk+/D6rtyjT6yh zODVc8NqPjE6kEa/U79XWh9qaE7zfRd9et58OBcqYabeukMDhpFX8Wsk1PYWESky Kp6XKpLdRGQmPb11w2mt3nr2q9z7TRXIsevuYHe1Iesc+yhKdcMAortqC9kAgeg5 i57qmSvf =/mP2 -END PGP SIGNATURE-
Bug#1067229: metpy: autopkgtest regression with NumPy 1.26
Source: metpy Version: 1.6.1+ds-1 Severity: serious -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dear maintainer, your package has an autopkgtest regression with NumPy 1.26. Hopefully relevant excerpt from the test log: 142s > if np.any(np.max(pressure, axis=vertical_dim) < 950 * units.hectopascal): 142s E TypeError: no implementation found for 'numpy.max' on types that implement __array_function__: [.Quantity'>] 142s 142s /usr/lib/python3/dist-packages/metpy/calc/thermo.py:4589: TypeError 142s === short test summary info 142s FAILED tests/calc/test_calc_tools.py::test_get_layer_heights_agl - TypeError:... 142s FAILED tests/calc/test_calc_tools.py::test_get_layer_heights_agl_bottom_no_interp 142s FAILED tests/calc/test_calc_tools.py::test_angle_to_direction - TypeError: no... 142s FAILED tests/calc/test_calc_tools.py::test_angle_to_direction_edge - TypeErro... 142s FAILED tests/calc/test_calc_tools.py::test_angle_to_direction_list - TypeErro... 142s FAILED tests/calc/test_calc_tools.py::test_angle_to_direction_arr - TypeError... 142s FAILED tests/calc/test_calc_tools.py::test_angle_to_direction_full - TypeErro... 142s FAILED tests/calc/test_calc_tools.py::test_angle_to_direction_invalid_scalar 142s FAILED tests/calc/test_calc_tools.py::test_angle_to_direction_invalid_arr - T... 142s FAILED tests/calc/test_calc_tools.py::test_angle_to_direction_level_3 - TypeE... 142s FAILED tests/calc/test_calc_tools.py::test_angle_to_direction_level_2 - TypeE... 142s FAILED tests/calc/test_calc_tools.py::test_angle_to_direction_level_1 - TypeE... 142s FAILED tests/calc/test_kinematics.py::test_storm_relative_helicity_no_storm_motion 142s FAILED tests/calc/test_kinematics.py::test_storm_relative_helicity_storm_motion 142s FAILED tests/calc/test_kinematics.py::test_storm_relative_helicity_with_interpolation 142s FAILED tests/calc/test_kinematics.py::test_storm_relative_helicity - TypeErro... 142s FAILED tests/calc/test_kinematics.py::test_storm_relative_helicity_agl - Type... 142s FAILED tests/calc/test_kinematics.py::test_storm_relative_helicity_masked - T... 142s FAILED tests/calc/test_thermo.py::test_lfc_ml2 - TypeError: no implementation... 142s FAILED tests/calc/test_thermo.py::test_lfc_and_el_below_lcl - TypeError: no i... 142s FAILED tests/calc/test_thermo.py::test_gdi - TypeError: no implementation fou... 142s FAILED tests/calc/test_thermo.py::test_gdi_xarray - TypeError: no implementat... 142s FAILED tests/calc/test_thermo.py::test_gdi_arrays - TypeError: no implementat... 142s FAILED tests/calc/test_thermo.py::test_gdi_profile - TypeError: no implementa... 142s FAILED tests/calc/test_thermo.py::test_gdi_no_950_raises_valueerror - TypeErr... 142s = 25 failed, 937 passed, 25 skipped, 268 deselected in 21.69s == Cheers Timo -BEGIN PGP SIGNATURE- iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmX7B5EACgkQ+C8H+466 LVmokQv+OIpBqsgrDGYODgkQxUW/D+rWrkJtJehe8HjFXsCVtOViQjC4WaSGcvR3 vnLkRoeEPbNTCUmjMzOsoRtDqx2mQ4BPKGZboBc/64G6JPtgrB1WRAVrxDXeeHVT HMFmIWnoKV3FmNxvMSujPPK3t0HoawppkGlnK/66GOHWmj4SBfkSud9YuHQEfqDa 2H6uXeBA5TcxDEz+5qy32zNwtdGAksX3HnMcpnPBnCpi8l/ouPVXoaqDY4y/tB9w e6iGFTJ9pYvJrI9n8eKOZCg6odI/z1Yhl3pPT7dg//zwzOCM8dtNBHM/tQWV1wUd DUBp2H05RqgF+tJsjJ+HnLYzRCFjK0trQRAcG48UlrJJoG8FDrVzyGjQ4UNj2D6J 3J+0UkTEi7lqLasBFLZl0XsQX/Hom/XWNq4LBM6oObCWWoa5b0i7T5sCtrWKASVl /oT6t77ms6O/eyLb68BT73tMxIzWecWYA42y8vocSXrQnbF32OGqYHr3AvhQeui9 ImdiPbEZ =qYXE -END PGP SIGNATURE-
Bug#1067144: [3dprinter-general] Bug#1067144: uranium: missing depend on python3-all for autopkgtest
Hi Gregor, * Gregor Riepl [2024-03-19 23:22]: Shouldn't autopkgtest figure out by itself that this package is needed to run tests against all python versions? (and if this is about Build-Depends - src:uranium has depended on python3-all since it existed) This is not about Build-Depends, nor about the binary package Depends. uranium has an explicit debian/tests/control file with "Depends: @", which only installs the built package(s) and their dependencies. Up until now, these dependencies included all supported Python interpreters, because python3-numpy depended on them explicitly. As this is no longer the case, you must either - add python3-all to the Depends line in debian/tests/control, or - stop using `pyversions -r` in the Test-Command Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Bug#1067145: websockify: missing depend on python3-all for autopkgtest
Source: websockify Version: 0.10.0+dfsg1-5 Severity: serious -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dear maintainer, your package has an autopkgtest regression due to changes in NumPy. The python3-numpy package no longer depends on all supported Python versions. You need to depend on python3-all if you want to run your tests against all supported Python releases. Cheers Timo -BEGIN PGP SIGNATURE- iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmX5ZWMACgkQ+C8H+466 LVklSQwAy7kT48/933q/dYkim+duv/km7n1KV7tLw3GF5O8ctdOxu2X3KRJA63cI T1TSrwjRstiWnLKaeRbKNPlC32f38OxCxMKejwnadBEpGYEcictC9T+x9GNtGL77 2tqtpNBksMSCcbF6nJHWTX0CnCqH8aIlbAQg56JiMuDhT3JpmJd4xgLYp0SHpZeF LbD4KHLGfuyMjF76V07KTjOK7cpOW2tgVMwDLik+24doO85K/js4RsS0oN2gaI4T ViHvDM+YTlB3sfPcfjpaZF+zSQB04Q2ntfFJcB+AijxVBnlDAZw/Ue8ONwSPVrXl y8No1OtRGX0p2f3EmOAgrQjiql5fqN3g9t6isO+hdt1dsuYr6OupeZ2V9+8mVaOG x6y2l7RgOjbCdpWTDeLBAsilSdU5adzdBWDTpGY7sjsSNSskDItSc103XAqmENGy zDSDGHkpSQ7H76Nmdy9PQ0FOpndYKehXujUxjF67IEiSHa5aELeLgL8b3VICoh2V k4N0zbUx =J7Oc -END PGP SIGNATURE-
Bug#1067144: uranium: missing depend on python3-all for autopkgtest
Source: uranium Version: 5.0.0-3 Severity: serious -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dear maintainer, your package has an autopkgtest regression due to changes in NumPy. The python3-numpy package no longer depends on all supported Python versions. You need to depend on python3-all if you want to run your tests against all supported Python releases. Cheers Timo -BEGIN PGP SIGNATURE- iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmX5ZSgACgkQ+C8H+466 LVkccAwAtHJn3Uao7rafpTM11dP6LIPEfuSbhYzvVJI3/vJAqCnTP6IkbtHzSqaz qcDpQib0v0pMzjzJx0Yotef1DIel8yOo1wM1elHT/bs2fqCmQCh3vs+zexWy4+Xl sNqzvMXz1YUyRbmD9ePYW3l927Mfz5BXXSratVzld2qiIYyJXJlf3dHGg4jce96v NrAzYvPbxDrDgUMD9DZd5iAIkyTBHsYQKO9nOkadxDEDA3hT19t7JIc6H8RrnBKE SEdKWyBfaIxz+KnDgDeRunF+trjDoIFMk6NakNkU1jROtCsPQK1q1bEi8rWoARko HJYdTFfyf8Ch485c9xt8PuWWI15j1k5P/egqu98WNDBycRf6/aOiZVfrPJPJ7bqx VPrmumy4oax2ognulQEhfj9XINEvwd1W5rGMCcUp6198HAepdxHER1oAOUcvSeFn TIOJQW6dob4cqvIqq6QIO0HIoFXnEZ7wGreUdCg20eqee8Qz1pS1SgFtGe/wl39c vtTy8M+I =+zQr -END PGP SIGNATURE-
Bug#1067142: python-av: missing depend on python3-all for autopkgtest
Source: python-av Version: 11.0.0-3 Severity: serious -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dear maintainer, your package has an autopkgtest regression due to changes in NumPy. The python3-numpy package no longer depends on all supported Python versions. You need to depend on python3-all if you want to run your tests against all supported Python releases. Cheers Timo -BEGIN PGP SIGNATURE- iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmX5ZJkACgkQ+C8H+466 LVlbzgwAsNQR0D8jal0Wq22h2IiJ/2wCN1ZfvkOic8bS+6n5dXkWt7uynYqaDFxl PI1AeZg/aKujIO+cMWp+rft4RLNEOhGze98Y5kP01L5yYj6K/pscZpLfYloVJVcU a/ByHVVgXKAoBD/JsDDeV4Xi/zPFs8IyXWTeOkO5c1l4PBycHlZ+rnlObp0lb/Rr 1UqJKprMqJSO1FStx3S6p9kO/MTz2O+UDweC+zsnEerEXUbqXr7Qgafeco0XiHs1 +BvTgGvzpHIUa+1tWFOyQqeYNpUpEtNkOCd787D56vvA/rZQ9pnWsKrexvCpzkMh kgrx2N1Mv6sY5y2Fplis5rigdi36PqD/pF8ATD7C6CHFV2sk4dxt4DTQpAY72a3m ac1dj0N7EoTip/ky0ecOGUCGjFT5zYfanEnhZYk4BUO6GThx1a4H/S1ewZMTLiuC 6qghvXv4yi3zqkUATpD8vhlHp+Gm12pwWdQ48aDLDtFFSh7okK/aYyLJRr66NnAT 3kl6+x+n =Ui1t -END PGP SIGNATURE-
Bug#1067143: python-multipletau: missing depend on python3-all for autopkgtest
Source: python-multipletau Version: 0.3.3+ds-5 Severity: serious -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dear maintainer, your package has an autopkgtest regression due to changes in NumPy. The python3-numpy package no longer depends on all supported Python versions. You need to depend on python3-all if you want to run your tests against all supported Python releases. Cheers Timo -BEGIN PGP SIGNATURE- iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmX5ZNAACgkQ+C8H+466 LVlVtwv+K7dLyDdDt8NFi4g9q8xYzLjzTK5Pwf0zYiK60rc+QZCr2LIhX3jj046U hs+YQkzq11FLzXMW+MGOpHANABzFrAIdLT1c0D5BO2m07gnP12YaaIsGwzlSW/tv /zi/DtrzvIa1oIuxAf5tqj7F5nlFzGwV/jQecKqQdVlLF6NWRDAsxgf+RurH85nf IuPSC5B4kM7iYeo0OlUJaTUiTGWzmLXZ/2pYwdxsWlFB5n0CnUe2A3gebLriXgFQ Af9NF8Ex+6WDY2mayYcJYzq4A+BkeJS/aUKUBt/fao6jY2aaxjvlnxS9+SuET+D4 TRmwOxRthCc8xg17+U1hVLtG154rwUQTalHGlj/ZGsdviNn5mRkmOix2HFMO5pI2 DBL00KBO3++hzZqCjzWsxnugm5q4LE4owwxSCJLFtYGg5I8BEkSAMRBPAmaAb63q ejBUPLvkQdzaK44RZJwwCjhbzbPdsX5+jI8pYKUNehEJfD4zEFroIcZnl+72RAdY W74q7XcD =xxHR -END PGP SIGNATURE-
Bug#1067140: pygrib: missing depend on python3-all for autopkgtest
Source: pygrib Version: 2.1.5-3 Severity: serious -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dear maintainer, your package has an autopkgtest regression due to changes in NumPy. The python3-numpy package no longer depends on all supported Python versions. You need to depend on python3-all if you want to run your tests against all supported Python releases. Cheers Timo -BEGIN PGP SIGNATURE- iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmX5ZFcACgkQ+C8H+466 LVlwqgv8CsBwWmyZ97CzjMvEDJhBKS4IQ1dsIwK+2DZZoFIDNlkH2tzBGPm34oZ1 To9msBKhHtB7vM2v1Y63cFQsqe4PMOfm6UONlbQaemykrRJ0rg5peDFnKZTHPsjG eThBBsJHzzCqb4Zbn0yed1E3awrTlhkF41Jrkov3+nodkp+yoGldxTrn/njswTzk NTtNbXOOEUHYlY2pU5BrluD24TBHJ3kb3ZKghmPHytKWblFcq4aSvHK6NWcf1ydV jnFK6K8ILs3F1AIwfW0wk3UNQDYaOpKnFpJ9IafeXquyZue9tAkFuOZYN3c20/AC gFWUVMlp7jHwnOPiBxb4VdEyRf42PLJ6qvUkHBIJzxSy2cIPU2niVja/VYuVybtE yAnJTjtEq2QzvlloTa4CTuHLfSjy6ym8EX3CZf56RbaW/kS0lU8kSjrEoSGJX3U3 6nmw58htPUokVupiyBZTqljU7BT4Tv06aF9YJWS12mNbIO6fRnmIlg7gHLKBw3OX PWtgaFIa =de/9 -END PGP SIGNATURE-
Bug#1067139: matplotlib: missing depend on python3-all for autopkgtest
Source: matplotlib Version: 3.6.3-1 Severity: serious -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dear maintainer, your package has an autopkgtest regression due to changes in NumPy. The python3-numpy package no longer depends on all supported Python versions. You need to depend on python3-all if you want to run your tests against all supported Python releases. Cheers Timo -BEGIN PGP SIGNATURE- iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmX5ZB4ACgkQ+C8H+466 LVlCRgv/dZZtG62N0OQPyMHnR7lIi8RhSqcGrYswTt1KXEsG203iutNYsWKTsE28 VZPllUoH22bdXZIGVWDs+HcjlY++TIuGBPw3zT95A7hSRzRrXMC9QhHKy1QWTLk9 gHddmCoFPQho4zBhxcdaCfpi2O3d0+lmTrYOtAya6LvlEd2lZzyGxRH3JMD94tzW uyVI+YqTFQHoAfSiCQPVlVZHlSTYN5Xm8krEP/QfzuMt7T05lmW6doRAW0UY6Sk7 x8ss/bHcRPzkYU4JJc9+p5xqbnSEp6f3l/KPawc7ieorGuDy61L/I9Cq9Pz5SOCG jYqqiBk0KaO3dfIAMbV71m89VLxZePCqmlKbsYmbaGk9Gy5Swss0QJPfaUx+QRix 6CjPJJGt22WtMbJfzfrNUqENpJmHNdeJ6H/s8iucbhJXCTnIUHjsFrZpgnwYRVZB NP3FG597GI7+DrwXXQGJelqpKRVtqn1THRuBQxQ45zpfg3amESJRJyUsXl+GYHfa +cJn+pfP =Bf9+ -END PGP SIGNATURE-
Bug#1067137: harmonypy: missing depend on python3-all for autopkgtest
Source: harmonypy Version: 0.0.9-2 Severity: serious -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dear maintainer, your package has an autopkgtest regression due to changes in NumPy. The python3-numpy package no longer depends on all supported Python versions. You need to depend on python3-all if you want to run your tests against all supported Python releases. Cheers Timo -BEGIN PGP SIGNATURE- iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmX5Ya8ACgkQ+C8H+466 LVnbFgwAgMo8/cuq3/uIEV1LUQXPgfGWveb3mRN1bViYSEc7xIiRR0Sv3AhV4L5g 4CuLL6aRE6X46l83Q+56DgCAgNQ8O53O0a0kzpYfnXMNiNeU9XBP8+CH6yqyyq4V rCvFyVxjVPuDFE+Lq1JQq+INNtYzHoPGRWbh0Fxz7ax1XsihNBp4QjxrHSLUsELK PaLJZTrUr4G0LFKaDWXKb7Vo8j9em+di6S7Jbh67YMmoeDKSx4+Ly9m6kkx+wDUM qoLWd1c0Jj2ArHB1sGx4abqNE36T0knbJRIFFi8izyZoNGYOmYG1H3jPKpVo7jxA EFA2sl2dW/GH9LvOearHynBlK/pYn1yi6ghgouV8lGi3TZkYKeo8Ih8NM3yfRpZ3 RvPx8ZKJeh59eLo09hlOysRohJKDC7uT109701iTy7mzZZJ8LzWMIfOHwnvvYmgy /pgmYwgYBMHYYoZTSVsbxsORtmbyRg44JKrxt0gSV3xHx98weWGY1tzTatdX7vvw 14yLQvNU =9kzA -END PGP SIGNATURE-
Bug#1067136: astroml: numpy.testing.run_module_suite no longer exists
Source: astroml Version: 1.0.2-3 Severity: serious -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dear maintainer, your package has an autopkgtest regression due to a change in NumPy. The run_module_suite function used to be a wrapper for nose, which is no longer supported. NumPy upstream recommends that tests be run using pytest directly. Cheers Timo -BEGIN PGP SIGNATURE- iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmX5YLEACgkQ+C8H+466 LVnF3wwAhy8xIYazieR4ZeawBRHJaeSZh5NjYZQRHzFJJeyqL0YRVm6zqjyakdT7 tw1aClmxk7sC0z82FLkkFYO5exbzF2Y+VXYFejyKnENo21WkYd9sRXbOU0gtgvCL iXodr1r3PFfbvJ89jJeo/TwqWZlgqs+jnP+Pr8bfYWtVLuIWGCDmVa9sKabh18Xg RWZqp4LBn1miRZYzQtZfEJawSIEy3KxfWpQpn2gXq8IiVn29wIbs2D86IRp/ldUu vgss94o58ofKehq+h4cOaFHP/OzR9gG+Sf5wE4rOYXLuq2v4OSa89Z6qkEOw7x+o TDR9Oi+uh/41ArtWYW2dyNgr0rdIuTqbppE6NYp6iV7lBtFMMoMfFAR+RjHTm7DI 2/n7mC8e6Iw8e46GBR3Ku6oVCP6Ls6AOjIpghQ6ujWY9LvuJ+KnmnuCdxJepTdP1 IBxB9Il00AXANyyg7eZktay3LGbIw5SxnBsbqon7jAKbZprFpRB376ZSrohTKUZx pcq2GAen =MSgE -END PGP SIGNATURE-
Bug#972551: inclusion of Python3.9 breaks compatibility with libpython3-dev
Control: reassign -1 cmake Control: fixed -1 3.25.0-3 On Tue, 20 Oct 2020 09:46:59 +0200 Joachim Wuttke wrote: Package: python3-numpy Version: 1:1.19.2-2+b1 In latest Debian/testing, python3-numpy has added a dependence on libpython3.9-minimal libpython3.9-stdlib python3.9 python3.9-minimal. This breaks compatibility with packages like python3, python3-dev, libpython3-dev that depend exclusively on 3.8. It causes failure of CMake commands like find_package(Python3 COMPONENTS Interpreter Development NumPy) Is there a way to clarify once and for all that all Python3 packages with unspecified minor version ought to depend on the same minor version? This has been a known issue with CMake and has been fixed there. Closing this bug now. -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Bug#1065329: O: numpy -- Fast array facility to the Python 3 language
Hi Christian, On Sat, 2 Mar 2024 23:11:15 +0100 Christian Kastner wrote: Control: retitle -1 O: numpy -- Fast array facility to the Python 3 language Control: tags -1 - pending Having read up on debian-python, I have misread the situation. I think there needs to be a policy resolution first. I don't understand what you mean. The orphaning process is not tied to DPT policy, is it? FWIW, I am a regular user of this package and would also like to help maintain it. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Bug#1065810: tech-ctte: Call for votes on TC membership of Craig Small
===BEGIN The Technical Committee recommends that Craig Small be appointed by the Debian Project Leader to the Technical Committee. C: Recommend to Appoint Craig Small F: Further Discussion ===END I vote C > F Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Bug#1064730: stdgpu: FTBFS: type_traits.h:736:1: error: expected type-specifier before ‘template’
Hi, On Sun, 25 Feb 2024 20:28:53 +0100 Lucas Nussbaum wrote: > /usr/include/thrust/detail/type_traits.h:736:1: error: expected > type-specifier before ‘template’ This bug is caused by a #ifdef cascade for different THRUST_DEVICE_SYSTEM values, which sadly no longer works with THRUST_DEVICE_SYSTEM_OMP. This makes it effectively impossible to build the HIP backend and the OpenMP backend from the same source. -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Bug#1064547: glslang-dev: no longer shipping intermediate.h (among others)
Package: glslang-dev Version: 14.0.0-2 Severity: important Tags: affects -1 src:filament -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dear maintainer, glslang-dev stopped shipping a number of header files, which causes filament to FTBFS: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1063143 Cheers Timo -BEGIN PGP SIGNATURE- iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmXZMBUACgkQ+C8H+466 LVkCxgwAiwL9uR0sHaC2DgQL48TWIgZ1cit00KkNdxoJ1BPyf2URSUhJ3usYudms bdgbf3G8GerOouvMOMYpYljbISMCPV8oheptoc2vnr84uP4RckGYO+PPvmRCgxtJ 0+qohcrAG/1uSUw/aawl5Kp8PCuL8S3VFdSONbsocPyEOLbpaHj96uKaUoJ/RqnK rCq4eZYO8PS4L4NNvnvbOX+ldNOkEMAOsYKRJqNEnRCWW8bQfuCmyZ8LO8Lugunv z6o1XtIvWowg8X4v01auSB906jCFqDtkSAn+3i4LedDICumzjazjXXOtu9JSwkwb ky2GP1xWeI5QrVJYqIOFPYjQEdpMAr9mrIMbfLP2d8kS4fKEqI8D7wPidIled2+m grqrSsWptbY7XfySkhLpbCP/vSNuiJY4P6pTIPeQSnwkV8Scuzy0fdCt+0bTP0L/ KMoCRTZon5zjGYB/wkGUPGnSx8uBzRkoF9cG54JHzyJdp5ZP6H0WWi0oPYXALsPI 6NtbkpBG =u2mR -END PGP SIGNATURE-
Bug#1052028: Bug#1052619: ITP: pydantic-core -- Rust implementation of pydantic core functionality
Hi Andreas, * Andreas Tille [2024-02-22 08:49]: any progress with pydantic-core? I've checked Salsa for the string "pydantic" but did not found pydantic-core there. It would be really great to have pydantic 2.x (I stumbled upon python-semantic-release which also needs it to easily fix #1056503 by upgrading to latest upstream which seems to work with Python3.12) The pydantic-core packaging itself is pretty much done, but I still need the Rust crate "speedate" as dependency. For the latest upstream version of pydantic-core, "jitter" is needed as well. I need to admit I have no experience in Rust packaging so I can't really help here but pushing some start to Salsa could be the first step. The Rust team has a very unusual workflow, which is not difficult to follow but somewhat more involved than "file ITP, upload package", which caused me to procrastinate. :/ Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭────────╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Bug#1059671: python3-capstone: Python 3.12 has no module named 'distutils'
On Fri, 2 Feb 2024 08:49:11 +0200 Graham Inggs
wrote:
I believe all that is required here is patching out the import of
distutils.sysconfig:
--- a/bindings/python/capstone/__init__.py
+++ b/bindings/python/capstone/__init__.py
@@ -263,7 +263,6 @@
import ctypes, ctypes.util
from os.path import split, join, dirname
-import distutils.sysconfig
import inspect
if not hasattr(sys.modules[__name__], '__file__'):
...and dropping the dependency on python3-distutils:
--- a/debian/control
+++ b/debian/control
@@ -66,7 +67,6 @@
Section: python
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}, ${python3:Depends}, libcapstone4,
- python3-distutils
XB-Python3-Version: ${python:Versions}
Description: lightweight multi-architecture disassembly framework -
Python bindings
Capstone is a lightweight multi-platform, multi-architecture disassembly
I just NMU'd capstone (see the attached diff)
Cheers
Timo
--
⢀⣴⠾⠻⢶⣦⠀ ╭╮
⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │
⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄ ╰╯
diff --git a/debian/changelog b/debian/changelog
index 0133e16a..09e72715 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+capstone (4.0.2-5.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Remove vestigial distutils.sysconfig import (Closes: #1059671)
+
+ -- Timo Röhling Tue, 20 Feb 2024 21:30:13 +0100
+
capstone (4.0.2-5) unstable; urgency=medium
* Team upload.
diff --git a/debian/control b/debian/control
index a7d23515..9f422dc8 100644
--- a/debian/control
+++ b/debian/control
@@ -66,7 +66,6 @@ Package: python3-capstone
Section: python
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}, ${python3:Depends}, libcapstone4,
- python3-distutils
XB-Python3-Version: ${python:Versions}
Description: lightweight multi-architecture disassembly framework - Python bindings
Capstone is a lightweight multi-platform, multi-architecture disassembly
diff --git a/debian/patches/0001-Remove-magic-for-loading-shared-libraries.patch b/debian/patches/0001-Remove-magic-for-loading-shared-libraries.patch
index 69f041b8..1f0e426a 100644
--- a/debian/patches/0001-Remove-magic-for-loading-shared-libraries.patch
+++ b/debian/patches/0001-Remove-magic-for-loading-shared-libraries.patch
@@ -3,17 +3,18 @@ Date: Wed, 25 Jul 2018 15:14:07 +0200
Subject: Remove magic for loading shared libraries
---
- bindings/python/capstone/__init__.py | 46 +---
- 1 file changed, 1 insertion(+), 45 deletions(-)
+ bindings/python/capstone/__init__.py | 47 +---
+ 1 file changed, 1 insertion(+), 46 deletions(-)
diff --git a/bindings/python/capstone/__init__.py b/bindings/python/capstone/__init__.py
-index 757dc7d..4917af9 100644
+index 757dc7d..0bdb782 100644
--- a/bindings/python/capstone/__init__.py
+++ b/bindings/python/capstone/__init__.py
-@@ -264,56 +264,12 @@ CS_OPT = {v:k for k,v in locals().items() if k.startswith('CS_OPT_')}
+@@ -263,57 +263,12 @@ CS_OPT = {v:k for k,v in locals().items() if k.startswith('CS_OPT_')}
+
import ctypes, ctypes.util
from os.path import split, join, dirname
- import distutils.sysconfig
+-import distutils.sysconfig
-import pkg_resources
import inspect
signature.asc
Description: PGP signature
Bug#1061061: transition: astc-encoder
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: astc-enco...@packages.debian.org Control: affects -1 + src:astc-encoder -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dear release team, I'd like to transition astc-encoder after a SONAME bump. There is only one reverse dependency (filament), which builds fine against the new version. The Ben file is good: https://release.debian.org/transitions/html/auto-astc-encoder.html Cheers Timo -BEGIN PGP SIGNATURE- iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmWnjM4ACgkQ+C8H+466 LVkI7wv/fx0B5AFI3EvuddCxwTHbie6pC5KnS0LdYlhGyl4FgEH1YDr6ZlJ8cATC XKlf0zWyQQM6jic4gJmkMbkBEyRjR916ZMn+KDCGJbSPbr+t8CG7S5pyuwaiNj7a lVboovIx0ZbgcYlA9TvsI9sY+5d7sYZM7lUgGBF8zvE2iGG1z8DggOH5+7YwfNSO 3E7AO5UBzy1YmWmQLJxdGCdNk8Jk7JfVAcye0b9Rq7bevSJUzfNWMYKt3CCCaX97 W0sEWHqWHW7clPH4psFkfov/kr96rBnnehIMFj2sti5HfdJ3by/JlPX77lOJ29Me 6H2uAbFWN2wmFDdwumMizKCNNyNj8dlPWpKCL5i6nr149xACKOn4zHO4q3zsGQKN JH4zBVdSgwMtQDx9Y3LCAe2c4FeWVG8STPVut04IbuoNzDu6oGiVHwvSxs3TcGwJ Ok+7Xqn9UsGei2qvsNbfWrn9PRITDmRXbEuLUIQojWmMGhuqH+uWm1mSULPQ3nhI 00zsZHum =t361 -END PGP SIGNATURE-
Bug#1057717: cmake ftbfs on ppc64el (and ppc64)
Control: severity -1 normal Control: affects -1 + src:cmake Control: reassign -1 libuv1 1.46.0-2 The ppc64 related segfaults seems to have suddenly vanished again with libuv1 1.46.0-3. After some discussion and bug hunting with upstream [1], which could not reproduce the bug on their end, I think this was either caused by a tainted ppc64el build of libuv1 in Debian, or this points to a very well hidden bug in libuv1 that needs very specific conditions to trigger. In either case, I find it justified to lower the severity and reassign the bug to libuv1. I suggest we keep this bug open for now, in case the problem resurfaces on our buildds. Cheers Timo [1] https://gitlab.kitware.com/cmake/cmake/-/issues/25500 On Thu, 7 Dec 2023 15:02:33 +0100 Matthias Klose wrote: Package: src:cmake Version: 3.28.0-1 Severity: serious Tags: sid trixie cmake ftbfs on ppc64el (and ppc64): [...] 99% tests passed, 5 tests failed out of 697 Label Time Summary: CMake = 1205.59 sec*proc (290 tests) CUDA = 90.91 sec*proc (11 tests) HIP= 17.89 sec*proc (6 tests) ISPC = 60.92 sec*proc (6 tests) Label1 = 0.06 sec*proc (1 test) Label2 = 0.06 sec*proc (1 test) Qt5= 678.18 sec*proc (49 tests) command= 6.93 sec*proc (23 tests) policy = 81.42 sec*proc (42 tests) run= 1198.66 sec*proc (267 tests) Total Test time (real) = 436.62 sec The following tests FAILED: 108 - LibName (SEGFAULT) 241 - CMakeCommands.add_link_options (SEGFAULT) 264 - CTestTestDepends (Failed) 393 - RunCMake.FPHSA (SEGFAULT) 467 - RunCMake.cmake_path (SEGFAULT) Errors while running CTest make[2]: *** [Makefile:94: test] Error 8 make[2]: Leaving directory '/<>/Build' -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Bug#1059671: ropgadget: autopkgtest failure with Python 3.12
Control: reassign -1 python3-capstone Control: retitle -1 python3-capstone: Python 3.12 has no module named 'distutils' On Fri, 29 Dec 2023 23:25:28 +0200 Graham Inggs wrote: 36s from capstone import * 36s File "/usr/lib/python3/dist-packages/capstone/__init__.py", line 266, in 36s import distutils.sysconfig 36s ModuleNotFoundError: No module named 'distutils' 37s autopkgtest [20:09:36]: test autodep8-python3: ---] 37s autodep8-python3 FAIL non-zero exit status 1 The distutils import happens in python3-capstone, reassigning. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Bug#1059897: python-hypothesis: flaky tests/quality/test_discovery_ability.py::test_can_produce_multi_line_string
Source: python-hypothesis Version: 6.92.2-1 Severity: important Tags: ftbfs Forwarded: https://github.com/HypothesisWorks/hypothesis/issues/3829 -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Recently, I started to see intermittent test failures for test_can_produce_multi_line_strings in Debian package builds. I don't know if this is some sort of regression in version 6.92.2 or if this test has always been a bit flaky and merely became more likely to fail because Debian runs the test suite twice at the moment (Python 3.11 and Python 3.12). Example failure for Python 3.11: https://buildd.debian.org/status/fetch.php?pkg=python-hypothesis=all=6.92.2-1=1703980481=0 _ test_can_produce_multi_line_strings __ Traceback (most recent call last): File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 341, in from_call result: Optional[TResult] = func() ^^ File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 262, in lambda: ihook(item=item, **kwds), when=when, reraise=reraise File "/usr/lib/python3/dist-packages/pluggy/_hooks.py", line 493, in __call__ return self._hookexec(self.name, self._hookimpls, kwargs, firstresult) ^^^ File "/usr/lib/python3/dist-packages/pluggy/_manager.py", line 115, in _hookexec return self._inner_hookexec(hook_name, methods, kwargs, firstresult) ^ File "/usr/lib/python3/dist-packages/pluggy/_callers.py", line 152, in _multicall return outcome.get_result() File "/usr/lib/python3/dist-packages/pluggy/_result.py", line 114, in get_result raise exc.with_traceback(exc.__traceback__) File "/usr/lib/python3/dist-packages/pluggy/_callers.py", line 77, in _multicall res = hook_impl.function(*args) ^ File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 177, in pytest_runtest_call raise e File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 169, in pytest_runtest_call item.runtest() File "/usr/lib/python3/dist-packages/_pytest/python.py", line 1792, in runtest self.ihook.pytest_pyfunc_call(pyfuncitem=self) File "/usr/lib/python3/dist-packages/pluggy/_hooks.py", line 493, in __call__ return self._hookexec(self.name, self._hookimpls, kwargs, firstresult) ^^^ File "/usr/lib/python3/dist-packages/pluggy/_manager.py", line 115, in _hookexec return self._inner_hookexec(hook_name, methods, kwargs, firstresult) ^ File "/usr/lib/python3/dist-packages/pluggy/_callers.py", line 113, in _multicall raise exception.with_traceback(exception.__traceback__) File "/usr/lib/python3/dist-packages/pluggy/_callers.py", line 77, in _multicall res = hook_impl.function(*args) ^ File "/usr/lib/python3/dist-packages/_pytest/python.py", line 194, in pytest_pyfunc_call result = testfunction(**testargs) File "/<>/.pybuild/cpython3_3.11_hypothesis/build/tests/quality/test_discovery_ability.py", line 118, in run_test raise HypothesisFalsified( tests.quality.test_discovery_ability.HypothesisFalsified: P(lambda x: "\n" in x) ~ 47 / 98 = 0.48 < 0.50; rejected Example failure for Python 3.12: https://salsa.debian.org/python-team/packages/python-hypothesis/-/jobs/5108379 _ test_can_produce_multi_line_strings __ def run_test(): if condition is None: def _condition(x): return True condition_string = "" else: _condition = condition condition_string = strip_lambda( reflection.get_pretty_function_description(condition) ) def test_function(data): with BuildContext(data): try: value = data.draw(specifier) except UnsatisfiedAssumption: data.mark_invalid() if not _condition(value): data.mark_invalid() if predicate(value): data.mark_interesting() successes = 0 actual_runs = 0 for actual_runs in range(1, RUNS + 1): # We choose the max_examples a bit larger than default so that we # run at least 100 examples outside of the small example generation # part of the generation phase. runner = ConjectureRunner( test_function, settings=Settings( max_examples=150, phases=no_shrink,
Bug#1058958: ITP: laszip -- Lossless LiDAR compression
Package: wnpp Severity: wishlist Owner: Timo Röhling X-Debbugs-Cc: debian-de...@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: laszip Version : 3.5.0 Upstream Author : Rapidlasso GmbH * URL : https://laszip.org/ * License : BSD-2-clause, BSD-3-clause, Apache-2.0, BSL-1.0 Programming Lang: Python, C, C++ Description : Lossless LiDAR compression LASzip quickly turns bulky LAS files into compact LAZ files without information loss. The package is reintroduced by the Science Team, with consent of the GIS team, the previous maintainers. Among other things, it is needed for the Python LASzip bindings, which in turn enable the optional LASzip support in LASpy. -BEGIN PGP SIGNATURE- iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmWAvtAACgkQ+C8H+466 LVkcqwwAwetn4chREePE+wrc171arleRn8sVAD6+BH5TKTVDhkwQdqc6p/9Yad3n yZSmZv8oI59pSDqx/7iVtD3KL0y86x/UQL75nC2nfhDAMJ3VDQbcOIhD7G0RxTzE vqE2EsRhogydUlwQdUTaDbZVpdexInww3rXrRpkptczQ4PxwFZZR8frduqHwFO7F pCfWITZb4eA3zavw7DrkGqLv0hojdYLXcth+jtQwuvzqLaJQZdHGA79oSFJV65YL nhxyyVtgImDf8LcogM+KEJ+3Joa+Er8MfE+CQjLep8nwzTwFiPOcLo0GyQaixGNV Wy9+JfFGM0QirQ3zQPFMxO3k0+OqNw3CVyZV5GIISLuoUCAl5a5Bh1KDPCNRDsZU bPeDYwrAr2zjgPY3OZfJH67eyIfVsz0w2hPqV1MsnB2qDUm+LsWrRkdb5kbWh3+0 hILlsyYNrbgdazJs3AL1eqIO/IMyXHQbPgqKNRNDuplTJoMaiHEmo4dY+qHSTuM6 otwGKu9D =2IoO -END PGP SIGNATURE-
Bug#1058805: python3-open3d: SyntaxError: f-string: expecting '=', or '!', or ':', or '}'
Package: python3-open3d
Version: 0.17.0+ds-8+b1
Severity: serious
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Since the last binNMU, python3-open3d fails to configure at install
time:
Setting up python3-open3d (0.17.0+ds-8+b1) ...
/usr/lib/python3/dist-packages/open3d/examples/geometry/rgbd_datasets.py:35:
SyntaxWarning: invalid escape sequence '\s'
b"(^P5\s(?:\s*#.*[\r\n])*"
/usr/lib/python3/dist-packages/open3d/examples/geometry/rgbd_datasets.py:36:
SyntaxWarning: invalid escape sequence '\d'
b"(\d+)\s(?:\s*#.*[\r\n])*"
/usr/lib/python3/dist-packages/open3d/examples/geometry/rgbd_datasets.py:37:
SyntaxWarning: invalid escape sequence '\d'
b"(\d+)\s(?:\s*#.*[\r\n])*"
/usr/lib/python3/dist-packages/open3d/examples/geometry/rgbd_datasets.py:38:
SyntaxWarning: invalid escape sequence '\d'
b"(\d+)\s(?:\s*#.*[\r\n]\s)*)", buffer).groups()
/usr/lib/python3/dist-packages/open3d/examples/t_reconstruction_system/pose_graph_optim.py:16:
SyntaxWarning: invalid escape sequence '\i'
'''
File
"/usr/lib/python3/dist-packages/open3d/visualization/tensorboard_plugin/summary.py",
line 427
f"{tensor.shape[k-1] for tensor in tensor_tuple}.")
^^^
SyntaxError: f-string: expecting '=', or '!', or ':', or '}'
dpkg: error processing package python3-open3d (--configure):
installed python3-open3d package post-installation script subprocess returned
error exit status 1
- -- System Information:
Debian Release: trixie/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.5.0-5-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages python3-open3d depends on:
ii libc6 2.37-13
ii libfmt9 9.1.0+ds1-2
ii libgcc-s1 13.2.0-9
ii libopen3d0.17 0.17.0+ds-8+b1
ii libstdc++6 13.2.0-9
ii open3d-gui-data 0.17.0+ds-8
ii python3 3.11.6-1
ii python3-configargparse 1.5.3-1
ii python3-nbformat5.9.1-1
ii python3-numpy [python3-numpy-abi9] 1:1.24.2-2
ii python3-torch 2.0.1+dfsg-5
ii python3-werkzeug2.2.2-3
python3-open3d recommends no packages.
Versions of packages python3-open3d suggests:
pn open3d-doc
pn open3d-tools
- -- no debconf information
-BEGIN PGP SIGNATURE-
iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmV9+DkACgkQ+C8H+466
LVlvxQv/STeBt+9PrCco5maXUBgJUV67o1sgiY/2udgNZtk7DfkzjY5hOuK9R5YR
dRPCAkHpR7ptOy/skXmz/cVl1AChiT3WrkuVJXYxMX+K3ue4ReYO+kDucPUuz1OL
kWC3hI0dnBiJA74p2X7BeCJaeB3tEyehGFgZOkHvOX7rp48o1lhbghzWfebGfkEl
aS97muuoDN/Zy693qkL8cqWn7rfvAY6X95IQX3/O9EN96zbwk/PuH5Og/nZqtKh9
uKWLmnE3CacNnfBu3E7/U2cyFB8pnf048ucnFe9QYBM9olKxmZuXlwNMxEimvo6g
D/KozgKIU/e7ub2HRhlF0/0RiVp8E0zAUykD2gvc28ZdmwTOwqUecA+gCfWdDKmY
sEAVrl6uOjFH1nvaze7YBkzr8kt6epI6Njvr/r2RT5JvMO0uMTMpAdiWEata9Gd/
eiiYuRvt5Rw/ZPpuImP6aY65Qc+vVvfBobJaX/kMTIm4GAS6lhQiO+q5at7Cd/ma
EaYQxzfa
=4eus
-END PGP SIGNATURE-
Bug#1057304: nmu: ros2-performance-test-fixture_0.2.0-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu X-Debbugs-Cc: ros2-performance-test-fixt...@packages.debian.org, team+robot...@tracker.debian.org Control: affects -1 + src:ros2-performance-test-fixture -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 nmu ros2-performance-test-fixture_0.2.0-1 . ANY . unstable . -m "Rebuild against benchmark (Closes: #1054676)" benchmark 1.8.3 apparently dropped an exported symbol, which causes an undefined reference to `benchmark::internal::Benchmark::Benchmark(char const*)' when linking against ros2-performance-test-fixture. A binNMU seems to be the simplest fix for that. Cheers Timo -BEGIN PGP SIGNATURE- iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmVruXkACgkQ+C8H+466 LVn5WAv/WyQ9BfZxjG9e6vDx2lGKvkTUSE0WnZ/V2wvwZXn1qytJDdKlsRuMuGTZ 9BE5usD35IKv2yuPnPjYNxB8cRfKZX2O5iDTVNf3WZ9puRpe7X5f2ydQevfsW7j0 foq+VZ5/dkWyNHskrOUXCZHewI59XNkrILgpRIel6A3aa0Nb13d6pn00775df244 zSrgB9eGzLH9fbZNI4TE63/re/CJAWBjS316qO5og7aAimELHldhxK2/RP+mZ2Av O0BGXl9d6j69L8CvpG0mSSH1iQ9ucbANM/4eUB5dKHMv24dLw+WV24Cy2J67scta B2ZJCnlSnxQ2l+MNCLPtakPHURuqEdDhMsVld3vcSiR6OawfAtG9v5W5AdVwGFRs abBLuUd+UaVS4zFBzQMKGoPXvvD5NVZWjj53Et5QziF37HkHuf9uw+V0MeVrNUfu 8ZiuOgk+BXZ2bF/oplASBqkr8aqtVWBMXkON15UXSrKLoUnL0Fmwk0HUL2B7fByH mX/9FT/J =g67D -END PGP SIGNATURE-
Bug#1051876: ruby-rugged: please prepare for libgit2 transition
Hi, On Wed, 13 Sep 2023 22:25:30 +0200 =?utf-8?q?Timo_R=C3=B6hling?= wrote: I suggest you upload ruby-rugged 1.7.1 to experimental first, so we can check for potential regressions. I will start the transition once all language bindings are ready. FYI: It took longer than anticipated, but the transition will start now. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Bug#1053800: transition: libgit2
Hi Sebastian, * Sebastian Ramacher [2023-12-01 22:17]: Hoping that there are some good news regarding the bindings. What's the current status? 50% progress :) The Go Team replied that their one reverse dependency no longer depends on the libgit2 bindings, and suggested I bump the bug to serious (which I did) and proceed with the transition. The Rust Team did not react. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Bug#1056614: RM: tweepy -- ROM; broken, obsolete, associated service doesn't exist anymore
On Thu, 23 Nov 2023 21:38:59 + MigueL Landaeta wrote: Package: ftp.debian.org Severity: normal As title says. This package and all Twitter related packages should be removed from the archive. Twitter API access is broken, so there is no point keeping this in the archive. +1 Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Bug#1056619: ITP: soplex -- sequential object-oriented simplex solver
Hi David, * David Bremner [2023-11-24 08:49]: Great, see also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1039923 if you were not aware. I am aware, and it is my ultimate goal to package SCIP. :) There seems to be no patching needed to get the full scipoptsuite to build under sid (or even bullseye). I have not carefully examined what external software is embedded in the source. There seem to be a few things under papilo (presolver); I'm not sure if that is used by soplex or only by scip. There are a few external dependencies, but nothing too daunting. More importantly though, all three of PaPILO, SoPlex, and SCIP can potentially be linked against each other. In order to avoid circular dependencies, I came to the conclusion that SCIP should be linked against both PaPILO and SoPlex, PaPILO should probably be linked against SoPlex, and SoPlex should be built standalone. If you think otherwise, I'd be happy to hear your thoughts. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Bug#1054676: ros2-rosidl: FTBFS: ld: /usr/lib/x86_64-linux-gnu/libperformance_test_fixture.so.0d: undefined reference to `benchmark::internal::Benchmark::Benchmark(char const*)'
Control: reassign -1 src:ros2-performance-test-fixture This bug can be resolved by a rebuild of ros2-performance-test-fixture. On Fri, 27 Oct 2023 21:15:54 +0200 Lucas Nussbaum wrote: > /usr/bin/ld: > /usr/lib/x86_64-linux-gnu/libperformance_test_fixture.so.0d: > undefined reference to > `benchmark::internal::Benchmark::Benchmark(char const*)' > collect2: error: ld returned 1 exit status -- ⢀⣴⠾⠻⢶⣦⠀ ╭────╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Bug#1056619: ITP: soplex -- sequential object-oriented simplex solver
Package: wnpp Severity: wishlist Owner: Timo Röhling X-Debbugs-Cc: debian-de...@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: soplex Version : 6.0.3 Upstream Author : Zuse Institute Berlin (ZIB) * URL : https://github.com/scipopt/soplex * License : Apache-2, LGPL-2.1+, BSD-3-clause Programming Lang: C, C++ Description : sequential object-oriented simplex solver This package is part of the SCIP Optimization Suite. SoPlex is an optimization package for solving linear programming problems (LPs) based on an advanced implementation of the primal and dual revised simplex algorithm. It provides special support for the exact solution of LPs with rational input data. The package will be team-maintained under the umbrella of the Debian Math Team at https://salsa.debian.org/math-team/soplex -BEGIN PGP SIGNATURE- iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmVfzOsACgkQ+C8H+466 LVnexAwAv47byYfXLrXInUiK/H2iFsLMynDDe6RB4eE/kQ0UJmJ769+ZEIU2PPF0 LyHp7SwlJykCrIgmfFI6RFkfpG0Nxk/V3ZmA6jtYr0qEif19062ykIEfkhueCvPY cr7jLBkYTRWpqOA4Ot9d4dc/ZDzmsWHkKmxD5TbRkppgevxnXsbvbOtPtWeGlOgc G4FKW3O+YyyXE14vc2hrwsQILO7zmTzDBnlZa4HYCCn+CNhhzfkIXACafM8nXERg J+MIpJ+e+VQQXwVhIbP1T4XNS20ARyWLBaKkyDRIsa1ieyK95ajZyL7W/v9yRspp vdoFfCWXVqeqr7rg1qFHYB7cbXY0D+W3zOHzEZgm2DHZc6+Ifc6LsLrvGwrmETKT L8iBRiOwA+UUu9ENPV20pn3jUYl/SR975wFjZzwezEbJcQ+KCFiYZmPAWQYEoyWC lI8b7rsw2NO/PBGInJH4vPxUefbhp1MGGIrDQBsUnvaSQHqABj9KZThB+wJzrC0L NfYRW/iB =h/nn -END PGP SIGNATURE-
Bug#1056212: ITP: sphinxcontrib-moderncmakedomain -- Sphinx domain for Modern CMake
Package: wnpp Severity: wishlist Owner: Timo Röhling X-Debbugs-Cc: debian-de...@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: sphinxcontrib-moderncmakedomain Version : 3.27.0 Upstream Author : Kitware, Inc * URL : https://github.com/scikit-build/moderncmakedomain * License : BSD-3-clause Programming Lang: Python Description : Sphinx domain for Modern CMake This is the stand-alone version of Kitware's Sphinx code to generate the official CMake documentation, taken directly from the CMake sources. The package will be team-maintained under the umbrella of the Debian Python Team at https://salsa.debian.org/python-team/packages/sphinxcontrib-moderncmakedomain -BEGIN PGP SIGNATURE- iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmVZVuQACgkQ+C8H+466 LVnX1QwApgxr9rEY7qwtK9drW4aDxiSVWcXbl7beYcOdD3AHls0VXAWXK3XLmnlZ QNebR90PtzkhvWvyehJweSYjxE0YAOe/LOYvsfJJOcpKpm8AohnyZPnPlslmaFUI ck9j8GPJXbCEIUyApFxp/X0okDL00MsR5RuBAOVzgFmbZpJDM3ypEO3WmvGWBcZs ZEqwQ2zyDdM8guKi4uCkvWRzOAhHgEj9m1vcudj6KXxwYhuV85V442xQo6WPtFsb 78fhVgfFgjzWBkTrzGD4kCbIVTFUD1MkzmRCOgp4QEBx95nArsVOgZrlkkrmKBsF UV+UFaEB4hfRDQPQLME82q3Dr2+VHzDwTYCpGOOIzGHg+ulFya9LUxcy3/S/bRBn L1jumCoWuntWTjWVaevXxoDShYX2RF/coD0fHRbQsL8oYtrWIP9JGoXJaeyxf8y2 7TpeHHhnza/RzDDDnx6pIlqHBGVKmOidn9yyaBNJjvIx0mnKiEXdSNDGgid3ozIg l+tBHUkp =Z45h -END PGP SIGNATURE-
Bug#1055995: ITP: python-laszip -- Python bindings for LASzip
Package: wnpp Severity: wishlist Owner: Timo Röhling X-Debbugs-Cc: debian-de...@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: python-laszip Version : 0.2.3 Upstream Author : Thomas Montaigu * URL : https://github.com/tmontaigu/laszip-python * License : Expat Programming Lang: Python, C++ Description : Python bindings for LASzip This module provides LASzip bindings in Python, primarily intended for use with laspy. LASzip is a specialized compression for the ASPRS LAS file format to store data from LiDAR sensors much more efficiently. The package will be team-maintained under the umbrella of the Debian Python Team at https://salsa.debian.org/python-team/packages/python-laszip -BEGIN PGP SIGNATURE- iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmVVGKUACgkQ+C8H+466 LVlGCQwA3K3CGbqHT4sEWWRBkc2KrtTaY2IWbylUQjGaN+JyeEicBvNauYrLf2qy Z69BOoUi2vFc8tQihmH+Ogi2wcENoZ9dtx1GrP89Jfz4rwY++1ylMpr3wjzRMYd+ ulu8rTPdu52GxaFracNMY4trNktP2hO8HpqKCPQ1lWJHGQyc/yASwD1ultV9PsgS cPkAUwXcLyn3qyXzkCfNQEH1wOG69Zizh8dsqFi4ZfHRZ4iQC4X3SbRL3UtylYcr FMu6ZsbZgiv3Y/+OmKbkGKX4kbw+OZU4wPCyhjBRZAR+d0UrNkBVzQkIEqH6rB3A CKsjBdzohOQaeC6hfvyinC9VwWALFOy7HJVb9oY3UbS5gov1aKYoFMS+fhRH8EtB VNLggfgpXKH9XusUE89i9TJR9943WdM2/Y4nu1Djc88GmxmP1R17UedXjmVDmBcc cOAt19eOvvP9AzjTaYGwfquO3erPM+6HmRouX3zZWP+tOOICcwpMvekBX5gQTUWt umj7J766 =V5l9 -END PGP SIGNATURE-
Bug#1055829: ITP: nanobind -- Tiny and efficient C++/Python bindings
Package: wnpp Severity: wishlist Owner: Timo Röhling X-Debbugs-Cc: debian-de...@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: nanobind Version : 1.8.0 Upstream Author : Wenzel Jakob * URL : https://github.com/wjakob/nanobind * License : BSD-3-clause Programming Lang: Python, C++ Description : Tiny and efficient C++/Python bindings nanobind is a small binding library that exposes C++ types in Python and vice versa. It is reminiscent of Boost.Python and pybind11 and uses near-identical syntax. In contrast to these existing tools, nanobind is more efficient: bindings compile in a shorter amount of time, produce smaller binaries, and have better runtime performance. The package will be team-maintained under the umbrella of the Debian Python Team at https://salsa.debian.org/python-team/packages/nanobind -BEGIN PGP SIGNATURE- iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmVQpFMACgkQ+C8H+466 LVk6/wwAtd3RjzQiYoBeO2WwquWnQWwrNTJj2/IXs+J1GO1u3yoSJjm1fTTNmyGi iYU5zFcMuUizZ2gEChOHUQ+50xcAtTBUAIMYPgDRD6D+vZrtcFTAGk5DbotCZ8i+ +ER+jCdBMJa3et+Cpz2ryhgqM9ZyFRRkNQfya26aOBiacCsR3B0XxBjOg6eiXlQ3 J/hbi2le+7ukp84cwphWVchqXgeEEkyc5IFfBm3P2sTLIr2K8WazcRhOvnc7NczL zdIldu1k8lQ82GyTsUIyBLBbt7yjZeg+8xvj5ww2IWi1kWxIJZI6S4ac8LT03lfV ezpmoNNY0REsvT2ASa03RO+C9wIxCLZ4rnkK/R2CvOXLb0COszfRVowxXsY3tIMm qcq8yz4z4elHGeFkKjeCq7+Ype5F2NLXQ3hHP44DKBzrECdrPC45KNXzX5zigdnU 9Vi2YDdWR8ZWm3M3NF1FMz/XNwIKdPjPLaKuXsh7jFfxeirhbRDQrQ2moSrDMuYW H1boyhwy =tka6 -END PGP SIGNATURE-
Bug#1055198: ITP: lzfse -- LZFSE Compression library
* Andreas Henriksson [2023-11-04 23:03]: I hope I understood you correctly and this now adresses your concerns: https://salsa.debian.org/bananas-team/asahi-fwextract/-/commit/bfbd6f53c2e8721b9457c3a37421280a8a86dbc8 Yes, that looks good! I also like the fallback. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Bug#1053799: golang-github-libgit2-git2go: no upstream support for latest libgit2
Hi Mohammed, Pirate, On Wed, 11 Oct 2023 15:39:42 +0200 =?utf-8?q?Timo_R=C3=B6hling?= wrote: Source: golang-github-libgit2-git2go Version: 34.0.0-4 Severity: important Tags: upstream -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dear maintainer, the Go bindings for libgit2 are out of date with respect to libgit2, which blocks the planned transition of libgit2 1.7. I think the Go bindings either need to be updated to work with libgit 1.7 or removed from Debian for lack of upstream support. Can you comment on this? Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Bug#1051877: rust-libgit2-sys: please prepare for libgit2 transition
On Wed, 13 Sep 2023 22:30:42 +0200 =?utf-8?q?Timo_R=C3=B6hling?= wrote: Source: rust-libgit2-sys Version: 0.14.1-1 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dear maintainer, I have uploaded libgit2 1.7.1 to experimental and want to start the transition for unstable soon. Like many other language bindings for libgit2, the rust-libgit2-sys package needs to be upgraded in lock-step. I suggest you upload version 0.16.1+1.7.1 to experimental first, so we can check for potential regressions, but we can skip that step if you think it is not necessary. I will start the transition once all language bindings are ready. Ping! Just wondering if you saw this bug / still maintain the package :) Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Bug#1053800: transition: libgit2
Hi Sebastian, * Sebastian Ramacher [2023-11-01 12:14]: There are no replies on the bug report. Are there any news regarding the rust bindings? No, nothing yet. All uploads in the past two years came from Peter Michael Green, so I am going to ping him directly. golang-github-libgit2-git2go upstream has fallen behind and Same as above. Are there any news here? No. I was prepared to ignore the Go bindings completely after they got removed from trixie, but Mohammed Bilal did an upload to fix the RC bug, presumably because they are a build dependency of gitlab. I'll ping him, too. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Bug#1055198: ITP: lzfse -- LZFSE Compression library
Hi, * Andreas Henriksson [2023-11-04 18:05]: I've previously suggested that maybe it would be better to set a debian-specific version (0d?), to avoid the theoretical situation that upstream one day ships a different ABI under the 1 so version. Normally, I would agree, but in this particular case, Fedora already went ahead and used SOVERSION 1 [1], so that version is "burned" and we might just as well use it, too. [1] https://src.fedoraproject.org/rpms/lzfse/blob/rawhide/f/60.patch I would welcome peoples input here on what you think is best from the debian perspective. Obviously we're going to be incompatible with everyone else. I don't think that "incompatible" patch you linked creates much of an issue, because very few (if any) other library consumers will do this rather unusual dlopen() "soft linking" dance (normal linking with e.g. "gcc -llzfse" will automatically use the proper SONAME); besides, it is easy to patch in Debian packages and trivial to work around with "apt install liblzfse-dev" for everyone else. I do have one remark, though: the idea behind SONAME/SOVERSION is that you have a common name for all versions which are binary backwards compatible. Using the full version liblzfse.so.1.0 instead of libltfse.so.1 (i.e., the SONAME) in your patch defeats that purpose: it will only work with the exact version 1.0, but not any (hypothetical) future, backwards-compatible versions. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭────╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Bug#1054830: python-laspy: FTBFS: make: *** [debian/rules:11: binary] Error 25
Control: retitle 1054830 python3-sphinx-rtd-theme: Theme error:
AttributeError("'str' object has no attribute 'attributes'")
Control: reassign 1054830 python3-sphinx-rtd-theme 2.0.0~rc3+dfsg-1
Control: reassign 1054685 python3-sphinx-rtd-theme 2.0.0~rc3+dfsg-1
Control: forcemerge 1054830 1054685
Control: affects 1054830 src:open3d src:python-laspy
Hi Dmitry,
looks like the Sphinx RTD theme 2.0.0~rc3 has a rendering bug:
looking for now-outdated files... none found
pickling environment... done
checking consistency... done
preparing documents... done
writing output... [ 3%] api/index
Theme error:
An error happened in rendering the page api/index.
Reason: AttributeError("'str' object has no attribute 'attributes'")
E: pybuild pybuild:395: install: plugin pyproject failed with: exit code=2: cd docs && pandoc /<>/CHANGELOG.md
-o /<>/CHANGELOG.rst && PYTHONPATH=/<>/.pybuild/cpython3_3.11_laspy/build python3.11
-m sphinx -b html . /<>/debian/python-laspy-doc/usr/share/doc/python-laspy-doc/html
Cheers
Timo
--
⢀⣴⠾⠻⢶⣦⠀ ╭────────╮
⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │
⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄ ╰╯
signature.asc
Description: PGP signature
Bug#1051650: cmake: Problems finding libraries on Alpha
Hi Michael, On Fri, 6 Oct 2023 09:42:40 +1300 Michael Cree wrote: I have tried the suggested script (with a small modification to count number of failures) running for a few hours on one of the packages that had failed on the buildd and never saw cmake fail. But then building a few packages locally with sbuild, apbs failed first time to build with the cmake failure. Second try at building apbs with sbuild succeeded. So it appears that there is something different about running in sbuild (or possibly under dpkg-buildpackage) that is triggering this failure on occassion. Thank you for your effort! Assuming this is somehow related to the actual package build, debhelper injects a number of additional CLI arguments, mostly setting global variables that affect CMake's default behavior: -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=None -DCMAKE_INSTALL_SYSCONFDIR=/etc -DCMAKE_INSTALL_LOCALSTATEDIR=/var -DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON -DCMAKE_FIND_USE_PACKAGE_REGISTRY=OFF -DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON -DFETCHCONTENT_FULLY_DISCONNECTED=ON -DCMAKE_INSTALL_RUNSTATEDIR=/run -DCMAKE_SKIP_INSTALL_ALL_DEPENDENCY=ON -DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_INSTALL_LIBDIR=lib/alpha-linux-gnu -G"Unix Makefiles" None of that should be affecting find_library(), but... Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Bug#1053901: tech-ctte: Repeal merged-/usr file movement moratorium
* Sean Whitton [2023-10-13 21:59]: === BEGIN OPTION A: The Technical Committee formally repeals its moratorium recommending that maintainers of individual packages should not proactively move files from the root filesystem to corresponding locations under /usr in the data.tar.* of packages (see #1035831). Under Constitution 6.1.5, the Technical Committee now recommends that maintainers consult with those driving the merged-/usr transition before moving files from the root filesystem to corresponding locations under /usr in the data.tar.* of packages. The transition driver, which at the time of writing is Helmut Grohne, is using a phased approach, in which the moratorium is rolled back for only certain classes of packages, and changes, at a time. In addition, restructuring uploads should be targeted at experimental, and left for three days. This is in order that automated testing by dumat can occur. We recommend following <https://wiki.debian.org/UsrMerge>, as edited by the transition driver(s). If there is any doubt as to whether a change you wish to make is appropriate, please seek explicit approval from the transition driver(s). OPTION N: None of the above. === END I vote A > N Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Bug#1053800: transition: libgit2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: libg...@packages.debian.org Control: affects -1 + src:libgit2 Control: block -1 by 1051877 Control: block -1 by 1053799 -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dear release team, I'd like to transition libgit2 to its latest upstream release, which requires coordinated updates of its bindings for some other languages: python-pygit2 is maintained by me. ruby-rugged has been uploaded to experimental awaiting the transition. rust-libgit2-sys needs to be updated, I filed a bug for that [1]. That package is also missing from the Ben tracker. golang-github-libgit2-git2go upstream has fallen behind and cannot be updated right now, although it is possible that the bindings are actually compatible and only break because of a strict version dependency. I asked the maintainer to look into it [2]. The non-Rust reverse dependencies seem to build fine with the new libgit2. Ben tracker: https://release.debian.org/transitions/html/auto-libgit2.html Cheers Timo [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051877 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1053799 -BEGIN PGP SIGNATURE- iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmUmqaQACgkQ+C8H+466 LVn/zAwAlD5A9DlxS6qXL4hXZy+laa76LxIt8pD811r+UHV1YKHgNVGg6CcKT0fE voTO1/qD9Xi8s7SpuO7Nm6NPPEnw9dtV6k94jl5Xnd3ge7DHb7gJsQUpul56vu+w KfboMNzD6E/lpPgiuVeaIj+IahV4crsU9WuNwbz3XPH26rbpUZCIuAbYoKKnBKde SJ+L/ep5kGPNKdMNghgJd6JbVhJJlU/wreOWfqAVMaV48TxAiH07M2Q2pg2XlOrD 3A3fUAPlW7jkaqrIbXRGR2x6g0oZlrRG6KGV+fDKwOSpbaOunOAKUnM2kOztdWNY HSMG1Pu75MDPCY8lSoOdmUq3UJfVQZu2InmxGlvDRoA34I22jOk/r2I6RFjYduSZ vRDBSfjPt/RxbKSvZjK3rFACWzumFnxTu3ahH8Xa20HqMW6RSBAb346i4BxHN1qR VaJTNyeoTGknLnU2U3awTbXUG46T4PcqeV3zeEFZwuVVNed/TUFIrCxNW8pR2HCv 9ZS0Dgh/ =2/Ps -END PGP SIGNATURE-
Bug#1053799: golang-github-libgit2-git2go: no upstream support for latest libgit2
Source: golang-github-libgit2-git2go Version: 34.0.0-4 Severity: important Tags: upstream -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dear maintainer, the Go bindings for libgit2 are out of date with respect to libgit2, which blocks the planned transition of libgit2 1.7. I think the Go bindings either need to be updated to work with libgit 1.7 or removed from Debian for lack of upstream support. Cheers Timo -BEGIN PGP SIGNATURE- iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmUmpZsACgkQ+C8H+466 LVkWNQwAkbW7dn/uaTabgQPY34SN2fDp6l/bkFpm2FWPZ/UF1K+EYnUVo8Dx7E+r JSoNfnPWNF5W+n8yCCOL4AXMOY9z2HsV+bgpks4xMWQooYeQi0xZl+DSaAyV6wQQ IaeU8vYazUeTcWi0+SEepx/djyOmLF/Xes9yQNiZTBB1oWU1Z/h7qGxIUdF66zEP bP9h5uqqrekQPJIQiK5NISKXLsMnowmIQ/AUdQg9Pr4qHsaFKmggOZ07fphIXnuD LPVjPMunBWBjMrLeS4vK34oqSW94L0iRwQYfAetRkv8uvqeZjf7tdfsGXOtLlEbT Z/PSdHcUAAcbmHyDvz+Fm0lJ/wKVaKkebRUOAfQVjdGAGhQRAZLabzN6lwivCiK6 oqTHo91oOKMUCvH7Xq+lgmDQYf5XhWLCSGPach/aeLz3/r439t9XxGZE3uZM2hjt GKedL0uIMdl1jnyoOeQ2nDXghrhvxhs4QubLpqAxq8zbEWK+2n0TCrnHIv+CN3lU ueY9ennx =reBL -END PGP SIGNATURE-
Bug#1052619: ITP: pydantic-core -- Rust implementation of pydantic core functionality
Package: wnpp Severity: wishlist Owner: Timo Röhling X-Debbugs-Cc: debian-de...@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: pydantic-core Version : 2.9.0 Upstream Author : Samuel Colvin * URL : https://github.com/pydantic/pydantic-core * License : Expat Programming Lang: Python, Rust Description : Rust implementation of pydantic core functionality pydantic uses type hinting (PEP 484) and variable annotation (PEP 526) to validate that untrusted data takes the desired form. There is also support for an extension to dataclasses where the input data is validated. The core library is implemented in Rust and up to seventeen times faster than the original pure Python implementation. This is a new dependency for pydantic 2. The package will probably be team-maintained under the umbrella of the Debian Python Team . -BEGIN PGP SIGNATURE- iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmURdfQACgkQ+C8H+466 LVkUawwAjCO9wWXpdir5lVlaQa0b5niJ/JGEWC2qg6bZxBELJHyniYlyUtAl+qeb AsySa6hSQ+4nCgQEinCo9JHwwhERlY9MlceVeez4EuP1Xt4udbvx8l9RUUAlUP7b BYxgw8GAWMQsrn+ZCPdv0jjvzjI9u1LOzJqwV8w6E0XpuQTi7ZsqNegKsEg0jfVk NKUGaCyWKvEmhh1rfn7iPO0QGiufbsjp568JCA1LGX/OKL8oXD3LEu+ji9P9gCRq ym6iqrmrRtNH3vIBi29chaQUkEZRQvkzAocWXF5F8Ba6j2B9dMiuNsPT7ylBFGF/ tEbg+9ELAHlV7Ab9yAH2VPM1gpmblOs9rpp0+F+fCfW+raTH3OByXYGgMbyryOeD P+YtP2awBSpQSrS6YGjK83MTPRxrv0UflK6+XL3eDHN7GsMMQuAv4TkA9HX7BDUf 7+JP2urP0gjL4sdkRtZncHQWhEIc2HWHGUW3OAlJEClMyu/HVslomsEcS8zxKIUk UCc5c91X =J7bx -END PGP SIGNATURE-
Bug#1051435: upstream fix committed
Control: tags -1 + patch fixed-upstream Hi again, On Wed, 13 Sep 2023 16:17:59 +0200 Timo Röhling wrote: Unfortunately, this bug is *not* resolved; it looks like this is not a false positive but the subclass case which is explicitly mentioned in the documentation: Upstream has fixed this by removing the offending test, as the tested behavior (inheriting Hypothesis tests) is considered unsupported: https://github.com/pytest-dev/pytest-asyncio/commit/fd57e55db1170c029324a7a9c56f86f14468217e Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Bug#1052028: please update to pydantic 2.x
Source: pydantic Version: 1.10.4-1 Severity: wishlist X-Debbugs-Cc: debian-pyt...@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dear maintainer, I would like to have pydantic updated to the latest 2.x major release, because rstcheck depends on it. The 2.x API has some breaking changes, but according to the pydantic README, version 1.10.4 is shipped as pydantic.v1 legacy module. Therefore, any reverse dependency which is incompatible with the 2.x API can be fixed trivially at import level. As pydantic is only weakly team managed, I am submitting this wishlist bug, but I am willing to do the grunt work for this and provide the necessary team uploads. I cc'd the Python team mailing list as advance notice for the maintainers of affected reverse dependencies. Cheers Timo -BEGIN PGP SIGNATURE- iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmUFgtIACgkQ+C8H+466 LVlPWgwA48KvUKxcwuy9DEQKH6jPaa7g8vNJXIz7EdXnqhUJAVUlDV+7nJ4T5+rJ aesvqHpC6NE76Okkm76UhPk3wwCvsvoww+Ib4OHMKfYt9f1QS3FvQvMRSQWZrUpq +AB0nPfUxc5HepCcH+prshDeUkJ5QmotqeMZTmDbdmZmpHyyF1hAz+0BfgXuJlSg Gpyew8M/qm4IiN04wdG34JwyVTSGutxcHNV8o4cnupp7TuiYpLFVDVYkeJkdWYq1 vFIH80pHfTvDX+2Gk+KlfJA4tcPxvMu2sZm3S4OvIYSq97FeVWLHBUiZmNYboXIe doiAC87EFEo/NTjv1xFXzjKYz27ae/XTpTVgS2FD2U1YUYyYUtr88423QrtvUGnz gDiz+efixPsdy3H26yH1x/Y6qRLQWnag3dyXjPx3xUZgDe0Merhrm5C9Djk8ZKD4 9WuSLNVwXit3n6MMZRZHIdNO/QVxYyFsPSobytXRluroxWVYhOYeSH+uEOhvBYLl qhf317wZ =6qsd -END PGP SIGNATURE-
Bug#1051650: cmake: Problems finding libraries on Alpha
Hi Adrian, On Mon, 11 Sep 2023 01:20:53 +0300 Adrian Bunk wrote: 1. The problem is about not finding a library, it happens in many packages with many libraries. 2. The problem happens only on alpha. 3. There is no such problem with non-cmake build systems. 4. The problem started after the release of bookworm. It might be a regression in cmake 3.26 or somewhere else (glibc?). Do you think the bug is reproducible with a small shell script such as: set -e while sleep 5 do mkdir /tmp/_build cmake -B /tmp/_build -S /path/to/project/with/required/find_library rm -rf /tmp/_build done If yes, we could try this with a rebuilt CMake 3.25 and see if this is truly a CMake regression. I looked at the code and could not spot anything suspicious yet, so this would certainly be instructive. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Bug#1051877: rust-libgit2-sys: please prepare for libgit2 transition
Source: rust-libgit2-sys Version: 0.14.1-1 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dear maintainer, I have uploaded libgit2 1.7.1 to experimental and want to start the transition for unstable soon. Like many other language bindings for libgit2, the rust-libgit2-sys package needs to be upgraded in lock-step. I suggest you upload version 0.16.1+1.7.1 to experimental first, so we can check for potential regressions, but we can skip that step if you think it is not necessary. I will start the transition once all language bindings are ready. Cheers Timo -BEGIN PGP SIGNATURE- iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmUCG+4ACgkQ+C8H+466 LVmf+AwA0iNOBlUtNTVlSQXsnqfo1WnluQcI/RPJT0kPhtC4Zf3s6xncUSDnEmZc 1RTS6kalw64my9iq6usa9hnJxgl8NcZ3jPUQq1AOGgTnh6YmRBhlRIeci/7Z8Ivf fL6iWeCrHevXBPL/lu9nLcSrUhJDkgmpqfjYMnXAVkvkSrfTJ0H3l6GF5EE2GbE9 SLq92UhqhHeqGLuozPJYMSHx4ySPDIa/p0IHYpBk9X1QONhMtTT07YQZ2JZKN2bo OJg6MyQH7A/TOgKHJlk7lLcIzmQemim7badOBpbTe5a1157eRaBKIUC36cSx35fS YZJbrx/7DdQO2CaT7urbaQtzF8tfRKH8JdpNfDAm5PmTFDZUzQcreVqW9BYlp/YR svl9YZqnjhHzK0TpiXVdqBOLtwFwL4pZF5JvrmqQuI4uLxVCB4ZtR27uLmZMSERv 0FptK2JS5flvfI1j0kxzu1bzXzNTQdBohNYLUN6pbONvuOjrNVFQvDZ5KvCSKXv6 XB4xvEjK =hYqx -END PGP SIGNATURE-
Bug#1051876: ruby-rugged: please prepare for libgit2 transition
Source: ruby-rugged Version: 1.5.1+ds-1 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dear maintainer, I have uploaded libgit2 1.7.1 to experimental and want to start the transition for unstable soon. Like many other language bindings for libgit2, the ruby-rugged package needs to be upgraded in lock-step. I suggest you upload ruby-rugged 1.7.1 to experimental first, so we can check for potential regressions. I will start the transition once all language bindings are ready. Cheers Timo -BEGIN PGP SIGNATURE- iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmUCGrQACgkQ+C8H+466 LVlrkQv/QkrLfOBf8LwlJP27aLFLgPcY2XNaA2F7puXrVQJ1XGD0PlG1+KZojSRj aAchkdpet9AXiVSuwAf0V0mj4+B9CGHOtQ1uVdd9ApBpHf9WyVOyVgPSOj/X+h79 bOaOeJlad7gT0julK5Cmr0Ipw59PseVQYw3AkZyuIx1+OqIQIQzHZXSgIHVLQsTr AIEL6+gN2ljyxj+aRRShpmnuHm2tV2H0XY3mXecz1xLcJ1MPqKcwkpO3mUYYTXep 5z+ipj9C9d/ysbAEM5JBIcr/0fYjrhMxe25iIKbwi5dn8IdtKRSG4l05BVquQQFu iHsXQrAldwnV5b6x8pPBhVQSD9jYZj5WPWPPbHN2zcj0SfRUQHI53jUVQKvxVE0w rl/xUP2BNgGQzW464BknZAWOWy3hJoLrZZ8PaGxnXJO0wETZufBYJQz1xbEVqi4U NBSiut8aTRvBBcAuAxf5wcZFXmO5CQpmw2PVaBCPr2+5k3O3rq5d5luqwBlYTW3W oE+F/26r =PEtp -END PGP SIGNATURE-
Bug#1051435: fixed in python-hypothesis 6.84.3-1
Control: reopen -1 Control: severity -1 serious Unfortunately, this bug is *not* resolved; it looks like this is not a false positive but the subclass case which is explicitly mentioned in the documentation: https://hypothesis.readthedocs.io/en/latest/settings.html#hypothesis.HealthCheck.differing_executors On Tue, 12 Sep 2023 16:50:45 + Debian FTP Masters wrote: Source: python-hypothesis Source-Version: 6.84.3-1 Done: Timo Röhling We believe that the bug you reported is fixed in the latest version of python-hypothesis, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 1051...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Timo Röhling (supplier of updated python-hypothesis package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Tue, 12 Sep 2023 18:26:02 +0200 Source: python-hypothesis Architecture: source Version: 6.84.3-1 Distribution: unstable Urgency: medium Maintainer: Debian Python Team Changed-By: Timo Röhling Closes: 1051434 1051435 Changes: python-hypothesis (6.84.3-1) unstable; urgency=medium . * New upstream version 6.84.3 - Disable differing_executor health check for pytest parametrized tests, because those were mostly false alarms (Closes: #1051434, #1051435) Checksums-Sha1: 0bfb6343b1d69e09f31a8bb6a3586b0f7d2be8c1 2662 python-hypothesis_6.84.3-1.dsc 22d168b7b51e7efa8b15c133c39a457474e95e4d 9386113 python-hypothesis_6.84.3.orig.tar.gz 0b9912f773546cc5d144800586c5f67c95dc4c9a 14048 python-hypothesis_6.84.3-1.debian.tar.xz 9a50f0a9818b1d96e4f10ae9d6f39717663c 9018 python-hypothesis_6.84.3-1_amd64.buildinfo Checksums-Sha256: 88968bf42d6f5cfccb650ef50a20eca146312ab22c258833fa0126c8ee282da1 2662 python-hypothesis_6.84.3-1.dsc 49cf459b602bd817a8c78fa18f27c7a2fd3fc9d1f86061c30910ddc758839b15 9386113 python-hypothesis_6.84.3.orig.tar.gz 485e60251c12e63fbc1a9b6350324e3f4edcdce6fea157819a58ad7e7080ff12 14048 python-hypothesis_6.84.3-1.debian.tar.xz bb9ff05e7a0f0b8289e585638668e29419c123cb42e7adacf525d468108c673e 9018 python-hypothesis_6.84.3-1_amd64.buildinfo Files: e7224035ab38de967b4405962415837c 2662 python optional python-hypothesis_6.84.3-1.dsc 69e683b0e87e7b21f433a0b0c8ab42d8 9386113 python optional python-hypothesis_6.84.3.orig.tar.gz e69c9b74e3be61ef5e83be60a25d3fce 14048 python optional python-hypothesis_6.84.3-1.debian.tar.xz 2a27c00b9292392e81e399c302abb0ee 9018 python optional python-hypothesis_6.84.3-1_amd64.buildinfo -BEGIN PGP SIGNATURE- -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Bug#885698: What licenses should be included in /usr/share/common-licenses?
* Russ Allbery [2023-09-10 09:16]: In order to structure the discussion and prod people into thinking about the implications, I will make the following straw man proposal. This is what I would do if the decision was entirely up to me: Licenses will be included in common-licenses if they meet all of the following criteria: * The license is DFSG-free. * Exactly the same license wording is used by all works covered by it. * The license applies to at least 100 source packages in Debian. * The license text is longer than 25 lines. In the thread so far, there's been a bit of early convergence around my threshold of 100 packages above. I want to make sure people realize that this is a very conservative threshold that would mean saying no to most new license inclusion requests. My guess is that with the threshold set at 100, we will probably add around eight new licenses with the 25 line threshold (AGPL-2, Artistic-2.0, CC-BY 3.0, CC-BY 4.0, CC-BY-SA 3.0, CC-BY-SA 4.0, and OFL-1.1, and I'm not sure about some of those because the CC licenses have variants that would each have to reach the threshold independently; my current ad hoc script does not distinguish between the variants), and maybe 10 to 12 total without that threshold (adding Expat, zlib, some of the BSD licenses). This would essentially be continuing current practice except with more transparent and consistent criteria. It would mean not including a lot of long legal license texts that people have complained about having to duplicate, such as the CDDL, CeCILL licenses, probably the EPL, the Unicode license, etc. If that's what people want, that's what we'll do; as I said, that's what I would do if the choice were left entirely up to me. But I want to make sure I give the folks who want a much more relaxed standard a chance to speak up. For me, this outcome would already be an improvement over the current situation and alleviate my biggest pain point (CC licenses). Still, I'd like to be significantly more relaxed. I propose the following three criteria must be satisfied for inclusion in /usr/share/common-licenses: * The license is DFSG-free. * Exactly the same license wording is used by all works covered by it. * The license is in the SPDX list of common licenses (https://spdx.org/licenses/) OR The license applies to at least 100 source packages in Debian. I am not committed to the 100 source packages threshold, it is mostly intended as fallback for a hypothetical future license which is super popular but for some reason does not make it to the SPDX list in a timely manner. One very intentional side effect of my proposal is a nudge towards using SPDX License Identifiers in d/copyright files. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Bug#1051435: python-pytest-asyncio: failing autopkgtest
Source: python-pytest-asyncio Version: 0.20.3-1 Severity: important -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dear maintainer, your package started failing its autopkgtest because python-hypothesis gained a new health check. Relevant autopkgtest log excerpt from https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-pytest-asyncio/37548165/log.gz 34s === FAILURES === 34s ___ TestTwo.test_hypothesis 34s tests/hypothesis/test_inherited_test.py:8: in test_hypothesis 34s @given(value=st.integers()) 34s E hypothesis.errors.FailedHealthCheck: The method BaseClass.test_hypothesis was called from multiple different executors. This may lead to flaky tests and nonreproducible errors when replaying from database. 34s E See https://hypothesis.readthedocs.io/en/latest/healthchecks.html for more information about this. If you want to disable just this health check, add HealthCheck.differing_executors to the suppress_health_check settings for this test. -BEGIN PGP SIGNATURE- iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmT6TyEACgkQ+C8H+466 LVkQtAwA40RJWbOIQVar32o5ldh8hXMDWs64+01f+RSzKPAJTuov69jOwat7oW3z yQ+SKaEEmuolmmnFTRe7SqkjxmY8SWWjjWTliqc+kqCCWWEiOQNqMplbiA2yQ97v w/zEJk2XI063XEtF1EG4pz78a0PMJEW27vEYDMhuqH3rqfIGjnq1whiLGo2bc3xd felvm1wr8xgzin/tQfRuV/pZqzAfMZ7pzYR5VES3T11DBgU8HWFE9RWUo0314I3U fsQvk63Khv9gtquJACIxN9TbUKjGcgyXc1LczpFgs11zAN9AeruMo4F5Anp3rM1D 6RxcfEgCiw8KhRuoi2+V1C/6vLNCPseqbcUt2f+xg2PZV/EKFHbEkalqFJPCq7OC CV2ErrOT7wSMML3Fu2b2DOPGJWw4HGD4IwB1pcdJ4BUUxfeophWFq3kM7btu6IoX aFlUhFNwXCCkkSSWR1lbn++ceB2b3c1auDcIqax8yPRTJ2WOutXSvzdQyXNLOQ5C nRuuGgxu =NDil -END PGP SIGNATURE-
Bug#1051434: python-h2: failing autopkgtest
Source: python-h2
Version: 4.1.0-4
Severity: important
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Dear maintainer,
your package started failing its autopkgtest because python-hypothesis gained a
new health check.
Relevant autopkgtest log excerpt from
https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-h2/37548164/log.gz
[...]
27s
27s === FAILURES
===
27s _
TestFilter.test_range_of_acceptable_outputs[hdr_validation_flags0-validate_outbound_headers]
_
27s
27s self =
27s validation_function =
27s hdr_validation_flags = HeaderValidationFlags(is_client=True,
is_trailer=True, is_response_header=True, is_push_promise=True)
27s
27s @pytest.mark.parametrize('validation_function', validation_functions)
27s > @pytest.mark.parametrize('hdr_validation_flags', hdr_validation_combos)
27s E hypothesis.errors.FailedHealthCheck: The method
TestFilter.test_range_of_acceptable_outputs was called from multiple different
executors. This may lead to flaky tests and nonreproducible errors when
replaying from database.
27s E See https://hypothesis.readthedocs.io/en/latest/healthchecks.html for
more information about this. If you want to disable just this health check, add
HealthCheck.differing_executors to the suppress_health_check settings for this
test.
27s
27s test/test_invalid_headers.py:509: FailedHealthCheck
27s _
TestFilter.test_range_of_acceptable_outputs[hdr_validation_flags1-validate_headers]
_
27s
27s self =
27s validation_function =
27s hdr_validation_flags = HeaderValidationFlags(is_client=True,
is_trailer=True, is_response_header=True, is_push_promise=False)
27s
27s @pytest.mark.parametrize('validation_function', validation_functions)
27s > @pytest.mark.parametrize('hdr_validation_flags', hdr_validation_combos)
27s E hypothesis.errors.FailedHealthCheck: The method
TestFilter.test_range_of_acceptable_outputs was called from multiple different
executors. This may lead to flaky tests and nonreproducible errors when
replaying from database.
27s E See https://hypothesis.readthedocs.io/en/latest/healthchecks.html for
more information about this. If you want to disable just this health check, add
HealthCheck.differing_executors to the suppress_health_check settings for this
test.
27s
[...]
-BEGIN PGP SIGNATURE-
iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmT6TbAACgkQ+C8H+466
LVnEigv/XHJJjJlTFpvNji7aBNeNCnYzjCvNQMWNMc2Q1URGZnUF28Xnx/gl3SRF
+DHngXG3JLBbL0YRZ3Wz/CdEkGlV0rbR8VbGEiSvIwHv5QjB28Vnu2NJPLK5AMWi
9H7WECs6XMYADAvwEFiTIOR3VJ7Erv95HahIHDJictQ1Vui1tt03VeycAxJky/J7
+N0R2F9j1TwZgjG/oad+rEbZDhqqeloNRIHIsT0OuPXzpkR1jm6Xafw5KCv7GqOB
TnfSMc81VkG8uGib9UlXtuSv2pTppIoSnnJu0s42CqF+zZMTn5zfq0SuyzqHbn45
Fl+8dSpmmxor3RpDn/9oTV9NWzayp/8tRMwG5ZEvhvYwZ2iZRC8erNr9YhpkSykw
yiSCizPLZgRI05rnzt2ZUpzFfo2iGTfSLCDpLzP8WYcaKUSQtvPC188i2FE1kRhD
14UV3g/Qsb2IDYeJeUeiudChSPt0BzDvuwpkJ2+1IdpBlbiPpIGlzCVLRsvStmFW
+DSqehCB
=6Bju
-END PGP SIGNATURE-
Bug#1051430: ITP: python-laspy -- Library for working with LAS LiDAR files
Package: wnpp Severity: wishlist Owner: Timo Röhling X-Debbugs-Cc: debian-de...@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: python-laspy Version : 2.5.1 Upstream Author : Grant Brown * URL : https://github.com/laspy/laspy * License : BSD-2-clause Programming Lang: Python Description : Library for working with LAS LiDAR files Laspy is a Python library for reading, modifying, and creating LAS LiDAR files. The ASPRS LAS format is a sequential binary file format used to store data from LiDAR sensors and by LiDAR processing software for data interchange and archival. The package will be team-maintained under the umbrella of the Debian Python Team at https://salsa.debian.org/python-team/packages/python-laspy -BEGIN PGP SIGNATURE- iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmT6KxwACgkQ+C8H+466 LVndKAwAwgyox6Pw9oGiQr4B9NLQ46BqdaBNkfNDUq5IXIIsdaE2+m2Q3L58HB+r 1AqX2hA5HzEVk9UW/2MaH5wvbbNmjuoPq7Ov0e6Qz2Gy5zKRZWUiFCJLjslinmfI wUm43POIFt4Ss7fEwPZHUEUHb4Qn5M4JffEgUqeXrjdlylVlkZBM11vzOpeEjhpv 8c5zXEtQT4V98vzSe9y59dpbk91tBWihG6SeDpn1+jamBp8EA+WM4Q6YYJQoVAjX gmMylOHsAp+C03vxqqvQg7QSIHn/mS5v8xlDT/Vj0v6813Uq791uTko8Ac7F6+MG jLPlblXri8jhhImcOiLgQ/BA7sMsMH28cCbW0kpudqyG2agrwdxVu9rewm3O8DU6 5VoTdQU1/wm8nhxJ0e5ZjQUp4GX1lSGxdz16lD5u59Sfi8K2OGPipP7+LJkmpqnE U52OCp1/ZQrrh9gPN5cdtM2qttAIPH8ZSJ29KDwmyDIEROC9TP6iINjAMpwc28X/ weJITNvP =Ii5X -END PGP SIGNATURE-
