Bug#1071655: pytorch: FTBFS on ppc64el
Source: pytorch
Version: 2.1.2+dfsg-4
Severity: serious
Tags: ftbfs
Hello,
pytorch FTBFS on ppc64el:
FAILED:
caffe2/CMakeFiles/torch_cpu.dir/__/aten/src/ATen/native/Col2Im.cpp.o
/usr/bin/c++ -DAT_PER_OPERATOR_HEADERS -DCAFFE2_BUILD_MAIN_LIB
-DFMT_HEADER_ONLY=1 -DHAVE_MALLOC_USABLE_SIZE=1 -DHAVE_MMAP=1
-DHAVE_SHM_OPEN=1 -DHAVE_SHM_UNLINK=1
-DMINIZ_DISABLE_ZIP_READER_CRC32_CHECKS -DONNXIFI_ENABLE_EXT=1
-DONNX_ML=1 -DONNX_NAMESPACE=onnx -DTORCH_ENABLE_LLVM -DUSE_C10D_GLOO
-DUSE_DISTRIBUTED -DUSE_EXTERNAL_MZCRC -DUSE_RPC -DUSE_TENSORPIPE
-D_FILE_OFFSET_BITS=64 -Dtorch_cpu_EXPORTS
-I/home/merkys/pytorch-2.1.2+dfsg/build/aten/src
-I/home/merkys/pytorch-2.1.2+dfsg/aten/src
-I/home/merkys/pytorch-2.1.2+dfsg/build
-I/home/merkys/pytorch-2.1.2+dfsg
-I/home/merkys/pytorch-2.1.2+dfsg/cmake/../third_party/benchmark/include
-I/usr/lib/llvm-16/include -I/home/merkys/pytorch-2.1.2+dfsg/debian/foxi
-I/home/merkys/pytorch-2.1.2+dfsg/build/debian/foxi
-I/home/merkys/pytorch-2.1.2+dfsg/torch/csrc/api
-I/home/merkys/pytorch-2.1.2+dfsg/torch/csrc/api/include
-I/home/merkys/pytorch-2.1.2+dfsg/caffe2/aten/src/TH
-I/home/merkys/pytorch-2.1.2+dfsg/build/caffe2/aten/src/TH
-I/home/merkys/pytorch-2.1.2+dfsg/build/caffe2/aten/src
-I/home/merkys/pytorch-2.1.2+dfsg/build/caffe2/../aten/src
-I/home/merkys/pytorch-2.1.2+dfsg/torch/csrc
-I/home/merkys/pytorch-2.1.2+dfsg/third_party/miniz-2.1.0
-I/home/merkys/pytorch-2.1.2+dfsg/debian/kineto/libkineto/include
-I/home/merkys/pytorch-2.1.2+dfsg/debian/kineto/libkineto/src
-I/home/merkys/pytorch-2.1.2+dfsg/aten/src/ATen/..
-I/home/merkys/pytorch-2.1.2+dfsg/c10/..
-I/home/merkys/pytorch-2.1.2+dfsg/third_party/flatbuffers/include
-isystem /home/merkys/pytorch-2.1.2+dfsg/build/third_party/gloo -isystem
/home/merkys/pytorch-2.1.2+dfsg/cmake/../third_party/gloo -isystem
/home/merkys/pytorch-2.1.2+dfsg/cmake/../third_party/googletest/googlemock/include
-isystem
/home/merkys/pytorch-2.1.2+dfsg/cmake/../third_party/googletest/googletest/include
-isystem /usr/include/opencv4 -isystem /usr/include/eigen3 -isystem
/home/merkys/pytorch-2.1.2+dfsg/caffe2 -Wdate-time -D_FORTIFY_SOURCE=2
-g -O2 -ffile-prefix-map=/home/merkys/pytorch-2.1.2+dfsg=.
-fstack-protector-strong -Wformat -Werror=format-security -gsplit-dwarf
-Wno-dangling-reference -I/usr -D_GLIBCXX_USE_CXX11_ABI=1
-fvisibility-inlines-hidden -DUSE_KINETO -DLIBKINETO_NOCUPTI
-DLIBKINETO_NOROCTRACER -DSYMBOLICATE_MOBILE_DEBUG_HANDLE -O2 -fPIC
-Wall -Wextra -Werror=return-type -Werror=non-virtual-dtor
-Werror=range-loop-construct -Werror=bool-operation -Wnarrowing
-Wno-missing-field-initializers -Wno-type-limits -Wno-array-bounds
-Wno-unknown-pragmas -Wno-unused-parameter -Wno-unused-function
-Wno-unused-result -Wno-strict-overflow -Wno-strict-aliasing
-Wno-stringop-overflow -Wno-psabi -Wno-error=pedantic
-Wno-error=old-style-cast -Wno-invalid-partial-specialization
-Wno-unused-private-field -Wno-aligned-allocation-unavailable
-Wno-missing-braces -fdiagnostics-color=always -faligned-new
-Wno-unused-but-set-variable -Wno-maybe-uninitialized -fno-math-errno
-fno-trapping-math -Werror=format -Werror=cast-function-type
-Wno-stringop-overflow -O2 -g -DNDEBUG -std=gnu++17 -fPIC
-DCAFFE2_USE_GLOO -DTH_HAVE_THREAD -Wall -Wextra -Wno-unused-parameter
-Wno-unused-function -Wno-unused-result -Wno-missing-field-initializers
-Wno-unknown-pragmas -Wno-type-limits -Wno-array-bounds
-Wno-strict-overflow -Wno-strict-aliasing -Wno-missing-braces
-Wno-maybe-uninitialized -fvisibility=hidden -O2 -fopenmp -MD -MT
caffe2/CMakeFiles/torch_cpu.dir/__/aten/src/ATen/native/Col2Im.cpp.o -MF
caffe2/CMakeFiles/torch_cpu.dir/__/aten/src/ATen/native/Col2Im.cpp.o.d
-o caffe2/CMakeFiles/torch_cpu.dir/__/aten/src/ATen/native/Col2Im.cpp.o
-c /home/merkys/pytorch-2.1.2+dfsg/aten/src/ATen/native/Col2Im.cpp
In file included from
/home/merkys/pytorch-2.1.2+dfsg/aten/src/ATen/cpu/vec/vec256/vsx/vec256_common_vsx.h:8,
from
/home/merkys/pytorch-2.1.2+dfsg/aten/src/ATen/cpu/vec/vec256/vec256.h:19,
from
/home/merkys/pytorch-2.1.2+dfsg/aten/src/ATen/cpu/vec/vec.h:6,
from
/home/merkys/pytorch-2.1.2+dfsg/aten/src/ATen/native/cpu/utils.h:4,
from
/home/merkys/pytorch-2.1.2+dfsg/aten/src/ATen/native/im2col.h:7,
from
/home/merkys/pytorch-2.1.2+dfsg/aten/src/ATen/native/Col2Im.cpp:6:
/home/merkys/pytorch-2.1.2+dfsg/aten/src/ATen/cpu/vec/vec256/vsx/vec256_double_vsx.h:
In member function ‘at::vec::CPU_CAPABILITY::Vectorized
at::vec::CPU_CAPABILITY::Vectorized::acos() const’:
/home/merkys/pytorch-2.1.2+dfsg/aten/src/ATen/cpu/vec/vec256/vsx/vec256_double_vsx.h:220:14:
error: ‘Sleef_acosd2_u10’ was not declared in this scope; did you mean
‘Sleef_acoshf_u10’?
220 | return {Sleef_acosd2_u10(_vec0), Sleef_acosd2_u10(_vec1)};
| ^~~~
| Sleef_acoshf_u10
Bug#1035833: cpptraj: autopkgtest failure everywhere except on amd64
Control: severity -1 important Control: retitle -1 cpptraj: FTBFS on \!amd64 On Wed, 10 May 2023 02:29:08 +0530 Kiran S Kunjumon wrote: You package cpptraj has an autopkgtest, great. However, it fails everywhere except on amd64. Can you please investigate the situation and fix it? I have extended the build time tests to catch segfaulting executables. Therefore all architectures for which autopkgtests failed now FTBFS. Now binaries of all non-amd64 architectures are excluded. Thus cpptraj should be allowed to migrate to testing, at least for amd64. Andrius
Bug#1035833: cpptraj: autopkgtest failure everywhere except on amd64
On Wed, 10 May 2023 02:29:08 +0530 Kiran S Kunjumon wrote: === FAILURES === TEST: /tmp/autopkgtest-lxc.kz5vbtvg/downtmp/build.qgE/src/test/Test_SPAM CPPTRAJ: SPAM Test ../MasterTest.sh: line 495: 3218 Killed $cpptraj_cmd >> $CPPTRAJ_OUTPUT Error: cpptraj exited with status 137 CPPTRAJ: SPAM Pure Solvent Test 1 out of 2 executions exited with an error. 2 out of 5 comparisons failed. Interestingly, the same segmentation faults happen during build, although they do not terminate the build process. Thanks, Andrius
Bug#1064311: rdkit: NMU diff for 64-bit time_t transition
Hi, On Wed, 24 Apr 2024 23:57:17 +0200 Chris Hofstaedtler wrote:> An upload with t64 binaries is required as soon as possible. Given the packages have to go to binary-NEW, you must upload with binaries, and then probably follow up with a source-only upload once they are ACCEPTed. t64 binaries for rdkit got accepted to experimental. Should I upload it to unstable, or should I wait for someone else to do that? Best, Andrius
Bug#1065660: antlr4-maven-plugin: please provide debian-versioned maven coordinates
Control: severity -1 important Control: tags -1 - ftbfs Hi, On 2024-04-25 19:12, Santiago Vila wrote: I noticed that chemicaltagger currently FTBFS and I believe it is because of this problem, so to avoid duplicate reports, I'm raising this one to serious. A build log for chemicaltagger is available here: https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/chemicaltagger.html I have just fixed the FTBFS bug in chemicaltagger/1.6.2-4, it was a separate issue, unrelated to antlr4-maven-plugin. Best, Andrius
Bug#1065660: antlr4-maven-plugin: please provide debian-versioned maven coordinates
Hi, On 2024-04-25 19:12, Santiago Vila wrote: I noticed that chemicaltagger currently FTBFS and I believe it is because of this problem, so to avoid duplicate reports, I'm raising this one to serious. A build log for chemicaltagger is available here: https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/chemicaltagger.html I think this FTBFS is caused by change in some other dependency as antlr4-maven-plugin did not change since last successful build of chemicaltagger. By raising the severity of this bug, I'm assuming that this will be eventually fixed in antlr4-maven-plugin and chemicaltagger will not need to be changed to build again, but I really have no idea if such thing will happen. If it does not, we would need a different FTBFS bug for chemicaltagger so that it's fixed there. chemicaltagger could in principle be adapted to detect the version of antlr4-maven-plugin and build against that, but I would like to understand why antlr4-maven-plugin exports only the strictly versioned maven coordinates. This seems quite unusual for Java packages, but as said, there might be a reason for this. Best, Andrius
Bug#1069873: rdkit: FTBFS convert: Unable to read font (/usr/share/fonts/type1/gsfonts/n019003l.pfb).
Source: rdkit Version: 202309.3-3 Severity: serious Tags: ftbfs sid Hello, rdkit FTBFS with the following error in latexpdf documentation build: Extension error: convert exited with error: [stderr] b'convert: Unable to read font (/usr/share/fonts/type1/gsfonts/n019003l.pfb).\n' [stdout] b'' make[2]: *** [Makefile:118: latexpdf] Error 2 make[2]: Leaving directory '/builds/debichem-team/rdkit/debian/output/source_dir/Docs/Book' make[1]: *** [debian/rules:95: override_dh_auto_build] Error 2 make[1]: Leaving directory '/builds/debichem-team/rdkit/debian/output/source_dir' make: *** [debian/rules:40: binary] Error 2 dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2 Since I need to upload rdkit to experimental to deal with time_t64 transition, I am going to disable latexpdf documentation building for the time being and deal with this issue later. Andrius
Bug#1064311: rdkit: NMU diff for 64-bit time_t transition
Hi Chris, On 2024-04-25 00:57, Chris Hofstaedtler wrote: t64 is already in unstable and making its way to testing. So you are a bit late with getting rdkit fixed for t64. An upload with t64 binaries is required as soon as possible. Given the packages have to go to binary-NEW, you must upload with binaries, and then probably follow up with a source-only upload once they are ACCEPTed. Thanks for the information. I will upload rdkit ASAP. Best, Andrius
Bug#1063124: libccp4: NMU diff for 64-bit time_t transition
Hi, On Mon, 05 Feb 2024 07:52:37 + Steve Langasek wrote: If you have any concerns about this patch, please reach out ASAP. Although this package will be uploaded to experimental immediately, there will be a period of several days before we begin uploads to unstable; so if information becomes available that your package should not be included in the transition, there is time for us to amend the planned uploads. Should I upload libccp4 to unstable, or should I wait until someone performing the time_t64 transition does that? Andrius
Bug#1064311: rdkit: NMU diff for 64-bit time_t transition
Hi, On Mon, 19 Feb 2024 21:35:16 + Steve Langasek wrote:> Since turning on 64-bit time_t is being handled centrally through a change to the default dpkg-buildflags (https://bugs.debian.org/1037136), it is important that libraries affected by this ABI change all be uploaded close together in time. Therefore I have prepared a 0-day NMU for rdkit which will initially be uploaded to experimental if possible, then to unstable after packages have cleared binary NEW. Please find the patch for this NMU attached. It is most likely my fault this has not been resolved yet - by uploading 202309.3-3 I trashed 202309.3-2.1~exp1. Am I right that I should reupload rdkit with t64 binaries to experimental now? Andrius
Bug#1068942: unblock 1068942 by 1069098
control: unblock 1068942 by 1069098 Hello, emboss no longer builds on s390x and its binaries have been RMed from s390x, unblocking emboss migration to testing. This in principle should resolve the current bug. Andrius
Bug#1069226: tomogui: FTBFS: RuntimeError: Sphinx is required to build or test the documentation
Source: tomogui Version: 0.3.1-2 Severity: serious Tags: ftbfs Hello, tomogui FTBFS in sid on amd64: running build_doc Traceback (most recent call last): File "/home/merkys/tomogui-0.3.1/setup.py", line 804, in setup_package() File "/home/merkys/tomogui-0.3.1/setup.py", line 801, in setup_package setup(**setup_kwargs) File "/usr/lib/python3/dist-packages/setuptools/__init__.py", line 107, in setup return distutils.core.setup(**attrs) ^ File "/usr/lib/python3/dist-packages/setuptools/_distutils/core.py", line 185, in setup return run_commands(dist) ^^ File "/usr/lib/python3/dist-packages/setuptools/_distutils/core.py", line 201, in run_commands dist.run_commands() File "/usr/lib/python3/dist-packages/setuptools/_distutils/dist.py", line 969, in run_commands self.run_command(cmd) File "/usr/lib/python3/dist-packages/setuptools/dist.py", line 1233, in run_command super().run_command(command) File "/usr/lib/python3/dist-packages/setuptools/_distutils/dist.py", line 988, in run_command cmd_obj.run() File "/home/merkys/tomogui-0.3.1/setup.py", line 175, in run raise RuntimeError( RuntimeError: Sphinx is required to build or test the documentation. Please install Sphinx (http://www.sphinx-doc.org).
Bug#1069225: freesas: FTBFS: fatal error: numpy/arrayobject.h: No such file or directory
Source: freesas Version: 0.9.0-6 Severity: serious Tags: ftbfs Hello, freesas FTBFS in sid on amd64: INFO:root:x86_64-linux-gnu-gcc -Wsign-compare -fwrapv -O2 -Wall -Werror=implicit-function-declaration -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/home/merkys/freesas-0.9.0=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -g -DNDEBUG "-DPyMODINIT_FUNC=__attribute__((visibility(\"default\"))) PyObject* " -I/usr/include/python3.11 -c freesas/_distance.c -o build/temp.linux-x86_64-cpython-311/freesas/_distance.o -fopenmp -fvisibility=hidden freesas/_distance.c:1212:10: fatal error: numpy/arrayobject.h: No such file or directory 1212 | #include "numpy/arrayobject.h" | ^ compilation terminated.
Bug#1069224: nabu: FTBFS: AssertionError: OpenclUnsharpMask: max error is too high with method
Source: nabu Version: 2023.1.1-3 Severity: serious Tags: ftbfs Hello, nabu FTBFS in sid on amd64: FAILURES = __ TestUnsharp.testOpenclUnsharp __ self = @pytest.mark.skipif(not (__has_pyopencl__), reason="Need pyopencl for this test") def testOpenclUnsharp(self): cl_queue = CommandQueue(self.cl_ctx) d_image = parray.to_device(cl_queue, self.data) d_out = parray.zeros_like(d_image) for method in OpenclUnsharpMask.avail_methods: d_image = parray.to_device(cl_queue, self.data) d_out = parray.zeros_like(d_image) opencl_unsharp = OpenclUnsharpMask(self.data.shape, self.sigma, self.coeff, method=method, ctx=self.cl_ctx) opencl_unsharp.unsharp(d_image, output=d_out) res = d_out.get() > self.check_result(res, method, error_msg_prefix="OpenclUnsharpMask") nabu/misc/tests/test_unsharp.py:61: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ self = result = array([[ 82.38305 , 82.57701 , 82.776085, ..., 116.8 , 116.8 , 116.8 ], [ 82.23501 , 82.112217], [177.92279 , 177.92285 , 177.92336 , ..., 36. , 57. , 57. ]], dtype=float32) method = 'log', data = None, error_msg_prefix = 'OpenclUnsharpMask' def check_result(self, result, method, data=None, error_msg_prefix=None): reference = self.get_reference_result(method, data=data) mae = np.max(np.abs(result - reference)) err_msg = str( "%s: max error is too high with method=%s: %.2e > %.2e" % (error_msg_prefix or "", method, mae, self.tol) ) > assert mae < self.tol, err_msg E AssertionError: OpenclUnsharpMask: max error is too high with method=log: 2.33e+02 > 1.00e-04 E assert 232.60403 < 0.0001 E+ where 0.0001 = object at 0x7f62be9990a0>.tol nabu/misc/tests/test_unsharp.py:47: AssertionError
Bug#1066450: opensearch: FTBFS with lucene9/9.10.0+dfsg
control: retitle -1 opensearch: FTBFS with lucene9/9.10.0+dfsg I have recently updated lucene9. Current FTBFS is caused by missing lucene9 classes. Thus it seems that lucene9 API has changed breaking backwards compatibility. Andrius
Bug#1066296: RE: Bug#1066296: xli: FTBFS: dither.c:77:36: error: implicit declaration of function ‘strlen’ [-Werror=implicit-function-declaration]
Hi Nilson, On Wed, 13 Mar 2024 17:34:15 + Nilson Silva wrote: Relevant part (hopefully): > cc -c -g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/<>=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -O -DSYSPATHFILE=\"/usr/lib/X11/Xli\" -Wdate-time -D_FORTIFY_SOURCE=2 fill.c > dither.c: In function ‘dither’: > dither.c:77:36: error: implicit declaration of function ‘strlen’ [-Werror=implicit-function-declaration] >77 | image->title = (char *)lmalloc(strlen(cimage->title) + 12); > |^~ > dither.c:28:1: note: include ‘’ or provide a declaration of ‘strlen’ >27 | #include "xli.h" > +++ |+#include >28 | Do you need a hand in fixing this? This issue threatens a bunch of my packages with autoremoval. Best wishes, Andrius
Bug#1061765: Help needed to fix python-coverage-test-runner
Hi Andreas, On 2024-02-23 09:15, Andreas Tille wrote: I've attempted to fix python-coverage-test-runner in Git since this package is finally responsible for the failure of vmdb2: File "/usr/lib/python3/dist-packages/CoverageTestRunner.py", line 22, in import imp ModuleNotFoundError: No module named 'imp' I had a similar problem. I worked it around by depending on python3-zombie-imp, the original code did not require any modifications. Best, Andrius
Bug#1041027: rapidjson FTBFS with googletest 1.13.0
On Thu, 8 Feb 2024 10:22:10 +0200 Andrius Merkys wrote: I attach a patch which fixes the issue by setting -std=c++14 (as needed by googletest) and commenting out a code line in include/rapidjson/document.h which is gone in the newest upstream commit [1]. [1] https://github.com/Tencent/rapidjson/commit/a98e2bd633a2736cc41f96ec85ef0c50e44d A more elegant solution would be to configure rapidjson with -DRAPIDJSON_BUILD_CXX11=OFF and set -std=c++14 via DEB_CXXFLAGS_MAINT_APPEND in debian/rules, this would avoid patching CMakeLists.txt. Andrius
Bug#1041027: rapidjson FTBFS with googletest 1.13.0
control: tags -1 + patch
On Fri, 14 Jul 2023 11:03:55 +0300 Adrian Bunk wrote:
Source: rapidjson
Version: 1.1.0+dfsg2-7.1
Severity: serious
Tags: ftbfs trixie sid
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/rapidjson.html
...
In file included from /usr/src/gtest/include/gtest/gtest-message.h:57,
from /usr/src/gtest/include/gtest/gtest-assertion-result.h:46,
from /usr/src/gtest/include/gtest/gtest.h:64,
from
/build/1st/rapidjson-1.1.0+dfsg2/test/unittest/unittest.h:47,
from
/build/1st/rapidjson-1.1.0+dfsg2/test/unittest/namespacetest.cpp:15:
/usr/src/gtest/include/gtest/internal/gtest-port.h:270:2: error: #error C++
versions less than C++14 are not supported.
270 | #error C++ versions less than C++14 are not supported.
| ^
...
I attach a patch which fixes the issue by setting -std=c++14 (as needed
by googletest) and commenting out a code line in
include/rapidjson/document.h which is gone in the newest upstream commit
[1].
[1]
https://github.com/Tencent/rapidjson/commit/a98e2bd633a2736cc41f96ec85ef0c50e44d
Andrius--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -63,7 +63,7 @@
if (CMAKE_CXX_COMPILER_VERSION VERSION_LESS "4.7.0")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++0x")
else()
-set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11")
+set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++14")
endif()
endif()
if (RAPIDJSON_BUILD_ASAN)
--- a/include/rapidjson/document.h
+++ b/include/rapidjson/document.h
@@ -316,7 +316,7 @@
GenericStringRef(const GenericStringRef& rhs) : s(rhs.s), length(rhs.length) {}
-GenericStringRef& operator=(const GenericStringRef& rhs) { s = rhs.s; length = rhs.length; }
+// GenericStringRef& operator=(const GenericStringRef& rhs) { s = rhs.s; length = rhs.length; }
//! implicit conversion to plain CharType pointer
operator const Ch *() const { return s; }
Bug#1058454: [Debichem-devel] Bug#1058454: Do we really need to support 32bit in abinit and prody (maybe others)
Hi Andreas, On 2024-01-31 13:08, Andreas Tille wrote: in connection with the time_t transition in Debian Med we are discussing[1] whether we really need 32 bit support for some of our tools or whether we should realistically drop this support to concentrate on problems which are more relevant for our users. I wonder whether we could also consider abinit and prody candidates for droping 32 bit support and by doing so closing these two RC bugs. prody fails a single test case which could be fixed by increasing test tolerance. Therefore I do not think it is worth RM'ing. It is just that I cannot get down to it due to being busy with other Python migration bugs in packages I care more about. [1] https://lists.debian.org/debian-med/2024/01/msg00021.html Best, Andrius
Bug#1058127: python-mpiplus: FTBFS: AttributeError: module 'configparser' has no attribute 'SafeConfigParser'. Did you mean: 'RawConfigParser'?
Hi Yogeswaran, On 2024-01-16 03:43, Yogeswaran Umasankar wrote: I have removed the hard-coded version number from setup.py. I found that the issue was due to changes in PEP440 version naming convention in versioneer. For this package no need python3-versioneer, upstream has its own versioneer.py. The work around is, once have everything in master branch create a tag with just the version number (0.0.2-1) instead of debian/version number (debian/0.0.2-1). This would not work, either. Debian build machines build packages not from git repositories, but from source packages. Therefore they will not see git tags. Moreover, one should not deviate from Debian packaging principles to make a package build, thus Debian git tag names should not be tampered with. I have forked python-mpiplus [0] for you to check the changes and to see how it works before you decide to incorporate the changes. Feel free to MR the fork and make any further changes needed. [0] https://salsa.debian.org/yogu/python-mpiplus Thanks for looking into python-mpiplus, but I have chosen a different approach to deal with this issue. I removed embedded versioneer.py in favor of python3-versioneer thus resolving the build issue. This is not optimal either, as versioneer-derived package version stays '0+unknown', but this does not seem to be uncommon in Debian [1]. [1] $ apt-file search 0+unknown.egg-info Thank you for caring for python-mpiplus. Andrius
Bug#1058127: python-mpiplus: FTBFS: AttributeError: module 'configparser' has no attribute 'SafeConfigParser'. Did you mean: 'RawConfigParser'?
Hi Yogeswaran, On 2024-01-14 18:46, Yogeswaran Umasankar wrote: I created a patch for fixing AttributeError: module 'configparser' has no attribute 'SafeConfigParser'. In the process I have updated it to the latest upstream too. I’ve attached the debdiff for you to check out. I noticed you have hard-coded the version number in setup.py. I would suggest against doing that as maintainer(s) will have to refresh this patch each time a new upstream release is imported. Manual tasks tend to be easily overlooked. I think a better fix would be to use versioneer packaged in Debian package python3-versioneer, although I have not tried that. Best wishes, Andrius
Bug#1054974: behave: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.11 returned exit code 13
Hi, On 2024-01-15 17:34, Christoph Berg wrote: Re: Andrius Merkys The patch proposed in #1042610 does not fix test failure. Interestingly, the failure seems to be nondeterministic: after patching #1042610 some builds succeed. However, I did not manage to find the root cause. The difference between a working and a failing run is this diff: dh_auto_test -O--buildsystem=pybuild -I: pybuild base:305: cd /home/myon/debian/nmu/behave/behave/.pybuild/cpython3_3.12_behave/build; python3.12 -m pytest test +I: pybuild base:305: cd /home/myon/debian/nmu/behave/behave/.pybuild/cpython3_3.12_behave/build; python3.12 -m pytest tests I.e. pybuild invokes either "python3.12 -m pytest test" (good) or "python3.12 -m pytest tests" (bad) Great catch! I tried diff'ing working and failing buildlogs as well, but probably was not that attentive to spot this. I tried to drill down where this decision is made but couldn't spot it. This might be a bug in dh-python. As a workaround, we can move the "tests" directory aside. Then it will reliably run the "test" target. (Not pretty, but I want to get the package unstuck.) Yes, this makes sense. Best, Andrius
Bug#1054974: behave: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.11 returned exit code 13
Hi, On Tue, 12 Dec 2023 19:35:09 +0100 s3v wrote: please see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1042610 for a proposed patch. The patch proposed in #1042610 does not fix test failure. Interestingly, the failure seems to be nondeterministic: after patching #1042610 some builds succeed. However, I did not manage to find the root cause. Andrius
Bug#1042610: #1042610: patch works
Control: tags -1 + patch Hello, I can confirm that the provided patch (+B-D on python3-doc) fixes the bug. However, #1054974 is not fixed, thus behave still FTBFS. Andrius
Bug#1059175: dials: FTBFS: Imported target "DXTBX::DXTBX" includes non-existent path
Control: tags -1 + patch pending Hi, On 2023-12-21 00:42, Sebastian Ramacher wrote: Source: dials Version: 3.12.1+dfsg3-5 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) X-Debbugs-Cc: sramac...@debian.org https://buildd.debian.org/status/fetch.php?pkg=dials=amd64=3.12.1%2Bdfsg3-5%2Bb2=1702954054=0 -- Found Boost: /usr/lib/x86_64-linux-gnu/cmake/Boost-1.83.0/BoostConfig.cmake (found version "1.83.0") found components: thread python312 -- Configuring done (3.1s) CMake Error in src/dials/algorithms/background/CMakeLists.txt: Imported target "DXTBX::DXTBX" includes non-existent path "/usr/lib/python3/dist-packages/dxtbx/src" I have fixed this and pushed the fix to salsa. Salsa contains an unreleased new upstream version, therefore I refrain from upload. The same patch is applicable to 3.12.1+dfsg3 as well. Andrius
Bug#1056457: [Debichem-devel] Bug#1056457: python-ase's autopkg tests fail with Python 3.12
Control: tags -1 + patch Hi, On 2023-12-20 20:23, s3v wrote: After applying [1][2][3] from upstream and adding "-p no:warnings": addopts = -p no:cacheprovider -p no:warnings in ase/test/pytest.ini (DeprecationWarnings from various packages make tests fail), I was able to build your package in a sid chroot environment. Kind Regards [1] https://gitlab.com/ase/ase/-/commit/9c019c1782115343014691596514eb6d351e8e17 [2] https://gitlab.com/ase/ase/-/commit/f0932b3385fea739bc737e5aec1fc92960b0550c [3] https://gitlab.com/ase/ase/-/merge_requests/3022 This is great news, thanks for caring for python-ase. It would be nice to have an upstream release with all Python 3.12 compatibility fixes, but in the meantime patches are OK. Is there a way to ignore DeprecationWarnings, but leave them in to the output? They are quite helpful to see, but not worth failing the build at the time being. Best, Andrius
Bug#1058690: liblatex-tounicode-perl: trying to overwrite .../ltx2unitxt.1.gz, which is also in package texlive-bibtex-extra 2023.20231207-1
Control: tags -1 + patch Hello, On 2023-12-14 16:07, Vincent Lefevre wrote: Package: liblatex-tounicode-perl Version: 0.54-1 Severity: serious As a consequence of the upgrade of texlive-bibtex-extra to 2023.20231207-3: [...] Selecting previously unselected package liblatex-tounicode-perl. (Reading database ... 711147 files and directories currently installed.) Preparing to unpack .../00-liblatex-tounicode-perl_0.54-1_all.deb ... Unpacking liblatex-tounicode-perl (0.54-1) ... dpkg: error processing archive /tmp/apt-dpkg-install-seikpl/00-liblatex-tounicode-perl_0.54-1_all.deb (--unpack): trying to overwrite '/usr/share/man/man1/ltx2unitxt.1.gz', which is also in package texlive-bibtex-extra 2023.20231207-1 [...] It seems that the fix in bug 1058462 is incorrect or incomplete. I agree that this bug is due to the incomplete fix for #1058462. The offending files were removed from texlive-bibtex-extra, but Breaks+Replaces were not added to liblatex-tounicode-perl. Thus to complete the fix one should add the following to liblatex-tounicode-perl: Breaks: texlive-bibtex-extra (<< 2023.20231207-2) Replaces: texlive-bibtex-extra (<< 2023.20231207-2) Thanks, Andrius
Bug#1058454: [Debichem-devel] Bug#1058454: prody: autopkgtest regression on i386
Hi, On 2023-12-12 13:48, Graham Inggs wrote: Source: prody Version: 2.3.1+dfsg-3 Severity: serious Tags: sid trixie User: debian...@lists.debian.org Usertags: regression Hi Maintainer The autopkgtest of prody 2.3.1+dfsg-3 is failing when tested with numpy 1:1.24.2-2 [1]. I've copied what I hope is the relevant part of the log below. [...] 345s E AssertionError: 345s E Arrays are not equal 345s E hessian is not symmetric 345s E Mismatched elements: 6 / 51984 (0.0115%) 345s E Max absolute difference: 4.4408921e-16 345s E Max relative difference: 7.83963072e-16 345s E x: array([[ 6.913751, 0.021868, 0.94014 , ..., 0. , 0. , 345s E 0. ], 345s E [ 0.021868, 9.066915, -0.076779, ..., 0. , 0. ,... 345s E y: array([[ 6.913751, 0.021868, 0.94014 , ..., 0. , 0. , 345s E 0. ], 345s E [ 0.021868, 9.066915, -0.076779, ..., 0. , 0. ,... I think the issue here is with the tolerance of the equality criterion. Maximum absolute difference nowhere exceeds 1e-14, thus lowering the tolerance should with the failure. I am not sure how to adjust the frequency in this particular case, but I will give it a look when I have time. Thanks, Andrius
Bug#1057951: [Debichem-devel] Bug#1057951: promod3: FTBFS: No such file or directory: 'model.pdb'
Control: owner -1 ! Hi, On 2023-12-11 14:04, Santiago Vila wrote: # Also happens in bookworm found 1057951 3.2.1+ds-6 thanks El 11/12/23 a las 12:06, Andrius Merkys escribió: I can reproduce this in clean chroot on barriere.d.o. Interestingly, FTBFS happens only when building on two threads, four thread build succeeds. I have a feeling that the test execution order is important somehow. Will give a look and/or forward upstream. New upstream release is out, need to check first if the issue persists there. More to the point: This has never failed for me on single-CPU systems (where I've also tried a lot of times). I see in the build log that the tests are invoked in this way: dh_auto_test cd obj-x86_64-linux-gnu && make -j2 check ARGS\+=--verbose ARGS\+=-j2 so maybe forcing -j1 at such point would serve as a workaround. Good catch, and indeed seems to fix the issue. I will fix and upload shortly. Thanks, Andrius
Bug#1057951: [Debichem-devel] Bug#1057951: promod3: FTBFS: No such file or directory: 'model.pdb'
Control: tags -1 + confirmed
Hi,
On 2023-12-10 22:51, Santiago Vila wrote:
Package: src:promod3
Version: 3.3.1+ds-1
Severity: serious
Tags: ftbfs
Dear maintainer:
During a rebuild of all packages in unstable, your package failed to build:
[...]
[...]
==
ERROR: testExit0 (__main__.HelpActionTests.testExit0)
--
Traceback (most recent call last):
File "/<>/actions/tests/test_action_build-model.py",
line 48, in testExit0
os.remove('model.pdb')
FileNotFoundError: [Errno 2] No such file or directory: 'model.pdb'
--
Ran 3 tests in 5.583s
I can reproduce this in clean chroot on barriere.d.o. Interestingly,
FTBFS happens only when building on two threads, four thread build
succeeds. I have a feeling that the test execution order is important
somehow. Will give a look and/or forward upstream. New upstream release
is out, need to check first if the issue persists there.
Andrius
Bug#1055896: cod-tools: FTBFS: source.c:33:5: error: ‘SPGCONST’ undeclared (first use in this function); did you mean ‘OP_CONST’?
Control: owner -1 ! Hi, On 2023-11-14 14:27, Gianfranco Costamagna wrote: https://github.com/cod-developers/cod-tools/commit/2e9c0aaa367366883105fa9a7ba3d965495700f8 Just removing SPGCONST from the source.c file is enough, trivial patch attached: Sadly I opened an upstream PR before upstream updated the branch, so the patch I uploaded in Ubuntu has my name as author [patch removed for brevity] I will soon update cod-tools to the newest upstream release where this bug is fixed. Best, Andrius
Bug#1055447: htsjdk: FTBFS: 35741 tests completed, 9 failed, 10 skipped
Hi Pierre, On 2023-11-08 12:14, Pierre Gruet wrote: Thanks for the bug report. It was not easy to reproduce this one! Interesting, I ran rebuild two times and both times it failed :) I spotted this issue during ratt-rebuild of a bunch of other packages, did not really give a decent look. I found out some the failing tests were trying to create temporary files in directories that did not exist, possibly they rely on other tests to create them and tests are not run in the same order in every build? I am unsure how to address the test order so that it is always the same. Anyway, I added a check of the existence of directories before attempting to put anything inside them. Great, thanks! Best wishes, Andrius
Bug#1055237: does not conform to the standards for library packaging
Hello, On Thu, 02 Nov 2023 18:10:19 +0100 Pierre Gruet wrote: Recently catch2/3.4.0-1 was uploaded to Debian, great. Yet the binary packages do not follow the layout for libraries that is described in Policy Section 8. For instance I think we should provide a shared library and if there are enough reasons not to do so (see Policy 8.3), at least the binary package name should be changed to libcatch2-dev. Also this is not a header-only library anymore, the description of the package should be changed. I agree, binary package could be renamed and descriptions should be adapted as well. I am not sure about shared library, though. First, upstream uses full source package version for soversion. This means a transition for even a patch level upstream release. I maintain a couple of packages like this and it is tiring. Second, I do not expect any real binary package depending on catch2 shared library as only test objects are linked with it. But I may be wrong here. As a side note, the upload of the major version 3.x came out with many breaking interface changes giving rise to RC bugs in e.g. genomicsdb, netgen, spdlog, therion just to name a few, also to failing autopkgtests in many rdeps. I would have been more comfortable with such a huge version change being advertised and more prepared, with some kind of a library transition process for instance. Right. Such changes should be announced beforehand since catch2 is used widely in the archive. Transition would have been nice indeed. In any case, thanks for your work on catch2, Seconded - thanks for maintaining this package. Best wishes, Andrius
Bug#1055153: skeema: FTBFS on mips64el
Hello, On Wed, 1 Nov 2023 11:49:20 +0100 Sebastian Ramacher wrote: Source: skeema Version: 1.11.0+ds-1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) I am unable to reproduce this on eller. Most likely the test timeout is due to slow buildd machine, increasing the timeout should fix it. I will give it a look. Andrius
Bug#1055447: htsjdk: FTBFS: 35741 tests completed, 9 failed, 10 skipped
Source: htsjdk Version: 3.0.5+dfsg-1 Severity: serious Justification: FTBFS Tags: sid ftbfs Hi, I noticed htsjdk FTBFS in sid: Gradle Test Executor 1 finished executing tests. Results: FAILURE (35741 tests, 35722 successes, 9 failures, 10 skipped) 35741 tests completed, 9 failed, 10 skipped Finished generating test XML results (0.354 secs) into: /home/merkys/htsjdk-3.0.5+dfsg/build/test-results/testWithDefaultReference Generating HTML test report... Finished generating test html results (0.42 secs) into: /home/merkys/htsjdk-3.0.5+dfsg/build/reports/tests/testWithDefaultReference :testWithDefaultReference FAILED :testWithDefaultReference (Thread[Task worker for ':' Thread 2,5,main]) completed. Took 11 mins 7.989 secs. FAILURE: Build failed with an exception. * What went wrong: Execution failed for task ':testWithDefaultReference'. > There were failing tests. See the report at: file:///home/merkys/htsjdk-3.0.5+dfsg/build/reports/tests/testWithDefaultReference/index.html Andrius
Bug#1052877: redmine: FTBFS: make[1]: *** [debian/rules:20: override_dh_auto_configure] Error 7
Hello, On Tue, 26 Sep 2023 15:30:11 +0200 Lucas Nussbaum wrote:> > bundle install --local --quiet > `/sbuild-nonexistent` is not a directory. > Bundler will use `/tmp/bundler20230926-1767679-427jij1767679' as your home directory temporarily. > Could not find gem 'nokogiri (~> 1.14.0)' in cached gems or installed locally. > > The source contains the following gems matching 'nokogiri': > * nokogiri-1.15.4 > make[1]: *** [debian/rules:20: override_dh_auto_configure] Error 7 Adjusting dependency versions in Gemfile offsets this particular build issue, but one test case fails: Failure: IssueTest#test_issue_overdue_should_respect_user_timezone [/home/merkys/redmine-5.0.4/test/unit/issue_test.rb:3381]: Expected false to be truthy. rails test test/unit/issue_test.rb:3359 Maybe it is worth to replace all '~>' in Gemfile with '>=' to remove the need to patch the Gemfile with every version bump of its dependencies in Debian? Best, Andrius
Bug#1054433: node-puppeteer: website is build with Docusaurus not packaged for debian
Hi, On 2023-10-23 22:06, Bastien Roucariès wrote: Source: fasttext Source package names in Subject and Source do not match. Please retitle if this is not intentional. Best, Andrius
Bug#1054432: [Pkg-javascript-devel] Bug#1054432: node-puppeteer: website is build with Docusaurus not packaged for debian
Hi, On 2023-10-23 22:04, Bastien Roucariès wrote: Source: node-katex Source package names in Subject and Source do not match. Please retitle if this is not intentional. Best, Andrius
Bug#1053865: prody: incompatible with python3-biopython > 1.79
Source: prody Version: 2.3.1+dfsg-3 Severity: serious Justification: FTBFS Tags: sid ftbfs Forwarded: https://github.com/prody/ProDy/issues/1723 Hello, prody FTBFS with python3-biopython > 1.79: == FAIL: testBuildMSAlocal (prody.tests.sequence.test_analysis.TestBuildMSA.testBuildMSAlocal) -- Traceback (most recent call last): File "/<>/.pybuild/cpython3_3.11_prody/build/prody/tests/sequence/test_analysis.py", line 1210, in testBuildMSAlocal assert_array_equal(expect, result) File "/usr/lib/python3/dist-packages/numpy/testing/_private/utils.py", line 985, in assert_array_equal assert_array_compare(operator.__eq__, x, y, err_msg=err_msg, File "/usr/lib/python3.11/contextlib.py", line 81, in inner return func(*args, **kwds) ^^^ File "/usr/lib/python3/dist-packages/numpy/testing/_private/utils.py", line 862, in assert_array_compare raise AssertionError(msg) AssertionError: Arrays are not equal Mismatched elements: 2 / 2 (100%) x: array([and 26 gaps)>, gaps)>], dtype=object) y: array([, ], dtype=object) The upstream knows about the issue. Best, Andrius
Bug#1052888: epics-base: FTBFS: make[2]: *** [configure/RULES_TOP:62: runtests] Error 1
Control: tags -1 + unreproducible On Tue, 26 Sep 2023 15:34:01 +0200 Lucas Nussbaum wrote: Source: epics-base Version: 7.0.7+dfsg1-5 Severity: serious Justification: FTBFS Tags: trixie sid ftbfs User: lu...@debian.org Usertags: ftbfs-20230925 ftbfs-trixie Hi, During a rebuild of all packages in sid, your package failed to build on amd64. I cannot reproduce the issue on amd64. From your log the relevant part seems to be the following: epicsEventTrigger: pthread_mutex_lock failed: Invalid argument epicsEventMustTriggerThread CAC-event (0x7f4370025b30) can't proceed, suspending. Dumping a stack trace of thread 'CAC-event': [0x7f4384e76943]: /<>/lib/linux-x86_64/libCom.so.3.22.0(epicsStackTrace+0x73) [0x7f4384e679a9]: /<>/lib/linux-x86_64/libCom.so.3.22.0(cantProceed+0xc9) [0x7f4384eec0b1]: /<>/lib/linux-x86_64/libdbCore.so.3.22.0(testdbCaWaitForEventCB+0x21) [0x7f4384b4a2bc]: /<>/lib/linux-x86_64/libca.so.4.14.2(_ZN15oldSubscription7currentER10epicsGuardI10epicsMutexEjmPKv+0x6c) [0x7f4384ef052a]: /<>/lib/linux-x86_64/libdbCore.so.3.22.0(_ZN9dbContext15callStateNotifyEP9dbChanneljmPK12db_field_logR14cacStateNotify+0x17a) [0x7f4384ee4645]: /<>/lib/linux-x86_64/libdbCore.so.3.22.0(event_task+0x1e5) [0x7f4384e70842]: /<>/lib/linux-x86_64/libCom.so.3.22.0(start_routine+0xd2) [0x7f4384cd13ec]: /lib/x86_64-linux-gnu/libc.so.6(pthread_condattr_setpshared+0x4cc) [0x7f4384d51a2c]: /lib/x86_64-linux-gnu/libc.so.6(__clone+0x11c) Thread CAC-event (0x7f4370025b30) suspended regressTest.t: Timed out './regressTest' after 500 seconds regressTest.t ... I think the test has timed out due to the high load of the building machine. If this persists, increasing the timeout value could be a solution. Cheers, Andrius
Bug#1049872: armel and armhf excluded from asmjit architectures
control: severity -1 normal Hello, In 0.0~git20230914.917f19d-1 I have excluded armel and armhf architectures from the list of architectures asmjit is built upon. Thus I think the severity should be normal now. Andrius
Bug#1049872: FTBFS on multiple release architectures
Hi Emanuele, On 2023-09-11 12:07, Emanuele Rocca wrote: On 2023-09-09 08:38, Andrius Merkys wrote: This is news to me. Could you please point out where in Debian Policy I can read more about such requirement? I thought I saw packages dropping support for one or another release architecture without being removed from testing. Seehttps://release.debian.org/testing/rc_policy.txt section 4 (Autobuilding). Thanks for the pointer. According to the cited RC policy this is indeed an RC bug. I will see what I can do about it. Best, Andrius
Bug#1049872: FTBFS on multiple release architectures
Hi Emanuele, On 2023-09-05 16:58, Emanuele Rocca wrote: On 2023-08-28 07:42, Andrius Merkys wrote: On Wed, 16 Aug 2023 14:29:10 +0200 Emanuele Rocca wrote: asmjit does not build correctly on the following architectures: armel, armhf, mips64el, mipsel, s390x. Does this constitute an RC bug? If not, severity should be lowered. It does, on armel and armhf the package did build successfully in the past. See: https://buildd.debian.org/status/logs.php?pkg=asmjit=armhf https://buildd.debian.org/status/logs.php?pkg=asmjit=armel This is news to me. Could you please point out where in Debian Policy I can read more about such requirement? I thought I saw packages dropping support for one or another release architecture without being removed from testing. Bug retitled given that meanwhile the issue has been fixed on mips64el, mipsel, and s390x. This is correct, thanks. Best wishes, Andrius
Bug#1049872: FTBFS on multiple release architectures
Hi, On Wed, 16 Aug 2023 14:29:10 +0200 Emanuele Rocca wrote: asmjit does not build correctly on the following architectures: armel, armhf, mips64el, mipsel, s390x. Does this constitute an RC bug? If not, severity should be lowered. Thanks, Andrius
Bug#1042769: provean: incompatible with cd-hit >= 4.8.1-4
Hi Andreas, On 2023-08-17 10:49, Andreas Tille wrote: thanks for reporting this issue. You were mentioning you want to come up with a patch. Since you seem to have dived into this issue deeper I assume you will care for this bug. If not please clarify the status (or may be set the "help" tag). I feel like working on it myself as I have a setup for reproducing it (it needs a version of NR database, ~100 GB) and I have located the approximate location in the code (cd-hit output parsing). It could help me a lot if someone knew the changes in cd-hit output since 4.8.1, though, as I am not a frequent user. Best wishes, Andrius
Bug#1042769: provean: incompatible with cd-hit >= 4.8.1-4
Package: provean Version: 1.1.5+ds-2 Severity: serious Hello, Current provean package is broken: it segfaults while parsing the output of cd-hit. The most recent compatible version of cd-hit seems to be 4.6.4-1. I hope to come up with a patch sooner or later. Andrius
Bug#1039917: [Debichem-devel] Bug#1039917: gemmi breaks finalcif autopkgtest: causes autopkgtest timeout
Hi, On 2023-06-29 17:06, Paul Gevers wrote: With a recent upload of gemmi the autopkgtest of finalcif fails in testing when that autopkgtest is run with the binary packages of gemmi from unstable. It passes when run with only packages from testing. In tabular form: pass fail gemmi from testing 0.6.2+ds-2 finalcif from testing 113+dfsg-2 all others from testing from testing I copied some of the output at the bottom of this report. After the fifth test, there's no output until autopkgtest aborts after 2:47 hours. Normally the test takes 2 to 3 minutes. Currently this regression is blocking the migration of gemmi to testing [1]. Due to the nature of this issue, I filed this bug report against both packages. Can you please investigate the situation and reassign the bug to the right package? I have just updated finalcif to its new upstream release. This should restore finalcif's compatibility with gemmi. Should finalcif's autopkgtests pass, I will close this bug. [1] https://qa.debian.org/excuses.php?package=gemmi Andrius
Bug#1000303: liboqs: not yet ready for testing or stable
Hi Mikael, On Wed, 28 Jun 2023, 10:09 Mikael Frykholm, wrote: > > The upstream wishes to keep the package out of stable distributions for > > now, until the NIST Post-Quantum Cryptography standardization project > > reaches its conclusion > > Is this still true? Can this package be migrated to testing now? > The upstream has to be contacted regarding the status of liboqs. They have previously explicitely expressed their wish to stay out of testing. Andrius >
Bug#1039087: epic-base: embed yajl
Hi, On Sun, 25 Jun 2023 15:02:18 + =?utf-8?q?Bastien_Roucari=C3=A8s?= wrote: Your package embed a copy of yajl. I agree with un-embedding. Could you: - compile against the packaged yajl package I spent some time trying, but did not find an unintrusive way to do so. Adding OP_SYS_INCLUDES passes the compilation: override_dh_auto_build: make LINKER_USE_RPATH=NO OP_SYS_INCLUDES=-I/usr/include/yajl But I could not make the linker use the yajl library, arriving at the following failure: /usr/bin/g++ -o yajl_test -L/home/merkys/epics-base-7.0.3.1/lib/linux-x86_64 -rdynamic -m64 yajl_test.o-lCom /usr/bin/ld: yajl_test.o: in function `main': yajl_test.c:(.text.startup+0x62): undefined reference to `yajl_alloc' /usr/bin/ld: yajl_test.c:(.text.startup+0xde): undefined reference to `yajl_parse' /usr/bin/ld: yajl_test.c:(.text.startup+0x119): undefined reference to `yajl_complete_parse' /usr/bin/ld: yajl_test.c:(.text.startup+0x129): undefined reference to `yajl_free' /usr/bin/ld: yajl_test.c:(.text.startup+0x212): undefined reference to `yajl_config' /usr/bin/ld: yajl_test.c:(.text.startup+0x26b): undefined reference to `yajl_config' /usr/bin/ld: yajl_test.c:(.text.startup+0x31b): undefined reference to `yajl_config' /usr/bin/ld: yajl_test.c:(.text.startup+0x343): undefined reference to `yajl_config' /usr/bin/ld: yajl_test.c:(.text.startup+0x374): undefined reference to `yajl_get_error' /usr/bin/ld: yajl_test.c:(.text.startup+0x39d): undefined reference to `yajl_free_error' /usr/bin/ld: yajl_test.c:(.text.startup+0x3fd): undefined reference to `yajl_free' collect2: error: ld returned 1 exit status - remove by repacking the embded code copy in order to avoid accidental compilation of the embed code copy This should be doable when the build succeeds. Best, Andrius
Bug#1038954: Bug#1037474: transition: openmm
Hello, On 2023-06-25 21:15, Sebastian Ramacher wrote: python-pdbfixer seems to need a sourceful upload due to the python3-simtk => python3-openmm rename. Sourceful upload does not seem to help: somewhy python3-pdbfixer picks dependency on python3-simtk instead of python3-openmm. I guess this has something to do with package relationship declarations of python3-openmm. Andrius
Bug#1037472: molmodel: FTBFS with gemmi 0.6.2+ds-1
Source: molmodel Severity: serious Version: 3.1.0-2 Hello, molmodel FTBFS after recent update of gemmi to 0.6.2+ds-1: /home/merkys/molmodel-3.1.0/src/PDBReader.cpp: In function 'gemmi::Structure getStructureFromFile(const std::string&)': /home/merkys/molmodel-3.1.0/src/PDBReader.cpp:98:29: error: 'make_structure_from_block' is not a member of 'gemmi::impl'; did you mean 'gemmi::make_structure_from_block'? 98 | return gemmi::impl::make_structure_from_block ( gemmiDoc.blocks.at(0) ); | ^ In file included from /usr/include/gemmi/mmread.hpp:13, from /home/merkys/molmodel-3.1.0/./include/molmodel/internal/Compound.h:48, from /home/merkys/molmodel-3.1.0/./include/molmodel/internal/CompoundSystem.h:6, from /home/merkys/molmodel-3.1.0/./include/molmodel/internal/PDBReader.h:36, from /home/merkys/molmodel-3.1.0/src/PDBReader.cpp:33: /usr/include/gemmi/mmcif.hpp:15:21: note: 'gemmi::make_structure_from_block' declared here 15 | GEMMI_DLL Structure make_structure_from_block(const cif::Block& block); | ^ make[3]: *** [CMakeFiles/SimTKmolmodel.dir/build.make:219: CMakeFiles/SimTKmolmodel.dir/src/PDBReader.cpp.o] Error 1 make[3]: *** Waiting for unfinished jobs /home/merkys/molmodel-3.1.0/src/Pdb.cpp: In function 'gemmi::Structure gemmiStructFromDoc(const gemmi::cif::Document&)': /home/merkys/molmodel-3.1.0/src/Pdb.cpp:39:25: error: 'make_structure_from_block' is not a member of 'gemmi::impl'; did you mean 'gemmi::make_structure_from_block'? 39 | return gemmi::impl::make_structure_from_block(doc.blocks.front()); | ^ In file included from /usr/include/gemmi/mmread.hpp:13, from /home/merkys/molmodel-3.1.0/./include/molmodel/internal/Compound.h:48, from /home/merkys/molmodel-3.1.0/./include/molmodel/internal/Pdb.h:6, from /home/merkys/molmodel-3.1.0/src/Pdb.cpp:4: /usr/include/gemmi/mmcif.hpp:15:21: note: 'gemmi::make_structure_from_block' declared here 15 | GEMMI_DLL Structure make_structure_from_block(const cif::Block& block); | ^ The issue is better fixed upstream, I will forward the report. In the meantime it is OK to remove molmodel from testing to not obstruct the upcoming openmm transition. Andrius
Bug#1037463: macromoleculebuilder: FTBFS with gemmi 0.6.2+ds-1
Source: macromoleculebuilder Severity: serious Version: 4.0.0+dfsg-2 Hello, macromoleculebuilder FTBFS after recent update of gemmi to 0.6.2+ds-1: /home/merkys/macromoleculebuilder-4.0.0+dfsg/src/CifOutput.cpp: In function 'void SimTK::CIFOut::reWriteOutCif(const gemmi::Model&, const std::string&, const std::string&, ParameterReader&, const SimTK::CompoundSystem&, bool)': /home/merkys/macromoleculebuilder-4.0.0+dfsg/src/CifOutput.cpp:113:81: error: cannot bind rvalue reference of type 'gemmi::cif::Document&&' to lvalue of type 'gemmi::cif::Document' 113 | gemmi::Structure myTrajectoryOutputFile = gemmi::make_structure ( doc ); | ^~~ The issue is better fixed upstream, I will forward the report. In the meantime it is OK to remove macromoleculebuilder from testing to not obstruct the upcoming openmm transition. Andrius
Bug#1016958: epics-base: FTBFS without network access
Hello, On 2023-02-28 12:57, Santiago Vila wrote: Hello. Merely trying network access is already considered RC, so this should really be serious. (I would be willing to test a fix if somebody proposes one). This particular test seems to attempt to communicate to a locally running server daemon. It assumes a certain executable is installed in $PATH, thus will always fail in build time tests. I think it is OK to skip the test entirely and maybe make it an autopkgtest. On a related note, is trying network access to localhost RC? Best, Andrius
Bug#1030491: prody: FTBFS: AssertionError: 3205 != 3211
Hi Santiago, On 2023-02-06 19:36, Santiago Vila wrote: This is fully reproducible at least on Hetzner virtual instances of type CX21 and CX31. Thanks for giving this a look. Could you please provide the versions of python3-biopython and python3-numpy on your setup? ci.debian.net uses the following: python3-biopython (1.80+dfsg-4+b1) python3-numpy (1:1.24.1-2+b1) I would like to rule out the possibility that version differences are to blame here. Best, Andrius
Bug#1028722: [Debichem-devel] Bug#1028722: prody: FTBFS: AssertionError: 3205 != 3211 : selection 'abs(x) == sqrt(sq(x))' for Selection 'all' failed, expected 3211, selected 3205
Control: severity -1 important Control: tags -1 + moreinfo unreproducible Hello, On 2023-01-27 13:40, Adrian Bunk wrote: On Sat, Jan 14, 2023 at 01:42:10PM +0100, Lucas Nussbaum wrote: Source: prody Version: 2.3.1+dfsg-3 Severity: serious Justification: FTBFS Tags: bookworm sid ftbfs User: lu...@debian.org Usertags: ftbfs-20230113 ftbfs-bookworm Hi, During a rebuild of all packages in sid, your package failed to build on amd64. ... == FAIL: testFunctionSelection13 (prody.tests.atomic.test_select.TestSelect) Test function selections 'abs(x) == sqrt(sq(x))' for pdb3mht -- Traceback (most recent call last): File "/<>/.pybuild/cpython3_3.10_prody/build/prody/tests/atomic/test_select.py", line 442, in func self.assertEqual(len(sel), natoms, AssertionError: 3205 != 3211 : selection 'abs(x) == sqrt(sq(x))' for AtomGroup 3mht failed, expected 3211, selected 3205 == FAIL: testFunctionSelection14 (prody.tests.atomic.test_select.TestSelect) Test function selections "abs(x) == sqrt(sq(x))" -- Traceback (most recent call last): File "/<>/.pybuild/cpython3_3.10_prody/build/prody/tests/atomic/test_select.py", line 483, in func self.assertEqual(len(sel), natoms, AssertionError: 3205 != 3211 : selection 'abs(x) == sqrt(sq(x))' for Selection 'all' failed, expected 3211, selected 3205 -- Ran 954 tests in 46.514s FAILED (failures=2, skipped=37) ... Are you still able to reproduce this? It built both on the buildds and in reproducible: https://buildd.debian.org/status/package.php?p=prody https://tests.reproducible-builds.org/debian/history/prody.html I cannot reproduce this neither in sid nor bookworm. Maybe this has something to do with temporary broken numpy. Andrius
Bug#1028705: xraylarch: FTBFS: build-dependency not installable: python-numpy-doc
Control: tags -1 + pending On Sat, 14 Jan 2023 13:54:02 +0100 Lucas Nussbaum wrote:> > The following packages have unmet dependencies: > sbuild-build-depends-main-dummy : Depends: python-numpy-doc but it is not installable > E: Unable to correct problems, you have held broken packages. > apt-get failed. xraylarch builds successfully without python-numpy-doc. I have removed it and pushed to salsa. Andrius
Bug#1026207: marked as pending in python-ase
Control: tag -1 pending Hello, Bug #1026207 in python-ase reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/debichem-team/python-ase/-/commit/107cd838b53315dd7a0e9536e219ab72b68ca21b Restore compatibility of tests (Closes: #1026207) (this message was generated automatically) -- Greetings https://bugs.debian.org/1026207
Bug#1027215: How much do we lose if we remove theano (+keras, deepnano, invesalius)?
Hello, On 2023-01-14 13:12, Rebecca N. Palmer wrote: theano has been mostly abandoned upstream since 2018. (The Aesara fork is not abandoned, but includes interface changes including the import name, so would break reverse dependencies not specifically altered for it.) Its reverse dependencies are keras, deepnano and invesalius. It is currently broken, probably by numpy 1.24 (#1027215), and the immediately obvious fixes weren't enough (https://salsa.debian.org/science-team/theano/-/pipelines). Is this worth spending more effort on fixing, or should we just remove it? keras is needed to train evaluation models for qmean [1] which I intend [2] to package eventually. qmean is a quite popular protein model evaluation tool, personally I use it a lot and I believe it would be useful to have it in Debian. That said, it is OK to omit keras in bookworm if need be, but I would like to see it back for trixie. [1] https://git.scicore.unibas.ch/search?search=keras_source=navbar_id=69_id=25_code=true_ref=master [2] https://bugs.debian.org/976981 Best, Andrius
Bug#1023972: Python 3.11 for bookworm?
Hi Simon,
On 2023-01-07 13:24, Simon McVittie wrote:
On Sat, 07 Jan 2023 at 10:23:19 +0200, Andrius Merkys wrote:
If I may, I would as well be grateful if someone could give a look at:
#1023972 [src:python-ase] FTBFS with Python 3.11 due to
pathlib.Path.__enter__() deprecation
I have no idea how to fix this and the upstream is silent.
My first thought on seeing this was: why were Path objects a context
manager in the first place? What would that mean?
Looking at the code in python3.10 and python3.11 pathlib, it seems the
reason this is deprecated is indeed that it didn't make sense:
def __enter__(self):
# In previous versions of pathlib, __exit__() marked this path as
# closed; subsequent attempts to perform I/O would raise an IOError.
# This functionality was never documented, and had the effect of
# making Path objects mutable, contrary to PEP 428.
# In Python 3.9 __exit__() was made a no-op.
# In Python 3.11 __enter__() began emitting DeprecationWarning.
# In Python 3.13 __enter__() and __exit__() should be removed.
warnings.warn("pathlib.Path.__enter__() is deprecated and scheduled "
"for removal in Python 3.13; Path objects as a context "
"manager is a no-op",
DeprecationWarning, stacklevel=2)
return self
def __exit__(self, t, v, tb):
pass
So the solution seems to be that if your package contains this:
with some_path_object:
do_stuff(some_path_object)
replace it with:
do_stuff(some_path_object)
and if it contains:
with Path(...) as my_path:
do_stuff(my_path)
replace with:
my_path = Path(...)
do_stuff(my_path)
I hope that should be a relatively straightforward change.
Thanks a lot for the hint, this indeed worked. Failure in __enter__()
threw me off tracks, but now I recall how it is related to 'with'
construction.
Best wishes,
Andrius
Bug#1023972: marked as pending in python-ase
Control: tag -1 pending Hello, Bug #1023972 in python-ase reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/debichem-team/python-ase/-/commit/1ff2e8498eda0fbb3684c3a695f31712e9c93bfa Add a patch to fix compatibility with Python 3.11 (Closes: #1023972). Thanks Simon McVittie. (this message was generated automatically) -- Greetings https://bugs.debian.org/1023972
Bug#1023972: Python 3.11 for bookworm?
Hello, On 2023-01-07 10:05, Andreas Tille wrote: Am Thu, Jan 05, 2023 at 01:57:43PM +0100 schrieb Thomas Goirand: Please share it in this list! #1023965 [src:pandas] pandas FTBFS with Python 3.11 as supported version #1024031 [src:numba] numba FTBFS with Python 3.11 as supported version If I may, I would as well be grateful if someone could give a look at: #1023972 [src:python-ase] FTBFS with Python 3.11 due to pathlib.Path.__enter__() deprecation I have no idea how to fix this and the upstream is silent. Best, Andrius
Bug#1027828: [Debichem-devel] Bug#1027828: macromoleculebuilder: FTBFS in bullseye (a2x: ERROR: "xsltproc" [...] returned non-zero exit status 5)
Hi Santiago, On 2023-01-03 22:35, Santiago Vila wrote: Package: src:macromoleculebuilder Version: 3.2+dfsg-2 Severity: serious Tags: ftbfs Control: fixed -1 4.0.0+dfsg-2 Dear maintainer: During a rebuild of all packages in bullseye, your package failed to build I can reproduce the issue. Should I propose a bullseye-pu upload fixing it? Best, Andrius
Bug#1026603: foolscap: FTBFS: AttributeError: module 'inspect' has no attribute 'getargspec'
Hello, On Tue, 20 Dec 2022 18:11:51 +0100 Lucas Nussbaum > During a rebuild of all packages in sid, your package failed to build on amd64. [skip] > File "/<>/.pybuild/cpython3_3.11/build/foolscap/remoteinterface.py", line 191, in initFromMethod > names, _, _, typeList = inspect.getargspec(method) > ^^ > AttributeError: module 'inspect' has no attribute 'getargspec' inspect.getargspec has been deprecated for some time [1] and most likely finally removed in Python 3.11. I have attempted to replace it with inspect.getfullargspec as seen somewhere else [2], but this did not work. [1] https://docs.python.org/3/library/inspect.html [2] https://github.com/pyinvoke/invoke/issues/833#issuecomment-1293148106 Andrius
Bug#1026325: [Debichem-devel] Bug#1026325: libchemistry-opensmiles-perl breaks smiles-scripts autopkgtest: output changed
Control: owner -1 ! Hi Paul, On 2022-12-18 18:48, Paul Gevers wrote: With a recent upload of libchemistry-opensmiles-perl the autopkgtest of smiles-scripts fails in testing when that autopkgtest is run with the binary packages of libchemistry-opensmiles-perl from unstable. It passes when run with only packages from testing. In tabular form: pass fail libchemistry-opensmiles-perl from testing 0.8.4-1 smiles-scripts from testing 0.2.0+dfsg1-1 all others from testing from testing I copied some of the output at the bottom of this report. Currently this regression is blocking the migration of libchemistry-opensmiles-perl to testing [1]. Due to the nature of this issue, I filed this bug report against both packages. Can you please investigate the situation and reassign the bug to the right package? Thanks for the report. I am aware of the situation, will fix in the upcoming week or two. Best, Andrius
Bug#1023972: python-ase: FTBFS with Python 3.11 due to pathlib.Path.__enter__() deprecation
On Sun, 13 Nov 2022 13:12:15 +0200 Andrius Merkys wrote:
python-ase/3.22.1 FTBFS with the following after Python 3.11 support has
been added:
DeprecationWarning: pathlib.Path.__enter__() is deprecated and scheduled
for removal in Python 3.13; Path objects as a context manager is a no-op
I have forwarded this upstream.
A month has passed without any action from the upstream. Now the issue
is of severity:serious. If threatened by autoremoval, one possibility to
resolve it might be ignoring the warning for the time being:
import warnings
warnings.filterwarnings("ignore", category=DeprecationWarning)
Source:
https://stackoverflow.com/questions/879173/how-to-ignore-deprecation-warnings-in-python
Haven't tested if this indeed works yet.
Andrius
Bug#1025000: python-qtawesome: Includes non-source Font Awesome 5
Hi,
On 2022-12-12 00:17, Bastian Germann wrote:
finalcif's source has some fa5 prefixes, so the package might be affected.
Andrius, can you please comment on this?
Yes, these are calls to qtawesome.icon('fa5.save') and the like. But if
fonts can be drop-in-replaced with ones from fonts-fork-awesome then I
think these icon functions should work as expected.
Andrius
Bug#1025000: python-qtawesome: Includes non-source Font Awesome 5
Hi, On 2022-12-09 09:28, Julian Gilbey wrote: I have seen this and will deal with it soon. Have you contacted the authors of the package to discuss this issue? No, I did not. Anyway, a quick check on testing shows that there are three packages depending on python3-qtawesome: finalcif, openlp, python3-spyder. I know about python3-spyder (and it has the same upstream developers as python3-qtawesome), but finalcif and openlp's maintainers might not realise the issue and be surprised when they start getting bug reports about icons missing (or the package failing) - it would be polite to email their maintainers and uploaders before releasing this DFSG version of the package. I got the impression that the removed fonts can be drop-in-replaced with ones from DFSG-compatible fork from fonts-fork-awesome, but I did not check that. I am in contact with finalcif upstream and could talk to them, but I would first try the drop-in replacement approach. Best, Andrius
Bug#1025000: python-qtawesome: Includes non-source Font Awesome 5
Hi Bastian, On Mon, 28 Nov 2022 16:16:19 +0100 Bastian Germann wrote: This package contains three font files /usr/share/python-qtawesome/fonts/fontawesome5-*-webfont.ttf which are licensed freely but are not built from source and cannot be built from source (missing build system). #902981 has the details. Please repack the package to get rid of these files. I saw you have excluded the files in unreleased 1.2.1+dfsg-1 version of the package. Are you planning to upload it soon, or are there any blockers? Best, Andrius
Bug#1024526: simbody: FTBFS on ppc64el, mips64el
Control: severity -1 important The upstream says this is a bug in optimization, but they do not have access to these architectures. For now I have RMed the binaries of ppc64el and mips64el, thus the package should be allowed to migrate to testing without them for the time being. Andrius
Bug#1025242: fastapi: FTBFS with python3.11
Source: fastapi
Severity: serious
Version: 0.85.0-2
Hello,
fastapi FTBFS with added support for python3.11:
pybuild --test --test-pytest -i python{version} -p "3.11 3.10"
I: pybuild base:240: PYTHONPATH=/<>/build/lib/ python3.11
-m pytest tests/ --ignore=tests/test_default_response_class.py
--ignore-glob=tests/test_tutorial/test_security/test_tutorial005*
--ignore=te
sts/test_tutorial/test_custom_response/test_tutorial009c.py
--ignore=tests/test_response_by_alias.py -k ' not
test_get_custom_response and not test_root and not test_async_testing
and not test_orjson_non_str_key
s'
= test session starts
==
platform linux -- Python 3.11.0+, pytest-7.1.2, pluggy-1.0.0+repack
rootdir: /<>, configfile: pyproject.toml
plugins: anyio-3.6.2
collected 35 items / 287 errors
ERRORS
_ ERROR collecting tests/test_additional_properties.py
_
tests/test_additional_properties.py:3: in
from fastapi import FastAPI
fastapi/__init__.py:7: in
from .applications import FastAPI as FastAPI
fastapi/applications.py:15: in
from fastapi import routing
fastapi/routing.py:23: in
from fastapi.dependencies.models import Dependant
fastapi/dependencies/models.py:3: in
from fastapi.security.base import SecurityBase
fastapi/security/__init__.py:1: in
from .api_key import APIKeyCookie as APIKeyCookie
fastapi/security/api_key.py:3: in
from fastapi.openapi.models import APIKey, APIKeyIn
fastapi/openapi/models.py:8: in
import email_validator # type: ignore
/usr/lib/python3/dist-packages/email_validator/__init__.py:6: in
import dns.resolver
/usr/lib/python3/dist-packages/dns/resolver.py:38: in
import dns.query
/usr/lib/python3/dist-packages/dns/query.py:52: in
import httpx
/usr/lib/python3/dist-packages/httpx/__init__.py:2: in
from ._api import delete, get, head, options, patch, post, put,
request, stream
/usr/lib/python3/dist-packages/httpx/_api.py:4: in
from ._client import Client
/usr/lib/python3/dist-packages/httpx/_client.py:9: in
from ._auth import Auth, BasicAuth, FunctionAuth
/usr/lib/python3/dist-packages/httpx/_auth.py:10: in
from ._models import Request, Response
/usr/lib/python3/dist-packages/httpx/_models.py:1: in
import cgi
/usr/lib/python3.11/cgi.py:57: in
warnings._deprecated(__name__, remove=(3,13))
/usr/lib/python3.11/warnings.py:514: in _deprecated
warn(msg, DeprecationWarning, stacklevel=3)
E DeprecationWarning: 'cgi' is deprecated and slated for removal in
Python 3.13
Many similar failures follow as well, skipped here for brevity.
Andrius
Bug#1025238: python-uvicorn: FTBFS with python3.11
Source: python-uvicorn Severity: serious Version: 0.17.6-1 Hello, python-uvicorn FTBFS with added support for python3.11: debian/rules override_dh_auto_test make[1]: Entering directory '/<>' http_proxy= https_proxy= dh_auto_test I: pybuild pybuild:300: cp -r /<>/tests /<>/.pybuild/cpython3_3.11/build I: pybuild base:240: cd /<>/.pybuild/cpython3_3.11/build; python3.11 -m pytest -s --verbose -k 'not test_run and not test_invalid_upgrade and not test_default_headers and not test_trace_logging and not test_websocket_auto' --ignore=tests/protocols/test_websocket.py = test session starts == platform linux -- Python 3.11.0+, pytest-7.1.2, pluggy-1.0.0+repack -- /usr/bin/python3.11 cachedir: .pytest_cache rootdir: /<>, configfile: setup.cfg plugins: asyncio-0.19.0, mock-3.8.2, anyio-3.6.2 asyncio: mode=Mode.STRICT collecting ... collected 201 items / 8 errors / 1 deselected / 200 selected ERRORS _ ERROR collecting .pybuild/cpython3_3.11/build/tests/test_default_headers.py __ tests/test_default_headers.py:1: in import httpx /usr/lib/python3/dist-packages/httpx/__init__.py:2: in from ._api import delete, get, head, options, patch, post, put, request, stream /usr/lib/python3/dist-packages/httpx/_api.py:4: in from ._client import Client /usr/lib/python3/dist-packages/httpx/_client.py:9: in from ._auth import Auth, BasicAuth, FunctionAuth /usr/lib/python3/dist-packages/httpx/_auth.py:10: in from ._models import Request, Response /usr/lib/python3/dist-packages/httpx/_models.py:1: in import cgi /usr/lib/python3.11/cgi.py:57: in warnings._deprecated(__name__, remove=(3,13)) /usr/lib/python3.11/warnings.py:514: in _deprecated warn(msg, DeprecationWarning, stacklevel=3) E DeprecationWarning: 'cgi' is deprecated and slated for removal in Python 3.13 Many similar failures follow as well, skipped here for brevity. Andrius
Bug#1025237: scalene: FTBFS with python3.11
Source: scalene
Severity: serious
Version: 1.4.1-1
Hello,
scalene FTBFS with added support for python3.11:
building 'scalene.pywhere' extension
x86_64-linux-gnu-gcc -Wsign-compare -DNDEBUG -g -fwrapv -O2 -Wall -g
-fstack-protector-strong -Wformat -Werror=format-security -g -fwrapv -O2
-g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong
-Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC
-I. -Isrc -Isrc/include -I/usr/include/python3.11 -c
src/source/pywhere.cpp -o
build/temp.linux-x86_64-cpython-311/src/source/pywhere.o -std=c++14
src/source/pywhere.cpp: In function ‘int whereInPython(std::string&,
int&, int&)’:
src/source/pywhere.cpp:176:40: error: ‘PyThreadState’ {aka ‘struct _ts’}
has no member named ‘frame’; did you mean ‘cframe’?
176 | if (threadState == 0 || threadState->frame == 0) {
|^
|cframe
src/source/pywhere.cpp:190:34: error: ‘PyThreadState’ {aka ‘struct _ts’}
has no member named ‘frame’; did you mean ‘cframe’?
190 | for (auto frame = threadState->frame; frame != nullptr;
| ^
| cframe
error: command '/usr/bin/x86_64-linux-gnu-gcc' failed with exit code 1
E: pybuild pybuild:379: build: plugin distutils failed with: exit
code=1: /usr/bin/python3.11 setup.py build
Andrius
Bug#1019808: [Debichem-devel] Bug#1019808: marked as pending in openbabel
Hi Olly, On 2022-11-27 21:09, Olly Betts wrote: This transition is now down to just 3 packages needing updating (one of which accidentally got uploaded over the weekend based on a pre-transition version so we should be down to 2 packages soon). This bug has been tagged as "pending" for over a month now - please could a maintainer make an upload of openbabel soon? Or if there's a problem with the update then please update this bug so we know what the status is. Thanks for a reminder. I will upload openbabel tomorrow at latest. Best, Andrius
Bug#1024986: python-biopython: does not vendor bindings for python3.11 yet
Hi, On 2022-11-28 10:23, Nilesh Patra wrote: biopython in unstable does not vendor bindings for python3.11, due to which augur and busco fail their autopkgtest. This as well blocks the update of prody to 2.3.1. The issue is fixed in 1.80+dfsg-1~0exp0 in experimental [1][2]. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1022307#66 [2] https://buildd.debian.org/status/fetch.php?pkg=python-biopython=amd64=1.80%2Bdfsg-1%7E0exp0=1669325748=0 Andrius
Bug#1022307: status on t_coffee causing biopython ftbfs
Hi Nilesh, On 2022-11-23 15:35, Nilesh Patra wrote: That sounds quite a reasonable thing to do, but we probably should also decrese the severity of this bug to "important" to let biopython be in testing once the corresponding tests are skipped. Sure, lowering of severity was implied (but it is good to have that stated explicitly). Best, Andrius
Bug#1022307: status on t_coffee causing biopython ftbfs
Hi, On Tue, 22 Nov 2022 23:54:48 +0100 =?utf-8?Q?=C3=89tienne?= Mollier wrote: Hi, mostly retitling the open entry against biopython for the sake of clarity, and also pinging both bugs to reset auto- removal counters. We don't have much news from t_coffee upstream to day unfortunately. Maybe it will be necessary to revert the t-coffee version bump for the upcoming Debian release or do people see other options? This issue is blocking Python 3.11-add transition, but we surely do not want biopython to be dropped from testing. However, the problem is not with biopython, but with t-coffee which biopython merely uses for tests. Would it be acceptable to skip t-coffee tests for now thus unblocking Python 3.11-add transition? This bug report should remain open to remind us bring t-coffee tests back once #1022570 is solved. Best, Andrius
Bug#953630: [Debichem-devel] Bug#953630: openbabel autopkg tests fail on non-amd64 architectures
Hi, On 2022-11-20 18:18, Paul Gevers wrote: From the BSP in Tilburg, I uploaded the attached NMU to DELAYED/5. Please let me know if I should delay more or cancel. Thanks, IMO this NMU is fine. Similar logic should be applied to the build time tests in future, since now their failures are plainly ignored. Andrius
Bug#1024035: marked as pending in pycifrw
Control: tag -1 pending Hello, Bug #1024035 in pycifrw reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/pycifrw/-/commit/7762ede8fb0774b5b53392040d110ae36e69d188 Fix compatibility with Python 3.11 (Closes: #1024035). (this message was generated automatically) -- Greetings https://bugs.debian.org/1024035
Bug#1024075: [Debichem-devel] Bug#1024075: pymatgen FTBFS with Python 3.11 as supported version
Control: tags -1 + fixed-upstream Hello, On 2022-11-14 15:54, Adrian Bunk wrote: x86_64-linux-gnu-gcc -Wsign-compare -DNDEBUG -g -fwrapv -O2 -Wall -g -fstack-protector-strong -Wformat -Werror=format-security -g -fwrapv -O2 -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -I/usr/include/python3.11 -I/usr/lib/python3/dist-packages/numpy/core/include -c pymatgen/optimization/linear_assignment.c -o build/temp.linux-x86_64-cpython-311/pymatgen/optimization/linear_assignment.o pymatgen/optimization/linear_assignment.c:196:12: fatal error: longintrepr.h: No such file or directory 196 | #include "longintrepr.h" |^~~ compilation terminated. error: command '/usr/bin/x86_64-linux-gnu-gcc' failed with exit code 1 E: pybuild pybuild:379: build: plugin distutils failed with: exit code=1: /usr/bin/python3.11 setup.py build Updating to the newest upstream version should fix Python 3.11 compatibility issues, at least upstream reports no issues with Python 3.11 [1]. [1] https://github.com/materialsproject/pymatgen/issues/2710 Andrius
Bug#1012093: ciftools-java: FTBFS with OpenJDK 17 due to test failures
Hi Pierre, On 2022-11-10 11:04, Pierre Gruet wrote: But whoops, sorry, this morning I tried to upload 4.0.3-2 with a manual fix as I hadn't seen upstream released 4.0.4 fixing the issue. I launched a dcut cancel command, we will see if it worked... Else my upload will get accepted and I will update the VCS! Wow, what a coincidence :) Anyway, I think this should not be a problem. I have fetched your commits, merged and resolved the conflicts to reflect the state after my upload of 4.0.4-1. Sorry for the mess. Best, Andrius
Bug#1012093: ciftools-java: FTBFS with OpenJDK 17 due to test failures
Control: owner -1 ! Control: tags -1 + pending fixed-upstream Hi Pierre, On 2022-11-10 00:05, Pierre Gruet wrote: I investigated the test failure a bit and saw tiny differences between a generated gzip file and a reference one. This reminded me of one similar and innocuous issue [0] so that I filled an issue upstream [1]. Let's see. Thanks a lot for investigating and contacting the upstream! The new release builds and passes its tests successfully. I will upload it in short. Best, Andrius
Bug#1019808: marked as pending in openbabel
Control: tag -1 pending Hello, Bug #1019808 in openbabel reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/debichem-team/openbabel/-/commit/9a875ec27408d6d399f0e69b20fd8f019eed646e Transition to wxwidgets3.2 (Closes: #1019808) (this message was generated automatically) -- Greetings https://bugs.debian.org/1019808
Bug#1021550: FTBFS: JarCacheTest.cacheMiss Expected exception: java.io.IOException
Control: tags -1 + unreproducible Control: severity -1 important Hi Pierre, I have successfully built the package even with disabled network. Thus I cannot reproduce the FTBFS in any setup I can think of. As a result I am lowering issue's severity. Feel free to bump it back, but please supply some additional environment details to help me reproduce it. It may as well be that the failure is nondeterministic (signal race). Thanks, Andrius
Bug#1021550: FTBFS: JarCacheTest.cacheMiss Expected exception: java.io.IOException
Control: tags -1 + moreinfo Hi Pierre, I cannot reproduce this issue. I suspect it may have something to do with network not being present at the build time. Could you please confirm that your build setup has network disabled intentionally? Interestingly, reproducible-builds does not reproduce FTBFS also. Thanks, Andrius
Bug#1020148: marked as pending in georegression
Control: tag -1 pending Hello, Bug #1020148 in georegression reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/java-team/georegression/-/commit/10c8f41bde224d1059cd94983f7ac29f48450d71 Switch to javahelper (Closes: #1020148). (this message was generated automatically) -- Greetings https://bugs.debian.org/1020148
Bug#1016227: marked as pending in openbabel
Control: tag -1 pending Hello, Bug #1016227 in openbabel reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/debichem-team/openbabel/-/commit/b0d93c983566d19977c36ab28368b7b2fe4b7129 Include in obutil.h (Closes: #1016227) (this message was generated automatically) -- Greetings https://bugs.debian.org/1016227
Bug#1017717: cp2k: FTBFS: symbol lookup error: /usr/lib/x86_64-linux-gnu/openmpi/lib/openmpi3/mca_pmix_ext3x.so: undefined symbol: pmix_value_load
Source: cp2k Version: 9.1-2 Severity: serious Justification: FTBFS Tags: bookworm sid ftbfs Hello, cp2k fails to build on amd64: cd tools/manual && \ /home/merkys/cp2k-9.1/exe/*/cp2k.psmp --xml && \ saxonb-xslt -o index.html -ext:on cp2k_input.xml cp2k_input.xsl orted: symbol lookup error: /usr/lib/x86_64-linux-gnu/openmpi/lib/openmpi3/mca_pmix_ext3x.so: undefined symbol: pmix_value_load [barriere:463328] [[INVALID],INVALID] ORTE_ERROR_LOG: Unable to start a daemon on the local node in file ../../../../../../orte/mca/ess/singleton/ess_singleton_module.c at line 716 [barriere:463328] [[INVALID],INVALID] ORTE_ERROR_LOG: Unable to start a daemon on the local node in file ../../../../../../orte/mca/ess/singleton/ess_singleton_module.c at line 172 -- It looks like orte_init failed for some reason; your parallel process is likely to abort. There are many reasons that a parallel process can fail during orte_init; some of which are due to configuration or environment problems. This failure appears to be an internal failure; here's some additional information (which may only be relevant to an Open MPI developer): orte_ess_init failed --> Returned value Unable to start a daemon on the local node (-127) instead of ORTE_SUCCESS -- -- It looks like MPI_INIT failed for some reason; your parallel process is likely to abort. There are many reasons that a parallel process can fail during MPI_INIT; some of which are due to configuration or environment problems. This failure appears to be an internal failure; here's some additional information (which may only be relevant to an Open MPI developer): ompi_mpi_init: ompi_rte_init failed --> Returned "Unable to start a daemon on the local node" (-127) instead of "Success" (0) -- *** An error occurred in MPI_Init_thread *** on a NULL communicator *** MPI_ERRORS_ARE_FATAL (processes in this communicator will now abort, ***and potentially your MPI job) [barriere:463328] Local abort before MPI_INIT completed completed successfully, but am not able to aggregate error messages, and not able to guarantee that all other processes were killed! Andrius
Bug#1009281: [Debichem-devel] Bug#1009281: Bug#1009281: Bug#1009281: Should cinfony be removed?
Hi,
On 2022-07-24 21:18, Moritz Mühlenhoff wrote:
> Did you get any reply? Otherwise let's go ahead with the removal.
I have checked upstream's master branch and it indeed seems to contain
at least some porting to Python 3. I have opened a branch on Salsa
('python3') to attempt to package it. However, the port does not seem to
be complete, as I get syntax errors due to Python 2 syntax.
Best,
Andrius
Bug#953630: [Debichem-devel] Bug#953630: openbabel autopkg tests fail on non-amd64 architectures
Hello, IMO it is high time to revisit this issue. On 2020-03-11 14:33, Matthias Klose wrote: > openbabel autopkg tests areq quiet interesting. Working around the timeout on > arm64 hides the fact that two other tests fail on every non-amd64 > architecture. I agree that the way the autopkgtest is written hides some of the failures. Your patch does indeed un-hide them. > Also looking at the test output, you see that one test succeeds despites the > python3 binary segfaulting. Test failures are ignored for openbabel now (pinging Michael who did that [1]). If we really aim at catching all test failures, I guess we should not ignore them. However, this may result in openbabel being RMed from non-amd64 architectures and I got the impression that the upstream may not have enough resources to debug on non-amd64 architectures [2]. [1] https://salsa.debian.org/debichem-team/openbabel/-/commit/eb17fde215d2ec6d3b37f365ff42250cde3700e7 [2] https://github.com/openbabel/openbabel/issues/2417#issuecomment-942098541 Best, Andrius
Bug#1012482: rdflib: URLInputSource can be abused to retrieve arbitrary documents if used naïvely
Hi Nilesh, On Sun, 31 Jul 2022, 12:12 Nilesh Patra, wrote: > rdflib has been removed from testing along with a bunch of other packages. > And it is triggering -rm-s for packages in testing anyway. > > Upstream is not actively working on the issue as I see from the github > Issue > URL. -- Do you think we can lower severity of this bug for a bit? > AFAIK, usually it is up to the maintainer to decide about the severity. It could be lowered, yes, but I do not think it is OK to have rdflib with this bug in bookworm. It would be good to ping the upstream as well. Best, Andrius >
Bug#1014492: guzzle: CVE-2022-31090 CVE-2022-31091
Hi Katharina, On Thu, 7 Jul 2022 10:56:06 +0200 Katharina Drexel wrote: > thanks for the hints. I pushed a new version in the repo > (https://salsa.debian.org/php-team/pear/php-guzzlehttp-guzzle). > TBD: someone should upload it in the debian repo. Is it OK if I upload guzzle? By the way, debian/changelog contains two Debian versions for 7.4.5: 7.4.5-1 and 7.4.5-2. It does not seem 7.4.5-1 has been uploaded yet, could you merge both of them to be 7.4.5-1? Best, Andrius
Bug#1013085: marked as pending in python-ase
Control: tag -1 pending Hello, Bug #1013085 in python-ase reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/debichem-team/python-ase/-/commit/c46ddfb3c73b679151f71a98920ce19933523ba4 Fix test failure due to the usage of deprecated scipy API (Closes: #1013085) (this message was generated automatically) -- Greetings https://bugs.debian.org/1013085
Bug#1013566: [Pkg-javascript-devel] Bug#1013566: node-sockjs: FTBFS: sockjs.coffee:137:9: error: Can't reference 'this' before calling super in derived class constructors
Hi Yadd, On 2022-06-24 17:10, Yadd wrote: > I prepared a fix, pushed to salsa. Could you take a look ? Thanks a lot, reviewed and uploaded. Best wishes, Andrius
Bug#1012498: finalcif: FTBFS with python3-gemmi 0.5.5+ds
Source: finalcif Version: 104+dfsg-1 Severity: serious Tags: ftbfs finalcif FTBFS with python3-gemmi 0.5.5+ds: self = @property def is_centrosymm(self) -> bool: """ Whether a structuere is centro symmetric or not. """ if not self.symmops or self.symmops == ['']: # Do not crash without symmops return False ops = gemmi.GroupOps([gemmi.Op(o) for o in self.symmops]) > return ops.is_centric() E AttributeError: 'gemmi.GroupOps' object has no attribute 'is_centric' finalcif/cif/cif_file_io.py:567: AttributeError It worked fine with python3-gemmi 0.5.4+ds, thus the cause is API change in python3-gemmi. Andrius
Bug#1012482: rdflib: URLInputSource can be abused to retrieve arbitrary documents if used naïvely
Source: rdflib Version: 6.1.1 Severity: critical Tags: security upstream Forwarded: https://github.com/RDFLib/rdflib/issues/1844 Hello, rdflib will attempt to resolve any URL in @context in POSTed JSON-LD messages, leading to various probing and DDoS vectors, see the upstream discussion [1]. [1] https://github.com/RDFLib/rdflib/issues/1844 Andrius
Bug#1009402: [Debichem-devel] Bug#1009402: Bug#1009402: molmodel: FTBFS: demangle.hpp:23:33: error: ‘string_view’ in namespace ‘std’ does not name a type
Hi, On 2022-05-26 16:24, Adrian Bunk wrote: > The remaining problem can be fixed with the same change as > https://salsa.debian.org/debichem-team/macromoleculebuilder/-/blob/master/debian/patches/drop-CMAKE_CXX_STANDARD.patch Thanks for the suggestion - it worked! Best, Andrius
Bug#1009402: [Debichem-devel] Bug#1009402: molmodel: FTBFS: demangle.hpp:23:33: error: ‘string_view’ in namespace ‘std’ does not name a type
Control: retitle -1 molmodel: FTBFS with tao-pegtl v3 Control: tags -1 + confirmed Control: block -1 by 1009415 Hello, On 2022-04-12 20:47, Lucas Nussbaum wrote: > /usr/include/tao/pegtl/match.hpp:139:15: error: use of deleted function > ‘tao::pegtl::internal::marker M>::marker(tao::pegtl::internal::marker&&) [with Iterator = > tao::pegtl::internal::iterator; tao::pegtl::rewind_mode M = > tao::pegtl::rewind_mode::dontcare]’ molmodel FTBFS with tao-pegtl v3. It used to build fine with v2, but tao-pegtl v3 has recently been uploaded to unstable, hence the failure. This most likely is blocked by #1009415 (gemmi is incompatible with tao-pegtl v3 too). Andrius
Bug#1009415: [Debichem-devel] Bug#1009415: gemmi: FTBFS: cif.hpp:40:30: error: ‘analysis’ in namespace ‘gemmi::cif::pegtl’ does not name a type
Control: retitle -1 gemmi: FTBFS with tao-pegtl v3 Control: tags -1 + confirmed Hello, On 2022-04-12 20:45, Lucas Nussbaum wrote: >> /usr/include/tao/pegtl/match.hpp:57:34: error: incomplete type >> ‘gemmi::cif::rules::str_stop’ used in nested name specifier >>57 | -> decltype( Rule::match( in ) ) >> | ~~~^~ >> make[3]: *** [CMakeFiles/input.dir/build.make:79: >> CMakeFiles/input.dir/src/input.cpp.o] Error 1 gemmi FTBFS with tao-pegtl v3. It used to build fine with v2, but tao-pegtl v3 has recently been uploaded to unstable, hence the failure. Upstream uses embedded fork of tao-pegtl, thus patching might be necessary to fix the bug. Andrius
Bug#1009281: [Debichem-devel] Bug#1009281: Should cinfony be removed?
Hi, On 2022-04-11 01:35, Moritz Muehlenhoff wrote: > Source: cinfony > Version: 1.2-4 > Severity: serious > > Your package came up as a candidate for removal from Debian: > > - Still depends on Python 2 and thus removed from testing since 2019 > - Dead upstream > - No reverse dependencies Incidentally, I was the last to upload this package. Since 2019 there were no uploads, due to aforementioned reasons. I have contemplated filing for RM ever since, but did not get to it. I think it is fine to remove. If Python 3 port ever happens, we can reintroduce the package then. Andrius OpenPGP_signature Description: OpenPGP digital signature
