Bug#1069756: readability: build time test error: lxml.html.clean module is now a separate project lxml_html_clean
Hi Colin, Colin Watson, on 2024-04-26: > Based on https://github.com/buriy/python-readability/issues/179, it > looks as though upstream intends to switch to bleach; I think we can > just patch setup.py in Debian in the meantime though. I'll do that. Looks good to me, thanks for tackling this! Have a nice day, :) -- .''`. Étienne Mollier : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/3, please excuse my verbosity `-on air: Saga - Give 'Em The Money signature.asc Description: PGP signature
Bug#1069691: [Debian-med-packaging] Bug#1069691: libmaus2: FTBFS on arm64: what(): AutoArray failed to allocate 1398102 elements (11184816 bytes)
Control: found -1 2.0.813+ds-3 Hmn, this is annoying. I do not manage to reproduce the error with qemu-user. The test error is reproducible on buildd's real hardware in the meantime[1], or at least on two of the Arm build machines hosted by Conova. There could be something hardware specific. I'd have to check how things go on porterbox next. [1]: https://buildd.debian.org/status/fetch.php?pkg=libmaus2=arm64=2.0.813%2Bds-3=1713977128=0 Have a nice day, :) -- .''`. Étienne Mollier : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/0, please excuse my verbosity `- signature.asc Description: PGP signature
Bug#1069756: readability: build time test error: lxml.html.clean module is now a separate project lxml_html_clean
Source: readability Version: 0.8.1+dfsg1-3 Severity: serious Tags: ftbfs Justification: ftbfs Dear Maintainer, Attempt to run readability tests at build time results in the following error: == ERROR: readability (unittest.loader._FailedTest.readability) -- ImportError: Failed to import test module: readability Traceback (most recent call last): File "/usr/lib/python3.11/unittest/loader.py", line 452, in _find_test_path package = self._get_module_from_name(name) File "/usr/lib/python3.11/unittest/loader.py", line 362, in _get_module_from_name __import__(name) File "/<>/.pybuild/cpython3_3.11/build/readability/__init__.py", line 3, in from .readability import Document File "/<>/.pybuild/cpython3_3.11/build/readability/readability.py", line 11, in from .cleaners import clean_attributes File "/<>/.pybuild/cpython3_3.11/build/readability/cleaners.py", line 3, in from lxml.html.clean import Cleaner File "/usr/lib/python3/dist-packages/lxml/html/clean.py", line 18, in raise ImportError( ImportError: lxml.html.clean module is now a separate project lxml_html_clean. Install lxml[html_clean] or lxml_html_clean directly. As far as I could witness, replacing the python3-lxml build dependency by python3-lxml-html-clean resolved the issue at least for the bulid time test. The package is subject to autodep8 python3 test, which raises that the binary package will also need it dependencies adjusted; this suggests the setup.py would probably need patching so this is addressed appropriately at a larger scale than Debian's. The missing dependency on python3-lxml-html-clean is also causing a regression in offpunk autopkgtest[1], although that could be easily worked around by pulling the missing dependency there. [1]: https://ci.debian.net/packages/o/offpunk/unstable/amd64/44684161/ Have a nice day, :) -- .''`. Étienne Mollier : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/4, please excuse my verbosity `-on air: Mike Oldfield - Lion signature.asc Description: PGP signature
Bug#1066369: obitools: FTBFS: error: implicit declaration of function ‘heapsort’
Hi, Lucas Nussbaum, on 2024-03-13: > > build/temp.linux-x86_64-cpython-311/pyrex/obitools/word/_readindex.c:6320:3: > > error: implicit declaration of function ‘heapsort’ > > [-Werror=implicit-function-declaration] Interesting, if I trust the Debian online manual of heapsort[1], this is a Berkeley function optimized for "almost" sorted arrays. I see two options here: either try to implement the libbsd compatibility layer in cython context, or replace heapsort by qsort[2] (and remove the heapsort function declaration from the .pyx); the two functions look to have compatible argument passing. I would consider implementing the replacement by qsort: this may affect the memory consumption, and possibly performances of obitools; on the other hand I wonder how come the program managed to do the sorting without appropriate function available in the application binary interface in the first place. [1]: https://manpages.debian.org/bookworm/libbsd-dev/heapsort.3bsd.en.html [2]: https://manpages.debian.org/bookworm/manpages-fr-dev/qsort.3.fr.html Have a nice day, :) -- .''`. Étienne Mollier : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/1, please excuse my verbosity `-on air: Genesis - Throwing it All Away signature.asc Description: PGP signature
Bug#1066377: argtable2: FTBFS: arg_int.c:60:12: error: implicit declaration of functions
Control: tag -1 + patch Hi Shachar, I wrapped up a patch to resolve #1066377, the recently caught build failure affecting argtable2. You will find the diff in attachment. Hope this helps, -- .''`. Étienne Mollier : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/2, please excuse my verbosity `- Description: fix multiple implicit function declarations. Author: Étienne Mollier Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1066377 Forwarded: no Last-Update: 2024-03-25 --- This patch header follows DEP-3: http://dep.debian.net/deps/dep3/ --- argtable2-13.orig/src/arg_int.c +++ argtable2-13/src/arg_int.c @@ -29,6 +29,7 @@ /* #endif */ #include "argtable2.h" +#include #include /* local error codes */ --- argtable2-13.orig/tests/fntests.c +++ argtable2-13/tests/fntests.c @@ -1,5 +1,6 @@ #include "../src/argtable2.h" #include +#include /* for memory leak debugging */ #ifdef DMALLOC --- argtable2-13.orig/tests/test_file.c +++ argtable2-13/tests/test_file.c @@ -21,6 +21,7 @@ #include "../src/argtable2.h" #include +#include /* for memory leak debugging */ #ifdef DMALLOC signature.asc Description: PGP signature
Bug#1066485: [Debian-med-packaging] Bug#1066485: volpack: diff for NMU version 1.0b3-9.1
Hi Andrey, Andrey Rakhmatullin, on 2024-03-17: > I've prepared an NMU for volpack (versioned as 1.0b3-9.1) and > uploaded it to DELAYED/4. Please feel free to tell me if I > should delay it longer. Thank you for helping out with tackling these bugs, I reviewed through your changes, with which I agree, and inlined them in the VCS, so they will be preserved on further uploads. Please feel even free to reduce the delay to 0, if you like. Have a nice day, :) -- .''`. Étienne Mollier : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/4, please excuse my verbosity `-on air: Jean-Luc Ponty - Upon The Wings Of Music signature.asc Description: PGP signature
Bug#1067035: apache2-bin: rebuild for the 64-bit time_t migration is uninstallable
Hi Simon, Simon McVittie, on 2024-03-17: > I believe the attached patches should fix this (untested). After fixing > this in apr-util, apache2 will need a binNMU (or a re-upload). Thanks for your patches, I confirm they resolve the dependency issue after a rebuild of apache2. libaprutil164 without 't' is no more present in the dependencies. Have a nice day, :) -- .''`. Étienne Mollier : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/1, please excuse my verbosity `- signature.asc Description: PGP signature
Bug#1067035: apache2-bin: rebuild for the 64-bit time_t migration is uninstallable
Package: apache2-bin Version: 2.4.58-1+b2 Severity: serious Justification: uninstallable Dear Maintainer, Attempting to upgrade apache2-bin from rebuild 2.4.58-1+b1 to the rebuild 2.4.58-1+b2 leads to the following error: $ sudo apt upgrade apache2-bin Reading package lists... Done Building dependency tree... Done Reading state information... Done Calculating upgrade... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: apache2-bin : Depends: libaprutil164 (>= 1.2.7+dfsg) but it is not installable E: Broken packages libaprutil164 (note the missing 't' for "t64") is not available in unstable. The dependency looks typoed and duplicated, as libaprutil1t64 (>= 1.6.0) is also present as needed in the Depends field, Otherwise, have a nice Sunday, :) Étienne. -- Package-specific info: -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.7.9-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=C.UTF-8, LC_CTYPE=C.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 apache2-bin depends on: ii libapr1t64 [libapr1] 1.7.2-3.2 ii libaprutil1-dbd-sqlite3 1.6.3-1.1+b1 ii libaprutil1-ldap 1.6.3-1.1+b1 ii libaprutil1t64 [libaprutil1] 1.6.3-1.1+b1 ii libbrotli11.1.0-2+b3 ii libc6 2.37-15.1 ii libcrypt1 1:4.4.36-4 ii libcurl4t64 [libcurl4]8.6.0-4 ii libjansson4 2.14-2+b2 ii libldap-2.5-0 2.5.16+dfsg-2 ii liblua5.3-0 5.3.6-2+b2 ii libnghttp2-14 1.59.0-1+b1 ii libpcre2-8-0 10.42-4+b1 ii libssl3t64 [libssl3] 3.1.5-1.1 ii libxml2 2.9.14+dfsg-1.3+b2 ii perl 5.38.2-3.2 ii zlib1g1:1.3.dfsg-3.1 apache2-bin recommends no packages. Versions of packages apache2-bin suggests: pn apache2-doc pn apache2-suexec-pristine | apache2-suexec-custom ii firefox-esr [www-browser]115.8.0esr-1+b1 ii lynx [www-browser] 2.9.0rel.0-2+b1 ii surf [www-browser] 2.1+git20221016-6+b1 ii w3m [www-browser]0.5.3+git20230121-2+b3 Versions of packages apache2 depends on: ii apache2-data 2.4.58-1 ii apache2-utils2.4.58-1+b1 ii init-system-helpers 1.66 ii media-types 10.1.0 ii perl 5.38.2-3.2 ii procps 2:4.0.4-4 Versions of packages apache2 recommends: ii ssl-cert 1.1.2 Versions of packages apache2 suggests: pn apache2-doc pn apache2-suexec-pristine | apache2-suexec-custom ii firefox-esr [www-browser]115.8.0esr-1+b1 ii lynx [www-browser] 2.9.0rel.0-2+b1 ii surf [www-browser] 2.1+git20221016-6+b1 ii w3m [www-browser]0.5.3+git20230121-2+b3 Versions of packages apache2-bin is related to: ii apache2 2.4.58-1+b1 ii apache2-bin 2.4.58-1+b1 -- no debconf information -- .''`. Étienne Mollier : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/4, please excuse my verbosity `-on air: Antony Kalugin - Key signature.asc Description: PGP signature
Bug#1065976: python-levenshtein: FTBFS on arm{el,hf}: Levenshtein/_levenshtein.c:749:15: error: implicit declaration of function ‘PyUnicode_AS_UNICODE’; did you mean ‘PyUnicode_AsUCS4’? [-Werror=impli
Hi, Sebastian Ramacher, on 2024-03-10: > Levenshtein/_levenshtein.c:749:15: error: implicit declaration of function > ‘PyUnicode_AS_UNICODE’; did you mean ‘PyUnicode_AsUCS4’? > [-Werror=implicit-function-declaration] > 749 | string1 = PyUnicode_AS_UNICODE(arg1); This looks to be a duplicate of an initial ftbfs issue I looked up this morning. Ultimately it would be fixed by the latest upstream version of python-levenshtein, but for this to be doable, rapidfuzz-cpp needs to make it to the archive first. Julian pushed rapidfuzz-cpp some time ago to the New queue, thanks! Have a nice day, :) -- .''`. Étienne Mollier : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/4, please excuse my verbosity `- signature.asc Description: PGP signature
Bug#1064147: ftbfs: test failures affecting Bio.SeqIO.SeqXmlIO
Control: severity -1 normal I reduce the severity. The version 1.83+dfsg-1 recently uploaded skips the affected tests, due to lack of better options. I leave the issue open in case someone comes up with a more appropriate way to resolve this, but the situation is not serious anymore. -- .''`. Étienne Mollier : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/1, please excuse my verbosity `-on air: Fates Warning - From The Rooftops signature.asc Description: PGP signature
Bug#1064147: ftbfs: test failures affecting Bio.SeqIO.SeqXmlIO
So, following discutions with upstream, and quite some investigation, this turned out to be caused by the migration of expat from version 2.5 to 2.6. The newer version looks to have had to introduce breaking changes in order to be able to fix a security vulnerability. When looking into expat migration excuses[1], I noted that there were also test failures affecting Python's xml module[2]. Then, I had a lookup at open CPython issues, which suggest a change to address the build failure has landed[3] and will be ready for upcoming interpreter versions. That being said, looking closely at the patch, it seems the direction taken was to adjust the test suite to ignore the affected cases. There don't seem to have been any changes to the core logic of the xml module. This suggests it may be necessary to skip the affected tests, at least for now. Those are only two failures among dozens of tests, which suggest the SeqXmlIO is in otherwise mostly working conditions. [1]: https://qa.debian.org/excuses.php?package=expat [2]: https://ci.debian.net/packages/p/python3.12/testing/amd64/43764480/ [3]: https://github.com/python/cpython/pull/115289/files Now pondering a version that has a chance to migrate, -- .''`. Étienne Mollier : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/2, please excuse my verbosity `-on air: Genesis - Turn It on Again signature.asc Description: PGP signature
Bug#1062403: marked as done (freecontact: NMU diff for 64-bit time_t transition)
From mwhud...@debian.org: > This has been uploaded now, but unfortunately I forgot to include the bug > number in the changelog. Apologies. No worries, I happen to trip on this carpet from time to time. NMU is acknowledged in the VCS, thanks for the work on the 64-bit time_t transition! Have a nice day, :) -- .''`. Étienne Mollier : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/1, please excuse my verbosity `- signature.asc Description: PGP signature
Bug#1062757: [Debian-med-packaging] Bug#1062757: odil: NMU diff for 64-bit time_t transition
Benjamin Drung, on 2024-02-29: > Please find attached a final version of this patch for the time_t > transition. This patch is being uploaded to unstable. NMU acknowledged, thanks! :) -- .''`. Étienne Mollier : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/1, please excuse my verbosity `- signature.asc Description: PGP signature
Bug#1062525: [Debian-med-packaging] Bug#1062525: eegdev: NMU diff for 64-bit time_t transition
mwhud...@fastmail.fm, on 2024-02-28: > Please find attached a final version of this patch for the time_t > transition. This patch is being uploaded to unstable. Thanks Michael, your NMU is inlined in Salsa. Have a nice day, :) -- .''`. Étienne Mollier : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/1, please excuse my verbosity `- signature.asc Description: PGP signature
Bug#1062316: libgkarrays: NMU diff for 64-bit time_t transition
Benjamin Drung, on 2024-02-29: > On Wed, 28 Feb 2024 20:12:53 +0100 =?utf-8?Q?=C3=89tienne?= Mollier > wrote: > > Benjamin Drung, on 2024-02-28: > > > Please find attached a final version of this patch for the time_t > > > transition. This patch is being uploaded to unstable. > > > > NMU acknowledged, thank you! :) > > The upload was rejected, because the the version number 2.1.0+dfsg-4.1 > was used for the experimental upload. So I had to bump the version > number to 2.1.0+dfsg-4.2. Thanks for the notice, I updated the VCS tree accordingly. Have a nice day, :) -- .''`. Étienne Mollier : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/1, please excuse my verbosity `- signature.asc Description: PGP signature
Bug#1062942: [Debian-med-packaging] Bug#1062942: mmlib: NMU diff for 64-bit time_t transition
Benjamin Drung, on 2024-02-28: > Please find attached a final version of this patch for the time_t > transition. This patch is being uploaded to unstable. NMU acknowledged, thank you! :) -- .''`. Étienne Mollier : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/1, please excuse my verbosity `-on air: Pink Floyd - Stay signature.asc Description: PGP signature
Bug#1062316: [Debian-med-packaging] Bug#1062316: libgkarrays: NMU diff for 64-bit time_t transition
Benjamin Drung, on 2024-02-28: > Please find attached a final version of this patch for the time_t > transition. This patch is being uploaded to unstable. NMU acknowledged, thank you! :) -- .''`. Étienne Mollier : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/1, please excuse my verbosity `-on air: The Gift - Far Stranger signature.asc Description: PGP signature
Bug#1062602: [Debian-med-packaging] Bug#1062602: librcsb-core-wrapper: NMU diff for 64-bit time_t transition
Benjamin Drung, on 2024-02-28: > Please find attached a final version of this patch for the time_t > transition. This patch is being uploaded to unstable. NMU acknowledged, thank you! :) -- .''`. Étienne Mollier : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/1, please excuse my verbosity `-on air: Gentle Giant - Free Hand (Steven Wilson 2021 R… signature.asc Description: PGP signature
Bug#1061931: [Debian-med-packaging] Bug#1061931: biosquid: NMU diff for 64-bit time_t transition
Steve Langasek, on 2024-02-28: > Please find attached a final version of this patch for the time_t > transition. This patch is being uploaded to unstable. NMU acknowledged, thank you! :) -- .''`. Étienne Mollier : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/1, please excuse my verbosity `-on air: Gentle Giant - Free Hand (Steven Wilson 2021 R… signature.asc Description: PGP signature
Bug#1062612: [Debian-med-packaging] Bug#1062612: librostlab: NMU diff for 64-bit time_t transition
Benjamin Drung, on 2024-02-28: > Please find attached a final version of this patch for the time_t > transition. This patch is being uploaded to unstable. NMU acknowledged, thank you! :) -- .''`. Étienne Mollier : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/1, please excuse my verbosity `- signature.asc Description: PGP signature
Bug#1062427: [Debian-med-packaging] Bug#1062427: ghmm: NMU diff for 64-bit time_t transition
Steve Langasek, on 2024-02-28: > Please find attached a final version of this patch for the time_t > transition. This patch is being uploaded to unstable. NMU acknowledged, thank you! :) -- .''`. Étienne Mollier : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/1, please excuse my verbosity `- signature.asc Description: PGP signature
Bug#1062619: [Debian-med-packaging] Bug#1062619: libsbml: NMU diff for 64-bit time_t transition
Benjamin Drung, on 2024-02-28: > Please find attached a final version of this patch for the time_t > transition. This patch is being uploaded to unstable. NMU acknowledged, thank you! :) -- .''`. Étienne Mollier : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/1, please excuse my verbosity `-on air: The Flower Kings - A New Species signature.asc Description: PGP signature
Bug#1062417: [Debian-med-packaging] Bug#1062417: libmialm: NMU diff for 64-bit time_t transition
Benjamin Drung, on 2024-02-28: > Please find attached a final version of this patch for the time_t > transition. This patch is being uploaded to unstable. Acknowledged, thank you! :) -- .''`. Étienne Mollier : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/1, please excuse my verbosity `-on air: Widow's Walk - Moonrise signature.asc Description: PGP signature
Bug#1062418: [Debian-med-packaging] Bug#1062418: libminc: NMU diff for 64-bit time_t transition
Benjamin Drung, on 2024-02-28: > Please find attached a final version of this patch for the time_t > transition. This patch is being uploaded to unstable. NMU acknowledged, thanks! :) -- .''`. Étienne Mollier : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/1, please excuse my verbosity `-on air: Amberian Dawn - Symphony Nr. 1, Part 1 - The W… signature.asc Description: PGP signature
Bug#1062416: [Debian-med-packaging] Bug#1062416: libmems: NMU diff for 64-bit time_t transition
Benjamin Drung, on 2024-02-28: > Please find attached a final version of this patch for the time_t > transition. This patch is being uploaded to unstable. Acknowledged in the VCS, thank you for the transition! :) -- .''`. Étienne Mollier : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/1, please excuse my verbosity `-on air: Widow's Walk - Moonrise signature.asc Description: PGP signature
Bug#1064147: ftbfs: test failures affecting Bio.SeqIO.SeqXmIIO
Control: forwarded -1 https://github.com/biopython/biopython/issues/4640 Control: tags -1 + sid Control: tags -1 - testing I'm dry on even pinpointing what change is causing Biopython 1.81 to fail those tests, maybe upstream will have a better idea. If nothing, there remains the option to skip the affected tests and reduce the bug severity, but this is not ideal. We'll see how things go, -- .''`. Étienne Mollier : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/1, please excuse my verbosity `- signature.asc Description: PGP signature
Bug#1064157: [Debian-med-packaging] Bug#1064157: jellyfish: NMU diff for 64-bit time_t transition
Lukas Märdian, on 2024-02-28: > Please find attached a final version of this patch for the time_t > transition. This patch is being uploaded to unstable. NMU patch acknowledged, thanks! Have a nice day, :) -- .''`. Étienne Mollier : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/1, please excuse my verbosity `- signature.asc Description: PGP signature
Bug#1062310: [Debian-med-packaging] Bug#1062310: libgdf: NMU diff for 64-bit time_t transition
Hi Benjamin, Benjamin Drung, on 2024-02-28: > Please find attached a final version of this patch for the time_t > transition. This patch is being uploaded to unstable. Thanks for your work on the 64-bit time_t transition, I pushed your changes in the packaging repository to avoid accidental undoing of the change in the future. Have a nice day, :) -- .''`. Étienne Mollier : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/1, please excuse my verbosity `-on air: Harmony - Rain signature.asc Description: PGP signature
Bug#1062037: camp: NMU diff for 64-bit time_t transition
Steve Langasek, on 2024-02-28: > Please find attached a final version of this patch for the time_t > transition. This patch is being uploaded to unstable. NMU acknowledged in the VCS. Thank you for your work on the transition! Have a nice day, :) -- .''`. Étienne Mollier : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/1, please excuse my verbosity `-on air: Gentle Giant - Just The Same signature.asc Description: PGP signature
Bug#1062022: [Debian-med-packaging] Bug#1062022: dcmtk: NMU diff for 64-bit time_t transition
Hi Michael, mwhud...@fastmail.fm, on 2024-02-28: > Please find attached a final version of this patch for the time_t > transition. This patch is being uploaded to unstable. Thanks for moving forwards the 64-bit time_t transition! Your NMU is injected in the packaging tree, so it won't risk being undone by accident. Have a nice day, :) -- .''`. Étienne Mollier : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/1, please excuse my verbosity `-on air: Arena - Returning The Curse signature.asc Description: PGP signature
Bug#1062443: [Debian-med-packaging] Bug#1062443: igraph: NMU diff for 64-bit time_t transition
Lukas Märdian, on 2024-02-28: > Please find attached a final version of this patch for the time_t > transition. This patch is being uploaded to unstable. NMU acknowledged in the VCS. Thank you! Have a nice day, :) -- .''`. Étienne Mollier : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/1, please excuse my verbosity `-on air: Michael Manring - Fire Sermon signature.asc Description: PGP signature
Bug#1062049: [Debian-med-packaging] Bug#1062049: gdcm: NMU diff for 64-bit time_t transition
Hi Steve, Steve Langasek, on 2024-02-28: > Please find attached a final version of this patch for the time_t > transition. This patch is being uploaded to unstable. NMU injected in the packaging tree, thanks for your work on the massive 64-bit time_t transition! Have a nice day, :) -- .''`. Étienne Mollier : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/1, please excuse my verbosity `-on air: Schysma - Time Man signature.asc Description: PGP signature
Bug#1062201: [Debian-med-packaging] Bug#1062201: gwyddion: NMU diff for 64-bit time_t transition
Lukas Märdian, on 2024-02-28: > Please find attached a final version of this patch for the time_t > transition. This patch is being uploaded to unstable. Acknowledged in the VCS, thank you for your work on the 64-bit time_t transition! Have a nice day, :) -- .''`. Étienne Mollier : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/1, please excuse my verbosity `-on air: Assignment - Electric City (Home Of The Machin… signature.asc Description: PGP signature
Bug#1062344: [Debian-med-packaging] Bug#1062344: htslib: NMU diff for 64-bit time_t transition
Hi Lukas, Lukas Märdian, on 2024-02-28: > Please find attached a final version of this patch for the time_t > transition. This patch is being uploaded to unstable. Thanks for your work on the 64-bit time_t transission, I inlined your work in the packaging development tree so the package rename does not go undone by accident. Have a nice day, :) -- .''`. Étienne Mollier : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/1, please excuse my verbosity `-on air: Caravan - Frozen Rose (I Don't Know Its Name A… signature.asc Description: PGP signature
Bug#1061208: Please upgrade to llvm-toolchain-17
Hi Christian, Christian Kastner, on 2024-02-26: > Hi Sebastian, > > writing to you as you bumped the severity to 'serious': could the rT > please give us an extension on the autoremoval for this particular bug. If that helps, the autoremoval timer is reset each time the RC critical bug triggering the autoremoval is updated, e.g. when reporting an evolution of the situation in a new comment. Have a nice day, :) -- .''`. Étienne Mollier : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/2, please excuse my verbosity `- signature.asc Description: PGP signature
Bug#1046029: double build failures in libvitacilina-perl
On both #1046029 and #1049522, the error shows: > Error reading from file 'META.yml': UTF-8 "\xA1" does not map to Unicode > at /usr/share/perl5/Module/Install/Admin/Metadata.pm line 14. > make[1]: *** [Makefile:832: realclean] Error 25 This is caused by the YAML parser to choke on the inverted exclamation mark in the abstract which should be valid UTF-8[1]: $ echo -e '\xC2\xA1' ¡ It looks like something in the parsing does not capture the C2A1 properly, and jumps straight to the A1, not sure what yet. It could be an issue in YAML::Tiny, or in perl (although I would have expected much more fallouts if the latter). [1]: https://www.utf8-chartable.de/ I will move on to lower hanging fruits for now, ;) -- .''`. Étienne Mollier : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/5, please excuse my verbosity `- signature.asc Description: PGP signature
Bug#1062344: htslib: diff for 64-bit time_t transition, for htslib 1.19
Hi Graham,
I migrated htslib 1.19 to unstable in the past weekend (and in
turn it migrated to testing this morning). The experimental
distribution being now available, I am preparing an upload with
your changes for the migration to the 64-bit time_t. You will
find the new debdiff in attachment; normally there should be no
surprises here, but just in case.
In hope this helps,
--
.''`. Étienne Mollier
: :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da
`. `' sent from /dev/pts/1, please excuse my verbosity
`-on air: Crippled Black Phoenix - Bonefire
diff -Nru htslib-1.19+ds/debian/changelog htslib-1.19+ds/debian/changelog
--- htslib-1.19+ds/debian/changelog 2024-02-17 11:42:52.0 +0100
+++ htslib-1.19+ds/debian/changelog 2024-02-20 19:55:09.0 +0100
@@ -1,3 +1,13 @@
+htslib (1.19+ds-1+exp1) experimental; urgency=medium
+
+ * Rename libraries for 64-bit time_t transition.
+This change was initially proposed as NMU, but it didn't make it to
+experimental due to a conflicting version already present at the time
+of the upload. See also #1062344.
+Thanks to Graham Inggs for the initial version and work on 64-bit time_t
+
+ -- Étienne Mollier Tue, 20 Feb 2024 19:55:09 +0100
+
htslib (1.19+ds-1) unstable; urgency=medium
* Migrate htslib 1.19 from experimental to unstable.
diff -Nru htslib-1.19+ds/debian/control htslib-1.19+ds/debian/control
--- htslib-1.19+ds/debian/control 2023-12-15 17:43:46.0 +0100
+++ htslib-1.19+ds/debian/control 2024-02-20 19:55:09.0 +0100
@@ -21,18 +21,20 @@
Homepage: https://github.com/samtools/htslib
Rules-Requires-Root: no
-Package: libhts3
+Package: libhts3t64
+Provides: ${t64:Provides}
Architecture: any
Multi-Arch: same
Section: libs
Depends: ${misc:Depends},
${shlibs:Depends}
Pre-Depends: ${misc:Pre-Depends}
-Breaks: libtabixpp (<< 1.0.0-5~),
+Breaks: libhts3 (<< ${source:Version}),
+libtabixpp (<< 1.0.0-5~),
libhts-dev (<< 1.13~),
samtools (<< 1.17~),
ivar (<< 1.3.1~)
-Replaces: libhts-dev (<< 1.13~)
+Replaces: libhts3, libhts-dev (<< 1.13~)
Description: C library for high-throughput sequencing data formats
HTSlib is an implementation of a unified C library for accessing common file
formats, such as SAM (Sequence Alignment/Map), CRAM and VCF (Variant Call
@@ -48,7 +50,7 @@
Architecture: any
Multi-Arch: same
Section: libdevel
-Depends: libhts3 (= ${binary:Version}),
+Depends: libhts3t64 (= ${binary:Version}),
libcurl4-gnutls-dev,
libdeflate-dev,
liblzma-dev,
diff -Nru htslib-1.19+ds/debian/libhts3.install
htslib-1.19+ds/debian/libhts3.install
--- htslib-1.19+ds/debian/libhts3.install 2022-10-19 16:55:31.0
+0200
+++ htslib-1.19+ds/debian/libhts3.install 1970-01-01 01:00:00.0
+0100
@@ -1,3 +0,0 @@
-usr/lib/${DEB_HOST_MULTIARCH}/libhts.so.* usr/lib/${DEB_HOST_MULTIARCH}
-usr/lib/${DEB_HOST_MULTIARCH}/htslib usr/lib/${DEB_HOST_MULTIARCH}
-usr/share/man/man5/* usr/share/man/man5
diff -Nru htslib-1.19+ds/debian/libhts3.manpages
htslib-1.19+ds/debian/libhts3.manpages
--- htslib-1.19+ds/debian/libhts3.manpages 2022-07-03 09:14:15.0
+0200
+++ htslib-1.19+ds/debian/libhts3.manpages 1970-01-01 01:00:00.0
+0100
@@ -1 +0,0 @@
-htslib-s3-plugin.7
diff -Nru htslib-1.19+ds/debian/libhts3.symbols
htslib-1.19+ds/debian/libhts3.symbols
--- htslib-1.19+ds/debian/libhts3.symbols 2023-12-15 22:15:41.0
+0100
+++ htslib-1.19+ds/debian/libhts3.symbols 1970-01-01 01:00:00.0
+0100
@@ -1,929 +0,0 @@
-libhts.so.3 libhts3 #MINVER#
-* Build-Depends-Package: libhts-dev
- HTSLIB_1.0@HTSLIB_1.0 1.17
- HTSLIB_1.10@HTSLIB_1.10 1.17
- HTSLIB_1.11@HTSLIB_1.11 1.17
- HTSLIB_1.12@HTSLIB_1.12 1.17
- HTSLIB_1.13@HTSLIB_1.13 1.17
- HTSLIB_1.14@HTSLIB_1.14 1.17
- HTSLIB_1.15@HTSLIB_1.15 1.17
- HTSLIB_1.16@HTSLIB_1.16 1.17
- HTSLIB_1.17@HTSLIB_1.17 1.17
- HTSLIB_1.18@HTSLIB_1.18 1.18
- HTSLIB_1.1@HTSLIB_1.1 1.17
- HTSLIB_1.2.1@HTSLIB_1.2.1 1.17
- HTSLIB_1.3@HTSLIB_1.3 1.17
- HTSLIB_1.4@HTSLIB_1.4 1.17
- HTSLIB_1.5@HTSLIB_1.5 1.17
- HTSLIB_1.6@HTSLIB_1.6 1.17
- HTSLIB_1.7@HTSLIB_1.7 1.17
- HTSLIB_1.9@HTSLIB_1.9 1.17
- bam_aux2A@HTSLIB_1.0 1.17
- bam_aux2Z@HTSLIB_1.0 1.17
- bam_aux2f@HTSLIB_1.0 1.17
- bam_aux2i@HTSLIB_1.0 1.17
- bam_auxB2f@HTSLIB_1.4 1.17
- bam_auxB2i@HTSLIB_1.4 1.17
- bam_auxB_len@HTSLIB_1.4 1.17
- bam_aux_append@HTSLIB_1.0 1.17
- bam_aux_del@HTSLIB_1.0 1.17
- bam_aux_first@HTSLIB_1.17 1.17
- bam_aux_get@HTSLIB_1.0 1.17
- bam_aux_next@HTSLIB_1.17 1.17
- bam_aux_remove@HTSLIB_1.17 1.17
- bam_aux_update_array@HTSLIB_1.9 1.17
- bam_aux_update_float@HTSLIB_1.9 1.17
- bam_aux_update_int@HTSLIB_1.9 1.17
- bam_aux_update_str@HTSLIB_1.4 1.17
- bam_cigar2qlen@HTSLIB_1.0 1.17
- bam_cigar2rlen@HTSLIB_1.0 1.17
- bam_cigar_table@HTSLIB_1.10 1.17
- bam
Bug#1064209: offpunk: opnk.py:52: SyntaxWarning: invalid escape sequence '\%'
Control: forwarded -1 https://lists.sr.ht/~lioploum/offpunk-devel/patches/49706 Control: tag -1 + patch upstream Hi Paul, Paul Wise, on 2024-02-18: > I got a warning when upgrading offpunk: > >Preparing to unpack .../archives/offpunk_2.2-1_all.deb ... >Unpacking offpunk (2.2-1) over (2.1-1) ... >Setting up offpunk (2.2-1) ... >/usr/lib/python3/dist-packages/opnk.py:52: SyntaxWarning: invalid escape > sequence '\%' > less_prompt = "page %%d/%%D- lines %%lb/%%L - %%Pb\%%" Thank you for the report, I sent a mitigation upstream so this should be fixed in upcoming versions. Have a nice day, :) -- .''`. Étienne Mollier : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/1, please excuse my verbosity `- signature.asc Description: PGP signature
Bug#1064147: ftbfs: test failures affecting Bio.SeqIO.SeqXmIIO
Source: python-biopython Version: 1.81+dfsg-3 Severity: serious Tags: ftbfs Justification: ftbfs While trying to pinpoint the root cause of test failures in the packaging attempt of Biopython 1.83, I eventually realized that the version 1.81 of Biopython is also affected by the same issues. The relevant part of the test log looks like: == ERROR: test_embl7 (test_SeqIO.TestSeqIO.test_embl7) -- Traceback (most recent call last): File "/<>/.pybuild/cpython3_3.11/build/Tests/test_SeqIO.py", line 3388, in test_embl7 self.perform_test( File "/<>/.pybuild/cpython3_3.11/build/Tests/test_SeqIO.py", line 626, in perform_test self.check_simple_write_read( File "/<>/.pybuild/cpython3_3.11/build/Tests/test_SeqIO.py", line 363, in check_simple_write_read records2 = list(SeqIO.parse(handle=handle, format=fmt)) File "/<>/.pybuild/cpython3_3.11/build/Bio/SeqIO/Interfaces.py", line 72, in __next__ return next(self.records) ^^ File "/<>/.pybuild/cpython3_3.11/build/Bio/SeqIO/SeqXmlIO.py", line 447, in iterate parser.close() File "/usr/lib/python3.11/xml/sax/expatreader.py", line 240, in close self.feed(b"", isFinal=True) File "/usr/lib/python3.11/xml/sax/expatreader.py", line 217, in feed self._parser.Parse(data, isFinal) File "../Modules/pyexpat.c", line 416, in StartElement File "/usr/lib/python3.11/xml/sax/expatreader.py", line 369, in start_element_ns self._cont_handler.startElementNS(pair, None, File "/<>/.pybuild/cpython3_3.11/build/Bio/SeqIO/SeqXmlIO.py", line 163, in startEntryFieldElement return self.startPropertyElement(attrs) File "/<>/.pybuild/cpython3_3.11/build/Bio/SeqIO/SeqXmlIO.py", line 339, in startPropertyElement record = self.records[-1] IndexError: list index out of range == ERROR: test_genbank8 (test_SeqIO.TestSeqIO.test_genbank8) -- Traceback (most recent call last): File "/<>/.pybuild/cpython3_3.11/build/Tests/test_SeqIO.py", line 2785, in test_genbank8 self.perform_test( File "/<>/.pybuild/cpython3_3.11/build/Tests/test_SeqIO.py", line 626, in perform_test self.check_simple_write_read( File "/<>/.pybuild/cpython3_3.11/build/Tests/test_SeqIO.py", line 363, in check_simple_write_read records2 = list(SeqIO.parse(handle=handle, format=fmt)) File "/<>/.pybuild/cpython3_3.11/build/Bio/SeqIO/Interfaces.py", line 72, in __next__ return next(self.records) ^^ File "/<>/.pybuild/cpython3_3.11/build/Bio/SeqIO/SeqXmlIO.py", line 447, in iterate parser.close() File "/usr/lib/python3.11/xml/sax/expatreader.py", line 240, in close self.feed(b"", isFinal=True) File "/usr/lib/python3.11/xml/sax/expatreader.py", line 217, in feed self._parser.Parse(data, isFinal) File "../Modules/pyexpat.c", line 416, in StartElement File "/usr/lib/python3.11/xml/sax/expatreader.py", line 369, in start_element_ns self._cont_handler.startElementNS(pair, None, File "/<>/.pybuild/cpython3_3.11/build/Bio/SeqIO/SeqXmlIO.py", line 163, in startEntryFieldElement return self.startPropertyElement(attrs) File "/<>/.pybuild/cpython3_3.11/build/Bio/SeqIO/SeqXmlIO.py", line 339, in startPropertyElement record = self.records[-1] IndexError: list index out of range I haven't checked but I heavily suspect that this is causing also autopkgtest failures. For information, -- .''`. Étienne Mollier : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/0, please excuse my verbosity `- signature.asc Description: PGP signature
Bug#1064134: ITP: python-nixio -- NIX data model implementation in pure Python
Package: wnpp Severity: wishlist Owner: Étienne Mollier X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: python-nixio Version : 1.5.3 Upstream Contact: Jan Grewe * URL : * License : BDS-3-Clauses Programming Lang: Python Description : NIX data model implementation in pure Python The NIXIO module is the native Python re-implementation of the NIX C++ library for the NIX data model. . The NIX data model allows to store fully annotated scientific datasets, i.e. the data together with its metadata within the same container. Our aim is to achieve standardization by providing a common/generic data structure for a multitude of data types. . The current implementations store the actual data using the HDF5 file format as a storage backend. This package is a new dependency required by neo 0.13.0. I consider maintaining it under the Debian Python Team umbrella. Have a nice day, :) -- .''`. Étienne Mollier : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/2, please excuse my verbosity `- signature.asc Description: PGP signature
Bug#1063542: python-parsl-doc: please make the build reproducible
James Addison, on 2024-02-10: > I'll also forward the same change to upstream, in the hope that we may > be able to drop the patch from the packaging in future. That would be useful. Patch rebase tends to cause quite some friction on the long run with newer upstream versions. It shouldn't hurt informing upstream of the availability of the change, in case they are sensible to build reproducibility issue. Have a nice day, :) -- .''`. Étienne Mollier : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/1, please excuse my verbosity `- signature.asc Description: PGP signature
Bug#1063542: python-parsl-doc: please make the build reproducible
Hi James, James Addison, on 2024-02-09: > When Sphinx builds documentation, by default it will emit a Python repr() of > the manager_config argument, causing the hostname of the build host to be > included. > > We can solve that by instructing the Sphinx autodoc extension to retain the > textual representation of argument lists as they are found in the source > code, instead of evaluated and repr'd equivalents. Thank you thank you thank you! This reproducibility issue has been nagging me from day zero. Despite trying to filter out the host name, it ended up in the search indexer, sliced by dashes when the name contained some, preventing sed passes to resolve the issue. I see to include your patch in the next python-parsl upload; this will also allow some cleanup in the d/rules. Have a nice day, :) -- .''`. Étienne Mollier : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/5, please excuse my verbosity `-on air: AndersonPonty Band - Time and a Word signature.asc Description: PGP signature
Bug#1044079: augur 24 still ftbfs against pandas 2.1.4
Control: reopen -1 I must have mistaken something about pandas versions when uploading augur 24.0.0, because the error is still there and is now causing ftbfs again with at least pandas 2.1.4. This is still the same error in the same test: self = capsys = <_pytest.capture.CaptureFixture object at 0x7fc3d81d59d0> def test_fix_dates(self, capsys): full_date = "4-5-2020" > assert parse.fix_dates(full_date) == "2020-05-04" tests/test_parse.py:14: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ d = '4-5-2020', dayfirst = True def fix_dates(d, dayfirst=True): ''' attempt to parse a date string using pandas date parser. If ambiguous, the argument 'dayfirst' determines whether month or day is assumed to be the first field. Incomplete dates will be padded with XX. On failure to parse the date, the function will return the input. ''' try: from pandas.core.tools.datetimes import parsing > results = parsing.parse_time_string(d, dayfirst=dayfirst) E AttributeError: module 'pandas._libs.tslibs.parsing' has no attribute 'parse_time_string' Too bad things looked promising, -- .''`. Étienne Mollier : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/3, please excuse my verbosity `- signature.asc Description: PGP signature
Bug#1022797: librocm-smi-dev: find_package(rocm_smi) fails due to missing liboam
Control: severity -1 wishlist The package is uploaded. I reduce the severity to a wishlist item, as we will have a workaround in place. Have a nice day, :) -- .''`. Étienne Mollier : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/1, please excuse my verbosity `-on air: Different Strings - The Abyss signature.asc Description: PGP signature
Bug#1022797: librocm-smi-dev: find_package(rocm_smi) fails due to missing liboam
Hi Cory, Cordell Bloor, on 2024-02-01: > Could we add 'Recommends: liboam-dev' to librocm-smi-dev until the CMake > config in the latter is modified to make liboam-dev optional? There has been > no progress on this issue for some time, so I think it may be worth applying > that mitigation. I reread through the bug entry, and I agree. If there are no blockers or objections, I'm also considering taking that opportunity to migrate the version 5.7 to unstable. Have a nice day, :) -- .''`. Étienne Mollier : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/3, please excuse my verbosity `-on air: Glass Hammer - If The Stars signature.asc Description: PGP signature
Bug#1062344: [Debian-med-packaging] Bug#1062344: htslib: NMU diff for 64-bit time_t transition
Hi Graham, Thanks for your (and the others) titan work on moving this transition forward. \o/ > diff -Nru htslib-1.18+ds/debian/changelog htslib-1.18+ds/debian/changelog > --- htslib-1.18+ds/debian/changelog 2023-11-07 18:46:30.0 + > +++ htslib-1.18+ds/debian/changelog 2024-02-01 05:58:50.0 + > @@ -1,3 +1,10 @@ > +htslib (1.18+ds-1.1) experimental; urgency=medium ^^^ There is an htslib 1.19 upload lingering in experimental, that I did some time ago to make sure I was not throwing entropy to too many reverse dependencies. I'm afraid it might have voided your NMU. Would it be more helpful to adjust the patch to the newer htslib version, or do you prefer the 1.19 to be reverted for now until the time_t 64-bit transition goes through? I may be able to upload myself if you're busy somewhere else, I'm just unsure of the way forward. Have a nice day, :) -- .''`. Étienne Mollier : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/5, please excuse my verbosity `-on air: Agusa - Under bar himmel signature.asc Description: PGP signature
Bug#1060965: q2-feature-classifier: FTBFS due to qiime AttributeError: module 'bibtexparser' has no attribute 'bparser'
Control: reassign -1 src:qiime 2022.11.1-2 Control: affects -1 + q2-feature-classifier Control: merge -1 1060987 This is another manifestation of #1060987, this time affecting q2-feature-classifier: > /usr/lib/python3/dist-packages/qiime2/core/cite.py:26: in load > parser = bp.bparser.BibTexParser() > E AttributeError: module 'bibtexparser' has no attribute 'bparser' Have a nice day, :) -- .''`. Étienne Mollier : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/2, please excuse my verbosity `- signature.asc Description: PGP signature
Bug#1060987: q2cli: FTBFS: AttributeError: module 'bibtexparser' has no attribute 'bparser'
Control: reassign -1 src:qiime/2022.11.1-2 Control: retitle -1 qiime: FTBFS: AttributeError: module 'bibtexparser' has no attribute 'bparser' Control: affects -1 + q2cli This looks to be the main issue: > /usr/lib/python3/dist-packages/qiime2/core/cite.py:26: in load > parser = bp.bparser.BibTexParser() > E AttributeError: module 'bibtexparser' has no attribute 'bparser' Since update of bibtexparser to 2.0.0b, the bparser has been either removed or not reimplemented yet. The documentation exposed in the bibtexparser source code gives little clue how to migrate from that particular situation. Quick lookup at contemporary qiime source code[1] shows the invocation is still around as of today, so an upstream version bump won't help yet. Maybe an option could be to avoid attemting to apply the bibtex parser customization when the bparser does not exist anymore? I'm not entirely confident on the side effects downstream. Only other option I can think of would be to wait and see how the bibtexparser v2.0.0 release will behave if there are planned changes on the parser or unicode customizations front. [1]: https://github.com/qiime2/qiime2/blob/dev/qiime2/core/cite.py Have a nice day, :) -- .''`. Étienne Mollier : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/3, please excuse my verbosity `-on air: Fish - Little Man What Now? signature.asc Description: PGP signature
Bug#1060973: python-pbcore: FTBFS
Control: tags -1 + unreproducible moreinfo Hi Lucas, I got information from Andreas Tille that the build failure is not reproducible in his environment. Actually I did give it a go myself, and the build went through for me as well. The build log is available on the people's server[1]. Actually, looking closely, I'm not sure why the build works in normal times: the build environment does not look to embed python3-pip packages in both cases, so in my case, pip may not be called in the first place. [1]: https://people.debian.org/~emollier/logs/python-pbcore/python-pbcore_amd64-2024-01-18T18:13:24Z.build.xz Thanks for your quality assessment work, this is very useful to catch issues! Have a nice day, :) -- .''`. Étienne Mollier : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/4, please excuse my verbosity `-on air: Flying Colors - Peaceful Harbor (Live) signature.asc Description: PGP signature
Bug#1058661: [Debian-med-packaging] Bug#1058661: dipy: slow (sometimes timing out) autopkgtest
Étienne Mollier, on 2024-01-12: > Rebecca N. Palmer, on 2023-12-14: > > This autopkgtest, and particularly test_reconstruct_rumba, is slow enough > > that it sometimes times out and fails. I think this is varying hardware > > speed and not a random hang because failure seems to correlate with the > > earlier tests taking longer. > > dipy 1.8.0-1 took more than thirteen hours to build on riscv64 > machine rv-manda-01[1]. Bumping the severity because this looks > a tad bit excessive. In the end, the build time of dipy 1.8.0-2 on rv-manda-03 was still 13h. On the other hand the autopkgtest on amd64 looks to have dropped from timeout at 1s to 3770s run time. This should be enough to even avoid dropping whent two python3 versions will be tested in sequence. Have a nice day, :) -- .''`. Étienne Mollier : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/2, please excuse my verbosity `-on air: One Shot - Off The Grid signature.asc Description: PGP signature
Bug#1058661: [Debian-med-packaging] Bug#1058661: dipy: slow (sometimes timing out) autopkgtest
Control: severity -1 important Rebecca N. Palmer, on 2023-12-14: > This autopkgtest, and particularly test_reconstruct_rumba, is slow enough > that it sometimes times out and fails. I think this is varying hardware > speed and not a random hang because failure seems to correlate with the > earlier tests taking longer. dipy 1.8.0-1 took more than thirteen hours to build on riscv64 machine rv-manda-01[1]. Bumping the severity because this looks a tad bit excessive. [1]: https://buildd.debian.org/status/fetch.php?pkg=dipy=riscv64=1.8.0-1=1705009202=0 Have a nice day, :) -- .''`. Étienne Mollier : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/5, please excuse my verbosity `-on air: Fleesh - Burning Rope signature.asc Description: PGP signature
Bug#1058661: dipy: slow (sometimes timing out) autopkgtest
Hi Rebecca, Rebecca N. Palmer, on 2023-12-14: > This autopkgtest, and particularly test_reconstruct_rumba, is slow enough > that it sometimes times out and fails. I think this is varying hardware > speed and not a random hang because failure seems to correlate with the > earlier tests taking longer. > > This could be fixed by skipping some slow tests (-k 'not > test_reconstruct_rumba'). Alternatively, if these tests are important it > _may_ be possible to increase the time limit. Thanks for the notice and hint for getting the run time a tad bit shorter. I'm in the process of bumping dipy to version 1.8.0, and this is taking forever notably due to the sheer time needed for running the test suite. Version 1.8.0 looks to introduce further tests which substancially increase further the runtime (I now register more than twenty minutes on my machine, per python3 version). I'm a bit wary to begin skipping tests for the first upload of the new upstream version, but I guess some trimming can be done in a second time to get the run time down to reasonable levels. Have a nice day, :) -- .''`. Étienne Mollier : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/7, please excuse my verbosity `-on air: Steven Wilson - Impossible Tightrope signature.asc Description: PGP signature
Bug#1060205: castxml: BD-Uninstallable: castxml build-depends on missing: libclang-17-dev:mips64el
Hi Andreas, Andreas Tille, on 2024-01-09: > Am Sun, Jan 07, 2024 at 09:05:10PM +0100 schrieb Étienne Mollier: > > Thanks for the heads up, I'm afraid this is a bit out of hands > > right now. According to bug entries #1059465 and #1056116, > > llvm-toolchain-16 and -17 fail to build on mips64el at the > > moment. Also, the llvm-toolchain-15 is not planned to ship with > > trixie if I trust #1058812. > > Wouldn't it make sense to ask ftpmaster for removal of the binary > castxml:mips64el? It may be a bit early to tell: I saw llvm-toolchain-17 upload today, so maybe its maintainers are up to something. Have a nice day, :) -- .''`. Étienne Mollier : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/2, please excuse my verbosity `-on air: Spheric Universe Experience - Moonlight signature.asc Description: PGP signature
Bug#1060176: [Debian-med-packaging] Bug#1060176: dipy: FTBFS on ppc64el: FAILED dipy/segment/tests/test_mrf.py::test_icm_square - AssertionError
Control: tags -1 + fixed-upstream pending Good day, I am working on bumping dipy version to 1.8.0 for some time, and in the light of my ppc64el build attempt, the new upstream version did not fail to build from source. I'm hopeful that the upcoming upload is going to fix this for sure. That was a qemu build, and I'm not at risk of flaky test issue, but crossing fingers. Have a nice one, :) -- .''`. Étienne Mollier : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/2, please excuse my verbosity `-on air: The Inner Road - Dark Door signature.asc Description: PGP signature
Bug#1060205: castxml: BD-Uninstallable: castxml build-depends on missing: libclang-17-dev:mips64el
Control: block -1 by #1056116 Hi Sebastian, > castxml build-depends on missing: > - libclang-17-dev:mips64el Thanks for the heads up, I'm afraid this is a bit out of hands right now. According to bug entries #1059465 and #1056116, llvm-toolchain-16 and -17 fail to build on mips64el at the moment. Also, the llvm-toolchain-15 is not planned to ship with trixie if I trust #1058812. Have a nice day, :) -- .''`. Étienne Mollier : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/0, please excuse my verbosity `-on air: Apple Pie - Letters Of A Deadman - Part III - … signature.asc Description: PGP signature
Bug#1060207: [Debian-med-packaging] Bug#1060207: ncbi-acc-download: please remove extraneous dependency on python3-mock
Hi Alexandre, Alexandre Detiste, on 2024-01-07: > For some reason Salsa doesn't let me push to this one reposotiry. The default branch is protected by default for Developers (in Salsa vernacular) and lower, so bumped you to Maintainer (still in Salsa vernacular). You should be able to push fixes now. Have a nice day, :) -- .''`. Étienne Mollier : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/0, please excuse my verbosity `-on air: Klaus Schulze - Nowhere - Now Here signature.asc Description: PGP signature
Bug#1054535: neuron: There is a compilation error for Neuron on the LoongArch machine.
Hi wuruilong, wuruilong, on 2024-01-02: > In order to reproduce the problem you mentioned in the email, I created a > clean compilation environment and recompiled the neuron software package. > > The problem did not reproduce and the compilation was successful after > solving the compilation problem caused by librandom123. > > For now, send the patch to librandom123. See the link for details. > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059824. Thanks for the additional details and investigations, I uploaded librandom123 1.14.0+dfsg-5 yesterday to allow your patch in the Debian archive. Someone kindly triggered a rebuild of neuron, but apparently, accordingl to the log[1], we are still hitting the same failure to capture the MPI CXX library. It looks like there is something else at play. Nice try though! [1]: https://buildd.debian.org/status/fetch.php?pkg=neuron=loong64=8.2.2-5=1704309241=1 Have a nice day, :) -- .''`. Étienne Mollier : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/0, please excuse my verbosity `-on air: Fish on Frday - Unreal signature.asc Description: PGP signature
Bug#1059776: ITP: python-trx-python -- implementation of the trx file-format for tractography data
Hi Andreas, Andreas Tille, on 2024-01-02: > While I understand to avoid naming confusion even with not yet > packaged code this duplicated python inside the name looks > quite unusual to me. I'd consider > > python-trx-tractography > > more speaking in this case. Thank you for the suggestion, I sent a rejection request to ftpmaster and was going to make the necessary adjustments but it looks like we collided, so python-trx-python it is. Thanks to them for the prompt acceptance though! Have a good evening, :) -- .''`. Étienne Mollier : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/1, please excuse my verbosity `- signature.asc Description: PGP signature
Bug#1059776: ITP: python-trx-python -- implementation of the trx file-format for tractography data
Package: wnpp Severity: wishlist Owner: Étienne Mollier X-Debbugs-Cc: debian-de...@lists.debian.org X-Debbugs-Cc: debian-...@lists.debian.org * Package name: python-trx-python Version : 0.2.9 Upstream Contact: Francois Rheault * URL : https://github.com/tee-ar-ex/trx-python * License : BSD-2-Clause Programming Lang: Python3 Description : implementation of the trx file-format for tractography data TRX is a tractography file format designed to facilitate dataset exchange, interoperability, and state-of-the-art analyses, acting as a community-driven replacement for the myriad existing file formats. . This package contains the Python implementation of the trx file-format. This package is a new dependency introduced in dipy 1.8.0. I plan to maintain it under the Debian Med Team umbrella. I am not 100% decided about the package name, because plain python-trx could refer to an unrelated python project, which is not packaged though. In the meantime, the packaging stub is available with its current heavy name on salsa[1]. [1]: https://salsa.debian.org/med-team/python-trx-python Happy new year! :) -- .''`. Étienne Mollier : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/6, please excuse my verbosity `- signature.asc Description: PGP signature
Bug#1059717: phylonium: packaging help likely needed
Source: phylonium Version: 1.7-1 Severity: normal I had a chat with Fabian Klötzl[1], and it appears they might not be in position to work on the packaging front anymore (although on upstream side, their support will still be provided). Additional uploaders would probably be needed so the package does not risk becoming team orphaned. [1]: https://github.com/EvolBioInf/andi/pull/17 For information, -- .''`. Étienne Mollier : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/3, please excuse my verbosity `-on air: Van der Graaf Generator - Aloft signature.asc Description: PGP signature
Bug#1059716: libdivsufsort: packaging help likely needed
Source: libdivsufsort Version: 2.0.1-5 Severity: normal I had a chat with Fabian Klötzl[1], and it appears they might not be in position to work on the packaging front anymore (although on upstream side, their support will still be provided). Additional uploaders would probably be needed so the package does not risk becoming team orphaned. [1]: https://github.com/EvolBioInf/andi/pull/17 For information, -- .''`. Étienne Mollier : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/3, please excuse my verbosity `-on air: Van der Graaf Generator - Aloft signature.asc Description: PGP signature
Bug#1059715: libmurmurhash: packaging help likely needed
Source: libmurmurhash Version: 1.5-3 Severity: normal I had a chat with Fabian Klötzl[1], and it appears they might not be in position to work on the packaging front anymore (although on upstream side, their support will still be provided). Additional uploaders would probably be needed so the package does not risk becoming team orphaned. [1]: https://github.com/EvolBioInf/andi/pull/17 For information, -- .''`. Étienne Mollier : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/3, please excuse my verbosity `-on air: Van der Graaf Generator - Aloft signature.asc Description: PGP signature
Bug#1059714: spaced: packaging help likely needed
Source: spaced Version: 1.2.0-201605+dfsg-3 Severity: normal I had a chat with Fabian Klötzl[1], and it appears they might not be in position to work on the packaging front anymore (although on upstream side, their support will still be provided). Additional uploaders would probably be needed so the package does not risk becoming team orphaned. [1]: https://github.com/EvolBioInf/andi/pull/17 For information, -- .''`. Étienne Mollier : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/3, please excuse my verbosity `- signature.asc Description: PGP signature
Bug#1059428: brian: Add support for loong64
Control: forwarded -1 https://github.com/brian-team/brian2/pull/1497 Control: tags -1 + upstream patch Hi liuxiang, Thank you for the patch, since it applies to the upstream part of the source, I took the liberty to forward it to the Brian Team on github. There is a slight change because I forgot to remove the original Debian patch which implemented the optimizer options selection per cpu; this will be safely removed on next brian package upload. Have a nice day, :) -- .''`. Étienne Mollier : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/3, please excuse my verbosity `-on air: Big Big Train - The Underfall Yard signature.asc Description: PGP signature
Bug#1054535: neuron: There is a compilation error for Neuron on the LoongArch machine.
Control: tags -1 - moreinfo Hi wuruilong, wuruilong, on 2023-12-21: > I searched for the local code about neuron and found that it was missing. > > I tried to compile neuron to make a new patach, and found that it could be > compiled directly successfully. > > Maybe now you can re-trigger the compilation of neuron to get the packages > in the unreleased state. Thanks for the hint, I attempted a rebuild of the package on the loong64 buildd, but the build failed here[1] with: -- Could NOT find MPI_CXX (missing: MPI_CXX_WORKS) CMake Error at /usr/share/cmake-3.28/Modules/FindPackageHandleStandardArgs.cmake:230 (message): Could NOT find MPI (missing: MPI_CXX_FOUND) (found version "3.1") Call Stack (most recent call first): /usr/share/cmake-3.28/Modules/FindPackageHandleStandardArgs.cmake:600 (_FPHSA_FAILURE_MESSAGE) /usr/share/cmake-3.28/Modules/FindMPI.cmake:1837 (find_package_handle_standard_args) cmake/MacroHelper.cmake:277 (find_package) CMakeLists.txt:309 (nrn_mpi_find_package) which is weird, because I believe it should capture the file below, which does exist in the loong64 libopenmpi-dev and libopenmpi3 packages in the debian-ports archive: usr/lib/loongarch64-linux-gnu/openmpi/lib/libmpi_cxx.so: symbolic link to ../../libmpi_cxx.so.40 usr/lib/loongarch64-linux-gnu/libmpi_cxx.so.40: symbolic link to libmpi_cxx.so.40.30.1 usr/lib/loongarch64-linux-gnu/libmpi_cxx.so.40.30.1: ELF 64-bit LSB shared object, LoongArch, version 1 (SYSV), dynamically linked, BuildID[sha1]=780933118b0c18c0272f4effb5b438e81410eccd, stripped [1]: https://buildd.debian.org/status/fetch.php?pkg=neuron=loong64=8.2.2-5=1703760534=1 I am afraid I am lacking the infrastructure to investigate further. Anyway, in hope this helps, -- .''`. Étienne Mollier : :' : gpg: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/1, please excuse my verbosity `-on air: Hecenia - Le Grimoire signature.asc Description: PGP signature
Bug#1058768: [Debian-med-packaging] Bug#1058768: cyvcf2: ftbfs and autopkgtest regression with htslib 1.19
Hi Andreas, Andreas Tille, on 2023-12-21: > I have *not* tested cyvcf2 with htslib 1.19 from experimental thus not > closing this bug. However it builds nicely with htslib 1.18 now and > thus I uploaded to close cython3-legacy related bug #1056799. You did good not closing, I quickly checked the new upstream version but it still failed to build with the newer htslib 1.19 on my end. Have a nice day, :) -- .''`. Étienne Mollier : :' : gpg: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/1, please excuse my verbosity `- signature.asc Description: PGP signature
Bug#1054535: neuron: There is a compilation error for Neuron on the LoongArch machine.
Control: tags -1 + moreinfo Hi wuruilong, Thank you for your patch for improving neuron portability! Please note that in its current form, it embeds intermediate configuration artifacts, notably but not limited to below obj-loongarch64-linux-gnu/, which severely inflate the package size, and make it very hard to review. In addition, it will make it difficult to maintain in the future, as the hardcoded configuration records will change as compiler and build utilities version will increase. Please could you provide more targeted changes necessary for the port to loong64? As a side note, the patch's DEP3 metadata would really gain in being filled in. For the moment it is only filled with boilerplate text. Have a nice day, :) -- .''`. Étienne Mollier : :' : gpg: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/3, please excuse my verbosity `-on air: Elephant Plaza - Southwest signature.asc Description: PGP signature
Bug#1058768: [Debian-med-packaging] Bug#1058768: cyvcf2: ftbfs and autopkgtest regression with htslib 1.19
Control: forwarded -1 https://github.com/brentp/cyvcf2/pull/290 Experimental pseudo-excuses tripped the cyvcf2 autopkgtest bug, which has its log[1] now available. Besides, upstream seems to be discussing porting effort[2] of cyvcf2 to htslib 1.19, with changes which seem to allow for mitigating the bug at play. We will see how it goes. [1]: https://ci.debian.net/packages/c/cyvcf2/unstable/amd64/41057999/ [2]: https://github.com/brentp/cyvcf2/pull/290 Have a nice day, :) -- .''`. Étienne Mollier : :' : gpg: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/2, please excuse my verbosity `-on air: Lalu - Potboy: The Final Fantasy signature.asc Description: PGP signature
Bug#1058790: mayavi2: autopkgtest failure in pysurfer since python-traitsui 8
Source: mayavi2
Version: 4.8.1-1
Severity: serious
Justification: autopkgtest failure in reverse dependecy
Tags: patch upstream fixed-upstream
Affects: pysurfer
Forwarded: https://github.com/enthought/mayavi/pull/1255
Dear Maintainer,
Since introduction of python3-traitsui 8, pysurfer is failing
its autopkgtest suite with errors like[1]:
ERRORS
_ ERROR collecting tests/test_utils.py
_
ImportError while importing test module
'/tmp/autopkgtest.pQ5bOG/autopkgtest_tmp/tests/test_utils.py'.
Hint: make sure your test modules/packages have valid Python names.
Traceback:
/usr/lib/python3.11/importlib/__init__.py:126: in import_module
return _bootstrap._gcd_import(name[level:], package, level)
tests/test_utils.py:9: in
from surfer import utils
/usr/lib/python3/dist-packages/surfer/__init__.py:1: in
from .viz import Brain, TimeViewer # noqa
/usr/lib/python3/dist-packages/surfer/viz.py:17: in
from mayavi.core.ui.api import SceneEditor
/usr/lib/python3/dist-packages/mayavi/core/ui/api.py:4: in
from tvtk.pyface.scene_editor import SceneEditor
/usr/lib/python3/dist-packages/tvtk/pyface/scene_editor.py:12: in
SceneEditor = toolkit_object('scene_editor:SceneEditor')
/usr/lib/python3/dist-packages/pyface/base_toolkit.py:127: in __call__
module = import_module(mname, package)
/usr/lib/python3.11/importlib/__init__.py:126: in import_module
return _bootstrap._gcd_import(name[level:], package, level)
/usr/lib/python3/dist-packages/tvtk/pyface/ui/qt4/scene_editor.py:16:
in
from traitsui.qt4.editor import Editor
E ModuleNotFoundError: No module named 'traitsui.qt4.editor'
[1]: https://ci.debian.net/packages/p/pysurfer/unstable/amd64/39514398/
They look to stem from mayavi2 trying to make use of an old way
of loading the editor module, now called traitsui.qt.editor.
Upstream prepared the a patch[2] to upcoming versions of
mayavi2, but it is not there yet.
[2]: https://github.com/enthought/mayavi/pull/1255
I have verified the patch fixes the autopkgtest regression in
pysurfer, and did not raise any obvious issues in mayavi2. I'm
considering providing a team upload to resolve this particular
issue.
Have a nice day, :)
--
.''`. Étienne Mollier
: :' : gpg: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da
`. `' sent from /dev/pts/7, please excuse my verbosity
`-on air: K2 - Storm at Sunset
signature.asc
Description: PGP signature
Bug#1058768: cyvcf2: ftbfs and autopkgtest regression with htslib 1.19
Source: cyvcf2
Version: 0.30.22-1
Severity: important
Tags: ftbfs upstream
With the introduction of htslib 1.19 in experimental, cyvcf2 is
experiencing test failures at package build time and autopkgtest
time. The relevant part of the error looks like:
cyvcf2/tests/test_reader.py .Fatal Python error:
Aborted
Current thread 0x7fa7874de040 (most recent call first):
File
"/<>/.pybuild/cpython3_3.11_cyvcf2/build/cyvcf2/tests/test_reader.py",
line 285 in test_writer_from_string
File "/usr/lib/python3/dist-packages/_pytest/python.py", line 194 in
pytest_pyfunc_call
File "/usr/lib/python3/dist-packages/pluggy/_callers.py", line 77 in
_multicall
File "/usr/lib/python3/dist-packages/pluggy/_manager.py", line 115 in
_hookexec
File "/usr/lib/python3/dist-packages/pluggy/_hooks.py", line 493 in
__call__
File "/usr/lib/python3/dist-packages/_pytest/python.py", line 1792 in
runtest
File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 169 in
pytest_runtest_call
File "/usr/lib/python3/dist-packages/pluggy/_callers.py", line 77 in
_multicall
File "/usr/lib/python3/dist-packages/pluggy/_manager.py", line 115 in
_hookexec
File "/usr/lib/python3/dist-packages/pluggy/_hooks.py", line 493 in
__call__
File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 262 in
File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 341 in
from_call
File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 261 in
call_runtest_hook
File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 222 in
call_and_report
File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 133 in
runtestprotocol
File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 114 in
pytest_runtest_protocol
File "/usr/lib/python3/dist-packages/pluggy/_callers.py", line 77 in
_multicall
File "/usr/lib/python3/dist-packages/pluggy/_manager.py", line 115 in
_hookexec
File "/usr/lib/python3/dist-packages/pluggy/_hooks.py", line 493 in
__call__
File "/usr/lib/python3/dist-packages/_pytest/main.py", line 350 in
pytest_runtestloop
File "/usr/lib/python3/dist-packages/pluggy/_callers.py", line 77 in
_multicall
File "/usr/lib/python3/dist-packages/pluggy/_manager.py", line 115 in
_hookexec
File "/usr/lib/python3/dist-packages/pluggy/_hooks.py", line 493 in
__call__
File "/usr/lib/python3/dist-packages/_pytest/main.py", line 325 in
_main
File "/usr/lib/python3/dist-packages/_pytest/main.py", line 271 in
wrap_session
File "/usr/lib/python3/dist-packages/_pytest/main.py", line 318 in
pytest_cmdline_main
File "/usr/lib/python3/dist-packages/pluggy/_callers.py", line 77 in
_multicall
File "/usr/lib/python3/dist-packages/pluggy/_manager.py", line 115 in
_hookexec
File "/usr/lib/python3/dist-packages/pluggy/_hooks.py", line 493 in
__call__
File "/usr/lib/python3/dist-packages/_pytest/config/__init__.py",
line 169 in main
File "/usr/lib/python3/dist-packages/_pytest/config/__init__.py",
line 192 in console_main
File "/usr/lib/python3/dist-packages/pytest/__main__.py", line 5 in
File "", line 88 in _run_code
File "
The affected test item looks like:
273 def test_writer_from_string():
274
275 header = """##fileformat=VCFv4.1
276 ##FORMAT=
277 ##contig=
278 #CHROM POS ID REF ALT QUALFILTER INFO
FORMAT samplea
279 """
280
281 w = Writer.from_string("out.vcf", header)
282 w.write_header()
283 v =
w.variant_from_string("chr1\t234\t.\tA\tC\t40\tPASS\t.\tGT\t0/0")
284 w.write_record(v)
>285 w.close()
The test engine bails out after that, so this may not be the
single occurrence of the issue in the test suite.
From tests done locally, this does not look caused by the
disappearance of an internal htslib symbol that leaked to the
libhts3 package symbols table from version 1.16 to 1.18. That
could be a bug in cyvcf2, or one introduced in htslib 1.19, in
which case the bug may have to be reassigned accordingly. This
issue will become "serious" after htslib 1.19 is migrated to
unstable.
For information,
--
.''`. Étienne Mollier
: :' : gpg: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da
`. `' sent from /dev/pts/2, please excuse my verbosity
`-on air: Conception - In Your Multitude
signature.asc
Description: PGP signature
Bug#1058705: nitime: please provide non-superficial autopkgtest support
Source: nitime Version: 0.10.1-1 Severity: wishlist Tags: newcomer Hi all, nitime currently only ships a superficial autopkgtest-pkg-python module that makes sure there is no obvious issues with nitime module loading. While this is better than nothing, it would be nice to have some more involved test making use of the nitime module for real. Note that I already tried to move to autopkgtest-pkg-pybuild, but the engine did not manage to capture properly the existing test suite for autopkgtest context, so there will be some more manual work involved. Have a nice day, :) -- .''`. Étienne Mollier : :' : gpg: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/3, please excuse my verbosity `-on air: Starcastle - Fountains signature.asc Description: PGP signature
Bug#1057983: brian: runtime dependency on cython legitimate
Hi Matthias, Matthias Klose, on 2023-12-14: > if I understand that correctly, then the extension itself doesn't need the > dependency, but just an example code to build. So yes, recommends would be > better, or split out an -examples or -doc package, where you add that again > as a dependency. > > adding cython3 as an autopkg test dependency should also be ok if the tests > need cython3. Sounds good, thank you for your advice, I will demote cython3 to a recommendation and close the bug. Have a nice day, :) -- .''`. Étienne Mollier : :' : gpg: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/1, please excuse my verbosity `-on air: Galahad - All In The Name Of Progress signature.asc Description: PGP signature
Bug#1057983: brian: runtime dependency on cython legitimate
Hi Matthias, Would it be helpful, for the upcoming transition, to demote the dependency to cython3 to a recommendation? Matthias Klose, on 2023-12-11: > Please check that this dependency can be removed. Most likely this > dependency is generated by pybuild, because the setup.py requires > Cython in it's 'install_requires' attribute. Please remove that, > after checking that it is not a runtime dependency, and also report > that issue upstream for upcoming releases. > > If the runtime dependency is necessary, please just close this bug > report. I suspected that python3-brian is one of the few cases where the cython3 dependency could be legitimate, so I searched within upstream examples and found at least one[1] which, when I attempt to run is without cython3, will output warnings and informational messages, then crash several steps later, issue which is fixed when I install cython3 and rerun the script. [1]: https://brian2.readthedocs.io/en/stable/examples/advanced.compare_GSL_to_conventional.html Meddling with GSL looks far fetched for this module's usage though, and most functions have implemented mechanisms to fallback to numpy when cython3 is not available. cython3 is thus not 100% necessary, but it is useful at runtime. I checked against the existing autopkgtest, and lacking cython3 has no influence in that particular context so far. That being said, a number of functions benefit from a substancial (as in 170%, but GSL will bump that to a whooping 3500% depending on the target CPU) performance boost from running with cython3 available. (Speaking of GSL, this one depends on make and libgsl-dev, but they look missing from the runtime dependencies for now; g++ is part of the suggestions though.) Have a nice day, :) -- .''`. Étienne Mollier : :' : gpg: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/3, please excuse my verbosity `-on air: Matt Stevens - Big Sky signature.asc Description: PGP signature
Bug#1058394: augur: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.12 3.11" returned exit code 13
Control: reassign -1 src:pyfastx 2.0.2-1 Control: affects -1 src:augur > > /usr/lib/python3.12/importlib/__init__.py:90: in import_module > > return _bootstrap._gcd_import(name[level:], package, level) > > tests/test_align.py:16: in > > from augur import align > > augur/__init__.py:15: in > > from .io.print import print_err > > augur/io/__init__.py:6: in > > from .metadata import read_metadata # noqa: F401 > > augur/io/metadata.py:5: in > > import pyfastx > > E ModuleNotFoundError: No module named 'pyfastx' These test failures stem from pyfastx lacking Python 3.12 due to missing cython shared objects rebuild for that python3 version. I'm checking whether other packages are affected. Have a nice day, :) -- .''`. Étienne Mollier : :' : gpg: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/5, please excuse my verbosity `-on air: Arch/Matheos - Neurotically Wired signature.asc Description: PGP signature
Bug#1053509: shasta: autopkgtest regression on arm64: is memory suddenly not enough?
Alright, I think I managed to get somewhere with the program's configuration options: using an older reference config from 2019, shasta doesn't look to reserve itself unnecessary amounts of memory, and the test should now go through. If this works, we can forget about checking available memory on the host, and the Ubuntu specific change (apparently, Steve Langasek disabled the first command of the test suite, which explains why there were no issues on this operating system). I will push an updated autopkgtest soon to close the issue. Have a nice day, :) -- .''`. Étienne Mollier : :' : gpg: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/2, please excuse my verbosity `- signature.asc Description: PGP signature
Bug#1053509: [Debian-med-packaging] Bug#1053509: shasta: autopkgtest regression on arm64: is memory suddenly not enough?
Hi Paul, Paul Gevers, on 2023-12-03: > 8GiB... that's not little, considering that that's what these hosts have as > RAM (https://wiki.debian.org/ContinuousIntegration/WorkerSpecs). […] > ci-worker-arm64-NN: -rw--- 1 root root 3.9G May 27 2022 /swap […] > It's kbytes, memory, ratio == 0, 0, 50 across all our hosts. Thank you for the figures, that makes: (50% × 8 GiB RAM) + 4 GiB swap = 8 GiB CommitLimit With overcommit disabled, that is a hard limit for commiting anonymous memory for the whole system (which makes me wonder how come we hit a failures modes which looks like it should only occur when some overcommit is allowed). 8 GiB is the lower limit documented by upstream, so I'm even wondering how is it possible that the test has been passing in the past. Some more precise calculation of memory consumption show me an upper bound of 7,900,000 kB, with some runs consuming in the 6,000,000 kB. This may be explained by the algorithm involving random steps. Otherwise said, tests may pass on sheer luck… > Be aware though that tests don't run in > isolation. At the same time, on our arm64 hosts, one more test might be > running. So what's *available* might not be constant in time. Okay, that means there will be concurrent access to an already tight space for shasta. It looks like that's on me being greedy. I see what I can do to reduce anonymous maps usage. Upstream's documentation looks to have a chapter on reducing memory consumption by giving options to use disk backed memory maps, although on first try it didn't look to reduce the commit memory consumption. Let's see if I can get somewhere… Have a nice day, :) -- .''`. Étienne Mollier : :' : gpg: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/1, please excuse my verbosity `-on air: Tangerine Dream - Stratosfear signature.asc Description: PGP signature
Bug#1053509: shasta: autopkgtest regression on arm64: is memory suddenly not enough?
Hi Paul, > 1) why does it now suddenly start to (nearly always) fail across the > board on arm64 (in Debian, Ubuntu still seems fine), without changes to > the infrastructure that I know of? I'm afraid I'm not sure what is up with shasta eating up more memory on arm64 hosts of CI infrastructure. What I can see from my end is that the test roughly requires 8GiB of anonymous memory to map for doing its job. Except that, this is already the case for shasta in bookworm running on bookworm kernel, so that doesn't look to be a regression per se. > 2) do you also believe this is related to memory consumption? The problem you mentioned, where shasta explicitly gives up when running into memory limits, is reproducible when I disable the swap on an 8GiB machine that I have at hand. I attempted to play with /proc/sys/vm/overcommmit_* settings, but my swap at t time was too big (10GiB) to give me the granularity necessary to check whether I could get somewhere with improper overcommit memory tuning. In any cases, the "Killed" status suggest overcommit is active (or heuristic) on your end for at least some of the hosts. Per chance, could you double check the memory settings on the CI hosts, just in case, to make sure that the swap didn't drop off the machine? Or maybe check for memory overcommit settings inconsistencies? Currently readable test logs suggest that: * ci-worker-arm64-10 met memory requirements in November, * ci-worker-arm64-07 did not meet requirements in October, * ci-worker-arm64-08 did not meet requirements in October, * ci-worker-arm64-03 did not meet requirements in October. So this may already be resolved, in case you changed something in between. > 3) If 2 == yes, what are the memory requirements for the test? The test > *could* test for that before it starts and bail out (restriction: > skippable with exit code 77 [2]) if the amount of memory available is > too small. It shouldn't hurt I guess. I think I can bolt something reading the memory commit capacity and usage in /proc/meminfo at the beginning of the test, and skip the run if the testbed couldn't meet the memory requirement for whatever reason. Note this may involve some trial and error. Have a nice Sunday, :) -- .''`. Étienne Mollier : :' : gpg: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/1, please excuse my verbosity `-on air: Ghost - Avalanche signature.asc Description: PGP signature
Bug#1015668: spades: ftbfs with LTO: supplemental
Control: tags -1 + confirmed Control: forwarded -1 https://github.com/ablab/spades/issues/1007 Hi all, I gave another go at this issue today, and the relevant part of the build log seemed to be: cd /<>/obj-x86_64-linux-gnu/projects/corrector && /usr/bin/c++ -DNDEBUG -DUSE_GLIBCXX_PARALLEL=1 -I/<>/assembler/src/include -I/<>/obj-x86_64-linux-gnu/include -I/<>/assembler/src -I/<>/assembler/src/common -I/<>/assembler/src/projects/corrector -I/<>/assembler/ext/src/mimalloc/include -isystem /<>/assembler/src/../ext/include -isystem /<>/assembler/ext/include -g -O2 -ffile-prefix-map=/<>=. -flto=auto -ffat-lto-objects -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -Wdate-time -D_FORTIFY_SOURCE=2 -fopenmp -std=gnu++14 -Wno-deprecated -O2 -Wall -Wextra -Wconversion -Wno-sign-conversion -Wno-long-long -Wwrite-strings -MD -MT projects/corrector/CMakeFiles/spades-corrector-core.dir/dataset_processor.cpp.o -MF CMakeFiles/spades-corrector-core.dir/dataset_processor.cpp.o.d -o CMakeFiles/spades-corrector-core.dir/dataset_processor.cpp.o -c /<>/assembler/src/projects/corrector/dataset_processor.cpp lto1: fatal error: multiple prevailing defs for 'insert' compilation terminated. lto-wrapper: fatal error: /usr/bin/c++ returned 1 exit status compilation terminated. /usr/bin/ld: error: lto-wrapper failed collect2: error: ld returned 1 exit status make[4]: *** [projects/scaffold_correction/CMakeFiles/spades-truseq-scfcorrection.dir/build.make:131: bin/spades-truseq-scfcorrection] Error 1 Feeding 'gcc lto "fatal error: multiple prevailing defs for"' to a search engine shown multiple results suggesting probable compiler bugs, notably as mentioned in upstream bug report[1], which itself redirects to bug Gcc#86490[2]. I'm considering an upload of spades which ensures lto builds are always disabled. [1]: https://github.com/ablab/spades/issues/1007 [2]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86490 Have a nice Sunday, :) -- .''`. Étienne Mollier : :' : gpg: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/5, please excuse my verbosity `-on air: 7for4 - Rushian signature.asc Description: PGP signature
Bug#1055414: patch for bedtools FTBFS on i386 with "intersect" tool failure
Control: tags -1 + patch The below patch fixes the test failure. There is a catch though in that I think it introduces a baseline violation on i386, but similar change was already needed in htslib to fix #942580. I'm not sure what to make of that for now. --- a/debian/rules +++ b/debian/rules @@ -6,7 +6,7 @@ export DEB_BUILD_MAINT_OPTIONS = hardening=+all include /usr/share/dpkg/default.mk ifneq (,$(filter $(DEB_HOST_ARCH),i386 kfreebsd-i386 hurd-i386)) - export DEB_CXXFLAGS_MAINT_APPEND=-ffloat-store + export DEB_CXXFLAGS_MAINT_APPEND=-msse -mfpmath=sse endif %: -- .''`. Étienne Mollier : :' : gpg: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/5, please excuse my verbosity `- signature.asc Description: PGP signature
Bug#1055669: bcftools: test_vcf_merge failures on armhf: Bus error
Source: bcftools Version: 1.18-1 Severity: serious Tags: ftbfs Justification: ftbfs Control: forwarded -1 https://github.com/samtools/bcftools/issues/2036 Dear Maintainer, bcftools currently ftbfs on armhf due to multiple test_vcf_merge failures with Bus error[1]. I already informed upstream[2]. This bug is mostly to keep track of the issue on Debian side and eventually comment on possible Debian specific workarounds. For the context, there are 44 failure looking typically like: test_vcf_merge: /<>/bcftools merge --no-version -Ob --force-samples -0 /tmp/YVqRgiAYOP/merge.a.vcf.gz /tmp/YVqRgiAYOP/merge.b.vcf.gz /tmp/YVqRgiAYOP/merge.c.vcf.gz | /<>/bcftools view --no-version | grep -v ^##bcftools_ Non-zero status 1 Failed to read from standard input: unknown file type .. failed ... [1]: https://buildd.debian.org/status/fetch.php?pkg=bcftools=armhf=1.18-1=1699434189=1 [2]: https://github.com/samtools/bcftools/issues/2036 For information, -- .''`. Étienne Mollier : :' : gpg: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/2, please excuse my verbosity `-on air: Silent Voices - Humancradlegrave signature.asc Description: PGP signature
Bug#1055527: [Debian-med-packaging] Bug#1055527: castxml: Please update llvm/clang to llvm-17 in unstable
Étienne Mollier, on 2023-11-07: > Étienne Mollier, on 2023-11-07: > > I'm also tempted by the unversionned llvm > > packages so these kind of version bumps do not go overlooked in > > the future, but need to check why the specific version was > > applied in the first place. > > According to commit 4be8e58e4d07bde442b5b118318e8dc2e1ac80c8, > the versionning originated from a need to bump ahead of the > default at llvm-9 to get simde intrinsics support. It thus > looks now suitable to drop the versionning. … if it weren't for packages, like the mlir, which have only versioned packages. I push dependency on llvm 17. Have a nice day, :) -- .''`. Étienne Mollier : :' : gpg: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/2, please excuse my verbosity `-on air: Odd Dimension - Far From Desire signature.asc Description: PGP signature
Bug#1055527: [Debian-med-packaging] Bug#1055527: castxml: Please update llvm/clang to llvm-17 in unstable
Étienne Mollier, on 2023-11-07: > I'm also tempted by the unversionned llvm > packages so these kind of version bumps do not go overlooked in > the future, but need to check why the specific version was > applied in the first place. According to commit 4be8e58e4d07bde442b5b118318e8dc2e1ac80c8, the versionning originated from a need to bump ahead of the default at llvm-9 to get simde intrinsics support. It thus looks now suitable to drop the versionning. Cheers, :) -- .''`. Étienne Mollier : :' : gpg: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/1, please excuse my verbosity `-on air: This Winter Machine - The River (Parts 1 & 2) signature.asc Description: PGP signature
Bug#1055527: [Debian-med-packaging] Bug#1055527: castxml: Please update llvm/clang to llvm-17 in unstable
Hi Witold, Witold Baryluk, on 2023-11-07: > Dear Maintainer, > > castxml is using llvm-14 > > would be nice to bump this to 17 in unstable / testing. Unless there is > some autoupgrade comming in few next weeks. Thank you for the heads up, llvm-17 looks like it could be a good option indeed. I'm also tempted by the unversionned llvm packages so these kind of version bumps do not go overlooked in the future, but need to check why the specific version was applied in the first place. Have a nice day, :) -- .''`. Étienne Mollier : :' : gpg: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/1, please excuse my verbosity `-on air: Green Lung - The Forest Church signature.asc Description: PGP signature
Bug#1055528: dgit: perl warning: variable $date masks earlier declaration
Package: dgit Version: 11.4 Severity: minor Dear Maintainer, Running dgit on Debian sid, I noticed recently that every invocation started with what looks like a perl warning. Example output can be optained with --help flag: $ dgit --help "my" variable $date masks earlier declaration in same scope at /usr/bin/dgit line 2188. main usages: dgit [dgit-opts] clone [dgit-opts] package [suite] [./dir|/dir] dgit [dgit-opts] fetch|pull [dgit-opts] [suite] dgit [dgit-opts] build [dpkg-buildpackage-opts] […] This is repeatable with any other invocation from my typical dgit workflow. This is not visibly impairing the functionality of dgit, hence the minor severity. Have a nice day, :) Étienne. -- 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-3-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=C.UTF-8, LC_CTYPE=C.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 dgit depends on: ii apt2.7.6 ii ca-certificates20230311 ii coreutils 9.1-1 ii curl 8.4.0-2 ii devscripts 2.23.6 ii dpkg-dev 1.22.1 ii dput-ng [dput] 1.37 ii git [git-core] 1:2.42.0-1 ii git-buildpackage 0.9.32 ii libdpkg-perl 1.22.1 ii libjson-perl 4.1-1 ii liblist-moreutils-perl 0.430-2 ii liblocale-gettext-perl 1.07-6 ii libtext-csv-perl 2.03-1 ii libtext-glob-perl 0.11-3 ii libtext-iconv-perl 1.7-8 ii libwww-curl-perl 4.17-10 ii perl [libdigest-sha-perl] 5.36.0-9 Versions of packages dgit recommends: ii distro-info-data 0.59 ii liburi-perl 5.21-1 ii openssh-client [ssh-client] 1:9.4p1-1 Versions of packages dgit suggests: ii pbuilder 0.231 ii sbuild0.85.4 -- no debconf information -- .''`. Étienne Mollier : :' : gpg: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/5, please excuse my verbosity `-on air: Sky Empire - The Last Days of Planet Fantasy signature.asc Description: PGP signature
Bug#1055414: bedtools: FTBFS on i386: "intersect" tool failure
Source: bedtools Version: 2.31.0+dfsg-1 Severity: serious Tags: ftbfs Justification: ftbfs Dear Maintainer, While making a routine metadata update on a Debian patch against bedtools, Salsa CI caught a build failure on i386[1] which I could reproduce multiple times in sid and in testing with the unmodified version of the package. [1]: https://salsa.debian.org/med-team/bedtools/-/jobs/4891166 The relevant part of the build log shows the following differences in the test suite of the "intersect" tool: intersect.t22.p...0a1 > chr1 0 30 one_block_one_exon_30bp 40 - 0 30 0,0,0 1 30, 0, chr1 0 100 exon1 1 + 30 fail intersect.t22.q...1a2 > chr1 80 110 one_block_one_exon_20bp 40 - 80 110 0,0,0 1 30, 0, chr1 0 100 exon1 1 + 20 fail The tests are started from test/intersect/test-intersect.sh. I'm not sure what change caused the build failure to appear. The issue is not affecting amd64, nor armhf, which suggest something very i386 specific. I have not checked closely the other CPU architectures yet. The relevant upstream change that introduced this code begins to date back from quite some time ago[2] and the package builds with -ffloat-store for a while, so this may be caused by a dependency, or a compiler change. [2]: https://github.com/arq5x/bedtools2/commit/9d22ccb24f258553b0eff31e689b09563227331b Hope this helps pinpointing what's up, Étienne. -- 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-3-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=C.UTF-8, LC_CTYPE=C.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 -- .''`. Étienne Mollier : :' : gpg: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/7, please excuse my verbosity `-on air: Condition Red - Let It All Come Out signature.asc Description: PGP signature
Bug#1054920: perftest: ib__ manual pages outdated
Package: perftest Version: 4.5+0.17-1 Severity: minor Dear Maintainer, There is currently a lot of delta between the documented options of maintainer manual pages of the different ib__ commands, which are timestamped as dating back from 2008, and the wealth of options currently reported by the commands' --help output. I have been banging my head wondering how to change some test parameters until I noticed the newer options while browsing through perftest source code. Depending on what is the easiest for you, I think it would be welcome to see the manual pages refreshed, or at least have a prominent SEE ALSO section strongly stating that the information in the manual may be outdated, and one should preferably refer to --help for the complete list of options. Have a good day, :) -- .''`. Étienne Mollier : :' : gpg: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/3, please excuse my verbosity `-on air: Subsignal - Sliver (The Sheltered Garden) signature.asc Description: PGP signature
Bug#1053257: ITP: python-globus-sdk -- convenient Pythonic interface to Globus APIs
Package: wnpp Severity: wishlist Owner: Étienne Mollier X-Debbugs-Cc: debian-de...@lists.debian.org X-Debbugs-Cc: debian-pyt...@lists.debian.org X-Debbugs-Cc: debian-...@lists.debian.org * Package name: python-globus-sdk Version : 3.28.0 Upstream Contact: Globus Team * URL : https://github.com/globus/globus-sdk-python * License : Apache-2.0 Programming Lang: Python Description : convenient Pythonic interface to Globus APIs The Globus SDK for Python provides a convenient Pythonic interface to Globus APIs. Using this package, one can import Globus client classes and other helpers from the globus_sdk python module. This package would be needed to finish the packaging of python-parsl, which in turn would be required to finish the qiime ecosystem upgrade to version 2023.7. For the moment, I plan to put this package under the Debian Python team umbrella, but I'm also open to put it under the Debian HPC team, so the people behind the Globus ecosystem packaging also have this component on their radar. I have not settled for a location for the repository yet, probably some place like [1] if sticking to the Python team. [1]: https://salsa.debian.org/python-team/packages/python-globus-sdk Have a nice day, :) -- .''`. Étienne Mollier : :' : gpg: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/3, please excuse my verbosity `-on air: Final Conflict - A River Of Dreams signature.asc Description: PGP signature
Bug#1044070: python-pauvre: FTBFS with pandas 2.0
Control: tags -1 confirmed
There is a build failure reproducible by pulling python3-pandas
and python3-pandas-lib from experimental specifically. Relevant
log that went missing from Launchpad would probably have looked
like:
debian/rules override_dh_auto_test
make[1]: Entering directory '/<>'
PYBUILDDIR="$(echo "/<>"/.pybuild/cpython3_3.*/build)" \
&& mkdir -p "${PYBUILDDIR}/pauvre/tests/testdata/alignments" \
"${PYBUILDDIR}/pauvre/tests/testresults" \
&& cp -r "/<>/debian/tests/gff_files" \
"${PYBUILDDIR}/pauvre/tests/testdata" \
&& BUILDDIR="${PYBUILDDIR}" PATH="/<>/debian/bin:$PATH" \
dh_auto_test \
&& rm "${PYBUILDDIR}/input" \
&& rm -r "${PYBUILDDIR}/pauvre/tests/testdata" \
"${PYBUILDDIR}/pauvre/tests/testresults"
I: pybuild base:291: cd
/<>/.pybuild/cpython3_3.11_pauvre/build; python3.11 -m unittest
discover -v
test_normal_plotting_scenario
(pauvre.tests.test_synplot.libSeq_test_case.test_normal_plotting_scenario)
This verifies that the LibSeq class is constructed with all of the ...
+ export PYTHONPATH=/<>/.pybuild/cpython3_3.11_pauvre/build
+ PYTHONPATH=/<>/.pybuild/cpython3_3.11_pauvre/build
+ exec python3
/<>/.pybuild/cpython3_3.11_pauvre/build/pauvre/pauvre_main.py
synplot --aln_dir
/<>/.pybuild/cpython3_3.11_pauvre/build/pauvre/tests/testdata/alignments/
--fileform pdf --gff_paths
/<>/.pybuild/cpython3_3.11_pauvre/build/pauvre/tests/testdata/gff_files/Bf201706.gff
/<>/.pybuild/cpython3_3.11_pauvre/build/pauvre/tests/testdata/gff_files/JN392469.gff
/<>/.pybuild/cpython3_3.11_pauvre/build/pauvre/tests/testdata/gff_files/NC016117.gff
--center_on COX1 --gff_labels 'B. forskalii' 'P. bachei' 'M. leidyi'
Traceback (most recent call last):
File
"/<>/.pybuild/cpython3_3.11_pauvre/build/pauvre/pauvre_main.py",
line 636, in
main()
File
"/<>/.pybuild/cpython3_3.11_pauvre/build/pauvre/pauvre_main.py",
line 630, in main
args.func(parser, args)
File
"/<>/.pybuild/cpython3_3.11_pauvre/build/pauvre/pauvre_main.py",
line 64, in run_subtool
submodule.run(args)
File
"/<>/.pybuild/cpython3_3.11_pauvre/build/pauvre/synplot.py", line
581, in run
synplot(args)
File
"/<>/.pybuild/cpython3_3.11_pauvre/build/pauvre/synplot.py", line
402, in synplot
GFFs.append(GFFParse(gffpath, args.stop_codons, species))
File
"/<>/.pybuild/cpython3_3.11_pauvre/build/pauvre/functions.py",
line 75, in __init__
self.features.drop('dunno1', 1, inplace=True)
TypeError: DataFrame.drop() takes from 1 to 2 positional arguments but
3 positional arguments (and 1 keyword-only argument) were given
FAIL
==
FAIL: test_normal_plotting_scenario
(pauvre.tests.test_synplot.libSeq_test_case.test_normal_plotting_scenario)
This verifies that the LibSeq class is constructed with all of the
--
Traceback (most recent call last):
File
"/<>/.pybuild/cpython3_3.11_pauvre/build/pauvre/tests/test_synplot.py",
line 66, in test_normal_plotting_scenario
self.assertEqual(0, int(data.returncode))
AssertionError: 0 != 1
In hope this helps (including future self),
--
.''`. Étienne Mollier
: :' : gpg: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da
`. `' sent from /dev/pts/0, please excuse my verbosity
`-on air: Pink Floyd - One Of These Days
signature.asc
Description: PGP signature
Bug#1044079: augur: FTBFS with pandas 2.0
Control: tags -1 + help It looks like there are no plans upstream to fix the issue for now, and the item was closed on that ground. I would welcome help, as the code makes use of a pandas' internal to make something smart with dates, and I didn't make sense of what happens despite some digging before filing the issue upstream. Thanks, -- .''`. Étienne Mollier : :' : gpg: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/2, please excuse my verbosity `-on air: Cirrus Bay - Song Of The Wind signature.asc Description: PGP signature
Bug#1051325: [Debian-med-packaging] Bug#1051325: sortmerna: FTBFS: concurrentqueue.h: No such file or directory
Control: tags -1 + confirmed Hi László, László Böszörményi, on 2023-09-06: > /build/sortmerna-4.3.6/include/readsqueue.hpp:49:12: fatal error: > concurrentqueue/concurrentqueue.h: No such file or directory >49 | # include > |^~~ […] > It seems the mentioned header moved to > /usr/include/concurrentqueue/moodycamel/concurrentqueue.h ; please > update your package. Thanks for the report and the hint, I'm looking at this. Have a nice day, :) -- .''`. Étienne Mollier : :' : gpg: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/2, please excuse my verbosity `-on air: Marillion - Angelina signature.asc Description: PGP signature
Bug#1051083: [Debian-med-packaging] Bug#1051083: Please fix autopkgtest regression with file 1.45
Control: tag -1 + confirmed patch pending Bonjour Cristoph, Thanks for the heads up, I implemented a change in the spirit of your suggestion. I'll upload something to ease your transition in not too long. Bonne journée, :) -- .''`. Étienne Mollier : :' : gpg: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/2, please excuse my verbosity `- signature.asc Description: PGP signature
Bug#964082: parsinsert fails it's tests when built with -O2 gcc-13
Hi Andreas, Andreas Tille, on 2023-08-28: > Am Sun, Aug 27, 2023 at 11:26:32PM +0200 schrieb Étienne Mollier: > > > > -O1 -O2 -O3 > > -fPIE + no hardening OK OKOK > > -fno-PIE + no hardening OK FAIL FAIL > > -fPIE + hardening OK FAIL FAIL > > -fno-PIE + hardening OK FAIL FAIL > > Thanks a lot for creating this matrix. The change even fixed LTO builds. :) On the other hand, well, the hardening is gone. :( The package looks to range on the performance critical side of the spectrum, so this is probably an acceptable trade-off. This is probably symptomatic of a deeper problem in the source code though, but I don't really expect to pinpoint the exact cause without help from upstream. > > I'm considering pushing an upload that goes in the direction of > > disabling hardening and enforcing PIE in the upcoming week, > > unless there are reasons to hold on, or someone is faster than > > me in uploading. > > I will probably be not faster than you. Please make sure you document > in d/rules that hardening breaks the tests. This should avoid that > someone later might simply switch on hardening since we usually do this. > (may be same for salsa-ci.yaml when you switch of the CI test there.) This is documented in d/rules. I'll also add the necessary lintian overrides and blhc markers to reduce the noise caused by the change in automated checks. Have a nice day, :) -- .''`. Étienne Mollier : :' : gpg: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/tty1, please excuse my verbosity `-on air: Orphaned Land - Fail signature.asc Description: PGP signature
Bug#964082: parsinsert fails it's tests when built with -O2 gcc-13
Étienne Mollier, on 2023-08-26: > After suspecting hardening, it turned out > that the following, when combined with build of ParsInsert.o > with -O2 optimization, is causing the test failure: > > -specs=/usr/share/dpkg/no-pie-compile.specs Rerunning these tests in a properly isolate chroot show me that the hardening is also contributing to the improper results. Hardening must be disabled and PIE must be enforced to ensure the program runs appropriately -O1 -O2 -O3 -fPIE + no hardening OK OKOK -fno-PIE + no hardening OK FAIL FAIL -fPIE + hardening OK FAIL FAIL -fno-PIE + hardening OK FAIL FAIL I'm considering pushing an upload that goes in the direction of disabling hardening and enforcing PIE in the upcoming week, unless there are reasons to hold on, or someone is faster than me in uploading. Have a nice day, :) -- .''`. Étienne Mollier : :' : gpg: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/1, please excuse my verbosity `-on air: Dream Theater - Scene Three: II. Fatal Tragedy signature.asc Description: PGP signature
Bug#1050557: [Debian-med-packaging] Bug#1050557: abyss: FTBFS: error: possibly dangling reference to a temporary [-Werror=dangling-reference]
Control: tags -1 + confirmed Hi Aurélien, Aurelien Jarno, on 2023-08-26: > | GfaIO.h:182:27: error: possibly dangling reference to a temporary > [-Werror=dangling-reference] Thank you for your report, this seems to be one of those cases where the newly introduced warnings in gcc 13 are getting possibly overzealous. I did reproduce the crash on my end and consider making the warning non-fatal for the time being. This will solve the build failure on amd64, riscv64, and all the other architectures which were otherwise working with this package. Have a nice day, :) -- .''`. Étienne Mollier : :' : gpg: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/2, please excuse my verbosity `-on air: Sieges Even - Unbreakable signature.asc Description: PGP signature
Bug#964082: parsinsert fails it's tests when built with -O2 gcc-13
Hi Matthias, Matthias Klose, on 2023-08-24: > please can you identify the object file which is wrongly built? > build two versions, one with -O1, the other with -O2, then combine the > object files from the two builds to identify a specific file? Thanks for the procedure, I isolated that ParsInsert.o is the faulty object file when built with -O2. Erasing it with the equivalent object file built with -O1 fixes the errors. Something intresting though: when I manually build ParsInsert.o with `c++ -c ParsInsert.c -o ParsInsert.o -O2`, the error doesn't appear, so it looks to result from a bad combination with something else. After suspecting hardening, it turned out that the following, when combined with build of ParsInsert.o with -O2 optimization, is causing the test failure: -specs=/usr/share/dpkg/no-pie-compile.specs -O2 alone is not sufficient to cause the failure, and no-pie specifications neither if combined with only -O1. Under tabular form: -O1 -O2 -fPIE OK OK -fno-PIE OK FAIL In case this were caused by an optimization kicking in, I tried logging all optimizations with -fopt-info, but there were no differences at all between the two flavors of -O2 builds. In the light of this finding, I attempted to force build with -fPIE, which resolved the problem at -O2 and even -O3. Assuming this is the right approach, it might be sufficient to resolve the problem. What do you think? Would passing -fPIE be the appropriate change, or is it possible such change would hide something else under the carpet? > also there seem to be some warnings, is the package really ready for C++17? The upstream version hasn't changed since the introduction of the package in the archive, ten years ago, so I guess not? Have a nice day, :) -- .''`. Étienne Mollier : :' : gpg: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/2, please excuse my verbosity `-on air: Collage - Man In The Middle signature.asc Description: PGP signature
Bug#964082: parsinsert fails it's tests when built with -O3; and -O2 since gcc-13
Control: retitle -1 parsinsert fails it's tests when built with -O2 Control: tags -1 - unreproducible Control: tags -1 - moreinfo Hi, Just mentionning that since introduction of gcc-13, parsinsert saw also its tests failing in #1037816 with optimization -O2 on amd64. So we're currently building parsinsert -O1 for now. Cheers, :) -- .''`. Étienne Mollier : :' : gpg: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/4, please excuse my verbosity `-on air: Ivory Tower - The Wolves You've Let In signature.asc Description: PGP signature
Bug#1050164: [Debian-med-packaging] Bug#1050164: libleidenalg: missing symbols with newer glibc/lto
Control: tags -1 + confirmed Hi Gianfranco, Gianfranco Costamagna, on 2023-08-21: > I found in Ubuntu that 4 symbols are disappearing, probably due to lto and > them being virtually provided. > I think it might be useful to mark them as optional, to avoid FTBFS with lto > or newer gcc versions. > > Thanks for considering the patch. I haven't tested this library with optimize=+lto yet, so thanks for checking! The symbols you flag are consistent with my own verification. I consider applying your patch. Have a nice day, :) -- .''`. Étienne Mollier : :' : gpg: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/1, please excuse my verbosity `- signature.asc Description: PGP signature
Bug#1050081: ITP: python-parsl -- Parallel Scripting Library
Package: wnpp Severity: wishlist Owner: Étienne Mollier X-Debbugs-Cc: debian-de...@lists.debian.org X-Debbugs-Cc: debian-pyt...@lists.debian.org * Package name: python-parsl Version : 2023.08.14 Upstream Contact: Yadu Nand Babuji , et al. * URL : https://github.com/Parsl/parsl * License : Apache 2.0 Programming Lang: Python Description : Parallel Scripting Library Parsl extends parallelism in Python beyond a single computer. . One can use Parsl just like Python's parallel executors but across multiple cores and nodes. However, the real power of Parsl is in expressing multi-step workflows of functions. Parsl lets one chain functions together and will launch each function as inputs and computing resources are available. This package is a new dependency for upgrading the qiime2 distribution on Debian Med radar. Since the module parsl itself is a bit more generic than medical field, I intend to put the package under the Debian Python team umbrella. A stub of packaging is available on Salsa[1]. [1]: https://salsa.debian.org/python-team/packages/python-parsl/ Have a nice day, :) -- .''`. Étienne Mollier : :' : gpg: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/2, please excuse my verbosity `- signature.asc Description: PGP signature
Bug#1050037: RM: dipy [s390x] -- ANAIS; Little-endian buffer not supported on big-endian compiler
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: d...@packages.debian.org Control: affects -1 + src:dipy Hi ftpmaster, dipy currently fails to build from source on a couple of release architectures. I have some fixes pending upload to get support for arm64, ppc64el, riscv64 and possibly other unreleased debian ports. But tests on big endian architectures are also failing with the following error: > ??? E ValueError: Little-endian buffer not supported on big-endian compiler Please kindly consider removing dipy from the s390x unstable distribution. Have a nice day, :) -- .''`. Étienne Mollier : :' : gpg: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/7, please excuse my verbosity `-on air: Anubis - Reflective PS: hope this will not be a duplicate, I didn't get feedback for my initial message, and I suspect I erroneously sent the initial message through a black hole instead of mail-submit, sorry about that. But it should be okay given the timing of feedback on the tnseq-transit bug. signature.asc Description: PGP signature
Bug#1050034: RM: tnseq-transit [s390x] -- ROM; wrong results on big endian systems caught by build-time tests
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: tnseq-tran...@packages.debian.org Control: affects -1 + src:tnseq-transit Hi ftpmaster, Please remove tnseq-transit for the s390x architecture in unstable, as the newer version fails its test suite on intricate computational errors on big endian systems, as seen in the build log[1]. This package has no reverse dependencies. [1]: https://buildd.debian.org/status/fetch.php?pkg=tnseq-transit=s390x=3.3.0-1=1691922911=1 Have a nice day, :) -- .''`. Étienne Mollier : :' : gpg: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/7, please excuse my verbosity `-on air: 7Days - Wisdom Calls PS: hope this will not be a duplicate, I didn't get feedback for my initial message, and I suspect I erroneously sent the initial message through a black hole instead of mail-submit, sorry about that. signature.asc Description: PGP signature
