Bug#1069871: netplan.io: flaky autopkgtest on s390x: eth42 interface already exists
Source: netplan.io
Version: 0.107.1-3
Severity: serious
User: debian...@lists.debian.org
Usertags: flaky
Dear maintainer(s),
I looked at the results of the autopkgtest of your package. I noticed
that it regularly fails on s390x (and maybe on armel/armhf, but that's
hard to tell because of the time_t fall-out).
Because the unstable-to-testing migration software now blocks on
regressions in testing, flaky tests, i.e. tests that flip between
passing and failing without changes to the list of installed packages,
are causing people unrelated to your package to spend time on these
tests.
Don't hesitate to reach out if you need help and some more information
from our infrastructure.
Paul
e.g.
https://ci.debian.net/packages/n/netplan.io/testing/s390x/45071647/
272s ==
272s ERROR: test_rename_interfaces
(__main__.TestNetworkd.test_rename_interfaces)
272s --
272s Traceback (most recent call last):
272s File
"/tmp/autopkgtest-lxc.ndthudlr/downtmp/build.hjS/src/tests/integration/base.py",
line 177, in setUp
272s self.create_devices()
272s File
"/tmp/autopkgtest-lxc.ndthudlr/downtmp/build.hjS/src/tests/integration/base.py",
line 120, in create_devices
272s raise SystemError('eth42 interface already exists')
272s SystemError: eth42 interface already exists
OpenPGP_signature.asc
Description: OpenPGP digital signature
Bug#1069724: slurm-wlm: autopkgtest regression on !amd64: trying to overwrite '/usr/lib/-linux-gnu/slurm-wlm/accounting_storage_mysql.so'
Source: slurm-wlm Version: 23.11.4-1.4 X-Debbugs-CC: bdr...@debian.org, vor...@debian.org, mckins...@debian.org Severity: serious User: debian...@lists.debian.org Usertags: regression Dear maintainer(s), With a recent upload of slurm-wlm the autopkgtest of slurm-wlm fails in testing when that autopkgtest is run with the binary packages of slurm-wlm from unstable. It passes when run with only packages from testing. In tabular form: passfail slurm-wlm from testing23.11.4-1.4 all others from testingfrom testing I copied some of the output at the bottom of this report. Currently this regression is blocking the migration to testing [1]. Can you please investigate the situation and fix it? More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=3Dslurm-wlm https://ci.debian.net/data/autopkgtest/testing/arm64/s/slurm-wlm/45786802/log.gz 96s Unpacking slurm-wlm-mysql-plugin (23.11.4-1.4) ... 96s dpkg: error processing archive /tmp/apt-dpkg-install-zn5wp3/17-slurm-wlm-mysql-plugin_23.11.4-1.4_arm64.deb (--unpack): 96s trying to overwrite '/usr/lib/aarch64-linux-gnu/slurm-wlm/accounting_storage_mysql.so', which is also in package slurm-wlm-basic-plugins 23.11.4-1.4 OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1069603: [Pkg-openssl-devel] Bug#1069603: openssl breaks libcrypt-smime-perl autopkgtest: Crypt::SMIME#setPublicKeyStore: failed to store the public cert
Hi On 21-04-2024 5:56 p.m., Sebastian Andrzej Siewior wrote: The problem is that libcrypt-smime-perl < 0.29 fails with openssl >= 3.2.0. This was solved by the Perl team with their 0.29 upload. This and 0.30 didn't migrate to testing and in the meantime we got OpenSSL into unstable which relies on that fix. The migration was delayed by the time_t transition. Ack. I figured that out too. Could britney be hinted to migrate both at the same time? This should solve the issue you pointed out. There is no "please test together" knob if that's what you mean (is that what you mean?). I have triggered the test manually, so for now the lights are green. Because those expire, I have added a hint to ignore the failure of the old version in testing. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1069603: openssl breaks libcrypt-smime-perl autopkgtest: Crypt::SMIME#setPublicKeyStore: failed to store the public cert
Source: openssl, libcrypt-smime-perl Control: found -1 openssl/3.2.1-3 Control: found -1 libcrypt-smime-perl/0.28-1 Severity: serious Tags: sid trixie User: debian...@lists.debian.org Usertags: breaks needs-update Dear maintainer(s), With a recent upload of openssl the autopkgtest of libcrypt-smime-perl fails in testing when that autopkgtest is run with the binary packages of openssl from unstable. It passes when run with only packages from testing. In tabular form: passfail opensslfrom testing3.2.1-3 libcrypt-smime-perlfrom testing0.28-1 all others from testingfrom testing I copied some of the output at the bottom of this report. Currently this regression is blocking the migration of openssl to testing [1]. Due to the nature of this issue, I filed this bug report against both packages. Can you please investigate the situation and reassign the bug to the right package? More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=3Dopenssl https://ci.debian.net/data/autopkgtest/testing/amd64/libc/libcrypt-smime-perl/45599656/log.gz 50s not ok 14 - Load the default public key store 50s=20 50s # Failed test 'Load the default public key store' 50s # at t/04-taint.t line 257. 50s # died: Crypt::SMIME#setPublicKeyStore: failed to store the public cert at t/04-taint.t line 257. 50s Failed 2/7 subtests=20 OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1069554: [Pkg-pascal-devel] Bug#1069554: winff: FTBFS on armel: build-dependency not installable: libreoffice-draw-nogui
Hi, On 20-04-2024 3:22 p.m., Lucas Nussbaum wrote: The following packages have unmet dependencies: sbuild-build-depends-main-dummy : Depends: libreoffice-draw-nogui but it is not installable E: Unable to correct problems, you have held broken packages. apt-get failed. I recall rene mentioning that parts of lo are expected to not work on armel due to java being broken. Probably the best way forward is to request binary removal on armel. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1068942: src:oscar4: unsatisfied build dependency in testing: emboss-data
Source: oscar4 Version: 5.2.0+dfsg-2 Severity: serious Tags: sid trixie User: debian...@lists.debian.org Usertags: edos-uninstallable Dear maintainer(s), Dose [1] is reporting a build issue with your package, it's missing a build dependency. Obviously your build dependencies shouldn't be removed from testing, but unfortunately there are multiple scenarios where that can happen nevertheless. To uphold our social contract, Debian requires that packages can be rebuild from source in the suite we are shipping them, so currently this is a serious issue with your package in testing. Can you please investigate the situation and figure out how to resolve it? Regularly, if the build dependency is available in unstable, helping the maintainer of your Build-Depends to enable migration to testing is a great way to solve the issue. If your build dependency is gone from unstable and testing, you'll have to fix the build process in some other way. Paul Note: this bug report was sent after some quick manual checks using a template. Please reach out to me if you believe I made a mistake in my process. [1] https://qa.debian.org/dose/debcheck/src_testing_main/latest/amd64.html OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1068941: src:mdevctl: unsatisfied build dependency in testing: librust-env-logger-0.10.0+default-dev
Source: mdevctl Version: 1.3.0-1 Severity: serious Tags: sid trixie User: debian...@lists.debian.org Usertags: edos-uninstallable Dear maintainer(s), Dose [1] is reporting a build issue with your package, it's missing a build dependency. Obviously your build dependencies shouldn't be removed from testing, but unfortunately there are multiple scenarios where that can happen nevertheless. To uphold our social contract, Debian requires that packages can be rebuild from source in the suite we are shipping them, so currently this is a serious issue with your package in testing. Can you please investigate the situation and figure out how to resolve it? Regularly, if the build dependency is available in unstable, helping the maintainer of your Build-Depends to enable migration to testing is a great way to solve the issue. If your build dependency is gone from unstable and testing, you'll have to fix the build process in some other way. Paul Note: this bug report was sent after some quick manual checks using a template. Please reach out to me if you believe I made a mistake in my process. [1] https://qa.debian.org/dose/debcheck/src_testing_main/latest/amd64.html OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1067067: ruby-rdiscount: FTBFS: rdiscount.c:50:17: error: implicit declaration of function ‘rb_rdiscount__get_flags’ [-Werror=implicit-function-declaration]
Hi, On Sun, 17 Mar 2024 23:37:03 +0100 Sebastian Ramacher wrote: Justification: fails to build from source (but built successfully in the past) This package is a key package (hence we can't trivially remove it from testing) and the failure is blocking the time_t transition. Can this please be looked into ASAP? Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1068589: gem2deb: autopkgtest needs update for new version of ruby3.1: "libc6 (>= 2.2.5)", "libruby3.1t64 (>= 3.1.0~preview1)", "ruby | ruby-interpreter\n"] expected to include 'ruby (>= something
Source: gem2deb Version: 2.2.2 Severity: serious X-Debbugs-CC: ruby...@packages.debian.org Tags: sid trixie User: debian...@lists.debian.org Usertags: needs-update Control: affects -1 src:ruby3.1 Dear maintainer(s), With a recent upload of ruby3.1 (in the time_t transition) the autopkgtest of gem2deb fails in testing when that autopkgtest is run with the binary packages of ruby3.1 from unstable. It passes when run with only packages from testing. In tabular form: passfail ruby3.1from testing3.1.2-8.3 gem2debfrom testing2.2.2 all others from testingfrom testing I copied some of the output at the bottom of this report. Currently this regression is blocking the migration of ruby3.1 to testing [1]. Of course, ruby3.1 shouldn't just break your autopkgtest (or even worse, your package), but it seems to me that the change in ruby3.1 was intended and your package needs to update to the new situation. If this is a real problem in your package (and not only in your autopkgtest), the right binary package(s) from ruby3.1 should really add a versioned Breaks on the unfixed version of (one of your) package(s). Note: the Breaks is nice even if the issue is only in the autopkgtest as it helps the migration software to figure out the right versions to combine in the tests. More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=ruby3.1 https://ci.debian.net/data/autopkgtest/testing/amd64/g/gem2deb/44893387/log.gz 42s W: Inconsistent version numbers: lib/gem2deb/version.rb says 2.1, debian/changelog says 2.2.2 42s => Unit tests ... 108s test: multibinary source package should inject dependency on ruby (>= something). : F 108s === 108s Failure: test: multibinary source package should inject dependency on ruby (>= something). (Gem2DebTest): 108s ["libc6 (>= 2.2.5)", "libruby3.1t64 (>= 3.1.0~preview1)", "ruby | ruby-interpreter\n"] expected to include 'ruby (>= something)'. 108sis not true. 108s /tmp/autopkgtest-lxc.f1vq6prr/downtmp/build.NZh/src/test/integration/gem2deb_test.rb:83:in `block (3 levels) in ' 108s /tmp/autopkgtest-lxc.f1vq6prr/downtmp/build.NZh/src/test/integration/gem2deb_test.rb:87:in `instance_exec' 108s /tmp/autopkgtest-lxc.f1vq6prr/downtmp/build.NZh/src/test/integration/gem2deb_test.rb:87:in `block in create_test_from_should_hash' 108s === OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1068562: crmsh: autopkgtest regression: unsupported operand type(s) for -: 'NoneType' and 'int'
Source: crmsh
Version: 4.6.0-1
Severity: serious
User: debian...@lists.debian.org
Usertags: regression
Dear maintainer(s),
Your package has an autopkgtest, great. However, it started to fail in
testing several days ago. Can you please investigate the situation and
fix it? I copied some of the output at the bottom of this report. This
looks like it will cause FTBFS too (I scheduled rebuilds on the
reproducible-builds infra to confirm).
The release team has announced [1] that failing autopkgtest on amd64 and
arm64 are considered RC in testing.
More information about this bug and the reason for filing it can be
found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
Paul
[1] https://lists.debian.org/debian-devel-announce/2019/07/msg2.html
https://ci.debian.net/packages/c/crmsh/testing/amd64/44624510/
105s === FAILURES
===
105s __ TestUtils.test_findln_by_timestamp
__
105s
105s self = testMethod=test_findln_by_timestamp>
105s
105s def test_findln_by_timestamp(self):
105s target_time = "Apr 03 13:10"
105s target_time_stamp =
crmutils.parse_to_timestamp(target_time+' 2023')
105s with open('pacemaker.log') as f:
105s data = f.read()
105s constants.STAMP_TYPE = utils.determin_log_format(data)
105s pacemaker_file_path = "pacemaker.log"
105s result_line = utils.findln_by_timestamp(data,
target_time_stamp, pacemaker_file_path)
105s > result_line_stamp =
utils.get_timestamp(data.split('\n')[result_line-1], pacemaker_file_path)
105s E TypeError: unsupported operand type(s) for -: 'NoneType'
and 'int'
105s
105s test_report_utils.py:825: TypeError
OpenPGP_signature.asc
Description: OpenPGP digital signature
Bug#1066763: liferea: FTBFS: dh_auto_test: error: make -j8 test "TESTSUITEFLAGS=-j8 --verbose" VERBOSE=1 returned exit code 2
control: notfixed -1 1.15.5-1 On 04-04-2024 6:04 p.m., Paul Gevers wrote: So, marking the bug as not affecting the version in testing to avoid autoremoval. And also removing the fixed version. There was only a *time* that liferea was broken (by liblzma), not a version of liferea, nor was there a version that fixed the problem. Otherwise the BTS still thinks that the version in testing is affected and our tools schedule an autoremoval. Because of the time_t transition, liferea in unstable can't migrate soon. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1068363: src:autopkgtest: flaky autopkgtest (host dependent?) on ppc64el
The mystery continues. On 04-04-2024 10:08 p.m., Paul Gevers wrote: I forgot that on amd64, autopkgtest's autopkgtest now runs in qemu which doesn't benefit yet as much from tmpfs as lxc does, so it's not a good comparison. On ci-worker13: """ root@elbrus:/tmp/autopkgtest-lxc.ww6f2cls/downtmp/build.VWV/src# df -h Filesystem Size Used Avail Use% Mounted on tmpfs 250G 44G 207G 18% / none492K 4.0K 488K 1% /dev tmpfs 126G 0 126G 0% /dev/shm tmpfs51G 52K 51G 1% /run tmpfs 5.0M 0 5.0M 0% /run/lock root@elbrus:/tmp/autopkgtest-lxc.ww6f2cls/downtmp/build.VWV/src# AUTOPKGTEST_TEST_SCHROOT=testing-amd64-sbuild tests/autopkgtest SchrootRunner.test_copy_timeout test_copy_timeout (__main__.SchrootRunner.test_copy_timeout) handling copying timeout ... ok -- Ran 1 test in 5.768s OK """ So it's not only tmpfs. I ran the test on ci-worker-ppc64el-05 (no other tests were running at the time) with adapted timeout. If I reduce the current 3 sec copy-timeout to 1 sec the test passes (2 seconds is too long, only int allowed). If I try the same thing in the opposite direction on ci-worker13, raising to 4 seconds causes failure in the """self.assertLess(huge_size, 100)""", with bumping to 5 seconds fails in the same way. ci-worker13 was running quite some tests at the same time, not sure if that's related. Anyways, it looks like we could just lower the timeout to 1 second and hope were fine for some time to come. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1068157: siridb-server: FTBFS on armhf: ./test.sh: line 18: 3276877 Segmentation fault valgrind --tool=memcheck --error-exitcode=1 --leak-check=full -q ./$OUT
Hi William, I noticed you "binNMU"-ed siridb-server in Ubuntu where it built successfully on all arches. In Debian I got the bug below reported. Any idea what the difference could be between the state of Debian and the state of Ubuntu that causes this? reproducible-builds [1] confirms that the problem exists in both unstable and testing, introduced somewhere after 2023-11-02. Paul [1] https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/siridb-server.html On 01-04-2024 12:00 a.m., Sebastian Ramacher wrote: Source: siridb-server Version: 2.0.51-2 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) X-Debbugs-Cc: sramac...@debian.org https://buildd.debian.org/status/fetch.php?pkg=siridb-server=2.0.51-2%2Bb3=armhf=1711922161 Testing expr␛[32mOK␛[0m (8.519 ms) ==3276877== ==3276877== Process terminating with default action of signal 11 (SIGSEGV) ==3276877== Access not within mapped region at address 0xFEC4F704 ==3276877==at 0x495F6F0: pcre2_compile_8 (in /usr/lib/arm-linux-gnueabihf/libpcre2-8.so.0.11.2) ==3276877== If you believe this happened as a result of a stack ==3276877== overflow in your program's main thread (unlikely but ==3276877== possible), you can try to increase the size of the ==3276877== main thread stack using the --main-stacksize= flag. ==3276877== The main thread stack size used in this run was 8388608. ./test.sh: line 18: 3276877 Segmentation fault valgrind --tool=memcheck --error-exitcode=1 --leak-check=full -q ./$OUT Cheers OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1068363: src:autopkgtest: flaky autopkgtest (host dependent?) on ppc64el
Control: retitle -1 autopkgtest: test_copy_timeout fails on tmpfs Hi, On 04-04-2024 10:08 a.m., Paul Gevers wrote: Overall, I expect the host to be *faster* than the old hosts, but ironically the tests that seems to fail is: __main__.SchrootRunner.test_copy_timeout. Yes, it's too fast. The test is testing a huge file and expects the copy to fail because it should take longer. Well, with tmpfs the autopktest inside the test passes and hence the outer test fails. https://ci.debian.net/packages/a/autopkgtest/testing/ppc64el/44781763/ 640s 16:22:15 O: handling copying timeout ... FAIL 640s 16:22:15 E: # command stdout: 640s 16:22:15 E: # to PASS ... 640s 16:22:15 E: # exit status: 0 As also amd64 has /tmp on tmpfs, I don't immediately suspect that to be the problem; I forgot that on amd64, autopkgtest's autopkgtest now runs in qemu which doesn't benefit yet as much from tmpfs as lxc does, so it's not a good comparison. Is there a way to detect if we're on tmpfs? We should skip this test then. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1066763: liferea: FTBFS: dh_auto_test: error: make -j8 test "TESTSUITEFLAGS=-j8 --verbose" VERBOSE=1 returned exit code 2
control: notfound -1 1.15.4-1 On 04-04-2024 5:42 p.m., Paul Gevers wrote: I've scheduled retries on the reproducible build infrastructure. amd64 and i386 both build fine (while on amd64 there was the same failure in the past as in this bug report). So, marking the bug as not affecting the version in testing to avoid autoremoval. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1066763: liferea: FTBFS: dh_auto_test: error: make -j8 test "TESTSUITEFLAGS=-j8 --verbose" VERBOSE=1 returned exit code 2
Hi, On Fri, 15 Mar 2024 22:42:34 +0100 Paul Gevers wrote: The problem is somewhere in liblzma. In hind-sight, this is all to likely that it's caused by CVE-2024-3094, the xz backdoor. I've scheduled retries on the reproducible build infrastructure. As the version in unstable is stuck in the time_t transition, I ping the bug (before closing unversioned if rebuilds in trixie proof the problem is gone) to reset the autoremoval timer. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1068393: src:pytest-testinfra: unsatisfied build dependency in testing: ansible
Source: pytest-testinfra Version: 10.1.0-1 Severity: serious Tags: sid trixie User: debian...@lists.debian.org Usertags: edos-uninstallable Dear maintainer(s), Dose [1] is reporting a build issue with your package, it's missing a build dependency. Obviously your build dependencies shouldn't be removed from testing, but unfortunately there are multiple scenarios where that can happen nevertheless. To uphold our social contract, Debian requires that packages can be rebuild from source in the suite we are shipping them, so currently this is a serious issue with your package in testing. Can you please investigate the situation and figure out how to resolve it? Regularly, if the build dependency is available in unstable, helping the maintainer of your Build-Depends to enable migration to testing is a great way to solve the issue. If your build dependency is gone from unstable and testing, you'll have to fix the build process in some other way. Paul Note: this bug report was sent after some quick manual checks using a template. Please reach out to me if you believe I made a mistake in my process. [1] https://qa.debian.org/dose/debcheck/src_testing_main/latest/amd64.html OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1068392: src:ruby-graphlient: unsatisfied build dependency in testing: ruby-faraday-middleware
Source: ruby-graphlient Version: 0.7.0-1 Severity: serious Tags: sid trixie User: debian...@lists.debian.org Usertags: edos-uninstallable Dear maintainer(s), Dose [1] is reporting a build issue with your package, it's missing a build dependency. Obviously your build dependencies shouldn't be removed from testing, but unfortunately there are multiple scenarios where that can happen nevertheless. To uphold our social contract, Debian requires that packages can be rebuild from source in the suite we are shipping them, so currently this is a serious issue with your package in testing. Can you please investigate the situation and figure out how to resolve it? Regularly, if the build dependency is available in unstable, helping the maintainer of your Build-Depends to enable migration to testing is a great way to solve the issue. If your build dependency is gone from unstable and testing, you'll have to fix the build process in some other way. The maintainer of ruby-faraday-middleware says it's obsolete, so you're probably in the last category. Paul Note: this bug report was sent after some quick manual checks using a template. Please reach out to me if you believe I made a mistake in my process. [1] https://qa.debian.org/dose/debcheck/src_testing_main/latest/amd64.html OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1068391: src:ruby-asana: unsatisfied build dependency in testing: ruby-faraday-middleware (>= 1.0~)
Source: ruby-asana Version: 0.10.13-2 Severity: serious Tags: sid trixie User: debian...@lists.debian.org Usertags: edos-uninstallable Dear maintainer(s), Dose [1] is reporting a build issue with your package, it's missing a build dependency. Obviously your build dependencies shouldn't be removed from testing, but unfortunately there are multiple scenarios where that can happen nevertheless. To uphold our social contract, Debian requires that packages can be rebuild from source in the suite we are shipping them, so currently this is a serious issue with your package in testing. Can you please investigate the situation and figure out how to resolve it? Regularly, if the build dependency is available in unstable, helping the maintainer of your Build-Depends to enable migration to testing is a great way to solve the issue. If your build dependency is gone from unstable and testing, you'll have to fix the build process in some other way. Apparently the maintainer of ruby-faraday-middleware thinks it should be removed, so you're probably in the last category. Paul Note: this bug report was sent after some quick manual checks using a template. Please reach out to me if you believe I made a mistake in my process. [1] https://qa.debian.org/dose/debcheck/src_testing_main/latest/amd64.html OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1068390: src:translate-toolkit: unsatisfied build dependency in testing: python3-levenshtein
Source: translate-toolkit Version: 3.12.2-1 Severity: serious Tags: sid trixie User: debian...@lists.debian.org Usertags: edos-uninstallable Dear maintainer(s), Dose [1] is reporting a build issue with your package, it's missing a build dependency. Obviously your build dependencies shouldn't be removed from testing, but unfortunately there are multiple scenarios where that can happen nevertheless. To uphold our social contract, Debian requires that packages can be rebuild from source in the suite we are shipping them, so currently this is a serious issue with your package in testing. Can you please investigate the situation and figure out how to resolve it? Regularly, if the build dependency is available in unstable, helping the maintainer of your Build-Depends to enable migration to testing is a great way to solve the issue. Paul Note: this bug report was sent after some quick manual checks using a template. Please reach out to me if you believe I made a mistake in my process. [1] https://qa.debian.org/dose/debcheck/src_testing_main/latest/amd64.html OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1068389: src:pcp: unsatisfied build dependency in testing: python3-bpfcc
Source: pcp Version: 6.2.0-1 Severity: serious Tags: sid trixie User: debian...@lists.debian.org Usertags: edos-uninstallable Dear maintainer(s), Dose [1] is reporting a build issue with your package, it's missing a build dependency. Obviously your build dependencies shouldn't be removed from testing, but unfortunately there are multiple scenarios where that can happen nevertheless. To uphold our social contract, Debian requires that packages can be rebuild from source in the suite we are shipping them, so currently this is a serious issue with your package in testing. Can you please investigate the situation and figure out how to resolve it? Regularly, if the build dependency is available in unstable, helping the maintainer of your Build-Depends to enable migration to testing is a great way to solve the issue. If your build dependency is gone from unstable and testing, you'll have to fix the build process in some other way. Paul Note: this bug report was sent after some quick manual checks using a template. Please reach out to me if you believe I made a mistake in my process. [1] https://qa.debian.org/dose/debcheck/src_testing_main/latest/amd64.html OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1068051: tilix: FTBFS on armhf, s390x (undefined reference to `_D4core8internal5array8equality...)
Control: severity -1 important Hi, On Sat, 30 Mar 2024 14:48:24 +0900 Kentaro HAYASHI wrote: tilix fails to build on armhf, s390x. But on armhf, there currently are no binaries in any suite and on s390x it never build. So, this is no regression and hence not serious (this bug is blocking migration). Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1068363: src:autopkgtest: flaky autopkgtest (host dependent?) on ppc64el
Source: autopkgtest Version: 5.33 Severity: serious User: debian...@lists.debian.org Usertags: flaky Dear maintainer(s), I looked at the results of the autopkgtest of your package. I noticed that it recently started to fail a lot on ppc64el. The failures seem related to the host that runs the test. Several weeks ago, we commissioned a new host (ci-worker-ppc64el-05) with more cores, more RAM and faster disk and most recent tests ran on that host. Apart from the hardware, we also use /tmp on tmpfs (with lots of swap). Overall, I expect the host to be *faster* than the old hosts, but ironically the tests that seems to fail is: __main__.SchrootRunner.test_copy_timeout. As also amd64 has /tmp on tmpfs, I don't immediately suspect that to be the problem; also at least one run on ci-worker-ppc64el-05 passed (44524634). Because the unstable-to-testing migration software now blocks on regressions in testing, flaky tests, i.e. tests that flip between passing and failing without changes to the list of installed packages, are causing people unrelated to your package to spend time on these tests. Don't hesitate to reach out if you need help and some more information from our infrastructure. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1064533: src:peony: fails to migrate to testing for too long: new Build-Depends not available everywhere
user release.debian.org usertag 1064533 time-t-downgrade severity 1064533 important Hi On 04-04-2024 4:25 a.m., handsome_feng wrote: If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. The excuses shows peony blocked by qtbase-opensource-src which it's beyond my contorl, and the peony and peony-extensions will been auto removedon 2024-04-07, how to deal with this? As this is part of the time_t transition and it *seems* the issue will go away once the time_t transition migrates without changes in peony, I have downgraded the severity while setting the time_t usertag for future reference. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1067705: src:siridb-server: flaky autopkgtest: curl: (7) Failed to connect to localhost port 9020 after 0 ms: Couldn't connect to server
Source: siridb-server Version: 2.0.51-2 Severity: serious User: debian...@lists.debian.org Usertags: flaky Dear maintainer(s), I looked at the results of the autopkgtest of your package. I noticed that it regularly fails. From a distance, this looks like a race condition. Should the test ensure the server is started? Because the unstable-to-testing migration software now blocks on regressions in testing, flaky tests, i.e. tests that flip between passing and failing without changes to the list of installed packages, are causing people unrelated to your package to spend time on these tests. Don't hesitate to reach out if you need help and some more information from our infrastructure. Paul [1] https://ci.debian.net/packages/s/siridb-server/testing/amd64/44324499/ 19s autopkgtest [11:10:05]: test http-api: [--- 19s * fixing /etc/siridb/siridb.conf 19s * restarting siridb-server 19s * run queries 19s get-version 19s curl: (7) Failed to connect to localhost port 9020 after 0 ms: Couldn't connect to server 19s cat: res.txt: No such file or directory 19s autopkgtest [11:10:05]: test http-api: ---] OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1067604: src:libcdk5: autopkgtest regression, tests the old version and more issues
Source: libcdk5 Version: 5.0.20230201-2 Severity: serious User: debian...@lists.debian.org Usertags: regression Dear maintainer(s), Your package has an autopkgtest, great. However, it fails. Can you please investigate the situation and fix it? I copied some of the output at the bottom of this report. I note that the version it tests against is the previous version. On top of that, this test is really, really superficial, please mark it as such [2]. Also, autopkgtest is supposed to be tested against the *installed* packages. It doesn't look like your test needs a build, can you please remove the "build-needed" restriction (it's probably what's causing the migration test to fail in view of the time_t)? The release team has announced [1] that failing autopkgtest on amd64 and arm64 are considered RC in testing. More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://lists.debian.org/debian-devel-announce/2019/07/msg2.html [2] https://release.debian.org/testing/rc_policy.txt section 6(a) (bottom) https://ci.debian.net/packages/libc/libcdk5/unstable/amd64/44302393/ 94s autopkgtest [12:22:08]: test command1: [ "$(dash cdk-config --version)" == '5.0.20180306' ] OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1064423: bug 1064423: src:gnome-keyring: FTBFS on s390x
Hi all, [s390x porters in CC, maybe they can help?] On Wed, 21 Feb 2024 22:22:54 +0100 Paul Gevers wrote: Source: gnome-keyring The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:gnome-keyring has been trying to migrate for 32 days [2]. Hence, I am filing this bug. The version in unstable (and version 42.2) failed to build on s390x. By now three uploads in a row of gnome-keyring FTBFS on s390x on Debian buildds (but at least the last ones built on Ubuntu's infrastructure). This is a key package [3], so autoremoval doesn't happen and most likely (I haven't checked) removal of the binary on s390x isn't going to be trivial (otherwise it wouldn't be key). Hence, the issue needs to be solved for gnome-keyring to migrate. Is there any progress on this? Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=gnome-keyring [3] https://release.debian.org/key-packages.html OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1067121: supysonic: flaky autopkgtest including times out
Source: supysonic Version: 0.7.6+ds-3 Severity: serious User: debian...@lists.debian.org Usertags: flaky timeout Dear maintainer(s), I looked at the results of the autopkgtest of your package. I noticed that it regularly fails. What's worse, sometimes that failure is due to it timing out after 2h47, while a normal run only takes minutes. It seems to hang. From a quick inspection, I didn't see this on amd64, but it happens on arm64, armel, armhf, i386 (failure but no timeout) ppc64el and s390x. Because the unstable-to-testing migration software now blocks on regressions in testing, flaky tests, i.e. tests that flip between passing and failing without changes to the list of installed packages, are causing people unrelated to your package to spend time on these tests. Don't hesitate to reach out if you need help and some more information from our infrastructure. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1065038: src:commit-patch: fails to migrate to testing for too long: uploader built arch:all binary
Hi, Disclaimer: I only now saw your e-mail. By default the Debian bug tracking system doesn't CC replies to the submitter of bugs. On Sat, 9 Mar 2024 13:07:04 -0800 David Caldwell wrote: > Your package is only blocked because the arch:all binary package(s) > aren't built on a buildd. Unfortunately the Debian infrastructure > doesn't allow arch:all packages to be properly binNMU'ed. Hence, I will > shortly do a no-changes source-only upload to DELAYED/15, closing this > bug. Please let me know if I should delay or cancel that upload. I think this failed. I got this email shortly afterward: > Subject: commit-patch_2.6.2-1_amd64.changes REJECTED > > Version check failed: > Your upload included the source package commit-patch, version 2.6.2-1, > however unstable already has version 2.6.2-1. > Uploads to unstable must have a higher version than present in unstable. That wasn't my upload, as I uploaded version 2.6.2-1.1 (which by now has been excepted in the archive. Is this expected or did something go wrong? Well, the upload was rejected so didn't accomplish anything. I would be surprised if that was expected by the uploader. Today I got this: > commit-patch 2.6-2.1 is marked for autoremoval from testing on 2024-03-29 > > It is affected by these RC bugs: > 1065038: commit-patch: fails to migrate to testing for too long: uploader built arch:all binary > https://bugs.debian.org/1065038 So I think things are not in a good state. What is the solution to this? My upload (in DELAYED at that time) fixed it. You could have prevented that message by doing a new upload yourself after I filed this bug (I prefer it when maintainers fix the issue themselves instead of me becoming responsible for a trivial upload). Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1066249: libmediascan: FTBFS: api_test.c:80:3: error: implicit declaration of function ‘gettimeofday’ [-Werror=implicit-function-declaration]
Hi Niko, gregor, On 14-03-2024 8:16 p.m., Niko Tyni wrote: [Paul: copying you for eyeballs as this seems to have been your pet package at some point :)] I'm receiving the bugs of this package, but thanks. It is (or I fear was) a dependency of a package I still have the ambition to package one day. On Thu, Mar 14, 2024 at 06:21:35PM +0100, gregor herrmann wrote: Not going to upload as-is, as I hardly speak any C Neither do I. Hope this helps :) I'll have a look next time I have both time and energy (hopefully within a week). Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1065395: spirv-llvm-translator-14: autopkgtest on s390x uses huge amount of disk space
Hi, On 12-03-2024 10:18 a.m., Andreas Beckmann wrote: On 06/03/2024 06.20, Paul Gevers wrote: Unfortunately the test still takes upto 33 GB at least (see below). Did you have time to test the -12 version, yet? I just did. The biggest rise I saw (and I didn't even stop parallel runners) was ~5 GB, so this version seems fine. Please let me know when the other versions are fixed too. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1065813: src:rocm-compilersupport: fails to migrate to testing for too long: clang-17 not available on mips64el
Source: rocm-compilersupport Version: 5.2.3-2 Severity: serious Control: close -1 6.0+git20231212.4510c28+dfsg-3 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:rocm-compilersupport has been trying to migrate for 31 days [2]. Hence, I am filing this bug. The version in unstable Build-Depends on clang-17, but that's not available on mips64el (tracked in bug #1056116). If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=rocm-compilersupport OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1065753: src:magic-wormhole: unsatisfied build dependency in testing: python3-magic-wormhole-mailbox-server
Source: magic-wormhole Version: 0.12.0-1.1 Severity: serious Tags: sid trixie User: debian...@lists.debian.org Usertags: edos-uninstallable Dear maintainer(s), Dose [1] is reporting a build issue with your package, it's missing a build dependency. Obviously your build dependencies shouldn't be removed from testing, but unfortunately there are multiple scenarios where that can happen nevertheless. To uphold our social contract, Debian requires that packages can be rebuild from source in the suite we are shipping them, so currently this is a serious issue with your package in testing. Can you please investigate the situation and figure out how to resolve it? Regularly, if the build dependency is available in unstable, helping the maintainer of your Build-Depends to enable migration to testing is a great way to solve the issue. If your build dependency is gone from unstable and testing, you'll have to fix the build process in some other way. Paul Note: this bug report was sent after some quick manual checks using a template. Please reach out to me if you believe I made a mistake in my process. [1] https://qa.debian.org/dose/debcheck/src_testing_main/latest/amd64.html OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1065752: src:expat: fails to migrate to testing for too long: autopkgtest breakage
Source: expat Version: 2.5.0-2 Severity: serious Control: close -1 2.6.1-1 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:expat has been trying to migrate for 31 days [2]. Hence, I am filing this bug. The version in unstable causes autopkgtest failure in multiple reverse dependencies. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=expat OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1065750: src:beaker: fails to migrate to testing for too long: Depends on new pycryptodome which isn't migrating
Source: beaker Version: 1.12.1-1.1 Severity: serious Control: close -1 1.12.1-3 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Control: block -1 by 1052336 Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:beaker has been trying to migrate for 31 days [2]. Hence, I am filing this bug. The version in unstable is blocked by pycryptodome which itself FTBFS on some architectures. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=beaker OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1065395: [Pkg-opencl-devel] Bug#1065395: spirv-llvm-translator-14: autopkgtest on s390x uses huge amount of disk space
Hi, On 06-03-2024 10:30 a.m., Andreas Beckmann wrote: Do you have the log from running that autopkgtest? I have no idea what's happening here. At least the buildd build only used 500 MB. Attached. Paul debug.log.xz Description: application/xz OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1063596: flint: FTBFS on amd64: test segfault
Hi Julien, On Sat, 24 Feb 2024 14:40:13 +0100 julien.pu...@gmail.com wrote: A case of eigenbug where you compile three times and it only fails one? If it's one in three that would be too much. For ci.d.n I'm having my "flaky" bug filing threshold between 1/5 and 1/8, but I think it should be below something like 1/20 to say it's acceptable if it's caused by the package itself. If not caused by the package itself, but toolchain issues, those really should get a decent bug and get fixed. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1065395: spirv-llvm-translator-14: autopkgtest on s390x uses huge amount of disk space
Hi Andreas, On 05-03-2024 10:16 a.m., Andreas Beckmann wrote: But first I'd like to see the s390x build happen and your confirmation that this unbreaks the CI infrastructure. But at least ppc64 and sparc64 built with 500MB instead of 40GB now ;-) Feel free to block 15-17 temporarily, too. Unfortunately the test still takes upto 33 GB at least (see below). Paul By the way, I just noticed this in the -14 log (judging from the name of the test I think that's intentional, but just checking (installing from the -16 package instead of the -14 one): Get:2 http://deb.debian.org/debian unstable/main s390x spirv-headers all 1.6.1+1.3.275.0-1 [118 kB] root@ci-worker-s390x-01:~# while true ; do df -h /scratch/ | grep mapper ; sleep 10 ; done /dev/mapper/3600507630affd250004a 196G 27G 160G 15% /scratch /dev/mapper/3600507630affd250004a 196G 27G 160G 15% /scratch /dev/mapper/3600507630affd250004a 196G 27G 160G 15% /scratch /dev/mapper/3600507630affd250004a 196G 27G 160G 15% /scratch /dev/mapper/3600507630affd250004a 196G 27G 160G 15% /scratch /dev/mapper/3600507630affd250004a 196G 27G 160G 15% /scratch /dev/mapper/3600507630affd250004a 196G 27G 160G 15% /scratch /dev/mapper/3600507630affd250004a 196G 27G 159G 15% /scratch /dev/mapper/3600507630affd250004a 196G 28G 159G 15% /scratch /dev/mapper/3600507630affd250004a 196G 28G 159G 15% /scratch /dev/mapper/3600507630affd250004a 196G 28G 159G 15% /scratch /dev/mapper/3600507630affd250004a 196G 28G 159G 15% /scratch /dev/mapper/3600507630affd250004a 196G 29G 158G 16% /scratch /dev/mapper/3600507630affd250004a 196G 29G 158G 16% /scratch /dev/mapper/3600507630affd250004a 196G 29G 158G 16% /scratch /dev/mapper/3600507630affd250004a 196G 29G 158G 16% /scratch /dev/mapper/3600507630affd250004a 196G 29G 157G 16% /scratch /dev/mapper/3600507630affd250004a 196G 29G 157G 16% /scratch /dev/mapper/3600507630affd250004a 196G 30G 157G 16% /scratch /dev/mapper/3600507630affd250004a 196G 30G 157G 16% /scratch /dev/mapper/3600507630affd250004a 196G 28G 159G 15% /scratch /dev/mapper/3600507630affd250004a 196G 28G 159G 15% /scratch /dev/mapper/3600507630affd250004a 196G 28G 159G 15% /scratch /dev/mapper/3600507630affd250004a 196G 28G 159G 15% /scratch /dev/mapper/3600507630affd250004a 196G 29G 158G 16% /scratch /dev/mapper/3600507630affd250004a 196G 34G 153G 19% /scratch /dev/mapper/3600507630affd250004a 196G 44G 143G 24% /scratch /dev/mapper/3600507630affd250004a 196G 53G 133G 29% /scratch /dev/mapper/3600507630affd250004a 196G 62G 124G 34% /scratch /dev/mapper/3600507630affd250004a 196G 70G 117G 38% /scratch /dev/mapper/3600507630affd250004a 196G 28G 159G 15% /scratch /dev/mapper/3600507630affd250004a 196G 28G 159G 15% /scratch /dev/mapper/3600507630affd250004a 196G 28G 159G 15% /scratch /dev/mapper/3600507630affd250004a 196G 29G 158G 16% /scratch /dev/mapper/3600507630affd250004a 196G 27G 160G 15% /scratch /dev/mapper/3600507630affd250004a 196G 27G 160G 15% /scratch /dev/mapper/3600507630affd250004a 196G 27G 160G 15% /scratch /dev/mapper/3600507630affd250004a 196G 27G 160G 15% /scratch /dev/mapper/3600507630affd250004a 196G 27G 160G 15% /scratch OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1065395: spirv-llvm-translator-14: autopkgtest on s390x uses huge amount of disk space
Hi On 05-03-2024 10:16 a.m., Andreas Beckmann wrote: Feel free to block 15-17 temporarily, too. I already did that ;). I'll try when I see 14 in the archive on s390x. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1065395: spirv-llvm-translator-14: autopkgtest on s390x uses huge amount of disk space
Hi Andreas, Thanks for the upload. On 04-03-2024 12:26 p.m., Andreas Beckmann wrote: Control: forwarded -1 https://github.com/KhronosGroup/SPIRV-LLVM-Translator/issues/2397 On 03/03/2024 20.52, Paul Gevers wrote: Source: spirv-llvm-translator-14 Version: 14.0.0-10 In the upstream report you mention it's the same across all versions and yesterday we had the same problem with -15. Will you fix the other versions too? Do you want me to clone this bug for that? Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1065412: src:pytables: fails to migrate to testing for too long: old s390x binary left around
Source: pytables Version: 3.7.0-10 Severity: serious Control: close -1 3.9.2-1 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Control: block -1 by 1061661 Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:pytables has been trying to migrate for 64 days [2]. Hence, I am filing this bug. As suggested in bug 1061661, the s390x binary needs to be removed by ftp-master. Somebody needs to request it. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=pytables OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1065395: spirv-llvm-translator-14: autopkgtest on s390x uses huge amount of disk space
Source: spirv-llvm-translator-14 Version: 14.0.0-10 Severity: serious X-Debbugs-CC: debian...@lists.debian.org User: debian...@lists.debian.org Usertags: issue Dear maintainers, Since a couple of days, our workers on s390x are dying because some test is filling up all disk space. Several days ago, I wrongly suspected src:fenics-dolfinx (bug #1064995) and added it to our reject-list. It didn't solve the issue, so today I spend more time on finding the culprit. Basically every spike above 40% in the graph [1] is a moment that we see issues like: Feb 28 05:38:18 ci-worker-s390x-01 debci[1738391]: gzip: /tmp/debci-worker-43383540-cNnbLE372K/autopkgtest-incoming/testing/s390x/f/fenics-dolfinx/43383540/log.gz: No space left on device Feb 28 05:38:18 ci-worker-s390x-01 debci[1424101]: E: Test for package fenics-dolfinx produced no exit code, aborting One of the suspects started to be spirv-llvm-translator-14, so I ran its autopkgtest manually, while logging disk use every 10 seconds (I started slightly delayed because I monitored the wrong partition first). As you can see below, during the test it grows from 17 GB (at the end) to its peak at 179 GB. That's not acceptable on our infrastructure. One file I happened to spot on the way was build/test/test_output/DebugInfo/Generic/Output/two-cus-from-same-file.ll.tmp: -rw-r--r-- 1 root root 41G Mar 3 19:18 two-cus-from-same-file.ll.tmp I have added spirv-llvm-translator-14 to our reject-list on s390x. As this seems to be a rather new issue, I'm wondering if it's due to: * Add build-needed autopkgtest for spirv-headers compat check. Or maybe something in the toolchain that broke on s390x? Paul [1] https://ci.debian.net/munin/ci-worker-s390x-01/ci-worker-s390x-01/df.html /dev/mapper/3600507630affd250004a 196G 40G 146G 22% /scratch /dev/mapper/3600507630affd250004a 196G 49G 138G 27% /scratch /dev/mapper/3600507630affd250004a 196G 57G 130G 31% /scratch /dev/mapper/3600507630affd250004a 196G 65G 122G 35% /scratch /dev/mapper/3600507630affd250004a 196G 66G 121G 36% /scratch /dev/mapper/3600507630affd250004a 196G 67G 120G 36% /scratch /dev/mapper/3600507630affd250004a 196G 70G 117G 38% /scratch /dev/mapper/3600507630affd250004a 196G 73G 114G 40% /scratch /dev/mapper/3600507630affd250004a 196G 76G 111G 41% /scratch /dev/mapper/3600507630affd250004a 196G 79G 108G 43% /scratch /dev/mapper/3600507630affd250004a 196G 83G 104G 45% /scratch /dev/mapper/3600507630affd250004a 196G 85G 101G 46% /scratch /dev/mapper/3600507630affd250004a 196G 88G 98G 48% /scratch /dev/mapper/3600507630affd250004a 196G 92G 95G 50% /scratch /dev/mapper/3600507630affd250004a 196G 95G 92G 51% /scratch /dev/mapper/3600507630affd250004a 196G 98G 89G 53% /scratch /dev/mapper/3600507630affd250004a 196G 101G 86G 54% /scratch /dev/mapper/3600507630affd250004a 196G 104G 83G 56% /scratch /dev/mapper/3600507630affd250004a 196G 107G 80G 58% /scratch /dev/mapper/3600507630affd250004a 196G 65G 122G 35% /scratch /dev/mapper/3600507630affd250004a 196G 65G 122G 35% /scratch /dev/mapper/3600507630affd250004a 196G 66G 121G 36% /scratch /dev/mapper/3600507630affd250004a 196G 68G 118G 37% /scratch /dev/mapper/3600507630affd250004a 196G 72G 115G 39% /scratch /dev/mapper/3600507630affd250004a 196G 75G 112G 41% /scratch /dev/mapper/3600507630affd250004a 196G 78G 109G 42% /scratch /dev/mapper/3600507630affd250004a 196G 81G 106G 44% /scratch /dev/mapper/3600507630affd250004a 196G 85G 102G 46% /scratch /dev/mapper/3600507630affd250004a 196G 87G 99G 47% /scratch /dev/mapper/3600507630affd250004a 196G 90G 96G 49% /scratch /dev/mapper/3600507630affd250004a 196G 94G 93G 51% /scratch /dev/mapper/3600507630affd250004a 196G 97G 90G 52% /scratch /dev/mapper/3600507630affd250004a 196G 100G 87G 54% /scratch /dev/mapper/3600507630affd250004a 196G 103G 84G 56% /scratch /dev/mapper/3600507630affd250004a 196G 106G 81G 57% /scratch /dev/mapper/3600507630affd250004a 196G 109G 78G 59% /scratch /dev/mapper/3600507630affd250004a 196G 112G 74G 61% /scratch /dev/mapper/3600507630affd250004a 196G 116G 71G 63% /scratch /dev/mapper/3600507630affd250004a 196G 119G 68G 64% /scratch /dev/mapper/3600507630affd250004a 196G 123G 64G 66% /scratch /dev/mapper/3600507630affd250004a 196G 126G 61G 68%
Bug#1065341: src:openstructure: unsatisfied build dependency in testing: sip-dev
Source: openstructure Version: 2.5.0-1 Severity: serious Tags: sid trixie User: debian...@lists.debian.org Usertags: edos-uninstallable Control: block -1 by 1060745 Dear maintainer(s), Dose [1] is reporting a build issue with your package, it's missing a build dependency. Obviously your build dependencies shouldn't be removed from testing, but unfortunately there are multiple scenarios where that can happen nevertheless. To uphold our social contract, Debian requires that packages can be rebuild from source in the suite we are shipping them, so currently this is a serious issue with your package in testing. Bug 1060745 was filed about this and apparently the issue is already fixed in experimental, because it's closed. However, sip4 has been removed from testing due to its RC bug, and I don't expect it to come back. Can you please investigate the situation and figure out how to resolve it? Paul Note: this bug report was sent after some quick manual checks using a template. Please reach out to me if you believe I made a mistake in my process. [1] https://qa.debian.org/dose/debcheck/src_testing_main/latest/amd64.html OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1065340: src:guidata: unsatisfied build dependency in testing: python3-sip
Source: guidata Version: 3.0.4+dfsg1-1 Severity: serious Tags: sid trixie User: debian...@lists.debian.org Usertags: edos-uninstallable Control: block -1 by 1060742 Dear maintainer(s), Dose [1] is reporting a build issue with your package, it's missing a build dependency. Obviously your build dependencies shouldn't be removed from testing, but unfortunately there are multiple scenarios where that can happen nevertheless. To uphold our social contract, Debian requires that packages can be rebuild from source in the suite we are shipping them, so currently this is a serious issue with your package in testing. Bug #1060742 was filed earlier to warn you about the issue; python3-sip has now been removed from testing due to its RC bug. Can you please investigate the situation and figure out how to resolve it? Paul Note: this bug report was sent after some quick manual checks using a template. Please reach out to me if you believe I made a mistake in my process. [1] https://qa.debian.org/dose/debcheck/src_testing_main/latest/amd64.html OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1065339: src:r-cran-rstanarm: fails to migrate to testing for too long: FTBFS on mips64el
Source: r-cran-rstanarm Version: 2.26.1-2 Severity: serious Control: close -1 2.32.1-1 Tags: sid trixie ftbfs User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:r-cran-rstanarm has been trying to migrate for 31 days [2]. Hence, I am filing this bug. The version in unstable failed to build on mips64el. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=r-cran-rstanarm OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1065338: src:r-cran-rpact: fails to migrate to testing for too long: autopkgtest failures
Source: r-cran-rpact Version: 3.4.0-1 Severity: serious Control: close -1 3.5.0-1 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:r-cran-rpact has been trying to migrate for 31 days [2]. Hence, I am filing this bug. The version in unstable fails its own autopkgtest on some architectures: arm64, ppc64el and s390x (and i386, but that's not a regression). If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=r-cran-rpact OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1065337: src:r-cran-igraph: fails to migrate to testing for too long: FTBFS on32 bits
Source: r-cran-igraph Version: 1.6.0-1 Severity: serious Control: close -1 2.0.1.1-1 Tags: sid trixie ftbfs User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:r-cran-igraph has been trying to migrate for 31 days [2]. Hence, I am filing this bug. The version in unstable failed to build on armel, armhf and i386 (our 32 bits architectures). If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=r-cran-igraph OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1065324: src:glslang: fails to migrate to testing for too long: unresolved RC bug and autopkgtest failure
Source: glslang Version: 13.1.1-3 Severity: serious Control: close -1 14.0.0-2 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:glslang has been trying to migrate for 32 days [2]. Hence, I am filing this bug. The version in unstable has an unresolved RC bug and its own autopkgtest fail (seems related). If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=glslang OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1065044: src:gnome-shell-extension-dash-to-panel: fails to migrate to testing for too long: unsatisfiable dependency
Source: gnome-shell-extension-dash-to-panel Version: 56-1 Severity: serious Control: close -1 60-1~exp1 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:gnome-shell-extension-dash-to-panel has been trying to migrate for 36 days [2]. Hence, I am filing this bug. The version in unstable (with ~exp1 version!) fails to install because gnome-shell isn't at a high enough version yet (it would work in experimental). If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=gnome-shell-extension-dash-to-panel OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1065041: src:racket-mode: fails to migrate to testing for too long: autopkgtest failure
Source: racket-mode Version: 20231222git0-1 Severity: serious Control: close -1 20240129git0-1 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:racket-mode has been trying to migrate for 31 days [2]. Hence, I am filing this bug. The version in unstable fails its own autopkgtest. By the looks of it, due to progression (but I might be reading the logs wrong): """ 162s Ran 15 tests, 11 results as expected, 1 unexpected, 3 skipped (2024-02-28 18:16:14+, 116.541772 sec) """ If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=racket-mode OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1065040: src:uncrustify: fails to migrate to testing for too long: FTBFS on mips64el
Source: uncrustify Version: 0.72.0+dfsg1-2 Severity: serious Control: close -1 0.78.1+dfsg1-1 Tags: sid trixie ftbfs User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:uncrustify has been trying to migrate for 32 days [2]. Hence, I am filing this bug. The version in unstable failed to build on mips64el. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul PS: bug 867376 is still open; seems like it could just be closed [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=uncrustify OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1065038: src:commit-patch: fails to migrate to testing for too long: uploader built arch:all binary
Source: commit-patch Version: 2.6-2.1 Severity: serious Control: close -1 2.6.2-1 X-Debbugs-CC: dko...@debian.org Tags: sid trixie pending User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:commit-patch has been trying to migrate for 31 days [2]. Hence, I am filing this bug. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. Your package is only blocked because the arch:all binary package(s) aren't built on a buildd. Unfortunately the Debian infrastructure doesn't allow arch:all packages to be properly binNMU'ed. Hence, I will shortly do a no-changes source-only upload to DELAYED/15, closing this bug. Please let me know if I should delay or cancel that upload. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=commit-patch OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1065022: libglib2.0-0t64: t64 transition breaks the systems
Hi, On 29-02-2024 4:47 a.m., Christoph Anton Mitterer wrote: @d-d: - How can it happen that purge *t64 packages and at the same time install the previous package, and then the so file is missing? I mean it's clear that they use the same name, but shouldn't DPKG handle the cleanly? Well, officially downgrading isn't supported (although it typically works) *and* losing files is one of the problems of our merged-/usr solution (see [1]). I *suspect* this might be the cause. We're working hard (well, helmut is) to protect us and our users from loosing files on upgrades. We don't protect against downgrades. Obviously there might be issues, but you are running unstable *during* a transition. You have to expect some troubles. Thanks for the information, let's see if this is a real issue or not. Paul [1] https://subdivi.de/~helmut/dep17.html OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1064922: src:r-cran-gbm: fails to migrate to testing for too long: autopkgtest regression
Source: r-cran-gbm Version: 2.1.8.1-1 Severity: serious Control: close -1 2.1.9-1 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:r-cran-gbm has been trying to migrate for 31 days [2]. Hence, I am filing this bug. The version in unstable fails its own autopkgtest everywhere except on amd64 and i386. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=r-cran-gbm OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1064921: src:r-cran-estimatr: fails to migrate to testing for too long: autopkgtest regression on i386
Source: r-cran-estimatr Version: 1.0.0-3 Severity: serious Control: close -1 1.0.2-1 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:r-cran-estimatr has been trying to migrate for 31 days [2]. Hence, I am filing this bug. The version in unstable fails its own autopkgtest on i386. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=r-cran-estimatr OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1059995: pdns: flaky autopkgtest (host dependent): pdns.service: Failed to set up IPC namespacing: Resource temporarily unavailable
Hi, On Fri, 26 Jan 2024 11:31:37 +0100 Chris Hofstaedtler wrote: Paul Gevers noted that src:pdns's autopkgtests fail every so often on a large amd64 debci worker and on s390x workers. Apparently a similar problem can be seen in src:pdns-recursor's debci runs. The issue (or at least some issue) seems to be kernel related. Due to issues with the backports kernel on arm64, we had to revert to the bookworm kernel and now pdns fails on arm64 too. On ppc64el and riscv64 the test passes for the last two months, both run a newer kernel (backports or even sid). However, s390x also runs a backports kernel and the issue still exists there. Paul By the way, if you want to use "exit 77" when conditions are not met, you also need to set the skippable restriction on those tests, otherwise the exit code is used like any other. OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1064670: nut: flaky autopkgtest: Test daemons using PID files ... FAIL
Source: nut Version: 2.8.1-3 Severity: serious User: debian...@lists.debian.org Usertags: flaky Dear maintainer(s), I looked at the results of the autopkgtest of your package. I noticed that it regularly fails, e.g about half the time on armel. It seems that the solution for bug #1023530 wasn't enough. Because the unstable-to-testing migration software now blocks on regressions in testing, flaky tests, i.e. tests that flip between passing and failing without changes to the list of installed packages, are causing people unrelated to your package to spend time on these tests. Don't hesitate to reach out if you need help and some more information from our infrastructure. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1063799: Bug#1052429: fixed in snapd-glib 1.63-5.1
Control: clone -1 -2 Control: retitle -2 FTBFS on mips64el, ppc64el and s390x Control: reopen -2 Hi, On 25-02-2024 5:25 p.m., Bastian Germann wrote: As I have already written in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1063799#16 this is not true. The failing architectures also fail without our NMU's change. Sorry, I somehow missed that message. I'm cloning, reopening and retitling the clone to make this more visible. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1063799: Bug#1052429: fixed in snapd-glib 1.63-5.1
Hi Bastian, Bo, On Thu, 11 Jan 2024 00:07:10 + Debian FTP Masters wrote: Maintainer: Ayatana Packagers Changed-By: Bo YU Closes: 1052429 Changes: snapd-glib (1.63-5.1) unstable; urgency=medium . * Non-maintainer upload. * Update libsnapd-qt-2-1.symbols to support riscv64. (Closes: #1052429) May I remind you that this upload broke the mips64el, ppc64el and s390x builds as reported in bug 1063799. Can you please have a look and fix? It seems these added symbols are not exclusive to riscv64 and your patch is wrong. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1064590: src:aflplusplus: fails to migrate to testing for too long: Build-Depends not available on mips64el
Source: aflplusplus Version: 4.08c-1 Severity: serious Control: close -1 4.09c-1 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:aflplusplus has been trying to migrate for 31 days [2]. Hence, I am filing this bug. The version in unstable has a new Build-Dependency that's not available on mips64el. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=aflplusplus OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1064533: src:peony: fails to migrate to testing for too long: new Build-Depends not available everywhere
Source: peony Version: 3.2.4-2 Severity: serious Control: close -1 4.0.0.0-1 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:peony has been trying to migrate for 31 days [2]. Hence, I am filing this bug. The version in unstable apparently has a new Build-Depends. It's not available on armel, armhf, i386, mips64el and ppc64el. If the Build-Depends can't be worked around, you'll need to request binary removals from those architectures from unstable $(reportbug ftp.debian.org). If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=peony OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1064532: src:dt-schema: fails to migrate to testing for too long: autopkgtest failure
Source: dt-schema Version: 2022.08.2-5 Severity: serious Control: close -1 2023.11-3 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:dt-schema has been trying to migrate for 31 days [2]. Hence, I am filing this bug. The version in unstable fails its own autopkgtest. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=dt-schema OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1064531: src:amberol: unsatisfied build dependency in testing: librust-lofty-0.17-dev
Source: amberol Version: 0.10.3-2 Severity: serious Tags: sid trixie User: debian...@lists.debian.org Usertags: edos-uninstallable Dear maintainer(s), Dose [1] is reporting a build issue with your package, it's missing a build dependency. Obviously your build dependencies shouldn't be removed from testing, but unfortunately there are multiple scenarios where that can happen nevertheless. To uphold our social contract, Debian requires that packages can be rebuild from source in the suite we are shipping them, so currently this is a serious issue with your package in testing. Can you please investigate the situation and figure out how to resolve it? Regularly, if the build dependency is available in unstable, helping the maintainer of your Build-Depends to enable migration to testing is a great way to solve the issue. If your build dependency is gone from unstable and testing, you'll have to fix the build process in some other way. Paul Note: this bug report was sent after some quick manual checks using a template. Please reach out to me if you believe I made a mistake in my process. [1] https://qa.debian.org/dose/debcheck/src_testing_main/latest/amd64.html OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1064424: src:castxml: fails to migrate to testing for too long: Build-Depends not available on mips64el
Source: castxml Version: 0.6.2-2 Severity: serious Control: close -1 0.6.3-1 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:castxml has been trying to migrate for 31 days [2]. Hence, I am filing this bug. The version in unstable is missing it's build depends on mips64el and hence doesn't build. However, this package was build there in the past, so manual action is needed to resolve the matter (e.g. helping llvm-toolchain-17 maintainers to build for mips64el (bug #1062086) or by requesting castxml/mips64el removal from unstable). If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=castxml OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1064425: src:breezy: fails to migrate to testing for too long: autopkgtest failure
Source: breezy Version: 3.3.4-1.1 Severity: serious Control: close -1 3.3.5-5 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:breezy has been trying to migrate for 31 days [2]. Hence, I am filing this bug. The version in unstable fails its own autopkgtest: "No module named 'tzlocal'". If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=breezy OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1064423: src:gnome-keyring: fails to migrate to testing for too long: FTBFS on s390x
Source: gnome-keyring Version: 42.1-1 Severity: serious Control: close -1 46.1-1 Tags: sid trixie ftbfs User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:gnome-keyring has been trying to migrate for 32 days [2]. Hence, I am filing this bug. The version in unstable (and version 42.2) failed to build on s390x. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=gnome-keyring OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1064422: src:ohai: fails to migrate to testing for too long: uploader built arch:all binary
Source: ohai Version: 17.9.0-2 Severity: serious Control: close -1 18.1.3-2 Tags: sid trixie pending User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:ohai has been trying to migrate for 32 days [2]. Hence, I am filing this bug. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. Your package is only blocked because the arch:all binary package(s) aren't built on a buildd. Unfortunately the Debian infrastructure doesn't allow arch:all packages to be properly binNMU'ed. Hence, I will shortly do a no-changes source-only upload to DELAYED/15, closing this bug. Please let me know if I should delay or cancel that upload. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=ohai OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1064420: src:ruby-omniauth-alicloud: fails to migrate to testing for too long: uploader built arch:all binary
Source: ruby-omniauth-alicloud Version: 2.0.1-2 Severity: serious Control: close -1 3.0.0-2 Tags: sid trixie pending User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:ruby-omniauth-alicloud has been trying to migrate for 32 days [2]. Hence, I am filing this bug. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. Your package is only blocked because the arch:all binary package(s) aren't built on a buildd. Unfortunately the Debian infrastructure doesn't allow arch:all packages to be properly binNMU'ed. Hence, I will shortly do a no-changes source-only upload to DELAYED/15, closing this bug. Please let me know if I should delay or cancel that upload. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=ruby-omniauth-alicloud OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1064365: src:endless-sky: fails to migrate to testing for too long: FTBFS on i386 and ppc64el and unresolved RC issue
Source: endless-sky Version: 0.10.2-6 Severity: serious Control: close -1 0.10.4-1 Tags: sid trixie ftbfs User: release.debian@packages.debian.org Usertags: out-of-sync Control: block -1 by 1061241 Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:endless-sky has been trying to migrate for 31 days [2]. Hence, I am filing this bug. The version in unstable failed to build on i386 and ppc64el. It also has an unresolved RC issue: bug #1061241. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=endless-sky OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1064309: src:python-pamqp: fails to migrate to testing for too long: autopkgtest failures on 32 bit
Source: python-pamqp Version: 3.2.1-1 Severity: serious Control: close -1 3.3.0-1 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:python-pamqp has been trying to migrate for 31 days [2]. Hence, I am filing this bug. The version in unstable fails its own autopkgtest on armel, armhf and i386 with what looks like a broken test for 32 bits architectures. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=python-pamqp OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1064212: src:expeyes: fails to migrate to testing for too long: arch:all FTBFS
Source: expeyes
Version: 5.3.1+repack-1
Severity: serious
Control: close -1 5.3.1+repack-4
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync
Dear maintainer(s),
The Release Team considers packages that are out-of-sync between testing
and unstable for more than 30 days as having a Release Critical bug in
testing [1]. Your package src:expeyes has been trying to migrate for 31
days [2]. Hence, I am filing this bug. The version in unstable failed to
build on arch:all because:
"""
dpkg-gencontrol: error: the Depends field contains an arch-specific
dependency but the package 'eyes17' is architecture all
dh_gencontrol: error: dpkg-gencontrol -peyes17 -ldebian/changelog
-Tdebian/eyes17.substvars -Pdebian/eyes17 returned exit code 25
"""
I recognize the solution from our discussion on mediawiki2latex, but it
only works for arch:${not-all} binaries, as the architecture qualifiers
are resolved at build time, not at install time. If these dependencies
aren't absolutely needed, I suggest to add them to Recommends (as those
are installed by default, while still supporting armel, ppc64el and
s390x). If they are near "absolutely needed", then just have eyes17
not-installable on these architectures (which needs a hint from the
Release Team to migrate to testing).
If a package is out of sync between unstable and testing for a longer
period, this usually means that bugs in the package in testing cannot be
fixed via unstable. Additionally, blocked packages can have impact on
other packages, which makes preparing for the release more difficult.
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that
hamper the migration of their package in a timely manner.
This bug will trigger auto-removal when appropriate. As with all new
bugs, there will be at least 30 days before the package is auto-removed.
I have immediately closed this bug with the version in unstable, so if
that version or a later version migrates, this bug will no longer affect
testing. I have also tagged this bug to only affect sid and trixie, so
it doesn't affect (old-)stable.
If you believe your package is unable to migrate to testing due to
issues beyond your control, don't hesitate to contact the Release Team.
Paul
[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=expeyes
OpenPGP_signature.asc
Description: OpenPGP digital signature
Bug#1064210: src:rust-async-task: fails to migrate to testing for too long: autopkgtest failure
Source: rust-async-task Version: 4.5.0-1.1 Severity: serious Control: close -1 4.7.0-1 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:rust-async-task has been trying to migrate for 31 days [2]. Hence, I am filing this bug. The version in unstable fails its own autopkgtest. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=rust-async-task OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1064136: src:btm: unsatisfied build dependency in testing: librust-toml-edit-0.19+default-dev
Source: btm Version: 0.9.6-3 Severity: serious Tags: sid trixie User: debian...@lists.debian.org Usertags: edos-uninstallable Dear maintainer(s), Dose [1] is reporting a build issue with your package, it's missing a build dependency. Obviously your build dependencies shouldn't be removed from testing, but unfortunately there are multiple scenarios where that can happen nevertheless. To uphold our social contract, Debian requires that packages can be rebuild from source in the suite we are shipping them, so currently this is a serious issue with your package in testing. Can you please investigate the situation and figure out how to resolve it? Regularly, if the build dependency is available in unstable, helping the maintainer of your Build-Depends to enable migration to testing is a great way to solve the issue. If your build dependency is gone from unstable and testing, you'll have to fix the build process in some other way. Paul Note: this bug report was sent after some quick manual checks using a template. Please reach out to me if you believe I made a mistake in my process. [1] https://qa.debian.org/dose/debcheck/src_testing_main/latest/amd64.html OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1064135: src:r-cran-bigmemory: fails to migrate to testing for too long: autopkgtest fails on arm*, ppc64el and s390x
Source: r-cran-bigmemory Version: 4.6.1-1 Severity: serious Control: close -1 4.6.4-1 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:r-cran-bigmemory has been trying to migrate for 31 days [2]. Hence, I am filing this bug. The version in unstable added an autopkgtest (thanks for that), but it fails everywhere except on amd64 and i386. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=r-cran-bigmemory OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1061229: numpydoc: Failing autopkgtest
Control: found -1 1.5.0-1 Hi, On Sat, 20 Jan 2024 18:47:50 -0500 =?UTF-8?Q?Jeremy_B=C3=ADcha?= wrote: numpydoc's autopkgtest is failing. Matthias added a path to Ubuntu to mark it as expected fail, but without further explanation. I am attaching a version of his patch. The version in testing now fails too. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1063864: src:mediawiki2latex: fails to migrate to testing for too long: not installable on armel, mips64el and s390x
Hi, On 15-02-2024 15:56, Dirk Hünniger wrote: So could you Paul please post some information on how to do that. Maybe an example. See [1] after the first example. Replace [2] with chromium [!armel !mips64el !s390x], Paul [1] https://www.debian.org/doc/debian-policy/ch-relationships.html [2] https://sources.debian.org/src/mediawiki2latex/8.7-2/debian/control/#L51 OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1063864: src:mediawiki2latex: fails to migrate to testing for too long: not installable on armel, mips64el and s390x
Hi, On 15-02-2024 08:40, Dirk Hünniger wrote: So it still wants to build on s390x armel and mips64el. Possibly its not possible to drop support for an architecture that once was supported. This is not the solution *I* had in mind. I was thinking about just adding an architecture qualified depends on chromium, not only build on the non-chromium architectures. If you want to continue the current route, instead of hardcoding the architectures, I would add a *build*-depends on chromium to prevent building on architectures where it's not available. Then the package automatically builds on those once chromium becomes available. Once an architecture builds successfully, it requires actions from ftp-master to remove the binaries. So, $(reportbug ftp.debian.org) if the architectures are fully unsupported. So possible we need to tell the system that it can still build on all architectures, but the the dependency to chromium is only needed on all architectures but s390x armel and mips64el That's what I had in mind indeed. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1064006: src:user-mode-linux: unsatisfied build dependency in testing: linux-source-6.5
Source: user-mode-linux Version: 6.5um1 Severity: serious Tags: sid trixie User: debian...@lists.debian.org Usertags: edos-uninstallable Dear maintainer(s), Dose [1] is reporting a build issue with your package, it's missing a build dependency. Obviously your build dependencies shouldn't be removed from testing, but unfortunately there are multiple scenarios where that can happen nevertheless. To uphold our social contract, Debian requires that packages can be rebuild from source in the suite we are shipping them, so currently this is a serious issue with your package in testing. Can you please investigate the situation and figure out how to resolve it? Regularly, if the build dependency is available in unstable, helping the maintainer of your Build-Depends to enable migration to testing is a great way to solve the issue. If your build dependency is gone from unstable and testing, you'll have to fix the build process in some other way. Paul Note: this bug report was sent after some quick manual checks using a template. Please reach out to me if you believe I made a mistake in my process. [1] https://qa.debian.org/dose/debcheck/src_testing_main/latest/amd64.html OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1064004: src:cross-toolchain-base-ports: unsatisfied build dependency in testing: linux-source-6.5 (>= 6.5.8)
Source: cross-toolchain-base-ports Version: 64 Severity: serious Tags: sid trixie User: debian...@lists.debian.org Usertags: edos-uninstallable Dear maintainer(s), Dose [1] is reporting a build issue with your package, it's missing a build dependency. Obviously your build dependencies shouldn't be removed from testing, but unfortunately there are multiple scenarios where that can happen nevertheless. To uphold our social contract, Debian requires that packages can be rebuild from source in the suite we are shipping them, so currently this is a serious issue with your package in testing. Can you please investigate the situation and figure out how to resolve it? Regularly, if the build dependency is available in unstable, helping the maintainer of your Build-Depends to enable migration to testing is a great way to solve the issue. If your build dependency is gone from unstable and testing, you'll have to fix the build process in some other way. Paul Note: this bug report was sent after some quick manual checks using a template. Please reach out to me if you believe I made a mistake in my process. [1] https://qa.debian.org/dose/debcheck/src_testing_main/latest/amd64.html OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1064003: src:cross-toolchain-base: unsatisfied build dependency in testing: linux-source-6.5 (>= 6.5.8)
Source: cross-toolchain-base Version: 68 Severity: serious Tags: sid trixie User: debian...@lists.debian.org Usertags: edos-uninstallable Dear maintainer(s), Dose [1] is reporting a build issue with your package, it's missing a build dependency. Obviously your build dependencies shouldn't be removed from testing, but unfortunately there are multiple scenarios where that can happen nevertheless. To uphold our social contract, Debian requires that packages can be rebuild from source in the suite we are shipping them, so currently this is a serious issue with your package in testing. Can you please investigate the situation and figure out how to resolve it? Regularly, if the build dependency is available in unstable, helping the maintainer of your Build-Depends to enable migration to testing is a great way to solve the issue. If your build dependency is gone from unstable and testing, you'll have to fix the build process in some other way. Paul Note: this bug report was sent after some quick manual checks using a template. Please reach out to me if you believe I made a mistake in my process. [1] https://qa.debian.org/dose/debcheck/src_testing_main/latest/amd64.html OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1063864: src:mediawiki2latex: fails to migrate to testing for too long: not installable on armel, mips64el and s390x
Hi, On 14-02-2024 16:53, Dirk Hünniger wrote: If it helps to change the dependency to chromium and chromium-sandbox from Depends to Recommends I would like to ask Georges to do so. If you think the Depends is best, make it conditional on the architecture, because ideally also Recommends can be installed (so would benefit from the architecture qualifier). Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1063864: src:mediawiki2latex: fails to migrate to testing for too long: not installable on armel, mips64el and s390x
Hi, On 14-02-2024 14:27, Georges Khaznadar wrote: At the same time, https://buildd.debian.org/status/package.php?p=mediawiki2latex says that the package could be installed, I understand the confusing but the word "installed" on buildd.d.o means something else than that you can install the binaries. It means that the packages were incorporated (installed) into the archive. so its runtime dependencies are correct, on architectures: amd64, arm64, armel, armhf, i386, mips64el, ppc64el, riscv64, s390x, alpha, hurd-i386, ia64, ppc64, sparc64. Maybe you can try to install the binaries in a clean environment (I've done so, pasted below). Paul root@autopkgtest-lxc-vtalsf:/tmp/autopkgtest-lxc.c47fu43n/downtmp/build.Nel/src# apt install mediawiki2latex Reading package lists... Done Building dependency tree... Done Reading state information... 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: mediawiki2latex : Depends: chromium but it is not installable Depends: chromium-sandbox but it is not installable Recommends: calibre but it is not going to be installed Recommends: latex2rtf but it is not going to be installed Recommends: libreoffice but it is not going to be installed E: Unable to correct problems, you have held broken packages. OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1063865: src:tailspin: unsatisfied build dependency in testing: librust-terminal-size-0.2+default-dev
Source: tailspin Version: 2.0.0+dfsg-1 Severity: serious Tags: sid trixie User: debian...@lists.debian.org Usertags: edos-uninstallable Dear maintainer(s), Dose [1] is reporting a build issue with your package, it's missing a build dependency. Obviously your build dependencies shouldn't be removed from testing, but unfortunately there are multiple scenarios where that can happen nevertheless. To uphold our social contract, Debian requires that packages can be rebuild from source in the suite we are shipping them, so currently this is a serious issue with your package in testing. Can you please investigate the situation and figure out how to resolve it? Regularly, if the build dependency is available in unstable, helping the maintainer of your Build-Depends to enable migration to testing is a great way to solve the issue. If your build dependency is gone from unstable and testing, you'll have to fix the build process in some other way. Paul Note: this bug report was sent after some quick manual checks using a template. Please reach out to me if you believe I made a mistake in my process. [1] https://qa.debian.org/dose/debcheck/src_testing_main/latest/amd64.html OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1063864: src:mediawiki2latex: fails to migrate to testing for too long: not installable on armel, mips64el and s390x
Source: mediawiki2latex Version: 8.0-1 Severity: serious Control: close -1 8.7-1 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:mediawiki2latex has been trying to migrate for 31 days [2]. Hence, I am filing this bug. The version can't be installed on armel, mips64el and s390x while the package builds on those architectures. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=mediawiki2latex OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1063800: src:pinfish: fails to migrate to testing for too long: not installable on armel, armhf and i386
Source: pinfish Version: 0.1.0+ds-3 Severity: serious Control: close -1 0.1.0+ds-4 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:pinfish has been trying to migrate for 31 days [2]. Hence, I am filing this bug. It seem the version in unstable isn't installable on our 32 bit architectures. It seems like the version in testing doesn't have binaries on these architectures, while the buildd history shows they were built for the previous version, so you probably had them removed. You probably need to do this again, but I suggest to add a Build-Depends on racon to prevent accidental builds on architectures where racon isn't available (and thus the package becomes not installable). If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=pinfish OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1063799: src:snapd-glib: fails to migrate to testing for too long: FTBFS on mips64el, ppc64el and s390x
Source: snapd-glib Version: 1.63-5 Severity: serious Control: close -1 1.63-5.1 Tags: sid trixie ftbfs X-Debbugs-CC: Bo YU , b...@debian.org User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:snapd-glib has been trying to migrate for 32 days [2]. Hence, I am filing this bug. The version in unstable failed to build on mips64el, ppc64el and s390x If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=snapd-glib OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1063798: src:spaln: fails to migrate to testing for too long: FTBFS on arm64, ppc64el and s390x
Source: spaln Version: 2.4.13f+dfsg-1 Severity: serious Control: close -1 3.0.2+dfsg-1 Tags: sid trixie ftbfs User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:spaln has been trying to migrate for 32 days [2]. Hence, I am filing this bug. The version in unstable failed to build on arm64, ppc64el and s390x. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=spaln OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1063797: src:mathgl: fails to migrate to testing for too long: FTBFS on amd64 and i386
Source: mathgl Version: 8.0.1-4 Severity: serious Control: close -1 8.0.1-5 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Control: block -1 by 1063599 Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:mathgl has been trying to migrate for 34 days [2]. Hence, I am filing this bug. The version in unstable failed to build on amd64 and i386 (and arch:all), as reported in bug #1063599). Apparently now also a lot of other architectures have build problems (build depends not available) If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=mathgl OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1063796: src:plplot: fails to migrate to testing for too long: patchelf not available on mips64el
Source: plplot Version: 5.15.0+dfsg2-6 Severity: serious Control: close -1 5.15.0+dfsg2-7+deb13u1 X-Debbugs-CC: debian-m...@lists.debian.org Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:plplot has been trying to migrate for 34 days [2]. Hence, I am filing this bug. The package Build-Depends on patchelf, which has a build issue on mips64el (bug #1059752). Unfortunately patchelf is a key package, and saw a new version in the time that mips64el was allowed to be broken, so currently patchelf doesn't exist on mips64el in testing. This is impacting your package. I think that for the time being it's probably easiest to request removal of your package on mips64el. Alternatively you try to help fix the bug in patchelf (I've CC'd the mips porters to draw their attention to the problem too). If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=plplot OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1063434: src:389-ds-base: fails to migrate to testing for too long: FTBFS on 32 bits
Source: 389-ds-base Version: 2.3.4+dfsg1-1.1 Severity: serious Control: close -1 2.4.4+dfsg1-1 Tags: sid trixie ftbfs User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:389-ds-base has been trying to migrate for 31 days [2]. Hence, I am filing this bug. The version in unstable failed to build on armel, armhf and i386 (our 32 bit architectures). If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=389-ds-base OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1063433: src:gjs: fails to migrate to testing for too long: FTBFS on mips64el
Source: gjs Version: 1.78.1-3 Severity: serious Control: close -1 1.78.3-1 Tags: sid trixie ftbfs User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:gjs has been trying to migrate for 31 days [2]. Hence, I am filing this bug. The version in unstable failed to build on mips64el. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=gjs OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1063432: src:linux-apfs-rw: fails to migrate to testing for too long: RC bug and autopkgtest failure
Source: linux-apfs-rw Version: 0.3.5-1 Severity: serious Control: close -1 0.3.7-1 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Control: block -1 by 1060898 Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:linux-apfs-rw has been trying to migrate for 31 days [2]. Hence, I am filing this bug. The version in unstable has an unresolved RC bug and fails its own autopkgtest. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=linux-apfs-rw OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1063431: src:r-cran-future.apply: fails to migrate to testing for too long: autopkgtest failure
Source: r-cran-future.apply Version: 1.11.0+dfsg-1 Severity: serious Control: close -1 1.11.1+dfsg-1 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:r-cran-future.apply has been trying to migrate for 31 days [2]. Hence, I am filing this bug. The version in unstable fails its own autopkgtest on armel, armhf and i386 (our 32 bits architectures). If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=r-cran-future.apply OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1063430: src:seqan-needle: fails to migrate to testing for too long: FTBFS on amd64 and arm64
Source: seqan-needle Version: 1.0.2+ds-1 Severity: serious Control: close -1 1.0.2+ds-2 Tags: sid trixie ftbfs User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:seqan-needle has been trying to migrate for 31 days [2]. Hence, I am filing this bug. The version in unstable failed to build on amd64 and arm64. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=seqan-needle OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1063428: src:iwyu: fails to migrate to testing for too long: waiting for BD clang-17 on mips64el
Source: iwyu Version: 8.18-2 Severity: serious Control: close -1 8.21-1 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:iwyu has been trying to migrate for 32 days [2]. Hence, I am filing this bug. The version in unstable Build-Depends on several packages that are not available on mips64el. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=iwyu OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1063427: src:nng: fails to migrate to testing for too long: FTBFS on i386, ppc64el and s390x
Source: nng Version: 1.6.0-1 Severity: serious Control: close -1 1.7.2-1 Tags: sid trixie ftbfs User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:nng has been trying to migrate for 32 days [2]. Hence, I am filing this bug. The version in unstable failed to build on i386, ppc64el and s390x. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=nng OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1063426: src:node-websocket: fails to migrate to testing for too long: FTBFS on armel
Source: node-websocket Version: 1.0.34+~cs10.0.25-1 Severity: serious Control: close -1 1.0.34+~cs10.0.25-2 Tags: sid trixie ftbfs User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:node-websocket has been trying to migrate for 32 days [2]. Hence, I am filing this bug. The version in unstable failed to build on armel. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=node-websocket OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1063425: src:rust-gdk-pixbuf-sys: fails to migrate to testing for too long: autopkgtest failures
Source: rust-gdk-pixbuf-sys Version: 0.18.0-2 Severity: serious Control: close -1 0.18.0-3 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:rust-gdk-pixbuf-sys has been trying to migrate for 32 days [2]. Hence, I am filing this bug. The version in unstable fails its own autopkgtest as well as triggers other packages to fail theirs. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=rust-gdk-pixbuf-sys OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1063366: src:syncthing: fails to migrate to testing for too long: new Build-Depends not migrating
Source: syncthing Version: 1.19.2~ds1-3 Severity: serious Control: close -1 1.27.2~ds4-1 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:syncthing has been trying to migrate for 31 days [2]. Hence, I am filing this bug. The version in unstable Build-Depends on a new package that needs manual actions before it can migrate. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=syncthing OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1063365: src:python-cryptography: unsatisfied build dependency in testing: librust-pyo3-0.19-dev
Source: python-cryptography Version: 41.0.7-2 Severity: serious Tags: sid trixie User: debian...@lists.debian.org Usertags: edos-uninstallable Dear maintainer(s), Dose [1] is reporting a build issue with your package, it's missing a build dependency. Obviously your build dependencies shouldn't be removed from testing, but unfortunately there are multiple scenarios where that can happen nevertheless. To uphold our social contract, Debian requires that packages can be rebuild from source in the suite we are shipping them, so currently this is a serious issue with your package in testing. Can you please investigate the situation and figure out how to resolve it? Regularly, if the build dependency is available in unstable, helping the maintainer of your Build-Depends to enable migration to testing is a great way to solve the issue. If your build dependency is gone from unstable and testing, you'll have to fix the build process in some other way. Paul Note: this bug report was sent after some quick manual checks using a template. Please reach out to me if you believe I made a mistake in my process. [1] https://qa.debian.org/dose/debcheck/src_testing_main/latest/amd64.html OpenPGP_signature.asc Description: OpenPGP digital signature
