Bug#1080126: marked as pending in python-applicationinsights
Control: tag -1 pending Hello, Bug #1080126 in python-applicationinsights 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/python-team/packages/python-applicationinsights/-/commit/d02d943c9abcc40214a96da1a204d79b1be02570 Build-depend on python3-django for unit tests Closes: #1080126 (this message was generated automatically) -- Greetings https://bugs.debian.org/1080126
Bug#1080126: marked as pending in python-applicationinsights
Control: tag -1 pending Hello, Bug #1080126 in python-applicationinsights 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/python-team/packages/python-applicationinsights/-/commit/d02d943c9abcc40214a96da1a204d79b1be02570 Build-depend on python3-django for unit tests Closes: #1080126 (this message was generated automatically) -- Greetings https://bugs.debian.org/1080126
Bug#1078721: iproute2: removing /sbin/ip link breaks other packages and possibly user scripts
Control: reassign -1 vlan 2.0.5+nmu2 Control: tags -1 patch On Wed, 14 Aug 2024 15:35:56 -0400 Michael Stone wrote: > Package: iproute2 > Version: 6.10.0-1 > Severity: critical > Justification: breaks the whole system > > The first time I rebooted after iproute2 removed the /sbin/ip link, my system > failed to boot. I eventually discovered this was because /sbin/vconfig (from > the "vlan" package) calls /sbin/ip and when that failed the network was not > configured. This meant having to boot into single user mode for diagnostics > because systemd hung forever waiting for the network. This change was noted in NEWS. I would suggest hooking your config into something that uses the network-online.target target, with a timeout like network-manager and networkd do, so that the boot process doesn't hang. If it's a simple unit, it's enough to add RuntimeMaxSec= to it, so that it's killed if it doesn't work within the configured timeout. Patch for vlan sent at: https://salsa.debian.org/debian/vlan/-/merge_requests/3 -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1064408: marked as pending in live-build
Control: tag -1 pending Hello, Bug #1064408 in live-build 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/live-team/live-build/-/commit/0eb97d9c367811f94ce2206ab510182f08b44310 duplicate aliased diversions for DEP17 /bin/hostname and /sbin/start-stop-daemon are being moved from / to /usr in trixie. Hence, these diversions become ineffective. Temporarily add both diversions to handle both variants. Closes: #1064408 (this message was generated automatically) -- Greetings https://bugs.debian.org/1064408
Bug#1064408: [PATCH] duplicate aliased diversions for DEP17
Control: tags -1 pending On Wed, 21 Feb 2024 18:04:17 +0100 Helmut Grohne wrote: > Package: live-build > Versrion: 1:20230502 > User: helm...@debian.org > Usertags: dep17p3 > Tags: patch > > /bin/hostname and /sbin/start-stop-daemon are being moved from / to /usr > in trixie. Hence, these diversions become ineffective. Temporarily add > both diversions to handle both variants. > --- > scripts/build/chroot_dpkg | 15 --- > scripts/build/chroot_hostname | 17 + > 2 files changed, 25 insertions(+), 7 deletions(-) > > I note that while live-build has MRs on salsa, I cannot seem to create > one. Hence sending a patch via bugs.d.o. > > diff --git a/scripts/build/chroot_dpkg b/scripts/build/chroot_dpkg > index c43c0eb01..d64820f72 100755 > --- a/scripts/build/chroot_dpkg > +++ b/scripts/build/chroot_dpkg > @@ -38,8 +38,14 @@ case "${_ACTION}" in > Acquire_lockfile > > # Create custom start-stop-daemon program > - Chroot chroot dpkg-divert --rename --quiet --add > /sbin/start-stop-daemon > - ln -fs /bin/true chroot/sbin/start-stop-daemon > + Chroot chroot dpkg-divert --rename --quiet --add > /usr/sbin/start-stop-daemon > + # begin-remove-after: released:trixie > + # In the bookworm to trixie upgrade, dpkg moves > + # start-stop-daemon from /sbin to /usr/sbin. Duplicate the > + # diversion to cover both. DEP17 P3 M18 > + Chroot chroot dpkg-divert --rename --quiet --add --divert > /sbin/start-stop-daemon.distrib.usr-is-merged This is missing the second positional parameter (/sbin/start-stop- daemon), but after fixing that it seems to work, so I'll upload a fixed version shortly -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1078115: azure-cli - fails to get access token: User 'X' does not exist in MSAL token cache
Control: severity -1 minor Control: reassign -1 microsoft-authentication-extensions-for-python On Wed, 7 Aug 2024 10:18:59 +0200 Bastian Blank wrote: > Control: severity -1 serious > > On Wed, Aug 07, 2024 at 09:59:06AM +0200, Bastian Blank wrote: > > With a brand new config and after using "az login" to login with exactly > > the mentioned user, this now fails with: > > | % az account get-access-token > > | User 'wa...@spi-inc.org' does not exist in MSAL token cache. Run `az login`. > > | % grep waldi@spi ~/.azure/msal_token_cache.json > > | "username": "wa...@spi-inc.org", > > Okay, this problem is fixed in > https://github.com/AzureAD/microsoft-authentication-extensions-for-python/commit/6fd4920f20ab36263a55ad228c432265f8d2f2eb > and released with python-msal-extensions 1.2.0. What a shitshow. > > In a nut shell: the token cache changed function namens from find to > search. msal_extensions 1.1.0 wraps "find" to actually read the token > cache, but azure-cli uses "search". Sigh they tag their betas as "1.2.0b1" so uscan on ddpo doesn't show that 1.2.0 was actually released and it looked like it was still in beta -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1065832: marked as pending in azure-cli
Control: tag -1 pending Hello, Bug #1065832 in azure-cli 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/python-team/packages/azure-cli/-/commit/07f7a76847677c64991b22d9052e38160bcf78ac Drop python3-distutils dependency Closes: #1065832 (this message was generated automatically) -- Greetings https://bugs.debian.org/1065832
Bug#1075772: marked as pending in openconnect
Control: tag -1 pending Hello, Bug #1075772 in openconnect 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/openconnect/-/commit/42eb7b6b00f6ed1feabfeb0c759c5c33ccdafc4a Disable autopkgtest and remove test build dependencies Dependencies for tests have been removed due to various armv7 bugs so they are no longer available in testing, disable all tests Closes: #1075772 (this message was generated automatically) -- Greetings https://bugs.debian.org/1075772
Bug#1077271: systemd broken after 256.4-2 upgrade
Control: severity -1 minor Control: tags -1 unreproducible moreinfo On Sat, 27 Jul 2024 18:16:36 + Richard B wrote: > Jul 27 11:41:44 fw13 systemd[1]: Failed to fork off sandboxing environment > for executing generators: Protocol error > Jul 27 11:41:45 fw13 systemd[1]: Freezing execution. Something on your system is blocking namespaces, you will need to figure out what it is and why -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1077184: systemd: /etc/sysctl.conf is no longer read
Control: severity -1 wishlist Control: tags -1 wontfix Control: close -1 On Fri, 26 Jul 2024 15:00:17 +0200 Vincent Lefevre wrote: > Package: systemd > Version: 256.4-2 > Severity: grave > Tags: security > Justification: user security hole > X-Debbugs-Cc: Debian Security Team > > The /etc/sysctl.conf file is no longer read, while I have security > settings there. > > I suspect that the cause is > > * Drop /etc/sysctl.d/99-sysctl.conf symlink procps no longer ships > /etc/sysctl.conf (Closes: #1076190) > > which is wrong! It is not, create the symlink yourself if you still need it, the procps package dropped it so this package dropped it as well -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#981937: dh-sysuser: Reduce negative impact and assess overall utility
Control: tags 981799 -moreinfo Control: tags 981799 patch Control: severity 981799 serious Control: severity 981937 serious On Fri, 28 Jun 2024 00:44:01 +0200 lorenzo wrote: > > That cycle has happened. How about removing it now? > I'm open to consider further changes but the removal request > is a wontfix. > > Lorenzo We have now finished painstakingly removing dh-sysuser usage from all packages in the archive, bar runit which is maintaned by the dh-sysuer maintainer, for which a patch has been available in #981799 for 3 years now. With Trixie's cycle coming to an end soon-ish, it is now time to either apply the provided runit patch, or alternatively merge whatever remains of dh-sysuser inside runit so that it can continue to use it individually, without it being available for other packages in the archive and being mistakenly picked up again. Having competing packaging APIs is confusing and detrimental to the project. The standard interface the project has adopted for declarative user/group creation is dh_installsysusers provided by debhelper. Having a similarly named API, that is incompatible, does not actually use the sysuser.d interface despite being named after it, and does not provide the same advantages, is confusing for developers who might pick it by mistake, and leads to needless divergence and bugs. Hence I am bumping the severity of both bugs to serious, so that this does not ship in Trixie. Please apply the suggested change, or an equivalent one, in runit, and then please file an RM bug for dh- sysuser. Thank you. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1069425: socket_wrapper and the time_t 64-bit is hard
On Mon, 29 Apr 2024 13:03:22 +1200 Andrew Bartlett wrote: > Just a warning that trying to brute force a fix for this is likely to > end badly. A lot of developer time was spent to get to this current > delicate situation, which relied on the narrow behaviour that is now > eliminated by the Debian time_t 64 transition rules. > > Socket-wrapper starts with: > > /* > * Make sure we do not redirect (f)open(at)() or fcntl() to their 64bit > * variants > */ > #undef _FILE_OFFSET_BITS > > This was added in > https://gitlab.com/cwrap/socket_wrapper/-/commit/bbe14cc3200ca553b13ed49357e2e88ba487eeaa > > Setting -D_FILE_OFFSET_BITS=64 will break the fcntl64 wrapper and so > break Samba's tests. > > I don't know if there is a good fix for this actually. > > Andrew Bartlett How about simply dropping armv7 support from socket-wrapper and uid- wrapper? Having architectures that are actually used being blocked by these issues is suboptimal at best -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1076127: (build-)dependency on removed python3-distutils
Control: tags -1 moreinfo upstream Control: severity -1 wishlist On Thu, 11 Jul 2024 08:08:05 +0200 Matthias Klose wrote: > Source: azure-cli > Version: 2.62.0-1 > Severity: serious > Tags: sid trixie > User: debian-pyt...@lists.debian.org > Usertags: python3.12 > > there are (build-)dependency on the now removed python3-distutils. > please remove them It's a runtime dependency, and it is still used, so it cannot just be removed. Have you file an upstream issue, or better yet, sent a PR upstream to provide an alternative? -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1073360: marked as pending in fabric
Control: tag -1 pending Hello, Bug #1073360 in fabric 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/python-team/packages/fabric/-/commit/d878371730cb80ba803c24a22cde8f69403ce5c9 Add build dependency on python3-six for tests Closes: #1073360 (this message was generated automatically) -- Greetings https://bugs.debian.org/1073360
Bug#1042969: vsftpd: Deletes the ftp user on remove, breaking other packages
Control: tags -1 pending On Thu, 03 Aug 2023 08:54:40 -0500 John Goerzen wrote: > Package: vsftpd > Version: 3.0.3-13+b2 > Severity: critical > Justification: breaks unrelated software > > On removing this package, it indiscriminately removes the ftp user. > Unfortunately, that user was required for iksd in package ckermit to work, so > this broke the unrelated ckermit package. > > It is likely that there are other packages and users that would also > use the ftp user. It should not be removed on package removal. Given this will cause the autoremoval of several of my packages, I've NMU'ed to DELAYED/7 with a fix to stop removing the ftp user/group in the postinst. debdiff attached. -- Kind regards, Luca Boccassi diff -Nru vsftpd-3.0.3/debian/changelog vsftpd-3.0.3/debian/changelog --- vsftpd-3.0.3/debian/changelog 2021-03-03 21:05:45.0 + +++ vsftpd-3.0.3/debian/changelog 2024-07-07 13:39:11.0 +0100 @@ -1,3 +1,10 @@ +vsftpd (3.0.3-13.1) unstable; urgency=medium + + * Non-maintainer upload. + * Stop removing ftp user/group on removal (Closes: #1042969) + + -- Luca Boccassi Sun, 07 Jul 2024 13:39:11 +0100 + vsftpd (3.0.3-13) unstable; urgency=medium [Frey Daniel] diff -Nru vsftpd-3.0.3/debian/vsftpd.postrm vsftpd-3.0.3/debian/vsftpd.postrm --- vsftpd-3.0.3/debian/vsftpd.postrm 2015-03-03 17:40:36.0 + +++ vsftpd-3.0.3/debian/vsftpd.postrm 2024-07-07 13:39:07.0 +0100 @@ -23,22 +23,8 @@ case "${1}" in remove) - _USERNAME="ftp" - _GROUPNAME="${_USERNAME}" _DIRECTORY="/srv/ftp" - pathfind deluser - if [ $? = 0 ] ; - then - deluser --quiet --system ${_USERNAME} - fi - - pathfind delgroup - if [ $? = 0 ] ; - then - delgroup --quiet --system --only-if-empty ${_GROUPNAME} || true - fi - if [ -d "${_DIRECTORY}" ] then rmdir --ignore-fail-on-non-empty "${_DIRECTORY}" || true signature.asc Description: This is a digitally signed message part
Bug#1073922: marked as pending in systemd
Control: tag -1 pending Hello, Bug #1073922 in systemd 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/systemd-team/systemd/-/commit/e220ce22f11e344910ef82c5a07b1c033ec66a6d Bump breaks/replaces to conflicts for DEP17 Breaks/replaces are not enough when moving files between packages and between locations as per DEP17, so bump to Conflicts. Closes: #1073922 (this message was generated automatically) -- Greetings https://bugs.debian.org/1073922
Bug#1073922: systemd-{container,cryptsetup,repart}: ineffective Replaces due to /usr-move (DEP17)
Control: tags -1 -patch Control: tags -1 pending On Fri, 21 Jun 2024 12:30:25 +0200 Helmut Grohne wrote: > Control: reassign -1 systemd-container,systemd-cryptsetup,systemd- repart > Control: found -1 systemd/256.1-1 > Control: tags -1 + patch > > On Thu, Jun 20, 2024 at 10:58:23AM +0200, Helmut Grohne wrote: > > Package: systemd-container,systemd-cryptsetup,cryptsetup-repart > > Fixed bad package cryptsetup-repart. > > > Let me not go into details of this problem just yet and just install > > this bug as a temporary migration blocker. I shall have an update within > > three working days, ideally with a patch. Thanks for your patience. > > The recurring theme is that systemd moved all of its files from / to > /usr (expected via DEP17) and now moves components from the main systemd > package into systemd-container, systemd-cryptsetup and systemd- repart. > In all of these cases, affected files may be lost in upgrades from > either bookworm or bookworm-backports to unstable and eventually trixie. > Users upgrading from trixie to sid, will likely not experience loss > unless they skip systemd versions. > > There are multiple mitigation techniques available. Upgrading > Breaks+Replaces to Conflicts provides a relatively strong protection as > long as one uses an apt-based package management tool. However, the CTTE > advised that packages relevant to booting a system should also be safe > when installing packages directly with dpkg and in that scenario, > Conflicts are insufficient, because dpkg allows a conflicting package to > be unpacked before the conflicted package is removed to facilitate a > smooth handover. This is only exercised by apt when the relevant > packages employ a mutual conflict, which is not the case here. As such, > I also add temporary diversions that exist from preinst to postinst to > protect the relevant files from loss. Thank you for the bug report, analysis and patch. Of the three affected packages, -cryptsetup and -repart are brand new, were never and will never be in bookworm, not even in backports, so they are actually unaffected by the potential issue that affects the Conflicts workaround. -container does ship in bookworm, but the affected files, the sd- sysupdate units, did not exist at all in bookworm, as the sub-feature was only enabled later, and they only shipped in backports, not in bookworm proper. Moreover, the feature itself is experimental, wasn't really in a good shape in the backports version, and even in the newer it cannot actually be used with any Debian infrastructure: we just do not build and publish any of the image formats it supports. The only reason it was enabled, was to allow local experiments. It is most definitely not "boot critical" in any sense of the term. Finally, if it _is_ actually used, then it would be in an image-based system, that by definition does not perform package upgrades at all, but exclusively installs read-only images using A/B schemes or similar, so any system actually making use of these units would not be affected by such upgrade issues in the first place, as it would be read-only. Any system affected by this hypothetical cycle-induce file loss would experience no issue, as the units would not be in use, by definition, and would just come back at the next point release update. Given the likelihood of any impact is minimal, and the magnitude of any impact is nil, and given that the fix requires a large and expensive to maintain patch, my conclusion is that the costs are not worth the benefits, and I am ok with the minimal and localized risk that comes with just relying on the much simpler Conflicts-based solution, and will hence opt to use that instead. Thanks again for the input and the discussion. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1073785: marked as pending in debootstrap
Control: tag -1 pending Hello, Bug #1073785 in debootstrap 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/installer-team/debootstrap/-/commit/89571b21021f84488f63c036023746d88f109507 Merge branch 'bug/1073785' into 'master' reinstate Debian codename symlinks (closes: #1073785) See merge request installer-team/debootstrap!118 (this message was generated automatically) -- Greetings https://bugs.debian.org/1073785
Bug#1073785: marked as pending in debootstrap
Control: tag -1 pending Hello, Bug #1073785 in debootstrap 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/installer-team/debootstrap/-/commit/cf55650623a4a87ab353a7a89fa18debca239f5f reinstate Debian codename symlinks (closes: #1073785) This reverts the removal of Debian codename symlinks from commit 2d3eae916af51cc49ab0989cea1f5bfb58012179 because their absence breaks debootstrap when run in Debian-Installer (which does not have `distro-info` available). It seems entierly plausible that the absence of the Ubuntu symlinks will similarly break debian-installer when used to install Ubuntu, but I'll leave those as they are until that's confirmed by someone from Ubuntu. (this message was generated automatically) -- Greetings https://bugs.debian.org/1073785
Bug#1073290: marked as pending in systemd
Control: tag -1 pending Hello, Bug #1073290 in systemd 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/systemd-team/systemd/-/commit/6de39134c1351f62f68fe7c2686b111d3f636fa6 Bump versioned breaks against dracut to 102-2 Closes: #1073290 (this message was generated automatically) -- Greetings https://bugs.debian.org/1073290
Bug#1073260: systemd-tmpfiles can nuke /home and /srv
Control: severity -1 wishlist Control: tags -1 wontfix Control: close -1 On Sat, 15 Jun 2024 12:58:28 +0200 Antoine Le Gonidec wrote: > Package: systemd > Version: 256-1 > Severity: critical > Justification: causes serious data loss > > The current build of systemd in Debian Sid ships the following file: > /usr/lib/tmpfiles.d/home.conf This is not social media, so if this is an attempt at trolling, it's not even funny. This functionality is for services and packaging scripts, not for manual invocation, there is nowhere that even hints to do that. Don't run things that you don't know what to do, without reading its documentation. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1073112: daemontools: autopkgtest daemontools-run-systemd is flaky
Source: daemontools Severity: serious Justification: flaky debci is RC as per RT User: debian...@lists.debian.org Usertags: flaky Dear maintainer(s), The daemontools-run-systemdautopkgtest is flaky, and often requires a retry to pass, with no other changes. As per RT, this is RC. Example: https://ci.debian.net/packages/d/daemontools/testing/riscv64/47570489/ https://ci.debian.net/packages/d/daemontools/testing/riscv64/47570489/ https://ci.debian.net/packages/d/daemontools/testing/riscv64/47664507/ -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1073052: cryptsetup: autopkgtest cryptroot-lvm is flaky
Source: cryptsetup Severity: serious Justification: flaky debci is RC as per RT User: debian...@lists.debian.org Usertags: flaky Dear maintainer(s), The cryptroot-lvm autopkgtest is flaky, and often fails and then passes upon reruns, independently of the reason why it was triggered. As per RT, this is an RC issue. Example: 134s /tmp/autopkgtest-lxc.snppntav/downtmp/build.WFv/src/debian/tests/cryptroot-lvm: line 514: 7255 Segmentation fault ${QEMU_TIMEOUT:+timeout 3600s} "$QEMU_SYSTEM_CMD" "${QEMU_COMMON_ARGS[@]}" "${QEMU_STDIO_ARGS[@]}" -drive "$QEMU_DEBIANIMG_DRIVE" -kernel "$TEMPDIR/vmlinuz-$KERNEL_VERSION" -append "console=$CONSOLE,115200n8" -initrd "$TEMPDIR/initrd.img-$KERNEL_VERSION" 134s + exit 139 134s + teardown 134s + local rv=139 ts 134s + '[' -n '' ']' 134s + rm -rf -- /tmp/autopkgtest-lxc.snppntav/downtmp/autopkgtest_tmp/cryptroot-lvm.fuN4MJ9S9Q 135s + trap - EXIT 135s + '[' '!' -t 1 ']' 135s ++ printf '%(%s)T' 135s + ts=1718183644 135s + rv=139 135s + printf 'Result for test '\''%s'\'': exit status %s, runtime %d seconds\n' cryptroot-lvm 139 56 135s + exit 139 135s Result for test 'cryptroot-lvm': exit status 139, runtime 56 seconds https://ci.debian.net/packages/c/cryptsetup/testing/amd64/47561302/ -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1072947: dropbear: autopkgtest remote-unlocking is flaky
Source: dropbear 2024.85-2 Severity: serious Justification: flaky debci is RC as per RT User: debian...@lists.debian.org Usertags: flaky Dear Maintainer(s), The remote-unlocking autopkgtest is flaky, and often requires a retry to pass, with no other changes. As per RT, this is RC. Example: https://ci.debian.net/packages/d/dropbear/testing/amd64/47506735/ https://ci.debian.net/packages/d/dropbear/testing/amd64/47426591/ https://ci.debian.net/packages/d/dropbear/testing/amd64/47261698/ https://ci.debian.net/packages/d/dropbear/testing/amd64/47105607/ 887s Connection timed out during banner exchange 887s Connection to 127.0.0.1 port 10022 timed out 887s + rv=255 887s + [ 255 -ne 255 ] 887s + [ 1 -le 1 ] 887s + echo ERROR: Couldn't SSH into QEMU: maximum number of tries exceeded 887s ERROR: Couldn't SSH into QEMU: maximum number of tries exceeded 887s + exit 1 887s + kill 29110 -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1072748: upower: autopkgtest installed-tests is flaky
Source: upower 1.90.3-1 Severity: serious Justification: flaky debci is RC as per RT User: debian...@lists.debian.org Usertags: flaky Dear Maintainer(s), This autopkgtest is flaky, and often requires a couple of retries to pass. As per RT, this is RC. Example: 236s FAIL: test_sibling_priority_no_overwrite (__main__.Tests.test_sibling_priority_no_overwrite) 236s Test siblings using the fallback device do not overwrite previous guesses 236s -- 236s Traceback (most recent call last): 236s File "/usr/libexec/upower/integration-test.py", line 2635, in test_sibling_priority_no_overwrite 236s self.assertDevs({ 236s File "/usr/libexec/upower/integration-test.py", line 294, in assertDevs 236s self.assertEqual(names, sorted(expected.keys())) 236s AssertionError: Lists differ: [] != ['battery_wacom_battery_0'] 236s 236s Second list contains 1 additional elements. 236s First extra element 0: 236s 'battery_wacom_battery_0' 236s 236s - [] 236s + ['battery_wacom_battery_0'] 236s 236s -- 236s Ran 67 tests in 177.484s 236s 236s FAILED (failures=1) 236s FAIL: upower/upower-integration.test (Child process exited with code 1) https://ci.debian.net/packages/u/upower/testing/s390x/47448061/ -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1069871: netplan.io: flaky autopkgtest on s390x: eth42 interface already exists
ues 64 numrxqueues 64 gso_max_size 65536 gso_max_segs 65535 tso_max_size 524280 tso_max_segs 65535 gro_max_size 65536 359s inet6 2600::19/128 scope global dynamic noprefixroute 359svalid_lft 86395sec preferred_lft 86395sec 359s inet6 fe80::e867:94ff:fe09:4831/64 scope link proto kernel_ll 359svalid_lft forever preferred_lft forever https://ci.debian.net/packages/n/netplan.io/testing/amd64/47450641/#S10 -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1072734: prometheus-squid-exporter: autopkgtest dh-golang-autopkgtest is flaky
Source: prometheus-squid-exporter Severity: serious Justification: flaky debci is RC as per RT User: debian...@lists.debian.org Usertags: flaky Dear maintainer(s), The dh-golang-autopkgtest autopkgtest is flaky, and often fails and then passes upon reruns, independently of the reason why it was triggered. As per RT, this is an RC issue. Example: 98s === RUN TestReadFromSquid 98s panic: runtime error: invalid memory address or nil pointer dereference 98s [signal SIGSEGV: segmentation violation code=0x1 addr=0x28 pc=0x653bf4] 98s 98s goroutine 7 [running]: 98s github.com/boynux/squid-exporter/collector.TestReadFromSquid.func1() 98s /tmp/autopkgtest-lxc.tnsof3vy/downtmp/autopkgtest_tmp/build/src/github.com/boynux/squid-exporter/collector/client_test.go:39 +0x44 98s created by github.com/boynux/squid-exporter/collector.TestReadFromSquid in goroutine 6 98s /tmp/autopkgtest-lxc.tnsof3vy/downtmp/autopkgtest_tmp/build/src/github.com/boynux/squid-exporter/collector/client_test.go:37 +0x70 98s FAIL github.com/boynux/squid-exporter/collector 0.010s https://ci.debian.net/packages/p/prometheus-squid-exporter/testing/arm64/47447211/ -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1072369: dropbear: flaky autopkgtest
Source: dropbear Version: 2024.85-1 Severity: serious Justification: flaky debci is RC as per RT X-Debbugs-CC: elb...@debian.org Hi, Dropbear's debci sometimes fails and works on reruns, which is RC according to the release team. E.g.: 44s _ test_read_pty[41234] _ 44s 44s request = > 44s dropbear = 44s size = 41234 44s 44s @pytest.mark.parametrize("size", [0, 1, 2, 100, 20001, 41234]) 44s def test_read_pty(request, dropbear, size): 44s# testcase for 44s# https://bugs.openwrt.org/index.php?do=details&task_id=1814 44s# https://github.com/mkj/dropbear/pull/85 44s# From Yousong Zhou 44s# Fixed Oct 2021 44s# 44s#$ ssh -t my.router cat /tmp/bigfile | wc 44s#Connection to my.router closed. 44s# 0 1 14335 <- should be 20001 44s 44s# Write the file. No newlines etc which could confuse ptys 44sdat = random_alnum(size) 44sr = dbclient(request, "tmpf=`mktemp`; echo $tmpf; cat > $tmpf", input=dat, capture_output=True, text=True) 44stmpf = r.stdout.rstrip() 44sr.check_returncode() 44s# Read with a pty, this is what is being tested. 44s# Timing/buffering is subtle, we seem to need to cat a file from disk to hit it. 44sm, s = pty.openpty() 44sr = dbclient(request, "-t", f"cat {tmpf}; rm {tmpf}", stdin=s, capture_output=True) 44sr.check_returncode() 44s > assert r.stdout.decode() == dat 44s EAssertionError: assert '5UJ3MW22xOOI...FaalTbhYJnMCI' == '5UJ3MW22xOOI...Y3JVX5tREk1dZ' 44s E 44s E Skipping 35313 identical leading characters in diff, use -v to show 44s E - alTbhYJnMCIn7LtG6YFfF3Gk3pFejnyM2rEbIILTIFdk1JWuplYKktUPBdJT7np0mbpsUIv4VRwGAVP2JWGnLAm4S4AAQIPMawGHMyoxqV9zFFE8MinMNvpw1aQf9QPfnO8TeBNMyIVtBwW3T3BnV5K9g46lSmnyHzb74TxhKlyUPfxptjwFB1d8v4HyDdl0RyLYulodzxNeIOB1Lm5ALyInEVcVc6cy4O9gmzgUCRHT5i3dJzMCvJJ0yBYRhfSwY4vms9TLH5uloGp5wK8QYMeiM4YGMR8LlGE0p2ol7aiVd0LxNqWb3dzlC17iPYOjxhpUaIuUOkhxu5JXcnEP8QkLOwEgWltymjnnvG3z4ITHf24leozVwGMOO8eR74E9JZdZE6Hs7EWKMuzFmlCHK08L5WtZRPYksOq5HuvUxttVOhtCYJDgPpnJ48Z27q0no73Qeg3gS7Y74nf3ZEGToWh71Wn9whsbp3QoGMENc4UUth8KPoiu2QuEzbl... 44s E 44s E ...Full output truncated (2 lines hidden), use '-vv' to show https://ci.debian.net/packages/d/dropbear/testing/s390x/47157781/ -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1072290: systemd prevent system to boot if /etc/fstab as an /tmp entry
Control: severity -1 minor Control: tags -1 moreinfo On Fri, 31 May 2024 16:42:38 +0200 eric wrote: > Package: systemd > Version: 256~rc3-6 > Severity: critical > Justification: breaks the whole system > > > if I let this entry in /etc/fstab > UUID=x /tmp ext4 defaults,discard,noatime,nodiratime 0 2 > > > System does not boot Set log level to debug via the kernel command line, and attach the journal log. Also use report-bug so that all the relevant information is collected and attached. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1060572: wireguard: Please switch Build-Depends to systemd-dev
Control: tags -1 pending patch On Thu, 11 Jan 2024 23:36:53 +0100 bi...@debian.org wrote: > Source: wireguard > Version: 1.0.20210914-1 > Severity: normal > User: pkg-systemd-maintain...@lists.alioth.debian.org > Usertags: systemd-dev > > Hi, > > your package wireguard declares a Build-Depends on systemd and/or > udev. > > In most cases, this build dependency is added to get the paths that > are defined in udev.pc or systemd.pc (via pkgconfig). > > Since systemd_253-2 [1], these two pkgconfig files have been split > into a separate package named systemd-dev. This package is arch:all, > so even available on non-Linux architectures, which will simplify the > installation of upstream provided service files / udev rules. > > To not make existing source packages FTBFS, the systemd and udev > package have a Depends: systemd-dev. This dependency will be removed > at some point though before trixie is released. Once this happens, > this issue will be bumped to RC. > > Please update your build dependencies accordingly at your earliest > convenience. > > If all you need is the systemd.pc or udev.pc pkgconfig file, please > replace any systemd or udev Build-Depends with systemd-dev. In most > cases that should be sufficient. If your package needs further > resources from systemd or udev to build successfully, it's fine to > keep those Build-Depends in addition to systemd-dev. > > To ease stable backports, a version of systemd with those changes is > provided via bookworm-backports. > > In case you have further questions, please contact the systemd team > at . > > On behalf of the systemd team, Michael This is causing the removal of wireguard-tools from testing, which I need for some CI jobs, so I am going to NMU this now, without delay as the RC bug has been open since January. Debdiff attached and pushed to Salsa. -- Kind regards, Luca Boccassi diff -Nru wireguard-1.0.20210914/debian/changelog wireguard-1.0.20210914/debian/changelog --- wireguard-1.0.20210914/debian/changelog 2021-09-28 02:21:06.0 +0100 +++ wireguard-1.0.20210914/debian/changelog 2024-05-30 16:12:29.0 +0100 @@ -1,3 +1,11 @@ +wireguard (1.0.20210914-1.1) unstable; urgency=medium + + * Non-maintainer upload. + * Build-depend on systemd-dev instead of systemd (Closes: #1060572) + * Switch to pkgconf + + -- Luca Boccassi Thu, 30 May 2024 16:12:29 +0100 + wireguard (1.0.20210914-1) unstable; urgency=medium * New upstream release. diff -Nru wireguard-1.0.20210914/debian/control wireguard-1.0.20210914/debian/control --- wireguard-1.0.20210914/debian/control 2021-09-28 02:19:37.0 +0100 +++ wireguard-1.0.20210914/debian/control 2024-05-30 16:12:21.0 +0100 @@ -6,8 +6,8 @@ Unit 193 , Build-Depends: debhelper-compat (= 13), - pkg-config, - systemd, + pkgconf, + systemd-dev, Standards-Version: 4.6.0 Homepage: https://www.wireguard.com Vcs-Git: https://salsa.debian.org/debian/wireguard.git signature.asc Description: This is a digitally signed message part
Bug#1072004: linux: regression in the 9p protocol in 6.8 breaks autopkgtest qemu jobs (affecting debci)
On Mon, 27 May 2024 13:02:12 +0100 Luca Boccassi wrote: > Source: linux > Version: 6.8.9-1 > Severity: grave > Justification: breaks autopkgtest jobs running in qemu, breaking amd64 debci > X-Debbugs-CC: elb...@debian.org, m...@tls.msk.ru > > Hi, > > Kernel 6.8 includes this change: > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=80105ed2fd2715fb09a8fdb0655a8bdc86c120db > > This has been bisected by Canonical and found to be breaking > qemu+autopkgtest. Tests just hang while waiting for input. > > This is reliably reproducible, and has already started affecting debci > amd64 jobs in unstable, so filing with high severity to avoid > migration, that would break migration debci autopkgtest jobs. Example: > > https://ci.debian.net/packages/s/systemd/unstable/amd64/47041978/ > > The launchpad ticket has more details: > > https://bugs.launchpad.net/ubuntu/+source/autopkgtest/+bug/2056461 This has been reported upstream 3 weeks ago, but so far it seems no action has been taken: https://lore.kernel.org/all/Zj0ErxVBE3DYT2Ea@gpd/ Maybe Thorsten could be able to help? TIA! -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1072004: linux: regression in the 9p protocol in 6.8 breaks autopkgtest qemu jobs (affecting debci)
Source: linux Version: 6.8.9-1 Severity: grave Justification: breaks autopkgtest jobs running in qemu, breaking amd64 debci X-Debbugs-CC: elb...@debian.org, m...@tls.msk.ru Hi, Kernel 6.8 includes this change: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=80105ed2fd2715fb09a8fdb0655a8bdc86c120db This has been bisected by Canonical and found to be breaking qemu+autopkgtest. Tests just hang while waiting for input. This is reliably reproducible, and has already started affecting debci amd64 jobs in unstable, so filing with high severity to avoid migration, that would break migration debci autopkgtest jobs. Example: https://ci.debian.net/packages/s/systemd/unstable/amd64/47041978/ The launchpad ticket has more details: https://bugs.launchpad.net/ubuntu/+source/autopkgtest/+bug/2056461 -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1071220: netplan.io: autopkgtest fails with systemd 256
On Wed, 22 May 2024 12:38:37 +0100 Luca Boccassi wrote: > On Wed, 22 May 2024 09:23:11 +0200 =?UTF-8?Q?Lukas_M=C3=A4rdian?= > wrote: > > Hi Luca, thanks for the NMU. > > > > Am 22.05.24 um 02:48 schrieb Luca Boccassi: > > > Given this has been an issue for a week and it now stops systemd > from > > > migrating to test, I have uploaded to DELAYED/1 with urgency=high a > > > patch to disable this test. MR on Salsa: > > > > > > https://salsa.debian.org/debian/netplan.io/-/merge_requests/14 > > > > Sorry, I was traveling and didn't have time to look into this, yet. > > > > Having a closer look, this sounds like a real regression in systemd- > udev. > > Did you double-check that "ReceiveChecksumOffload=" (inside a .link) > file > > is working properly with systemd v256 in unstable? > > > > Netplan's tests seem to work in unstable, except when the new systemd > is pulled in. > > It fails for Netplan's sd-networkd & NetworkManager backends, because > both make use of > > systemd-udev .link files. There's no special handling for > NetworkManager here. > > > > It's OK to have it temporarily disable to make systemd migrate, but > I'll probably > > revert the patch after merging your NMU in the packaging repo.. > > Please try to get this resolved in systemd, before the next upload. > > If it's an actual problem please file an issue upstream with all the > details, and a reproducer that doesn't require netplan, I don't really > know how these offload options are supposed to be handled. Yu says: > https://github.com/canonical/netplan/blob/26d2591d771cb4343c06dbb1e0eb1f3587ec910d/netplan_cli/cli/commands/apply.py#L257 > > Here, "--action add" is necessary, otherwise the generated .link > files will be never applied to existing interfaces. So it looks like a problem in netplan. If you can take care of that today I'll cancel the NMU, otherwise if it's ok I'll let that through to get the migration going. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1071220: netplan.io: autopkgtest fails with systemd 256
On Wed, 22 May 2024 09:23:11 +0200 =?UTF-8?Q?Lukas_M=C3=A4rdian?= wrote: > Hi Luca, thanks for the NMU. > > Am 22.05.24 um 02:48 schrieb Luca Boccassi: > > Given this has been an issue for a week and it now stops systemd from > > migrating to test, I have uploaded to DELAYED/1 with urgency=high a > > patch to disable this test. MR on Salsa: > > > > https://salsa.debian.org/debian/netplan.io/-/merge_requests/14 > > Sorry, I was traveling and didn't have time to look into this, yet. > > Having a closer look, this sounds like a real regression in systemd- udev. > Did you double-check that "ReceiveChecksumOffload=" (inside a .link) file > is working properly with systemd v256 in unstable? > > Netplan's tests seem to work in unstable, except when the new systemd is pulled in. > It fails for Netplan's sd-networkd & NetworkManager backends, because both make use of > systemd-udev .link files. There's no special handling for NetworkManager here. > > It's OK to have it temporarily disable to make systemd migrate, but I'll probably > revert the patch after merging your NMU in the packaging repo.. > Please try to get this resolved in systemd, before the next upload. If it's an actual problem please file an issue upstream with all the details, and a reproducer that doesn't require netplan, I don't really know how these offload options are supposed to be handled. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1071220: netplan.io: autopkgtest fails with systemd 256
Control: tags -1 pending On Thu, 16 May 2024 13:13:12 +0100 Luca Boccassi wrote: > Source: netplan.io > Version: 1.0-2 > Severity: serious > Justification: breaks another package's migration > X-Debbugs-CC: pkg-systemd-maintain...@lists.alioth.debian.org > > Hi, > > Netplan's autopkgtest are failing on all architectures with the newest > systemd from unstable in the ethernets test: > > 1095s == > 1095s FAIL: test_link_offloading (__main__.TestNetworkManager.test_link_offloading) > 1095s --- --- > 1095s Traceback (most recent call last): > 1095s File "/tmp/autopkgtest- lxc.r1eokuuo/downtmp/build.bnO/src/tests/integration/ethernets.py", line 286, in test_link_offloading > 1095s self.assertIn(b'rx-checksumming: off', out) > 1095s AssertionError: b'rx-checksumming: off' not found in b'Features for eth42:\nrx-checksumming: on\ntx-checksumming: on\n\ttx-checksum- ipv4: off [fixed]\n\ttx-checksum-ip-generic: on\n\ttx-checksum-ipv6: off [fixed]\n\ttx-checksum-fcoe-crc: off [fixed]\n\ttx-checksum-sctp: on\nscatter-gather: on\n\ttx-scatter-gather: on\n\ttx-scatter-gather- fraglist: on\ntcp-segmentation-offload: on\n\ttx-tcp-segmentation: on\n\ttx-tcp-ecn-segmentation: on\n\ttx-tcp-mangleid-segmentation: on\n\ttx-tcp6-segmentation: on\ngeneric-segmentation-offload: on\ngeneric-receive-offload: off\nlarge-receive-offload: off [fixed]\nrx-vlan-offload: on\ntx-vlan-offload: on\nntuple-filters: off [fixed]\nreceive-hashing: off [fixed]\nhighdma: on\nrx-vlan-filter: off [fixed]\nvlan-challenged: off [fixed]\ntx-lockless: on [fixed]\nnetns- local: off [fixed]\ntx-gso-robust: off [fixed]\ntx-fcoe-segmentation: off [fixed]\ntx-gre-segmentation: on\ntx-gre-csum-segmentation: on\ntx- ipxip4-segmentation: on\ntx-ipxip6-segmentation: on\ntx-udp_tnl- segmentation: on\ntx-udp_tnl-csum-segmentation: on\ntx-gso-partial: off [fixed]\ntx-tunnel-remcsum-segmentation: off [fixed]\ntx-sctp- segmentation: on\ntx-esp-segmentation: off [fixed]\ntx-udp- segmentation: on\ntx-gso-list: on\nfcoe-mtu: off [fixed]\ntx-nocache- copy: off\nloopback: off [fixed]\nrx-fcs: off [fixed]\nrx-all: off [fixed]\ntx-vlan-stag-hw-insert: on\nrx-vlan-stag-hw-parse: on\nrx- vlan-stag-filter: off [fixed]\nl2-fwd-offload: off [fixed]\nhw-tc- offload: off [fixed]\nesp-hw-offload: off [fixed]\nesp-tx-csum-hw- offload: off [fixed]\nrx-udp_tunnel-port-offload: off [fixed]\ntls-hw- tx-offload: off [fixed]\ntls-hw-rx-offload: off [fixed]\nrx-gro-hw: off [fixed]\ntls-hw-record: off [fixed]\nrx-gro-list: off\nmacsec-hw- offload: off [fixed]\nrx-udp-gro-forwarding: off\nhsr-tag-ins-offload: off [fixed]\nhsr-tag-rm-offload: off [fixed]\nhsr-fwd-offload: off [fixed]\nhsr-dup-offload: off [fixed]\n' > 1095s > 1095s == > 1095s FAIL: test_link_offloading (__main__.TestNetworkd.test_link_offloading) > 1095s --- --- > 1095s Traceback (most recent call last): > 1095s File "/tmp/autopkgtest- lxc.r1eokuuo/downtmp/build.bnO/src/tests/integration/ethernets.py", line 286, in test_link_offloading > 1095s self.assertIn(b'rx-checksumming: off', out) > 1095s AssertionError: b'rx-checksumming: off' not found in b'Features for eth42:\nrx-checksumming: on\ntx-checksumming: on\n\ttx-checksum- ipv4: off [fixed]\n\ttx-checksum-ip-generic: on\n\ttx-checksum-ipv6: off [fixed]\n\ttx-checksum-fcoe-crc: off [fixed]\n\ttx-checksum-sctp: on\nscatter-gather: on\n\ttx-scatter-gather: on\n\ttx-scatter-gather- fraglist: on\ntcp-segmentation-offload: on\n\ttx-tcp-segmentation: on\n\ttx-tcp-ecn-segmentation: on\n\ttx-tcp-mangleid-segmentation: on\n\ttx-tcp6-segmentation: on\ngeneric-segmentation-offload: on\ngeneric-receive-offload: off\nlarge-receive-offload: off [fixed]\nrx-vlan-offload: on\ntx-vlan-offload: on\nntuple-filters: off [fixed]\nreceive-hashing: off [fixed]\nhighdma: on\nrx-vlan-filter: off [fixed]\nvlan-challenged: off [fixed]\ntx-lockless: on [fixed]\nnetns- local: off [fixed]\ntx-gso-robust: off [fixed]\ntx-fcoe-segmentation: off [fixed]\ntx-gre-segmentation: on\ntx-gre-csum-segmentation: on\ntx- ipxip4-segmentation: on\ntx-ipxip6-segmentation: on\ntx-udp_tnl- segmentation: on\ntx-udp_tnl-csum-segmentation: on\ntx-gso-partial: off [fixed]\ntx-tunnel-remcsum-segmentation: off [fixed]\ntx-sctp- segmentation: on\ntx-esp-segmentation: off [fixed]\ntx-udp- segmentation: on\ntx-gso-list: on\nfcoe-mtu: off [fixed]\ntx-nocache- copy: off\nloopback: off [fixed]\nrx-fcs: off [fixed]\nrx-all: off [fixed]\ntx-vlan-stag-hw-insert: on\nrx-vlan-stag-hw-parse: on\nrx- vlan-stag-filter: off [fixed]\nl2-fwd-offload: off [fixed]\nhw-tc- offload: off [fixed]\nesp-hw-offlo
Bug#1071278: systemd 256 breaks dracut
Control: severity -1 normal Control: tags -1 moreinfo On Fri, 17 May 2024 17:09:43 +0200 Thomas Lange wrote: > > Package: systemd > Version: 256~rc2-3 > Severity: serious > > systemd changed it's behaviour and now makes /usr read-only in the > initrd. This breaks dracut and vice versa. > This bug is releated to #1071182 which says dracut breaks systemd. > Please add a Breaks: dracut(<<..) > > Currently I do not know when I will update dracut, because there are > also plans to replace dracut by dracut-ng, which may involve more > time. I not sure in which package I will invest my available time. > > In order to not break the systems of our users, IMO the smalles change > would be to add the Breaks: line to systemd. A breaks against what version? -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1071201: marked as pending in systemd
Control: tag -1 pending Hello, Bug #1071201 in systemd 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/systemd-team/systemd/-/commit/bbdac8b5b78c2b33c12ea3a6bcf827e9f2cedadf Backport patches to fix journald asserts Compress=yes Closes: #1071201 (this message was generated automatically) -- Greetings https://bugs.debian.org/1071201
Bug#1071220: netplan.io: autopkgtest fails with systemd 256
]\ntls-hw-record: off [fixed]\nrx-gro-list: off\nmacsec-hw-offload: off [fixed]\nrx-udp-gro-forwarding: off\nhsr-tag-ins-offload: off [fixed]\nhsr-tag-rm-offload: off [fixed]\nhsr-fwd-offload: off [fixed]\nhsr-dup-offload: off [fixed]\n' https://ci.debian.net/packages/n/netplan.io/testing/amd64/46796381/ -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1070768: bpfcc: ftbfs on ppc64el
Control: tags -1 pending On Sat, 11 May 2024 at 03:21, Vasudev Kamath wrote: > > On 11 May 2024, at 01:29, Luca Boccassi wrote: > > > > Unless there are objections, I am going to NMU to delayed/3 tomorrow > > to remove ppc64el > Please go ahead . > Thanks and Regards > Vasudev Uploaded to DELAYED/3, will push to git once it is in unstable.
Bug#1070768: bpfcc: ftbfs on ppc64el
On Fri, 10 May 2024 at 20:03, Nilesh Patra wrote: > > Quoting Luca Boccassi: > > Source: bpfcc > > Version: 0.29.1+ds-1 > > Severity: serious > > Tags: ftbfs > > > > Hi, > > > > bpfcc has been failing to build on ppc64el for a long time, and this is > > keeping it out of testing. > > > > If you don't have time to fix it, could you please consider at least a > > quick upload to remove ppc64el from the list of architectures, so that > > it can go back to testing? > > > > Thanks! > > > > Vasudev, Ritesh, this bug is causing a bunch of packages getting removed from > testing (bpfcc and transitive reverse depends). Can I ask you to please take > care of this, maybe dropping ppc64el altogether if it is not feasible to fix? Unless there are objections, I am going to NMU to delayed/3 tomorrow to remove ppc64el
Bug#1070768: bpfcc: ftbfs on ppc64el
Source: bpfcc Version: 0.29.1+ds-1 Severity: serious Tags: ftbfs Hi, bpfcc has been failing to build on ppc64el for a long time, and this is keeping it out of testing. If you don't have time to fix it, could you please consider at least a quick upload to remove ppc64el from the list of architectures, so that it can go back to testing? Thanks! -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1068255: dnf: dnf aborts with ImportError: cannot import name '_module' from partially initialized module 'libdnf'
Control: reassign -1 dh-python 6.20240401 Control: retitle -1 dh-python: dh_python3 loses cpython module name when renaming shared object On Tue, 2 Apr 2024 22:47:12 +0300 Michael Ivanov wrote: > Package: dnf > Version: 4.14.0-4.1 > Severity: grave > Justification: renders package unusable > > Dear Maintainer, > > I have just tried to start up dnf and it aborts with a following error: > > Traceback (most recent call last): > File "/usr/bin/dnf", line 61, in > from dnf.cli import main > File "/usr/lib/python3/dist-packages/dnf/__init__.py", line 30, in > import dnf.base > File "/usr/lib/python3/dist-packages/dnf/base.py", line 29, in > import libdnf.transaction > File "/usr/lib/python3/dist-packages/libdnf/__init__.py", line 13, in > > from . import module > File "/usr/lib/python3/dist-packages/libdnf/module.py", line 10, in > from . import _module > ImportError: cannot import name '_module' from partially initialized module > 'libdnf' (most likely due to a circular import) (/usr/lib/python3/dist- > packages/libdnf/__init__.py) > > Python version is 3.11.8 (python package version is 3.11.8-3+b2) This is caused by dh_python3. A regression was introduced at some point, and when renaming the cpython shared object dh_python3 loses the name, and _module.so is renamed to _.cpython-311-x86_64-linux-gnu.so when libdnf is built, breaking the import at runtime: I: dh_python3 fs:418: renaming _module.so to _.cpython-311-x86_64-linux-gnu.so https://buildd.debian.org/status/fetch.php?pkg=libdnf&arch=amd64&ver=0.73.1-1&stamp=1713175615&raw=0 Renaming the shared library manually to the expected filename makes dnf work again. Reassigning to dh-python. A binnmu of libdnf (and any other affected package) will be needed once resolved and uploaded. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1063976: marked as pending in javaproperties
Control: tag -1 pending Hello, Bug #1063976 in javaproperties 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/python-team/packages/javaproperties/-/commit/644c92fa170fe0ac6f0dceb9b02e4de9747f3f96 Disable tests due to API breakage in pytest 8 Closes: #1063976 (this message was generated automatically) -- Greetings https://bugs.debian.org/1063976
Bug#1067094: pacman-package-manager: FTBFS on armel/armh
Source: pacman-package-manager Version: 6.0.2-4.1 Severity: grave Pacman currently fails to build on armel/armhf, probably as a fallout from the time64 changes. Given it seems extremely unlikely to be needed on those architectures, given Archlinux doesn't even support them, I'd recommend to simply build-depend on architecture-is-64-bit to drop all 32 bit arches support, and revert the libalpm13 package rename that added the t64 suffix.
Bug#1066039: virt-firmware: autopkgtest are failing on debci
Source: virt-firmware Version: 24.1.1-1 Severity: grave Dear Maintainer, The autodep8 autopkgtest suite is failing and has never worked, which is stopping virt-firmware from migrating to testing (hence severity). The fix is trivial and attached, the test simply needs a hint on which modules to load. I will NMU to DELAYED/5 next Monday unless you get to it first. I would highly recommend to add a debian/salsa-ci.yml so that these issues can be caught automatically and easily before uploading. Thanks! -- Kind regards, Luca Boccassi diff -Nru virt-firmware-24.1.1/debian/changelog virt-firmware- 24.1.1/debian/changelog --- virt-firmware-24.1.1/debian/changelog 2024-02-15 15:16:12.0 + +++ virt-firmware-24.1.1/debian/changelog 2024-03-11 14:05:43.0 + @@ -1,3 +1,10 @@ +virt-firmware (24.1.1-1.1) unstable; urgency=medium + + * Non-maintainer upload. + * Fix autodep8 autopkgtest (Closes: #) + + -- Luca Boccassi Mon, 11 Mar 2024 14:05:43 + + virt-firmware (24.1.1-1) unstable; urgency=medium * New upstream release. diff -Nru virt-firmware-24.1.1/debian/tests/pkg-python/import-name virt-firmware-24.1.1/debian/tests/pkg-python/import-name --- virt-firmware-24.1.1/debian/tests/pkg-python/import-name1970- 01-01 00:00:00.0 + +++ virt-firmware-24.1.1/debian/tests/pkg-python/import-name2024- 03-11 14:04:03.0 + @@ -0,0 +1,2 @@ +virt.firmware +virt.peutils signature.asc Description: This is a digitally signed message part
Bug#1062259: libcomps: NMU diff for 64-bit time_t transition
On Thu, 29 Feb 2024 at 17:12, Steve Langasek wrote: > > On Wed, Feb 28, 2024 at 09:38:06PM +, Luca Boccassi wrote: > > Well, the title of this bug is "NMU diff for 64-bit time_t > > transition", and the bug description said: > > > "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" > > > So the fact that there's no trace of time_t to be found and the script > > was broken and couldn't find anything either sounds to me more than > > enough to say it is a false positive. > > If there are more things that can affect this, then the bug > > description ought to at least mention what they are and why, but right > > now it doesn't. > > > > So, I'm reopening this bug report. This package has already been skipped > > > over in the short term for NMUing to unstable, so you can take some > > > additional time to do your own analysis - but barring that, I will plan to > > > do the NMU in 2 days. > > > If you can fix the script and show it is actually needed then sure, > > please feel free to reopen and show that it's actually needed. But > > otherwise no, having to carry a silly package name forever "just in > > case" is very much not ok, sorry. > > We have done the work now to get an out-of-band result from > abi-compliance-checker confirming that this library's ABI is not affected. That's great, thanks for checking.
Bug#1062259: libcomps: NMU diff for 64-bit time_t transition
On Wed, 28 Feb 2024 at 22:40, Steve Langasek wrote: > > On Wed, Feb 28, 2024 at 09:38:06PM +, Luca Boccassi wrote: > > On Wed, 28 Feb 2024 at 20:15, Steve Langasek wrote: > > > On Wed, Feb 07, 2024 at 08:05:52PM +, Holger Levsen wrote: > > > > 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. > > > > > > This is not sufficient reason to consider the bug a false-positive. > > > time_t > > > is *not* the only type eaffected by this, and the entire reason that we > > > use > > > abi-compliance-checker for identifying packages that need uploaded is to > > > ensure we have deep inspection of the exposed types via a compiler rather > > > than a grep that we know will have false-negatives. > > > Well, the title of this bug is "NMU diff for 64-bit time_t > > transition", and the bug description said: > > > "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" > > > So the fact that there's no trace of time_t to be found and the script > > was broken and couldn't find anything either sounds to me more than > > enough to say it is a false positive. > > If there are more things that can affect this, then the bug > > description ought to at least mention what they are and why, but right > > now it doesn't. > > > > So, I'm reopening this bug report. This package has already been skipped > > > over in the short term for NMUing to unstable, so you can take some > > > additional time to do your own analysis - but barring that, I will plan to > > > do the NMU in 2 days. > > > If you can fix the script and show it is actually needed then sure, > > please feel free to reopen and show that it's actually needed. But > > otherwise no, having to carry a silly package name forever "just in > > case" is very much not ok, sorry. > > Seven months ago, the fact that we did not have capacity to fix every > library package that ships broken headers was communicated to debian-devel > and that if maintainers wanted to be sure they didn't get an unnecessary > transition, they were welcome to contribute patches to the analysis scripts > or fix their packages to make the headers analyzable. Sorry, that's not how it works. If you report a bug, you need to provide enough information to prove that there really is a bug. If you don't have the capacity or time, that's fine, but it means nothing gets changed. > I'm not going to argue with you about this. Expect an NMU incoming. Expect it to be immediately followed by a revert.
Bug#1062259: libcomps: NMU diff for 64-bit time_t transition
Control: close -1 On Wed, 28 Feb 2024 at 20:15, Steve Langasek wrote: > On Wed, Feb 07, 2024 at 08:05:52PM +, Holger Levsen wrote: > > On Wed, Feb 07, 2024 at 04:25:17PM +0000, 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. > > This is not sufficient reason to consider the bug a false-positive. time_t > is *not* the only type eaffected by this, and the entire reason that we use > abi-compliance-checker for identifying packages that need uploaded is to > ensure we have deep inspection of the exposed types via a compiler rather > than a grep that we know will have false-negatives. Well, the title of this bug is "NMU diff for 64-bit time_t transition", and the bug description said: "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" So the fact that there's no trace of time_t to be found and the script was broken and couldn't find anything either sounds to me more than enough to say it is a false positive. If there are more things that can affect this, then the bug description ought to at least mention what they are and why, but right now it doesn't. > So, I'm reopening this bug report. This package has already been skipped > over in the short term for NMUing to unstable, so you can take some > additional time to do your own analysis - but barring that, I will plan to > do the NMU in 2 days. If you can fix the script and show it is actually needed then sure, please feel free to reopen and show that it's actually needed. But otherwise no, having to carry a silly package name forever "just in case" is very much not ok, sorry.
Bug#1064735: pkcs11-provider: FTBFS: dh_auto_test: error: make -j8 check "TESTSUITEFLAGS=-j8 --verbose" VERBOSE=1 returned exit code 2
Control: tags -1 unreproducible Control: close -1 On Sun, 25 Feb 2024 20:44:24 +0100 Lucas Nussbaum wrote: > Source: pkcs11-provider > Version: 0.3-1 > Severity: serious > Justification: FTBFS > Tags: trixie sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20240224 ftbfs-trixie > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. Works fine here in a fresh sid chroot and on the buildds, so it must be a problem in your custom environment. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1063393: marked as pending in systemd
Control: tag -1 pending Hello, Bug #1063393 in systemd 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/systemd-team/systemd/-/commit/c3c302d3ac90d37ef6be01939bb2ddb5038674b6 Skip python3-pefile build dependency only if both nocheck and noinsttests are set Closes: #1063393 (this message was generated automatically) -- Greetings https://bugs.debian.org/1063393
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#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#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
Bug#1063261: xdp-tools: NMU diff for 64-bit time_t transition
Control: close -1 On Mon, 05 Feb 2024 22:06:28 + Steve Langasek wrote: > Source: xdp-tools > Version: 1.4.0-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 > xdp-tools 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 xdp- tools > 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. According to what was reported on IRC, this is a failed analysis rather than detection of an ABI change, and that's the reason the package was marked. But there is no reference of 'time_t' anywhere in the code base, let alone in the public headers, so it seems to me this is a false positive, closing accordingly. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1061997: czmq: NMU diff for 64-bit time_t transition
On Tue, 30 Jan 2024 19:18:12 + mwhud...@debian.org wrote: > Source: czmq > Version: 4.2.1-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 > czmq 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 czmq > 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. The package is in the 'debian' section of Salsa, so feel free to the changes push directly there when uploading to unstable. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1061397: marked as pending in network-manager-openconnect
Control: tag -1 pending Hello, Bug #1061397 in network-manager-openconnect 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/network-manager-openconnect/-/commit/e08af3b0f94296be66332b08ad2da8a0554a7f8c Build with webkit2gtk 4.1 instead of 4.0 Closes: #1061397 (this message was generated automatically) -- Greetings https://bugs.debian.org/1061397
Bug#1059899: systemd-resolved: systemd-resolved takes up all memory on certain PTR queries and is then oom-killed
Control: severity -1 normal Control: tags -1 moreinfo On Wed, 03 Jan 2024 12:02:40 +0100 Corin Langosch wrote: > Package: systemd > Version: 247.3-7+deb11u4 > Severity: critical > File: systemd-resolved > Justification: breaks the whole system Your logs show that it restarts just fine after the oom kill, so it is most definitely not "grave". Also, you did not attach your local resolved.conf. Also, oldstable is old. Try with backports or with upgrading to stable. -- Kind regards, Luca Boccassi
Bug#1058444: marked as pending in python-msrest
Control: tag -1 pending Hello, Bug #1058444 in python-msrest 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/python-team/packages/python-msrest/-/commit/9a1d6a25f6a4e40bb3469ae062fa8a457e9b1cff Skip more failing tests Closes: #1058444 (this message was generated automatically) -- Greetings https://bugs.debian.org/1058444
Bug#1056791: marked as pending in azure-uamqp-python
Control: tag -1 pending Hello, Bug #1056791 in azure-uamqp-python 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/python-team/packages/azure-uamqp-python/-/commit/15f829b8edb33985534890abf663cf391cec6eff Build depend on cython3-legacy Closes: #1056791 (this message was generated automatically) -- Greetings https://bugs.debian.org/1056791
Bug#1059467: python-dbusmock: new version 0.30.1-1 causes upower's autopkgtest to fail
On Thu, 28 Dec 2023 at 21:28, Martin Pitt wrote: > > Control: tag -1 upstream > Control: forwarded -1 > https://gitlab.freedesktop.org/upower/upower/-/merge_requests/207 > > Hello Luca, > > Luca Boccassi [2023-12-26 12:46 +0100]: > > Not sure whether it was a legitimate change and upower's tests need an > > update, or if it is a new bug, but 0.30.1-1 causes src:upower > > autopkgtest to fail and stops migration of a bunch of unrelated > > packages from unstable to testing as debci bundles new packages > > together when testing for regressions, and everything is held back. > > Thanks for the report and sorry for the trouble! This is better fixed in > upower's tests IMHO. I sent a fix for upower's tests to the above MR. I'll > give > it three days to review (it's holiday season, after all), and will then upload > the fix to Debian's upower either as a cherry-pick or a downstream patch. Thank you - the release team yesterday evening adjusted the debci run so that this is no longer blocking src:systemd from migrating, so there's no rush.
Bug#1059467: python-dbusmock: new version 0.30.1-1 causes upower's autopkgtest to fail
Source: python-dbusmock Version: 0.30.1-1 Severity: serious Affects: upower Hi, Not sure whether it was a legitimate change and upower's tests need an update, or if it is a new bug, but 0.30.1-1 causes src:upower autopkgtest to fail and stops migration of a bunch of unrelated packages from unstable to testing as debci bundles new packages together when testing for regressions, and everything is held back. You can see the first failure in upower when python-dbusmock was uploaded, without any other new packages being in the same test, on 2023-12-24: https://ci.debian.net/packages/u/upower/testing/amd64/ -- Kind regards, Luca Boccassi
Bug#1057712: collectd: FTBFS on i386
On Thu, 07 Dec 2023 12:55:42 + Luca Boccassi wrote: > Package: collectd > Version: 5.12.0-14 > Severity: serious > Justification: fails to build from sources > > collectd fails to build on i386: binNMUs from September and October were already failing to build: https://buildd.debian.org/status/logs.php?pkg=collectd&ver=5.12.0-14%2Bb1&arch=i386 -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1057712: collectd: FTBFS on i386
. . . . . no (disabled on command line) lua . . . . . . . . . yes madwifi . . . . . . . yes match_empty_counter . yes match_hashed . . . . yes match_regex . . . . . yes match_timediff . . . yes match_value . . . . . yes mbmon . . . . . . . . yes mcelog . . . . . . . yes md . . . . . . . . . yes mdevents . . . . . . yes memcachec . . . . . . yes memcached . . . . . . yes memory . . . . . . . yes mic . . . . . . . . . no (disabled on command line) modbus . . . . . . . yes mqtt . . . . . . . . yes multimeter . . . . . yes mysql . . . . . . . . yes netapp . . . . . . . no (disabled on command line) netlink . . . . . . . yes netstat_udp . . . . . no (disabled on command line) network . . . . . . . yes nfs . . . . . . . . . yes nginx . . . . . . . . yes notify_desktop . . . yes notify_email . . . . yes notify_nagios . . . . yes ntpd . . . . . . . . yes numa . . . . . . . . yes nut . . . . . . . . . yes olsrd . . . . . . . . yes onewire . . . . . . . no (disabled on command line) openldap . . . . . . yes openvpn . . . . . . . yes oracle . . . . . . . no (disabled on command line) ovs_events . . . . . yes ovs_stats . . . . . . yes pcie_errors . . . . . yes perl . . . . . . . . yes pf . . . . . . . . . no (disabled on command line) pinba . . . . . . . . yes ping . . . . . . . . yes postgresql . . . . . yes powerdns . . . . . . yes processes . . . . . . yes procevent . . . . . . yes protocols . . . . . . yes python . . . . . . . yes redfish . . . . . . . no (disabled on command line) redis . . . . . . . . yes routeros . . . . . . no (disabled on command line) rrdcached . . . . . . yes rrdtool . . . . . . . yes sensors . . . . . . . yes serial . . . . . . . yes sigrok . . . . . . . no (disabled on command line) slurm . . . . . . . . no (disabled on command line) smart . . . . . . . . yes snmp . . . . . . . . yes snmp_agent . . . . . yes statsd . . . . . . . yes swap . . . . . . . . yes synproxy . . . . . . yes sysevent. . . . . . . yes syslog . . . . . . . yes table . . . . . . . . yes tail_csv . . . . . . yes tail . . . . . . . . yes tape . . . . . . . . no (disabled on command line) target_notification . yes target_replace . . . yes target_scale . . . . yes target_set . . . . . yes target_v5upgrade . . yes tcpconns . . . . . . yes teamspeak2 . . . . . yes ted . . . . . . . . . yes thermal . . . . . . . yes threshold . . . . . . yes tokyotyrant . . . . . no (disabled on command line) turbostat . . . . . . yes ubi . . . . . . . . . yes unixsock . . . . . . yes uptime . . . . . . . yes users . . . . . . . . yes uuid . . . . . . . . yes varnish . . . . . . . yes virt . . . . . . . . yes vmem . . . . . . . . yes vserver . . . . . . . yes wireless . . . . . . yes write_graphite . . . yes write_http . . . . . yes write_influxdb_udp. . yes write_kafka . . . . . yes write_log . . . . . . yes write_mongodb . . . . yes write_prometheus. . . yes write_redis . . . . . yes write_riemann . . . . yes write_sensu . . . . . yes write_stackdriver . . yes write_syslog . . . . yes write_tsdb . . . . . yes xencpu . . . . . . . no (disabled on command line) xmms . . . . . . . . no (disabled on command line) zfs_arc . . . . . . . yes zone . . . . . . . . no (disabled on command line) zookeeper . . . . . . yes configure: error: "Some plugins are missing dependencies - see the summary above for details" This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1056292: marked as pending in systemd
Control: tag -1 pending Hello, Bug #1056292 in systemd 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/systemd-team/systemd/-/commit/0dc66cb2c6c2837460518fc7f89968ba2de10f9f Bump conflict with molly-guard to 0.8.2 The previous workarounds are not enough, so a new upload will be needed. Closes: #1056292 (this message was generated automatically) -- Greetings https://bugs.debian.org/1056292
Bug#1051243: This affects the build of the pspp package
On Mon, 20 Nov 2023 12:50:24 +0100 =?UTF-8?B?UHJldcOfZSwgSGlsbWFy?= wrote: > On 20.11.2023 10:43, Friedrich Beckmann wrote: > > Hi, > > > i noticed a failure in our CI pipeline for pspp probably due to this bug. The problem occurs when I try to install "apt install texlive-plain-generic“. The install fails with > > > > A new package is on the way. Another adaption to zlib is needed, I'll > trigger that later on. PANIC: unprotected error in call to Lua API (zlib library version does not match - header: 1.2.13, library: 1.3) This looks like an undeclared versioning dependency issue. If there are such constraints, please consider declaring them appropriately in the package control file by defining a dependency on the exact upstream version of zlib (e.g.: >= 1.3~ and << 1.3.1 or something like that). Then every new upstream revision of zlib need to be handled as a sort- of soname transition for tex-common. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1056312: zlib1g makes tex-common fail to install due to fmtutil failing
On Mon, 20 Nov 2023 11:57:20 + Luca Boccassi wrote: > Control: found -1 1:1.3.dfsg-1 > > On Mon, 20 Nov 2023 12:20:55 +0100 Johannes Schauer Marin Rodrigues > wrote: > > Package: zlib1g > > Version: 1:1.3.dfsg-2 > > Severity: serious > > > > Hi, > > > > I didn't investigate this further yet but filing this as RC as it is > easy to > > reproduce and it's easy to find out that only zlib1g changed using > debbisect. > > Downgrading to zlib1g 1:1.2.13.dfsg-3 makes the problem go away. > Steps to > > reproduce: > > > > $ mmdebstrap --include=tex-common,texlive-base unstable /dev/null > > Processing triggers for tex-common (6.18) ... > > Running updmap-sys. This may take some time... done. > > Running mktexlsr /var/lib/texmf ... done. > > Building format(s) --all. > > This may take some time... > > fmtutil failed. Output has been stored in > > /tmp/fmtutil.tcAsaQVq > > Please include this file if you report a bug. > > > > dpkg: error processing package tex-common (--configure): > > installed tex-common package post-installation script subprocess > returned error exit status 1 > > Errors were encountered while processing: > > tex-common > > E: Sub-process env returned an error code (1) > > Looks like this was introduced by 1:1.3.dfsg-1, as it can be reproduced > in a minimal sid chroot by installing it from > https://snapshot.debian.org/archive/debian/20231118T151103Z/pool/main/z/zlib/zlib1g_1.3.dfsg-1_amd64.deb > and then installing texlive-base: > > <...> > Processing triggers for tex-common (6.18) ... > Running updmap-sys. This may take some time... done. > Running mktexlsr /var/lib/texmf ... done. > Building format(s) --all. > This may take some time... > fmtutil failed. Output has been stored in > /tmp/fmtutil.ohLhbhu3 > Please include this file if you report a bug. > > dpkg: error processing package tex-common (--configure): > installed tex-common package post-installation script subprocess returned error exit status 1 > Errors were encountered while processing: > tex-common > E: Sub-process /usr/bin/dpkg returned an error code (1) > # dpkg -l | grep zlib > ii zlib1g:amd64 1:1.3.dfsg-1 amd64 compression library - runtime > ii zlib1g-dev:amd64 1:1.3.dfsg-1 amd64 compression library - development > > -- Looks like a problem in texlive itself, so this can probably be moved/merged: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051243#48 -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1056312: zlib1g makes tex-common fail to install due to fmtutil failing
Control: found -1 1:1.3.dfsg-1 On Mon, 20 Nov 2023 12:20:55 +0100 Johannes Schauer Marin Rodrigues wrote: > Package: zlib1g > Version: 1:1.3.dfsg-2 > Severity: serious > > Hi, > > I didn't investigate this further yet but filing this as RC as it is easy to > reproduce and it's easy to find out that only zlib1g changed using debbisect. > Downgrading to zlib1g 1:1.2.13.dfsg-3 makes the problem go away. Steps to > reproduce: > > $ mmdebstrap --include=tex-common,texlive-base unstable /dev/null > Processing triggers for tex-common (6.18) ... > Running updmap-sys. This may take some time... done. > Running mktexlsr /var/lib/texmf ... done. > Building format(s) --all. > This may take some time... > fmtutil failed. Output has been stored in > /tmp/fmtutil.tcAsaQVq > Please include this file if you report a bug. > > dpkg: error processing package tex-common (--configure): > installed tex-common package post-installation script subprocess returned error exit status 1 > Errors were encountered while processing: > tex-common > E: Sub-process env returned an error code (1) Looks like this was introduced by 1:1.3.dfsg-1, as it can be reproduced in a minimal sid chroot by installing it from https://snapshot.debian.org/archive/debian/20231118T151103Z/pool/main/z/zlib/zlib1g_1.3.dfsg-1_amd64.deb and then installing texlive-base: <...> Processing triggers for tex-common (6.18) ... Running updmap-sys. This may take some time... done. Running mktexlsr /var/lib/texmf ... done. Building format(s) --all. This may take some time... fmtutil failed. Output has been stored in /tmp/fmtutil.ohLhbhu3 Please include this file if you report a bug. dpkg: error processing package tex-common (--configure): installed tex-common package post-installation script subprocess returned error exit status 1 Errors were encountered while processing: tex-common E: Sub-process /usr/bin/dpkg returned an error code (1) # dpkg -l | grep zlib ii zlib1g:amd64 1:1.3.dfsg-1 amd64 compression library - runtime ii zlib1g-dev:amd64 1:1.3.dfsg-1 amd64 compression library - development -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1055510: Best way to coordinate this fix
On Tue, 7 Nov 2023 at 20:04, Francois Marier wrote: > > Hi Luca, > > What's the best way to coordinate a fix for this? > > I assume that we shouldn't upload a new molly-guard packages until the files > have actually moved in the systemd package? > > Should we wait until systemd is in unstable to push a new molly-guard out? Hi, I believe you can upload to unstable straight away, as it would be adding new diversions which should be fine if nothing is there. For confirmation CC'ing Helmut. Kind regards, Luca Boccassi
Bug#1055511: progress-linux-container: diversions need to be updated to deal with DEP17 P3
Package: progress-linux-container Severity: serious User: helm...@debian.org Usertags: dep17p3 Control: affects -1 + systemd-sysv Dear Maintainer(s), systemd-sysv 255~rc1-3, currently in experimental, moves halt/poweroff/reboot/shutdown from /sbin/ to /usr/sbin/, and thus diversions employed by this package fall afoul of DEP17 P3. Please update the diversions as needed. For now, systemd-sysv has an unversioned conflict to avoid data losses. This will be uploaded to unstable this week. As soon as a fixed version of this package is uploaded, the conflict will be changed to versioned. For more details, see: https://subdivi.de/~helmut/dep17.html https://subdivi.de/~helmut/dumat.yaml -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1055510: molly-guard: diversions need to be updated to deal with DEP17 P3
Package: molly-guard Severity: serious User: helm...@debian.org Usertags: dep17p3 Control: affects -1 + systemd-sysv Dear Maintainer(s), systemd-sysv 255~rc1-3, currently in experimental, moves halt/poweroff/reboot/shutdown from /sbin/ to /usr/sbin/, and thus diversions employed by this package fall afoul of DEP17 P3. Please update the diversions as needed. For now, systemd-sysv has an unversioned conflict to avoid data losses. This will be uploaded to unstable this week. As soon as a fixed version of this package is uploaded, the conflict will be changed to versioned. For more details, see: https://subdivi.de/~helmut/dep17.html https://subdivi.de/~helmut/dumat.yaml -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1055509: bfh-container: diversions need to be updated to deal with DEP17 P3
Package: bfh-container Severity: serious User: helm...@debian.org Usertags: dep17p3 Control: affects -1 + systemd-sysv Dear Maintainer(s), systemd-sysv 255~rc1-3, currently in experimental, moves halt/poweroff/reboot/shutdown from /sbin/ to /usr/sbin/, and thus diversions employed by this package fall afoul of DEP17 P3. Please update the diversions as needed. For now, systemd-sysv has an unversioned conflict to avoid data losses. This will be uploaded to unstable this week. As soon as a fixed version of this package is uploaded, the conflict will be changed to versioned. For more details, see: https://subdivi.de/~helmut/dep17.html https://subdivi.de/~helmut/dumat.yaml -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1052915: libdnf: FTBFS: dh_install: error: missing files, aborting
Looks like there was another issue, that only happens on sbuild/buildd but not on pbuilder, a missing "-p" for mkdir in d/rules: >debian/rules override_dh_auto_test > make[1]: Entering directory '/<>' > mkdir '/<>/debian/tests-home' > mkdir: cannot create directory ‘/<>/debian/tests-home’: File > exists > make[1]: *** [debian/rules:52: override_dh_auto_test] Error 1 Uploaded a new NMU, full debdiff attached. -- Kind regards, Luca Boccassi --- libdnf-0.69.0/debian/changelog 2023-01-08 09:08:51.0 + +++ libdnf-0.69.0/debian/changelog 2023-11-03 19:22:17.0 + @@ -1,3 +1,17 @@ +libdnf (0.69.0-2.2) unstable; urgency=medium + + * Non-maintainer upload. + * Use mkdir -p in override_dh_auto_test to fix FTBFS on buildds + + -- Luca Boccassi Fri, 03 Nov 2023 19:22:17 + + +libdnf (0.69.0-2.1) unstable; urgency=medium + + * Non-maintainer upload. + * Move python3 modules from /usr/lib/local/ (Closes: #1052915) + + -- Luca Boccassi Sun, 29 Oct 2023 15:57:28 + + libdnf (0.69.0-2) unstable; urgency=medium * Set myself to maintainer diff -Nru libdnf-0.69.0/debian/python3-hawkey.install libdnf-0.69.0/debian/python3-hawkey.install --- libdnf-0.69.0/debian/python3-hawkey.install 2022-11-12 22:06:07.0 + +++ libdnf-0.69.0/debian/python3-hawkey.install 2023-11-03 19:17:26.0 + @@ -1 +1 @@ -usr/local/lib/python3.*/dist-packages/hawkey +usr/lib/python3/dist-packages/hawkey diff -Nru libdnf-0.69.0/debian/python3-libdnf.install libdnf-0.69.0/debian/python3-libdnf.install --- libdnf-0.69.0/debian/python3-libdnf.install 2022-11-12 22:06:07.0 + +++ libdnf-0.69.0/debian/python3-libdnf.install 2023-11-03 19:17:11.0 + @@ -1 +1 @@ -usr/local/lib/python3.*/dist-packages/libdnf +usr/lib/python3/dist-packages/libdnf diff -Nru libdnf-0.69.0/debian/rules libdnf-0.69.0/debian/rules --- libdnf-0.69.0/debian/rules 2022-11-12 22:05:59.0 + +++ libdnf-0.69.0/debian/rules 2023-11-03 19:21:34.0 + @@ -49,7 +49,7 @@ dh_auto_clean --builddirectory=build override_dh_auto_test: - mkdir '$(CURDIR)/debian/tests-home' + mkdir -p '$(CURDIR)/debian/tests-home' LC_ALL=C HOME='$(CURDIR)/debian/tests-home' dh_auto_test --builddirectory=build -- ARGS='-V' override_dh_missing: signature.asc Description: This is a digitally signed message part
Bug#1055066: usrmerge: Cannot update to version 38 on sbuild
Control: fixed -1 1.0.133 Control: fixed -1 1.0.128+nmu2+deb12u1 Control: fixed -1 1.0.123+deb11u2 Control: close -1 On Tue, 31 Oct 2023 at 08:02, John Paul Adrian Glaubitz wrote: > > Hello! > > I am not sure whether this issue has been fixed. > > We're seeing this issue on buildds and porterboxes on Debian Ports, > regenerating the chroots fails: > > dpkg: warning: ignoring pre-dependency problem! > Preparing to unpack .../tar_1.34+dfsg-1.2_ppc64.deb ... > Unpacking tar (1.34+dfsg-1.2) ... > Selecting previously unselected package usr-is-merged. > Preparing to unpack .../usr-is-merged_38_all.deb ... > > > ** > * > * The usr-is-merged package cannot be installed because this system does > * not have a merged /usr. > * > * Please install the usrmerge package to convert this system to merged-/usr. > * > * For more information please read https://wiki.debian.org/UsrMerge. > * > ** > > > dpkg: error processing archive > /var/cache/apt/archives/usr-is-merged_38_all.deb (--unpack): > new usr-is-merged package pre-installation script subprocess returned error > exit status 1 > Selecting previously unselected package util-linux. > dpkg: regarding .../util-linux_2.39.2-5_ppc64.deb containing util-linux, > pre-dependency problem: > util-linux pre-depends on libblkid1 (>= 2.37.2) > libblkid1:ppc64 is unpacked, but has never been configured. > > Could it be that debootstrap needs to be switched to enabled usrmerge by > default? The buildds have already been updated with a new config ~3 weeks ago: https://lists.debian.org/debian-devel/2023/10/msg00019.html https://lists.debian.org/debian-devel/2023/10/msg00024.html Are the ports buildds managed differently? If so, they either need that change, or to take debootstrap from proposed-updates where the defaults have been switched. There is nothing actionable in debootstrap, as the relevant changes have already been made and uploaded (pending the next stable release to make it out of p-u).
Bug#1052915: libdnf: FTBFS: dh_install: error: missing files, aborting
Control: tags -1 pending On Tue, 26 Sep 2023 15:28:47 +0200 Lucas Nussbaum wrote: > Source: libdnf > Version: 0.69.0-2 > Severity: serious > Justification: FTBFS > Tags: trixie sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20230925 ftbfs-trixie > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. > > > Relevant part (hopefully): > > make[3]: Entering directory '/<>/build' > > make[3]: Nothing to be done for 'preinstall'. > > make[3]: Leaving directory '/<>/build' > > Install the project... > > /usr/bin/cmake -P cmake_install.cmake > > -- Install configuration: "None" > > -- Installing: /<>/debian/tmp/usr/lib/x86_64-linux- gnu/pkgconfig/libdnf.pc > > -- Installing: /<>/debian/tmp/usr/include/libdnf/config.h > > -- Installing: /<>/debian/tmp/usr/include/libdnf/log.hpp > > -- Installing: /<>/debian/tmp/usr/include/libdnf/nevra.hpp > > -- Installing: /<>/debian/tmp/usr/include/libdnf/nsvcap.hpp > > -- Installing: /<>/debian/tmp/usr/include/libdnf/dnf- advisory.h > > -- Installing: /<>/debian/tmp/usr/include/libdnf/dnf- advisorypkg.h > > -- Installing: /<>/debian/tmp/usr/include/libdnf/dnf- advisoryref.h > > -- Installing: /<>/debian/tmp/usr/include/libdnf/dnf- db.h > > -- Installing: /<>/debian/tmp/usr/include/libdnf/dnf- conf.h > > -- Installing: /<>/debian/tmp/usr/include/libdnf/dnf- context.h > > -- Installing: /<>/debian/tmp/usr/include/libdnf/dnf- enums.h > > -- Installing: /<>/debian/tmp/usr/include/libdnf/dnf- goal.h > > -- Installing: /<>/debian/tmp/usr/include/libdnf/dnf- keyring.h > > -- Installing: /<>/debian/tmp/usr/include/libdnf/dnf- lock.h > > -- Installing: /<>/debian/tmp/usr/include/libdnf/dnf- package.h > > -- Installing: /<>/debian/tmp/usr/include/libdnf/dnf- packagedelta.h > > -- Installing: /<>/debian/tmp/usr/include/libdnf/dnf- repo-loader.h > > -- Installing: /<>/debian/tmp/usr/include/libdnf/dnf- rpmts.h > > -- Installing: /<>/debian/tmp/usr/include/libdnf/dnf- sack.h > > -- Installing: /<>/debian/tmp/usr/include/libdnf/dnf- reldep.h > > -- Installing: /<>/debian/tmp/usr/include/libdnf/dnf- reldep-list.h > > -- Installing: /<>/debian/tmp/usr/include/libdnf/dnf- repo.h > > -- Installing: /<>/debian/tmp/usr/include/libdnf/dnf- state.h > > -- Installing: /<>/debian/tmp/usr/include/libdnf/dnf- transaction.h > > -- Installing: /<>/debian/tmp/usr/include/libdnf/dnf- types.h > > -- Installing: /<>/debian/tmp/usr/include/libdnf/dnf- utils.h > > -- Installing: /<>/debian/tmp/usr/include/libdnf/dnf- version.h > > -- Installing: /<>/debian/tmp/usr/include/libdnf/libdnf.h > > -- Installing: /<>/debian/tmp/usr/include/libdnf/hy- goal.h > > -- Installing: /<>/debian/tmp/usr/include/libdnf/hy- nevra.h > > -- Installing: /<>/debian/tmp/usr/include/libdnf/hy- package.h > > -- Installing: /<>/debian/tmp/usr/include/libdnf/hy- packageset.h > > -- Installing: /<>/debian/tmp/usr/include/libdnf/hy- query.h > > -- Installing: /<>/debian/tmp/usr/include/libdnf/hy- repo.h > > -- Installing: /<>/debian/tmp/usr/include/libdnf/hy- selector.h > > -- Installing: /<>/debian/tmp/usr/include/libdnf/hy- subject.h > > -- Installing: /<>/debian/tmp/usr/include/libdnf/hy- types.h > > -- Installing: /<>/debian/tmp/usr/include/libdnf/hy- util.h Uploaded NMU to DELAYED/5 fixing this issue with the attached debdiff. -- Kind regards, Luca Boccassi diff -Nru libdnf-0.69.0/debian/changelog libdnf-0.69.0/debian/changelog --- libdnf-0.69.0/debian/changelog 2023-01-08 09:08:51.0 + +++ libdnf-0.69.0/debian/changelog 2023-10-29 15:57:28.0 + @@ -1,3 +1,10 @@ +libdnf (0.69.0-2.1) unstable; urgency=medium + + * Non-maintainer upload. + * Move python3 modules from /usr/lib/local/ (Closes: #1052915) + + -- Luca Boccassi Sun, 29 Oct 2023 15:57:28 + + libdnf (0.69.0-2) unstable; urgency=medium * Set myself to maintainer diff -Nru libdnf-0.69.0/debian/python3-hawkey.install libdnf-0.69.0/debian/python3-hawkey.install --- libdnf-0.69.0/debian/python3-hawkey.install 2022-11-12 22:06:07.0 + +++ libdnf-0.69.0/debian/python3-hawkey.install 2023-10-29 15:53:24.0 + @@ -1 +1 @@ -usr/local/lib/python3.*/dist-packages/hawkey +usr/lib/python3/dist-packages/hawkey diff -Nru libdnf-0.69.0/debian/python3-libdnf.install libdnf-0.69.0/debian/python3-libdnf.install --- libdnf-0.69.0/debian/python3-libdnf.install 2022-11-12 22:06:07.0 + +++ libdnf-0.69.0/debian/python3-libdnf.install 2023-10-29 15:53:37.0 + @@ -1 +1 @@ -usr/local/lib/python3.*/dist-packages/libdnf +usr/lib/python3/dist-packages/libdnf signature.asc Description: This is a digitally signed message part
Bug#1052911: librepo: FTBFS: dh_install: error: missing files, aborting
Control: tags -1 pending On Tue, 26 Sep 2023 15:28:51 +0200 Lucas Nussbaum wrote: > Source: librepo > Version: 1.14.5-3 > Severity: serious > Justification: FTBFS > Tags: trixie sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20230925 ftbfs-trixie > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. > > > Relevant part (hopefully): > > make[3]: Entering directory '/<>/build' > > make[3]: Nothing to be done for 'preinstall'. > > make[3]: Leaving directory '/<>/build' > > Install the project... > > /usr/bin/cmake -P cmake_install.cmake > > -- Install configuration: "None" > > -- Installing: /<>/debian/tmp/usr/include/librepo/checksum.h > > -- Installing: /<>/debian/tmp/usr/include/librepo/fastestmirror.h > > -- Installing: /<>/debian/tmp/usr/include/librepo/gpg.h > > -- Installing: /<>/debian/tmp/usr/include/librepo/handle.h > > -- Installing: /<>/debian/tmp/usr/include/librepo/librepo.h > > -- Installing: /<>/debian/tmp/usr/include/librepo/metadata_downloader.h > > -- Installing: /<>/debian/tmp/usr/include/librepo/metalink.h > > -- Installing: /<>/debian/tmp/usr/include/librepo/mirrorlist.h > > -- Installing: /<>/debian/tmp/usr/include/librepo/package_downloader.h > > -- Installing: /<>/debian/tmp/usr/include/librepo/rcodes.h > > -- Installing: /<>/debian/tmp/usr/include/librepo/repoconf.h > > -- Installing: /<>/debian/tmp/usr/include/librepo/repomd.h > > -- Installing: /<>/debian/tmp/usr/include/librepo/repoutil_yum.h > > -- Installing: /<>/debian/tmp/usr/include/librepo/result.h > > -- Installing: /<>/debian/tmp/usr/include/librepo/types.h > > -- Installing: /<>/debian/tmp/usr/include/librepo/url_substitution.h > > -- Installing: /<>/debian/tmp/usr/include/librepo/util.h > > -- Installing: /<>/debian/tmp/usr/include/librepo/version.h > > -- Installing: /<>/debian/tmp/usr/include/librepo/xmlparser.h > > -- Installing: /<>/debian/tmp/usr/include/librepo/yum.h > > -- Installing: /<>/debian/tmp/usr/include/librepo/downloader.h > > -- Installing: /<>/debian/tmp/usr/include/librepo/downloader_internal.h > > -- Installing: /<>/debian/tmp/usr/include/librepo/downloadtarget.h > > -- Installing: /<>/debian/tmp/usr/lib/x86_64-linux- gnu/librepo.so.0 > > -- Installing: /<>/debian/tmp/usr/lib/x86_64-linux- gnu/librepo.so > > -- Installing: /<>/debian/tmp/usr/lib/x86_64-linux- gnu/pkgconfig/librepo.pc > > -- Installing: /<>/debian/tmp/usr/lib/python3/dist- packages/librepo/__init__.py > > -- Installing: /<>/debian/tmp/usr/lib/python3/dist- packages/librepo/_librepo.so > > make[2]: Leaving directory '/<>/build' > > # Use system-provides files. > > rm -fv 'build/doc/python/_static/jquery.js' \ > > 'build/doc/python/_static/underscore.js' \ > > 'build/doc/c/html/jquery.js' \ > > 'build/doc/python/_static/doctools.js' \ > > 'build/doc/python/_static/language_data.js' \ > > 'build/doc/python/_static/searchtools.js' > > removed 'build/doc/python/_static/jquery.js' > > removed 'build/doc/python/_static/underscore.js' > > removed 'build/doc/c/html/jquery.js' Uploaded NMU to DELAYED/5 fixing this issue with the attached debdiff. -- Kind regards, Luca Boccassi diff -Nru librepo-1.14.5/debian/changelog librepo-1.14.5/debian/changelog --- librepo-1.14.5/debian/changelog 2023-01-10 08:23:24.0 + +++ librepo-1.14.5/debian/changelog 2023-10-29 15:42:43.0 + @@ -1,3 +1,10 @@ +librepo (1.14.5-3.1) unstable; urgency=medium + + * Non-maintainer upload. + * Move python3 modules from /usr/lib/local/ (Closes: #1052911) + + -- Luca Boccassi Sun, 29 Oct 2023 15:42:43 + + librepo (1.14.5-3) unstable; urgency=medium * Update patch for test_yum_package_downloading.py thanks to diff -Nru librepo-1.14.5/debian/python3-librepo.install librepo-1.14.5/debian/python3-librepo.install --- librepo-1.14.5/debian/python3-librepo.install 2022-11-13 08:26:30.0 + +++ librepo-1.14.5/debian/python3-librepo.install 2023-10-29 15:42:22.0 + @@ -1 +1 @@ -usr/local/lib/python3.* +usr/lib/python3 signature.asc Description: This is a digitally signed message part
Bug#1052913: libcomps: FTBFS: dh_install: error: missing files, aborting
Control: tags -1 pending On Tue, 26 Sep 2023 15:28:41 +0200 Lucas Nussbaum wrote: > Source: libcomps > Version: 0.1.19-2 > Severity: serious > Justification: FTBFS > Tags: trixie sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20230925 ftbfs-trixie > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. > > > Relevant part (hopefully): > > make[3]: Entering directory '/<>/build' > > make[3]: Nothing to be done for 'preinstall'. > > make[3]: Leaving directory '/<>/build' > > Install the project... > > /usr/bin/cmake -P cmake_install.cmake > > -- Install configuration: "None" > > -- Installing: /<>/debian/tmp/usr/lib/x86_64-linux- gnu/libcomps.so.0 > > -- Installing: /<>/debian/tmp/usr/lib/x86_64-linux- gnu/libcomps.so > > -- Installing: /<>/debian/tmp/usr/include/libcomps/comps_doc.h > > -- Installing: /<>/debian/tmp/usr/include/libcomps/comps_docgroup.h > > -- Installing: /<>/debian/tmp/usr/include/libcomps/comps_doccategory.h > > -- Installing: /<>/debian/tmp/usr/include/libcomps/comps_docenv.h > > -- Installing: /<>/debian/tmp/usr/include/libcomps/comps_docpackage.h > > -- Installing: /<>/debian/tmp/usr/include/libcomps/comps_docgroupid.h > > -- Installing: /<>/debian/tmp/usr/include/libcomps/comps_obj.h > > -- Installing: /<>/debian/tmp/usr/include/libcomps/comps_mm.h > > -- Installing: /<>/debian/tmp/usr/include/libcomps/comps_hslist.h > > -- Installing: /<>/debian/tmp/usr/include/libcomps/comps_dict.h > > -- Installing: /<>/debian/tmp/usr/include/libcomps/comps_objradix.h > > -- Installing: /<>/debian/tmp/usr/include/libcomps/comps_objmradix.h > > -- Installing: /<>/debian/tmp/usr/include/libcomps/comps_objdict.h > > -- Installing: /<>/debian/tmp/usr/include/libcomps/comps_objlist.h > > -- Installing: /<>/debian/tmp/usr/include/libcomps/comps_elem.h > > -- Installing: /<>/debian/tmp/usr/include/libcomps/comps_radix.h > > -- Installing: /<>/debian/tmp/usr/include/libcomps/comps_mradix.h > > -- Installing: /<>/debian/tmp/usr/include/libcomps/comps_bradix.h > > -- Installing: /<>/debian/tmp/usr/include/libcomps/comps_set.h > > -- Installing: /<>/debian/tmp/usr/include/libcomps/comps_parse.h > > -- Installing: /<>/debian/tmp/usr/include/libcomps/comps_log.h > > -- Installing: /<>/debian/tmp/usr/include/libcomps/comps_default.h > > -- Installing: /<>/debian/tmp/usr/include/libcomps/comps_utils.h > > -- Installing: /<>/debian/tmp/usr/include/libcomps/comps_validate.h > > -- Installing: /<>/debian/tmp/usr/include/libcomps/comps_log_codes.h > > -- Up-to-date: /<>/debian/tmp/usr/lib/x86_64-linux- gnu/libcomps.so.0 > > -- Up-to-date: /<>/debian/tmp/usr/lib/x86_64-linux- gnu/libcomps.so > > -- Installing: /<>/debian/tmp/usr/lib/x86_64-linux- gnu/pkgconfig/libcomps.pc > > -- Up-to-date: /<>/debian/tmp/usr/lib/x86_64-linux- gnu/pkgconfig/libcomps.pc > > -- Installing: /<>/debian/tmp/usr/lib/python3/dist- packages/libcomps/__init__.py > > -- Installing: /<>/debian/tmp/usr/lib/python3/dist- packages/libcomps/_libpycomps.so > > running install_egg_info > > /usr/lib/python3/dist-packages/setuptools/_distutils/cmd.py:66: SetuptoolsDeprecationWarning: setup.py install is deprecated. > > !! Uploaded NMU to DELAYED/5 fixing this issue with the attached debdiff. -- Kind regards, Luca Boccassi diff -Nru libcomps-0.1.19/debian/changelog libcomps-0.1.19/debian/changelog --- libcomps-0.1.19/debian/changelog 2023-01-07 19:04:37.0 + +++ libcomps-0.1.19/debian/changelog 2023-10-29 15:32:45.0 + @@ -1,3 +1,10 @@ +libcomps (0.1.19-2.1) unstable; urgency=medium + + * Non-maintainer upload. + * Move python3 modules from /usr/lib/local/ (Closes: #1052913) + + -- Luca Boccassi Sun, 29 Oct 2023 15:32:45 + + libcomps (0.1.19-2) unstable; urgency=medium * Set myself to maintainer. diff -Nru libcomps-0.1.19/debian/python3-libcomps.install libcomps-0.1.19/debian/python3-libcomps.install --- libcomps-0.1.19/debian/python3-libcomps.install 2022-11-13 08:29:48.0 + +++ libcomps-0.1.19/debian/python3-libcomps.install 2023-10-29 15:31:40.0 + @@ -1 +1 @@ -usr/local/lib/python3.* +usr/lib/python3* signature.asc Description: This is a digitally signed message part
Bug#1040901: Upcoming changes to Debian Linux kernel packages
On Fri, 27 Oct 2023 20:09:57 +0200 Bastian Blank wrote: > On Fri, Oct 27, 2023 at 01:04:00PM +0300, Adrian Bunk wrote: > > > Sadly in Debian there is no way to make that happen. Think for example > > > about bin-nmu. > > Could you give a complete list of problems? > > There are at least those problems: > - Bin-nmu can't change binary package names. > - There is no way to embed a Debian version into a Debian package name > without loss. (Okay, I think we would only need ~, all the othe > characters are allowed) > > Bastian This whole discussion to me even more strongly suggests that the current way of trying to satisfy these requirements on kernels availability shouldn't really be delegated only to packages content. And that's before we get into ESP size issues. So the idea to split these apart - packages install to /usr/, and a separate mechanism manages what is available under /boot/ and for how long, depending also on how much space there is - seems more and more the right way forward. Just my 2c. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1054533: nvme-stas: autopkgtest fails on all architectures
Source: nvme-stas Version: 2.3-1 Severity: serious Justification: autopkgtest fails, blocking reverse dependencies migrations 36s autopkgtest [21:22:19]: test unittest: cp -r test "$AUTOPKGTEST_TMP" && cd "$AUTOPKGTEST_TMP/test" && rm test-avahi.py && python3 -m unittest -v test*.py 36s autopkgtest [21:22:19]: test unittest: [--- 36s Error reading mandatory Host NQN (see stasadm --help): [Errno 2] No such file or directory: '/etc/nvme/hostnqn' https://ci.debian.net/data/autopkgtest/testing/amd64/n/nvme-stas/39251054/log.gz This is blocking iproute2's migration from unstable to testing, hence filing at high severity. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1052847: fixed in python-marshmallow 3.20.1-1
On Tue, 10 Oct 2023 07:49:21 + Debian FTP Masters wrote: > Source: python-marshmallow > Source-Version: 3.20.1-1 > Done: Federico Ceratto > > We believe that the bug you reported is fixed in the latest version of > python-marshmallow, 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 1052...@bugs.debian.org, > and the maintainer will reopen the bug report if appropriate. > > Debian distribution maintenance software > pp. > Federico Ceratto (supplier of updated python- marshmallow 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: Sun, 08 Oct 2023 15:44:04 +0200 > Source: python-marshmallow > Binary: python3-marshmallow python3-marshmallow-doc > Architecture: source all > Version: 3.20.1-1 > Distribution: unstable > Urgency: medium > Maintainer: Federico Ceratto > Changed-By: Federico Ceratto > Description: > python3-marshmallow - Lightweight library for converting complex datatypes > python3-marshmallow-doc - Library for converting complex datatypes - documentation > Closes: 1052847 > Changes: > python-marshmallow (3.20.1-1) unstable; urgency=medium > . > * New upstream release > * Add tzdata-legacy dependency (Closes: #1052847) > Checksums-Sha1: > d071d76b4927a7dd9977a679731177a728ffec17 2231 python- marshmallow_3.20.1-1.dsc > b7c0b0ab3e920d0be51a2781494572be50497256 183404 python- marshmallow_3.20.1.orig.tar.gz > 0897439bc42faacd2cc589019b230a2105fb24ca 3416 python- marshmallow_3.20.1-1.debian.tar.xz > 52cae8744d027eda054153839f2531640196bbc6 8173 python- marshmallow_3.20.1-1_amd64.buildinfo > de04d18ad70a546ceda5ee7b43133a58c8f1934e 206608 python3-marshmallow- doc_3.20.1-1_all.deb > 91df8b952bcc1c2b1cb3147e0fd6374d53f763c4 67344 python3- marshmallow_3.20.1-1_all.deb > Checksums-Sha256: > e7b4a412db99f1cfe0085d5ca6f7053804a773bc9d6223724b945889ca523dd7 2231 python-marshmallow_3.20.1-1.dsc > 1f37696dea0b6d4a9de04459ba694106531c42179547b286c81113e02234d1bf 183404 python-marshmallow_3.20.1.orig.tar.gz > 0cdd5c67f3f622d0bd7fab8cde497a149867cbde65c5440dd66cbb9f57f0d02b 3416 python-marshmallow_3.20.1-1.debian.tar.xz > c3966faf26c25ac7696bfec0d96bc76a8a96742a04830f7ec8f0ce8656dc70c9 8173 python-marshmallow_3.20.1-1_amd64.buildinfo > 02ca24d9e18b15a09b06e1c27df34eff09947bb7ba9270ef8cc705ecb0a5ac12 206608 python3-marshmallow-doc_3.20.1-1_all.deb > c03f1923160bbba80b5823dd7310c185cbabef9fe723ba1be1c2f009a8003158 67344 python3-marshmallow_3.20.1-1_all.deb > Files: Federico, This was done as a binary upload, so it cannot migrate to testing. A bunch of stuff is going to be autoremoved soon because of this. Was that intentional? Could you please do a source-only upload? -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1053301: udev.postinst removes valid /etc/rc*.d/ symlinks
Control: severity -1 minor On Wed, 4 Oct 2023 22:00:06 +0100 Mark Hindley wrote: > Control: tags -1 patch > Control: affects -1 initscripts > Control: severity -1 serious > Justification: Breaks unrelated packages, breaks non-systemd boot > > Michael, > > Please find a patch below that addresses this issue in my test setup. I can > offer to NMU if you would like? > > I have provided an easy means to reproduce the bug and a clear justfication for > why I think this is an RC bug. If you disagree, please explain why, rather than > just changing the severity. Thanks. If you want to see your changes merged, I would recommend to stop playing games with severity and send a MR on Salsa instead. It will be quicker, easier and much more effective. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1053289: marked as pending in libzypp
Control: tag -1 pending Hello, Bug #1053289 in libzypp 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/libzypp/-/commit/dab4ac1337cd226d080ad38b4ce902cf0b1419f5 Disable flaky tests These tests often fail on slow or overloaded machines, so disable them Closes: #1053289 (this message was generated automatically) -- Greetings https://bugs.debian.org/1053289
Bug#1052548: smcroute: 'is-system-running' check in autopkgtest breaks on unrelated system changes
Package: smcroute Version: 2.5.6-1 Severity: serious Justification: stops other packages from migrating to testing Tags: patch pending X-Debbugs-Cc: pkg-systemd-maintain...@lists.alioth.debian.org Dear Maintainer(s), The autopkgtest does not actually use the systemd service, it calls the legacy script by hand. Also checking 'is-system-running' is incorrect, as that might be influenced by random unrelated fluctuations from other services, that have nothing to do with smcroute. The immediate solution is to drop the check from the test. Given this is blocking systemd from migrating to testing, high severity is set, and I have already uploaded an NMU to DELAYED/3. I have opened an MR against Salsa with the changes. Debdiff also attached. MR: https://salsa.debian.org/debian/smcroute/-/merge_requests/3 Failing log: https://ci.debian.net/data/autopkgtest/testing/amd64/s/smcroute/38108679/log.gz If you think there is a better solution please let me know and I'll cancel the deferred NMU, but we'd appreciate a swift resolution given it blocks migration. Thanks! -- Kind regards, Luca Boccassi diff -Nru smcroute-2.5.6/debian/changelog smcroute-2.5.6/debian/changelog --- smcroute-2.5.6/debian/changelog 2023-01-08 13:02:40.0 + +++ smcroute-2.5.6/debian/changelog 2023-09-24 13:34:21.0 +0100 @@ -1,3 +1,10 @@ +smcroute (2.5.6-1.1) unstable; urgency=medium + + * Non-maintainer upload. + * autopkgtest: drop is-system-running check (Closes: #) + + -- Luca Boccassi Sun, 24 Sep 2023 13:34:21 +0100 + smcroute (2.5.6-1) unstable; urgency=medium * New upstream version 2.5.6. diff -Nru smcroute-2.5.6/debian/tests/daemon-init-scripts smcroute-2.5.6/debian/tests/daemon-init-scripts --- smcroute-2.5.6/debian/tests/daemon-init-scripts 2021-09-25 13:28:23.0 +0100 +++ smcroute-2.5.6/debian/tests/daemon-init-scripts 2023-09-24 13:34:21.0 +0100 @@ -28,7 +28,7 @@ return $smcroute_pid; } -plan tests => 13; +plan tests => 11; # Work around test harness, start smcrouted if not already running my $startup = capture EXIT_ANY, INIT_SCRIPT, 'start'; @@ -43,11 +43,6 @@ is $EXITVAL, 0, "stopping smcroute"; my $smcroute_pid = get_smcrouted_pid 'stopped'; is $EXITVAL, 1, "smcroute is really stopped".( $EXITVAL ? '' : " (pid $smcroute_pid)" ); -SKIP: { -skip "System not managed by systemd", 1 unless -e '/run/systemd/system'; -my $wait_output = capture EXIT_ANY, 'systemctl', 'is-system-running', '--wait'; chomp $wait_output; -is $wait_output, "running", "Stopping smcroute completed"; -} my $double_stop_output = capture EXIT_ANY, INIT_SCRIPT, 'stop'; is $EXITVAL, 0, "stopping smcroute twice in a row"; @@ -57,11 +52,6 @@ # Try to start the daemon again my $start_output = capture EXIT_ANY, INIT_SCRIPT, 'start'; is $EXITVAL, 0, "starting smcroute"; -SKIP: { -skip "System not managed by systemd", 1 unless -e '/run/systemd/system'; -my $wait_output = capture EXIT_ANY, 'systemctl', 'is-system-running', '--wait'; chomp $wait_output; -is $wait_output, "running", "Starting smcroute completed"; -} my $new_smcroute_pid = get_smcrouted_pid 'running'; is $EXITVAL, 0, "smcroute is really running".( $EXITVAL ? '' : " (pid $new_smcroute_pid)" ); isnt $new_smcroute_pid, $initial_smcroute_pid, "smcroute pid changed ($new_smcroute_pid != $initial_smcroute_pid)"; signature.asc Description: This is a digitally signed message part
Bug#1042338: dnf: FTBFS: dh_auto_test: error: cd build && make -j8 test ARGS\+=--verbose ARGS\+=-j8 ARGS=-VV returned exit code 2
Control: tags -1 pending On Wed, 26 Jul 2023 22:20:02 +0200 Lucas Nussbaum wrote: > Source: dnf > Version: 4.14.0-4 > Severity: serious > Justification: FTBFS > Tags: trixie sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20230726 ftbfs-trixie > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. This looks like a crash when logging, probably due to a new version of python3 or sqlite. I've pushed an NMU disabling build-time tests to DELAYED/3 so that we can get dnf back in testing, as it works fine. Debdiff: diff -Nru dnf-4.14.0/debian/changelog dnf-4.14.0/debian/changelog --- dnf-4.14.0/debian/changelog 2023-05-23 08:08:24.0 +0100 +++ dnf-4.14.0/debian/changelog 2023-09-19 10:30:15.0 +0100 @@ -1,3 +1,11 @@ +dnf (4.14.0-4.1) unstable; urgency=medium + + * Non-maintainer upload. + * Disable build tests, python3/sqlite3 are crashing while logging. + (Closes: #1042338) + + -- Luca Boccassi Tue, 19 Sep 2023 10:30:15 +0100 + dnf (4.14.0-4) unstable; urgency=medium * Fix default DNF const PYTNON_INSTALL_DIR. Closes: #1034828. diff -Nru dnf-4.14.0/debian/rules dnf-4.14.0/debian/rules --- dnf-4.14.0/debian/rules 2023-05-23 08:08:24.0 +0100 +++ dnf-4.14.0/debian/rules 2023-09-19 10:30:00.0 +0100 @@ -56,9 +56,11 @@ # Maybe rip that out. # When building with sbuild, users do not have a home directory if /home is # shadowed. Replace HOME with a known directory. +# Tests are failing with new python/sqlite3 due to a segfault when logging, +# disable them for now. See: https://bugs.debian.org/1042338 override_dh_auto_test: - mkdir '$(CURDIR)/debian/tests-home' - TERM='xterm' HOME='$(CURDIR)/debian/tests-home' dh_auto_test --builddirectory=build -- ARGS='-VV' +# mkdir '$(CURDIR)/debian/tests-home' +# TERM='xterm' HOME='$(CURDIR)/debian/tests-home' dh_auto_test --builddirectory=build -- ARGS='-VV' override_dh_missing: dh_missing --fail-missing Full decoded backtrace: #0 __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:76 #1 0x77d066c9 in __printf_buffer (buf=buf@entry=0x7fffae50, format=0x761a6b0a "%s: %s: %s\n", ap=0x7fffaf40, mode_flags=2) at ./stdio-common/vfprintf-process-arg.c:435 #2 0x77d272d2 in __vsnprintf_internal (string=string@entry=0x0, maxlen=maxlen@entry=0, format=format@entry=0x761a6b0a "%s: %s: %s\n", args=args@entry=0x7fffaf40, mode_flags=mode_flags@entry=2) at ./libio/vsnprintf.c:96 #3 0x77dc08a4 in ___vsnprintf_chk (s=s@entry=0x0, maxlen=maxlen@entry=0, flag=flag@entry=1, slen=slen@entry=18446744073709551615, format=format@entry=0x761a6b0a "%s: %s: %s\n", ap=ap@entry=0x7fffaf40) at ./debug/vsnprintf_chk.c:34 #4 0x76127197 in vsnprintf (__ap=0x7fffaf40, __fmt=0x761a6b0a "%s: %s: %s\n", __n=0, __s=0x0) at /usr/include/x86_64-linux-gnu/bits/stdio2.h:68 #5 rpmlog (code=4, fmt=0x761a6b0a "%s: %s: %s\n") at ./rpmio/rpmlog.c:446 #6 0x760692f7 in renderLogMsg (iErrCode=283, zFormat=, ap=ap@entry=0x7fffb180) at ./src/printf.c:1315 #7 0x760693c7 in sqlite3_log (iErrCode=iErrCode@entry=283, zFormat=zFormat@entry=0x760cf268 "recovered %d frames from WAL file %s") at ./src/printf.c:1326 #8 0x760ac56d in walIndexRecover (pWal=0x11ff868) at ./src/wal.c:1589 #9 walIndexReadHdr (pWal=pWal@entry=0x11ff868, pChanged=pChanged@entry=0x7fffb42c) at ./src/wal.c:2694 #10 0x760aceab in walTryBeginRead (pWal=pWal@entry=0x11ff868, pChanged=pChanged@entry=0x7fffb42c, useWal=useWal@entry=0, cnt=cnt@entry=1) at ./src/wal.c:2996 #11 0x760ad362 in walBeginReadTransaction (pChanged=0x7fffb42c, pWal=0x11ff868) at ./src/wal.c:3302 #12 sqlite3WalBeginReadTransaction (pWal=0x11ff868, pChanged=pChanged@entry=0x7fffb42c) at ./src/wal.c:3386 #13 0x7605b61e in pagerBeginReadTransaction (pPager=0x11f3c58) at ./src/pager.c:3209 #14 sqlite3PagerSharedLock (pPager=0x11f3c58) at ./src/pager.c:5373 #15 0x75fd6d38 in lockBtree (pBt=0x121cae8) at ./src/btree.c:3228 #16 btreeBeginTrans (p=0x1193ea8, wrflag=0, pSchemaVersion=0x0) at ./src/btree.c:3625 #17 0x75fddadf in sqlite3BtreeBeginTrans (p=, wrflag=wrflag@entry=0, pSchemaVersion=pSchemaVersion@entry=0x0) at ./src/btree.c:3718 #18 0x760662ad in sqlite3InitOne (db=0x12124a8, iDb=iDb@entry=0, pzErrMsg=pzErrMsg@entry=0x7fffb938, mFlags=mFlags@entry=0) at ./src/prepare.c:261 #19 0x760664d4 in sqlite3Init (db=db@entry=0x12124a8, pzErrMsg=pzErrMsg@entry=0x7fffb938) at ./src/prepare.c:455 #20 0x7606651f in sqlite3ReadSchema (pParse=pParse@entry=0x7fffb930) at ./src/prepare.c:481 #21 0x7
Bug#1051577: iproute2: obsolete conffiles
On Wed, 13 Sept 2023 at 10:44, Ian Campbell wrote: > > On Tue, 2023-09-12 at 23:13 +0200, Luca Boccassi wrote: > > On Mon, 11 Sept 2023 at 15:57, Daniel Gröber > > wrote: > > > > > > Hi Luca, > > > > > > On Mon, Sep 11, 2023 at 01:06:06PM +0100, Luca Boccassi wrote: > > > > > I want to question whether removing these conffiles is a good idea at > > > > > all. I'm probably one of the few people that actually muck around in > > > > > there > > > > > but it seems like this is going to break things for any users that do. > > > > > > > > As far as I understand dpkg's conffile machinery should recognize if > > > > you changed anything, and leave it in place. Upstream moved the > > > > default ones to /usr, so we just follow what they do. > > > > > > Right. Think of an admin having to adjust these config files though: > > > previously they could just `editor /etc/iproute2/rt_tables` and get on > > > with > > > things. Now anyone needing to do that will have to do a doubletake, figure > > > out why /etc/iproute2 is missing, realize that it's at /usr/lib/iproute2 > > > now, copy that over and finally edit. > > > > > > Is that friction really warrented to cater to a specialized niche > > > use-case? > > > > > > Please consider overriding upstream's decision here. > > > > Yes, it is warranted, both because it's exactly the correct behaviour > > for a package, and also because we are certainly not spending time and > > resources to go against upstream choices, especially when they are the > > right choices. > > What is the plan for handling updates? AIUI we've lost the dpkg > conffile handling but it doesn't look like it's been replaced by > anything (e.g. like using ucf to prompt when an update happened > perhaps?). Same as everything else that uses drop-ins and hermetic-usr since forever. No more pointless noise and wasting time solving conflicts by hand in whitespace changes, comment typos and so on.
Bug#1051577: iproute2: obsolete conffiles
On Mon, 11 Sept 2023 at 15:57, Daniel Gröber wrote: > > Hi Luca, > > On Mon, Sep 11, 2023 at 01:06:06PM +0100, Luca Boccassi wrote: > > > I want to question whether removing these conffiles is a good idea at > > > all. I'm probably one of the few people that actually muck around in there > > > but it seems like this is going to break things for any users that do. > > > > As far as I understand dpkg's conffile machinery should recognize if > > you changed anything, and leave it in place. Upstream moved the > > default ones to /usr, so we just follow what they do. > > Right. Think of an admin having to adjust these config files though: > previously they could just `editor /etc/iproute2/rt_tables` and get on with > things. Now anyone needing to do that will have to do a doubletake, figure > out why /etc/iproute2 is missing, realize that it's at /usr/lib/iproute2 > now, copy that over and finally edit. > > Is that friction really warrented to cater to a specialized niche use-case? > > Please consider overriding upstream's decision here. Yes, it is warranted, both because it's exactly the correct behaviour for a package, and also because we are certainly not spending time and resources to go against upstream choices, especially when they are the right choices.
Bug#1033167: usrmerge: messes with /etc/shells
On Thu, 22 Jun 2023 22:52:53 +0200 Andreas Beckmann wrote: > Hi Marco, > > two questions about convert-etc-shells: > > 1.) why does usrmerge.postinst call /usr/lib/usrmerge/convert-etc- shells > (nearly) unconditionally (i.e. on every upgrade of the usrmerge > package)? Shouldn't that be a one-shot update and therefore be called at > the end of maybe_convert (from within maybe_convert, not after), s.t. it > is skipped if the system is already converted? > > 2.) can you call update-shells from within convert-etc-shells (or from > usrmerge.postinst directly before calling convert-etc-shells), s.t. most > of the /etc/shells modifications are performed by update-shells and the > state file /var/lib/shells.state gets updated properly? > > I have just uploaded a NMU for debianutils to DELAYED/10 that fixes some > issues (#1035820) and maybe makes convert-etc-shells superfluous. Hello Andreas and Helmut, Is there anything left to do here after Andreas' NMU fixing https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035820 last month, or can we close this? -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1043583: systemd-boot postinst update causes EFI crash
Control: severity -1 minor Control: tags -1 moreinfo On Sun, 13 Aug 2023 12:59:07 +0300 Maria Lisina wrote: > Package: systemd-boot > Version: 252.12-1~deb12u1 > Severity: critical > Tags: patch > Justification: breaks unrelated software > X-Debbugs-Cc: sekoohaka.sari...@gmail.com > > Dear Maintainer, when systemd-boot updates and if bootctl is- installed reports > 0, it runs bootctl update --graceful without --no-variables option. It causes > EFI crash on my machine because it doesn't support nvram. Official systemd-boot > update service has this option (/usr/lib/systemd/system/systemd-boot- > update.service:21). I think it should be added to postints too. Which hardware is that? And what does 'EFI crash' mean exactly? What's the output of 'SYSTEMD_LOG_LEVEL=debug bootctl update' ? -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1041476: systemd: keep 254-rcX out of testing
Source: systemd Version: 254~rc2-3 Severity: grave Let's avoid having release candidates reach testing, even after autopkgtest is happy. Apparently setting the urgency in the changelog entry does not work anymore... -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1041207: debootstrap: bad NMU produces buildds not supported by dpkg _and_ CTTE
On Sun, 16 Jul 2023 12:54:35 +0100 Simon McVittie wrote: > On Sun, 16 Jul 2023 at 12:42:11 +0100, Luca Boccassi wrote: > > In the meanwhile, I'll immediately revert the sabotage. > > Both of you, please don't turn this into an NMU war in the archive: > that doesn't benefit anyone. I would have preferred it if Adam had not > immediately uploaded a 0-day revert, but preserving the status quo from > bookworm is not the worst state to be in while we discuss this. > > If Adam's concerns about this change are valid, then we should address > them, either by doing something different in debootstrap or by reporting > bugs against affected packages. > > If Adam's concerns about this change turn out to be unfounded, then we > should reinstate my change (as NMU'd by Luca) in a calm and considered > way, and all we will have lost is a few days of progress and a few bytes > of changelog. I have already reverted the hostile and unwarranted NMU before you replied. And that is the right thing to do: the correct procedure when there is a suspicion that a change breaks something is not to do a 0- day revert without telling anybody, it's to file a bug _AND_ CC the involved people, and wait until there is an answer, while providing evidence of the actual issue. As you already correctly noted, there is zero evidence of any issue presented in this bug, and the stated 'reason' is wrong anyway: debootstrap from unstable/testing is NOT used to build packages for unstable/testing. This would have been trivial to find out for the reporter. So as with normal procedure, the change will stand where it is, and if there is evidence of any actual issues it can be revisited later. Blocking other people's progress with work that has the consensus of both the project and the CTTE and force them to spend days or weeks or months proving negatives is not an acceptable procedure. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1041207: debootstrap: bad NMU produces buildds not supported by dpkg _and_ CTTE
On Sat, 15 Jul 2023 18:27:24 +0200 Adam Borowski wrote: > Package: debootstrap > Version: 1.0.128+nmu3 > Severity: grave > > bluca's NMU on 2023-07-15 makes debootstrap produce chroots using the > aliased-dirs scheme. While it's currently the default scheme for non-buildd > systems, it is both not supported by dpkg (with no solution in sight), but > is also likely to produce packages that are explicitely forbidden by a > recent CTTE ruling that disallows moving files between directories aliased > by the current usrmerge scheme. > > Quoting the still unsolving issues is pointless (you can read about them > in massive threads in a number of places) as bluca seems to be ignoring > them completely. > > But, what matters here is the CTTE ruling in #1035831 -- for the time > being, > packages must not move files between locations affected by the > aliasing. If there is somebody who's ignoring things, that would be yourself, given this change has been not only been explicitly requested, but even provided _BY_ the CTTE, as you would have easily found out if you actually went and checked: https://salsa.debian.org/installer-team/debootstrap/-/merge_requests/93 http://meetbot.debian.net/debian-ctte/2023/debian-ctte.2023-07-11-17.58.log.html Debian Community Team, Adam is once again sabotaging the CTTE's work with hostile NMUs, could you please intervene? Thank you. In the meanwhile, I'll immediately revert the sabotage. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1040790: installation-reports: ID in /etc/machine-id and /var/lib/dbus/machine-id mismatch on fresh debian 12 installation
On Tue, 11 Jul 2023 at 14:14, Simon McVittie wrote: > > Control: reassign -1 src:dbus 1.12.20-3 > > On Mon, 10 Jul 2023 at 18:43:06 +0100, Luca Boccassi wrote: > > As a wild guess, maybe the split of src:dbus into multiple packages > > affected the order in which the postinsts run, and now systemd's runs > > first and creates /etc/machine-id, and then dbus-daemon's runs and > > creates /var/lib/dbus/machine-id. > > The ordering here is not *meant* to matter, because dbus-uuidgen is meant > to copy /etc/machine-id if it already exists and has suitable contents, > and systemd-machine-id-setup is meant to copy /var/lib/dbus/machine-id > if *that* already exists and has suitable contents. > > > mkdir -p "${DPKG_ROOT:-/}var/lib/dbus" > > dbus-uuidgen --ensure="${DPKG_ROOT:-/}var/lib/dbus/machine-id" > > I think the regression here is that in attempting to respect DPKG_ROOT, > I replaced dbus-uuidgen --ensure (which copies an existing systemd > machine ID if one exists) with dbus-uuidgen --ensure=PATH (which doesn't). > This was at the same time as the split into dbus.deb / dbus-daemon.deb, > but it was an orthogonal change. bullseye is unaffected, bookworm is the > first release with this. > > I'm sorry that it took so long to notice this. I should have had test > coverage that would have detected this error. Ah that explains it, thanks > > There is a tmpfiles.d shipped by dbus-daemon that creates > > /var/lib/dbus/machine-id as a symlink to /etc/machine-id if it exists, > > but this snippet runs _after_ the dbus-uuidgen so effectively it is > > always a no-op on package install: > > As an upstream, this is clearly the right thing to do, but as a > downstream, I'm intentionally not relying on it as load-bearing by > default. There is nothing in Debian that guarantees that /etc/machine-id > will be created, unless we happen to be booting with systemd, which > isn't guaranteed; and if it did get created, as far as I can see, there > is technically also nothing that guarantees that it won't subsequently > be deleted. > > https://bugs.debian.org/745876 proposed creating the machine ID in > base-files as a basic Debian feature that any package can rely on, > but it was closed as wontfix. > > See also https://bugs.debian.org/783716 for more background. > > Of course, d-i doesn't provide a way to not install systemd-sysv, but > a vocal minority of users and developers use non-default installation > mechanisms to get a different init system and consider that to be > a critically important use-case; and I'm concerned that even if these > users got a machine ID generated during installation, they would delete > it as a perceived systemd'ism, and then complain loudly in the form of > RC bugs when D-Bus doesn't work because /var/lib/dbus/machine-id is now > a dangling symlink. Well, I don't think we should make the 99.5% of cases more fragile to cater to an entirely hypothetical 0.5% that would actively damage their own installation by deleting OS files for no good reason. If someone wants to mess manually with /etc/machine-id and /var/lib/dbus/machine-id it's fair that they are allowed to do that, but it's also fair to tell them that they get to keep the pieces. Kind regards, Luca Boccassi
Bug#1040790: installation-reports: ID in /etc/machine-id and /var/lib/dbus/machine-id mismatch on fresh debian 12 installation
On Mon, 10 Jul 2023 17:14:48 +0100 Steve McIntyre wrote: > Hi, and thanks for your bug report! > > On Mon, Jul 10, 2023 at 05:27:50PM +0200, yogg wrote: > >Package: installation-reports > >Severity: serious > >Tags: d-i > >Justification: https://wiki.debian.org/MachineId > > > > ... > > >After installation was finished and the system has been restarted the > >files "/etc/machine-id" and "/var/lib/dbus/machine-id" are not linked > >in any way (no soft or hardlink) and the ID inside the files differ > >from each other. > > I've confirmed this bug just now, doing a clean installation from the > 12.0.0 amd64 netinst. As a wild guess, maybe the split of src:dbus into multiple packages affected the order in which the postinsts run, and now systemd's runs first and creates /etc/machine-id, and then dbus-daemon's runs and creates /var/lib/dbus/machine-id. There is a tmpfiles.d shipped by dbus-daemon that creates /var/lib/dbus/machine-id as a symlink to /etc/machine-id if it exists, but this snippet runs _after_ the dbus-uuidgen so effectively it is always a no-op on package install: $ cat /var/lib/dpkg/info/dbus-daemon.postinst #!/bin/sh set -e if [ "$1" = configure ]; then # This is idempotent, so it's OK to do every time. The system bus' init # script does this anyway, but you also have to do this before a session # bus will work on non-systemd systems, so we do this here for the # benefit of people starting a temporary session bus in a chroot. mkdir -p "${DPKG_ROOT:-/}var/lib/dbus" dbus-uuidgen --ensure="${DPKG_ROOT:-/}var/lib/dbus/machine-id" fi # Automatically added by dh_installtmpfiles/13.11.4 if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ] || [ "$1" = "abort-deconfigure" ] || [ "$1" = "abort-remove" ] ; then if [ -x "$(command -v systemd-tmpfiles)" ]; then systemd-tmpfiles ${DPKG_ROOT:+--root="$DPKG_ROOT"} --create dbus.conf >/dev/null || true fi fi # End automatically added section It seems to me a safe way to fix this and do the right thing is to swap the #DEBHELPER# token and the manual dbus-uuidgen block in dbus- daemon's postinst. Then on systemd systems the tmpfiles will win and on other systems dbus-uuidgen will do its job. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1040406: closed by Debian FTP Masters (reply to Luca Boccassi ) (Bug#1040406: fixed in python-azure 20230705+git-1)
On Thu, 6 Jul 2023 at 09:42, Bastian Blank wrote: > > On Thu, Jul 06, 2023 at 09:39:43AM +0100, Luca Boccassi wrote: > > Yes I will bump the dependency in the next azcli upload, but I wanted > > to push the fix immediately. > > Okay. Any reason for not just merging the two into one source? Can be > automated and you don't need to think about it again. Any time python-azure is updated to a new revision it can also break azure-cli, so I'd rather keep it separate and fixed and change it only when something is actually detected that needs an uprev.
Bug#1040406: closed by Debian FTP Masters (reply to Luca Boccassi ) (Bug#1040406: fixed in python-azure 20230705+git-1)
On Thu, 6 Jul 2023 at 09:14, Bastian Blank wrote: > > Hi Luca > > >* New upstream version 20230705+git (Closes: #1040406) > > Could you please describe how a new version of the azure module can fix > that? The dependency needs to be updated as well at least. > > Also, how can it be that azure-cli is updated without the corresponding > azure? Because the upstream projects are sadly an absolute mess. The mass of code in python-azure (upstream azure-sdk-for-python) is an amorphous blob without any logic or reason, with hundreds of modules that get thrown in the repository incoherently. At any give commit these modules can be incompatible with each other in unpredictable ways, so updating python-azure is like playing russian roulette, so I avoid doing it unless it becomes obviously necessary (as you noticed for the 'az vm' subcommand in the bug you filed). And to top it all, upstream azure-cli just bumps its requirements.txt on every release to whatever is available on the developer's machine that day, so it is completely unreliable and needs to be ignored. Yes I will bump the dependency in the next azcli upload, but I wanted to push the fix immediately. Honestly, if I didn't need this for $work, I'd have filed an RM bug long ago. But the upstream 'releases' are even worse and vendor everything including the full python interpreter and openssl, without any security maintenance guarantees, so I don't want to have to rely on them. Kind regards, Luca Boccassi
Bug#1040049: gnome-terminal: assert hit on mouseover, all open terminal windows are lost
On Mon, 3 Jul 2023 at 22:04, Simon McVittie wrote: > > On Mon, 03 Jul 2023 at 16:12:11 +0100, Luca Boccassi wrote: > > On Mon, 3 Jul 2023 at 16:08, Simon McVittie wrote: > > > I normally use gnome-console (kgx) myself, and I wasn't able to reproduce > > > this in some brief testing with gnome-terminal; I also didn't see > > > this when testing the 0.70.6-1~deb12u1 update on a bookworm system. > > > Are there any special steps to trigger this assertion failure? > > > > Bookworm with p-u. I cannot reproduce reliably, it happens randomly > > when using the mouse scroll wheel inside gnome-terminal. Do you need > > the core file? > > A backtrace to the bug would be ideal; a full core dump file probably > gives us a limited amount of extra info compared with a backtrace, > and is more likely to contain something confidential. If you can find > a way to repro the issue somewhat reliably then it would also be useful > to know whether it's the same backtrace every time. > > If you can try rolling back to bookworm without p-u for this package and > try to reproduce it, that would also be very useful: if we need to revert > a change before 12.1, then there is going to be quite a tight deadline > for that. Here's the full backtrace, if I manage to repro with the non-p-u version I'll reply back: #0 __pthread_kill_implementation (threadid=, signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44 tid = ret = 0 pd = old_mask = {__val = {140075865543808}} ret = #1 0x7f65f32a9d2f in __pthread_kill_internal (signo=6, threadid=) at ./nptl/pthread_kill.c:78 #2 0x7f65f325aef2 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 ret = #3 0x7f65f3245472 in __GI_abort () at ./stdlib/abort.c:79 save_stage = 1 act = {__sigaction_handler = {sa_handler = 0x20, sa_sigaction = 0x20}, sa_mask = {__val = {93865595894560, 140734737393720, 140075864777479, 93862215286832, 140733193388032, 93865597004128, 0, 206158430248, 9061015767978157056, 140075865037995, 18446744073709551360, 11, 140075865546368, 140075853536075, 140734737393824, 0}}, sa_flags = -215253713, sa_restorer = 0x7f65f37d84d0} #4 0x7f65f4238ec8 in g_assertion_message (domain=domain@entry=0x7f65f37d84d0 "VTE", file=file@entry=0x7f65f37ddb4b "../src/ringview.cc", line=line@entry=299, func=func@entry=0x7f65f37ddc50 "const vte::base::BidiRow* vte::base::RingView::get_bidirow(vte::grid::row_t) const", message=message@entry=0x555ec9412d40 "assertion failed (row < m_start + m_len): (23079 < 23079)") at ../../../glib/gtestutils.c:3256 lstr = "299\000\000\000\000\000\001\000\000\000\000\000\000\000@\250\a\\\377\177\000\000\000\000\000\000e\177\000" s = 0x555ec990e960 "\216\213\273\234[U" #5 0x7f65f42991a1 in g_assertion_message_cmpnum (domain=0x7f65f37d84d0 "VTE", file=0x7f65f37ddb4b "../src/ringview.cc", line=299, func=0x7f65f37ddc50 "const vte::base::BidiRow* vte::base::RingView::get_bidirow(vte::grid::row_t) const", expr=, arg1=23079, cmp=, arg2=23079, numtype=105 'i') at ../../../glib/gtestutils.c:3315 s = 0x555ec9412d40 "assertion failed (row < m_start + m_len): (23079 < 23079)" #6 0x7f65f3799615 in vte::base::RingView::get_bidirow(long) const (this=this@entry=0x555ec811f928, row=23079) at ../src/ringview.cc:299 __n1 = 23079 __n2 = __PRETTY_FUNCTION__ = "const vte::base::BidiRow* vte::base::RingView::get_bidirow(vte::grid::row_t) const" #7 0x7f65f379da59 in vte::terminal::Terminal::grid_coords_from_view_coords(vte::view::coords const&) const (this=this@entry=0x555ec811c520, pos=...) at ../src/vte.cc:1607 col = 52 row = 23079 bidirow = #8 0x7f65f379dfe8 in vte::terminal::Terminal::grid_coords_from_event(vte::platform::MouseEvent const&) const (event=, this=0x555ec811c520) at ../src/vte.cc:1563 rowcol = {> = {first = , second = }, } #9 vte::terminal::Terminal::rowcol_from_event(vte::platform::MouseEvent const&, long*, long*) (this=this@entry=0x555ec811c520, event=, column=column@entry=0x7fff5c07aa78, row=row@entry=0x7fff5c07aa80) at ../src/vte.cc:1785 rowcol = {> = {first = , second = }, } #10 0x7f65f37a86c3 in vte::terminal::Terminal::hyperlink_check(vte::platform::MouseEvent const&) (this=this@entry=0x555ec811c520, event=...) at ../src/vte.cc:1837 col = 140075459440672 row = 93865571894560 #11 0x7f65f37b88c1 in vte::platform::Widget::hyperlink_check(_GdkEvent*) (event=0x7f65dc007020, this=) at ../src/widget.hh:475 __PRETTY_FUNCTION__ = "char* vte_terminal_hyperlink_check_event(VteTerminal*, Gdk
Bug#1040049: gnome-terminal: assert hit on mouseover, all open terminal windows are lost
On Mon, 3 Jul 2023 at 16:08, Simon McVittie wrote: > > Control: reassign -1 libvte-2.91-0 > Control: affects -1 + gnome-terminal src:gnome-terminal > Control: retitle -1 gnome-terminal: crash with assertion failure on > mouseover: row < m_start + m_len > > On Sat, 01 Jul 2023 at 19:51:16 +0100, Luca Boccassi wrote: > > gnome-terminal-server asserts on mouseover, losing all open terminals > > > > gnome-terminal-server[2464750]: VTE:ERROR:../src/ringview.cc:299:const > > vte::base::BidiRow* vte::base::RingView::get_bidirow(vte::grid::row_t) > > const: assertion failed (row < m_start + m_len): (15728 < 15725) > > A VTE:ERROR is an assertion failure in libvte2.91-0 rather than > gnome-terminal itself. > > Which of these versions have you tested, and which one(s) are affected? > > - 0.70.3-1 in bookworm > - 0.70.6-1~deb12u1 in bookworm-proposed-updates > - 0.70.6-1 in testing/unstable > - 0.72.2-1 in experimental > > It's helpful if you use reportbug to report bugs so that information on > dependency versions is present. > > I normally use gnome-console (kgx) myself, and I wasn't able to reproduce > this in some brief testing with gnome-terminal; I also didn't see > this when testing the 0.70.6-1~deb12u1 update on a bookworm system. > Are there any special steps to trigger this assertion failure? Bookworm with p-u. I cannot reproduce reliably, it happens randomly when using the mouse scroll wheel inside gnome-terminal. Do you need the core file?
Bug#1040049: gnome-terminal: assert hit on mouseover, all open terminal windows are lost
On Mon, 3 Jul 2023 at 13:21, Jeremy Bícha wrote: > > On Sat, Jul 1, 2023 at 2:54 PM Luca Boccassi wrote: > > Package: gnome-terminal > > Version: 3.46.8-1 > > Severity: important > > Tags: patch bookworm > > Forwarded: https://gitlab.gnome.org/GNOME/vte/-/issues/2577 > > > > Dear Maintainer(s), > > > > gnome-terminal-server asserts on mouseover, losing all open terminals: > > > > gnome-terminal-server[2464750]: VTE:ERROR:../src/ringview.cc:299:const > > vte::base::BidiRow* vte::base::RingView::get_bidirow(vte::grid::row_t) > > const: assertion failed (row < m_start + m_len): (15728 < 15725) > > gnome-terminal-server[2464750]: Bail out! > > VTE:ERROR:../src/ringview.cc:299:const vte::base::BidiRow* > > vte::base::RingView::get_bidirow(vte::grid::row_t) const: assertion failed > > (row < m_start + m_len): (15728 < 15725) > > > > This is upstream issue: > > > > https://gitlab.gnome.org/GNOME/vte/-/issues/2577 > > > > Which was fixed by: > > > > https://gitlab.gnome.org/GNOME/vte/-/commit/dcfc0ec44df3084987a6faa0fdc03e6de717c682 > > > > Please backport the fix to bookworm via proposed-updates, given it's a > > hard crash. > > But Debian 12 already has vte2.91 0.70.6 which includes the fix from > February you identified. > https://gitlab.gnome.org/GNOME/vte/-/commits/0.70.6 Different assertion then? It looked the same, but maybe it's not. This is what I have running: $ dpkg -l | grep libvte ii libvte-2.91-0:amd64 0.70.6-1~deb12u1 amd64Terminal emulator widget for GTK+ 3.0 - runtime files ii libvte-2.91-common 0.70.6-1~deb12u1 amd64Terminal emulator widget for GTK+ 3.0 - common files
Bug#1040035: puppet-agent: autopkgtest failures on 32bit architecture with systemd v253
Control: reassing -1 systemd 253-1 Control: forwarded -1 https://github.com/systemd/systemd/issues/26568 On Sat, 01 Jul 2023 11:24:10 +0100 Luca Boccassi wrote: > Source: puppet-agent > Version: 7.23.0-1 > Severity: serious > Justification: autopkgtest stops other package migration > X-Debbugs-Cc: pkg-systemd-maintain...@lists.alioth.debian.org > > Dear Maintainer(s), > > autopkgtest of puppet-agent are failing on 32bit architectures with > systemd v253 from unstable: > > https://ci.debian.net/data/autopkgtest/testing/armel/p/puppet-agent/34962416/log.gz > https://ci.debian.net/data/autopkgtest/testing/armhf/p/puppet-agent/34962433/log.gz > https://ci.debian.net/data/autopkgtest/testing/i386/p/puppet-agent/34967095/log.gz > > 326s # ./spec/service-systemd/systemd_spec.rb:47:in `block (4 levels) in ' > 326s > 326s 6) Command "systemctl is-enabled dep8-sd-sysv" stdout is expected to match /^disabled/ > 326s Failure/Error: its(:stdout) { should match /^disabled/ } > 326s expected "enabled\n" to match /^disabled/ > 326s Diff: > 326s @@ -1 +1 @@ > 326s -/^disabled/ > 326s +enabled > 326s /bin/sh -c systemctl\ is-enabled\ dep8-sd-sysv > 326s enabled > 326s > 326s # ./spec/service-systemd/systemd_spec.rb:51:in `block (4 levels) in ' > 326s > 326s 7) Command "puppet apply --debug --detailed-exitcodes -e "service { 'dep8-sd-only' : ensure => running, enable => true, provider => 'systemd' }"" stdout is expected to match /systemctl enable/ > 326s Failure/Error: its(:stdout) { should match /systemctl enable/ } > 326s expected "\e[0;36mDebug: Runtime environment: puppet_version=7.23.0, ruby_version=3.1.2, run_mode=user, defaul...n\e[0;36mDebug: Processing report from ci-181-6d069294 with processor Puppet::Reports::Store\e[0m\n" to match /systemctl enable/ Never mind, this is an instance of: https://github.com/systemd/systemd/issues/26568 -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1040035: puppet-agent: autopkgtest failures on 32bit architecture with systemd v253
Source: puppet-agent Version: 7.23.0-1 Severity: serious Justification: autopkgtest stops other package migration X-Debbugs-Cc: pkg-systemd-maintain...@lists.alioth.debian.org Dear Maintainer(s), autopkgtest of puppet-agent are failing on 32bit architectures with systemd v253 from unstable: https://ci.debian.net/data/autopkgtest/testing/armel/p/puppet-agent/34962416/log.gz https://ci.debian.net/data/autopkgtest/testing/armhf/p/puppet-agent/34962433/log.gz https://ci.debian.net/data/autopkgtest/testing/i386/p/puppet-agent/34967095/log.gz 326s # ./spec/service-systemd/systemd_spec.rb:47:in `block (4 levels) in ' 326s 326s 6) Command "systemctl is-enabled dep8-sd-sysv" stdout is expected to match /^disabled/ 326s Failure/Error: its(:stdout) { should match /^disabled/ } 326sexpected "enabled\n" to match /^disabled/ 326sDiff: 326s@@ -1 +1 @@ 326s-/^disabled/ 326s+enabled 326s/bin/sh -c systemctl\ is-enabled\ dep8-sd-sysv 326senabled 326s 326s # ./spec/service-systemd/systemd_spec.rb:51:in `block (4 levels) in ' 326s 326s 7) Command "puppet apply --debug --detailed-exitcodes -e "service { 'dep8-sd-only' : ensure => running, enable => true, provider => 'systemd' }"" stdout is expected to match /systemctl enable/ 326s Failure/Error: its(:stdout) { should match /systemctl enable/ } 326sexpected "\e[0;36mDebug: Runtime environment: puppet_version=7.23.0, ruby_version=3.1.2, run_mode=user, defaul...n\e[0;36mDebug: Processing report from ci-181-6d069294 with processor Puppet::Reports::Store\e[0m\n" to match /systemctl enable/ Please apply a workaround or disable the tests. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part