Bug#1072271: src:skimage: fails to migrate to testing for too long: FTBFS on mips64el
Source: skimage Version: 0.22.0-3 Severity: serious Control: close -1 0.23.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:skimage has been trying to migrate for 49 days [2]. Hence, I am filing this bug. The version in unstable failed to build on mips64el. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=skimage OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1072271: src:skimage: fails to migrate to testing for too long: FTBFS on mips64el
Source: skimage Version: 0.22.0-3 Severity: serious Control: close -1 0.23.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:skimage has been trying to migrate for 49 days [2]. Hence, I am filing this bug. The version in unstable failed to build on mips64el. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=skimage OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1072271: src:skimage: fails to migrate to testing for too long: FTBFS on mips64el
Source: skimage Version: 0.22.0-3 Severity: serious Control: close -1 0.23.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:skimage has been trying to migrate for 49 days [2]. Hence, I am filing this bug. The version in unstable failed to build on mips64el. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=skimage OpenPGP_signature.asc Description: OpenPGP digital signature -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1071147: bluez: autopkgtests fail due to lack of devices
Hi, On Wed, 15 May 2024 10:16:55 +0200 Emilio Pozuelo Monfort wrote: If this can't be fixed in the short term by adding some type of restriction to the autopkgtest or by mocking the devices, then the tests should be removed until they can be made to work on our infrastructure. The autopkgtest failure is not due to the test failing itself, but due to the test writing to stderr, which by default is considered a test failure. You can ignore output to stderr by marking the test with the allow-stderr restriction. But please, if you do that, this test doesn't actually do anything anymore on Debian infrastructure so be sure to also mark it as superficial or mark the test as skippable and exit with exit code 77 in case all tests are skipped. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1071147: bluez: autopkgtests fail due to lack of devices
Hi, On Wed, 15 May 2024 10:16:55 +0200 Emilio Pozuelo Monfort wrote: If this can't be fixed in the short term by adding some type of restriction to the autopkgtest or by mocking the devices, then the tests should be removed until they can be made to work on our infrastructure. The autopkgtest failure is not due to the test failing itself, but due to the test writing to stderr, which by default is considered a test failure. You can ignore output to stderr by marking the test with the allow-stderr restriction. But please, if you do that, this test doesn't actually do anything anymore on Debian infrastructure so be sure to also mark it as superficial or mark the test as skippable and exit with exit code 77 in case all tests are skipped. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1072269: src:python-arrow: fails to migrate to testing for too long: uploader built arch:all binaries
Source: python-arrow Version: 1.2.3-1 Severity: serious Control: close -1 1.3.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:python-arrow has been trying to migrate for 52 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=python-arrow OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1072270: src:bluez: fails to migrate to testing for too long: autopkgtest failure
Source: bluez Version: 5.71-1 Severity: serious Control: close -1 5.73-1 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Control: block -1 by 1071147 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:bluez has been trying to migrate for 50 days [2]. Hence, I am filing this bug. The version in unstable is blocked from migration because it fails it's own autopkgtest, as reported in bug 1071147. 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=bluez OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1072270: src:bluez: fails to migrate to testing for too long: autopkgtest failure
Source: bluez Version: 5.71-1 Severity: serious Control: close -1 5.73-1 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Control: block -1 by 1071147 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:bluez has been trying to migrate for 50 days [2]. Hence, I am filing this bug. The version in unstable is blocked from migration because it fails it's own autopkgtest, as reported in bug 1071147. 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=bluez OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1072269: src:python-arrow: fails to migrate to testing for too long: uploader built arch:all binaries
Source: python-arrow Version: 1.2.3-1 Severity: serious Control: close -1 1.3.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:python-arrow has been trying to migrate for 52 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=python-arrow OpenPGP_signature.asc Description: OpenPGP digital signature
[DRE-maint] Bug#1072268: src:rake: fails to migrate to testing for too long: causes autopkgtest issues
Source: rake Version: 13.0.6-3 Severity: serious Control: close -1 13.2.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:rake has been trying to migrate for 58 days [2]. Hence, I am filing this bug. The version in unstable causes the autopkgtest of src:ruby-hoe 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=rake OpenPGP_signature.asc Description: OpenPGP digital signature ___ Pkg-ruby-extras-maintainers mailing list Pkg-ruby-extras-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-ruby-extras-maintainers
Bug#1072268: src:rake: fails to migrate to testing for too long: causes autopkgtest issues
Source: rake Version: 13.0.6-3 Severity: serious Control: close -1 13.2.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:rake has been trying to migrate for 58 days [2]. Hence, I am filing this bug. The version in unstable causes the autopkgtest of src:ruby-hoe 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=rake OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1072268: src:rake: fails to migrate to testing for too long: causes autopkgtest issues
Source: rake Version: 13.0.6-3 Severity: serious Control: close -1 13.2.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:rake has been trying to migrate for 58 days [2]. Hence, I am filing this bug. The version in unstable causes the autopkgtest of src:ruby-hoe 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=rake OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1072243: src:zmat: fails to migrate to testing for too long: FTBFS on non-x86
Source: zmat Version: 0.9.8+ds-8 Severity: serious Control: close -1 0.9.9+ds.1-2 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Control: block -1 by 1068683 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:zmat has been trying to migrate for 57 days [2]. Hence, I am filing this bug. As reported in bugs 1068683 and 10686834, the version in unstable fails to build nearly everywhere. 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=zmat OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1072243: src:zmat: fails to migrate to testing for too long: FTBFS on non-x86
Source: zmat Version: 0.9.8+ds-8 Severity: serious Control: close -1 0.9.9+ds.1-2 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Control: block -1 by 1068683 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:zmat has been trying to migrate for 57 days [2]. Hence, I am filing this bug. As reported in bugs 1068683 and 10686834, the version in unstable fails to build nearly everywhere. 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=zmat OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1072242: src:git-delta: fails to migrate to testing for too long: FTBFS on arm64, armel and ppc64el
Source: git-delta Version: 0.16.5-5 Severity: serious Control: close -1 0.17.0-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:git-delta has been trying to migrate for 58 days [2]. Hence, I am filing this bug. The version in unstable failed to build on arm64, armel and ppc64el. 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-delta OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1068349: nbsphinx/nbconvert broken by lxml 5.2: lxml.html.clean
Hi, On Sun, 19 May 2024 16:25:01 +0100 "Rebecca N. Palmer" wrote: Filing a bug against two packages means that it could be fixed in *either* of them, *not* that it requires changes to both of them. Hence, it is correct that this bug was closed. While I recall it's documented like this, this is not how the BTS reports this bug to the outside world and the migration software is still informed that this bug affects src:lxml with its version in unstable and hence blocks migration. Are you saying that if lxml migrates to testing, everything is fine? Than the easiest thing to do is to assign this bug to the package that fixed it. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1072242: src:git-delta: fails to migrate to testing for too long: FTBFS on arm64, armel and ppc64el
Source: git-delta Version: 0.16.5-5 Severity: serious Control: close -1 0.17.0-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:git-delta has been trying to migrate for 58 days [2]. Hence, I am filing this bug. The version in unstable failed to build on arm64, armel and ppc64el. 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-delta OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1068349: nbsphinx/nbconvert broken by lxml 5.2: lxml.html.clean
Hi, On Sun, 19 May 2024 16:25:01 +0100 "Rebecca N. Palmer" wrote: Filing a bug against two packages means that it could be fixed in *either* of them, *not* that it requires changes to both of them. Hence, it is correct that this bug was closed. While I recall it's documented like this, this is not how the BTS reports this bug to the outside world and the migration software is still informed that this bug affects src:lxml with its version in unstable and hence blocks migration. Are you saying that if lxml migrates to testing, everything is fine? Than the easiest thing to do is to assign this bug to the package that fixed it. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1072241: src:manpages: fails to migrate to testing for too long: RC bug and B-D not in testing
Source: manpages Version: 6.05.01-1 Severity: serious Control: close -1 6.8-1 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Control: block -1 by 1072158 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:manpages has been trying to migrate for 59 days [2]. Hence, I am filing this bug. The version in unstable has an unresolved RC bug (#1072158) and one of its Build-Depends isn't in testing and can't migrate. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=manpages OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1072241: src:manpages: fails to migrate to testing for too long: RC bug and B-D not in testing
Source: manpages Version: 6.05.01-1 Severity: serious Control: close -1 6.8-1 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Control: block -1 by 1072158 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:manpages has been trying to migrate for 59 days [2]. Hence, I am filing this bug. The version in unstable has an unresolved RC bug (#1072158) and one of its Build-Depends isn't in testing and can't migrate. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=manpages OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1072110: glslang breaks shaderc autopkgtest: undefined reference: ABI breakage?? -- not the case
Hi. [Just in case you're not aware, the BTS doesn't forward replies to the bug submitter unless they are subscribed. If you want to have the submitters attention, please add them explicitly.] On Wed, 29 May 2024 19:55:19 +0200 Philippe SWARTVAGHER wrote: Well, this issue is "normal". Currently, shaderc 2023.2-1 is in testing. This version suffers from an "undefined symbol" bug (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1070983). This bug is fixed in version 2023.8-1 which is now in unstable. Can you please elaborate how the fix works. This feels like you're using a symbol that's only available from a new version of glslang, why don't you have the right versioned constrained to prevent migration of shaderc without the right version providing the symbol? And how can the test of shaderc in testing work with the version of glslang in testing? It really looks like src:glslang is still failing to provide the symbol that shaderc (and maybe other packages in testing) are expecting from it. What I mean to say is that very regularly when an ABI breaks "just rebuilding" reverse dependencies fixes missing symbol issues, but it's the wrong fix. Bumping SONAME when ABI breaks and going through a transition is the right solution if the dropping of the symbol is intended. (I'm not saying that's the case here as I don't fully understand it). However, this version never migrated to testing due to a blocking bug in glslang (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1062799). This bug in glslang is now fixed with the last upload. But the new version of glslang still doesn't provide the missing symbol. I'm a beginner regarding this kind transition / blocking bug / CI, so I don't know how this bug can be solved... From where I stand this looks like ABI is broken and if it's not going to be reverted, the SONAME must be bumped and we have to go through a transition: https://wiki.debian.org/Teams/ReleaseTeam/Transitions I don't know if it helps, but I have a RFS (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1072181) for a new version of shaderc (which changes nothing about this bug). You can see on Salsa that autopkgtests pass with the version of glslang available in unstable: https://salsa.debian.org/debian/shaderc/-/pipelines/683648. Well, shaderc in unstable is build against the new version of glslang. As I mentioned before, rebuilds often paper over missing symbols problems, but is the wrong solution. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1072110: glslang breaks shaderc autopkgtest: undefined reference: ABI breakage?? -- not the case
Hi. [Just in case you're not aware, the BTS doesn't forward replies to the bug submitter unless they are subscribed. If you want to have the submitters attention, please add them explicitly.] On Wed, 29 May 2024 19:55:19 +0200 Philippe SWARTVAGHER wrote: Well, this issue is "normal". Currently, shaderc 2023.2-1 is in testing. This version suffers from an "undefined symbol" bug (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1070983). This bug is fixed in version 2023.8-1 which is now in unstable. Can you please elaborate how the fix works. This feels like you're using a symbol that's only available from a new version of glslang, why don't you have the right versioned constrained to prevent migration of shaderc without the right version providing the symbol? And how can the test of shaderc in testing work with the version of glslang in testing? It really looks like src:glslang is still failing to provide the symbol that shaderc (and maybe other packages in testing) are expecting from it. What I mean to say is that very regularly when an ABI breaks "just rebuilding" reverse dependencies fixes missing symbol issues, but it's the wrong fix. Bumping SONAME when ABI breaks and going through a transition is the right solution if the dropping of the symbol is intended. (I'm not saying that's the case here as I don't fully understand it). However, this version never migrated to testing due to a blocking bug in glslang (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1062799). This bug in glslang is now fixed with the last upload. But the new version of glslang still doesn't provide the missing symbol. I'm a beginner regarding this kind transition / blocking bug / CI, so I don't know how this bug can be solved... From where I stand this looks like ABI is broken and if it's not going to be reverted, the SONAME must be bumped and we have to go through a transition: https://wiki.debian.org/Teams/ReleaseTeam/Transitions I don't know if it helps, but I have a RFS (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1072181) for a new version of shaderc (which changes nothing about this bug). You can see on Salsa that autopkgtests pass with the version of glslang available in unstable: https://salsa.debian.org/debian/shaderc/-/pipelines/683648. Well, shaderc in unstable is build against the new version of glslang. As I mentioned before, rebuilds often paper over missing symbols problems, but is the wrong solution. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1072110: glslang breaks shaderc autopkgtest: undefined reference: ABI breakage?? -- not the case
Hi. [Just in case you're not aware, the BTS doesn't forward replies to the bug submitter unless they are subscribed. If you want to have the submitters attention, please add them explicitly.] On Wed, 29 May 2024 19:55:19 +0200 Philippe SWARTVAGHER wrote: Well, this issue is "normal". Currently, shaderc 2023.2-1 is in testing. This version suffers from an "undefined symbol" bug (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1070983). This bug is fixed in version 2023.8-1 which is now in unstable. Can you please elaborate how the fix works. This feels like you're using a symbol that's only available from a new version of glslang, why don't you have the right versioned constrained to prevent migration of shaderc without the right version providing the symbol? And how can the test of shaderc in testing work with the version of glslang in testing? It really looks like src:glslang is still failing to provide the symbol that shaderc (and maybe other packages in testing) are expecting from it. What I mean to say is that very regularly when an ABI breaks "just rebuilding" reverse dependencies fixes missing symbol issues, but it's the wrong fix. Bumping SONAME when ABI breaks and going through a transition is the right solution if the dropping of the symbol is intended. (I'm not saying that's the case here as I don't fully understand it). However, this version never migrated to testing due to a blocking bug in glslang (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1062799). This bug in glslang is now fixed with the last upload. But the new version of glslang still doesn't provide the missing symbol. I'm a beginner regarding this kind transition / blocking bug / CI, so I don't know how this bug can be solved... From where I stand this looks like ABI is broken and if it's not going to be reverted, the SONAME must be bumped and we have to go through a transition: https://wiki.debian.org/Teams/ReleaseTeam/Transitions I don't know if it helps, but I have a RFS (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1072181) for a new version of shaderc (which changes nothing about this bug). You can see on Salsa that autopkgtests pass with the version of glslang available in unstable: https://salsa.debian.org/debian/shaderc/-/pipelines/683648. Well, shaderc in unstable is build against the new version of glslang. As I mentioned before, rebuilds often paper over missing symbols problems, but is the wrong solution. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1072110: glslang breaks shaderc autopkgtest: undefined reference: ABI breakage??
Source: glslang, shaderc Control: found -1 glslang/14.2.0-1 Control: found -1 shaderc/2023.2-1 Severity: serious Tags: sid trixie User: debian...@lists.debian.org Usertags: breaks needs-update Dear maintainer(s), With a recent upload of glslang the autopkgtest of shaderc fails in testing when that autopkgtest is run with the binary packages of glslang from unstable. It passes when run with only packages from testing. In tabular form: passfail glslangfrom testing14.2.0-1 shadercfrom testing2023.2-1 all others from testingfrom testing I copied some of the output at the bottom of this report. Normally "undefined reference to ..." means an ABI bump without a SONAME change. Is that the case here too? Currently this regression is blocking the migration of glslang 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=glslang https://ci.debian.net/data/autopkgtest/testing/arm64/s/shaderc/47069332/log.gz 80s /usr/bin/ld: /usr/lib/gcc/aarch64-linux-gnu/13/../../../aarch64-linux-gnu/libshaderc.so: undefined reference to `glslang::TIntermediate::improperStraddle(glslang::TType const&, int, int)' 80s collect2: error: ld returned 1 exit status 80s autopkgtest [15:07:47]: test lib OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1072110: glslang breaks shaderc autopkgtest: undefined reference: ABI breakage??
Source: glslang, shaderc Control: found -1 glslang/14.2.0-1 Control: found -1 shaderc/2023.2-1 Severity: serious Tags: sid trixie User: debian...@lists.debian.org Usertags: breaks needs-update Dear maintainer(s), With a recent upload of glslang the autopkgtest of shaderc fails in testing when that autopkgtest is run with the binary packages of glslang from unstable. It passes when run with only packages from testing. In tabular form: passfail glslangfrom testing14.2.0-1 shadercfrom testing2023.2-1 all others from testingfrom testing I copied some of the output at the bottom of this report. Normally "undefined reference to ..." means an ABI bump without a SONAME change. Is that the case here too? Currently this regression is blocking the migration of glslang 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=glslang https://ci.debian.net/data/autopkgtest/testing/arm64/s/shaderc/47069332/log.gz 80s /usr/bin/ld: /usr/lib/gcc/aarch64-linux-gnu/13/../../../aarch64-linux-gnu/libshaderc.so: undefined reference to `glslang::TIntermediate::improperStraddle(glslang::TType const&, int, int)' 80s collect2: error: ld returned 1 exit status 80s autopkgtest [15:07:47]: test lib OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1072110: glslang breaks shaderc autopkgtest: undefined reference: ABI breakage??
Source: glslang, shaderc Control: found -1 glslang/14.2.0-1 Control: found -1 shaderc/2023.2-1 Severity: serious Tags: sid trixie User: debian...@lists.debian.org Usertags: breaks needs-update Dear maintainer(s), With a recent upload of glslang the autopkgtest of shaderc fails in testing when that autopkgtest is run with the binary packages of glslang from unstable. It passes when run with only packages from testing. In tabular form: passfail glslangfrom testing14.2.0-1 shadercfrom testing2023.2-1 all others from testingfrom testing I copied some of the output at the bottom of this report. Normally "undefined reference to ..." means an ABI bump without a SONAME change. Is that the case here too? Currently this regression is blocking the migration of glslang 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=glslang https://ci.debian.net/data/autopkgtest/testing/arm64/s/shaderc/47069332/log.gz 80s /usr/bin/ld: /usr/lib/gcc/aarch64-linux-gnu/13/../../../aarch64-linux-gnu/libshaderc.so: undefined reference to `glslang::TIntermediate::improperStraddle(glslang::TType const&, int, int)' 80s collect2: error: ld returned 1 exit status 80s autopkgtest [15:07:47]: test lib OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1072049: please provide a link to the artifacts on the page displaying the log
Hi,
Unfortunately
On 28-05-2024 2:46 p.m., Antonio Terceiro wrote:
FWIW given this is pretty simple I also live patched the server.
..the link now is:
https://ci.debian.net/packages/r/reform-setup-wizard/testing/s390x/47038806/%7B%20base_url%20%7D/artifacts.tar.gz
Note the {base_url}/ which doesn't get replaced correctly... :(
Paul
OpenPGP_signature.asc
Description: OpenPGP digital signature
Bug#1072004: linux: regression in the 9p protocol in 6.8 breaks autopkgtest qemu jobs (affecting debci)
Hi, On 28-05-2024 10:54 a.m., Luca Boccassi wrote: If 6.8 migrates to testing, it will break amd64 debci for unrelated packages for migration tests too. I don't think that's something we want? Paul, wouldn't that qualify as RC? With the kernel team being aware of the issue, I trust the kernel team to balance the options appropriately. I defer to make a call as a Release Team member. Options that I'm aware of: 1) accept the kernel package as is in testing where it will cause some regression in some autopkgtest on ci.d.n infrastructure in testing. We have (only) 56 packages tested with qemu and I could disable qemu based testing on ci.d.n until this bug is resolved (which means that isolation-machine tests will not be run, but also not cause unnecessary failures). 2) update the kernel package with the bisected commit reverted. I understand that the kernel team tries to follow upstream as much as possible to avoid Debian delta's that might be hard to get rid of. 3) update the kernel package with a proposed (but not accepted) patch. 4) wait with updating the kernel package in testing until this issue is solved upstream, causing all kernel fixes to hit testing later. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1072004: linux: regression in the 9p protocol in 6.8 breaks autopkgtest qemu jobs (affecting debci)
Hi, On 28-05-2024 10:54 a.m., Luca Boccassi wrote: If 6.8 migrates to testing, it will break amd64 debci for unrelated packages for migration tests too. I don't think that's something we want? Paul, wouldn't that qualify as RC? With the kernel team being aware of the issue, I trust the kernel team to balance the options appropriately. I defer to make a call as a Release Team member. Options that I'm aware of: 1) accept the kernel package as is in testing where it will cause some regression in some autopkgtest on ci.d.n infrastructure in testing. We have (only) 56 packages tested with qemu and I could disable qemu based testing on ci.d.n until this bug is resolved (which means that isolation-machine tests will not be run, but also not cause unnecessary failures). 2) update the kernel package with the bisected commit reverted. I understand that the kernel team tries to follow upstream as much as possible to avoid Debian delta's that might be hard to get rid of. 3) update the kernel package with a proposed (but not accepted) patch. 4) wait with updating the kernel package in testing until this issue is solved upstream, causing all kernel fixes to hit testing later. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1071907: src:traitlets: fails to migrate to testing for too long: causes issues in src:jupyter-notebook
Source: traitlets Version: 5.5.0-2 Severity: serious Control: close -1 5.14.3-1 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:traitlets has been trying to migrate for 54 days [2]. Hence, I am filing this bug. The version in unstable causes autopkgtest failure in src:jupyter-notebook. 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=traitlets OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1071907: src:traitlets: fails to migrate to testing for too long: causes issues in src:jupyter-notebook
Source: traitlets Version: 5.5.0-2 Severity: serious Control: close -1 5.14.3-1 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:traitlets has been trying to migrate for 54 days [2]. Hence, I am filing this bug. The version in unstable causes autopkgtest failure in src:jupyter-notebook. 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=traitlets OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1071906: src:mame: fails to migrate to testing for too long: FTBFS on armel
Source: mame Version: 0.261+dfsg.1-1 Severity: serious Control: close -1 0.264+dfsg.1-1 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Control: block -1 by 1069544 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:mame has been trying to migrate for 57 days [2]. Hence, I am filing this bug. The version in unstable failed to build on armel as reported in bug 1069544. 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=mame OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1071906: src:mame: fails to migrate to testing for too long: FTBFS on armel
Source: mame Version: 0.261+dfsg.1-1 Severity: serious Control: close -1 0.264+dfsg.1-1 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Control: block -1 by 1069544 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:mame has been trying to migrate for 57 days [2]. Hence, I am filing this bug. The version in unstable failed to build on armel as reported in bug 1069544. 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=mame OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1071905: src:python-ppmd: fails to migrate to testing for too long: FTBFS on mips64el and ppc64el
Source: python-ppmd Version: 0.3.3-5 Severity: serious Control: close -1 0.5.0-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:python-ppmd has been trying to migrate for 59 days [2]. Hence, I am filing this bug. The version in unstable failed to build on mips64el and ppc64el. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=python-ppmd OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1071905: src:python-ppmd: fails to migrate to testing for too long: FTBFS on mips64el and ppc64el
Source: python-ppmd Version: 0.3.3-5 Severity: serious Control: close -1 0.5.0-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:python-ppmd has been trying to migrate for 59 days [2]. Hence, I am filing this bug. The version in unstable failed to build on mips64el and ppc64el. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=python-ppmd OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1071857: src:python-watson-developer-cloud: fails to migrate to testing for too long: uploader built arch:all binary
Source: python-watson-developer-cloud Version: 7.0.0-1 Severity: serious Control: close -1 8.0.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:python-watson-developer-cloud has been trying to migrate for 61 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=python-watson-developer-cloud OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1071856: src:alttab: fails to migrate to testing for too long: autopkgtest regression
Source: alttab Version: 1.7.1-1 Severity: serious Control: close -1 1.7.1-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:alttab has been trying to migrate for 65 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=alttab OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1071857: src:python-watson-developer-cloud: fails to migrate to testing for too long: uploader built arch:all binary
Source: python-watson-developer-cloud Version: 7.0.0-1 Severity: serious Control: close -1 8.0.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:python-watson-developer-cloud has been trying to migrate for 61 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=python-watson-developer-cloud OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1071856: src:alttab: fails to migrate to testing for too long: autopkgtest regression
Source: alttab Version: 1.7.1-1 Severity: serious Control: close -1 1.7.1-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:alttab has been trying to migrate for 65 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=alttab OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1071854: src:matrix-synapse: fails to migrate to testing for too long: RC bug
Source: matrix-synapse Version: 1.100.0-1 Severity: serious Control: close -1 1.103.0-1 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Control: block -1 by 1069763 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:matrix-synapse has been trying to migrate for 66 days [2]. Hence, I am filing this bug. The version in unstable doesn't migrate because bug 1069763 is filed against that version, although I somehow assume it applies equally against the version 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=matrix-synapse OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1071854: src:matrix-synapse: fails to migrate to testing for too long: RC bug
Source: matrix-synapse Version: 1.100.0-1 Severity: serious Control: close -1 1.103.0-1 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Control: block -1 by 1069763 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:matrix-synapse has been trying to migrate for 66 days [2]. Hence, I am filing this bug. The version in unstable doesn't migrate because bug 1069763 is filed against that version, although I somehow assume it applies equally against the version 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=matrix-synapse OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1071853: src:postsrsd: fails to migrate to testing for too long: FTBFS on armel and armhf
Source: postsrsd Version: 1.10-2 Severity: serious Control: close -1 1.10-2.1 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Control: block -1 by 1068053 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:postsrsd has been trying to migrate for 66 days [2]. Hence, I am filing this bug. The version in unstable fails to build on armel and armhf as reported in bug 1068053. 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=postsrsd OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1071853: src:postsrsd: fails to migrate to testing for too long: FTBFS on armel and armhf
Source: postsrsd Version: 1.10-2 Severity: serious Control: close -1 1.10-2.1 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Control: block -1 by 1068053 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:postsrsd has been trying to migrate for 66 days [2]. Hence, I am filing this bug. The version in unstable fails to build on armel and armhf as reported in bug 1068053. 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=postsrsd OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1071852: src:python-uinput: fails to migrate to testing for too long: FTBFS on armel and armhf
Source: python-uinput Version: 0.11.3-1 Severity: serious Control: close -1 1.0.1-1 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Control: block -1 by 1067083 Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:python-uinput has been trying to migrate for 68 days [2]. Hence, I am filing this bug. The version in unstable failed to build on armel and armhf as reported in bug 1067083. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=python-uinput OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1071852: src:python-uinput: fails to migrate to testing for too long: FTBFS on armel and armhf
Source: python-uinput Version: 0.11.3-1 Severity: serious Control: close -1 1.0.1-1 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Control: block -1 by 1067083 Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:python-uinput has been trying to migrate for 68 days [2]. Hence, I am filing this bug. The version in unstable failed to build on armel and armhf as reported in bug 1067083. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=python-uinput OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1071851: src:remmina: fails to migrate to testing for too long: unresolved RC bug
Source: remmina Version: 1.4.34+dfsg-1 Severity: serious Control: close -1 1.4.35+dfsg-2 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Control: block -1 by 1070063 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:remmina has been trying to migrate for 70 days [2]. Hence, I am filing this bug. The version in unstable has an unresolved RC bug: 1070063. 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=remmina OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1071851: src:remmina: fails to migrate to testing for too long: unresolved RC bug
Source: remmina Version: 1.4.34+dfsg-1 Severity: serious Control: close -1 1.4.35+dfsg-2 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Control: block -1 by 1070063 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:remmina has been trying to migrate for 70 days [2]. Hence, I am filing this bug. The version in unstable has an unresolved RC bug: 1070063. 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=remmina OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1071850: src:python-dmidecode: fails to migrate to testing for too long: new autopkgtest fails everywhere
Source: python-dmidecode Version: 3.12.3-2 Severity: serious Control: close -1 3.12.3-3 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:python-dmidecode has been trying to migrate for 72 days [2]. Hence, I am filing this bug. The version in unstable has a newly added autopkgtest (thanks for that), but it fails everywhere. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=python-dmidecode OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1071850: src:python-dmidecode: fails to migrate to testing for too long: new autopkgtest fails everywhere
Source: python-dmidecode Version: 3.12.3-2 Severity: serious Control: close -1 3.12.3-3 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:python-dmidecode has been trying to migrate for 72 days [2]. Hence, I am filing this bug. The version in unstable has a newly added autopkgtest (thanks for that), but it fails everywhere. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=python-dmidecode OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1071849: src:creduce: fails to migrate to testing for too long: blocked by Build-Depends
Source: creduce Version: 2.11.0~20231125-2 Severity: serious Control: close -1 2.11.0~20240312-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:creduce has been trying to migrate for 74 days [2]. Hence, I am filing this bug. The version in unstable Build-Depends on src:llvm-toolchain-18 which isn't ready to migrate to testing yet. 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=creduce OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1071846: src:cvise: fails to migrate to testing for too long: blocked by Build-Depends
Source: cvise Version: 2.9.0-2 Severity: serious Control: close -1 2.10.0-1 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:cvise has been trying to migrate for 74 days [2]. Hence, I am filing this bug. The version in unstable build depends on src:llvm-toolchain-18 which isn't ready to migrate to testing yet. 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=cvise OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1071849: src:creduce: fails to migrate to testing for too long: blocked by Build-Depends
Source: creduce Version: 2.11.0~20231125-2 Severity: serious Control: close -1 2.11.0~20240312-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:creduce has been trying to migrate for 74 days [2]. Hence, I am filing this bug. The version in unstable Build-Depends on src:llvm-toolchain-18 which isn't ready to migrate to testing yet. 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=creduce OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1071846: src:cvise: fails to migrate to testing for too long: blocked by Build-Depends
Source: cvise Version: 2.9.0-2 Severity: serious Control: close -1 2.10.0-1 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:cvise has been trying to migrate for 74 days [2]. Hence, I am filing this bug. The version in unstable build depends on src:llvm-toolchain-18 which isn't ready to migrate to testing yet. 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=cvise OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1071849: src:creduce: fails to migrate to testing for too long: blocked by Build-Depends
Source: creduce Version: 2.11.0~20231125-2 Severity: serious Control: close -1 2.11.0~20240312-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:creduce has been trying to migrate for 74 days [2]. Hence, I am filing this bug. The version in unstable Build-Depends on src:llvm-toolchain-18 which isn't ready to migrate to testing yet. 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=creduce OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1071846: src:cvise: fails to migrate to testing for too long: blocked by Build-Depends
Source: cvise Version: 2.9.0-2 Severity: serious Control: close -1 2.10.0-1 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:cvise has been trying to migrate for 74 days [2]. Hence, I am filing this bug. The version in unstable build depends on src:llvm-toolchain-18 which isn't ready to migrate to testing yet. 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=cvise OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1071844: src:libfiu: fails to migrate to testing for too long: FTBFS on armel and armhf
Source: libfiu Version: 1.2-1 Severity: serious Control: close -1 1.2-2 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Control: block -1 by 1066938 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:libfiu has been trying to migrate for 75 days [2]. Hence, I am filing this bug. The version in unstable failed to build on armel and armhf as reported in bug 1066938. 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=libfiu OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1071844: src:libfiu: fails to migrate to testing for too long: FTBFS on armel and armhf
Source: libfiu Version: 1.2-1 Severity: serious Control: close -1 1.2-2 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Control: block -1 by 1066938 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:libfiu has been trying to migrate for 75 days [2]. Hence, I am filing this bug. The version in unstable failed to build on armel and armhf as reported in bug 1066938. 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=libfiu OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1071843: src:r-cran-pracma: fails to migrate to testing for too long: uploader built arch:all binary
Source: r-cran-pracma Version: 2.4.4-1 Severity: serious Control: close -1 2.4.4-2 Tags: sid trixie pending User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:r-cran-pracma has been trying to migrate for 75 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=r-cran-pracma OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1071843: src:r-cran-pracma: fails to migrate to testing for too long: uploader built arch:all binary
Source: r-cran-pracma Version: 2.4.4-1 Severity: serious Control: close -1 2.4.4-2 Tags: sid trixie pending User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:r-cran-pracma has been trying to migrate for 75 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=r-cran-pracma OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1071842: src:rust-gsettings-macro: fails to migrate to testing for too long: Build-Depends not available
Source: rust-gsettings-macro Version: 0.1.20-1 Severity: serious Control: close -1 0.2.0-2 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Control: block -1 by 1068142 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-gsettings-macro has been trying to migrate for 76 days [2]. Hence, I am filing this bug. The version in unstable fails to build due to missing Build-Depends as reported in bug 1068142. 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-gsettings-macro OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1071842: src:rust-gsettings-macro: fails to migrate to testing for too long: Build-Depends not available
Source: rust-gsettings-macro Version: 0.1.20-1 Severity: serious Control: close -1 0.2.0-2 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Control: block -1 by 1068142 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-gsettings-macro has been trying to migrate for 76 days [2]. Hence, I am filing this bug. The version in unstable fails to build due to missing Build-Depends as reported in bug 1068142. 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-gsettings-macro OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1071818: __lxcapi_create: 1760 Template "debian" not found on riscv64
Control: tags -1 moreinfo Hi vimer, On 25-05-2024 7:08 a.m., Bo YU wrote: lxc-create: autopkgtest-unstable-riscv64: ../src/lxc/lxccontainer.c: __lxcapi_create: 1760 Template "debian" not found Did you install lxc-templates? Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1071782: skimage: autopkgtest needs update for new version of pytest on s390x
Source: skimage
Version: 0.22.0-3
Severity: serious
X-Debbugs-CC: pyt...@packages.debian.org
Tags: sid trixie
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:pytest
Dear maintainer(s),
With a recent upload of pytest the autopkgtest of skimage fails in
testing on s390x when that autopkgtest is run with the binary packages
of pytest from unstable. It passes when run with only packages from
testing. In tabular form:
passfail
pytest from testing8.1.2-1
skimagefrom testing0.22.0-3
all others from testingfrom testing
I copied some of the output at the bottom of this report. I'll note that
s390x is our only big endian architecture with autopgktest.
Currently this regression is blocking the migration of pytest to testing
[1]. Of course, pytest shouldn't just break your autopkgtest (or even
worse, your package), but due to the nature of the package pytest I
suspect that your package just needs to update to the new situation.
If this is a real problem in your package (and not only in your
autopkgtest), the right binary package(s) from pytest should really add
a versioned Breaks on the unfixed version of (one of your) package(s).
Note: the Breaks is nice even if the issue is only in the autopkgtest as
it helps the migration software to figure out the right versions to
combine in the tests.
More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
Paul
[1] https://qa.debian.org/excuses.php?package=pytest
https://ci.debian.net/data/autopkgtest/testing/s390x/s/skimage/46978110/log.gz
=== FAILURES
===
300s __ test_imread_handle
__
300s 300s def test_imread_handle():
300s expected = np.load(fetch('data/chessboard_GRAY_U8.npy'))
300s with open(fetch('data/chessboard_GRAY_U16.tif'), 'rb') as fh:
300s img = imread(fh)
300s > assert img.dtype == np.uint16
300s E AssertionError: assert dtype('
300s E+ where dtype('0, 0],\n [255, 255, 255, ..., 0, 0, 0],\n [255, 255,
255, ..., 0, 0, 0],\n ...,\n [ 0, 0, 0, ..., 255,
255, 255],\n [ 0, 0, 0, ..., 255, 255, 255],\n [ 0,
0, 0, ..., 255, 255, 255]], dtype='
300s E+ and= np.uint16
300s 300s
/usr/lib/python3/dist-packages/skimage/io/tests/test_tifffile.py:48:
AssertionError
300s === warnings summary
===
300s filters/tests/test_unsharp_mask.py: 480 warnings
300s
/usr/lib/python3/dist-packages/skimage/filters/tests/test_unsharp_mask.py:26:
RuntimeWarning: invalid value encountered in cast
300s array = ((array + offset) * 128).astype(dtype)
300s 300s io/tests/test_pil.py::test_png_round_trip
300s io/tests/test_pil.py::test_imsave_filelike
300s
/usr/lib/python3/dist-packages/skimage/io/_plugins/pil_plugin.py:105:
DeprecationWarning: The binary mode of fromstring is deprecated, as it
behaves surprisingly on unicode inputs. Use frombuffer instead
300s frame = np.fromstring(frame.tobytes(), dtype)
300s 300s measure/tests/test_fit.py::test_ellipse_parameter_stability
300s /usr/lib/python3/dist-packages/skimage/measure/fit.py:526:
RuntimeWarning: divide by zero encountered in scalar divide
300s phi = 0.5 * np.arctan((2. * b) / (a - c))
300s 300s
transform/tests/test_pyramids.py::test_pyramid_dtype_support[pyramid_gaussian-uint8]
300s
transform/tests/test_pyramids.py::test_pyramid_dtype_support[pyramid_laplacian-uint8]
300s
/usr/lib/python3/dist-packages/skimage/transform/tests/test_pyramids.py:208:
RuntimeWarning: invalid value encountered in cast
300s img = np.random.randn(32, 8).astype(dtype)
300s 300s
../../../../usr/lib/python3/dist-packages/_pytest/cacheprovider.py:446
300s /usr/lib/python3/dist-packages/_pytest/cacheprovider.py:446:
PytestCacheWarning: could not create cache path
/usr/lib/python3/dist-packages/skimage/.pytest_cache/v/cache/nodeids:
[Errno 13] Permission denied:
'/usr/lib/python3/dist-packages/skimage/.pytest_cache'
300s config.cache.set("cache/nodeids", sorted(self.cached_nodeids))
300s 300s
../../../../usr/lib/python3/dist-packages/_pytest/cacheprovider.py:398
300s /usr/lib/python3/dist-packages/_pytest/cacheprovider.py:398:
PytestCacheWarning: could not create cache path
/usr/lib/python3/dist-packages/skimage/.pytest_cache/v/cache/lastfailed:
[Errno 13] Permission denied:
'/usr/lib/python3/dist-packages/skimage/.pytest_cache'
300s config.cache.set("cache/lastfailed", self.lastfailed)
300s 300s ../../../../usr/lib/python3/dist-packages/_pytest/stepwise.py:57
300s /usr/lib/python3/dist-packages/_pytest/stepwise.py:57:
PytestCacheWarning: could not create cache path
Bug#1071782: skimage: autopkgtest needs update for new version of pytest on s390x
Source: skimage
Version: 0.22.0-3
Severity: serious
X-Debbugs-CC: pyt...@packages.debian.org
Tags: sid trixie
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:pytest
Dear maintainer(s),
With a recent upload of pytest the autopkgtest of skimage fails in
testing on s390x when that autopkgtest is run with the binary packages
of pytest from unstable. It passes when run with only packages from
testing. In tabular form:
passfail
pytest from testing8.1.2-1
skimagefrom testing0.22.0-3
all others from testingfrom testing
I copied some of the output at the bottom of this report. I'll note that
s390x is our only big endian architecture with autopgktest.
Currently this regression is blocking the migration of pytest to testing
[1]. Of course, pytest shouldn't just break your autopkgtest (or even
worse, your package), but due to the nature of the package pytest I
suspect that your package just needs to update to the new situation.
If this is a real problem in your package (and not only in your
autopkgtest), the right binary package(s) from pytest should really add
a versioned Breaks on the unfixed version of (one of your) package(s).
Note: the Breaks is nice even if the issue is only in the autopkgtest as
it helps the migration software to figure out the right versions to
combine in the tests.
More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
Paul
[1] https://qa.debian.org/excuses.php?package=pytest
https://ci.debian.net/data/autopkgtest/testing/s390x/s/skimage/46978110/log.gz
=== FAILURES
===
300s __ test_imread_handle
__
300s 300s def test_imread_handle():
300s expected = np.load(fetch('data/chessboard_GRAY_U8.npy'))
300s with open(fetch('data/chessboard_GRAY_U16.tif'), 'rb') as fh:
300s img = imread(fh)
300s > assert img.dtype == np.uint16
300s E AssertionError: assert dtype('
300s E+ where dtype('0, 0],\n [255, 255, 255, ..., 0, 0, 0],\n [255, 255,
255, ..., 0, 0, 0],\n ...,\n [ 0, 0, 0, ..., 255,
255, 255],\n [ 0, 0, 0, ..., 255, 255, 255],\n [ 0,
0, 0, ..., 255, 255, 255]], dtype='
300s E+ and= np.uint16
300s 300s
/usr/lib/python3/dist-packages/skimage/io/tests/test_tifffile.py:48:
AssertionError
300s === warnings summary
===
300s filters/tests/test_unsharp_mask.py: 480 warnings
300s
/usr/lib/python3/dist-packages/skimage/filters/tests/test_unsharp_mask.py:26:
RuntimeWarning: invalid value encountered in cast
300s array = ((array + offset) * 128).astype(dtype)
300s 300s io/tests/test_pil.py::test_png_round_trip
300s io/tests/test_pil.py::test_imsave_filelike
300s
/usr/lib/python3/dist-packages/skimage/io/_plugins/pil_plugin.py:105:
DeprecationWarning: The binary mode of fromstring is deprecated, as it
behaves surprisingly on unicode inputs. Use frombuffer instead
300s frame = np.fromstring(frame.tobytes(), dtype)
300s 300s measure/tests/test_fit.py::test_ellipse_parameter_stability
300s /usr/lib/python3/dist-packages/skimage/measure/fit.py:526:
RuntimeWarning: divide by zero encountered in scalar divide
300s phi = 0.5 * np.arctan((2. * b) / (a - c))
300s 300s
transform/tests/test_pyramids.py::test_pyramid_dtype_support[pyramid_gaussian-uint8]
300s
transform/tests/test_pyramids.py::test_pyramid_dtype_support[pyramid_laplacian-uint8]
300s
/usr/lib/python3/dist-packages/skimage/transform/tests/test_pyramids.py:208:
RuntimeWarning: invalid value encountered in cast
300s img = np.random.randn(32, 8).astype(dtype)
300s 300s
../../../../usr/lib/python3/dist-packages/_pytest/cacheprovider.py:446
300s /usr/lib/python3/dist-packages/_pytest/cacheprovider.py:446:
PytestCacheWarning: could not create cache path
/usr/lib/python3/dist-packages/skimage/.pytest_cache/v/cache/nodeids:
[Errno 13] Permission denied:
'/usr/lib/python3/dist-packages/skimage/.pytest_cache'
300s config.cache.set("cache/nodeids", sorted(self.cached_nodeids))
300s 300s
../../../../usr/lib/python3/dist-packages/_pytest/cacheprovider.py:398
300s /usr/lib/python3/dist-packages/_pytest/cacheprovider.py:398:
PytestCacheWarning: could not create cache path
/usr/lib/python3/dist-packages/skimage/.pytest_cache/v/cache/lastfailed:
[Errno 13] Permission denied:
'/usr/lib/python3/dist-packages/skimage/.pytest_cache'
300s config.cache.set("cache/lastfailed", self.lastfailed)
300s 300s ../../../../usr/lib/python3/dist-packages/_pytest/stepwise.py:57
300s /usr/lib/python3/dist-packages/_pytest/stepwise.py:57:
PytestCacheWarning: could not create cache path
Bug#1071782: skimage: autopkgtest needs update for new version of pytest on s390x
Source: skimage
Version: 0.22.0-3
Severity: serious
X-Debbugs-CC: pyt...@packages.debian.org
Tags: sid trixie
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:pytest
Dear maintainer(s),
With a recent upload of pytest the autopkgtest of skimage fails in
testing on s390x when that autopkgtest is run with the binary packages
of pytest from unstable. It passes when run with only packages from
testing. In tabular form:
passfail
pytest from testing8.1.2-1
skimagefrom testing0.22.0-3
all others from testingfrom testing
I copied some of the output at the bottom of this report. I'll note that
s390x is our only big endian architecture with autopgktest.
Currently this regression is blocking the migration of pytest to testing
[1]. Of course, pytest shouldn't just break your autopkgtest (or even
worse, your package), but due to the nature of the package pytest I
suspect that your package just needs to update to the new situation.
If this is a real problem in your package (and not only in your
autopkgtest), the right binary package(s) from pytest should really add
a versioned Breaks on the unfixed version of (one of your) package(s).
Note: the Breaks is nice even if the issue is only in the autopkgtest as
it helps the migration software to figure out the right versions to
combine in the tests.
More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
Paul
[1] https://qa.debian.org/excuses.php?package=pytest
https://ci.debian.net/data/autopkgtest/testing/s390x/s/skimage/46978110/log.gz
=== FAILURES
===
300s __ test_imread_handle
__
300s 300s def test_imread_handle():
300s expected = np.load(fetch('data/chessboard_GRAY_U8.npy'))
300s with open(fetch('data/chessboard_GRAY_U16.tif'), 'rb') as fh:
300s img = imread(fh)
300s > assert img.dtype == np.uint16
300s E AssertionError: assert dtype('
300s E+ where dtype('0, 0],\n [255, 255, 255, ..., 0, 0, 0],\n [255, 255,
255, ..., 0, 0, 0],\n ...,\n [ 0, 0, 0, ..., 255,
255, 255],\n [ 0, 0, 0, ..., 255, 255, 255],\n [ 0,
0, 0, ..., 255, 255, 255]], dtype='
300s E+ and= np.uint16
300s 300s
/usr/lib/python3/dist-packages/skimage/io/tests/test_tifffile.py:48:
AssertionError
300s === warnings summary
===
300s filters/tests/test_unsharp_mask.py: 480 warnings
300s
/usr/lib/python3/dist-packages/skimage/filters/tests/test_unsharp_mask.py:26:
RuntimeWarning: invalid value encountered in cast
300s array = ((array + offset) * 128).astype(dtype)
300s 300s io/tests/test_pil.py::test_png_round_trip
300s io/tests/test_pil.py::test_imsave_filelike
300s
/usr/lib/python3/dist-packages/skimage/io/_plugins/pil_plugin.py:105:
DeprecationWarning: The binary mode of fromstring is deprecated, as it
behaves surprisingly on unicode inputs. Use frombuffer instead
300s frame = np.fromstring(frame.tobytes(), dtype)
300s 300s measure/tests/test_fit.py::test_ellipse_parameter_stability
300s /usr/lib/python3/dist-packages/skimage/measure/fit.py:526:
RuntimeWarning: divide by zero encountered in scalar divide
300s phi = 0.5 * np.arctan((2. * b) / (a - c))
300s 300s
transform/tests/test_pyramids.py::test_pyramid_dtype_support[pyramid_gaussian-uint8]
300s
transform/tests/test_pyramids.py::test_pyramid_dtype_support[pyramid_laplacian-uint8]
300s
/usr/lib/python3/dist-packages/skimage/transform/tests/test_pyramids.py:208:
RuntimeWarning: invalid value encountered in cast
300s img = np.random.randn(32, 8).astype(dtype)
300s 300s
../../../../usr/lib/python3/dist-packages/_pytest/cacheprovider.py:446
300s /usr/lib/python3/dist-packages/_pytest/cacheprovider.py:446:
PytestCacheWarning: could not create cache path
/usr/lib/python3/dist-packages/skimage/.pytest_cache/v/cache/nodeids:
[Errno 13] Permission denied:
'/usr/lib/python3/dist-packages/skimage/.pytest_cache'
300s config.cache.set("cache/nodeids", sorted(self.cached_nodeids))
300s 300s
../../../../usr/lib/python3/dist-packages/_pytest/cacheprovider.py:398
300s /usr/lib/python3/dist-packages/_pytest/cacheprovider.py:398:
PytestCacheWarning: could not create cache path
/usr/lib/python3/dist-packages/skimage/.pytest_cache/v/cache/lastfailed:
[Errno 13] Permission denied:
'/usr/lib/python3/dist-packages/skimage/.pytest_cache'
300s config.cache.set("cache/lastfailed", self.lastfailed)
300s 300s ../../../../usr/lib/python3/dist-packages/_pytest/stepwise.py:57
300s /usr/lib/python3/dist-packages/_pytest/stepwise.py:57:
PytestCacheWarning: could not create cache path
Bug#1071767: fpdf2: autopkgtest needs update for new version of pytest
Source: fpdf2
Version: 2.7.9-1
Severity: serious
X-Debbugs-CC: pyt...@packages.debian.org
Tags: sid trixie
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:pytest
Dear maintainer(s),
With a recent upload of pytest the autopkgtest of fpdf2 fails in testing
when that autopkgtest is run with the binary packages of pytest from
unstable. It passes when run with only packages from testing. In tabular
form:
passfail
pytest from testing8.1.2-1
fpdf2 from testing2.7.9-1
all others from testingfrom testing
I copied some of the output at the bottom of this report.
Currently this regression is blocking the migration of pytest to testing
[1]. Of course, pytest shouldn't just break your autopkgtest (or even
worse, your package), but given the nature of the package pytest, I
suspect your package needs to update to the new situation.
If this is a real problem in your package (and not only in your
autopkgtest), the right binary package(s) from pytest should really add
a versioned Breaks on the unfixed version of (one of your) package(s).
Note: the Breaks is nice even if the issue is only in the autopkgtest as
it helps the migration software to figure out the right versions to
combine in the tests.
More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
Paul
[1] https://qa.debian.org/excuses.php?package=pytest
https://ci.debian.net/data/autopkgtest/testing/amd64/f/fpdf2/46966995/log.gz
=== FAILURES
===
263s __ test_multi_cell_split_only
__
263s 263s def test_multi_cell_split_only(): # discussion 314
263s pdf = FPDF()
263s pdf.add_page()
263s pdf.set_font("Helvetica", size=TEXT_SIZE)
263s text = "Lorem ipsum Ut nostrud irure reprehenderit anim
nostrud dolore sed ut"
263s expected = [
263s "Lorem ipsum Ut nostrud irure",
263s "reprehenderit anim nostrud",
263s "dolore sed ut",
263s ]
263s with pytest.warns(
263s DeprecationWarning, match='The parameter "split_only"
is deprecated.'
263s ) as record:
263s assert (
263s pdf.multi_cell(w=0, h=LINE_HEIGHT, text=text,
split_only=True) == expected
263s )
263s > assert len(record) == 1
263s E assert 2 == 1
263s E+ where 2 = len(WarningsChecker(record=True))
263s 263s test/text/test_multi_cell.py:267: AssertionError
263s === warnings summary
===
263s test/image/test_vector_image.py::test_svg_image_no_viewbox
263s
/tmp/autopkgtest-lxc.vf1cnias/downtmp/build.w5B/src/test/image/test_vector_image.py:45:
UserWarning: has no "viewBox", using its "width" & "height" as
default "viewBox"
263s img = pdf.image(SVG_SRCDIR / "simple_rect_no_viewbox.svg")
263s 263s
test/image/test_vector_image.py::test_svg_image_with_custom_width_and_no_viewbox
263s
/tmp/autopkgtest-lxc.vf1cnias/downtmp/build.w5B/src/test/image/test_vector_image.py:75:
UserWarning: has no "viewBox", using its "width" & "height" as
default "viewBox"
263s img = pdf.image(SVG_SRCDIR / "simple_rect_no_viewbox.svg", w=60)
263s 263s
test/image/test_vector_image.py::test_svg_image_with_custom_size_and_no_viewbox
263s
/tmp/autopkgtest-lxc.vf1cnias/downtmp/build.w5B/src/test/image/test_vector_image.py:106:
UserWarning: has no "viewBox", using its "width" & "height" as
default "viewBox"
263s img = pdf.image(SVG_SRCDIR / "simple_rect_no_viewbox.svg",
x=50, y=50, w=30, h=60)
263s 263s
test/image/test_vector_image.py::test_svg_image_style_inherited_from_fpdf
263s
/tmp/autopkgtest-lxc.vf1cnias/downtmp/build.w5B/src/test/image/test_vector_image.py:132:
UserWarning: has no "viewBox", using its "width" & "height" as
default "viewBox"
263s pdf.image(
263s 263s test/image/test_vector_image.py::test_svg_image_from_bytesio
263s
/tmp/autopkgtest-lxc.vf1cnias/downtmp/build.w5B/src/test/image/test_vector_image.py:145:
UserWarning: has no "viewBox", using its "width" & "height" as
default "viewBox"
263s pdf.image(
263s 263s test/image/test_vector_image.py::test_svg_image_from_bytes
263s
/tmp/autopkgtest-lxc.vf1cnias/downtmp/build.w5B/src/test/image/test_vector_image.py:158:
UserWarning: has no "viewBox", using its "width" & "height" as
default "viewBox"
263s pdf.image(
263s 263s
test/table/test_table_extraction.py::test_camelot_extract_simple_table[table_simple.pdf-lattice]
263s
test/table/test_table_extraction.py::test_camelot_extract_simple_table[table_with_images.pdf-lattice]
263s
test/table/test_table_extraction.py::test_camelot_extract_simple_table[table_with_images_and_img_fill_width.pdf-lattice]
263s
Bug#1071767: fpdf2: autopkgtest needs update for new version of pytest
Source: fpdf2
Version: 2.7.9-1
Severity: serious
X-Debbugs-CC: pyt...@packages.debian.org
Tags: sid trixie
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:pytest
Dear maintainer(s),
With a recent upload of pytest the autopkgtest of fpdf2 fails in testing
when that autopkgtest is run with the binary packages of pytest from
unstable. It passes when run with only packages from testing. In tabular
form:
passfail
pytest from testing8.1.2-1
fpdf2 from testing2.7.9-1
all others from testingfrom testing
I copied some of the output at the bottom of this report.
Currently this regression is blocking the migration of pytest to testing
[1]. Of course, pytest shouldn't just break your autopkgtest (or even
worse, your package), but given the nature of the package pytest, I
suspect your package needs to update to the new situation.
If this is a real problem in your package (and not only in your
autopkgtest), the right binary package(s) from pytest should really add
a versioned Breaks on the unfixed version of (one of your) package(s).
Note: the Breaks is nice even if the issue is only in the autopkgtest as
it helps the migration software to figure out the right versions to
combine in the tests.
More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
Paul
[1] https://qa.debian.org/excuses.php?package=pytest
https://ci.debian.net/data/autopkgtest/testing/amd64/f/fpdf2/46966995/log.gz
=== FAILURES
===
263s __ test_multi_cell_split_only
__
263s 263s def test_multi_cell_split_only(): # discussion 314
263s pdf = FPDF()
263s pdf.add_page()
263s pdf.set_font("Helvetica", size=TEXT_SIZE)
263s text = "Lorem ipsum Ut nostrud irure reprehenderit anim
nostrud dolore sed ut"
263s expected = [
263s "Lorem ipsum Ut nostrud irure",
263s "reprehenderit anim nostrud",
263s "dolore sed ut",
263s ]
263s with pytest.warns(
263s DeprecationWarning, match='The parameter "split_only"
is deprecated.'
263s ) as record:
263s assert (
263s pdf.multi_cell(w=0, h=LINE_HEIGHT, text=text,
split_only=True) == expected
263s )
263s > assert len(record) == 1
263s E assert 2 == 1
263s E+ where 2 = len(WarningsChecker(record=True))
263s 263s test/text/test_multi_cell.py:267: AssertionError
263s === warnings summary
===
263s test/image/test_vector_image.py::test_svg_image_no_viewbox
263s
/tmp/autopkgtest-lxc.vf1cnias/downtmp/build.w5B/src/test/image/test_vector_image.py:45:
UserWarning: has no "viewBox", using its "width" & "height" as
default "viewBox"
263s img = pdf.image(SVG_SRCDIR / "simple_rect_no_viewbox.svg")
263s 263s
test/image/test_vector_image.py::test_svg_image_with_custom_width_and_no_viewbox
263s
/tmp/autopkgtest-lxc.vf1cnias/downtmp/build.w5B/src/test/image/test_vector_image.py:75:
UserWarning: has no "viewBox", using its "width" & "height" as
default "viewBox"
263s img = pdf.image(SVG_SRCDIR / "simple_rect_no_viewbox.svg", w=60)
263s 263s
test/image/test_vector_image.py::test_svg_image_with_custom_size_and_no_viewbox
263s
/tmp/autopkgtest-lxc.vf1cnias/downtmp/build.w5B/src/test/image/test_vector_image.py:106:
UserWarning: has no "viewBox", using its "width" & "height" as
default "viewBox"
263s img = pdf.image(SVG_SRCDIR / "simple_rect_no_viewbox.svg",
x=50, y=50, w=30, h=60)
263s 263s
test/image/test_vector_image.py::test_svg_image_style_inherited_from_fpdf
263s
/tmp/autopkgtest-lxc.vf1cnias/downtmp/build.w5B/src/test/image/test_vector_image.py:132:
UserWarning: has no "viewBox", using its "width" & "height" as
default "viewBox"
263s pdf.image(
263s 263s test/image/test_vector_image.py::test_svg_image_from_bytesio
263s
/tmp/autopkgtest-lxc.vf1cnias/downtmp/build.w5B/src/test/image/test_vector_image.py:145:
UserWarning: has no "viewBox", using its "width" & "height" as
default "viewBox"
263s pdf.image(
263s 263s test/image/test_vector_image.py::test_svg_image_from_bytes
263s
/tmp/autopkgtest-lxc.vf1cnias/downtmp/build.w5B/src/test/image/test_vector_image.py:158:
UserWarning: has no "viewBox", using its "width" & "height" as
default "viewBox"
263s pdf.image(
263s 263s
test/table/test_table_extraction.py::test_camelot_extract_simple_table[table_simple.pdf-lattice]
263s
test/table/test_table_extraction.py::test_camelot_extract_simple_table[table_with_images.pdf-lattice]
263s
test/table/test_table_extraction.py::test_camelot_extract_simple_table[table_with_images_and_img_fill_width.pdf-lattice]
263s
Bug#1071766: src:sccache: fails to migrate to testing for too long: FTBFS
Source: sccache Version: 0.7.7-1 Severity: serious Control: close -1 0.8.0-3 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:sccache has been trying to migrate for 81 days [2]. Hence, I am filing this bug. The version in unstable failed to build. 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=sccache OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1071766: src:sccache: fails to migrate to testing for too long: FTBFS
Source: sccache Version: 0.7.7-1 Severity: serious Control: close -1 0.8.0-3 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:sccache has been trying to migrate for 81 days [2]. Hence, I am filing this bug. The version in unstable failed to build. 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=sccache OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1071764: src:kmod: fails to migrate to testing for too long: unresolved RC bug
Source: kmod Version: 31+20240202-2 Severity: serious Control: close -1 32-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:kmod has been trying to migrate for 76 days [2]. Hence, I am filing this bug. The version in unstable has an unresolved RC bug (it failed to build on buildds for armel and armhf). 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=kmod OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1071764: src:kmod: fails to migrate to testing for too long: unresolved RC bug
Source: kmod Version: 31+20240202-2 Severity: serious Control: close -1 32-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:kmod has been trying to migrate for 76 days [2]. Hence, I am filing this bug. The version in unstable has an unresolved RC bug (it failed to build on buildds for armel and armhf). 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=kmod OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)
Hi On 21-05-2024 1:08 p.m., Sean Whitton wrote: PS: I've always wondered if the dgit server shouldn't track history, even if uploads don't happen via it. A dgit clone could (should?) already provide available history, even if no upload happened via it yet. Well, 'dgit clone' adds a vcs-git remote pointing at the maintainer's history. So it sort of does this. We could make it do more. Huh. Than my workflow hides this. All I'm often seeing is just the tar content represented in a commit, the latest Debian packing in another and the merge of these two (if I recall and describe what I recall correctly). I always thought that dgit clone generated that on my computer if there was no git content on the dgit server. I'll try to remember this next time I run my no-changes-source-only upload script. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Re: About i386 support
Hi, On 20-05-2024 4:50 p.m., Ben Hutchings wrote: There is a tension here between the interests of (a) users that want to run proprietary i386 binaries on 64-bit CPUs, and (b) those who want to keep using 32-bit CPUs. If i386 is meant for group (a) then the baseline should be raised to include the features that 64-bit CPUs provide, but if it's also for group (b) then this mustn't happen. The Release Team expects the Debian i386 official port to go to (a). Paul, wearing his Release Team hat. OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1071508: RM: siridb-server [armhf] -- ROM; started to FTBFS on armhf since around time_t
Package: ftp.debian.org Severity: normal Tags: ftbfs User: ftp.debian@packages.debian.org Usertags: remove Hi, Since around the time_t transition, siridb-server FTBFS due to valgrind segfaulting during testing. Upstream doesn't seem to be interested to fix the issue and I lack the skills. Can siridb-server/armhf please be removed from the archive? Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1067064: transition: petsc hypre
Hi On 20-05-2024 11:26 a.m., Drew Parsons wrote: Something weird happened with the slepc upload (3.20.2+dfsg1-1). See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1071469 Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1067064: transition: petsc hypre
Hi On 20-05-2024 11:26 a.m., Drew Parsons wrote: Something weird happened with the slepc upload (3.20.2+dfsg1-1). See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1071469 Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1071506: release-notes: wireplumber NEWS mentions "no automatic conversion"
Package: release-notes Severity: normal X-Debbugs-CC: wireplum...@packages.debian.org I read the wireplumber NEWS [1] when I upgraded my system. It's probably worth mentioning it somewhere in the release-notes. Paul [1] https://salsa.debian.org/utopia-team/wireplumber/-/blob/d697eb4fb736f07571fc5964561ae010cdcd5c1a/debian/NEWS and I OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1071506: release-notes: wireplumber NEWS mentions "no automatic conversion"
Package: release-notes Severity: normal X-Debbugs-CC: wireplum...@packages.debian.org I read the wireplumber NEWS [1] when I upgraded my system. It's probably worth mentioning it somewhere in the release-notes. Paul [1] https://salsa.debian.org/utopia-team/wireplumber/-/blob/d697eb4fb736f07571fc5964561ae010cdcd5c1a/debian/NEWS and I OpenPGP_signature.asc Description: OpenPGP digital signature
[Pkg-utopia-maintainers] Bug#1071506: release-notes: wireplumber NEWS mentions "no automatic conversion"
Package: release-notes Severity: normal X-Debbugs-CC: wireplum...@packages.debian.org I read the wireplumber NEWS [1] when I upgraded my system. It's probably worth mentioning it somewhere in the release-notes. Paul [1] https://salsa.debian.org/utopia-team/wireplumber/-/blob/d697eb4fb736f07571fc5964561ae010cdcd5c1a/debian/NEWS and I OpenPGP_signature.asc Description: OpenPGP digital signature ___ Pkg-utopia-maintainers mailing list Pkg-utopia-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-utopia-maintainers
Bug#1068559: [Pkg-zfsonlinux-devel] Bug#1068559: Bug#1068559: zfs-linux: isolation-machine autopkgtest fails: zfs-test-suite times out (hangs?)
Hi, On 19-05-2024 2:55 p.m., 陈 晟祺 wrote: My concern now is that the results do not seem to be stable or reproducible. That's an reoccurring problem in lots of places, yes. Is there any convention in handling such situation? E.g., should I mark all zfs-test-suite-x as flaky and treat them as reference only? It depends ;) The disadvantage of marking the whole test stanza as flaky means that it won't block regressions at all. Depending on how the test (I mean per stanza in d/t/control) is set up, it makes more sense to mark individual tests as flaky then the whole suite/stanza. However, if there's not enough granularity, that doesn't really help. Then there's the infrastructure argument. If your test is not a cheap one, running a long test only to fail flaky is a rather high price for very little gain. Then it might make more sense to not run the test by default (add a unknown restriction for example) and only use the test for manual checking, where you can judge (or rerun) the test as you judge fit. In the end it's your decision. All I can say is that tests that are flaky enough (my level is roughly worse than 1/8) and not marked as such are considered RC buggy. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1071439: file wrongly identifies php script as "C source, ASCII text"
Package: file Version: 1:5.45-3 Severity: normal Hi, To prevent missing setting the execution bit on php scripts in bin:cacti, I use `file` in my d/rules to detect them. Lintian complains that I miss a file and it's right. paul@mulciber ~/packages/cacti/cacti $ file cli/remove_broken_graphs.php cli/remove_broken_graphs.php: C source, ASCII text I'll attach the file, which can also be found here: https://salsa.debian.org/debian/cacti/-/raw/b57583fe4e8dafa5004135c66f7e7f547b241d4a/cli/remove_broken_graphs.php Thanks for maintaining file. 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) Kernel taint flags: TAINT_WARN 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 file depends on: ii libc6 2.38-11 ii libmagic1t64 1:5.45-3 file recommends no packages. file suggests no packages. -- no debconf information <> OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)
Two mistakes spotted On 19-05-2024 10:05 a.m., Paul Gevers wrote: I think there's a large majority (maybe even consensus) that believe you *should* have the packaging in VCS I meant "at least should", as in "should or must". I think what pere did [3] [3] https://people.skolelinux.org/pere/blog/45_orphaned_Debian_packages_moved_to_git__391_to_go.html Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)
Hi all,
In this discussion about mandating things, I've been wondering
On 19-05-2024 9:11 a.m., Jonas Smedegaard wrote:
* mandate VCS-tracking
* Yes
* mandate the use of one specific VCS
* Yes: git
What do people think this should mean, a *should* or *must* in policy?
That the package has a RC bug if the packaging isn't tracked in git? And
if the packaging is in git but I forgot to push my latest changes to the
documented git server (this happens regularly to me as I do most uploads
with dgit)? RC? In all suites where the packaging version isn't pushed
for? And how about NMU's? (I just checked a random package without git:
aspell-am, last non-NMU upload was in 2013)?
If *must* and thus RC, can the issue be fixed by "NMU"? I.e. if the
person that did the changes, (and has nice local commits) somehow isn't
available, will the package (if not key) be auto-removed? Or can
everybody fix the repo? What if you don't have write access to the
existing repo? And then what if the uploader comes back and tries to
push the real history? What if my harddisk with local changes crashes
before I push (again, I forget that sometimes, but for me luckily dgit
will mostly have the commits).
Or is this "just a bug", maybe even at level important, but no other
consequences. Than I think this discussion is going to be moot. I don't
think there's much forcing possible and I think most already agree that
stuff *should* be in VCS, so this isn't going to change for those in
favor. And does it really add enough value if those that are forced are
just going to do "gbp import-dsc" for each upload to the archive on a
./debian only repository? Because that (or better) we could already
automate (see also my PS).
I'm against mandating ("must"). I think there's a large majority (maybe
even consensus) that believe you *should* have the packaging in VCS (and
I agree with that). Most packages already are (hopefully maintained) in
git (93% for testing) [1] on salsa (86%) [2], so I propose we stop the
discussion. I think what pere did [3] changed more than this whole
discussion: already 45 *orphaned* packages converted to git by 25 April,
which means my numbers above are on the low side. The remaining 438 QA
maintained (!!??) packages constitute close to 20% of the packages not
in git.
Paul
PS: I've always wondered if the dgit server shouldn't track history,
even if uploads don't happen via it. A dgit clone could (should?)
already provide available history, even if no upload happened via it yet.
[1] https://trends.debian.net/vcs_testing-stacked.png
[2] https://trends.debian.net/vcs-hosting_testing-stacked.png
OpenPGP_signature.asc
Description: OpenPGP digital signature
Bug#1068559: [Pkg-zfsonlinux-devel] Bug#1068559: Bug#1068559: zfs-linux: isolation-machine autopkgtest fails: zfs-test-suite times out (hangs?)
Hi On 19-05-2024 6:25 a.m., 陈 晟祺 wrote: I have made more adjustments, basically skipping some flaky tests in VM. Now new version 2.2.4-1 is in the archive, please try that again when available. I already noticed yesterday and had it run; it failed. (Currently) top one here: https://ci.debian.net/packages/z/zfs-linux/testing/amd64/ Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1071413: src:rust-debversion: fails to migrate to testing for too long: RC buggy Depends
Source: rust-debversion Version: 0.2.2-1 Severity: serious Control: close -1 0.3.0-1 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:rust-debversion has been trying to migrate for 70 days [2]. Hence, I am filing this bug. The version in unstable apparently has a new dependency chain that ends with rust-rsa which has an unresolved RC security issue and isn't migrating to testing. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=rust-debversion OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1071413: src:rust-debversion: fails to migrate to testing for too long: RC buggy Depends
Source: rust-debversion Version: 0.2.2-1 Severity: serious Control: close -1 0.3.0-1 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:rust-debversion has been trying to migrate for 70 days [2]. Hence, I am filing this bug. The version in unstable apparently has a new dependency chain that ends with rust-rsa which has an unresolved RC security issue and isn't migrating to testing. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=rust-debversion OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1071412: src:tracker: fails to migrate to testing for too long: autopkgtest regression
Source: tracker Version: 3.4.2-3 Severity: serious Control: close -1 3.7.3-1 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Control: block -1 by 1068468 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:tracker has been trying to migrate for 71 days [2]. Hence, I am filing this bug. The version in unstable fails its own autopkgtest as reported in bug 1068468. 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=tracker OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1071412: src:tracker: fails to migrate to testing for too long: autopkgtest regression
Source: tracker Version: 3.4.2-3 Severity: serious Control: close -1 3.7.3-1 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Control: block -1 by 1068468 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:tracker has been trying to migrate for 71 days [2]. Hence, I am filing this bug. The version in unstable fails its own autopkgtest as reported in bug 1068468. 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=tracker OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1071410: src:diffoscope: fails to migrate to testing for too long: FTBFS and blocked by Build-Depends
Source: diffoscope Version: 259 Severity: serious Control: close -1 267 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:diffoscope has been trying to migrate for 71 days [2]. Hence, I am filing this bug. The version in unstable failed to build and is also blocked by apktool, which was removed from testing due to an unresolved RC 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. 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=diffoscope OpenPGP_signature.asc Description: OpenPGP digital signature ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#1071410: src:diffoscope: fails to migrate to testing for too long: FTBFS and blocked by Build-Depends
Source: diffoscope Version: 259 Severity: serious Control: close -1 267 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:diffoscope has been trying to migrate for 71 days [2]. Hence, I am filing this bug. The version in unstable failed to build and is also blocked by apktool, which was removed from testing due to an unresolved RC 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. 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=diffoscope OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1071410: src:diffoscope: fails to migrate to testing for too long: FTBFS and blocked by Build-Depends
Source: diffoscope Version: 259 Severity: serious Control: close -1 267 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:diffoscope has been trying to migrate for 71 days [2]. Hence, I am filing this bug. The version in unstable failed to build and is also blocked by apktool, which was removed from testing due to an unresolved RC 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. 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=diffoscope OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1071409: src:fakeroot: fails to migrate to testing for too long: FTBFS on armel, armhf
Source: fakeroot 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:fakeroot has been trying to migrate for 73 days [2]. Hence, I am filing this bug. The version in unstable failed to build on armel and armhf. On reproducible-builds, a build on i386, arm64 and armhf today also failed (only amd64 passed). 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=fakeroot OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1071409: src:fakeroot: fails to migrate to testing for too long: FTBFS on armel, armhf
Source: fakeroot 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:fakeroot has been trying to migrate for 73 days [2]. Hence, I am filing this bug. The version in unstable failed to build on armel and armhf. On reproducible-builds, a build on i386, arm64 and armhf today also failed (only amd64 passed). 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=fakeroot OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1071403: src:geoalchemy2: fails to migrate to testing for too long: B-D on mysql which isn't allowed to migrate
Source: geoalchemy2 Version: 0.13.3-2 Severity: serious Control: close -1 0.14.6-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:geoalchemy2 has been trying to migrate for 73 days [2]. Hence, I am filing this bug. The version in unstable build depends on mysql, which for security support isn't allowed to migrate (Debian has MariaDB). 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=geoalchemy2 OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1071403: src:geoalchemy2: fails to migrate to testing for too long: B-D on mysql which isn't allowed to migrate
Source: geoalchemy2 Version: 0.13.3-2 Severity: serious Control: close -1 0.14.6-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:geoalchemy2 has been trying to migrate for 73 days [2]. Hence, I am filing this bug. The version in unstable build depends on mysql, which for security support isn't allowed to migrate (Debian has MariaDB). 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=geoalchemy2 OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1071402: src:gnome-shell-extension-arc-menu: fails to migrate to testing for too long: unsatisfiable dependency
Source: gnome-shell-extension-arc-menu Version: 49+forkv29-4 Severity: serious Control: close -1 55-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:gnome-shell-extension-arc-menu has been trying to migrate for 75 days [2]. Hence, I am filing this bug. The version in unstable has unsatisfiable 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=gnome-shell-extension-arc-menu OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1071402: src:gnome-shell-extension-arc-menu: fails to migrate to testing for too long: unsatisfiable dependency
Source: gnome-shell-extension-arc-menu Version: 49+forkv29-4 Severity: serious Control: close -1 55-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:gnome-shell-extension-arc-menu has been trying to migrate for 75 days [2]. Hence, I am filing this bug. The version in unstable has unsatisfiable 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=gnome-shell-extension-arc-menu OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1071401: src:cross-toolchain-base-mipsen: unsatisfied build dependency in testing: linux-source-6.6 (>= 6.6.11)
Source: cross-toolchain-base-mipsen Version: 27 Severity: serious Tags: sid trixie User: debian...@lists.debian.org Usertags: edos-uninstallable Dear maintainer(s), Dose [1] is reporting a build issue with your package, it's missing a build dependency. Obviously your build dependencies shouldn't be removed from testing, but unfortunately there are multiple scenarios where that can happen nevertheless. To uphold our social contract, Debian requires that packages can be rebuild from source in the suite we are shipping them, so currently this is a serious issue with your package in testing. Can you please investigate the situation and figure out how to resolve it? Regularly, if the build dependency is available in unstable, helping the maintainer of your Build-Depends to enable migration to testing is a great way to solve the issue. If your build dependency is gone from unstable and testing, you'll have to fix the build process in some other way. Paul Note: this bug report was sent after some quick manual checks using a template. Please reach out to me if you believe I made a mistake in my process. [1] https://qa.debian.org/dose/debcheck/src_testing_main/latest/amd64.html OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1071401: src:cross-toolchain-base-mipsen: unsatisfied build dependency in testing: linux-source-6.6 (>= 6.6.11)
Source: cross-toolchain-base-mipsen Version: 27 Severity: serious Tags: sid trixie User: debian...@lists.debian.org Usertags: edos-uninstallable Dear maintainer(s), Dose [1] is reporting a build issue with your package, it's missing a build dependency. Obviously your build dependencies shouldn't be removed from testing, but unfortunately there are multiple scenarios where that can happen nevertheless. To uphold our social contract, Debian requires that packages can be rebuild from source in the suite we are shipping them, so currently this is a serious issue with your package in testing. Can you please investigate the situation and figure out how to resolve it? Regularly, if the build dependency is available in unstable, helping the maintainer of your Build-Depends to enable migration to testing is a great way to solve the issue. If your build dependency is gone from unstable and testing, you'll have to fix the build process in some other way. Paul Note: this bug report was sent after some quick manual checks using a template. Please reach out to me if you believe I made a mistake in my process. [1] https://qa.debian.org/dose/debcheck/src_testing_main/latest/amd64.html OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1071399: src:ndcube: unsatisfied build dependency in testing: python3-sunpy
Source: ndcube Version: 2.2.0-1 Severity: serious Tags: sid trixie User: debian...@lists.debian.org Usertags: edos-uninstallable Dear maintainer(s), Dose [1] is reporting a build issue with your package, it's missing a build dependency. Obviously your build dependencies shouldn't be removed from testing, but unfortunately there are multiple scenarios where that can happen nevertheless. To uphold our social contract, Debian requires that packages can be rebuild from source in the suite we are shipping them, so currently this is a serious issue with your package in testing. Can you please investigate the situation and figure out how to resolve it? Regularly, if the build dependency is available in unstable, helping the maintainer of your Build-Depends to enable migration to testing is a great way to solve the issue. If your build dependency is gone from unstable and testing, you'll have to fix the build process in some other way. Paul Note: this bug report was sent after some quick manual checks using a template. Please reach out to me if you believe I made a mistake in my process. [1] https://qa.debian.org/dose/debcheck/src_testing_main/latest/amd64.html OpenPGP_signature.asc Description: OpenPGP digital signature
