Bug#1074064: src:git: fails to migrate to testing for too long: triggers autopkgtest issues
Source: git Version: 1:2.43.0-1 Severity: serious Control: close -1 1:2.45.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:git has been trying to migrate for 32 days [2]. Hence, I am filing this bug. The version in unstable causes issues for at least two reverse (test) 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=git OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1074063: src:bambam: fails to migrate to testing for too long: autopkgtest regression
Source: bambam Version: 1.2.1+dfsg-1 Severity: serious Control: close -1 1.3.0+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:bambam has been trying to migrate for 32 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=bambam OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1074062: src:node-nock: fails to migrate to testing for too long: autopkgtest regression
Source: node-nock Version: 13.3.3-1 Severity: serious Control: close -1 13.5.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:node-nock 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=node-nock OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1072764: node-multiparty: FTBFS: autobuilder hangs
Hi, On Fri, 7 Jun 2024 17:23:17 +0200 Santiago Vila wrote: During a rebuild of all packages in unstable, your package failed to build: The same seems to happen on ci.d.n on all architectures. The timeout there is 1 seconds (or 2:47h). I'm going to add node-multiparty to the ci.d.n reject_list, I'll remove it once this bug is fixed. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1074021: swift: flaky autopkgtest: timeout too tight?
Source: swift
Version: 2.33.0-5
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, particularly on amd64, but all architectures
are affected. I copied the failure output of one of the recent failures
and wondered if maybe one (or more) internal timeouts are too tight. The
autopkgtest also seems to fail systematically on s390x due to
autopkgtest timeout since halfway May 2024.
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
https://ci.debian.net/data/autopkgtest/testing/amd64/s/swift/47856417/log.gz
286s ==
286s FAIL:
test.unit.proxy.controllers.test_obj.TestECObjController.test_GET_disconnect
286s
test.unit.proxy.controllers.test_obj.TestECObjController.test_GET_disconnect
286s --
286s testtools.testresult.real._StringException: Traceback (most recent
call last):
286s File
"/tmp/autopkgtest-lxc.npd7s04o/downtmp/build.4lh/src/test/unit/proxy/controllers/test_obj.py",
line 2957, in test_GET_disconnect
286s self.assertIn("Trying to read EC fragment during GET (retrying)",
286s File "/usr/lib/python3.11/unittest/case.py", line 1140, in assertIn
286s self.fail(self._formatMessage(msg, standardMsg))
286s File "/usr/lib/python3.11/unittest/case.py", line 703, in fail
286s raise self.failureException(msg)
286s AssertionError: 'Trying to read EC fragment during GET (retrying)'
not found in "ChunkWriteTimeout feeding fragments for '/a/c/o':
ChunkWriteTimeout (0.1s after 3.59s)"
OpenPGP_signature.asc
Description: OpenPGP digital signature
Bug#1073927: autopkgtest: --shell and --shell-fail are broken
Hi, On 21-06-2024 11:21 a.m., Paride Legovini wrote: qemu doesn't try to directly open a shell, it gives the following output and those methods normally work for me: Right, I probably experienced this with qemu when I was working on my commands-via-ssh implementation and thought it was due to that. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1073972: Patch for #1073972
Tags: patch The attached patch fixes #1073972. -- Plasma From 9001b719b6a7ab51c1f5fa294183e7b7b4ef5c87 Mon Sep 17 00:00:00 2001 From: "Plasma (David Paul)" Date: Thu, 20 Jun 2024 15:31:44 -0500 Subject: [PATCH] morrowind: Install Morrowind.esm correctly Closes: #1073972 --- data/morrowind.yaml | 4 ++-- debian/changelog| 2 ++ 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/data/morrowind.yaml b/data/morrowind.yaml index 67ce08e4..f6f7211e 100644 --- a/data/morrowind.yaml +++ b/data/morrowind.yaml @@ -218,8 +218,8 @@ files: Morrowind.esm?en: alternatives: - - Morrowind.bsa?en_goty - - Morrowind.bsa?en_1.0 + - Morrowind.esm?en_goty + - Morrowind.esm?en_1.0 Morrowind.ini?en: distinctive_name: false diff --git a/debian/changelog b/debian/changelog index 79c5585b..4cbb24e2 100644 --- a/debian/changelog +++ b/debian/changelog @@ -8,6 +8,8 @@ game-data-packager (79) UNRELEASED; urgency=medium - Heroes of Might and Magic 3: Handle latest GOG releases * Bug fixes: - Commander Keen series: Include original executables [Sébastien Noel] +- Morrowind: Install Morrowind.esm correctly [Plasma (David Paul)] + (Closes: #1073972) - Return to Castle Wolfenstein: Update to iortcw 1.51c, cleaning up dead download links in the process [Dmitry Baryshkov] - Unreal: Clean up dead download links [smcv] -- 2.30.2
Bug#1073927: autopkgtest: --shell and --shell-fail are broken
Hi On 20-06-2024 1:34 p.m., Paride Legovini wrote: I can confirm this behavior, which I encountered when fixing LxcRunner tests, however I only hit it when the lxc virt server. I did not use a-virt-lxc that much until recently, so I can't tell when it stopped working. So you're saying it doesn't happen with qemu? I recall I had it there too, but I might be misremembering. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1072650: src:quantlib-swig: fails to migrate to testing for too long: FTBFS on armel, armhf, i386 and riscv64
Hi Dirk, On 20-06-2024 2:17 p.m., Dirk Eddelbuettel wrote: It is a (very) big package, but it has not grown much lately. Not being able to build may lead to auto-removal which is bad, excluding an architecture is also not good. Not clear what the least bad move is here... You might be aware, but pinging the bug resets the removal timer (if not done mere hours before the actual removal). So if you intent to keep the architecture supported and you and/or the riscv64 porters are working on it, feel free to keep pinging the bug to prevent removal. If nobody finds a solution keeping riscv64, removing the architecture is a good solution. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1073927: autopkgtest: --shell and --shell-fail are broken
Package: autopkgtest
Version: 5.35
Severity: normal
Hi,
Some time ago, I already experienced on my own laptop that --shell and
--shell-fail didn't work anymore like they used to, but I feared I
messed to much while developing autopkgtest. However, today I ran
autopkgtest on one of the ci.d.n hosts to provide a testbed for
debugging to someone, but the shell I got with --shell-fail didn't work.
The shell gives a prompt, but doesn't do anything with the input. I
stopped the shell in the end with Ctrl-C. I could reproduce with
src:hello and debugging info on my system too, see the attached log.
Paul
autopkgtest [09:54:00]: test unit-tests-server: - - - - - - - - - -
results - - - - - - - - - -
unit-tests-serverFAIL non-zero exit status 1
autopkgtest [09:54:00]: - - - - - - - - - - running shell - - - - - - -
- - -
root@elbrus:/tmp/autopkgtest-lxc.iolc4ahc/downtmp/build.tDD/src# apt
install tmate
^CTraceback (most recent call last):
File "/usr/bin/autopkgtest", line 911, in
main()
File "/usr/bin/autopkgtest", line 899, in main
process_actions()
File "/usr/bin/autopkgtest", line 854, in process_actions
run_tests(tests, tests_tree)
File "/usr/bin/autopkgtest", line 199, in run_tests
testbed.run_test(tree, t, opts.env, opts.shell_fail, opts.shell,
File "/usr/share/autopkgtest/lib/adt_testbed.py", line 1406, in run_test
self.run_shell(tree.tb, ['AUTOPKGTEST_ARTIFACTS="%s"' % test_artifacts,
File "/usr/share/autopkgtest/lib/adt_testbed.py", line 1145, in run_shell
self.command('shell', [cwd or '/'] + extra_env)
File "/usr/share/autopkgtest/lib/adt_testbed.py", line 705, in command
ll = self.expect('ok', nresults)
^^^
File "/usr/share/autopkgtest/lib/adt_testbed.py", line 668, in expect
line = self.sp.stdout.readline()
^
KeyboardInterrupt
-- System Information:
Debian Release: trixie/sid
APT prefers testing
APT policy: (990, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 6.7.12-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages autopkgtest depends on:
ii apt-utils 2.9.5
ii libdpkg-perl1.22.6
ii mawk1.3.4.20240123-1
ii procps 2:4.0.4-4
ii python3 3.11.8-1
ii python3-debian 0.1.49
Versions of packages autopkgtest recommends:
ii autodep8 0.28
ii fakeroot 1.33-1
Versions of packages autopkgtest suggests:
ii docker.io20.10.25+dfsg1-3
pn fakemachine
ii genisoimage 9:1.1.11-3.5
pn incus
ii lxc 1:6.0.0a-1
pn lxd
ii ovmf 2024.05-1
pn ovmf-ia32
ii podman 4.9.4+ds1-1
ii python3-distro-info 1.7
pn qemu-efi-aarch64
pn qemu-efi-arm
pn qemu-efi-riscv64
pn qemu-system
ii qemu-utils 1:8.2.4+ds-1
ii schroot 1.6.13-3+b3
ii util-linux 2.40.1-8.1
ii vmdb20.40-1
ii zerofree 1.1.1-1+b1
-- no debconf information
paul@mulciber ~ $ autopkgtest -ddd hello --test-name=upstream-tests --shell -- lxc -ddd --sudo autopkgtest-unstable-amd64
autopkgtest: DBG: autopkgtest options: Namespace(override_control=None, only_tests=['upstream-tests'], skip_tests=None, built_binaries=True, packages=['hello'], output_dir=None, logfile=None, summary=None, verbosity=2, setup_commands=[], setup_commands_boot=[], add_apt_sources=[], add_apt_releases=[], pin_packages=[], apt_pocket=[], apt_default_release=None, enable_apt_fallback=True, copy=[], env=[], ignore_restrictions=[], user=None, gainroot=None, shell_fail=False, shell=True, timeout=0, timeout_short=None, timeout_copy=None, timeout_install=None, timeout_test=None, timeout_build=None, timeout_factor=1.0, set_lang=None, auto_control=True, build_parallel=None, needs_internet='run', validate=False)
autopkgtest: DBG: virt-runner arguments: ['lxc', '-ddd', '--sudo', 'autopkgtest-unstable-amd64']
autopkgtest: DBG: actions: [('apt-source', 'hello', False)]
autopkgtest: DBG: build binaries: True
autopkgtest: DBG: testbed init
autopkgtest [13:01:12]: starting date and time: 2024-06-20 13:01:12+0200
autopkgtest [13:01:12]: version 5.35
autopkgtest [13:01:12]: host mulciber; command line: /usr/bin/autopkgtest -ddd hello --test-name=upstream-tests --shell -- lxc -ddd --sudo autopkgtest-unstable-amd64
autopkgtest: DBG: got reply from testbed: ok
autopkgtest: DBG: testbed open, scratch=None
autopkgtest: DBG: sending command to testbed: open
autopkgtest-virt-lxc: DBG: executing open
autopkgtest-virt-lxc: DBG: execute-timeout: sudo lxc-ls
autopkgtest-virt-lxc: DBG: using container name autopkgtest-lxc-dkykg
Bug#1050237:
Hi, On 18-06-2024 7:33 p.m., t...@envs.net wrote: hello? 46 was already released, testing is still on 44 is there anything i can help with to port the new version to testing? This bug has a "blocking" bug tagged. You could try and help fixing that bug as a starter? Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1073830: gcc-14: Missing build dependency on cargo on hurd-i386
Source: gcc-14 Version: 14.1.0-2 Severity: normal User: debian-h...@lists.debian.org Usertags: hurd-i386 X-Debbugs-Cc: debian-h...@lists.debian.org Hi, gcc-14 needs to build-depend on cargo on hurd-i386 to be able to build gccrs [1]: configure: error: cargo is required to build rust Thanks, Adrian > [1] > https://buildd.debian.org/status/fetch.php?pkg=gcc-14=hurd-i386=14.1.0-2=1718795837=0 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1073808: minified inline javascript without sources
Package: libreoffice Severity: serious User: paul...@debian.org Usertags: ftp X-Debbugs-CC: ftpmas...@ftp-master.debian.org thanks there looks to be a vendored copy of jQuery in wizards/source/access2base/*.html javascript in this form has been an ongoing struggle to get our arms around as a project. Having the unminimized javascript that that was generated from in the source tarball is likely the easiest way to get to complience without modifying the code and adding a package dependency on jQuery. If there's already a copy I missed, we can just close this bug. Thank you for all your work, paultag -- ⢀⣴⠾⠻⢶⣦⠀ Paul Tagliamonte ⣾⠁⢠⠒⠀⣿⡁ https://people.debian.org/~paultag | https://pault.ag/ ⢿⡄⠘⠷⠚⠋Debian, the universal operating system. ⠈⠳⣄⠀⠀ 4096R / FEF2 EB20 16E6 A856 B98C E820 2DCD 6B5D E858 ADF3 signature.asc Description: PGP signature
Bug#1073807: windows binaries without source
Package: libreoffice Severity: serious User: paul...@debian.org Usertags: ftp X-Debbugs-CC: ftpmas...@ftp-master.debian.org thanks There are some windows binaries in testtools/source/cliversioning/version_libs/version_3_0_0.dll. The readme notes that the files aren't reproducable given the current build env. I'd usually spend a bit more time figuring out if we had source for it and can find a way to maintain them in some form, but I don't think the windows DLLs are used -- are they? If it's possible to drop them that'd be ideal; if not, I'd love to make sure we have (and maybe document in some form) where the source is for those DLLs. Thank you for all your work, paultag -- ⢀⣴⠾⠻⢶⣦⠀ Paul Tagliamonte ⣾⠁⢠⠒⠀⣿⡁ https://people.debian.org/~paultag | https://pault.ag/ ⢿⡄⠘⠷⠚⠋Debian, the universal operating system. ⠈⠳⣄⠀⠀ 4096R / FEF2 EB20 16E6 A856 B98C E820 2DCD 6B5D E858 ADF3 signature.asc Description: PGP signature
Bug#1073582: src:r-cran-vegan: fails to migrate to testing for too long: cause autopkgtest issues
Source: r-cran-vegan Version: 2.6-4+dfsg-1 Severity: serious Control: close -1 2.6-6.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-vegan has been trying to migrate for 31 days [2]. Hence, I am filing this bug. The version in unstable causes issues with autopkgtests from reverse (test) 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=r-cran-vegan OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1073046: fixed in cups 2.4.7-3
Hi Thorsten, On Sun, 2024-06-16 at 00:19 +, Debian FTP Masters wrote: >[ Thorsten Alteholz ] >* reintroduce time_t changes that were accidentally deleted > with last upload > (thanks to Michael Hudson-Doyle for this work) >* debian/rules: no test on riscv64 (Closes: #1073046) Would be great if the testsuite could be disabled for sparc64 as well if there is no prospective fix for the testsuite failures in sight. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1073520: coyote: autopkgtest regression: times out
Source: coyote Version: 2022.04.12-1 Severity: serious User: debian...@lists.debian.org Usertags: regression Dear maintainer(s), Your package has an autopkgtest, great. However, it fails since around November 2023 on ppc64el because it times out. Can you please investigate the situation and fix it? I copied some of the output at the bottom of this report. The release team has announced [1] that failing autopkgtest on amd64 and arm64 are considered RC in testing. Because it times out where a successful run took only minutes, I have added coyote to the ci.d.n reject_list for ppc64el and will remove it when this bug is closed. 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/coyote/unstable/ppc64el/46719718/ 61s % CGHISTOPLOT: NANs found in the data. NAN keyword is set to 1. 61s % Compiled module: CGERRORMSG. 10056s autopkgtest [16:55:30]: ERROR: timed out on command "su -s /bin/bash debci ... OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1073517: src:gcc-bpf: fails to migrate to testing for too long: blocked by build dependency
Source: gcc-bpf Version: 14 Severity: serious Control: close -1 15 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:gcc-bpf has been trying to migrate for 31 days [2]. Hence, I am filing this bug. The version in unstable is blocked by gcc-14 which isn't ready to migrate itself (but is key so doesn't cause autoremoval). 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=gcc-bpf OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1061075: release.debian.org: Cross compilation of kernel modules for arm64 on bookworm is broken
Control: tags -1 moreinfo Hi, On Wed, 17 Jan 2024 15:10:55 +0100 Felix Moessbauer wrote: Package: release.debian.org Severity: normal The following dependencies need to be installed to cross compile a kernel module on debian bookworm, arm64: build-essential:amd64 crossbuild-essential-arm64:amd64 linux-headers-arm64 Currently, these have conflicting dependencies around gcc or binutils: | The following packages have unmet dependencies: | g++-12 : Depends: gcc-12 (= 12.2.0-14) but it is not installable | cpp : Depends: cpp-12 (>= 12.2.0-1~) but it is not installable | g++ : Depends: gcc-12 (>= 12.2.0-1~) but it is not installable | gcc : Depends: gcc-12 (>= 12.2.0-1~) but it is not installable | dpkg-dev : Depends: binutils but it is not installable | gcc-12-aarch64-linux-gnu : Depends: binutils-aarch64-linux-gnu (>= 2.40) What kind of action do you expect from the Release Team with regard to this bug report? Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1072920: release.debian.org: force-skiptest debusine/0.3.2/riscv64
Hi, On 10-06-2024 1:30 p.m., Colin Watson wrote: Would you please consider skipping debusine's autopkgtests on riscv64 (I think the hint in the subject line is correct, but I certainly wouldn't swear to it)? armel and armhf are having issues too (they were disabled due to time_t but I enabled them again recently). I fixed most of the issues in debusine 0.3.2, but the remaining failure happens persistently on ci.debian.net and refuses to reproduce for me in an emulated local environment. It doesn't appear that the package is terribly broken on riscv64 in general, and so I don't think this needs to block its migration to testing. ci.d.n maintainer hat on: I can give you access to a testbed where the test just ran if that would help you. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1073499: src:rust-snow: fails to migrate to testing for too long: autopkgtest regression
Source: rust-snow Version: 0.9.6-1 Severity: serious Control: close -1 0.9.6-4 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Control: block -1 by 1071537 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-snow has been trying to migrate for 31 days [2]. Hence, I am filing this bug. The version in unstable fails its own autopkgtest as reported in 1071537. 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-snow OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1072650: src:quantlib-swig: fails to migrate to testing for too long: FTBFS on armel, armhf, i386 and riscv64
Hi Dirk, On 16-06-2024 2:42 p.m., Dirk Eddelbuettel wrote: I may need a hgand with riscv64. That's normally a question to the porters, in CC now, so they can have a look. The 1.34-1 revision needed some build changes I had done poorly in such a way that the -O0 no longer applied to some arches, this has been fixed in 1.34-2 so armel, armhf, i386 are good. But riskv64 still times out. Ack. Can we expand the build-time window from the (arguably already large) value? Not that I know of. Or can we (worst case) turn riskv64 builds off? That's up to you as a maintainer, but this should be last resort [1]. Don't forget to request for removal of the existing riscv64 binaries if you go this route. Please be aware of [2] if you aren't already. Paul [1] https://release.debian.org/testing/rc_policy.txt : Packages must be supported on as many architectures as is *reasonably* possible. (Emphasis mine). [2] https://lists.debian.org/debian-devel/2022/09/msg00105.html OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1072780: src:transaction: fails to migrate to testing for too long: uploader built arch:all binary
Hi, On 15-06-2024 11:38 p.m., Colin Watson wrote: This was fixed by transaction 4.0-2, and it looks like either you cancelled your upload or it was automatically dropped from the DELAYED queue. I cancelled my upload once I spotted 4.0-2. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1073218: src:vim-eblook: fails to migrate to testing for too long: uploader built arch:all binaries
Hi , On 16-06-2024 2:15 a.m., Yukiharu YABUKI wrote: I am wondering that vim-eblook package is out of sync. The excuses page [1] says: Issues preventing migration: Not built on buildd: arch all binaries uploaded by yyabuki, a new source-only upload is needed to allow migration What point is wrong? You uploaded a binary package, which for some years now is not acceptable for migration [2]. All binaries need to be build on the buildds. We can binNMU binaries, but that doesn't work for arch:all. How do I fix? Multiple options 1) Upload a new version, but only upload source, without binary packages 2) Wait, because I did the above to DELAYED [3] 3) if you have the privileges, you could reschedule my upload to DELAYED (but I doubt you have them). This package uses vim script. That is why I choose 'arch:all'. That's perfectly fine. On Fri, 14 Jun 2024 21:02:58 +0200 Paul Gevers 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. Paul [1] https://qa.debian.org/excuses.php?package=vim-eblook [2] https://lists.debian.org/debian-devel-announce/2019/07/msg2.html [3] https://ftp-master.debian.org/deferred.html OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1073230: varna: autopkgtest regression: errors and than hangs
Source: varna Version: 3-93+ds-5 Severity: serious User: debian...@lists.debian.org Usertags: regression Dear maintainer(s), Your package has an autopkgtest, great. However, it started to fail recently. Can you please investigate the situation and fix it? I copied some of the output at the bottom of this report. The release team has announced [1] that failing autopkgtest on amd64 and arm64 are considered RC in testing. Because the test seems to hang and only times out after 2:47h I have added it to our reject_list and will remove it when this bug is closed. 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 OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1073229: rust-temp-testdir: autopkgtest timeouts: test::should_not_leave_a_dangling_empty_directory hangs
Source: rust-temp-testdir Version: 0.2.3-1 Severity: serious User: debian...@lists.debian.org Usertags: timeout Dear maintainer(s), Your package has an autopkgtest, great. However, it fails. What's worse, it fails because it seems to hang and eventually times out due to autopkgtest. Can you please investigate the situation and fix it? I copied some of the output at the bottom of this report. The release team has announced [1] that failing autopkgtest on amd64 and arm64 are considered RC in testing. Also tests that time out (while normally running in much less time) are bad for our infrastructure. I have added your package to our reject_list and will remove it once this bug is closed. 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 26s test test::should_resolve_root_in_env ... FAILED 26s test test::should_resolve_rstest_temp_dir_root_name_in_env ... FAILED 26s test test::tempdir_permanent_should_do_not_remove_dir ... FAILED 26s test test::two_temp_dir_should_have_different_path ... FAILED 86s test test::should_not_leave_a_dangling_empty_directory has been running for over 60 seconds 10026s autopkgtest [09:37:55]: ERROR: timed out on command "su -s /bin/bash debci ... OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1073226: src:makedumpfile: fails to migrate to testing for too long: fails its own autopkgtest
Source: makedumpfile Version: 1:1.7.5-1 Severity: serious Control: close -1 1:1.7.5-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:makedumpfile 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. 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=makedumpfile OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1073225: src:libmodule-faker-perl: fails to migrate to testing for too long: blocked by non-migrating dependency
Source: libmodule-faker-perl Version: 0.025-1 Severity: serious Control: close -1 0.027-1 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Control: block -1 by 1071967 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:libmodule-faker-perl has been trying to migrate for 33 days [2]. Hence, I am filing this bug. The version in unstable has a new dependency that's not ready to migrate: libdata-fake-perl. 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=libmodule-faker-perl OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1073224: src:slurm-wlm: fails to migrate to testing for too long: not installable on armel, armhf and i386
Source: slurm-wlm Version: 23.11.4-2 Severity: serious Control: close -1 23.11.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:slurm-wlm has been trying to migrate for 33 days [2]. Hence, I am filing this bug. The migration software warns that slurm-wlm-basic-plugins can't be installed on armel, armhf 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=slurm-wlm OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1073223: src:strace: fails to migrate to testing for too long: FTBFS on s390x
Source: strace Version: 6.5-0.1 Severity: serious Control: close -1 6.8-2 X-Debbugs-CC: tsu.y...@gmail.com, e...@debian.org, zu...@debian.org 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:strace has been trying to migrate for 35 days [2]. Hence, I am filing this bug. The version in unstable 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=strace OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1073222: src:syncthingtray: fails to migrate to testing for too long: FTBFS on arm64 and i386
Source: syncthingtray Version: 1.4.12-1 Severity: serious Control: close -1 1.5.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:syncthingtray has been trying to migrate for 38 days [2]. Hence, I am filing this bug. The version in unstable failed to build on arm64 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=syncthingtray OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1073221: src:tpm2-tss: fails to migrate to testing for too long: FTBFS on armel and armhf
Source: tpm2-tss Version: 4.0.1-7.2 Severity: serious Control: close -1 4.1.3-1 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Control: block -1 by 1070720 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:tpm2-tss has been trying to migrate for 38 days [2]. Hence, I am filing this bug. The version in unstable failed to build on armel and armhf as reported in bug 1070720. 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=tpm2-tss OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1073219: src:ifupdown-ng: fails to migrate to testing for too long: uploader built arch:all binaries
Source: ifupdown-ng Version: 0.12.1-4 Severity: serious Control: close -1 0.12.1-5 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:ifupdown-ng has been trying to migrate for 39 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=ifupdown-ng OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1073218: src:vim-eblook: fails to migrate to testing for too long: uploader built arch:all binaries
Source: vim-eblook Version: 1.2.3+git2020-3.1 Severity: serious Control: close -1 1.4.0-1 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:vim-eblook has been trying to migrate for 37 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=vim-eblook OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1073063: ausweisapp should depend on qml6-module-qtquick-effects
On Fri, 2024-06-14 at 10:33 +0200, Sune Stolborg Vuorela wrote: > On Friday, June 14, 2024 10:25:59 AM CEST John Paul Adrian Glaubitz wrote: > > I'm not denying that. However, a package named "qml6-module-qtquick-effects" > > doesn't sound like an interpreter to me. > > > > Thus, I don't really see how I am supposed to know as a maintainer what > > packages add Depends except for trial and error. Why not have one canonical > > "qt-interpretor" package or similar that applications can depend on? > > This is a module for a interpreted language. It is not much different than a > python package might need a hardcoded dependency on python-foo if it uses > that. or a perl package might need a hardcoded dependency on libperl-foo-bar- > baz if it uses the Foo::Bar::Baz perl module for important functionality. > > all qml*-module packages are qml (interpreted language) extensions. > > And yes. trial and error - or reading the sources - is for many interpreted > languages the only way of figuring it out. Ugh, that's truly a step backwards and way to add more burden to maintainers. I guess we'll be seeing plenty of such bug reports in the future when extensions get moved around or new ones get added. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1073171: dgit fails to build libabigail source
Hi, On 14-06-2024 11:08 a.m., Ian Jackson wrote: If you reran the dgit rune with -D, we could probably see which program failed to print the errno value, and reassign the bug to that package as a request for better error handling. I now already get issues while cloning. I wonder if that is because I already used `dgit push` manually (to delayed) while not on /tmp Paul paul@mulciber /tmp $ dgit -D clone libabigail | git config -z --get-regexp --global '.*' | git config -z --get-regexp --system '.*' clone main body CD libabigail query: fetching https://api.ftp-master.debian.org/suites... canonical suite name for unstable is sid query: fetching https://git.dgit.debian.org/libabigail/info/refs... dgit-repos check_for_git => 1. + git init -q | git config -z --get-regexp --local '.*' + git config merge.dpkg-mergechangelogs.name 'debian/changelog merge driver' + git config merge.dpkg-mergechangelogs.driver 'dpkg-mergechangelogs -m %O %A %B %A' + git config user.email 'elb...@debian.org' + git config user.name 'Paul Gevers' is_gitattrs_setup: found nothing fetching existing git history git_lrfetch_sane suppl=0 specs tags/archive/debian/* tags/debian/* dgit/sid dgit-rewrite/map git_lrfetch_sane specre=(?:refs/tags\/archive\/debian\/.*)|(?:refs/tags\/debian\/.*)|(?:refs/dgit\/sid)|(?:refs/dgit\-rewrite\/map) git_lrfetch_sane iteration 0 | git ls-remote -q --refs https://git.dgit.debian.org/libabigail 'refs/tags/archive/debian/*' 'refs/tags/debian/*' refs/dgit/sid refs/dgit-rewrite/map fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. dgit: failed command: git ls-remote -q --refs https://git.dgit.debian.org/libabigail 'refs/tags/archive/debian/*' 'refs/tags/debian/*' refs/dgit/sid refs/dgit-rewrite/map dgit: error: subprocess failed with error exit status 128 clone rmonerror removing libabigail OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1023649: ghc: FTBFS haskell-random powerpc (ghc Segmentation fault)
Hi Ilias, On Thu, 2024-06-13 at 20:50 +0200, John Paul Adrian Glaubitz wrote: > > Do we still have to build an unregisterised compiler for powerpc > > or can we switch back to NCG (https://bugs.debian.org/1060196)? > > I have not verified that yet. Please let's stay unregisterised for now > and have me verify first whether the NGC has been fixed with 9.6.x or > newer. > > Please let's keep this bug report open and use #1073159 [1] for adding > the flag --disable-ld-override to EXTRA_INSTALL_CONFIGURE_FLAGS. GHC 9.6.5 still fails on powerpc with the NGC enabled: # rts/include/rts/prof/LDV.h | Run Ghc CompileHs Stage1: rts/HeapStackCheck.cmm => _build/stage1/rts/build/cmm/HeapStackCheck.debug_o | Run Ghc CompileHs Stage1: rts/PrimOps.cmm => _build/stage1/rts/build/cmm/PrimOps.p_o | Run Ghc CompileHs Stage1: rts/Updates.cmm => _build/stage1/rts/build/cmm/Updates.thr_p_o | Run Ghc CompileHs Stage1: rts/Compact.cmm => _build/stage1/rts/build/cmm/Compact.thr_p_o | Run Ghc CompileHs Stage1: rts/Exception.cmm => _build/stage1/rts/build/cmm/Exception.o | Run Ghc CompileHs Stage1: rts/PrimOps.cmm => _build/stage1/rts/build/cmm/PrimOps.debug_o | Run Ghc CompileHs Stage1: rts/StgStartup.cmm => _build/stage1/rts/build/cmm/StgStartup.debug_p_o | Run Ghc CompileHs Stage1: rts/HeapStackCheck.cmm => _build/stage1/rts/build/cmm/HeapStackCheck.p_o | Run Ghc CompileHs Stage1: rts/StgStartup.cmm => _build/stage1/rts/build/cmm/StgStartup.thr_debug_p_o | Run Ghc CompileHs Stage1: rts/StgMiscClosures.cmm => _build/stage1/rts/build/cmm/StgMiscClosures.debug_o | Run Ghc CompileHs Stage1: rts/StgMiscClosures.cmm => _build/stage1/rts/build/cmm/StgMiscClosures.p_o | Run Ghc CompileHs Stage1: rts/ContinuationOps.cmm => _build/stage1/rts/build/cmm/ContinuationOps.debug_p_o | Run Ghc CompileHs Stage1: rts/Updates.cmm => _build/stage1/rts/build/cmm/Updates.debug_p_o | Run Ghc CompileHs Stage1: rts/StgStartup.cmm => _build/stage1/rts/build/cmm/StgStartup.thr_p_o | Run Ghc CompileHs Stage1: rts/Apply.cmm => _build/stage1/rts/build/cmm/Apply.o | Run Ghc CompileHs Stage1: rts/Exception.cmm => _build/stage1/rts/build/cmm/Exception.debug_o | Run Ghc CompileHs Stage1: rts/Apply.cmm => _build/stage1/rts/build/cmm/Apply.thr_dyn_o Command line: _build/stage0/bin/ghc -Wall -Wcompat -hisuf debug_p_hi -osuf debug_p_o -hcsuf debug_p_hc -static -prof -DDEBUG -optc-DDEBUG -hide-all-packages -no-user-package-db '-package-env -' '- package-db _build/stage1/inplace/package.conf.d' '-this-unit-id rts-1.0.2' -i -i/home/glaubitz/ghc-deb-9.6.5-new/ghc-9.6.5/_build/stage1/rts/build -i/home/glaubitz/ghc-deb-9.6.5-new/ghc- 9.6.5/_build/stage1/rts/build/autogen -i/home/glaubitz/ghc-deb-9.6.5-new/ghc-9.6.5/rts -Irts/include -I_build/stage1/rts/build -I_build/stage1/rts/build/include -I_build/stage1/rts/build/@FFIIncludeDir@ -I_build/stage1/rts/build/@LibdwIncludeDir@ -Irts/include -Irts/@FFIIncludeDir@ -Irts/@LibdwIncludeDir@ -optP-include - optP_build/stage1/rts/build/autogen/cabal_macros.h -ghcversion-file=rts/include/ghcversion.h -outputdir _build/stage1/rts/build -fdiagnostics-color=always -Wnoncanonical-monad-instances -optc-Wno- error=inline -optP-Wno-nonportable-include-path -c rts/ContinuationOps.cmm -o _build/stage1/rts/build/cmm/ContinuationOps.debug_p_o -O2 -H32m -this-unit-id rts -XHaskell98 -no-global-package-db - package-db=/home/glaubitz/ghc-deb-9.6.5-new/ghc-9.6.5/_build/stage1/inplace/package.conf.d -ghcversion-file=rts/include/ghcversion.h -ghcversion-file=rts/include/ghcversion.h -haddock -Irts - I_build/stage1/rts/build '-DRtsWay="rts_debug_p"' -DFS_NAMESPACE=rts -DCOMPILING_RTS -DPROFILING -Wno-deprecated-flags -Wcpp-undef ===> Command failed with error code: 1 ghc: panic! (the 'impossible' happened) GHC version 9.6.5: PPC.Ppr.pprInstr: JMP to ForeignLabel CallStack (from HasCallStack): panic, called at compiler/GHC/CmmToAsm/PPC/Ppr.hs:591:30 in ghc:GHC.CmmToAsm.PPC.Ppr Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug Error when running Shake build system: at want, called at src/Main.hs:124:44 in main:Main * Depends on: binary-dist-dir at need, called at src/Rules/BinaryDist.hs:130:9 in main:Rules.BinaryDist * Depends on: _build/stage1/lib/package.conf.d/rts-1.0.2.conf at need, called at src/Rules/Register.hs:134:5 in main:Rules.Register * Depends on: _build/stage1/rts/build/stamp-rts-1.0.2_debug_p at need, called at src/Rules/Library.hs:144:3 in main:Rules.Library * Depends on: _build/stage1/rts/build/libHSrts-1.0.2_debug_p.a at need, called at src/Rules/Library.hs:220:5 in main:Rules.Library * Depends on: _build/stage1/rts/build/cmm/ContinuationOps.debug_p_o at cmd', called at src/Builder.hs:387:23 in main:Builder at cmdArgs, called at src/Builder.hs:540:8 in main:Builder at cmdArgs, called at src/Builder.hs:564:18 in main:Builder at cmd
Bug#1073063: ausweisapp should depend on qml6-module-qtquick-effects
On Fri, 2024-06-14 at 09:39 +0200, Sune Stolborg Vuorela wrote: > Control: severity -1 serious > > Missing dependencies are RC > > > This is a common problem with Qt6 and has been reported for a different > > dependency before, see [1]. > > It is normal for interpreted languages to have their dependencies managed > manually. This is just another version of that. I'm not denying that. However, a package named "qml6-module-qtquick-effects" doesn't sound like an interpreter to me. Thus, I don't really see how I am supposed to know as a maintainer what packages add Depends except for trial and error. Why not have one canonical "qt-interpretor" package or similar that applications can depend on? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1051237: transition: move files from / to /usr to finalize /usr-merge
Hi, On 06-06-2024 8:54 a.m., Helmut Grohne wrote: I think this is fine. Doing final checks then uploading it all. For the record, the set of base-files, bash, dash, glibc and util-linux migrated yesterday in the 16:00 UTC britney2 run after some hinting from the Release Team side (me). Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1073171: dgit fails to build libabigail source
Package: dgit Version: 11.10 Severity: normal I ran the following script (with pkg=libabigail): """ dgit clone %(pkg)s dch --nmu "source only upload to enable migration (Closes: #%(bug)s)" dch -r "" git commit . -m"Prepare d/changelog for upload" dgit --quilt=linear build-source dgit --quilt=linear -wgf --delayed=15 push """ It failed with exit status 255 after `build-source` and a lot of output like: error: unable to write file tests/data/test-alt-dwarf-file/test1-libgromacs-debug-dir/.build-id/7c/85cee9a5a59e7d0a866386b47c1674da5d201f.debug error: unable to write file tests/data/test-alt-dwarf-file/test1-libgromacs-debug-dir/.dwz/gromacs-5.0.6-4.fc22.x86_64 This is with libabigail version 2.5-1 currently in sid. Paul -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (990, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.7.12-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages dgit depends on: ii apt2.9.3 ii ca-certificates20240203 ii coreutils 9.4-3.1 ii curl 8.8.0-1 ii devscripts 2.23.7 ii dpkg-dev 1.22.6 ii dput-ng [dput] 1.39 ii git [git-core] 1:2.43.0-1+b1 ii git-buildpackage 0.9.33 ii libdpkg-perl 1.22.6 ii libjson-perl 4.1-1 ii liblist-moreutils-perl 0.430-2 ii liblocale-gettext-perl 1.07-7 ii libtext-csv-perl 2.04-1 ii libtext-glob-perl 0.11-3 ii libtext-iconv-perl 1.7-8+b3 ii libwww-curl-perl 4.17-10+b2 ii perl [libdigest-sha-perl] 5.38.2-5 Versions of packages dgit recommends: ii distro-info-data 0.62 ii liburi-perl 5.28-1 ii openssh-client [ssh-client] 1:9.7p1-5 Versions of packages dgit suggests: ii cowbuilder 0.90 ii pbuilder0.231 ii sbuild 0.85.10 -- no debconf information OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1073170: src:libabigail: fails to migrate to testing for too long: uploader built arch:all binaries
Source: libabigail Version: 2.4-3 Severity: serious Control: close -1 2.5-1 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:libabigail has been trying to migrate for 41 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=libabigail OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1073168: src:mold: fails to migrate to testing for too long: FTBFS on armel
Source: mold Version: 2.30.0+dfsg-1 Severity: serious Control: close -1 2.31.0+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:mold has been trying to migrate for 41 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=mold OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1073167: src:rxtx: fails to migrate to testing for too long: FTBFS nearly everywhere
Source: rxtx Version: 2.2.0+dfsg-2 Severity: serious Control: close -1 2.2.0+dfsg-3 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Control: block -1 by 1070417 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:rxtx has been trying to migrate for 43 days [2]. Hence, I am filing this bug. The version in unstable failed to build as reported in bug 1070417. 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=rxtx OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1073165: src:golang-golang-x-tools: fails to migrate to testing for too long: triggers autopkgtest issues
Control: merge -1 1072779 Sorry for the noise, I wasn't paying enough attention that I already filed this report earlier. On Thu, 13 Jun 2024 22:36:00 +0200 Paul Gevers wrote: Source: golang-golang-x-tools Version: 1:0.19.0+ds-1 Severity: serious Control: close -1 1:0.20.0+ds-1 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1073166: src:django-pipeline: fails to migrate to testing for too long: autopkgtest failure
Source: django-pipeline Version: 1.6.14-6 Severity: serious Control: close -1 3.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:django-pipeline has been trying to migrate for 46 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=django-pipeline OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1073165: src:golang-golang-x-tools: fails to migrate to testing for too long: triggers autopkgtest issues
Source: golang-golang-x-tools Version: 1:0.19.0+ds-1 Severity: serious Control: close -1 1:0.20.0+ds-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:golang-golang-x-tools has been trying to migrate for 47 days [2]. Hence, I am filing this bug. The version in unstable causes the autopkgtest of ycmd to fail. 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=golang-golang-x-tools OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1073159: ghc: Please include --disable-ld-override in EXTRA_INSTALL_CONFIGURE_FLAGS
Source: ghc Version: 9.4.7-5 Severity: important Tags: patch User: debian-powe...@lists.debian.org Usertags: powerpc X-Debbugs-Cc: debian-powe...@lists.debian.org Hi, after debugging the segmentation faults with the unregisterised GHC on powerpc for a long time, I finally found the culprit which is the fact that GHC is built to default to the gold linker by default. The gold linker is known to be broken on some architectures which is unlikely to change in the future as the project has been abandoned by Google [1], so it has been long disabled for several architectures in debian/rules by passing the flag --disable-ld-override in EXTRA_CONFIGURE_FLAGS. However, as I learnt today, this only affects the linker choice when building GHC but not the default linker for the actual binary packages which still defaulted to gold in /usr/lib/ghc/lib/settings. As one of the upstream developers explained to me today [2], it's necessary to pass --disable-ld-override in EXTRA_INSTALL_CONFIGURE_FLAGS as well in order to disable gold for the binary distribution, i.e. what will end up in the Debian package. Thus, please modify debian/rules to also include the flag --disable-ld-override in EXTRA_INSTALL_CONFIGURE_FLAGS: --- debian/rules.orig 2024-06-13 11:01:23.450199875 -0700 +++ debian/rules2024-06-13 11:01:26.318242288 -0700 @@ -76,6 +76,7 @@ # See also https://bugs.debian.org/1056636 ifneq (,$(filter mips mipsel powerpc powerpcspe sparc64, $(DEB_HOST_ARCH))) EXTRA_CONFIGURE_FLAGS += --disable-ld-override + EXTRA_INSTALL_CONFIGURE_FLAGS += --disable-ld-override endif ifneq (,$(filter armhf, $(DEB_HOST_ARCH))) Also attaching a patch. Thanks, Adrian > [1] https://en.wikipedia.org/wiki/Gold_(linker) > [2] https://gitlab.haskell.org/ghc/ghc/-/issues/24986#note_570504 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 --- debian/rules.orig 2024-06-13 11:01:23.450199875 -0700 +++ debian/rules2024-06-13 11:01:26.318242288 -0700 @@ -76,6 +76,7 @@ # See also https://bugs.debian.org/1056636 ifneq (,$(filter mips mipsel powerpc powerpcspe sparc64, $(DEB_HOST_ARCH))) EXTRA_CONFIGURE_FLAGS += --disable-ld-override + EXTRA_INSTALL_CONFIGURE_FLAGS += --disable-ld-override endif ifneq (,$(filter armhf, $(DEB_HOST_ARCH)))
Bug#1023649: ghc: FTBFS haskell-random powerpc (ghc Segmentation fault)
Hi Ilias, On Thu, 2024-06-13 at 21:22 +0300, Ilias Tsitsimpis wrote: > Great job! Thanks! > I completely missed the fact this needs to be passes to the bindist's > configure script as well. It took me forever to figure this out ;-). > You need to edit debian/rules here > https://sources.debian.org/src/ghc/9.4.7-5/debian/rules/#L78 > and add the following line as well: > > + EXTRA_INSTALL_CONFIGURE_FLAGS += --disable-ld-override Yes, that's what I suggested, see my patch in [1]. > I will include that in the next upload. Great, thank you. I uploaded a patched version to unreleased in the mean time. > Do we still have to build an unregisterised compiler for powerpc > or can we switch back to NCG (https://bugs.debian.org/1060196)? I have not verified that yet. Please let's stay unregisterised for now and have me verify first whether the NGC has been fixed with 9.6.x or newer. Please let's keep this bug report open and use #1073159 [1] for adding the flag --disable-ld-override to EXTRA_INSTALL_CONFIGURE_FLAGS. Adrian > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1073159 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1073014: dhcpcd: flaky autopkgtest: Obtaining network configuration for veth1 via dhcp... timed out
Hi, On 13-06-2024 3:36 a.m., Martin-Éric Racine wrote: https://ci.debian.net/packages/d/dhcpcd/unstable/amd64/ I was looking at https://ci.debian.net/packages/d/dhcpcd/testing/amd64/ Most of these pre-date your previous bug report (#1069599) about the missing Depends on systemd-timesyncd for the test. I file so many bugs, I don't keep track. I forgot I recently filed another bug for dhcpcd. Thanks for reminding me. Subsequent ones randomly timeout waiting for an IP from the DHCP server. This could well be an issue with dnsmasq, which is what we use for the test. Alternately, it could be caused by those constant fails on glibc. Without more detailed logs, I am not in a position to investigate this. Help is welcome. Well, I can't give you more logs than what your test writes. So that's in your hands, I suggest you try and make the test more verbose of what's going on, or maybe ensure some logs end up in the artifacts for inspection. Also, if dnsmasq is the problem, you might want to contact the maintainer and discuss the issue (e.g. in a bug report). From my standpoint, it's the autopkgtest of dhcpcd that's having issues and that *is* an issue for src:dhcpcd. You could reassign this bug and mark it "affects dhcpcd". I acknowledge that something fishy seems to be ongoing in the archive when new version of src:glibc binaries appear (not only with dhcpcd I mean). For now I'll not hold that against autopkgtest failures of packages too much. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1023649: ghc: FTBFS haskell-random powerpc (ghc Segmentation fault)
Hi Jeff, On Thu, 2024-06-13 at 03:50 -0400, Jeffrey Walton wrote: > > Now we just need to figure out how to actually set the default linker back > > to bfd as it was actually explicitly supposed to happen according to > > debian/rules. > > > > This will most likely also unbreak GHC on m68k. > > Good job, Adrian. That's quite a bit of work to track down the issue. Thanks. In the meantime I filed a bug upstream for this [1]. I will actually open a second bug report since this bug report is about the broken NGC on 32-bit PowerPC which is a different issue. Adrian > [1] https://gitlab.haskell.org/ghc/ghc/-/issues/24986 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1023649: ghc: FTBFS haskell-random powerpc (ghc Segmentation fault)
Hi, I finally figured out what the problem is. After realizing that the two-stage build of GHC works without problems, I realized it can be a configuration issue only and, indeed, it is. Looking at /usr/lib/ghc/lib/settings, the default linker is set to gold: "C compiler link flags", "-fuse-ld=gold" Since gold is broken on powerpc and shouldn't really be used anymore since it's basically unmaintained upstream, we must use bfd on powerpc by default. Editing the file and switching back to bfd fixes the problem for me. Now we just need to figure out how to actually set the default linker back to bfd as it was actually explicitly supposed to happen according to debian/rules. This will most likely also unbreak GHC on m68k. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1073085: hfsutils: upgrade the source package to use compat level 13
Hello Liu, On Wed, 2024-06-12 at 15:10 -0600, Zixing Liu wrote: > This patch does the following: > > * d/rules: switch to use the debhelper autoreconf template. > - d/rules: disable parallel testing. > - d/hfsutils-tcltk.links: remove, this is auto-handled by debhelper now. > * d/p/0006-Fix-memory-corruption.patch: add a patch to fix memory corruption > issues (LP: #493273). > > > Thanks for considering the patch. Thanks for your patch. I'll implement your changes in the weekend. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1072733: Sherlock package name
Any opposition to naming the importable package `sherlocklib`? The installable package (via apt) would presumably remain `sherlock` The importable module (via python) would become `sherlocklib` The binary exec would remain `sherlock`
Bug#1073078: puredata breaks pd-iemmatrix autopkgtest: it now times out
Source: puredata, pd-iemmatrix Control: found -1 puredata/0.55.0+ds-1 Control: found -1 pd-iemmatrix/0.4.0-1 Severity: serious Tags: sid trixie User: debian...@lists.debian.org Usertags: breaks needs-update Dear maintainer(s), With a recent upload of puredata the autopkgtest of pd-iemmatrix fails in testing when that autopkgtest is run with the binary packages of puredata from unstable. What's worse, where the test normally passes within 10s of seconds to 2 minutes, it now times out after 2:47 hours. It passes when run with only packages from testing. In tabular form: passfail puredata from testing0.55.0+ds-1 pd-iemmatrix from testing0.4.0-1 all others from testingfrom testing I copied some of the output at the bottom of this report. Unfortunately there's isn't much to see. Currently this regression is blocking the migration of puredata 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=puredata https://ci.debian.net/data/autopkgtest/testing/amd64/p/pd-iemmatrix/47558213/log.gz 46s /usr/bin/pd 10043s autopkgtest [07:14:01]: ERROR: timed out on command "su -s /bin/bash debci -c set -e; exec /tmp/autopkgtest-lxc.scjcgjj4/downtmp/wrapper.sh --artifacts=/tmp/autopkgtest-lxc.scjcgjj4/downtmp/run-suite-sysinstalled-artifacts --chdir=/tmp/autopkgtest-lxc.scjcgjj4/downtmp/build.pM8/src --env=DEB_BUILD_OPTIONS=parallel=64 --env=DEBIAN_FRONTEND=noninteractive --env=LANG=C.UTF-8 --unset-env=LANGUAGE --unset-env=LC_ADDRESS --unset-env=LC_ALL --unset-env=LC_COLLATE --unset-env=LC_CTYPE --unset-env=LC_IDENTIFICATION --unset-env=LC_MEASUREMENT --unset-env=LC_MESSAGES --unset-env=LC_MONETARY --unset-env=LC_NAME --unset-env=LC_NUMERIC --unset-env=LC_PAPER --unset-env=LC_TELEPHONE --unset-env=LC_TIME --script-pid-file=/tmp/autopkgtest_script_pid --source-profile --stderr=/tmp/autopkgtest-lxc.scjcgjj4/downtmp/run-suite-sysinstalled-stderr --stdout=/tmp/autopkgtest-lxc.scjcgjj4/downtmp/run-suite-sysinstalled-stdout --tmp=/tmp/autopkgtest-lxc.scjcgjj4/downtmp/autopkgtest_tmp --make-executable=/tmp/autopkgtest-lxc.scjcgjj4/downtmp/build.pM8/src/debian/tests/run-suite-sysinstalled -- /tmp/autopkgtest-lxc.scjcgjj4/downtmp/build.pM8/src/debian/tests/run-suite-sysinstalled" (kind: test) 10043s autopkgtest [07:14:01]: test run-suite-sysinstalled OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1073076: pd-iemmatrix: autopkgtest regression on s390x: failing test doesn't stop
Source: pd-iemmatrix Version: 0.4.0-1 Severity: important User: debian...@lists.debian.org Usertags: regression Dear maintainer(s), Your package has an autopkgtest, great. However, it failed to fail nicely on s390x today, triggered by an upload of puredata. The s390x host that we use for ci.d.n was running out of disk space multiple times today and I debugged it down that the culprit is pd-iemmatrix. When I manually start the test on testing with """ root@ci-worker-s390x-01:~# /usr/bin/autopkgtest --no-built-binaries --timeout=30600 --user debci --apt-upgrade --pin-packages=unstable=src:puredata '--add-apt-source=deb-src http://deb.debian.org/debian unstable main contrib non-free non-free-firmwaredeb http://deb.debian.org/debian unstable main contrib non-free non-free-firmware' pd-iemmatrix -- lxc --sudo --name elbrus autopkgtest-testing-s390x """ I see a file appearing in /tmp/autopkgtest-lxc.3gwldww1/downtmp/build.sYI/src/tests/ called runtests.log.20240612-1935.1678 which keeps on growing until I kill the test (currently at 27 GB), it ends with seemingly endless repeats of: regression-test: 301 tests passed regression-test: 0 tests failed error: quit already called with exit code 0 I'll file a bug report with puredata shortly as a pure testing run is still fine. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1073014: dhcpcd: flaky autopkgtest: Obtaining network configuration for veth1 via dhcp... timed out
Hi, On 12-06-2024 6:20 a.m., Martin-Éric Racine wrote: This is a non-bug. Please elaborate more. This package has only one test and it requires an isolation machine. amd64 is the only architecture that provides it. Other architectures will always be marked flakey. Indeed, it's annotated with isolation-machine and not tested on our infa where that's not possible to fulfill. So on those architectures the test is skipped. Additionally, looking at the tracker for this package, amd64 always passes. I filed this bug exactly because looking at the history on amd64, the package very often fails. In testing in the last 1.5 months: https://ci.debian.net/packages/d/dhcpcd/testing/amd64/47553601/ https://ci.debian.net/packages/d/dhcpcd/testing/amd64/47552634/ https://ci.debian.net/packages/d/dhcpcd/testing/amd64/47542478/ https://ci.debian.net/packages/d/dhcpcd/testing/amd64/47446840/ https://ci.debian.net/packages/d/dhcpcd/testing/amd64/47186590/ https://ci.debian.net/packages/d/dhcpcd/testing/amd64/47164143/ https://ci.debian.net/packages/d/dhcpcd/testing/amd64/47104273/ https://ci.debian.net/packages/d/dhcpcd/testing/amd64/46055187/ https://ci.debian.net/packages/d/dhcpcd/testing/amd64/46053079/ https://ci.debian.net/packages/d/dhcpcd/testing/amd64/45883612/ https://ci.debian.net/packages/d/dhcpcd/testing/amd64/45702932/ Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1073063: ausweisapp should depend on qml6-module-qtquick-effects
Control: severity -1 normal Hello Reinhard, On Wed, 2024-06-12 at 18:40 +0200, Reinhard Karcher wrote: > ausweisapp doesn't start the gui, because qml6-module-qtquick-effects > is not installed. It should depend on that package. > Installing qml6-module-qtquick-effects solves the problem. This is a common problem with Qt6 and has been reported for a different dependency before, see [1]. I haven't found a satisfactory solution as hard-coding a dependency as suggested in your bug report would mean that the package cannot undergo automatic transitions. I am therefore reducing the severity to normal as the package would otherwise be removed from testing. Adrian > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1070018#10 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1073046: cups: FTBFS on riscv64 due to testsuite timeouts
Source: cups Version: 2.4.7-2 Severity: serious Tags: ftbfs Justification: ftbfs User: debian-ri...@lists.debian.org Usertags: riscv64 X-Debbugs-Cc: debian-ri...@lists.debian.org Hello, src:cups currently FTBFS on riscv64 due to a testsuite timeout [1]: Running command tests... Performing 5.1-lpadmin.sh: FAIL Performing 5.2-lpc.sh: PASS Performing 5.3-lpq.sh: FAIL Performing 5.4-lpstat.sh: FAIL Performing 5.5-lp.sh: FAIL Performing 5.6-lpr.sh: FAIL Performing 5.7-lprm.sh: FAIL Performing 5.8-cancel.sh: FAIL Performing 5.9-lpinfo.sh: FAIL Performing restart test: ./run-stp-tests.sh: 811: kill: No such process E: Build killed with signal TERM after 600 minutes of inactivity This issue has been observed on sparc64, so it seems reproducible. Thanks, Adrian > [1] > https://buildd.debian.org/status/fetch.php?pkg=cups=riscv64=2.4.7-2=1718180226=0 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1073023: ocaml-luv: autopkgtest regression: Version 3.15 of the dune language is not supported
Source: ocaml-luv Version: 0.5.12-2 Severity: serious Tags: sid trixie User: debian...@lists.debian.org Usertags: regression Dear maintainer(s), Your package has an autopkgtest, great. However, it started to fail in testing. Can you please investigate the situation and fix it? I copied some of the output at the bottom of this report. 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 OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1073014: dhcpcd: flaky autopkgtest: Obtaining network configuration for veth1 via dhcp... timed out
Source: dhcpcd Version: 1:10.0.8-1 Severity: serious User: debian...@lists.debian.org Usertags: flaky Dear maintainer(s), I looked at the results of the autopkgtest of your package because it was tested for glibc. I noticed that it regularly fails. 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 https://ci.debian.net/packages/d/dhcpcd/testing/amd64/47186590/ [--- 86s Preparing virtual interfaces... 86s Actual changes: 86s tx-checksum-ip-generic: off 86s tx-tcp-segmentation: off [not requested] 86s tx-tcp-ecn-segmentation: off [not requested] 86s tx-tcp-mangleid-segmentation: off [not requested] 86s tx-tcp6-segmentation: off [not requested] 86s tx-checksum-sctp: off 86s Preparing dnsmasq configuration... 91s Obtaining network configuration for veth1 via dhcp... 122s timed out 122s autopkgtest [05:47:12]: test timesyncd-ntp-servers-from-dhcp: ---] OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1072990: rsync error: error in rsync protocol data stream (code 12) at token.c(481) [sender=3.2.7]
On Tue 11 Jun 2024, Norbert Schulz wrote: > > If I run rsync without 'z' option the error is: > > [receiver] exceeded --max-alloc=1073741824 setting (file=fileio.c, line=260) > rsync error: error allocating core memory buffers (code 22) at util2.c(80) > [receiver=3.2.7] > rsync: [generator] write error: Broken pipe (32) > rsync: connection unexpectedly closed (18054825 bytes received so far) > [generator] Hmm, you could be running into a memory constraint, are you transferring a very large number of files? If so, is it possible to split the transfer up into smaller parts? Thanks, Paul
Bug#1072990: rsync error: error in rsync protocol data stream (code 12) at token.c(481) [sender=3.2.7]
On Tue 11 Jun 2024, Norbert Schulz wrote: > deflate on token returned 0 (6320 bytes left) [...] > The rsync command is: > rsync -avz --numeric-ids -e ssh --delete --delete-excluded \ Could you try without the 'z' option? There were issues with compression sometimes causing errors. It's also possible that the compression is actually slowing the transfer, if the network is fast enough. Note that '-e ssh' is redundant, that has been default for a long time now. Thanks, Paul
Bug#1069498: libx86emu: FTBFS on armhf: mem.c:581:12: error: implicit declaration of function ‘inb’; did you mean ‘ins’? [-Werror=implicit-function-declaration]
Hi Guillem, On Tue, 2024-06-11 at 13:42 +0200, Guillem Jover wrote: > > I had a look at this, and it seems like this package has never really > > worked on ARM systems at all? And this was hidden due to the missing > > declarations not being an error. > > > > AFAIK, only x86 (i386 and amd64), ia64 and alpha have port I/O, other > > systems have instead memory mapped I/O, but the code in mem.c is > > unconditionally calling port I/O functions such as in*() and out*(), > > provided by glibc. > > > > Until the upstream code is ported to systems with memory mapper I/O, I > > think the "best" way to resolve this would be to restrict the > > architecture list to: > > > > any-amd64 any-i386 alpha ia64 > > The attached patch implements this. It should not affect reverse build > depending packages (only hwinfo) which is already arch restricted to > «amd64 i386». > > I'm including the arm list to confirm the above, but also in case > someone there feels like porting the library to support memory mapped > I/O? (But perhaps that's not worth the effort.) It's perfectly fine to disable libx86emu on ARM as it has already been correctly stated, there are no I/O ports on ARM so the above code won't work on ARM. I also don't expect that to change in the future, so it's not worth bothering about this in the future, especially since the upstream project hasn't been very active lately [1]. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1072831: getting memory info fails when running under lxc
On Tue 11 Jun 2024, Paul Slootman wrote:
> This works for me. Patch attached.
I see I missed the case lseek() fails with another errno.
Updated patch attached.
Paul
--- library/meminfo.c.orig 2023-07-11 11:09:18.436786212 +0200
+++ library/meminfo.c 2024-06-11 13:11:12.878627527 +0200
@@ -646,12 +646,20 @@
// clear out the soon to be 'current' values
memset(>hist.new, 0, sizeof(struct meminfo_data));
-if (-1 == info->meminfo_fd
-&& (-1 == (info->meminfo_fd = open(MEMINFO_FILE, O_RDONLY
-return 1;
-
-if (lseek(info->meminfo_fd, 0L, SEEK_SET) == -1)
-return 1;
+if (-1 == info->meminfo_fd) {
+ if (-1 == (info->meminfo_fd = open(MEMINFO_FILE, O_RDONLY)))
+ return 1;
+}
+else {
+ if (lseek(info->meminfo_fd, 0L, SEEK_SET) == -1)
+ if (ESPIPE == errno) {
+ close(info->meminfo_fd);
+ if (-1 == (info->meminfo_fd = open(MEMINFO_FILE, O_RDONLY)))
+ return 1;
+ }
+ else
+ return 1;
+}
for (;;) {
if ((size = read(info->meminfo_fd, buf, sizeof(buf)-1)) < 0) {
Bug#1072831: getting memory info fails when running under lxc
tags 1072831 patch
thanks
On Tue 11 Jun 2024, Craig Small wrote:
> Could you check to see if in the container that lxcfs has overwritten
> the /proc/meminfo file? They sometimes do this for /proc/uptime. They
> might have messed one of the lines up and choked procps; I'm thinking
> like a tab/space at the end of the line or something that looks right
> to a human but not a computer.
The /proc/meminfo in the lxc container is basically the same as that of
the host, except the total memory reflects the limit imposed on the
container. So
-MemTotal:7914164 kB$
+MemTotal:2097152 kB$
and the Slab / SReclaimable / SUnreclaim lines show 0 kB.
> I think we'll need to either run a strace on free or a debugger to see
> where exactly the issue is.
I've been doing this.
Apparently the /proc/meminfo inside the lxc container is not seekable,
errno is ESPIPE.
The code does some seeks to reset to the beginning in preparation for
rereading the file.
I've changed the code to not do an lseek() just after opening the file
(as we should be at the start of the file then anyway), and if the file
is already open, try lseek() and if that returns errno == ESPIPE, then
close and reopen the file.
This works for me. Patch attached.
I don't know whether configure needs to test for existence of ESPIPE;
I do believe it's POSIX.
Paul
--- library/meminfo.c.orig 2023-07-11 11:09:18.436786212 +0200
+++ library/meminfo.c 2024-06-11 10:41:41.643438234 +0200
@@ -646,12 +646,18 @@
// clear out the soon to be 'current' values
memset(>hist.new, 0, sizeof(struct meminfo_data));
-if (-1 == info->meminfo_fd
-&& (-1 == (info->meminfo_fd = open(MEMINFO_FILE, O_RDONLY
-return 1;
-
-if (lseek(info->meminfo_fd, 0L, SEEK_SET) == -1)
-return 1;
+if (-1 == info->meminfo_fd) {
+ if (-1 == (info->meminfo_fd = open(MEMINFO_FILE, O_RDONLY)))
+ return 1;
+}
+else {
+ if (lseek(info->meminfo_fd, 0L, SEEK_SET) == -1)
+ if (ESPIPE == errno) {
+ close(info->meminfo_fd);
+ if (-1 == (info->meminfo_fd = open(MEMINFO_FILE, O_RDONLY)))
+ return 1;
+ }
+}
for (;;) {
if ((size = read(info->meminfo_fd, buf, sizeof(buf)-1)) < 0) {
Bug#1072576: coot: save its states in HOME.
On 11/06/2024 08:15, Andrius Merkys wrote: CAUTION: This email originated from outside of the LMB: .-andrius.mer...@gmail.com-. Do not click links or open attachments unless you recognize the sender and know the content is safe. If you think this is a phishing email, please forward it to phish...@mrc-lmb.cam.ac.uk -- On 2024-06-11 07:54, Paul Emsley wrote: I have been a bit sloppy with my file names and you should not be. Let's call the "refmac-dictionary" the "ccp4-monomer-library" OK, I will rename it to 'ccp4-monomer-library'. Thanks. This is where it lives: https://github.com/MonomerLibrary/monomers Looking at coot's build-it-3-3, it seems that it downloads the monomer library from [1] from year 2016 while GitHub contains more recent releases. Will coot be able to use the newer monomer library? [1] http://www2.mrc-lmb.cam.ac.uk/personal/pemsley/coot/dependencies I don't know what is going on. I'd like it to be using a modern copy of the monomer library. I'll look at this soon. Paul.
Bug#1072576: coot: save its states in HOME.
On Wed, 5 Jun 2024 10:17:19 +0200 Andrius Merkys wrote: > On 2024-06-05 10:13, Andrius Merkys wrote: > > The REFMAC dictionary packaged in Debian as refmac-dictionary needs some > > adjustment to make usable by coot and make the messages above go away. > > I have the fix for refmac-dictionary at hand, by the way. I will upload > it soon. > > Andrius > I have been a bit sloppy with my file names and you should not be. Let's call the "refmac-dictionary" the "ccp4-monomer-library" This is where it lives: https://github.com/MonomerLibrary/monomers Paul.
Bug#1072576: coot: save its states in HOME.
On Thu, 6 Jun 2024 04:11:11 +0100 Paul Emsley wrote: > > I was unaware of xdg - I will take a look. > OK, so 1.1.09 should now read and save the state and config files in an XDG Base Directory compliant manner. I have cleaned up some of the terminal output (it is verbose because doing so helps me diagnose other people start-up problems). I will see if I can put yet more output behind a "--debug" command line flag. Paul.
Bug#1071007:
When building the rpm, I named the (rpm) package sherlock-project to have parity with PyPI, due to the same conflicting package. The importable module is still simply sherlock, however, which is _less than ideal_, and should probably be addressed. With this discussion now being had on the deb side, I just introduced the conversation about renaming last night. Still up for debate, but assuming we do decide to change it, we'll most likely use sherlock_project (again, for parity). I don't like the underscore, but it's the least likely to have conflict. I'll let you guys know of the decision. (executable would remain sherlock even if the package name changes)
Bug#1072813: release.debian.org: Help doris migrate to testing
Hi, On 09-06-2024 9:25 a.m., Antonio Valentino wrote: The main problem with non-amd64 architecture is that I do not have easy > access to them, I'm only DM. Ack I think that in the past we had binaries for other platforms but it was quite a pain. I just reread the section of the devref about autobuilding and contrib [1]. I understand it again. If it is not a big issue on your side I would prefer to keep amd64 only. Ack, will do. Paul [1] https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#source-and-binary-uploads OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#829696: xfce4-panel: Panel displayed in wrong position on startup
On Sat, 8 Apr 2023 12:49:16 +0100 "Paul \"LeoNerd\" Evans" wrote: > On Thu, 10 Nov 2022 09:20:23 +0500 > Akbarkhon Variskhanov wrote: > > > Do you still face this problem? > > Yup, still happening. Hi there, Bug is still happening in current version, 4.18.4-1+b1 One thing I notice is that the bug only happens if using sawfish as the window manager. If using xfce's default of xfwm4 then it behaves as expected. Is there any further assistance I can provide in helping to fix it? -- Paul "LeoNerd" Evans leon...@leonerd.org.uk http://www.leonerd.org.uk/ | https://metacpan.org/author/PEVANS
Bug#1072940: mailtuils: FTBFS on sparc64 due to outdated symbols file
Source: mailutils Version: 1:3.17-2 Severity: normal User: debian-sp...@lists.debian.org Usertags: sparc64 X-Debbugs-Cc: debian-sp...@lists.debian.org Hello, mailutils fails to build from source on sparc64 due to an outdated symbols file [1]: dpkg-gensymbols: warning: debian/libmailutils9t64/DEBIAN/symbols doesn't match completely debian/libmailutils9t64.symbols --- debian/libmailutils9t64.symbols (libmailutils9t64_1:3.17-2_sparc64) +++ dpkg-gensymbolsjTYNfd 2024-06-09 13:24:35.314252567 + @@ -1928,6 +1928,7 @@ mu_py_script_run@Base 1:3.17 libmu_scm.so.9 libmailutils9t64 #MINVER# * Build-Depends-Package: libmailutils-dev + _etext@Base 1:3.17-2 _mu_scm_bugreport@Base 1:3.17 _mu_scm_debug@Base 1:3.17 _mu_scm_mailer@Base 1:3.17 dh_makeshlibs: error: failing due to earlier errors make[1]: *** [debian/rules:86: override_dh_makeshlibs] Error 25 make[1]: Leaving directory '/<>' make: *** [debian/rules:4: binary-arch] Error 2 Thanks, Adrian > [1] https://buildd.debian.org/status/package.php?p=mailutils=sid -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1072903: kiwi: please package v10.0.21 and remove the obsolete python3-mock build dependency
Hello, On Mon, 2024-06-10 at 01:17 +0200, Alexandre Detiste wrote: > please package v10.0.21 and remove the obsolete python3-mock build dependency > > > https://github.com/testing-cabal/mock > > > > mock is now part of the Python standard library, available as unittest.mock > > in Python 3.3 onward > > more information cab be find here: > > https://github.com/OSInside/kiwi/pull/2470 I have tried packaging the latest upstream version but I was unable to get the testsuite to pass successfully as setting the proper PYTHONPATH for running the testsuite did not work. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1072897: rustc: Please ignore test_arc_condvar_poison on powerpc
Source: rustc
Version: 1.75.0+dfsg1-4
Severity: normal
Tags: patch
User: debian-powe...@lists.debian.org
Usertags: powerpc
X-Debbugs-Cc: debian-powe...@lists.debian.org
Hi,
the test test_arc_condvar_poison hangs on powerpc for rustc 1.75.0 [1]:
test time::tests::instant_monotonic_concurrent ... ok
test sync::mpsc::tests::stress_recv_timeout_two_threads ... ok
test sync::mutex::tests::test_arc_condvar_poison has been running for a long
time
E: Build killed with signal TERM after 150 minutes of inactivity
Please include the attached patch to ignore it for the time being.
Thanks,
Adrian
> [1]
> https://buildd.debian.org/status/fetch.php?pkg=rustc=powerpc=1.75.0%2Bdfsg1-4=1717703746=0
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Index: rustc-1.75.0+dfsg1/library/std/src/sync/mutex/tests.rs
===
--- rustc-1.75.0+dfsg1.orig/library/std/src/sync/mutex/tests.rs
+++ rustc-1.75.0+dfsg1/library/std/src/sync/mutex/tests.rs
@@ -145,6 +145,7 @@ fn test_mutex_arc_condvar() {
}
}
+#[cfg(not(target_arch = "powerpc"))]
#[test]
fn test_arc_condvar_poison() {
let packet = Packet(Arc::new((Mutex::new(1), Condvar::new(;
Bug#1057050: qt6-multimedia: Please build with EIGEN_DONT_VECTORIZE on powerpc to fix FTBFS
Hello, On Sun, 2024-06-09 at 16:39 +0200, marillat wrote: > > This can be fixed by switching off vectorization in the »eigen« using the > > preprocessor > > macro EIGEN_DONT_VECTORIZE which can be defined on the cmake command line > > using the > > cmake variable COMPILE_DEFINITIONS: > > > > --- qt6-multimedia-6.4.2/debian/rules.orig 2023-07-26 > > 17:52:13.0 +0200 > > +++ qt6-multimedia-6.4.2/debian/rules 2023-11-28 18:26:47.950137854 +0100 > > @@ -9,6 +9,10 @@ > > cmake_extra_args += -DQT_HOST_PATH=/usr > > endif > > > > +ifneq (,$(filter $(DEB_HOST_ARCH),powerpc)) > > + cmake_extra_args += -DCOMPILE_DEFINITIONS="EIGEN_DONT_VECTORIZE" > > +endif > > + > > %: > > dh $@ --with pkgkde_symbolshelper --buildsystem=cmake+ninja > > > > With the above change, cmake defines the preprocessor macro > > EIGEN_DONT_VECTORIZE and > > the build succeeds on powerpc. > > With qt6-multimedia 6.6.2 qt6-multimedia still fail to build even with > this patch. > > I'm unable to find a solution. Adrian do you have an idea ? The syntax of my proposed solution was wrong. My local tests were not performed on a clean source which is why I did not notice the suggested syntax didn't work. The proper syntax is: ifneq (,$(filter $(DEB_HOST_ARCH),powerpc)) export DEB_CXXFLAGS_MAINT_APPEND = -DEIGEN_DONT_VECTORIZE endif @Patrick: Could you update the debian/rules file please to use the above syntax? Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1071007:
Hey all Thanks for your patience. Life gets a bit busy sometimes. I've just merged #2127 [1] upstream, switching Sherlock from setup-tools to Poetry, from unittest to pytest, and adding tox. With this, the site-/dist-packages dir is no longer dirtied. This bug **should** be resolved with the new upstream. All: Please feel free to ping me somewhere if things are problematic. I don't get emails for this thread despite subscribing for some reason, so I just check in once in a while. Things seem to work well on our end though, and I don't suspect any major issues For the packager: Not terribly sure if Debian builds need to occur offline, but if they do... If using tox... `tox -e offline` will direct tox to ignore internet-dependant unit tests If using pytest directly... `pytest -v -m "not online"` will direct pytest to do the same [1]: https://github.com/sherlock-project/sherlock/pull/2127
Bug#1072813: release.debian.org: Help doris migrate to testing
Hi, On 08-06-2024 11:17 a.m., Antonio Valentino wrote: Could you please clarify if there is something on my side that I should do to allow doris to migrate? You could bootstrap doris on other architectures too, such that it's not only available on amd64 and this check of the migration tooling wouldn't block the package. It's a hint you might have not thought about doing it. If bootstrapping doris on non-amd64 isn't trivial, we can add a hint to ignore the installability on arm64. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1072831: getting memory info fails when running under lxc
Package: procps Version: 2:4.0.2-3 Severity: normal I am running a number of virtual systems under lxc via libvirt. This means these systems share the host kernel (not like qemu where a whole virtual machine is emulated). I upgraded one to bookworm today, and when running 'ps faxu' or 'free' I get an error: Unable to create meminfo structure I downgraded procps to 2:3.3.17-5 (including libprocps8 2:3.3.17-5) and then it worked again. Working 'free' output: # free totalusedfree shared buff/cache available Mem: 2097152 64600 19323529028 100200 1932352 Swap: 10338296 795392 9542904 Not working 'free' output: # free free: Unable to create meminfo structure Contents of /proc/meminfo : MemTotal:2097152 kB MemFree: 1930792 kB MemAvailable:1930792 kB Buffers: 0 kB Cached: 100672 kB SwapCached:60812 kB Active: 119140 kB Inactive: 38800 kB Active(anon): 64480 kB Inactive(anon): 84 kB Active(file): 54660 kB Inactive(file):38716 kB Unevictable: 660 kB Mlocked: 43200 kB SwapTotal: 10338296 kB SwapFree:9542904 kB Zswap: 0 kB Zswapped: 0 kB Dirty: 344 kB Writeback: 0 kB AnonPages: 3726656 kB Mapped: 455856 kB Shmem: 9028 kB KReclaimable: 142356 kB Slab: 0 kB SReclaimable: 0 kB SUnreclaim:0 kB KernelStack:8576 kB PageTables:19560 kB SecPageTables:48 kB NFS_Unstable: 0 kB Bounce:0 kB WritebackTmp: 0 kB CommitLimit:14295376 kB Committed_AS:7452164 kB VmallocTotal: 34359738367 kB VmallocUsed: 42352 kB VmallocChunk: 0 kB Percpu: 3216 kB HardwareCorrupted: 0 kB AnonHugePages: 3117056 kB ShmemHugePages:0 kB ShmemPmdMapped:0 kB FileHugePages: 0 kB FilePmdMapped: 0 kB HugePages_Total: 0 HugePages_Free:0 HugePages_Rsvd:0 HugePages_Surp:0 Hugepagesize: 2048 kB Hugetlb: 0 kB DirectMap4k: 179704 kB DirectMap2M: 6940672 kB DirectMap1G: 3145728 kB I'm willing to help debug on my system if needed. Thanks, Paul -- System Information: Debian Release: 12.5 APT prefers stable APT policy: (800, 'stable'), (500, 'stable-updates'), (500, 'stable-security'), (500, 'unstable'), (500, 'oldstable'), (100, 'bookworm-fasttrack'), (100, 'bookworm-backports-staging') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-9-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages procps depends on: ii init-system-helpers 1.65.2 ii libc62.36-9+deb12u4 ii libncursesw6 6.4-4 ii libproc2-0 2:4.0.2-3 ii libtinfo66.4-4 Versions of packages procps recommends: ii psmisc 23.6-1 procps suggests no packages. -- no debconf information
Bug#1036630: procps: unowned /usr/bin/ps on filesystem after upgrade to bookworm
On Tue, 23 May 2023 09:06:31 -0500 C Seys wrote: > After upgrading to bookworm there is an unowned /usr/bin/ps on the filesystem: > > # dpkg -S /usr/bin/ps > dpkg-query: no path found matching pattern /usr/bin/ps > > There is also /bin/ps owned by procps: > > # dpkg -S /bin/ps > procps: /bin/ps I suspect that /bin is now a symlink to /usr/bin . So the /usr/bin/ps you see was installed as /bin/ps Regards, Paul
Bug#1057827: linux-minidisc: diff for NMU version 0.9.16-2.1
Hi, On Sat, 2024-06-08 at 09:15 +0200, Chris Hofstaedtler wrote: > > > I will take care of this myself. Please remove the upload. > > Done. Thanks. > > > I will try to fix the package tomorrow. Apologies for the delay. > > I'll take this opportunity to point out #1060195, a similar bug in > hfsprogs. Thanks for the reminder. Appreciate it. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1057827: linux-minidisc: diff for NMU version 0.9.16-2.1
Hello, On Fri, 2024-06-07 at 22:14 +0200, John Paul Adrian Glaubitz wrote: > On Fri, 2024-06-07 at 21:42 +0200, Chris Hofstaedtler wrote: > > I've prepared an NMU for linux-minidisc (versioned as 0.9.16-2.1) and > > uploaded it to DELAYED/14. Please feel free to tell me if I > > should delay it longer. > > I will take care of this myself. Please remove the upload. Sorry for the brevity in my previous mail. The reason I didn't fix this bug was because I missed the bug notification mail, so I wasn't aware this bug was around. I will try to fix the package tomorrow. Apologies for the delay. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1057827: linux-minidisc: diff for NMU version 0.9.16-2.1
Hello, On Fri, 2024-06-07 at 21:42 +0200, Chris Hofstaedtler wrote: > I've prepared an NMU for linux-minidisc (versioned as 0.9.16-2.1) and > uploaded it to DELAYED/14. Please feel free to tell me if I > should delay it longer. I will take care of this myself. Please remove the upload. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1072783: src:aardvark-dns: fails to migrate to testing for too long: unstatifiable Depends on s390x
Source: aardvark-dns Version: 1.4.0-5 Severity: serious Control: close -1 1.4.0-5.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:aardvark-dns has been trying to migrate for 36 days [2]. Hence, I am filing this bug. The version in unstable can't be installed on s390x while it can in 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=aardvark-dns OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1072780: src:transaction: fails to migrate to testing for too long: uploader built arch:all binary
Source: transaction Version: 3.0.0-1 Severity: serious Control: close -1 4.0-1 X-Debugs-CC: alexandre.deti...@gmail.com 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:transaction has been trying to migrate for 40 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=transaction OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1072779: src:golang-golang-x-tools: fails to migrate to testing for too long: triggers autopkgtest issues
Source: golang-golang-x-tools Version: 1:0.19.0+ds-1 Severity: serious Control: close -1 1:0.20.0+ds-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:golang-golang-x-tools has been trying to migrate for 41 days [2]. Hence, I am filing this bug. The version triggers autopkgtest issues in ycmd. 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=golang-golang-x-tools OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1072665: python3-commonmark-bkrs: Python 3.12: SyntaxWarning: invalid escape sequence
Package: python3-commonmark-bkrs
Version: 0.5.4+ds-7.1
Severity: normal
Usertags: warnings
User: debian-pyt...@lists.debian.org
Usertags: python3.12
Installing python3-commonmark-bkrs gives Python 3.12 warnings,
the fix for this is to use raw strings:
https://docs.python.org/3/library/re.html#raw-string-notation
Selecting previously unselected package python3-commonmark-bkrs.
Preparing to unpack .../python3-commonmark-bkrs_0.5.4+ds-7.1_all.deb ...
Unpacking python3-commonmark-bkrs (0.5.4+ds-7.1) ...
Setting up python3-commonmark-bkrs (0.5.4+ds-7.1) ...
/usr/lib/python3/dist-packages/CommonMark_bkrs/CommonMark.py:186:
SyntaxWarning: invalid escape sequence '\s'
return bool(re.compile("^\s*$").match(s))
/usr/lib/python3/dist-packages/CommonMark_bkrs/CommonMark.py:338:
SyntaxWarning: invalid escape sequence '\/'
"^<([a-zA-Z0-9.!#$%&'*+\/=?^_`{|}~-]+@[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?(?:\.[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?)*)>")
/usr/lib/python3/dist-packages/CommonMark_bkrs/CommonMark.py:385:
SyntaxWarning: invalid escape sequence '\s'
numdelims <= 3) and (not re.match("\s", char_after))
/usr/lib/python3/dist-packages/CommonMark_bkrs/CommonMark.py:387:
SyntaxWarning: invalid escape sequence '\s'
numdelims <= 3) and (not re.match("\s", char_before))
/usr/lib/python3/dist-packages/CommonMark_bkrs/CommonMark.py:1008:
SyntaxWarning: invalid escape sequence '\g'
re.sub(r'(?:(\\#) *#*| *#+) *$', '\g<1>', ln[offset:])]
-- System Information:
Debian Release: trixie/sid
APT prefers testing-debug
APT policy: (900, 'testing-debug'), (900, 'testing'), (800,
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700,
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 6.8.11-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8),
LANGUAGE=en_AU:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages python3-commonmark-bkrs depends on:
ii python3 3.11.8-1
python3-commonmark-bkrs recommends no packages.
Versions of packages python3-commonmark-bkrs suggests:
pn python-commonmark-bkrs-doc
-- no debconf information
--
bye,
pabs
https://wiki.debian.org/PaulWise
signature.asc
Description: This is a digitally signed message part
Bug#1072576: coot: save its states in HOME.
I was unaware of xdg - I will take a look. Paul.
Bug#1072650: src:quantlib-swig: fails to migrate to testing for too long: FTBFS on armel, armhf, i386 and riscv64
Source: quantlib-swig Version: 1.33-1 Severity: serious Control: close -1 1.34-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:quantlib-swig has been trying to migrate for 40 days [2]. Hence, I am filing this bug. The version in unstable failed to build on armel, armhf, i386 and riscv64. 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=quantlib-swig OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1072648: src:survival: fails to migrate to testing for too long: triggers autopkgtest issues
Source: survival Version: 3.5-8-1 Severity: serious Control: close -1 3.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:survival has been trying to migrate for 40 days [2]. Hence, I am filing this bug. The version in unstable triggers autopkgtest failure in r-cran-popepi. 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=survival OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1072647: src:openttd: fails to migrate to testing for too long: FTBFS on armel and unresolved RC bug
Source: openttd Version: 13.4-1 Severity: serious Control: close -1 14.0-1 Tags: sid trixie ftbfs User: release.debian@packages.debian.org Usertags: out-of-sync Control: block -1 by 1070208 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:openttd has been trying to migrate for 42 days [2]. Hence, I am filing this bug. The version in unstable failed to build on armel and has an unresolved RC bug: 1070208. 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=openttd OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1072646: src:rust-synstructure: fails to migrate to testing for too long
Source: rust-synstructure Version: 0.12.3-2 Severity: serious Control: close -1 0.13.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:rust-synstructure has been trying to migrate for 42 days [2]. Hence, I am filing this bug. The version in unstable isn't 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=rust-synstructure OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1072110: glslang breaks shaderc autopkgtest: undefined reference: ABI breakage?? -- not the case
Hi, On 01-06-2024 5:05 p.m., Philippe SWARTVAGHER wrote: As I understand it (but I can be wrong), the current state of glslang and shaderc in unstable is correct; mixing versions from testing and unstable triggers bugs that are now fixed in unstable. Ok. Does that mean that the version of glslang in unstable "Breaks" the version of shaderc in testing more than the version of glslang in testing, but it's shaderc that is broken either way? On that understanding I have manually triggered the combined test and the packages should migrate. Please close this bug if my understanding above was correct. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1051068: sysprof: Should mark test build dependencies as
On Tue, 2024-06-04 at 10:36 -0400, Jeremy Bícha wrote: > On Sat, Sep 2, 2023 at 4:22 PM Jeremy Bícha > wrote: > > > > Control: tags -1 moreinfo > > > > On Sat, Sep 2, 2023 at 2:06 AM John Paul Adrian Glaubitz > > wrote: > > > src:sysprof has multiple build dependencies in debian/control which are > > > required for running the testsuite only but yet these build dependencies > > > are not marked as to allow the package to be bootstrapped on > > > a new architecture. > > > > I was unable to identify any build dependencies like that. Please > > submit a merge proposal if you have specific improvements in mind. > > I am closing this bug since there has been no reply and there wasn't > enough information in this bug report to take any action. Hmm, I'm pretty sure that these were obvious. I will have to recheck. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1072539: ipywidgets: Recent changes introduced nodejs dependency limiting portability
Source: ipywidgets Version: 8.1.2-3 Severity: important Hello, the recent change to obsolete some binary packages in ipywidgets [1] introduced a hard dependency on nodejs which is available on a limited set of architectures only making ipywidgets uninstallable on a number of architectures: - alpha - hppa - hurd-amd64 - hurd-i386 - m68k - powerpc - ppc64 - sh4 - sparc64 - x32 Would it be possible to revert this change to remove the introduced dependency on nodejs again? Thanks, Adrian > [1] > https://salsa.debian.org/python-team/packages/ipywidgets/-/commit/ab52650adf13fd9f82f66dc1b328d04128496dcf -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1072535: puma: flaky autopkgtest
Source: puma Version: 6.4.2-4 Severity: serious User: debian...@lists.debian.org Usertags: flaky Dear maintainer(s), I looked at the results of the autopkgtest of your package because it showed up as regression for glibc. I noticed that it regularly fails. This particularly on happens on amd64, where our host is used to run many tests in parallel, so this may be a race condition under load. 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 https://ci.debian.net/packages/p/puma/testing/amd64/47272763/ 189s 1) Error: 189s TestPluginSystemd#test_systemd_notify_usr2_hot_restart_cluster: 189s Errno::EPIPE: Broken pipe 189s /tmp/autopkgtest-lxc.7lvlk_yq/downtmp/build.uxb/src/test/test_plugin_systemd.rb:90:in `write' 189s /tmp/autopkgtest-lxc.7lvlk_yq/downtmp/build.uxb/src/test/test_plugin_systemd.rb:90:in `assert_restarts_with_systemd' 189s /tmp/autopkgtest-lxc.7lvlk_yq/downtmp/build.uxb/src/test/test_plugin_systemd.rb:42:in `test_systemd_notify_usr2_hot_restart_cluster' 189s /tmp/autopkgtest-lxc.7lvlk_yq/downtmp/build.uxb/src/test/helper.rb:90:in `block (4 levels) in run' 189s /usr/lib/ruby/3.1.0/timeout.rb:107:in `block in timeout' 189s /usr/lib/ruby/3.1.0/timeout.rb:117:in `timeout' 189s /tmp/autopkgtest-lxc.7lvlk_yq/downtmp/build.uxb/src/test/helper.rb:88:in `block (3 levels) in run' OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1072533: procps: flaky autopkgtest:
Source: procps Version: 2:4.0.4-4 Severity: serious User: debian...@lists.debian.org Usertags: flaky Dear maintainer(s), I looked at the results of the autopkgtest of your package, because it showed up in the glibc regressions. I noticed that it regularly fails on amd64, ppc64el and s390x. For your info, as it seems to correlate, those are the architectures where multiple tests run in parallel, each in their own lxc container. 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/p/procps/testing/amd64/47064938/ 52s autopkgtest [06:08:26]: test vmstat: [--- 53s test_no_arguments 53s [1;31mASSERT:[0mvalue line 53s [1;31mshunit2:ERROR[0m test_no_arguments() returned non-zero return code. 53s test_forks 53s test_disk 53s 53s Ran [1;36m3[0m tests. 53s 53s [1;31mFAILED[0m ([1;31mfailures=2[0m) 53s autopkgtest [06:08:27]: test vmstat: ---] OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1072345: gcc-14: FTBFS on x32 due to missing package gccrs-14-x86-64-linux-gnux32
OK, it seems that this is because of x32 being part of "rs_no_cpu" in debian/rules.defs. So, please remove x32 from the Rust exclusion list and add cargo to BuildDepends in debian/control. It remains to be resolved why the build tries to enable Rust support despite x32 being in "rs_no_cpu" in debian/rules.defs. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1072345: gcc-14: FTBFS on x32 due to missing package gccrs-14-x86-64-linux-gnux32
Source: gcc-14 Version: 14.1.0-1 Severity: normal Hello, trying to build gcc-14 on x32 fails because the package gccrs-14-x86-64-linux-gnux32 is missing in debian/control so that the call to dh_installdirs fails: dh_installdirs -pgccrs-14-x86-64-linux-gnux32 usr/bin usr/share/man/man1 usr/libexec/gcc/x86_64-linux-gnux32/14 usr/share/lintian/overrides dh_installdirs: error: Requested unknown package gccrs-14-x86-64-linux-gnux32 via -p/--package, expected one of: gcc-14-base libgcc-s1 (...) gccrs-14-for-build gccrs-14 gcc-14-source dh_installdirs: error: unknown option or error during option parsing; aborting I assume the oversight was that on x32, the architecture is not used as a package prefix but a package suffix, i.e. gccrs-14-x86-64-linux-gnux32 instead of gccrs-14-x32-linux-gnu. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1072336: gcc-14: FTBFS on x32 due to outdated symbols file libasan8.symbols
Source: gcc-14 Version: 14.1.0-1 Severity: normal Hello, after installing cargo manually in the chroot to work around #1072327 [1], I ran into an FTBFS on x32 due to an outdated symbols file libasan8.symbols: dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols file: see diff output below dpkg-gensymbols: warning: debian/libasan8/DEBIAN/symbols doesn't match completely debian/libasan8.symbols --- debian/libasan8.symbols (libasan8_14.1.0-1_x32) +++ dpkg-gensymbolsRcyeWc 2024-06-01 08:50:52.822957692 + @@ -402,7 +402,7 @@ ___interceptor_setlocale@Base 14 ___interceptor_setpwent@Base 14 ___interceptor_setvbuf@Base 14 - ___interceptor_shmctl@Base 14 +#MISSING: 14.1.0-1# ___interceptor_shmctl@Base 14 ___interceptor_sigaction@Base 14 ___interceptor_sigaltstack@Base 14 ___interceptor_sigandset@Base 14 @@ -1579,7 +1579,7 @@ __interceptor_trampoline_setlocale@Base 14 __interceptor_trampoline_setpwent@Base 14 __interceptor_trampoline_setvbuf@Base 14 - __interceptor_trampoline_shmctl@Base 14 +#MISSING: 14.1.0-1# __interceptor_trampoline_shmctl@Base 14 __interceptor_trampoline_sigaction@Base 14 __interceptor_trampoline_sigaltstack@Base 14 __interceptor_trampoline_sigandset@Base 14 dh_makeshlibs: error: failing due to earlier errors I have uploaded the full gzipped build log in [2] since there were additional messages regarding symbols. Thanks, Adrian > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1072327 > [2] http://people.debian.org/~glaubitz/gcc-14_14.1.0-1_x32.build.gz -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1063735: python-maturin - upcoming rust-indexmap update.
Package: python-maturin Followup-For: Bug #1063735 Control: severity -1 serious Hello, I am setting the severity to serious now as this actually causes python-maturin to fails to build from source [1]: cargo generate-lockfile --offline error: failed to select a version for the requirement `indexmap = "^1.9.3"` candidate versions found which didn't match: 2.2.6 location searched: directory source `/usr/share/cargo/registry` (which is replacing registry `crates-io`) required by package `maturin v1.3.2 (/<>)` perhaps a crate was updated and forgotten to be re-vendored? Thanks, Adrian > [1] > https://buildd.debian.org/status/fetch.php?pkg=python-maturin=sparc64=1.3.2-1=1717193660=0 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
