Bug#1071321: tagging 1071321
Hi Florian, Florian Ernst, on 2024-05-18: > # yeah, confirmed via sbuild, and I will further investigate the next chance > I get If that helps, the symbols strlcat and strlcpy have been added to the glibc 2.38, so I believe it should be safe to remove the following symbols without soname bump: dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols file: see diff output below dpkg-gensymbols: warning: debian/libdumbnet1/DEBIAN/symbols doesn't match completely debian/libdumbnet1.symbols --- debian/libdumbnet1.symbols (libdumbnet1_1.18.0-1_amd64) +++ dpkg-gensymbolsWaiUn6 2024-05-17 17:44:34.104667735 + @@ -93,8 +93,8 @@ route_get@Base 1.8 route_loop@Base 1.8 route_open@Base 1.8 - strlcat@Base 1.8 - strlcpy@Base 1.8 +#MISSING: 1.18.0-1# strlcat@Base 1.8 +#MISSING: 1.18.0-1# strlcpy@Base 1.8 tun_close@Base 1.11 tun_fileno@Base 1.11 tun_name@Base 1.11 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: Kaipa - A Road In My Mind signature.asc Description: PGP signature
Bug#1058474: gubbins: please (temporarily) drop python3-numba dependencies
Control: tags -1 - wontfix Control: tags -1 + confirmed Control: severity -1 serious Hi, I've had a fresh look at this, and if I understand correctly, the situation is still problematic today. Gubbins is not operating properly without python3-numba in testing, but it is still installable because python3-numba is only recommended. The autopkgtest suite does not run without python3-numba, and indeed it is forcefully pulled by the debian/tests/control file. All that being said, numba provides a just-in-time compiler to accelerate decorated Python functions, so removing temporarily dependency on numba simply consists in removing the decorators. Fortunately, only the pyjar.py script makes use of numba, which greatly facilitates the removal. I have some changes almost ready to be uploaded. The only adverse effect of the removal that I foresee, is that removing numba may lead to performance reduction of the functions that were previously decorated. The removal should have no influence on functionalities or results. 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: Legacy Pilots - The Squad Is Back signature.asc Description: PGP signature
Bug#1065221: O: py7zr -- pure Python 7-zip library
yokota, on 2024-05-13: > py7zr 0.21 is now split-out all architecture-dependent binary module > to external python modules. > And py7zr target architecture is changed to "all". > I think we send RM request to Debian release team to drop old > architecture-dependent packages. Removal requests may not be necessary for an "any" to "all" change, but lets keep an eye on how things are moving. It's possible I'm missing something (an upload to NEW?), or the upload might just work. We'll see. 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#1065221: O: py7zr -- pure Python 7-zip library
Hi Yokota, yokota, on 2024-05-12: > py7zr was ready for upload to Debian. > Please examine salsa repository and upload to Debian if it looks well. I reviewed through your changes in py7zr and ran a couple of tests, notably the ones from the reverse dependency "calibre". I have not seen matter for comments, the package looked suitable for upload to unstable to me, so I proceeded. Congratulations! Thank you for your contribution! 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#1051534: analizo: Test failure in t/features.t during build and autopkgtests
Control: tags -1 + confirmed patch pending upstream Hi, gregor herrmann, on 2023-09-09: > # Failed test 'Then analizo must report that the project has > total_abstract_classes = 1' > # at t/features/metrics/abstract_classes.feature line 19. > # in step at t/features/metrics/abstract_classes.feature line 19. > # not ok > # # Failed test at > /build/analizo-1.25.4/t/features/step_definitions/analizo_steps.pl line 143. > # # got: 2 > # # expected: 1 Looking at t/features/metrics/abstract_classes.feature, ther is a curious discrepancy between the csharp and the other languages in terms of expected number of abstract classes: Scenario: "Animals" project Given I am in t/samples/animals/ When I run "analizo metrics ." Then analizo must report that the project has total_abstract_classes = Examples: | language | total_abstract_classes | | cpp | 2 | | java | 2 | | csharp | 1 | Looking at the sample code which is under test, there does seem to be two abstract classes for csharp samples: $ grep 'abstract class' t/samples/animals/csharp/* t/samples/animals/csharp/Animal.cs:public abstract class Animal { t/samples/animals/csharp/Mammal.cs:public abstract class Mammal : Animal { Looking upstream, I ran into the commit introducing the csharp support[1], which suggest there was something off at the time of the introduction of the test with Doxygen: >> doxyparse doesn't identify all abstract C# classes, the Mammal abstract >> class defined in animals sample (below) wasn't identified: >> >> // Mammal.cs: >> public abstract class Mammal : Animal { >> public virtual void close() {} >> } This suggests the issue has been resolved with the recent upload of doxygen that is currently staging in unstable. Therefore, I believe it should be safe to update the test item so analizo is expected to capture 2 abstract classes in csharp as well as the other languages. I am preparing an upload to resolve that. [1]: https://github.com/analizo/analizo/commit/6cdd646d723106bddc4f9f01cbbbf9370e347925 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: Pendragon - The Edge Of The World 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: tags -1 + confirmed upstream Control: forwarded -1 https://gitlab.com/german.tischler/libmaus2/-/issues/40 In the end, I could reproduce the test failures affecting libmaus2 on amdahl and informed upstream. We'll see how things go. 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: Silent Memorial - Retrospective signature.asc Description: PGP signature
Bug#1069370: shasta: FTBFS: dpkg-shlibdeps: error: cannot continue due to the error above
Hi, With the error rewrapped to facilitate readability: > dpkg-shlibdeps: error: > cannot find library shasta.cpython-311-aarch64-linux-gnu.so > needed by debian/shasta/usr/bin/shasta > (ELF format: 'elf64-littleaarch64' > abi: 'ELF:64:l:arm64:0'; > RPATH: '/usr/lib/python3/dist-packages') The problem seems to stem from the shasta binary having its DT_RUNPATH set to /usr/lib/python3/dist-packages. This is prompting dpkg-shlibdeps to scan the cython shared object to derive from which package obtaining the library, and fail. Now to mitigate properly, it might be helpful to see whether other options than setting the RPATH are acceptable. Otherwise dpkg-shlibdeps may have to be instructed to ignore shasta, which in turn will lead to manual maintenance of library dependencies in the package. I see if I can get somewhere… In hope this helps, -- .''`. É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 - Framed signature.asc Description: PGP signature
Bug#1070469: RM: python-pyppmd [s390x] -- ANAIS; big-endian architectures unsupported
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: python-pyp...@packages.debian.org Control: affects -1 + src:python-pyppmd User: ftp.debian@packages.debian.org Usertags: remove Hi ftpmaster, While adding pybuild test support to python-pyppmd, we noticed that some encoding and decoding cycles were failing to restore compressed user data on big-endian architectures, for instance on s390x[1]: _ test_ppmd8_encode_decode[1048576-1] __ tmp_path = PosixPath('/tmp/pytest-of-buildd/pytest-1/test_ppmd8_encode_decode_104851') mem_size = 1048576, restore_method = 1 @pytest.mark.parametrize( "mem_size, restore_method", [ (8 << 20, pyppmd.PPMD8_RESTORE_METHOD_RESTART), (8 << 20, pyppmd.PPMD8_RESTORE_METHOD_CUT_OFF), (1 << 20, pyppmd.PPMD8_RESTORE_METHOD_RESTART), (1 << 20, pyppmd.PPMD8_RESTORE_METHOD_CUT_OFF), ], ) @pytest.mark.timeout(20) def test_ppmd8_encode_decode(tmp_path, mem_size, restore_method): length = 0 m = hashlib.sha256() with testdata_path.joinpath("1SalesRecords.csv").open("rb") as f: with tmp_path.joinpath("target.ppmd").open("wb") as target: enc = pyppmd.Ppmd8Encoder(6, mem_size, restore_method=restore_method) data = f.read(READ_BLOCKSIZE) while len(data) > 0: m.update(data) length += len(data) target.write(enc.encode(data)) data = f.read(READ_BLOCKSIZE) target.write(enc.flush(endmark=True)) shash = m.digest() m2 = hashlib.sha256() assert length == 1237262 length = 0 with tmp_path.joinpath("target.ppmd").open("rb") as target: with tmp_path.joinpath("target.csv").open("wb") as out: dec = pyppmd.Ppmd8Decoder(6, mem_size, restore_method=restore_method) data = target.read(READ_BLOCKSIZE) while not dec.eof: res = dec.decode(data) m2.update(res) out.write(res) length += len(res) if len(data) == 0: break data = target.read(READ_BLOCKSIZE) > assert length == 1237262 E assert 1237261 == 1237262 tests/test_ppmd8.py:91: AssertionError [1]: https://buildd.debian.org/status/fetch.php?pkg=python-pyppmd=s390x=1.1.0%2Bds-2=1714557172=0 If left as is, we suspect the package could corrupt user data and is is not fit for release on big-endian systems. It should be removed from the archive until such configuration is properly supported. Please remove python-pyppmd from s390x release architecture. 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#1070387: [Debian-med-packaging] Bug#1070387: gdcm: CVE-2024-25569 CVE-2024-22373 CVE-2024-22391
Control: found -1 3.0.21-1 Control: found -1 3.0.8-2 Control: fixed -1 3.0.24-1 Hi Moritz, Thanks for the tracking and the triaging of these issues! Moritz Mühlenhoff, on 2024-05-04: > Please adjust the affected versions in the BTS as needed. Done with the present email; an upload of 3.0.24-1 is on the way in unstable. I'm afraid I'm not sure how to test those vulnerabilities, but mitigations brought by Mathieu apply with no fuzz, or just a little, to gdcm in stable and oldstable (and possibly oldoldstable), so I'm inclined to assume they are affected. Hi Mathieu, don't hesitate to chime in if you have some insights on applying the mitigations on older versions. I'm still running extensive tests at the moment against (build) reverse dependencies, but there were no issues directly induced by the newer gdcm version so far. I'm considering liaising with Stable Release Managers to get gdcm fixed there too in upcoming point releases, if that helps. 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: Alta Forma - Apocalyptus signature.asc Description: PGP signature
Bug#1070334: libnet-frame-device-perl needs network access during build
Control: tags -1 + patch Étienne Mollier, on 2024-05-03: > Has someone an idea of better approach? Answering to myself, the test suite does not actually attempt to access the Internet, but it does attempt to access the device on the build machine that can route by default to 1.1.1.1. This is not because it is a Cloudflare DNS, but merely because it is the first usable ipv4 available at hand. Especially in chroot-mode unshare, there are no device leading to Internet exposed, thus no device able to route to 1.1.1.1 with the default object instanciation routine. It turns out that the class can be told to construct objects that refer to the loopback interface by asking for routes to the loopback network (127/8 in ipv4, ::1/64 in ipv6). I prepared a patch in this direction and consider uploading soon. 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: Allman Brothers Band - Statesboro Blues Description: fix build failure when no network interfaces are available. On buildd systems using sbuild chroot mode unshare, the network interface leading to Internet is not exposed. However the default construction method for instanciating Net::Frame::Devices relies on the existence of a network interface able to route to 1.1.1.1. This change adjusts the test suite items failing when not such interfaces are available, by trying to refer to loopback interfaces instead. Note this slightly changes the meaning of the t/04-new-default.t, as it does not test the default behavior anymore, but it tests the behavior with ipv6 targets instead. . This addresses a Debian infrastructure specific behavior, probably not much worth forwarding upstream. Author: Étienne Mollier Bug-Debian: https://bugs.debian.org/1070334 Forwarded: not-needed Last-Update: 2024-05-04 --- This patch header follows DEP-3: http://dep.debian.net/deps/dep3/ --- libnet-frame-device-perl.orig/t/05-new-target.t +++ libnet-frame-device-perl/t/05-new-target.t @@ -2,7 +2,7 @@ BEGIN { plan(tests => 1) } use Net::Frame::Device; -my $d = Net::Frame::Device->new(target => '2.2.2.2') or die("Device::new"); +my $d = Net::Frame::Device->new(target => '127.1.1.1') or die("Device::new"); print $d->cgDumper if $d->can('cgDumper'); ok(1); --- libnet-frame-device-perl.orig/t/04-new-default.t +++ libnet-frame-device-perl/t/04-new-default.t @@ -2,7 +2,7 @@ BEGIN { plan(tests => 1) } use Net::Frame::Device; -my $d = Net::Frame::Device->new or die("Device::new"); +my $d = Net::Frame::Device->new(target6 => '::1') or die("Device::new"); print $d->cgDumper if $d->can('cgDumper'); ok(1); signature.asc Description: PGP signature
Bug#1070334: libnet-frame-device-perl needs network access during build
Control: tags -1 + confirmed Jochen Sprickerhof, on 2024-05-03: > libnet-frame-device-perl fails to build with no network connection: > > 1..1 > # Running under perl version 5.038002 for linux > # Current time local: Sat Apr 27 12:53:04 2024 > # Current time GMT: Sat Apr 27 12:53:04 2024 > # Using Test.pm version 1.31 > ok 1 # skip Test::Pod 1.00 required for testing > ok > Net::Frame::Device: updateFromDefault: unable to get dnet > > This can be tested with the sbuild unshare backend. Interesting, the test suite looks to expect to find non loopback interfaces being configured, at least one I assume. If I run the build in chroot-mode schroot, it captures details of the network configuration of the interface: $VAR1 = { 'subnet6' => 'fe80::/64', 'gatewayMac6' => undef, 'target6' => undef, 'gatewayIp6' => 'fe80::1234:56ff:fe78:9abc', 'ip6' => 'fe80::cba9:87ff:fe65:4321', 'mac' => 'cb:a9:87:65:43:21', 'gatewayMac' => '12:34:56:67:9a:bc', 'target' => undef, 'dev' => 'enp1s0', 'subnet' => '192.168.1.0/24', '_dnet' => undef, 'gatewayIp' => '192.168.1.254', 'ip' => '192.168.1.1' }; instead of the error below, which I also witnessed on my end in chroot-mode unshare: Net::Frame::Device: updateFromDefault: unable to get dnet I don't really have any good suggestion apart from not running the affected tests at build time: t/04-new-default.t (Wstat: 25856 (exited 101) Tests: 0 Failed: 0) Non-zero exit status: 101 Parse errors: Bad plan. You planned 1 tests but ran 0. t/05-new-target.t (Wstat: 25856 (exited 101) Tests: 0 Failed: 0) Non-zero exit status: 101 Parse errors: Bad plan. You planned 1 tests but ran 0. Has someone an idea of better approach? 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: Steve Hackett - The Cinema Show (Live at Hamme… signature.asc Description: PGP signature
Bug#1062071: [Debian-med-packaging] Bug#1062071: genometools: NMU diff for 64-bit time_t transition
Hi Steve, NMU for genometools 1.6.5+ds-2.1 acknowledged in the VCS, with a minor change to un-shadow Lukas Märdian experimental NMU earlier this year. Thanks for your work on the hairy time_t transition! 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: Laurent Garnier - Last tribute from the 20th c… signature.asc Description: PGP signature
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