Bug#1062955: marked as done (debian-cloud-images: unsatisfiable dependencies)
Your message dated Thu, 08 Feb 2024 07:48:57 + with message-id and subject line Bug#1062955: fixed in debian-cloud-images 0.0.8 has caused the Debian Bug report #1062955, regarding debian-cloud-images: unsatisfiable dependencies to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 1062955: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1062955 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Source: debian-cloud-images Version: 0.0.7 Severity: serious Hi Maintainer debian-cloud-images 0.0.7 introduced a dependency on systemd-timesyncd (not mentioned in the changelog), which makes the dependencies of debian-cloud-images-packages unsatisfiable [1] due to a conflict with chrony. The dependencies of debian-cloud-images-packages=0.0.7 cannot be satisfied in unstable on amd64, arm64, and ppc64el because: conflict between chrony and systemd-timesyncd Regards Graham [1] https://qa.debian.org/dose/debcheck/unstable_main/latest/packages/debian-cloud-images-packages.html#ba7045d5fe31253d7f974853bd0dca86 --- End Message --- --- Begin Message --- Source: debian-cloud-images Source-Version: 0.0.8 Done: Bastian Blank We believe that the bug you reported is fixed in the latest version of debian-cloud-images, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 1062...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Bastian Blank (supplier of updated debian-cloud-images package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Thu, 08 Feb 2024 08:02:37 +0100 Source: debian-cloud-images Architecture: source Version: 0.0.8 Distribution: unstable Urgency: medium Maintainer: Debian Cloud Team Changed-By: Bastian Blank Closes: 1062955 Changes: debian-cloud-images (0.0.8) unstable; urgency=medium . * Remove dependencies on conflicting packages. (closes: #1062955) Checksums-Sha1: 6ca05da86355c78b941674e90301d4665f936d29 1271 debian-cloud-images_0.0.8.dsc 3af1b4d152e27c190812272ffb4b0b9f15fa7008 4372 debian-cloud-images_0.0.8.tar.xz 8328a56e039cd27a9adf74c0369cc7d7d4202c4c 5289 debian-cloud-images_0.0.8_source.buildinfo Checksums-Sha256: 99de6983b32d7614c420321c7ce1af097ec3856be3a40c66b9290ff45288b413 1271 debian-cloud-images_0.0.8.dsc 7559b445ef280d643c19cc5823fade0e4a4248bfc299771432481ad03ab53793 4372 debian-cloud-images_0.0.8.tar.xz b94c45e719b052476730095d3319849721d81b51b80a112a4325dc0e712aecf6 5289 debian-cloud-images_0.0.8_source.buildinfo Files: 3c97eac3963fd8264de9267712045a9c 1271 web optional debian-cloud-images_0.0.8.dsc 9a9ff8ffd53bb84ff38bc74dc3836563 4372 web optional debian-cloud-images_0.0.8.tar.xz d21de95b7245f9f284bc4845252660ee 5289 web optional debian-cloud-images_0.0.8_source.buildinfo -BEGIN PGP SIGNATURE- iHUEARYIAB0WIQQ8pEKDNIgQDAQDOBFji0aBW7swjwUCZcSCXgAKCRBji0aBW7sw jxIhAP4mnEE4aHfKdO2rLSJNw2OZOAfgbQX6yeLEZp3KIRDy/QEAkHqUe8/zCihh q+6mMFAny0RRcOwuADwGw+z+n8EthQU= =Ol3q -END PGP SIGNATURE End Message ---
Bug#1063435: geopandas: test fail with pandas 2.x on 32 bit - int32 vs int64 mismatch
Package: python3-geopandas Version: 0.14.3-1 Severity: serious Control: block 1043240 by -1 In pandas 2.x (now in unstable), there are a few places where geopandas uses native-size int but the plain pandas objects used as test references are always int64, failing the test: https://ci.debian.net/packages/p/python-geopandas/testing/armhf/42777226/ Probably a reasonable response is to ignore this (check_index_type=False/check_dtype=False) but I haven't looked carefully.
Processed: geopandas: test fail with pandas 2.x on 32 bit - int32 vs int64 mismatch
Processing control commands: > block 1043240 by -1 Bug #1043240 [python3-pandas] transition: pandas 1.5 -> 2.1 1043240 was blocked by: 1044054 1044065 1044057 1053943 1053946 1044074 1044077 1043093 1053939 1053940 1063274 1053942 1053948 1044064 1044055 1044067 1053941 1043968 1044075 1044070 1044053 1044068 1044069 1044076 1053944 1053947 1044061 1044073 1044056 1053945 1044059 1044058 1044071 1044063 1044052 1050144 1044078 1044066 1044079 1044060 1044072 1043240 was blocking: 1056828 Added blocking bug(s) of 1043240: 1063435 -- 1043240: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1043240 1063435: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1063435 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: src:seqan-needle: fails to migrate to testing for too long: FTBFS on amd64 and arm64
Processing control commands: > close -1 1.0.2+ds-2 Bug #1063430 [src:seqan-needle] src:seqan-needle: fails to migrate to testing for too long: FTBFS on amd64 and arm64 Marked as fixed in versions seqan-needle/1.0.2+ds-2. Bug #1063430 [src:seqan-needle] src:seqan-needle: fails to migrate to testing for too long: FTBFS on amd64 and arm64 Marked Bug as done -- 1063430: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1063430 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: src:iwyu: fails to migrate to testing for too long: waiting for BD clang-17 on mips64el
Processing control commands: > close -1 8.21-1 Bug #1063428 [src:iwyu] src:iwyu: fails to migrate to testing for too long: waiting for BD clang-17 on mips64el Marked as fixed in versions iwyu/8.21-1. Bug #1063428 [src:iwyu] src:iwyu: fails to migrate to testing for too long: waiting for BD clang-17 on mips64el Marked Bug as done -- 1063428: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1063428 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: src:nng: fails to migrate to testing for too long: FTBFS on i386, ppc64el and s390x
Processing control commands: > close -1 1.7.2-1 Bug #1063427 [src:nng] src:nng: fails to migrate to testing for too long: FTBFS on i386, ppc64el and s390x Marked as fixed in versions nng/1.7.2-1. Bug #1063427 [src:nng] src:nng: fails to migrate to testing for too long: FTBFS on i386, ppc64el and s390x Marked Bug as done -- 1063427: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1063427 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: src:node-websocket: fails to migrate to testing for too long: FTBFS on armel
Processing control commands: > close -1 1.0.34+~cs10.0.25-2 Bug #1063426 [src:node-websocket] src:node-websocket: fails to migrate to testing for too long: FTBFS on armel Marked as fixed in versions node-websocket/1.0.34+~cs10.0.25-2. Bug #1063426 [src:node-websocket] src:node-websocket: fails to migrate to testing for too long: FTBFS on armel Marked Bug as done -- 1063426: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1063426 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: src:rust-gdk-pixbuf-sys: fails to migrate to testing for too long: autopkgtest failures
Processing control commands: > close -1 0.18.0-3 Bug #1063425 [src:rust-gdk-pixbuf-sys] src:rust-gdk-pixbuf-sys: fails to migrate to testing for too long: autopkgtest failures Marked as fixed in versions rust-gdk-pixbuf-sys/0.18.0-3. Bug #1063425 [src:rust-gdk-pixbuf-sys] src:rust-gdk-pixbuf-sys: fails to migrate to testing for too long: autopkgtest failures Marked Bug as done -- 1063425: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1063425 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: 1041027 is forwarded
Processing commands for cont...@bugs.debian.org: > forwarded 1041027 https://github.com/Tencent/rapidjson/issues/2118 Bug #1041027 [src:rapidjson] rapidjson FTBFS with googletest 1.13.0 Set Bug forwarded-to-address to 'https://github.com/Tencent/rapidjson/issues/2118'. > thanks Stopping processing here. Please contact me if you need assistance. -- 1041027: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1041027 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1063434: src:389-ds-base: fails to migrate to testing for too long: FTBFS on 32 bits
Source: 389-ds-base Version: 2.3.4+dfsg1-1.1 Severity: serious Control: close -1 2.4.4+dfsg1-1 Tags: sid trixie ftbfs User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:389-ds-base has been trying to migrate for 31 days [2]. Hence, I am filing this bug. The version in unstable failed to build on armel, armhf and i386 (our 32 bit architectures). If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=389-ds-base OpenPGP_signature.asc Description: OpenPGP digital signature
Processed: src:389-ds-base: fails to migrate to testing for too long: FTBFS on 32 bits
Processing control commands: > close -1 2.4.4+dfsg1-1 Bug #1063434 [src:389-ds-base] src:389-ds-base: fails to migrate to testing for too long: FTBFS on 32 bits Marked as fixed in versions 389-ds-base/2.4.4+dfsg1-1. Bug #1063434 [src:389-ds-base] src:389-ds-base: fails to migrate to testing for too long: FTBFS on 32 bits Marked Bug as done -- 1063434: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1063434 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: src:gjs: fails to migrate to testing for too long: FTBFS on mips64el
Processing control commands: > close -1 1.78.3-1 Bug #1063433 [src:gjs] src:gjs: fails to migrate to testing for too long: FTBFS on mips64el Marked as fixed in versions gjs/1.78.3-1. Bug #1063433 [src:gjs] src:gjs: fails to migrate to testing for too long: FTBFS on mips64el Marked Bug as done -- 1063433: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1063433 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1063433: src:gjs: fails to migrate to testing for too long: FTBFS on mips64el
Source: gjs Version: 1.78.1-3 Severity: serious Control: close -1 1.78.3-1 Tags: sid trixie ftbfs User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:gjs has been trying to migrate for 31 days [2]. Hence, I am filing this bug. The version in unstable failed to build on mips64el. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=gjs OpenPGP_signature.asc Description: OpenPGP digital signature
Processed: src:linux-apfs-rw: fails to migrate to testing for too long: RC bug and autopkgtest failure
Processing control commands:
> close -1 0.3.7-1
Bug #1063432 [src:linux-apfs-rw] src:linux-apfs-rw: fails to migrate to testing
for too long: RC bug and autopkgtest failure
Marked as fixed in versions linux-apfs-rw/0.3.7-1.
Bug #1063432 [src:linux-apfs-rw] src:linux-apfs-rw: fails to migrate to testing
for too long: RC bug and autopkgtest failure
Marked Bug as done
> block -1 by 1060898
Bug #1063432 {Done: Paul Gevers } [src:linux-apfs-rw]
src:linux-apfs-rw: fails to migrate to testing for too long: RC bug and
autopkgtest failure
1063432 was not blocked by any bugs.
1063432 was not blocking any bugs.
Added blocking bug(s) of 1063432: 1060898
--
1063432: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1063432
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
Bug#1063432: src:linux-apfs-rw: fails to migrate to testing for too long: RC bug and autopkgtest failure
Source: linux-apfs-rw Version: 0.3.5-1 Severity: serious Control: close -1 0.3.7-1 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Control: block -1 by 1060898 Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:linux-apfs-rw has been trying to migrate for 31 days [2]. Hence, I am filing this bug. The version in unstable has an unresolved RC bug and fails its own autopkgtest. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=linux-apfs-rw OpenPGP_signature.asc Description: OpenPGP digital signature
Processed: src:r-cran-future.apply: fails to migrate to testing for too long: autopkgtest failure
Processing control commands: > close -1 1.11.1+dfsg-1 Bug #1063431 [src:r-cran-future.apply] src:r-cran-future.apply: fails to migrate to testing for too long: autopkgtest failure Marked as fixed in versions r-cran-future.apply/1.11.1+dfsg-1. Bug #1063431 [src:r-cran-future.apply] src:r-cran-future.apply: fails to migrate to testing for too long: autopkgtest failure Marked Bug as done -- 1063431: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1063431 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1063431: src:r-cran-future.apply: fails to migrate to testing for too long: autopkgtest failure
Source: r-cran-future.apply Version: 1.11.0+dfsg-1 Severity: serious Control: close -1 1.11.1+dfsg-1 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:r-cran-future.apply has been trying to migrate for 31 days [2]. Hence, I am filing this bug. The version in unstable fails its own autopkgtest on armel, armhf and i386 (our 32 bits architectures). If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=r-cran-future.apply OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1063430: src:seqan-needle: fails to migrate to testing for too long: FTBFS on amd64 and arm64
Source: seqan-needle Version: 1.0.2+ds-1 Severity: serious Control: close -1 1.0.2+ds-2 Tags: sid trixie ftbfs User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:seqan-needle has been trying to migrate for 31 days [2]. Hence, I am filing this bug. The version in unstable failed to build on amd64 and arm64. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=seqan-needle OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1063428: src:iwyu: fails to migrate to testing for too long: waiting for BD clang-17 on mips64el
Source: iwyu Version: 8.18-2 Severity: serious Control: close -1 8.21-1 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:iwyu has been trying to migrate for 32 days [2]. Hence, I am filing this bug. The version in unstable Build-Depends on several packages that are not available on mips64el. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=iwyu OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1063427: src:nng: fails to migrate to testing for too long: FTBFS on i386, ppc64el and s390x
Source: nng Version: 1.6.0-1 Severity: serious Control: close -1 1.7.2-1 Tags: sid trixie ftbfs User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:nng has been trying to migrate for 32 days [2]. Hence, I am filing this bug. The version in unstable failed to build on i386, ppc64el and s390x. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=nng OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1063426: src:node-websocket: fails to migrate to testing for too long: FTBFS on armel
Source: node-websocket Version: 1.0.34+~cs10.0.25-1 Severity: serious Control: close -1 1.0.34+~cs10.0.25-2 Tags: sid trixie ftbfs User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:node-websocket has been trying to migrate for 32 days [2]. Hence, I am filing this bug. The version in unstable failed to build on armel. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=node-websocket OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1063425: src:rust-gdk-pixbuf-sys: fails to migrate to testing for too long: autopkgtest failures
Source: rust-gdk-pixbuf-sys Version: 0.18.0-2 Severity: serious Control: close -1 0.18.0-3 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:rust-gdk-pixbuf-sys has been trying to migrate for 32 days [2]. Hence, I am filing this bug. The version in unstable fails its own autopkgtest as well as triggers other packages to fail theirs. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=rust-gdk-pixbuf-sys OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1063422: linux-image-6.1.0-18-amd64: F2FS rw mount at boot fails with "invalid zstd compress level: 6"
Control: tags -1 + upstream Control: severity -1 important Hi On Wed, Feb 07, 2024 at 10:43:47PM -0500, Dhya wrote: > Package: src:linux > Version: 6.1.76-1 > Severity: critical > Justification: breaks the whole system > > Dear Maintainer, > > After upgrade to linux-image-6.1.0-18-amd64 6.1.76-1 F2FS filesystem > fails to mount rw. Message in the boot journal: > > kernel: F2FS-fs (nvme0n1p6): invalid zstd compress level: 6 > > There was recently an f2fs patch to the 6.1 kernel tree which might be > related: https://www.spinics.net/lists/stable-commits/msg329957.html > > Was able to recover the system by doing: > > sudo mount -o > remount,rw,relatime,lazytime,background_gc=on,discard,no_heap,user_xattr,inline_xattr,acl,inline_data,inline_dentry,extent_cache,mode=adaptive,active_logs=6,alloc_mode=default,checkpoint_merge,fsync_mode=posix,compress_algorithm=lz4,compress_log_size=2,compress_mode=fs,atgc,discard_unit=block,memory=normal > /dev/nvme0n1p6 / > > under the running bad 6.1.0-18-amd64 kernel, then editing > /etc/default/grub: > > GRUB_DEFAULT="Advanced options for Debian GNU/Linux>Debian GNU/Linux, with > Linux 6.1.0-17-amd64" > > and running 'update-grub' and rebooting to boot the 6.1.0-17-amd64 > kernel. Thanks for the report. Can you please report your finding upstream and keep this downstream report in the loop as well please? Regards, Salvatore
Processed: Re: Bug#1063422: linux-image-6.1.0-18-amd64: F2FS rw mount at boot fails with "invalid zstd compress level: 6"
Processing control commands: > tags -1 + upstream Bug #1063422 [src:linux] linux-image-6.1.0-18-amd64: F2FS rw mount at boot fails with "invalid zstd compress level: 6" Added tag(s) upstream. > severity -1 important Bug #1063422 [src:linux] linux-image-6.1.0-18-amd64: F2FS rw mount at boot fails with "invalid zstd compress level: 6" Severity set to 'important' from 'critical' -- 1063422: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1063422 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1044079: [Help] augur: FTBFS with pandas 2.0
Control: tags -1 help Hi Rebecca, Étienne has forwarded the issue long ago but it seems upstream does not want to move to Pandas 2.x[1] and simply closed the issue. Since I do not see any good reason that we maintain two versions of Pandas I need to ask for some help in this issue. Kind regards Andreas. [1] https://github.com/nextstrain/augur/issues/1303 -- http://fam-tille.de
Processed: [Help] augur: FTBFS with pandas 2.0
Processing control commands: > tags -1 help Bug #1044079 [src:augur] augur: FTBFS with pandas 2.0 Ignoring request to alter tags of bug #1044079 to the same tags previously set -- 1044079: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1044079 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1063392: marked as done (zfsutils-linux has an undeclared file conflict on /usr/bin/arcstat)
Your message dated Thu, 08 Feb 2024 06:21:20 + with message-id and subject line Bug#1063392: fixed in zfs-linux 2.2.2-5~exp3 has caused the Debian Bug report #1063392, regarding zfsutils-linux has an undeclared file conflict on /usr/bin/arcstat to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 1063392: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1063392 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: zfsutils-linux Version: 2.2.2-5~exp2 Severity: serious User: debian...@lists.debian.org Usertags: fileconflict Control: affects -1 + nordugrid-arc-client zfsutils-linux has an undeclared file conflict. This may result in an unpack error from dpkg. The file /usr/bin/arcstat is contained in the packages * nordugrid-arc-client * 6.10.2-1 as present in bullseye * 6.17.0-3 as present in bookworm * 6.18.0-1 as present in trixie|unstable * zfsutils-linux/2.2.2-5~exp2 as present in experimental These packages can be unpacked concurrently, because there is no relevant Replaces or Conflicts relation. Attempting to unpack these packages concurrently results in an unpack error from dpkg, because none of the packages installs a diversion for the affected file. Kind regards The Debian Usr Merge Analysis Tool This bug report has been automatically filed with no human intervention. The source code is available at https://salsa.debian.org/helmutg/dumat. If the filing is unclear or in error, don't hesitate to contact hel...@subdivi.de for assistance. --- End Message --- --- Begin Message --- Source: zfs-linux Source-Version: 2.2.2-5~exp3 Done: Shengqi Chen We believe that the bug you reported is fixed in the latest version of zfs-linux, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 1063...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Shengqi Chen (supplier of updated zfs-linux package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Wed, 07 Feb 2024 23:11:07 +0800 Source: zfs-linux Architecture: source Version: 2.2.2-5~exp3 Distribution: experimental Urgency: medium Maintainer: Debian ZFS on Linux maintainers Changed-By: Shengqi Chen Closes: 1063392 Changes: zfs-linux (2.2.2-5~exp3) experimental; urgency=medium . * Remove more obsolete lintian overrides * d/control: zfsutils-linux now conflicts with nordugrid-arc-client (Closes: #1063392) * d/NEWS: add notice on usr-merge and package conflict Checksums-Sha1: 79b81f3264db1e6abd33e81cf41a221576f4131f 3226 zfs-linux_2.2.2-5~exp3.dsc bc3b29b3181784b98b7cd7a99d14ae8496d867ee 109080 zfs-linux_2.2.2-5~exp3.debian.tar.xz 2c474af4dfef4d848930a4f92ad5dd2b29a5bf1c 8313 zfs-linux_2.2.2-5~exp3_source.buildinfo Checksums-Sha256: 0197c38ad45178d03bb78a43d8341c098ec3486bf101e9311f66b0fd73f8944b 3226 zfs-linux_2.2.2-5~exp3.dsc 51e99f4974387376192c09ad882cd051efc42dbe4ca691299242d6b00d90 109080 zfs-linux_2.2.2-5~exp3.debian.tar.xz 2fd3da0e77d1291a319c2452b37d4f42f92e02769d0eac80e68ef4ef3796ad73 8313 zfs-linux_2.2.2-5~exp3_source.buildinfo Files: b529c10330f0b08010e22cac9fbafb74 3226 contrib/kernel optional zfs-linux_2.2.2-5~exp3.dsc 844e348b9e501bebdedbaa211c9761d4 109080 contrib/kernel optional zfs-linux_2.2.2-5~exp3.debian.tar.xz 3ac1270c105a6121b3bbfec372c68992 8313 contrib/kernel optional zfs-linux_2.2.2-5~exp3_source.buildinfo -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEBLHAyuu1xqoC2aJ5NP8o68vMTMgFAmXEbpIACgkQNP8o68vM TMjuWwgAky6/7B3TPQzLb9yTAFZ3H1D5lfFj/wNHU1OerlkWxJ/Z8SH5PdP8pXoE qI0E+TJYAPHVIxuzlXIKSrWYCEQmbd1cakiHoSV898HGWJIA7sDdV44HJs2+icfq W9yBcUW8x1nYYjYNkTxImWL98xVuZRTimOqFRJt2exHlQZBbO3sEnDmjI9lxpFWB 84tfhL5f8puDBT1OJ3EnC39697B1HqAbtLgCQZScBuC6xCgAbDRrpXC2+RGFwIxQ fSrSOTPjn3TxfwtkTtU0OkPNQ1nxYDGNXtuSAp0WxecZtPW31XuSOGTm7WxaEqhm 9KGVXXcgYcXOfvB9xE2TMe11vKR57g== =FhRf -END PGP SIGNATURE End Message ---
Bug#1063329: libselinux1t64: breaks system in upgrade from unstable
06.02.2024 12:34, Helmut Grohne: ... An option I see here is to provide ABI-duality for libselinux: -extern int matchpathcon_filespec_add(ino_t ino, int specind, const char *file); +typedef unsigned long libselinux_ino_t; +typedef uint64_t libselinux_ino64_t; +extern int matchpathcon_filespec_add(libselinux_ino_t ino, int specind, const char *file); +#if defined _FILE_OFFSET_BITS && _FILE_OFFSET_BITS == 64 && sizeof(unsigned long) < 8 It's good for a sketch to show an idea but it wont work in practice, - you can't use sizeof(foo) in a preprocessor condition. That's what WORDSIZE #defines are for. But it's a minor nit. glibc already has all the support for LFS which can be used directly, by copying code from any glibc header, like eg for lseek definition... +extern int matchpathcon_filespec_add64(libselinux_ino64_t ino, int specind, const char *file); +#define matchpathcon_filespec_add matchpathcon_filespec_add64 and keeping this #define here instead of using internal in-glibc symbol redirection stuff. And ofc we need to define the compat wrapper for matchpathcon_filespec_add to the source, and the new 64bit symbol to libselinux.map, with the same arch-specific condition. /mjt
Bug#1063329: libselinux1t64: breaks system in upgrade from unstable
07.02.2024 11:06, Helmut Grohne :
..
pam seems difficult:
| extern time_t pam_misc_conv_warn_time; /* time that we should warn user */
| extern time_t pam_misc_conv_die_time; /* cut-off time for input */
Attached is a sketch to make pam compatible.
I had a more complete and *tested* fix 2 days ago but I forgot
it was in /tmp and I rebooted the machine, so had to do it again
yesterday.
The idea is to have both die_time and die_time64, and keep them
in sync (using minimum between two values which is !=0).
This is a sketch using a #define, though better is to use symbol
versioning here and have time32 compat stuff for old programs
and 64bit time stuff for new, using redirection at the link time,
instead of the #defines which makes whole thing rather difficult
to read, - that's extra several lines of code, also to the .map
file.
What the whole thing needs is the criteria to use to enable the
trick. Right now I used #ifdef NEED_TIME64_COMPAT which should
be defined somehow, - since I don't know the precise list of
architectures where this has to be done. This is an externally-
controlled thing, there's no way to determine this directly from
the .c code (short of using architecture list in the .h file),
so it must be some symbol substituted at the package build time,
like Provides: t64:Compat (or whatever it is) is substituted in
d/control.
This is a less-intrusve-to-original-code version of the sketch,
ie, I tried to keep all changes outside of the original code as
possible, keeping all the original logic as it is.
/mjtdiff --git a/libpam_misc/include/security/pam_misc.h b/libpam_misc/include/security/pam_misc.h
index fca2422..922341c 100644
--- a/libpam_misc/include/security/pam_misc.h
+++ b/libpam_misc/include/security/pam_misc.h
@@ -21,6 +21,15 @@ extern int misc_conv(int num_msg, const struct pam_message **msgm,
#include
+#if NEED_TIME64_COMPAT
+
+extern time32_t pam_misc_conv_warn_time;
+extern time32_t pam_misc_conv_die_time;
+#define pam_misc_conv_warn_time pam_misc_conv_warn_time64
+#define pam_misc_conv_die_time pam_misc_conv_die_time64
+
+#endif
+
extern time_t pam_misc_conv_warn_time; /* time that we should warn user */
extern time_t pam_misc_conv_die_time; /* cut-off time for input */
extern const char *pam_misc_conv_warn_line; /* warning notice */
diff --git a/libpam_misc/misc_conv.c b/libpam_misc/misc_conv.c
index 908ee89..a02d491 100644
--- a/libpam_misc/misc_conv.c
+++ b/libpam_misc/misc_conv.c
@@ -30,6 +30,9 @@
time_t pam_misc_conv_warn_time = 0; /* time when we warn */
time_t pam_misc_conv_die_time = 0; /* time when we timeout */
+static void fixup_compat_time();
+static void reset_warn_time();
+
const char *pam_misc_conv_warn_line = N_("...Time is running out...\n");
const char *pam_misc_conv_die_line = N_("...Sorry, your time is up!\n");
@@ -96,6 +99,8 @@ static int get_delay(void)
expired = 0;/* reset flag */
(void) time(&now);
+fixup_compat_time();
+
/* has the quit time past? */
if (pam_misc_conv_die_time && now >= pam_misc_conv_die_time) {
fprintf(stderr,"%s",pam_misc_conv_die_line);
@@ -107,7 +112,7 @@ static int get_delay(void)
/* has the warning time past? */
if (pam_misc_conv_warn_time && now >= pam_misc_conv_warn_time) {
fprintf(stderr, "%s", pam_misc_conv_warn_line);
- pam_misc_conv_warn_time = 0;/* reset warn_time */
+ reset_warn_time();
/* indicate remaining delay - if any */
@@ -399,3 +404,36 @@ failed_conversation:
return PAM_CONV_ERR;
}
+
+#ifdef NEED_TIME64_COMPAT
+
+#undef pam_misc_conv_warn_time
+#undef pam_misc_conv_die_time
+
+int pam_misc_conv_warn_time, pam_misc_conv_die_time;
+
+/* in compat 32/64 case, we have 2 values: time and time64.
+ We perform all operations with time64
+ But we try to keep them in sync, whiciever is smaller but !0 */
+#define fixup(t, t32) \
+if (t32 && (!t || t > t32)) t = t32; /* if t32 fires sooner */ \
+if (t < 0x7fff) t32 = t /* only if t can fit in t32 */
+
+static void fixup_compat_time() {
+fixup(pam_misc_conv_warn_time64, pam_misc_conv_warn_time);
+fixup(pam_misc_conv_die_time64, pam_misc_conv_die_time);
+}
+static void reset_warn_time() {
+ pam_misc_conv_warn_time = 0;
+ pam_misc_conv_warn_time64 = 0;
+}
+
+#else
+
+static void fixup_compat_time() {
+}
+static void reset_warn_time() {
+ pam_misc_conv_warn_time = 0;
+}
+
+#endif
Bug#1063422: mount options
Under the 6.1.0-17-amd64 kernel the mount command reports: /dev/nvme0n1p6 on / type f2fs (rw,relatime,lazytime,background_gc=on,gc_merge,discard,no_heap,user_xattr,inline_xattr,acl,inline_data,inline_dentry,flush_merge,extent_cache,mode=adaptive,active_logs=6,alloc_mode=default,checkpoint_merge,fsync_mode=posix,compress_algorithm=zstd:6,compress_log_size=2,compress_chksum,compress_mode=fs,atgc,discard_unit=block,memory=normal)
Bug#1063422: fstab
fstab entry: UUID=xxx/f2fs compress_algorithm=zstd:6,compress_chksum,atgc,gc_merge,lazytime 0 1 Allowable levels for zstd compression are 1-22: https://docs.kernel.org/filesystems/f2fs.html
Bug#1063422: linux-image-6.1.0-18-amd64: F2FS rw mount at boot fails with "invalid zstd compress level: 6"
Package: src:linux Version: 6.1.76-1 Severity: critical Justification: breaks the whole system Dear Maintainer, After upgrade to linux-image-6.1.0-18-amd64 6.1.76-1 F2FS filesystem fails to mount rw. Message in the boot journal: kernel: F2FS-fs (nvme0n1p6): invalid zstd compress level: 6 There was recently an f2fs patch to the 6.1 kernel tree which might be related: https://www.spinics.net/lists/stable-commits/msg329957.html Was able to recover the system by doing: sudo mount -o remount,rw,relatime,lazytime,background_gc=on,discard,no_heap,user_xattr,inline_xattr,acl,inline_data,inline_dentry,extent_cache,mode=adaptive,active_logs=6,alloc_mode=default,checkpoint_merge,fsync_mode=posix,compress_algorithm=lz4,compress_log_size=2,compress_mode=fs,atgc,discard_unit=block,memory=normal /dev/nvme0n1p6 / under the running bad 6.1.0-18-amd64 kernel, then editing /etc/default/grub: GRUB_DEFAULT="Advanced options for Debian GNU/Linux>Debian GNU/Linux, with Linux 6.1.0-17-amd64" and running 'update-grub' and rebooting to boot the 6.1.0-17-amd64 kernel. -- Package-specific info: ** Kernel log: boot messages should be attached ** Model information sys_vendor: Dell Inc. product_name: Wyse 7040 product_version: chassis_vendor: Dell Inc. chassis_version: bios_vendor: Dell Inc. bios_version: 1.20.0 board_vendor: Dell Inc. board_name: 0080PM board_version: A00 ** PCI devices: 00:00.0 Host bridge [0600]: Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Host Bridge/DRAM Registers [8086:191f] (rev 07) Subsystem: Dell Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Host Bridge/DRAM Registers [1028:0727] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: skl_uncore Kernel modules: ie31200_edac 00:01.0 PCI bridge [0604]: Intel Corporation 6th-10th Gen Core Processor PCIe Controller (x16) [8086:1901] (rev 07) (prog-if 00 [Normal decode]) Subsystem: Dell 6th-10th Gen Core Processor PCIe Controller (x16) [1028:0727] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport 00:02.0 VGA compatible controller [0300]: Intel Corporation HD Graphics 530 [8086:1912] (rev 06) (prog-if 00 [VGA controller]) Subsystem: Dell HD Graphics 530 [1028:0727] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: i915 Kernel modules: i915 00:14.0 USB controller [0c03]: Intel Corporation 100 Series/C230 Series Chipset Family USB 3.0 xHCI Controller [8086:a12f] (rev 31) (prog-if 30 [XHCI]) Subsystem: Dell 100 Series/C230 Series Chipset Family USB 3.0 xHCI Controller [1028:0727] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- Kernel driver in use: xhci_hcd Kernel modules: xhci_pci 00:14.2 Signal processing controller [1180]: Intel Corporation 100 Series/C230 Series Chipset Family Thermal Subsystem [8086:a131] (rev 31) Subsystem: Dell 100 Series/C230 Series Chipset Family Thermal Subsystem [1028:0727] Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: intel_pch_thermal Kernel modules: intel_pch_thermal 00:16.0 Communication controller [0780]: Intel Corporation 100 Series/C230 Series Chipset Family MEI Controller #1 [8086:a13a] (rev 31) Subsystem: Dell 100 Series/C230 Series Chipset Family MEI Controller [1028:0727] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: mei_me Kernel modules: mei_me 00:16.3 Serial controller [0700]: Intel Corporation 100 Series/C230 Series Chipset Family KT Redirection [8086:a13d] (rev 31) (prog-if 02 [16550]) Subsystem: Dell 100 Series/C230 Series Chipset Family KT Redirection [1028:0727] Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: serial 00:17.0 SATA controller [0106]: Intel Corporation Q170/Q150/B150/H170/H110/Z
Bug#1063398: marked as done (FTBFS: src/capng_swig.i:33: Error: Unknown directive '%except')
Your message dated Wed, 07 Feb 2024 23:04:02 + with message-id and subject line Bug#1063398: fixed in libcap-ng 0.8.4-2 has caused the Debian Bug report #1063398, regarding FTBFS: src/capng_swig.i:33: Error: Unknown directive '%except' to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 1063398: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1063398 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Source: libcap-ng Version: 0.8.4-1 Severity: serious Tags: sid trixie ftbfs Hi, libcap-ng currently FTBFS with the following error: make[6]: Entering directory '/<>/build-py3.11/bindings/python3' cat /usr/include/linux/capability.h | grep '^#define CAP' | grep -v '[()]' > caps.h cat ../../../src/cap-ng.h | grep -v '_state' > capng.h swig -o capng_wrap.c -python -I. -I../.. -I/usr/include/python3.11 -I/usr/include/python3.11 ../../../bindings/python3/../src/capng_swig.i ../../../bindings/python3/../src/capng_swig.i:33: Error: Unknown directive '%except'. make[6]: *** [Makefile:878: capng_wrap.c] Error 1 make[6]: Leaving directory '/<>/build-py3.11/bindings/python3' make[5]: *** [Makefile:595: all-recursive] Error 1 make[5]: Leaving directory '/<>/build-py3.11/bindings/python3' make[4]: *** [Makefile:390: all-recursive] Error 1 make[4]: Leaving directory '/<>/build-py3.11/bindings' make[3]: *** [Makefile:441: all-recursive] Error 1 make[3]: Leaving directory '/<>/build-py3.11' make[2]: *** [Makefile:373: all] Error 2 make[2]: Leaving directory '/<>/build-py3.11' --- End Message --- --- Begin Message --- Source: libcap-ng Source-Version: 0.8.4-2 Done: Håvard F. Aasen We believe that the bug you reported is fixed in the latest version of libcap-ng, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 1063...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Håvard F. Aasen (supplier of updated libcap-ng package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Wed, 07 Feb 2024 23:44:50 +0100 Source: libcap-ng Architecture: source Version: 0.8.4-2 Distribution: unstable Urgency: medium Maintainer: Håvard F. Aasen Changed-By: Håvard F. Aasen Closes: 1063398 Changes: libcap-ng (0.8.4-2) unstable; urgency=medium . * Add patch from upstream to fix ftbfs. Closes: #1063398 * Update copyright year for myself. Checksums-Sha1: 421c3e1d64c5a897fa91a94960f85503ba4c19de 1638 libcap-ng_0.8.4-2.dsc 28e9402d59a5f001bd0d6657ba313760060258a9 7264 libcap-ng_0.8.4-2.debian.tar.xz 98ea966e9bbb8ddcb973686579a0e9f94c328249 8878 libcap-ng_0.8.4-2_amd64.buildinfo Checksums-Sha256: 57f7b2e3b4ffb9180668e24b3201cd04e236594cdfaa0d896fd871acba43254a 1638 libcap-ng_0.8.4-2.dsc 3fa4bd0c1a65faf4e52d607f266ec24f4594a2503cc1f3fee1ec6f1db21d9351 7264 libcap-ng_0.8.4-2.debian.tar.xz ce8efb312727850238801f6a88b294682ff9b496df19c8e3c0824d1ea6bb9e54 8878 libcap-ng_0.8.4-2_amd64.buildinfo Files: 5b117b4af7b63bfb561e14fe2a01a3be 1638 libs optional libcap-ng_0.8.4-2.dsc a78b5ec02e7dcd133350630214c3f12e 7264 libs optional libcap-ng_0.8.4-2.debian.tar.xz 8f9141e1b3b278543b9b9e352cc4854e 8878 libs optional libcap-ng_0.8.4-2_amd64.buildinfo -BEGIN PGP SIGNATURE- iI0EARYIADUWIQSD/42dLkLq3fzhpN2I4w6v/UfCtwUCZcQI5xccaGF2YXJkLmYu YWFzZW5AcGZmdC5ubwAKCRCI4w6v/UfCt8znAP45R1oqYDWa+YQxOo2XIRyHi0YN ITErmcaiUEd7rMSghAD+IKTfM2AEJTN+qqxsaHkWo3I0tJg4rVDaJ6cdihVzGAw= =sWj/ -END PGP SIGNATURE End Message ---
Bug#1063398: marked as pending in libcap-ng
Control: tag -1 pending Hello, Bug #1063398 in libcap-ng reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/debian/libcap-ng/-/commit/9d720fd2b17b59b5c63aad2e57e00a2435a7ce1c Add patch from upstream to fix ftbfs. Closes: #1063398 (this message was generated automatically) -- Greetings https://bugs.debian.org/1063398
Processed: Bug#1063398 marked as pending in libcap-ng
Processing control commands: > tag -1 pending Bug #1063398 [src:libcap-ng] FTBFS: src/capng_swig.i:33: Error: Unknown directive '%except' Added tag(s) pending. -- 1063398: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1063398 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1063210: pari: NMU diff for 64-bit time_t transition
On Mon, Feb 05, 2024 at 02:43:30PM -0300, Lucas Kanashiro wrote: > Source: pari > Version: 2.15.4-2 > Severity: serious > Tags: patch pending sid trixie > Justification: library ABI skew on upgrade > User: debian-...@lists.debian.org > Usertags: time-t > > NOTICE: these changes must not be uploaded to unstable yet! > > Dear maintainer, > > As part of the 64-bit time_t transition required to support 32-bit > architectures in 2038 and beyond > (https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified > pari as a source package shipping runtime libraries whose ABI > either is affected by the change in size of time_t, or could not be > analyzed via abi-compliance-checker (and therefore to be on the safe > side we assume is affected). > > To ensure that inconsistent combinations of libraries with their > reverse-dependencies are never installed together, it is necessary to > have a library transition, which is most easily done by renaming the > runtime library package. > > Since turning on 64-bit time_t is being handled centrally through a change > to the default dpkg-buildflags (https://bugs.debian.org/1037136), it is > important that libraries affected by this ABI change all be uploaded close > together in time. Therefore I have prepared a 0-day NMU for pari > which will initially be uploaded to experimental if possible, then to > unstable after packages have cleared binary NEW. Have you actually checked that pari will really be build with the relevant flags ? If there is a new ABI, then one should take the opportunity to remove CFLAGS_i386 := -mpc64 There is no need for a lintian override, this is a well-known lintian bug... Cheers, Bill
Bug#1063206: papi: NMU diff for 64-bit time_t transition
On 05/02/2024 20.32, Andreas Beckmann wrote: Please don't upload to unstable, yet, until I've checked it in more detail (and maybe fixed it in experimental). Yes, there is a wrong dependency: │ │ │ │ Package: libpapi-dev │ │ │ │ Source: papi │ │ │ │ Version: 7.1.0-2.1~exp1 │ │ │ │ Architecture: amd64 │ │ │ │ Maintainer: Debian HPC Team │ │ │ │ Installed-Size: 1293 │ │ │ │ -Depends: libpapi7.1 (= 7.1.0-2.1~exp1), libsde1t64 (= 7.1.0-2.1~exp1) │ │ │ │ +Depends: libpapi7.1t64 (= 7.1.0-2.1~exp1), libsde1t64 (= 7.1.0-2.1~exp1) │ │ │ │ Section: libdevel │ │ │ │ Priority: optional │ │ │ │ Multi-Arch: same │ │ │ │ Homepage: https://icl.utk.edu/papi/ │ │ │ │ Description: PAPI development files (headers and API documentation) Preparing a fix ... Andreas
Bug#1063419: sugar-artwork: Please package version 0.121 needed by sugar-session
Source: sugar-artwork Version: 0.120-2 Severity: serious Control: affects -1 src:sugar X-Debbugs-CC: d...@jones.dk sugar-session in Unstable depends on sugar-themes (>= 0.121) but that version is not available in Unstable yet. Thank you, Jeremy Bícha
Processed: sugar-artwork: Please package version 0.121 needed by sugar-session
Processing control commands: > affects -1 src:sugar Bug #1063419 [src:sugar-artwork] sugar-artwork: Please package version 0.121 needed by sugar-session Added indication that 1063419 affects src:sugar -- 1063419: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1063419 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1063418: mdp ftbfs in unstable
Package: src:mdp
Version: 3.6-6
Severity: serious
Tags: sid trixie ftbfs
User: debian-pyt...@lists.debian.org
Usertags: python3.12
tests fail with both Python 3.11 and 3.12.
Also with 3.12:
mdp/test/test_reload.py:4
/<>/mdp/test/test_reload.py:4: DeprecationWarning: the
imp module is deprecated in favour of importlib and slated for removal
in Python 3.12; see the module's documentation for alternative uses
from imp import reload
[...]
=== short test summary info
FAILED mdp/test/test_hinet_generic.py::test_dtype_consistency[FlowNode]
- Typ...
FAILED mdp/test/test_nodes_generic.py::test_dtype_consistency[SFA2Node]
- Typ...
FAILED mdp/test/test_nodes_generic.py::test_dtype_consistency[FDANode] -
Type...
FAILED
mdp/test/test_nodes_generic.py::test_dtype_consistency[GaussianClassifier]
FAILED
mdp/test/test_nodes_generic.py::test_dtype_consistency[LinearRegressionNode]
FAILED mdp/test/test_nodes_generic.py::test_dtype_consistency[JADENode]
- Typ...
FAILED mdp/test/test_nodes_generic.py::test_dtype_consistency[XSFANode]
- Typ...
FAILED mdp/test/test_nodes_generic.py::test_dtype_consistency[iGSFANode]
- Ty...
FAILED mdp/test/test_nodes_generic.py::test_dtype_consistency[LLENode] -
Type...
FAILED mdp/test/test_nodes_generic.py::test_dtype_consistency[HLLENode]
- Typ...
FAILED
mdp/test/test_nodes_generic.py::test_dtype_consistency[CuBICANode] - T...
FAILED mdp/test/test_nodes_generic.py::test_dtype_consistency[FANode] -
TypeE...
FAILED
mdp/test/test_nodes_generic.py::test_dtype_consistency[FastICANode] - ...
FAILED mdp/test/test_nodes_generic.py::test_dtype_consistency[GSFANode]
- Typ...
FAILED mdp/test/test_nodes_generic.py::test_dtype_consistency[ISFANode]
- Typ...
FAILED mdp/test/test_nodes_generic.py::test_dtype_consistency[PCANode] -
Type...
FAILED mdp/test/test_nodes_generic.py::test_dtype_consistency[SFANode] -
Type...
FAILED mdp/test/test_nodes_generic.py::test_dtype_consistency[TDSEPNode]
- Ty...
FAILED
mdp/test/test_nodes_generic.py::test_dtype_consistency[VartimeSFANode]
FAILED mdp/test/test_nodes_generic.py::test_dtype_consistency[WhiteningNode]
== 20 failed, 823 passed, 16 skipped, 3 warnings in 158.17s
(0:02:38) ==
E: pybuild pybuild:391: test: plugin custom failed with: exit code=1:
python3.11 -m pytest --seed=725021957 mdp && python3.11 -m pytest
--seed=725021957 bimdp
dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p
"3.12 3.11" returned exit code 13
Bug#1063413: FTBFS: cannot open /<>/Keyboard/pc105.ekbd: No such file
Am 7. Februar 2024 21:55:05 MEZ schrieb Emanuele Rocca : > Dumping the encoded keymaps for pc105... > WARNING: Can not find "caps_switch" in "group". > WARNING: Can not find "caps_toggle" in "group". > gzip -9n >/Keyboard/pc105.ekbd > >/<>/Keyboard/pc105.ekbd.gz > /bin/sh: 1: cannot open /<>/Keyboard/pc105.ekbd: No such file > make[1]: *** [rules.mk:17: /<>/Keyboard/pc105.ekbd.gz] Error 2 > make[1]: Leaving directory '/<>' > make: *** [debian/rules:204: udeb-install] Error 2 > >Version 1.223 builds fine in unstable instead. Perhaps this is related >to the fact that 1.224 dropped the binary package console-setup-pc-ekbd? What makes you think, that this has happened? There is a merge request that includes the removal of said package, but it has not yet been merged. Holger -- Sent from /e/ OS on Fairphone3
Processed: libgit2: CVE-2024-24577: Arbitrary code execution due to heap corruption in `git_index_add`
Processing control commands: > found -1 1.5.1+ds-1 Bug #1063416 [src:libgit2] libgit2: CVE-2024-24577: Arbitrary code execution due to heap corruption in `git_index_add` Marked as found in versions libgit2/1.5.1+ds-1. > found -1 1.1.0+dfsg.1-4+deb11u1 Bug #1063416 [src:libgit2] libgit2: CVE-2024-24577: Arbitrary code execution due to heap corruption in `git_index_add` Marked as found in versions libgit2/1.1.0+dfsg.1-4+deb11u1. > found -1 1.1.0+dfsg.1-4 Bug #1063416 [src:libgit2] libgit2: CVE-2024-24577: Arbitrary code execution due to heap corruption in `git_index_add` Marked as found in versions libgit2/1.1.0+dfsg.1-4. -- 1063416: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1063416 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1063416: libgit2: CVE-2024-24577: Arbitrary code execution due to heap corruption in `git_index_add`
Source: libgit2 Version: 1.7.1+ds-2 Severity: grave Tags: security upstream X-Debbugs-Cc: car...@debian.org, Debian Security Team Control: found -1 1.5.1+ds-1 Control: found -1 1.1.0+dfsg.1-4+deb11u1 Control: found -1 1.1.0+dfsg.1-4 Hi, The following vulnerability was published for libgit2. CVE-2024-24577[0]: | libgit2 is a portable C implementation of the Git core methods | provided as a linkable library with a solid API, allowing to build | Git functionality into your application. Using well-crafted inputs | to `git_index_add` can cause heap corruption that could be leveraged | for arbitrary code execution. There is an issue in the | `has_dir_name` function in `src/libgit2/index.c`, which frees an | entry that should not be freed. The freed entry is later used and | overwritten with potentially bad actor-controlled data leading to | controlled heap corruption. Depending on the application that uses | libgit2, this could lead to arbitrary code execution. This issue has | been patched in version 1.6.5 and 1.7.2. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2024-24577 https://www.cve.org/CVERecord?id=CVE-2024-24577 [1] https://github.com/libgit2/libgit2/security/advisories/GHSA-j2v7-4f6v-gpg8 [2] https://github.com/libgit2/libgit2/commit/eb4c1716cd92bf56f2770653a915d5fc01eab8f3 [3] https://github.com/libgit2/libgit2/commit/487af0cf6687dc48b0a960fa2f39894e2d84d77b Regards, Salvatore
Bug#1063413: FTBFS: cannot open /<>/Keyboard/pc105.ekbd: No such file
Source: console-setup Version: 1.224 Severity: serious Justification: fails to build from source (but built successfully in the past) Tags: sid trixie ftbfs Dear Maintainer, console-setup 1.224 fails to build from source with the following error: Dumping the encoded keymaps for pc105... WARNING: Can not find "caps_switch" in "group". WARNING: Can not find "caps_toggle" in "group". gzip -9n >/Keyboard/pc105.ekbd >/<>/Keyboard/pc105.ekbd.gz /bin/sh: 1: cannot open /<>/Keyboard/pc105.ekbd: No such file make[1]: *** [rules.mk:17: /<>/Keyboard/pc105.ekbd.gz] Error 2 make[1]: Leaving directory '/<>' make: *** [debian/rules:204: udeb-install] Error 2 Version 1.223 builds fine in unstable instead. Perhaps this is related to the fact that 1.224 dropped the binary package console-setup-pc-ekbd?
Bug#1058324: marked as done (pydantic: FTBFS: failed tests)
Your message dated Wed, 07 Feb 2024 20:49:06 + with message-id and subject line Bug#1058324: fixed in pydantic 1.10.14-1 has caused the Debian Bug report #1058324, regarding pydantic: FTBFS: failed tests to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 1058324: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1058324 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Source: pydantic Version: 1.10.4-1 Severity: serious Justification: FTBFS Tags: trixie sid ftbfs User: lu...@debian.org Usertags: ftbfs-20231212 ftbfs-trixie Hi, During a rebuild of all packages in sid, your package failed to build on amd64. Relevant part (hopefully): > debian/rules binary > dh binary --with=python3 --buildsystem=pybuild >dh_update_autotools_config -O--buildsystem=pybuild >dh_autoreconf -O--buildsystem=pybuild >dh_auto_configure -O--buildsystem=pybuild > I: pybuild base:310: python3.12 setup.py config > running config > I: pybuild base:310: python3.11 setup.py config > running config >dh_auto_build -O--buildsystem=pybuild > I: pybuild base:310: /usr/bin/python3.12 setup.py build > running build > running build_py > creating /<>/.pybuild/cpython3_3.12/build/pydantic > copying pydantic/utils.py -> > /<>/.pybuild/cpython3_3.12/build/pydantic > copying pydantic/generics.py -> > /<>/.pybuild/cpython3_3.12/build/pydantic > copying pydantic/__init__.py -> > /<>/.pybuild/cpython3_3.12/build/pydantic > copying pydantic/tools.py -> > /<>/.pybuild/cpython3_3.12/build/pydantic > copying pydantic/version.py -> > /<>/.pybuild/cpython3_3.12/build/pydantic > copying pydantic/annotated_types.py -> > /<>/.pybuild/cpython3_3.12/build/pydantic > copying pydantic/main.py -> > /<>/.pybuild/cpython3_3.12/build/pydantic > copying pydantic/fields.py -> > /<>/.pybuild/cpython3_3.12/build/pydantic > copying pydantic/parse.py -> > /<>/.pybuild/cpython3_3.12/build/pydantic > copying pydantic/color.py -> > /<>/.pybuild/cpython3_3.12/build/pydantic > copying pydantic/decorator.py -> > /<>/.pybuild/cpython3_3.12/build/pydantic > copying pydantic/validators.py -> > /<>/.pybuild/cpython3_3.12/build/pydantic > copying pydantic/class_validators.py -> > /<>/.pybuild/cpython3_3.12/build/pydantic > copying pydantic/mypy.py -> > /<>/.pybuild/cpython3_3.12/build/pydantic > copying pydantic/error_wrappers.py -> > /<>/.pybuild/cpython3_3.12/build/pydantic > copying pydantic/errors.py -> > /<>/.pybuild/cpython3_3.12/build/pydantic > copying pydantic/types.py -> > /<>/.pybuild/cpython3_3.12/build/pydantic > copying pydantic/json.py -> > /<>/.pybuild/cpython3_3.12/build/pydantic > copying pydantic/dataclasses.py -> > /<>/.pybuild/cpython3_3.12/build/pydantic > copying pydantic/schema.py -> > /<>/.pybuild/cpython3_3.12/build/pydantic > copying pydantic/config.py -> > /<>/.pybuild/cpython3_3.12/build/pydantic > copying pydantic/datetime_parse.py -> > /<>/.pybuild/cpython3_3.12/build/pydantic > copying pydantic/env_settings.py -> > /<>/.pybuild/cpython3_3.12/build/pydantic > copying pydantic/typing.py -> > /<>/.pybuild/cpython3_3.12/build/pydantic > copying pydantic/networks.py -> > /<>/.pybuild/cpython3_3.12/build/pydantic > copying pydantic/_hypothesis_plugin.py -> > /<>/.pybuild/cpython3_3.12/build/pydantic > copying pydantic/py.typed -> > /<>/.pybuild/cpython3_3.12/build/pydantic > I: pybuild base:310: /usr/bin/python3 setup.py build > running build > running build_py > creating /<>/.pybuild/cpython3_3.11/build/pydantic > copying pydantic/utils.py -> > /<>/.pybuild/cpython3_3.11/build/pydantic > copying pydantic/generics.py -> > /<>/.pybuild/cpython3_3.11/build/pydantic > copying pydantic/__init__.py -> > /<>/.pybuild/cpython3_3.11/build/pydantic > copying pydantic/tools.py -> > /<>/.pybuild/cpython3_3.11/build/pydantic > copying pydantic/version.py -> > /<>/.pybuild/cpython3_3.11/build/pydantic > copying pydantic/annotated_types.py -> > /<>/.pybuild/cpython3_3.11/build/pydantic > copying pydantic/main.py -> > /<>/.pybuild/cpython3_3.11/build/pydantic > copying pydantic/fields.py -> > /<>/.pybuild/cpython3_3.11/build/pydantic > copying pydantic/parse.py -> > /<>/.pybuild/cpython3_3.11/build/pydantic > copying pydantic/color.py -> > /<>/.pybuild/cpython3_3.11/build/pydantic > copying pydantic/decorator.py -> > /<>/.pybuild/cpython3_3.11/build/pydantic > copying pydantic/validators.py -> > /<>/.pybuild/cpython3_3.11/build/pydantic > copying pydantic/class_validators.py -> > /<>/.pybuild/cpython3_3.11/build/pydantic > copying pydantic/mypy.py -> > /<>/.pybuild/cpython3_3.11/build/pydant
Bug#1061735: marked as done (bdepstrap ftbfs with Python 3.12 as the default)
Your message dated Thu, 8 Feb 2024 09:42:20 +1300
with message-id
and subject line Re: bdepstrap ftbfs with Python 3.12 as the default
has caused the Debian Bug report #1061735,
regarding bdepstrap ftbfs with Python 3.12 as the default
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
1061735: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1061735
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: src:bdebstrap
Version: 0.6.0-1
Severity: serious
Tags: sid trixie ftbfs
User: debian-pyt...@lists.debian.org
Usertags: python3.12
With python3-defaults from experimental, the package fails to build:
[...]
Test: Run pylint on Python source code. ... Running following command:
/usr/bin/python3.12 -m pylint
--rcfile=/<>/tests/pylint.conf --
/<>/bdebstrap tests /<>/setup.py
FAIL
test_flake8 (tests.test_shellcheck.ShellcheckTestCase.test_flake8)
Test: Run shellcheck on Shell source code. ... Running following command:
shellcheck /<>/hooks/disable-units
/<>/hooks/enable-units
ok
==
FAIL: test_pylint (tests.test_pylint.PylintTestCase.test_pylint)
Test: Run pylint on Python source code.
--
Traceback (most recent call last):
File "/<>/tests/test_pylint.py", line 74, in test_pylint
self.fail("\n".join(msgs))
AssertionError: pylint found issues:
* Module setup
/<>/setup.py:26:0: E0401: Unable to import 'distutils.log'
(import-error)
/<>/setup.py:27:0: E0401: Unable to import
'distutils.command.build' (import-error)
/<>/setup.py:28:0: E0401: Unable to import
'distutils.command.clean' (import-error)
/<>/setup.py:57:4: C0116: Missing function or method
docstring (missing-function-docstring)
/<>/setup.py:54:0: R0903: Too few public methods (1/2)
(too-few-public-methods)
/<>/setup.py:65:4: C0116: Missing function or method
docstring (missing-function-docstring)
/<>/setup.py:62:0: R0903: Too few public methods (1/2)
(too-few-public-methods)
--
Ran 61 tests in 5.767s
FAILED (failures=1)
E: pybuild pybuild:391: test: plugin distutils failed with: exit code=1:
cd /<>/.pybuild/cpython3_3.12/build; python3.12 -m unittest
discover -v -s /<>
dh_auto_test: error: pybuild --test -i python{version} -p 3.12 returned
exit code 13
--- End Message ---
--- Begin Message ---
The issue was fixed in bdebstrap 0.6.0-1.1--- End Message ---
Processed: Re: Bug#1063407: pybdsf fails to build with Python 3.12 as default
Processing control commands: > forwarded -1 https://github.com/lofar-astron/PyBDSF/issues/214 Bug #1063407 [src:pybdsf] pybdsf fails to build with Python 3.12 as default Ignoring request to change the forwarded-to-address of bug#1063407 to the same value -- 1063407: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1063407 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1063407: pybdsf fails to build with Python 3.12 as default
Control: forwarded -1 https://github.com/lofar-astron/PyBDSF/issues/214 While many (or even all) distutils were replaced by a migration to cmake (https://github.com/lofar-astron/PyBDSF/pull/204), the package is still not Python 3.12 compatible, and the solutions seems not trivial. Waiting for upstream here.
Bug#1062259: libcomps: NMU diff for 64-bit time_t transition
On Wed, Feb 07, 2024 at 04:25:17PM +, Luca Boccassi wrote: > Control: tags -1 -pending > Control: close -1 [...] > There are no mentions of 'time_t' in the public headers of this > library. The logs shows that it's a false positive, as the automated > tool simply wasn't able to build it: [...] > Closing as not applicable. thanks for closing this bug and thanks for the t64 transition in the first place! that said, someone needs to request the removal of src:libcomps from experimental now, and if this would only affect src:libcomps I would probably do that myself, but knowing there are several many cases of this: please also request removal of those packages from experimental which were accidently uploaded there! thanks for that too & already! -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ The past is over. signature.asc Description: PGP signature
Bug#1058445: marked as done (python-pyknon: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.12 3.11" returned exit code 13)
Your message dated Wed, 07 Feb 2024 19:49:46 +
with message-id
and subject line Bug#1058445: fixed in python-pyknon 1.2-6
has caused the Debian Bug report #1058445,
regarding python-pyknon: FTBFS: dh_auto_test: error: pybuild --test
--test-pytest -i python{version} -p "3.12 3.11" returned exit code 13
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
1058445: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1058445
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: python-pyknon
Version: 1.2-5
Severity: serious
Justification: FTBFS
Tags: trixie sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20231212 ftbfs-trixie
Hi,
During a rebuild of all packages in sid, your package failed to build
on amd64.
Relevant part (hopefully):
> make[2]: Entering directory '/<>/docs'
> sphinx-build -b html -d _build/doctrees . _build/html
> /usr/lib/python3/dist-packages/babel/messages/catalog.py:13:
> DeprecationWarning: 'cgi' is deprecated and slated for removal in Python 3.13
> from cgi import parse_header
> Running Sphinx v7.2.6
> making output directory... done
> WARNING: html_static_path entry '_static' does not exist
> WARNING: The config value `doctest_path' has type `str', defaults to `list'.
> building [mo]: targets for 0 po files that are out of date
> writing output...
> building [html]: targets for 4 source files that are out of date
> updating environment: [new config] 4 added, 0 changed, 0 removed
> [2Kreading sources... [ 25%] index
> [2Kreading sources... [ 50%] music
> [2Kreading sources... [ 75%] simplemusic
> [2Kreading sources... [100%] tutorial
>
> looking for now-outdated files... none found
> pickling environment... done
> checking consistency... done
> preparing documents... done
> copying assets... copying static files... done
> copying extra files... done
> done
> [2Kwriting output... [ 25%] index
> [2Kwriting output... [ 50%] music
> [2Kwriting output... [ 75%] simplemusic
> [2Kwriting output... [100%] tutorial
>
> generating indices... genindex done
> writing additional pages... search done
> dumping search index in English (code: en)... done
> dumping object inventory... done
> build succeeded, 2 warnings.
>
> The HTML pages are in _build/html.
>
> Build finished. The HTML pages are in _build/html.
> make[2]: Leaving directory '/<>/docs'
> make[1]: Leaving directory '/<>'
>dh_auto_test -O--buildsystem=pybuild
> I: pybuild base:310: cd /<>/.pybuild/cpython3_3.12/build;
> python3.12 -m pytest test
> = test session starts
> ==
> platform linux -- Python 3.12.1, pytest-7.4.3, pluggy-1.3.0
> rootdir: /<>
> collected 109 items
>
> test/test_genmidi.py .. [
> 5%]
> test/test_midi.py [
> 12%]
> test/test_music.py ..[
> 58%]
> test/test_notation.py .. [
> 64%]
> test/test_pcset.py ..[
> 73%]
> test/test_simplemusic.py .
> [100%]
>
> === FAILURES
> ===
> __ TestMIDIUtils.testAddNote
> ___
>
> self =
>
> def testAddNote(self):
> MyMIDI = MIDIFile(1)
> MyMIDI.addNote(0, 0, 100,0,1,100)
> > self.assertEquals(MyMIDI.tracks[0].eventList[0].type, "note")
> E AttributeError: 'TestMIDIUtils' object has no attribute
> 'assertEquals'. Did you mean: 'assertEqual'?
>
> test/test_midi.py:45: AttributeError
> _ TestMIDIUtils.testDeinterleaveNotes
> __
>
> self =
>
> def testDeinterleaveNotes(self):
> MyMIDI = MIDIFile(1)
> MyMIDI.addNote(0, 0, 100, 0, 2, 100)
> MyMIDI.addNote(0, 0, 100, 1, 2, 100)
> MyMIDI.close()
> > self.assertEquals(MyMIDI.tracks[0].MIDIEventList[0].type, 'NoteOn')
> E AttributeError: 'TestMIDIUtils' object has no attribute
> 'assertEquals'. Did you mean: 'assertEqual'?
>
> test/test_midi.py:56: AttributeError
> _ TestMIDIUtils.testFrequency
> __
>
> self =
>
> def testFrequency(self):
> freq = frequencyTransform(8.1758)
> > self.assertEquals(freq[0], 0x00)
> E AttributeError: 'TestMIDIUtils' object has no attribute
> 'assertEquals'. Did you mean: 'assertEqual'?
>
>
Bug#1062880: marked as done (saga: FTBFS: dh_auto_build: error: cd obj-x86_64-linux-gnu && make -j32 "INSTALL=install --strip-program=true" VERBOSE=1 returned exit code 2)
Your message dated Wed, 07 Feb 2024 19:50:06 +
with message-id
and subject line Bug#1062880: fixed in saga 9.3.1+dfsg-2
has caused the Debian Bug report #1062880,
regarding saga: FTBFS: dh_auto_build: error: cd obj-x86_64-linux-gnu && make
-j32 "INSTALL=install --strip-program=true" VERBOSE=1 returned exit code 2
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
1062880: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1062880
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: saga
Version: 9.3.1+dfsg-1
Severity: serious
Tags: sid ftbfs
Hi,
saga FTBFSes on sid. Here's the relevant build log:
--8<---cut here---start->8---
/<>/obj-x86_64-linux-gnu/src/saga_core/saga_api/saga_api_python/CMakeFiles/saga_api_python.dir/saga_apiPYTHON_wrap.cxx:
In function ‘PyObject* PyInit__saga_api()’:
/<>/obj-x86_64-linux-gnu/src/saga_core/saga_api/saga_api_python/CMakeFiles/saga_api_python.dir/saga_apiPYTHON_wrap.cxx:269918:82:
error: lvalue required as unary ‘&’ operand
269918 | SWIG_Python_SetConstant(d,
"M_ALMOST_ZERO",SWIG_NewPointerObj(SWIG_as_voidptr(&0.001),SWIGTYPE_p_long_double,
0 ));
|
^
/<>/obj-x86_64-linux-gnu/src/saga_core/saga_api/saga_api_python/CMakeFiles/saga_api_python.dir/saga_apiPYTHON_wrap.cxx:1136:89:
note: in definition of macro ‘SWIG_NewPointerObj’
1136 | #define SWIG_NewPointerObj(ptr, type, flags)
SWIG_Python_NewPointerObj(NULL, ptr, type, flags)
|
^~~
/<>/obj-x86_64-linux-gnu/src/saga_core/saga_api/saga_api_python/CMakeFiles/saga_api_python.dir/saga_apiPYTHON_wrap.cxx:269918:65:
note: in expansion of macro ‘SWIG_as_voidptr’
269918 | SWIG_Python_SetConstant(d,
"M_ALMOST_ZERO",SWIG_NewPointerObj(SWIG_as_voidptr(&0.001),SWIGTYPE_p_long_double,
0 ));
|
^~~
/<>/saga-gis/src/tools/imagery/imagery_classification/decision_tree.cpp:
In member function ‘int CDecision_Tree::Get_Class(const CSG_String&)’:
/<>/saga-gis/src/tools/imagery/imagery_classification/decision_tree.cpp:290:28:
warning: comparison of integer expressions of different signedness: ‘int’ and
‘size_t’ {aka ‘long unsigned int’} [-Wsign-compare]
290 | for(int i=0, j=1; i8---
Thanks,
--
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/
signature.asc
Description: PGP signature
--- End Message ---
--- Begin Message ---
Source: saga
Source-Version: 9.3.1+dfsg-2
Done: Bas Couwenberg
We believe that the bug you reported is fixed in the latest version of
saga, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 1062...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Bas Couwenberg (supplier of updated saga package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Wed, 07 Feb 2024 20:31:49 +0100
Source: saga
Architecture: source
Version: 9.3.1+dfsg-2
Distribution: unstable
Urgency: medium
Maintainer: Debian GIS Project
Changed-By: Bas Couwenberg
Closes: 1062880
Changes:
saga (9.3.1+dfsg-2) unstable; urgency=medium
.
* Team upload.
* Replace pkg-config build dependency with pkgconf.
* Drop Python bindings, causes FTBFS with SWIG 4.2.
(closes: #1062880)
Checksums-Sha1:
10749dcafc1820a695a9f77e08f856870b0e66a7 2304 saga_9.3.1+dfsg-2.dsc
ba4b07887e9ad9300440789aa28cbd38f6ad6c22 21708 saga_9.3.1+dfsg-2.debian.tar.xz
5017a73b49cfb0122198f488bee27a4992fe2a5e 18641
saga_9.3.1+dfsg-2_amd64.buildinfo
Checksums-Sha256:
29bf4292a5b19cd0321a18434395e6472ec0dd53a1dac672bdb8e2dde9a58e53 2304
saga_9.3.1+dfsg-2.dsc
33e8e7b6b2ea4d8dfe751997b3510ab973431a149656ae6826a612c92fe67431 21708
saga_9.3.1+dfsg-2.debian.tar.xz
08de7f2ebaaf1e3530d86ad15b213b45c9d9102369e87fe2034bb227b1440311 18641
saga_9.3.1+dfsg-2_amd64.buildinfo
Files:
8780efd39fc39d759fc3f5f7520ce228 2304 science optional saga_9.3.1+dfsg-2.
Bug#1056245: marked as done (fbtftp's autopkg tests fail with Python 3.12)
Your message dated Wed, 07 Feb 2024 19:34:02 + with message-id and subject line Bug#1056245: fixed in fbtftp 0.5-3 has caused the Debian Bug report #1056245, regarding fbtftp's autopkg tests fail with Python 3.12 to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 1056245: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1056245 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: src:fbtftp Version: 0.5-2 Severity: important Tags: sid trixie User: debian-pyt...@lists.debian.org Usertags: python3.12 fbtftp's autopkg tests fail with Python 3.12 (distutils module removed in 3.12): [...] 374s ERROR: Failure: ModuleNotFoundError (No module named 'distutils') 374s -- 374s Traceback (most recent call last): 374s File "/usr/lib/python3/dist-packages/nose/failure.py", line 39, in runTest 374s raise self.exc_val.with_traceback(self.tb) 374s File "/usr/lib/python3/dist-packages/nose/loader.py", line 416, in loadTestsFromName 374s module = self.importer.importFromPath( 374s ^ 374s File "/usr/lib/python3/dist-packages/nose/importer.py", line 47, in importFromPath 374s return self.importFromDir(dir_path, fqname) 374s 374s File "/usr/lib/python3/dist-packages/nose/importer.py", line 94, in importFromDir 374s mod = load_module(part_fqname, fh, filename, desc) 374s 374s File "/usr/lib/python3/dist-packages/zombie_imp/imp_3_11.py", line 238, in load_module 374s return load_source(name, filename, file) 374s^ 374s File "/usr/lib/python3/dist-packages/zombie_imp/imp_3_11.py", line 175, in load_source 374s module = _load(spec) 374s ^^^ 374s File "", line 960, in _load 374s File "", line 929, in _load_unlocked 374s File "", line 994, in exec_module 374s File "", line 488, in _call_with_frames_removed 374s File "/tmp/autopkgtest.xkq23u/autopkgtest_tmp/tests/integration_test.py", line 7, in 374s from distutils.spawn import find_executable 374s ModuleNotFoundError: No module named 'distutils' 374s 374s -- 374s Ran 35 tests in 2.049s 374s 374s FAILED (errors=1) --- End Message --- --- Begin Message --- Source: fbtftp Source-Version: 0.5-3 Done: Andreas Tille We believe that the bug you reported is fixed in the latest version of fbtftp, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 1056...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Andreas Tille (supplier of updated fbtftp package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Wed, 07 Feb 2024 20:15:55 +0100 Source: fbtftp Architecture: source Version: 0.5-3 Distribution: unstable Urgency: medium Maintainer: Debian Python Team Changed-By: Andreas Tille Closes: 1056245 Changes: fbtftp (0.5-3) unstable; urgency=medium . * Team upload. * Replace distutils by shutil to gain Python 3.12 compatibility Closes: #1056245 * Standards-Version: 4.6.2 (routine-update) * Build-Depends: s/dh-python/dh-sequence-python3/ (routine-update) * Add salsa-ci file (routine-update) Set upstream metadata fields: Repository-Browse. Checksums-Sha1: 34877322d0a67875dcae3769001b329bbf90daf4 2075 fbtftp_0.5-3.dsc b9988b6f4a0a472c9c4c3f20bac4576719b882c0 3044 fbtftp_0.5-3.debian.tar.xz e9d6d4aa798f9e450671098a38d32483baf8e7e2 7206 fbtftp_0.5-3_amd64.buildinfo Checksums-Sha256: c6227b4b8c68291eca5d1599174da98fe371625d633e1c3dad8ae78ef2433439 2075 fbtftp_0.5-3.dsc 82d858c05a27ddfdb0f8293a3709f1d34c8cfbac4cd772f7e35fb43ef07f2c33 3044 fbtftp_0.5-3.debian.tar.xz e4128cb6ff001c90aeb2ee4897da5a3170f9953b0a943cac4364b900cfe19f19 7206 fbtftp_0.5-3_amd64.buildinfo Files: c160a9251da8c31837bc10c40d2cfa7a 2075 python optional fbtftp_0.5-3.dsc 13cca0635490a9e6e0d83eba3e448b91 3044 python optional fbtftp_0.5-3.debian.tar.xz d7b874708ef08d45093a73745caf2b6b
Bug#1063409: mpi4py accesses the net for the build
Package: src:mpi4py
Version: 3.1.5-4
Severity: serious
Tags: sid trixie
at least the first repository should be available in the python3-doc
package.
[...]
make -C docs/source/usrman/ html man info latexpdf SPHINXOPTS="-D
today=\"January 14, 2024\""
make[2]: Entering directory '/<>/docs/source/usrman'
Running Sphinx v7.2.6
making output directory... done
[autosummary] generating autosummary for: appendix.rst, citing.rst,
index.rst, install.rst, intro.rst, mpi4py.MPI.rst, mpi4py.futures.rst,
mpi4py.rst, mpi4py.run.rst, mpi4py.util.dtlib.rst, mpi4py.util.pkl5.rst,
mpi4py.util.rst, overview.rst, reference.rst, tutorial.rst
[autosummary] generating autosummary for:
/<>/docs/source/usrman/reference/mpi4py.MPI.rst
loading intersphinx inventory from https://docs.python.org/3/objects.inv...
loading intersphinx inventory from
https://numpy.org/doc/stable/objects.inv...
WARNING: failed to reach any of the inventories with the following issues:
intersphinx inventory 'https://numpy.org/doc/stable/objects.inv' not
fetchable due to :
HTTPSConnectionPool(host='numpy.org', port=443): Max retries exceeded
with url: /doc/stable/objects.inv (Caused by ProxyError('Cannot connect
to proxy.', NewConnectionError('object at 0x7fec6bad3e90>: Failed to establish a new connection: [Errno
111] Connection refused')))
WARNING: failed to reach any of the inventories with the following issues:
intersphinx inventory 'https://docs.python.org/3/objects.inv' not
fetchable due to :
HTTPSConnectionPool(host='docs.python.org', port=443): Max retries
exceeded with url: /3/objects.inv (Caused by ProxyError('Cannot connect
to proxy.', NewConnectionError('object at 0x7fec6baa4550>: Failed to establish a new connection: [Errno
111] Connection refused')))
building [mo]: targets for 0 po files that are out of date
writing output...
building [html]: targets for 15 source files that are out of date
Bug#1058366: marked as done (beaker: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.12 3.11" returned exit code 13)
Your message dated Wed, 07 Feb 2024 19:19:06 +
with message-id
and subject line Bug#1058366: fixed in beaker 1.12.1-3
has caused the Debian Bug report #1058366,
regarding beaker: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i
python{version} -p "3.12 3.11" returned exit code 13
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
1058366: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1058366
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: beaker
Version: 1.12.1-1.1
Severity: serious
Justification: FTBFS
Tags: trixie sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20231212 ftbfs-trixie
Hi,
During a rebuild of all packages in sid, your package failed to build
on amd64.
Relevant part (hopefully):
> debian/rules binary
> dh binary --with python3 --buildsystem=pybuild
>dh_update_autotools_config -O--buildsystem=pybuild
>dh_autoreconf -O--buildsystem=pybuild
>dh_auto_configure -O--buildsystem=pybuild
> I: pybuild base:310: python3.12 setup.py config
> running config
> I: pybuild base:310: python3.11 setup.py config
> running config
>dh_auto_build -O--buildsystem=pybuild
> I: pybuild base:310: /usr/bin/python3.12 setup.py build
> running build
> running build_py
> creating /<>/.pybuild/cpython3_3.12_beaker/build/beaker
> copying beaker/__init__.py ->
> /<>/.pybuild/cpython3_3.12_beaker/build/beaker
> copying beaker/converters.py ->
> /<>/.pybuild/cpython3_3.12_beaker/build/beaker
> copying beaker/session.py ->
> /<>/.pybuild/cpython3_3.12_beaker/build/beaker
> copying beaker/container.py ->
> /<>/.pybuild/cpython3_3.12_beaker/build/beaker
> copying beaker/exceptions.py ->
> /<>/.pybuild/cpython3_3.12_beaker/build/beaker
> copying beaker/middleware.py ->
> /<>/.pybuild/cpython3_3.12_beaker/build/beaker
> copying beaker/synchronization.py ->
> /<>/.pybuild/cpython3_3.12_beaker/build/beaker
> copying beaker/_compat.py ->
> /<>/.pybuild/cpython3_3.12_beaker/build/beaker
> copying beaker/cookie.py ->
> /<>/.pybuild/cpython3_3.12_beaker/build/beaker
> copying beaker/util.py ->
> /<>/.pybuild/cpython3_3.12_beaker/build/beaker
> copying beaker/cache.py ->
> /<>/.pybuild/cpython3_3.12_beaker/build/beaker
> creating /<>/.pybuild/cpython3_3.12_beaker/build/beaker/crypto
> copying beaker/crypto/pycrypto.py ->
> /<>/.pybuild/cpython3_3.12_beaker/build/beaker/crypto
> copying beaker/crypto/__init__.py ->
> /<>/.pybuild/cpython3_3.12_beaker/build/beaker/crypto
> copying beaker/crypto/pyca_cryptography.py ->
> /<>/.pybuild/cpython3_3.12_beaker/build/beaker/crypto
> copying beaker/crypto/jcecrypto.py ->
> /<>/.pybuild/cpython3_3.12_beaker/build/beaker/crypto
> copying beaker/crypto/pbkdf2.py ->
> /<>/.pybuild/cpython3_3.12_beaker/build/beaker/crypto
> copying beaker/crypto/nsscrypto.py ->
> /<>/.pybuild/cpython3_3.12_beaker/build/beaker/crypto
> copying beaker/crypto/noencryption.py ->
> /<>/.pybuild/cpython3_3.12_beaker/build/beaker/crypto
> copying beaker/crypto/util.py ->
> /<>/.pybuild/cpython3_3.12_beaker/build/beaker/crypto
> creating /<>/.pybuild/cpython3_3.12_beaker/build/beaker/ext
> copying beaker/ext/__init__.py ->
> /<>/.pybuild/cpython3_3.12_beaker/build/beaker/ext
> copying beaker/ext/redisnm.py ->
> /<>/.pybuild/cpython3_3.12_beaker/build/beaker/ext
> copying beaker/ext/sqla.py ->
> /<>/.pybuild/cpython3_3.12_beaker/build/beaker/ext
> copying beaker/ext/database.py ->
> /<>/.pybuild/cpython3_3.12_beaker/build/beaker/ext
> copying beaker/ext/memcached.py ->
> /<>/.pybuild/cpython3_3.12_beaker/build/beaker/ext
> copying beaker/ext/mongodb.py ->
> /<>/.pybuild/cpython3_3.12_beaker/build/beaker/ext
> copying beaker/ext/google.py ->
> /<>/.pybuild/cpython3_3.12_beaker/build/beaker/ext
> I: pybuild base:310: /usr/bin/python3 setup.py build
> running build
> running build_py
> creating /<>/.pybuild/cpython3_3.11_beaker/build/beaker
> copying beaker/__init__.py ->
> /<>/.pybuild/cpython3_3.11_beaker/build/beaker
> copying beaker/converters.py ->
> /<>/.pybuild/cpython3_3.11_beaker/build/beaker
> copying beaker/session.py ->
> /<>/.pybuild/cpython3_3.11_beaker/build/beaker
> copying beaker/container.py ->
> /<>/.pybuild/cpython3_3.11_beaker/build/beaker
> copying beaker/exceptions.py ->
> /<>/.pybuild/cpython3_3.11_beaker/build/beaker
> copying beaker/middleware.py ->
> /<>/.pybuild/cpython3_3.11_beaker/build/beaker
> copying beaker/synchronization.py ->
> /<>/.pybuild/cpython3_3.11_beaker/build/beaker
> copying beaker/_compat.py ->
> /<>/.pybuild/cpython3_3.11_beaker/build/beaker
> copying beaker/cookie.py ->
> /<>/.
Processed: Re: Bug#1061866: adns: NMU diff for 64-bit time_t transition
Processing control commands: > severity -1 important Bug #1061866 [src:adns] adns: NMU diff for 64-bit time_t transition Severity set to 'important' from 'serious' -- 1061866: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1061866 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1061866: adns: NMU diff for 64-bit time_t transition
Control: severity -1 important
Ian Jackson writes ("Re: Bug#1061866: adns: NMU diff for 64-bit time_t
transition"):
> I have just got an alert saying adns is now scheduled for autoremoval
> due to #1061866.
>
> My understanding was that you were intending to NMU to unstable after
> "several days". I have been holding off making an upload myself so as
> not to interfere.
I'm not sure if I should:
(i) wait
(ii) apply that patch (on top of what's in experimental)
and upload to experimental
(iii) apply that patch on top of what's in experimental
and upload the result to sid.
For now I am going to downgrade this bug in the hope that the current
answer is (i).
Regards,
Ian.
--
Ian JacksonThese opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
Processed: severity of 1061961 is important, severity of 1061980 is important, severity of 1062100 is important ...
Processing commands for cont...@bugs.debian.org: > severity 1061961 important Bug #1061961 [src:fyba] fyba: NMU diff for 64-bit time_t transition Severity set to 'important' from 'serious' > severity 1061980 important Bug #1061980 [src:gdal] gdal: NMU diff for 64-bit time_t transition Severity set to 'important' from 'serious' > severity 1062100 important Bug #1062100 [src:geos] geos: NMU diff for 64-bit time_t transition Severity set to 'important' from 'serious' > severity 1062177 important Bug #1062177 [src:gmt] gmt: NMU diff for 64-bit time_t transition Severity set to 'important' from 'serious' > severity 1062223 important Bug #1062223 [src:libapreq2] libapreq2: NMU diff for 64-bit time_t transition Severity set to 'important' from 'serious' > severity 1062393 important Bug #1062393 [src:libkml] libkml: NMU diff for 64-bit time_t transition Severity set to 'important' from 'serious' > severity 1062717 important Bug #1062717 [src:qgis] qgis: NMU diff for 64-bit time_t transition Severity set to 'important' from 'serious' > severity 1062830 important Bug #1062830 [src:mapcache] mapcache: NMU diff for 64-bit time_t transition Severity set to 'important' from 'serious' > severity 1062834 important Bug #1062834 [src:mapnik] mapnik: NMU diff for 64-bit time_t transition Severity set to 'important' from 'serious' > severity 1062837 important Bug #1062837 [src:mapserver] mapserver: NMU diff for 64-bit time_t transition Severity set to 'important' from 'serious' > severity 1062893 important Bug #1062893 [src:sfcgal] sfcgal: NMU diff for 64-bit time_t transition Severity set to 'important' from 'serious' > severity 1063086 important Bug #1063086 [src:virtualpg] virtualpg: NMU diff for 64-bit time_t transition Severity set to 'important' from 'serious' > severity 1063168 important Bug #1063168 [src:netcdf] netcdf: NMU diff for 64-bit time_t transition Severity set to 'important' from 'serious' > severity 1063259 important Bug #1063259 [src:pktools] pktools: NMU diff for 64-bit time_t transition Severity set to 'important' from 'serious' > thanks Stopping processing here. Please contact me if you need assistance. -- 1061961: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1061961 1061980: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1061980 1062100: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1062100 1062177: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1062177 1062223: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1062223 1062393: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1062393 1062717: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1062717 1062830: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1062830 1062834: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1062834 1062837: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1062837 1062893: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1062893 1063086: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1063086 1063168: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1063168 1063259: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1063259 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: augur 24 still ftbfs against pandas 2.1.4
Processing control commands:
> reopen -1
Bug #1044079 {Done: Étienne Mollier } [src:augur] augur:
FTBFS with pandas 2.0
'reopen' may be inappropriate when a bug has been closed with a version;
all fixed versions will be cleared, and you may need to re-add them.
Bug reopened
No longer marked as fixed in versions augur/24.0.0-1.
--
1044079: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1044079
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
Bug#1044079: augur 24 still ftbfs against pandas 2.1.4
Control: reopen -1 I must have mistaken something about pandas versions when uploading augur 24.0.0, because the error is still there and is now causing ftbfs again with at least pandas 2.1.4. This is still the same error in the same test: self = capsys = <_pytest.capture.CaptureFixture object at 0x7fc3d81d59d0> def test_fix_dates(self, capsys): full_date = "4-5-2020" > assert parse.fix_dates(full_date) == "2020-05-04" tests/test_parse.py:14: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ d = '4-5-2020', dayfirst = True def fix_dates(d, dayfirst=True): ''' attempt to parse a date string using pandas date parser. If ambiguous, the argument 'dayfirst' determines whether month or day is assumed to be the first field. Incomplete dates will be padded with XX. On failure to parse the date, the function will return the input. ''' try: from pandas.core.tools.datetimes import parsing > results = parsing.parse_time_string(d, dayfirst=dayfirst) E AttributeError: module 'pandas._libs.tslibs.parsing' has no attribute 'parse_time_string' Too bad things looked promising, -- .''`. Étienne Mollier : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/3, please excuse my verbosity `- signature.asc Description: PGP signature
Bug#1063049: visp: NMU diff for 64-bit time_t transition
Dear, Thanks for this patch. If I understand well you will apply the patch. I don't have to apply it to the upstream. I'm right? Regards Fabien Le 04/02/2024 à 19:19, Steve Langasek a écrit : Source: visp Version: 3.6.0-2 Severity: serious Tags: patch pending sid trixie Justification: library ABI skew on upgrade User: debian-...@lists.debian.org Usertags: time-t NOTICE: these changes must not be uploaded to unstable yet! Dear maintainer, As part of the 64-bit time_t transition required to support 32-bit architectures in 2038 and beyond (https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified visp as a source package shipping runtime libraries whose ABI either is affected by the change in size of time_t, or could not be analyzed via abi-compliance-checker (and therefore to be on the safe side we assume is affected). To ensure that inconsistent combinations of libraries with their reverse-dependencies are never installed together, it is necessary to have a library transition, which is most easily done by renaming the runtime library package. Since turning on 64-bit time_t is being handled centrally through a change to the default dpkg-buildflags (https://bugs.debian.org/1037136), it is important that libraries affected by this ABI change all be uploaded close together in time. Therefore I have prepared a 0-day NMU for visp which will initially be uploaded to experimental if possible, then to unstable after packages have cleared binary NEW. Please find the patch for this NMU attached. If you have any concerns about this patch, please reach out ASAP. Although this package will be uploaded to experimental immediately, there will be a period of several days before we begin uploads to unstable; so if information becomes available that your package should not be included in the transition, there is time for us to amend the planned uploads. -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.5.0-14-generic (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system)
Bug#1063407: pybdsf fails to build with Python 3.12 as default
Package: src:pybdsf
Version: 1.10.3-2
Severity: serious
Tags: sid trixie ftbfs
User: debian-pyt...@lists.debian.org
Usertags: python3.12
Forwarded: https://github.com/lofar-astron/PyBDSF/issues/214
pybdsf fails to build with Python 3.12 as default, also the autopkg test
fails with:
290s autopkgtest [09:33:17]: test command1: [---
292s [31;1mWARNING[0m: Matplotlib pyplot could not be imported.
Plotting is disabled.
293s --> Loaded parameters from file 'tbdsf_process_image.in'.
293s Traceback (most recent call last):
293s File
"/tmp/autopkgtest.Z7dzWY/build.NDT/src/test/tbdsf_process_image.py",
line 5, in
293s img = bdsf.process_image('tbdsf_process_image.in', ncores=2)
293s ^^
293s File "/usr/lib/python3/dist-packages/bdsf/__init__.py", line 256,
in process_image
293s img.process(**kwargs)
293s File "/usr/lib/python3/dist-packages/bdsf/image.py", line 136, in
process
293s success = interface.process(self, **kwargs)
293s ^
293s File "/usr/lib/python3/dist-packages/bdsf/interface.py", line 66,
in process
293s _run_op_list(img, op_chain)
293s File "/usr/lib/python3/dist-packages/bdsf/__init__.py", line 155,
in _run_op_list
293s op(img)
293s File "/usr/lib/python3/dist-packages/bdsf/readimage.py", line 68,
in __call__
293s result = read_image_from_file(image_file, img, img.indir)
293s
293s File "/usr/lib/python3/dist-packages/bdsf/functions.py", line
1079, in read_image_from_file
293s from distutils.version import StrictVersion
293s ModuleNotFoundError: No module named 'distutils'
294s autopkgtest [09:33:21]: test command1: ---]
297s command1 FAIL non-zero exit status 1
Bug#1062781: marked as done (polari FTBFS with nocheck build profile: ../meson.build:68:6: ERROR: Program 'update-desktop-database' not found or not executable)
Your message dated Wed, 07 Feb 2024 16:50:40 + with message-id and subject line Bug#1062781: fixed in polari 45.0-3 has caused the Debian Bug report #1062781, regarding polari FTBFS with nocheck build profile: ../meson.build:68:6: ERROR: Program 'update-desktop-database' not found or not executable to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 1062781: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1062781 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Source: polari Version: 45.0-2 Severity: serious Tags: ftbfs trixie sid polari fails to build from source when built with the nocheck build profile. Since trixie, such a failure is considered release-critical. A build ends with: | Program gtk-update-icon-cache found: YES (/usr/bin/gtk-update-icon-cache) | Program update-desktop-database found: NO | | ../meson.build:68:6: ERROR: Program 'update-desktop-database' not found or not executable | dh_auto_configure: error: cd obj-x86_64-linux-gnu && DEB_PYTHON_INSTALL_LAYOUT=deb LC_ALL=C.UTF-8 meson setup .. --wrap-mode=nodownload --buildtype=plain --prefix=/usr --sysconfdir=/etc --localstatedir=/var --libdir=lib/x86_64-linux-gnu -Dpython.bytecompile=-1 returned exit code 1 | make: *** [debian/rules:7: binary] Error 25 | dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2 Please review your annotations. Helmut --- End Message --- --- Begin Message --- Source: polari Source-Version: 45.0-3 Done: Jeremy Bícha We believe that the bug you reported is fixed in the latest version of polari, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 1062...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Jeremy Bícha (supplier of updated polari package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Wed, 07 Feb 2024 11:27:02 -0500 Source: polari Built-For-Profiles: noudeb Architecture: source Version: 45.0-3 Distribution: unstable Urgency: medium Maintainer: Debian GNOME Maintainers Changed-By: Jeremy Bícha Closes: 1062781 Changes: polari (45.0-3) unstable; urgency=medium . * Drop erroneous nocheck annotation from desktop-file-utils dependency (Closes: #1062781) * Add Build-Depends: json-glib-tools for build tests * Update syntax for lintian override Checksums-Sha1: 7fcfce80cce3d97a5d67ea7b9281eee636c1a351 2292 polari_45.0-3.dsc da9a43da67f17b1c2feb9eb96df3961f6d007287 5400 polari_45.0-3.debian.tar.xz 5ffcb27f83a28f892f74519327c7fde81160dc78 11648 polari_45.0-3_source.buildinfo Checksums-Sha256: df80c285731e1ea1c76cab95875833f209cdf8c548df5baf46ff74cb9157148c 2292 polari_45.0-3.dsc bc0e7e8c111e189d162b90fb2e9c5b9e6f769958275f66ec62e3f2b3cbd4355c 5400 polari_45.0-3.debian.tar.xz 19b9d1be35bc608a97a5478bb2a6d9f6b6d776f494f146a0b7879271a527 11648 polari_45.0-3_source.buildinfo Files: f1324c40dde6712b9333c55d8aa61e0e 2292 gnome optional polari_45.0-3.dsc ee1e70ad5aeaa4100e124278a45872ad 5400 gnome optional polari_45.0-3.debian.tar.xz ae0339c10aecf7ee57239b7fa0cd31d5 11648 gnome optional polari_45.0-3_source.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEETQvhLw5HdtiqzpaW5mx3Wuv+bH0FAmXDr3EACgkQ5mx3Wuv+ bH04EQ/9HFGda9NtYNMB1bqtM8JHMIEjMz0clqT3KcVkYmYZFhQpSiPdemmQNDa9 GGlsFhlmd4E/csvLmkvWCVElUCGd4Xalmqdwzi6qffY3jVsU9T8HB/morU8T+HmA aWy5rmvRB/irPYm//n+pxJlFGrxKsrijTW9R3lV2TE6F2OWYj+HeHJusCvVqREV1 v4H6YjQ75oPBb60cZiC6+anSwGdB7kf0yKl1e9NdorQ8EYgSPiC0L0bfN08Hj4lz eQLbD1jIK6Y4fAWuJvYOiQTtflPRVdoKODN5RZjC5oqVffABvr58F4kEqRq8NDug 1OlRd0vmBDmHLXxmqiKBhct3sSwgSLLpEfooyv4sSr3IXsqKsAr5sUMGE9Pn63tT VmztpWIHaQ3bQLAcp6uILiYOVw5w5h3Y2w1vATQW4wsLSh98wCbjv5C9E7Z2/PkT 8pjfwRmxUVg0Wb0TaYU4tucpES/6u0b+lrYMylgXLe7G+eFxCSx9lM5ApqulSwjJ u3JicGmRfZ/QgR5Pu1ibsb7hJaiQcYGFYHVCSDGzkiMegdL+k8tBTQv3csX8QnjE YDjX5Yu0trzCuGlDQ0wVVvTmKZByFJ0FRchdlYdD0skiBLH+tNU/OWGZ2SnpRVmF fQve8DR0qjoySltYz3kcFZDARimJjgS3Ht8BDBxE6cijCPcUh/A= =Q7nt -END PGP SIGNATURE End Message ---
Bug#1063403: libeegdev-dev,libeegdev0t64: both ship /usr/share/doc/libeegdev0/changelog.gz
Package: libeegdev-dev,libeegdev0t64
Version: 0.2-8.1~exp1
Severity: serious
User: debian-...@lists.debian.org
Usertags: time-t
X-Debbugs-Cc: Michael Hudson-Doyle
Something weird happened after the package rename:
/usr/share/doc/libeegdev0/changelog.Debian.gz
/usr/share/doc/libeegdev0/changelog.gz
Are now shipped by libeegdev-dev and libeegdev0t64 while they should be
in none of these packages.
$ debdiff libeegdev-dev_0.2-8_amd64.deb libeegdev-dev_0.2-8.1~exp1_amd64.deb
[The following lists of changes regard files as different if they have
different names, permissions or owners.]
Files in second .deb but not in first
-
-rw-r--r-- root/root /usr/share/doc/libeegdev0/changelog.Debian.gz
-rw-r--r-- root/root /usr/share/doc/libeegdev0/changelog.gz
Control files: lines which differ (wdiff format)
Depends: {+libeegdev0t64 (= 0.2-8.1~exp1),+} libeegdev0 (= [-0.2-8)-]
{+0.2-8.1~exp1)+}
Installed-Size: [-71-] {+87+}
Version: [-0.2-8-] {+0.2-8.1~exp1+}
Also the libeegdev0 dependency is still there ...
Andreas
Bug#1063401: atm-tools: has gained /usr/share/doc/libatm1/changelog.*
Package: atm-tools
Version: 1:2.5.1-5.1~exp1
Severity: serious
User: debian-...@lists.debian.org
Usertags: time-t
X-Debbugs-Cc: Steve Langasek
atm-tools/experimental has gained two unexpected files, causing file
conflicts on upgrades:
$ debdiff atm-tools_1%3a2.5.1-5_amd64.deb atm-tools_1%3a2.5.1-5.1~exp1_amd64.deb
[The following lists of changes regard files as different if they have
different names, permissions or owners.]
Files in second .deb but not in first
-
-rw-r--r-- root/root /usr/share/doc/libatm1/changelog.Debian.gz
-rw-r--r-- root/root /usr/share/doc/libatm1/changelog.gz
Control files: lines which differ (wdiff format)
Depends: [-libatm1 (= 1:2.5.1-5),-] {+libatm1t64 (>= 2.4.1-17~),+} libc6 (>=
2.34), libfl2 (>= [-2.5.33)-] {+2.5.33), libatm1 (= 1:2.5.1-5.1~exp1)+}
Installed-Size: [-1197-] {+1243+}
Version: [-1:2.5.1-5-] {+1:2.5.1-5.1~exp1+}
There is still an libatm1 dependency, and the new libatm1t64 dependency
seems to miss the epoch.
Andreas
BTW, linux-atm is orphaned, so you should do QA instead of NMU uploads.
Processed: Re: libcomps: NMU diff for 64-bit time_t transition
Processing control commands: > tags -1 -pending Bug #1062259 [src:libcomps] libcomps: NMU diff for 64-bit time_t transition Removed tag(s) pending. > close -1 Bug #1062259 [src:libcomps] libcomps: NMU diff for 64-bit time_t transition Marked Bug as done -- 1062259: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1062259 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1062259: libcomps: NMU diff for 64-bit time_t transition
Control: tags -1 -pending Control: close -1 On Wed, 31 Jan 2024 21:02:50 + Steve Langasek wrote: > Source: libcomps > Version: 0.1.19-2.1 > Severity: serious > Tags: patch pending > Justification: library ABI skew on upgrade > User: debian-...@lists.debian.org > Usertags: time-t > > Dear maintainer, > > As part of the 64-bit time_t transition required to support 32-bit > architectures in 2038 and beyond > (https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified > libcomps as a source package shipping runtime libraries whose ABI > either is affected by the change in size of time_t, or could not be > analyzed via abi-compliance-checker (and therefore to be on the safe > side we assume is affected). > > To ensure that inconsistent combinations of libraries with their > reverse-dependencies are never installed together, it is necessary to > have a library transition, which is most easily done by renaming the > runtime library package. > > Since turning on 64-bit time_t is being handled centrally through a change > to the default dpkg-buildflags (https://bugs.debian.org/1037136), it is > important that libraries affected by this ABI change all be uploaded close > together in time. Therefore I have prepared a 0-day NMU for libcomps > which will initially be uploaded to experimental if possible, then to > unstable after packages have cleared binary NEW. > > Please find the patch for this NMU attached. > > If you have any concerns about this patch, please reach out ASAP. Although > this package will be uploaded to experimental immediately, there will be a > period of several days before we begin uploads to unstable; so if information > becomes available that your package should not be included in the transition, > there is time for us to amend the planned uploads. There are no mentions of 'time_t' in the public headers of this library. The logs shows that it's a false positive, as the automated tool simply wasn't able to build it: https://adrien.dcln.fr/misc/armhf-time_t/2024-02-06T16%3A48%3A00/logs/libcomps-dev/base/log.txt Closing as not applicable. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1062674: lua-compat53: NMU diff for 64-bit time_t transition
On Fri, Feb 02, 2024 at 04:18:01PM +, Graham Inggs wrote: > If you have any concerns about this patch, please reach out ASAP. Although > this package will be uploaded to experimental immediately, there will be a > period of several days before we begin uploads to unstable; so if information > becomes available that your package should not be included in the transition, > there is time for us to amend the planned uploads. The 53 in lua-compat53 isn't related to the ABI. This Lua module provides a Lua 5.3 API surface that can be used in previous Lua versions. Lua module packages aren't generally named according to the SONAME (for reasons I'm not clear on). Cheers, -- James GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
Processed: Re: libzypp: NMU diff for 64-bit time_t transition
Processing control commands: > tags -1 -pending Bug #1062744 [src:libzypp] libzypp: NMU diff for 64-bit time_t transition Removed tag(s) pending. > close -1 Bug #1062744 [src:libzypp] libzypp: NMU diff for 64-bit time_t transition Marked Bug as done -- 1062744: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1062744 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: Re: libsolv: NMU diff for 64-bit time_t transition
Processing control commands: > tags -1 -pending Bug #1062632 [src:libsolv] libsolv: NMU diff for 64-bit time_t transition Removed tag(s) pending. > close -1 Bug #1062632 [src:libsolv] libsolv: NMU diff for 64-bit time_t transition Marked Bug as done -- 1062632: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1062632 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1062744: libzypp: NMU diff for 64-bit time_t transition
Control: tags -1 -pending Control: close -1 On Fri, 02 Feb 2024 23:01:04 + Steve Langasek wrote: > Source: libzypp > Version: 17.31.29-1 > Severity: serious > Tags: patch pending sid trixie > Justification: library ABI skew on upgrade > User: debian-...@lists.debian.org > Usertags: time-t > > NOTICE: these changes must not be uploaded to unstable yet! > > Dear maintainer, > > As part of the 64-bit time_t transition required to support 32-bit > architectures in 2038 and beyond > (https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified > libzypp as a source package shipping runtime libraries whose ABI > either is affected by the change in size of time_t, or could not be > analyzed via abi-compliance-checker (and therefore to be on the safe > side we assume is affected). > > To ensure that inconsistent combinations of libraries with their > reverse-dependencies are never installed together, it is necessary to > have a library transition, which is most easily done by renaming the > runtime library package. > > Since turning on 64-bit time_t is being handled centrally through a change > to the default dpkg-buildflags (https://bugs.debian.org/1037136), it is > important that libraries affected by this ABI change all be uploaded close > together in time. Therefore I have prepared a 0-day NMU for libzypp > which will initially be uploaded to experimental if possible, then to > unstable after packages have cleared binary NEW. > > Please find the patch for this NMU attached. > > If you have any concerns about this patch, please reach out ASAP. Although > this package will be uploaded to experimental immediately, there will be a > period of several days before we begin uploads to unstable; so if information > becomes available that your package should not be included in the transition, > there is time for us to amend the planned uploads. There are no mentions of 'time_t' in the public headers of this library. The logs shows that it's a false positive, as the automated tool simply wasn't able to build it: https://adrien.dcln.fr/misc/armhf-time_t/2023-12-18/logs/libzypp-dev/base/log.txt Closing as not applicable. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1062632: libsolv: NMU diff for 64-bit time_t transition
Control: tags -1 -pending Control: close -1 On Fri, 02 Feb 2024 07:47:44 + Steve Langasek wrote: > Source: libsolv > Version: 0.7.28-1 > Severity: serious > Tags: patch pending > Justification: library ABI skew on upgrade > User: debian-...@lists.debian.org > Usertags: time-t > > NOTICE: these changes must not be uploaded to unstable yet! > > Dear maintainer, > > As part of the 64-bit time_t transition required to support 32-bit > architectures in 2038 and beyond > (https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified > libsolv as a source package shipping runtime libraries whose ABI > either is affected by the change in size of time_t, or could not be > analyzed via abi-compliance-checker (and therefore to be on the safe > side we assume is affected). > > To ensure that inconsistent combinations of libraries with their > reverse-dependencies are never installed together, it is necessary to > have a library transition, which is most easily done by renaming the > runtime library package. > > Since turning on 64-bit time_t is being handled centrally through a change > to the default dpkg-buildflags (https://bugs.debian.org/1037136), it is > important that libraries affected by this ABI change all be uploaded close > together in time. Therefore I have prepared a 0-day NMU for libsolv > which will initially be uploaded to experimental if possible, then to > unstable after packages have cleared binary NEW. > > Please find the patch for this NMU attached. > > If you have any concerns about this patch, please reach out ASAP. Although > this package will be uploaded to experimental immediately, there will be a > period of several days before we begin uploads to unstable; so if information > becomes available that your package should not be included in the transition, > there is time for us to amend the planned uploads. There are no mentions of 'time_t' in the public headers of this library. The logs shows that it's a false positive, as the automated tool simply wasn't able to build it: https://adrien.dcln.fr/misc/armhf-time_t/2023-12-18/logs/libsolvext-dev/base/log.txt Closing as not applicable. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1063400: giza-dev: missing Conflicts: pgplot5t64
Package: giza-dev Version: 1.4.1-1 Severity: serious User: debian-...@lists.debian.org Usertags: time-t X-Debbugs-Cc: Lucas Kanashiro giza-dev already has Conflicts: pgplot5 there needs to be pgplot5t64 added ... The conflicting file is /usr/include/cpgplot.h Andreas
Bug#1062928: stlink: NMU diff for 64-bit time_t transition
Control: tags -1 -pending Control: close -1 On Sun, 04 Feb 2024 00:43:16 + Steve Langasek wrote: > Source: stlink > Version: 1.7.0+ds-2 > Severity: serious > Tags: patch pending sid trixie > Justification: library ABI skew on upgrade > User: debian-...@lists.debian.org > Usertags: time-t > > NOTICE: these changes must not be uploaded to unstable yet! > > Dear maintainer, > > As part of the 64-bit time_t transition required to support 32-bit > architectures in 2038 and beyond > (https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified > stlink as a source package shipping runtime libraries whose ABI > either is affected by the change in size of time_t, or could not be > analyzed via abi-compliance-checker (and therefore to be on the safe > side we assume is affected). > > To ensure that inconsistent combinations of libraries with their > reverse-dependencies are never installed together, it is necessary to > have a library transition, which is most easily done by renaming the > runtime library package. > > Since turning on 64-bit time_t is being handled centrally through a change > to the default dpkg-buildflags (https://bugs.debian.org/1037136), it is > important that libraries affected by this ABI change all be uploaded close > together in time. Therefore I have prepared a 0-day NMU for stlink > which will initially be uploaded to experimental if possible, then to > unstable after packages have cleared binary NEW. > > Please find the patch for this NMU attached. > > If you have any concerns about this patch, please reach out ASAP. Although > this package will be uploaded to experimental immediately, there will be a > period of several days before we begin uploads to unstable; so if information > becomes available that your package should not be included in the transition, > there is time for us to amend the planned uploads. There are no mentions of 'time_t' in the public headers of this library. The logs shows that it's a false positive, as the automated tool simply wasn't able to build it: https://adrien.dcln.fr/misc/armhf-time_t/2023-12-18/logs/libstlink-dev/base/log.txt Closing as not applicable. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Processed: Re: stlink: NMU diff for 64-bit time_t transition
Processing control commands: > tags -1 -pending Bug #1062928 [src:stlink] stlink: NMU diff for 64-bit time_t transition Removed tag(s) pending. > close -1 Bug #1062928 [src:stlink] stlink: NMU diff for 64-bit time_t transition Marked Bug as done -- 1062928: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1062928 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1058365: add patch
On Thu, Jan 11, 2024 at 12:00:13PM +0100, Matthias Klose wrote: > Control: tags -1 + patch > > patch at > https://launchpadlibrarian.net/708712831/python-jedi_0.18.2-1_0.18.2-1ubuntu1.diff.gz Hi Piotr, Are you able to upload a fixed or new version of python-jedi to address this serious bug? It is likely to soon pull spyder out of testing, which I am responsible for. I'm happy to do an NMU, uploading the new version of python-jedi (as that introduces compatibility with Python 3.12). I'll do so in a few days if I haven't heard back from you by then. At the same time, using the python3-typeshed package rather than vendoring it (#1039627) would also fix #1040094, but this might be a bit more work, as jedi/inference/gradual/utils.py would also need some attention, and some of the test_typeshed.py tests might no longer work. You could also drop python3-unittest2 without harm (#1058976). I'd be happy to have a go at these other bugs if you would like me to. Best wishes, Julian
Bug#1063399: kylin-process-manager-daemon: missing Breaks+Replaces: kylin-process-manager (<< 4)
Package: kylin-process-manager-daemon Version: 4.0.0.0-1 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package fails to upgrade from 'experimental' to 'sid'. It installed fine in 'experimental', then the upgrade to 'sid' fails because it tries to overwrite other packages files without declaring a Breaks+Replaces relation. This error may also be triggered by having a predecessor package from 'experimental' installed while installing the package from 'sid'. See policy 7.6 at https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces >From the attached log (scroll to the bottom...): Preparing to unpack .../kylin-process-manager-daemon_4.0.0.0-1+b1_amd64.deb ... Unpacking kylin-process-manager-daemon (4.0.0.0-1+b1) ... dpkg: error processing archive /var/cache/apt/archives/kylin-process-manager-daemon_4.0.0.0-1+b1_amd64.deb (--unpack): trying to overwrite '/etc/kylin-process-manager/kylin-process-manager.json', which is also in package kylin-process-manager 3.0.0-1 Errors were encountered while processing: /var/cache/apt/archives/kylin-process-manager-daemon_4.0.0.0-1+b1_amd64.deb The files in conflict are: etc/kylin-process-manager/kylin-process-manager.json lib/systemd/system/kylin-process-manager-cleaner.service cheers, Andreas kylin-process-manager=3.0.0-1_kylin-process-manager-daemon=4.0.0.0-1+b1.log.gz Description: application/gzip
Bug#1063398: FTBFS: src/capng_swig.i:33: Error: Unknown directive '%except'
On 07.02.2024 16:27, Emanuele Rocca wrote: > Source: libcap-ng > Version: 0.8.4-1 > Severity: serious > Tags: sid trixie ftbfs > > Hi, > > libcap-ng currently FTBFS with the following error: > > make[6]: Entering directory '/<>/build-py3.11/bindings/python3' > cat /usr/include/linux/capability.h | grep '^#define CAP' | grep -v '[()]' > > caps.h > cat ../../../src/cap-ng.h | grep -v '_state' > capng.h > swig -o capng_wrap.c -python -I. -I../.. -I/usr/include/python3.11 > -I/usr/include/python3.11 ../../../bindings/python3/../src/capng_swig.i > ../../../bindings/python3/../src/capng_swig.i:33: Error: Unknown directive > '%except'. > make[6]: *** [Makefile:878: capng_wrap.c] Error 1 > make[6]: Leaving directory '/<>/build-py3.11/bindings/python3' > make[5]: *** [Makefile:595: all-recursive] Error 1 > make[5]: Leaving directory '/<>/build-py3.11/bindings/python3' > make[4]: *** [Makefile:390: all-recursive] Error 1 > make[4]: Leaving directory '/<>/build-py3.11/bindings' > make[3]: *** [Makefile:441: all-recursive] Error 1 > make[3]: Leaving directory '/<>/build-py3.11' > make[2]: *** [Makefile:373: all] Error 2 > make[2]: Leaving directory '/<>/build-py3.11' I believe upstream has fixed this with [1], I'll take a closer look, hopefully today, and get the package updated. -- Håvard [1] https://github.com/stevegrubb/libcap-ng/commit/30453b6553948cd05c438f9f509013e3bb84f25b
Bug#1063329: libselinux1t64: breaks system in upgrade from unstable
Hi Andreas,
On Wed, Feb 07, 2024 at 03:47:37PM +0100, Andreas Metzler wrote:
> Package: libselinux1t64
> Replaces: libselinux1
> Provides: libselinux1 (= 3.5-2.1~exp1)
> Breaks: libselinux1 (<< 3.5-2.1~exp1)
>
> Afaiui libselinux1t64 must not fullfill dpkg 1.22.4's dependency on
> "libselinux1 (>= 3.1~)". dpkg needs to be rebuilt and the rebuilt
> version gets a dep on "libselinux1t64 (>= 3.5)".
The *t64 libraries only break ABI on some architectures. Notably, on all
64bit architectures, i386 and x32, the ABI will not change. On the next
upload after the transition, library dependencies will move to the t64
variants, yes.
> Will ${t64:Provides} stop expanding to "libselinux1 = ${binary:Version
> for real t64-builds? (The ones in experimental are not.) If that is case
> this bug and this way of testing does not make sense.
No, the t64:Provides will remain that way for all architectures that do
not break ABI. In theory, we could have skipped the rename on those
architectures, but having architecture-dependent package names is
annoyingly hard. Hence, we rename them on e.g. amd64 as well even though
nothing changes there.
Hope this explains
Helmut
Bug#1063398: FTBFS: src/capng_swig.i:33: Error: Unknown directive '%except'
Source: libcap-ng Version: 0.8.4-1 Severity: serious Tags: sid trixie ftbfs Hi, libcap-ng currently FTBFS with the following error: make[6]: Entering directory '/<>/build-py3.11/bindings/python3' cat /usr/include/linux/capability.h | grep '^#define CAP' | grep -v '[()]' > caps.h cat ../../../src/cap-ng.h | grep -v '_state' > capng.h swig -o capng_wrap.c -python -I. -I../.. -I/usr/include/python3.11 -I/usr/include/python3.11 ../../../bindings/python3/../src/capng_swig.i ../../../bindings/python3/../src/capng_swig.i:33: Error: Unknown directive '%except'. make[6]: *** [Makefile:878: capng_wrap.c] Error 1 make[6]: Leaving directory '/<>/build-py3.11/bindings/python3' make[5]: *** [Makefile:595: all-recursive] Error 1 make[5]: Leaving directory '/<>/build-py3.11/bindings/python3' make[4]: *** [Makefile:390: all-recursive] Error 1 make[4]: Leaving directory '/<>/build-py3.11/bindings' make[3]: *** [Makefile:441: all-recursive] Error 1 make[3]: Leaving directory '/<>/build-py3.11' make[2]: *** [Makefile:373: all] Error 2 make[2]: Leaving directory '/<>/build-py3.11'
Bug#1063320: gretl: NMU diff for 64-bit time_t transition
On 6 February 2024 at 06:43, Steve Langasek wrote: | Source: gretl | Version: 2023c-2 | Severity: serious | Tags: patch pending sid trixie | Justification: library ABI skew on upgrade | User: debian-...@lists.debian.org | Usertags: time-t | | NOTICE: these changes must not be uploaded to unstable yet! | | Dear maintainer, | | As part of the 64-bit time_t transition required to support 32-bit | architectures in 2038 and beyond | (https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified | gretl as a source package shipping runtime libraries whose ABI | either is affected by the change in size of time_t, or could not be | analyzed via abi-compliance-checker (and therefore to be on the safe | side we assume is affected). | | To ensure that inconsistent combinations of libraries with their | reverse-dependencies are never installed together, it is necessary to | have a library transition, which is most easily done by renaming the | runtime library package. | | Since turning on 64-bit time_t is being handled centrally through a change | to the default dpkg-buildflags (https://bugs.debian.org/1037136), it is | important that libraries affected by this ABI change all be uploaded close | together in time. Therefore I have prepared a 0-day NMU for gretl | which will initially be uploaded to experimental if possible, then to | unstable after packages have cleared binary NEW. | | Please find the patch for this NMU attached. | | If you have any concerns about this patch, please reach out ASAP. Although | this package will be uploaded to experimental immediately, there will be a | period of several days before we begin uploads to unstable; so if information | becomes available that your package should not be included in the transition, | there is time for us to amend the planned uploads. Thanks, Steve. I applied the patch to my repo and committed to salsa. Gretl updates infrequently enough so that a transition to unstable is very likely to happen before a new upstream. Cheers, Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Processed: Reducing severity to important, see bug 1036884 for justification
Processing commands for cont...@bugs.debian.org: > severity 1062019 important Bug #1062019 [src:davix] davix: NMU diff for 64-bit time_t transition Severity set to 'important' from 'serious' > severity 1062021 important Bug #1062021 [src:dcap] dcap: NMU diff for 64-bit time_t transition Severity set to 'important' from 'serious' > severity 1062038 important Bug #1062038 [src:canl-c] canl-c: NMU diff for 64-bit time_t transition Severity set to 'important' from 'serious' > severity 1062052 important Bug #1062052 [src:cgsi-gsoap] cgsi-gsoap: NMU diff for 64-bit time_t transition Severity set to 'important' from 'serious' > severity 1062109 important Bug #1062109 [src:gfal2] gfal2: NMU diff for 64-bit time_t transition Severity set to 'important' from 'serious' > severity 1062128 important Bug #1062128 [src:gridsite] gridsite: NMU diff for 64-bit time_t transition Severity set to 'important' from 'serious' > severity 1062138 important Bug #1062138 [src:globus-authz-callout-error] globus-authz-callout-error: NMU diff for 64-bit time_t transition Severity set to 'important' from 'serious' > severity 1062139 important Bug #1062139 [src:globus-authz] globus-authz: NMU diff for 64-bit time_t transition Severity set to 'important' from 'serious' > severity 1062140 important Bug #1062140 [src:globus-callout] globus-callout: NMU diff for 64-bit time_t transition Severity set to 'important' from 'serious' > severity 1062141 important Bug #1062141 [src:globus-common] globus-common: NMU diff for 64-bit time_t transition Severity set to 'important' from 'serious' > severity 1062142 important Bug #1062142 [src:globus-ftp-client] globus-ftp-client: NMU diff for 64-bit time_t transition Severity set to 'important' from 'serious' > severity 1062143 important Bug #1062143 [src:globus-ftp-control] globus-ftp-control: NMU diff for 64-bit time_t transition Severity set to 'important' from 'serious' > severity 1062144 important Bug #1062144 [src:globus-gass-cache] globus-gass-cache: NMU diff for 64-bit time_t transition Severity set to 'important' from 'serious' > severity 1062145 important Bug #1062145 [src:globus-gass-copy] globus-gass-copy: NMU diff for 64-bit time_t transition Severity set to 'important' from 'serious' > severity 1062146 important Bug #1062146 [src:globus-gass-server-ez] globus-gass-server-ez: NMU diff for 64-bit time_t transition Severity set to 'important' from 'serious' > severity 1062147 important Bug #1062147 [src:globus-gass-transfer] globus-gass-transfer: NMU diff for 64-bit time_t transition Severity set to 'important' from 'serious' > severity 1062148 important Bug #1062148 [src:globus-gfork] globus-gfork: NMU diff for 64-bit time_t transition Severity set to 'important' from 'serious' > severity 1062149 important Bug #1062149 [src:globus-gram-client] globus-gram-client: NMU diff for 64-bit time_t transition Severity set to 'important' from 'serious' > severity 1062150 important Bug #1062150 [src:globus-gram-job-manager-callout-error] globus-gram-job-manager-callout-error: NMU diff for 64-bit time_t transition Severity set to 'important' from 'serious' > severity 1062151 important Bug #1062151 [src:globus-gram-protocol] globus-gram-protocol: NMU diff for 64-bit time_t transition Severity set to 'important' from 'serious' > severity 1062152 important Bug #1062152 [src:globus-gridftp-server-control] globus-gridftp-server-control: NMU diff for 64-bit time_t transition Severity set to 'important' from 'serious' > severity 1062153 important Bug #1062153 [src:globus-gridftp-server] globus-gridftp-server: NMU diff for 64-bit time_t transition Severity set to 'important' from 'serious' > severity 1062154 important Bug #1062154 [src:globus-gridmap-callout-error] globus-gridmap-callout-error: NMU diff for 64-bit time_t transition Severity set to 'important' from 'serious' > severity 1062155 important Bug #1062155 [src:globus-gsi-callback] globus-gsi-callback: NMU diff for 64-bit time_t transition Severity set to 'important' from 'serious' > severity 1062156 important Bug #1062156 [src:globus-gsi-cert-utils] globus-gsi-cert-utils: NMU diff for 64-bit time_t transition Severity set to 'important' from 'serious' > severity 1062157 important Bug #1062157 [src:globus-gsi-credential] globus-gsi-credential: NMU diff for 64-bit time_t transition Severity set to 'important' from 'serious' > severity 1062158 important Bug #1062158 [src:globus-gsi-openssl-error] globus-gsi-openssl-error: NMU diff for 64-bit time_t transition Severity set to 'important' from 'serious' > severity 1062159 important Bug #1062159 [src:globus-gsi-proxy-core] globus-gsi-proxy-core: NMU diff for 64-bit time_t transition Severity set to 'important' from 'serious' > severity 1062160 important Bug #1062160 [src:globus-gsi-sysconfig] globus-gsi-sysconfig: NMU diff for 64-bit time_t transition Severity set to 'important' from 'serious' > severity 1062161 important Bug #1062161 [src:globus-gss-assist] globus-gss-assist: NMU dif
Bug#1062364: dieharder: NMU diff for 64-bit time_t transition
On 1 February 2024 at 07:21, mwhud...@debian.org wrote: | Source: dieharder | Version: 3.31.1.4-1 | Severity: serious | Tags: patch pending | Justification: library ABI skew on upgrade | User: debian-...@lists.debian.org | Usertags: time-t | | Dear maintainer, | | As part of the 64-bit time_t transition required to support 32-bit | architectures in 2038 and beyond | (https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified | dieharder as a source package shipping runtime libraries whose ABI | either is affected by the change in size of time_t, or could not be | analyzed via abi-compliance-checker (and therefore to be on the safe | side we assume is affected). | | To ensure that inconsistent combinations of libraries with their | reverse-dependencies are never installed together, it is necessary to | have a library transition, which is most easily done by renaming the | runtime library package. | | Since turning on 64-bit time_t is being handled centrally through a change | to the default dpkg-buildflags (https://bugs.debian.org/1037136), it is | important that libraries affected by this ABI change all be uploaded close | together in time. Therefore I have prepared a 0-day NMU for dieharder | which will initially be uploaded to experimental if possible, then to | unstable after packages have cleared binary NEW. | | Please find the patch for this NMU attached. | | If you have any concerns about this patch, please reach out ASAP. Although | this package will be uploaded to experimental immediately, there will be a | period of several days before we begin uploads to unstable; so if information | becomes available that your package should not be included in the transition, | there is time for us to amend the planned uploads. Been meaning to say thanks for the patch and PR since I saw it bubble up late last week. I just applied it to my repo and pushed it. Thanks again, Dirk | -- System Information: | Debian Release: trixie/sid | APT prefers unstable | APT policy: (500, 'unstable'), (1, 'experimental') | Architecture: amd64 (x86_64) | | Kernel: Linux 6.5.0-15-generic (SMP w/16 CPU threads; PREEMPT) | Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE | Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set | Shell: /bin/sh linked to /usr/bin/dash | Init: systemd (via /run/systemd/system) | x[DELETED ATTACHMENT nmu_dieharder.debdiff, plain text] -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1063329: libselinux1t64: breaks system in upgrade from unstable
On 2024-02-06 Helmut Grohne wrote:
> Package: libselinux1t64
[...]> This looks fairly innocuous. We create a minimal sid chroot and install
> libselinux1t64 using apt. What could possibly go wrong? Well, apt thinks
> that it would be a good idea to avoid coinstalling breaking packages and
> first removes libselinux1 before proceeding to install libselinux1t64.
> Unfortunately, libselinux1 is transitively essential and dpkg links it,
[...]
> both dpkg and tar are now broken. This is pretty bad. To make matters
> worse, the situation arises from the combination of Breaks + Provides
[...]
Hello,
color me stupid but isn't this fishy?
Package: libselinux1t64
Replaces: libselinux1
Provides: libselinux1 (= 3.5-2.1~exp1)
Breaks: libselinux1 (<< 3.5-2.1~exp1)
Afaiui libselinux1t64 must not fullfill dpkg 1.22.4's dependency on
"libselinux1 (>= 3.1~)". dpkg needs to be rebuilt and the rebuilt
version gets a dep on "libselinux1t64 (>= 3.5)".
Will ${t64:Provides} stop expanding to "libselinux1 = ${binary:Version
for real t64-builds? (The ones in experimental are not.) If that is case
this bug and this way of testing does not make sense.
Otherwise the plan looks flawed.
cu Andreas
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
Bug#1062427: ghmm: NMU diff for 64-bit time_t transition
Hi Lukas, Am Thu, Feb 01, 2024 at 11:27:43AM +0100 schrieb Lukas Märdian: > please note that ghmm seems to FTBFS for a reason unrelated to this NMU: > > dh_install > dh_install: warning: Cannot find (any matches for) > "usr/lib/python3*/site-packages/*" (tried in ., debian/tmp) > > dh_install: warning: ghmm missing files: usr/lib/python3*/site-packages/* > dh_install: error: missing files, aborting > make[1]: *** [debian/rules:15: override_dh_install] Error 255 > make[1]: Leaving directory '/home/slyon/time_t/ghmm-0.9~rc3' > make: *** [debian/rules:9: binary] Error 2 > dpkg-buildpackage: error: debian/rules binary subprocess returned exit status > 2 > > > The python files seem to be generated in wrong directory (see tree below). The uploaded package was lagging quite behind packaging in Git. Since I was able to upload a fixed package to unstable today I applied all your changes in another upload to experimental which I "sponsored" for you as ghmm_0.9~rc3-5.1~exp. Hope this contributes a bit to all your huge work for the time_t transition. Kind regards and thanks a lot for your work Andreas. PS: In case you notice in tracker.debian.org that "version in VCS is newer than in repository, is it time to upload?" is set it might be useful to contact the maintainers of the package. -- http://fam-tille.de
Bug#1063393: systemd FTBFS with nocheck build profile: ../meson.build:1810:33: ERROR: Feature ukify cannot be enabled: Python >= 3.9 and pefile required
Source: systemd Version: 255.3-1 Severity: serious Tags: ftbfs trixie sid Hi, systemd fails to build from source when built with the nocheck build profile. Since trixie, such a failure is considered release-critical. The notable message probably is: | ../meson.build:1810:33: ERROR: Feature ukify cannot be enabled: Python >= 3.9 and pefile required I guess your python3-pefile dependency should not be tagged and it should probably be annotated :native until it becomes M-A:foreign. Helmut
Bug#1063392: zfsutils-linux has an undeclared file conflict on /usr/bin/arcstat
Package: zfsutils-linux Version: 2.2.2-5~exp2 Severity: serious User: debian...@lists.debian.org Usertags: fileconflict Control: affects -1 + nordugrid-arc-client zfsutils-linux has an undeclared file conflict. This may result in an unpack error from dpkg. The file /usr/bin/arcstat is contained in the packages * nordugrid-arc-client * 6.10.2-1 as present in bullseye * 6.17.0-3 as present in bookworm * 6.18.0-1 as present in trixie|unstable * zfsutils-linux/2.2.2-5~exp2 as present in experimental These packages can be unpacked concurrently, because there is no relevant Replaces or Conflicts relation. Attempting to unpack these packages concurrently results in an unpack error from dpkg, because none of the packages installs a diversion for the affected file. Kind regards The Debian Usr Merge Analysis Tool This bug report has been automatically filed with no human intervention. The source code is available at https://salsa.debian.org/helmutg/dumat. If the filing is unclear or in error, don't hesitate to contact hel...@subdivi.de for assistance.
Processed: zfsutils-linux has an undeclared file conflict on /usr/bin/arcstat
Processing control commands: > affects -1 + nordugrid-arc-client Bug #1063392 [zfsutils-linux] zfsutils-linux has an undeclared file conflict on /usr/bin/arcstat Added indication that 1063392 affects nordugrid-arc-client -- 1063392: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1063392 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1061752: Opened MR
Hi, I opened a MR to fix the issue. I can also prepare an upload if wanted. https://salsa.debian.org/python-team/packages/python-django-tagging/-/merge_requests/3 Thanks, Alex
Processed: tagging 1061752
Processing commands for cont...@bugs.debian.org: > tags 1061752 + patch Bug #1061752 [src:python-django-tagging] python-django-tagging ftbfs with Python 3.12 as default Added tag(s) patch. > thanks Stopping processing here. Please contact me if you need assistance. -- 1061752: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1061752 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1060964: marked as done (python-pure-sasl: FTBFS: tests failed)
Your message dated Wed, 07 Feb 2024 12:35:06 + with message-id and subject line Bug#1060964: fixed in python-pure-sasl 0.5.1+dfsg1-4 has caused the Debian Bug report #1060964, regarding python-pure-sasl: FTBFS: tests failed to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 1060964: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1060964 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Source: python-pure-sasl Version: 0.5.1+dfsg1-3 Severity: serious Justification: FTBFS Tags: trixie sid ftbfs User: lu...@debian.org Usertags: ftbfs-20240115 ftbfs-trixie Hi, During a rebuild of all packages in sid, your package failed to build on amd64. Relevant part (hopefully): > make[1]: Entering directory '/<>' > make[1]: pyversions: No such file or directory > py3versions: no X-Python3-Version in control file, using supported versions > pkgos-dh_auto_install --no-py2 --in-tmp > + PKGOS_IN_TMP=no > + echo WARNING: --no-py2 is deprecated and always on. > WARNING: --no-py2 is deprecated and always on. > + shift > + PKGOS_IN_TMP=yes > + shift > + dpkg-parsechangelog -SSource > + SRC_PKG_NAME=python-pure-sasl > + echo python-pure-sasl > + sed s/python-// > + PY_MODULE_NAME=pure-sasl > + py3versions -vr > + PYTHON3S=3.12 3.11 > + [ yes = yes ] > + TARGET_DIR=tmp > + pwd > + python3.12 setup.py install --install-layout=deb --root > /<>/debian/tmp > running install > /usr/lib/python3/dist-packages/setuptools/_distutils/cmd.py:66: > SetuptoolsDeprecationWarning: setup.py install is deprecated. > !! > > > > Please avoid running ``setup.py`` directly. > Instead, use pypa/build, pypa/installer or other > standards-based tools. > > See https://blog.ganssle.io/articles/2021/10/setup-py-deprecated.html > for details. > > > > !! > self.initialize_options() > running build > running build_py > creating build > creating build/lib > creating build/lib/puresasl > copying puresasl/__init__.py -> build/lib/puresasl > copying puresasl/mechanisms.py -> build/lib/puresasl > copying puresasl/client.py -> build/lib/puresasl > running install_lib > creating /<>/debian/tmp > creating /<>/debian/tmp/usr > creating /<>/debian/tmp/usr/lib > creating /<>/debian/tmp/usr/lib/python3 > creating /<>/debian/tmp/usr/lib/python3/dist-packages > creating /<>/debian/tmp/usr/lib/python3/dist-packages/puresasl > copying build/lib/puresasl/__init__.py -> > /<>/debian/tmp/usr/lib/python3/dist-packages/puresasl > copying build/lib/puresasl/mechanisms.py -> > /<>/debian/tmp/usr/lib/python3/dist-packages/puresasl > copying build/lib/puresasl/client.py -> > /<>/debian/tmp/usr/lib/python3/dist-packages/puresasl > byte-compiling > /<>/debian/tmp/usr/lib/python3/dist-packages/puresasl/__init__.py > to __init__.cpython-312.pyc > byte-compiling > /<>/debian/tmp/usr/lib/python3/dist-packages/puresasl/mechanisms.py > to mechanisms.cpython-312.pyc > byte-compiling > /<>/debian/tmp/usr/lib/python3/dist-packages/puresasl/client.py > to client.cpython-312.pyc > running install_egg_info > running egg_info > creating pure_sasl.egg-info > writing pure_sasl.egg-info/PKG-INFO > writing dependency_links to pure_sasl.egg-info/dependency_links.txt > writing requirements to pure_sasl.egg-info/requires.txt > writing top-level names to pure_sasl.egg-info/top_level.txt > writing manifest file 'pure_sasl.egg-info/SOURCES.txt' > reading manifest file 'pure_sasl.egg-info/SOURCES.txt' > reading manifest template 'MANIFEST.in' > adding license file 'LICENSE' > writing manifest file 'pure_sasl.egg-info/SOURCES.txt' > Copying pure_sasl.egg-info to > /<>/debian/tmp/usr/lib/python3/dist-packages/pure_sasl-0.5.1.egg-info > Skipping SOURCES.txt > running install_scripts > + pwd > + python3.11 setup.py install --install-layout=deb --root > /<>/debian/tmp > running install > /usr/lib/python3/dist-packages/setuptools/_distutils/cmd.py:66: > SetuptoolsDeprecationWarning: setup.py install is deprecated. > !! > > > > Please avoid running ``setup.py`` directly. > Instead, use pypa/build, pypa/installer or other > standards-based tools. > > See https://blog.ganssle.io/articles/2021/10/setup-py-deprecated.html > for details. > > > > !! > sel
Processed: severity of 1062567 is important
Processing commands for cont...@bugs.debian.org: > severity 1062567 important Bug #1062567 [src:libpg-query] libpg-query: NMU diff for 64-bit time_t transition Severity set to 'important' from 'serious' > thanks Stopping processing here. Please contact me if you need assistance. -- 1062567: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1062567 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1062462: [Pkg-tcltk-devel] Bug#1062462: itk3: NMU diff for 64-bit time_t transition
Hi Graham, On Thu, Feb 1, 2024 at 6:57 PM Graham Inggs wrote: > > Source: itk3 > Version: 3.4.2-3.1 > Severity: serious > Tags: patch pending > Justification: library ABI skew on upgrade > User: debian-...@lists.debian.org > Usertags: time-t > > Dear maintainer, > > As part of the 64-bit time_t transition required to support 32-bit > architectures in 2038 and beyond > (https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified > itk3 as a source package shipping runtime libraries whose ABI > either is affected by the change in size of time_t, or could not be > analyzed via abi-compliance-checker (and therefore to be on the safe > side we assume is affected). Can you elaborate how exactly you determined that itk3 is affected by time_t size change? As far as I can see in the sources, it doesn't use time_t at all. Cheers! -- Sergei Golovan
Bug#1062461: [Pkg-tcltk-devel] Bug#1062461: itcl3: NMU diff for 64-bit time_t transition
Hi Graham, On Thu, Feb 1, 2024 at 6:57 PM Graham Inggs wrote: > > Source: itcl3 > Version: 3.4.4-2 > Severity: serious > Tags: patch pending > Justification: library ABI skew on upgrade > User: debian-...@lists.debian.org > Usertags: time-t > > Dear maintainer, > > As part of the 64-bit time_t transition required to support 32-bit > architectures in 2038 and beyond > (https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified > itcl3 as a source package shipping runtime libraries whose ABI > either is affected by the change in size of time_t, or could not be > analyzed via abi-compliance-checker (and therefore to be on the safe > side we assume is affected). Can you elaborate how exactly you determined that itcl3 is affected by time_t size change? As far as I can see in the sources, it doesn't use time_t at all. Cheers! -- Sergei Golovan
Bug#1063329: libselinux1t64: breaks system in upgrade from unstable
Hi Guillem,
On Wed, Feb 07, 2024 at 04:32:45AM +0100, Guillem Jover wrote:
> Yes, I'm not sure I understand either. This is what symbol versioning
> makes possible, even providing different variants for the same symbol,
> see for example glibc or libbsd.
I think symbol versioning is subtly different and glibc does not use
symbol versioning for e.g. gettimeofday selection. With symbol
versioning, you select a default version at release time and stick to
it. In other words, building against the updated libselinux does not
allow you to use the older 32bit variant of the symbol even if you opt
out of lfs and time64 and you always get the 64bit symbol. What glibc
does is a little more fancy than my simplistic #define in that it uses
asm("name") instead. Still this approach allows for selecting which
symbol is being used via macros (e.g. _FILE_OFFSET_BITS). Please correct
me if I am misrepresenting this as my experience with symbol versioning
is fairly limited.
> In any case, if going the bi-ABI path, I think upstream should get
> involved, and the shape of this decided with them. In addition
> the library should also be built with LFS by the upstream build
> system, which it does not currently, to control its ABI.
I agree that involving upstream is a good idea and my understanding is
that someone from Canonical is doing that already, which is why the
schedule was delayed.
My real question here though is what's the downsides of providing two
variants of this symbol (whether with symbol versioning or name
redirection). From my pov, this effectively is your option 3 and what I
sketched is the most stupid implementation of it. My sketch did assume
that libselinux would be built with LFS support everywhere including
i386. Enabling that on the upstream side definitely is even better,
because it gets us to not have a Debian-specific ABI.
> I think there are only three ways to go about this, excluding the t64
> attempt:
Thanks for confirming that I've reported a real problem.
> If you'd like assistance with trying to get a proposal for 3 to
> present upstream I could look into that. But I think they should be
> involved early on to see what they'd like to see and what they might
> outright reject.
>From my naive point of view, this option 3 is the clear winner. Though
it all depends on what upstream says. If upstream cooperates on any
option, that's better still as we avoid ABI deviation.
Going from here, I also looked a bit into whether we could additionally
use an upstream-cooperating approach for other packages central to
Debian to avoid t64 bumps.
pam seems difficult:
| extern time_t pam_misc_conv_warn_time; /* time that we should warn user */
| extern time_t pam_misc_conv_die_time; /* cut-off time for input */
We cannot symbol-version these in a reasonable way. All we could do is
ask upstream for a real soname bump. We have a slight advantage here: On
little endian (such as armhf), we can extend this to 64bit and 32bit
accesses will continue to work for small values. However, doing this to
m68k would break horribly. I also couldn't find any in-Debian users of
these symbols (super merely vendors pam source), so just bumping it and
accepting breakage (Guillems option 1) might be worth a go?
For libaudit1, I fail to understand why we bump it at all. Both reports
look fine to me:
https://adrien.dcln.fr/misc/armhf-time_t/2024-02-01T09:53:00/compat_reports/libaudit-dev/base_to_lfs/compat_report.html
https://adrien.dcln.fr/misc/armhf-time_t/2024-02-01T09:53:00/compat_reports/libaudit-dev/lfs_to_time_t/compat_report.html
This does not extend to libauparse0 where the report gives a reason, but
libaudit1 is the one that interacts with /usr-move and libauparse0 not,
so can we skip the dance for libaudit1?
For libtirpc, it is only about rpcb_gettime, which returns time via a
time_t* and can indicate success/failure via return. It seems fairly
simple to implement ABI duality here and libtirpc already does symbol
versioning. Maybe we can also approach upstream about this?
For libfuse2, I think the ABI analysis is broken. The base-to-lfs report
supposedly is ok
https://adrien.dcln.fr/misc/armhf-time_t/2024-02-01T09:53:00/compat_reports/libfuse-dev/base_to_lfs/compat_report.html
and then going lfs-to-time changes ino_t
https://adrien.dcln.fr/misc/armhf-time_t/2024-02-01T09:53:00/compat_reports/libfuse-dev/lfs_to_time_t/compat_report.html
while I would have expected ino_t to change with lfs already. Are we
sure about this? In any case, this is more of an academic question as
adding ABI-duality would be more involved here. Moreover, I don't see
any ACC report for libfuse3-dev. Did that fail to analyze?
libiw30 only has one affected symbol:
iw_print_timeval ( char* buffer, int buflen, struct timeval const* time, struct
timezone const* tz )
Providing ABI duality for this seems doable. Moreover, libiw30 already
has soname 30, so maybe upstream is open to bumping it again? The
resulting library transition is f
Bug#1063061: mosquitto: autopkgtest needs update for new version of gcc-defaults on armel: max_connections exceeded
Hi, On 2024-02-04 08:47, Paul Gevers wrote: > With a recent upload of gcc-defaults the autopkgtest of mosquitto fails in > testing when that autopkgtest is run with the binary packages of > gcc-defaults from unstable on armel. It passes when run with only packages > from testing. In tabular form: > >passfail > gcc-defaults from testing1.214 > mosquitto from testing2.0.18-1 > all others from testingfrom testing It seems that this was a transient failure, and gcc-defaults 1.214 has meanwhile migrated to testing.
Processed: Re: ruby-faraday-middleware fails to rebuild after updating ruby-faraday
Processing control commands: > severity -1 serious Bug #1025092 [ruby-faraday-middleware] ruby-faraday-middleware fails to rebuild after updating ruby-faraday Severity set to 'serious' from 'important' -- 1025092: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1025092 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: Re: ruby-graphlient fails to rebuild after updating ruby-faraday to upstream
Processing control commands: > severity -1 serious Bug #1025084 [ruby-graphlient] ruby-graphlient fails to rebuild after updating ruby-faraday to upstream Severity set to 'serious' from 'important' -- 1025084: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1025084 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1061972: gap: NMU diff for 64-bit time_t transition
Am 06.02.24 um 14:22 schrieb Bill Allombert: On Thu, Feb 01, 2024 at 04:07:38PM +0100, Lukas Märdian wrote: thanks for the heads-up! The same debdiff should apply to the version in unstable (4.12.1). We'll make sure to NMU the version from unstable. Waiting for libgap.so.9 would also be an option, if timing works out. Fortunately libgap.so.9 was prereleased today. Would that mess anything if I upload it to experimental ? I expect not. It should be fine to upload this into experimental. Ideally, you would hold back with uploading it into unstable until the time_t transition started in there, too. Otherwise, we'd need to rebase the NMU patch on top of libgap9 once the transition starts in unstable. -- Lukas
Bug#1062821: ola: NMU diff for 64-bit time_t transition
On Wed, Feb 07, 2024 at 09:47:10AM +0200, Wouter Verhelst wrote:
> Hi Lucas,
>
> On Sat, Feb 03, 2024 at 02:39:49PM -0300, Lucas Kanashiro wrote:
> > Source: ola
> > Version: 0.10.9.nojsmin-4
> > Severity: serious
> > Tags: patch pending sid trixie
> > Justification: library ABI skew on upgrade
> > User: debian-...@lists.debian.org
> > Usertags: time-t
> >
> > NOTICE: these changes must not be uploaded to unstable yet!
> >
> > Dear maintainer,
> >
> > As part of the 64-bit time_t transition required to support 32-bit
> > architectures in 2038 and beyond
> > (https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified
> > ola as a source package shipping runtime libraries whose ABI
> > either is affected by the change in size of time_t, or could not be
> > analyzed via abi-compliance-checker (and therefore to be on the safe
> > side we assume is affected).
>
> Would it make sense for me to contact upstream and ask if they do
> certain things? They're quite knowledgeable and might know.
>
> If not, then no worries, but I thought I'd ask.
nvm, just read the d-d-a mail :-)
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
I will have a Tin-Actinium-Potassium mixture, thanks.
