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
mic 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_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-offload: off [fixed]\nesp-tx-csum-hw- offload: off [fixed]\nrx-udp_tun
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
ad: 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=amd64=0.73.1-1=1713175615=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=5.12.0-14%2Bb1=i386 -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1057712: collectd: FTBFS on i386
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 0x7606395d in sqlite3Pragma (pParse=pParse@entry=0x7fffb930, pId1=pId1@entry=0x12a8
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*, GdkEvent*)"
#12 vte_terminal_h
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
Bug#1000118: generator-scripting-language: depends on obsolete pcre3 library
Control: severity -1 wishlist Control: tags -1 help On Thu, 18 Nov 2021 11:49:04 + Matthew Vernon wrote: > Source: generator-scripting-language > Severity: important > User: matthew-pcre...@debian.org > Usertags: obsolete-pcre3 > > Dear maintainer, > > Your package still depends on the old, obsolete PCRE3[0] libraries > (i.e. libpcre3-dev). This has been end of life for a while now, and > upstream do not intend to fix any further bugs in it. Accordingly, I > would like to remove the pcre3 libraries from Debian, preferably in > time for the release of Bookworm. > > The newer PCRE2 library was first released in 2015, and has been in > Debian since stretch. Upstream's documentation for PCRE2 is available > here: https://pcre.org/current/doc/html/ > > Many large projects that use PCRE have made the switch now (e.g. git, > php); it does involve some work, but we are now at the stage where > PCRE3 should not be used, particularly if it might ever be exposed to > untrusted input. As already mentioned, this package is not used to process untrusted input, it is a 'done' project that hasn't been touched in a decade and just works as part of an existing toolchain. If someone provides a patch, that is tested against such workflows to confirm that they are not affected, then I'd merged it, upstream. If push came to shove, I will simply vendor the existing pcre code. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1039487: zfs-dkms: autopkgtest fails on Linux 6.3 (arm64 only)
Package: zfs-dkms Version: 2.1.12-1 Severity: serious Hi, The autopkgtest for zfs-dkms is failing, but only for the arm64 architecture for some reason: 1397s MODPOST /var/lib/dkms/zfs/2.1.12/build/module/Module.symvers 1397s ERROR: modpost: GPL-incompatible module zcommon.ko uses GPL-only symbol 'kernel_neon_begin' 1397s ERROR: modpost: GPL-incompatible module zcommon.ko uses GPL-only symbol 'kernel_neon_end' 1397s ERROR: modpost: GPL-incompatible module zfs.ko uses GPL-only symbol 'kernel_neon_end' 1397s ERROR: modpost: GPL-incompatible module zfs.ko uses GPL-only symbol 'kernel_neon_begin' 1397s make[4]: *** [/usr/src/linux-headers-6.3.0-1-common/scripts/Makefile.modpost:136: /var/lib/dkms/zfs/2.1.12/build/module/Module.symvers] Error 1 1397s make[3]: *** [/usr/src/linux-headers-6.3.0-1-common/Makefile:2002: modpost] Error 2 1397s make[3]: Leaving directory '/usr/src/linux-headers-6.3.0-1-cloud-arm64' 1397s make[2]: *** [Makefile:55: modules-Linux] Error 2 1397s make[2]: Leaving directory '/var/lib/dkms/zfs/2.1.12/build/module' 1397s make[1]: *** [Makefile:899: all-recursive] Error 1 1397s make[1]: Leaving directory '/var/lib/dkms/zfs/2.1.12/build' 1397s make: *** [Makefile:760: all] Error 2 https://ci.debian.net/data/autopkgtest/testing/arm64/z/zfs-linux/34875749/log.gz I've restarted it many times but no luck, it doesn't seem like a fluke. https://ci.debian.net/packages/z/zfs-linux/testing/arm64 -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1037924: marked as pending in systemd
Control: tag -1 pending Hello, Bug #1037924 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/26c9d15ece64b9dc8f55a40aa6d40fa6d2f35ec8 systemd-dev: add missing breaks/replaces with udev Closes: #1037924 (this message was generated automatically) -- Greetings https://bugs.debian.org/1037924
Bug#1038067: dash: fails to upgrade from -2 in debian:sid-slim image due to --path-exclude=/usr/share/man
On Sat, 17 Jun 2023, 02:05 Luca Boccassi, wrote: > Control: tags -1 patch > > On Thu, 15 Jun 2023 14:26:11 +0200 Helmut Grohne > wrote: > > Package: dash > > Version: 0.5.12-4 > > Severity: serious > > > > Hi, > > > > if you --path-exclude=/usr/share/man, dash fails to upgrade from -2. > > Reproducer: > > > > mmdebstrap trixie /dev/null --dpkgopt='path-exclude=/usr/share/man/*' > --chrooted-customize-hook='sed -i -e s/trixie/sid/ > /etc/apt/sources.list; apt-get update; apt-get -y install dash' > > > > Unfortunately, this breaks upgrading docker images debian:sid-slim to > > unstable at the moment and that breaks lots of CI jobs. > > > > I guess it is the readlink that silently fails on the non-existent > > manual page link. Probably, when that link doesn't exist and it is > > diverted by dash, we should assume that it is ok-ish: > > > > actualtarget=$(readlink "$dfile") || actualtarget=$ltarget > > > > What do you think? > > Yeah I can confirm your suggestion works, attached in patch format with > attribution. > Andrej I see that you are out of office, would you like me to NMU this fix to unblock the CI? Kind regards, Lube Boccassi >
Bug#1038067: dash: fails to upgrade from -2 in debian:sid-slim image due to --path-exclude=/usr/share/man
Control: tags -1 patch
On Thu, 15 Jun 2023 14:26:11 +0200 Helmut Grohne
wrote:
> Package: dash
> Version: 0.5.12-4
> Severity: serious
>
> Hi,
>
> if you --path-exclude=/usr/share/man, dash fails to upgrade from -2.
> Reproducer:
>
> mmdebstrap trixie /dev/null --dpkgopt='path-exclude=/usr/share/man/*'
--chrooted-customize-hook='sed -i -e s/trixie/sid/
/etc/apt/sources.list; apt-get update; apt-get -y install dash'
>
> Unfortunately, this breaks upgrading docker images debian:sid-slim to
> unstable at the moment and that breaks lots of CI jobs.
>
> I guess it is the readlink that silently fails on the non-existent
> manual page link. Probably, when that link doesn't exist and it is
> diverted by dash, we should assume that it is ok-ish:
>
> actualtarget=$(readlink "$dfile") || actualtarget=$ltarget
>
> What do you think?
Yeah I can confirm your suggestion works, attached in patch format with
attribution.
--
Kind regards,
Luca Boccassi
From 26bde9cff858faef4657d81be277381dc3c2816e Mon Sep 17 00:00:00 2001
From: Helmut Grohne
Date: Sat, 17 Jun 2023 02:02:59 +0100
Subject: [PATCH] dash.postinst: fix installing with
--path-exclude=/usr/share/man/*
The symlink might not exist, but we should remove the diversion
anyway.
Closes: #1038067
---
debian/dash.postinst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/debian/dash.postinst b/debian/dash.postinst
index 42b2fc9..7a1807f 100644
--- a/debian/dash.postinst
+++ b/debian/dash.postinst
@@ -64,7 +64,7 @@ drop_obsolete_diversion() {
dfile=$1 ltarget=$2 distrib=${3:-$dfile.distrib}
diverter=$(dpkg-divert --listpackage "$dfile")
truename=$(dpkg-divert --truename "$dfile")
- actualtarget=$(readlink "$dfile")
+ actualtarget=$(readlink "$dfile") || actualtarget=$ltarget
if [ "$diverter" != dash ] || [ "$truename" != "$distrib" ] || [ "$actualtarget" != "$ltarget" ]; then
# Not our diversion or a non-trivial one.
--
2.39.2
signature.asc
Description: This is a digitally signed message part
Bug#1038157: debootstrap: W: Failure while unpacking required packages. This will be attempted
Control: severity -1 minor Control: fixed -1 1.0.127+nmu1 On Fri, 16 Jun 2023 09:44:39 +0200 Jean-Marc LACROIX wrote: > ansible@hn-asusgl752-400:~$ df |grep dns-400 > /dev/mapper/vg_vn_dns_400-lv_rootfs 117331 >6 108438 1% /var/lib/lxc/vn-dns-400/rootfs > /dev/mapper/vg_vn_dns_400-lv_usr 675672 >8 626352 1% /var/lib/lxc/vn-dns-400/rootfs/usr > /dev/mapper/vg_vn_dns_400-lv_var 105431 >5 97399 1% /var/lib/lxc/vn-dns-400/rootfs/var > /dev/mapper/vg_vn_dns_400-lv_tmp 137161 >2 126838 1% /var/lib/lxc/vn-dns-400/rootfs/tmp > /dev/mapper/vg_vn_dns_400-lv_home117331 >2 108442 1% /var/lib/lxc/vn-dns-400/rootfs/home > /dev/mapper/vg_vn_dns_400-lv_var_log 192699 >2 178361 1% /var/lib/lxc/vn-dns-400/rootfs/var/log > /dev/mapper/vg_vn_dns_400-lv_var_lib 125250 >3 115786 1% /var/lib/lxc/vn-dns-400/rootfs/var/lib > /dev/mapper/vg_vn_dns_400-lv_var_cache 469458 >2 440580 1% /var/lib/lxc/vn-dns-400/rootfs/var/cache > /dev/mapper/vg_vn_dns_400-lv_var_lib_apt 920648 >8 856540 1% /var/lib/lxc/vn-dns-400/rootfs/var/lib/apt This is a strange setup, why is the rootfs under a different volume than /usr? That's not really supported. Anyway, this should be fixed in a newer version, try installing debootstrap from bullseye-backports. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1037924: systemd-dev: missing Breaks+Replaces: udev (<< 253-2~)
On Wed, 14 Jun 2023 13:36:19 +0200 Andreas Beckmann wrote: > Package: systemd-dev > Version: 253-2 > Severity: serious > User: debian...@lists.debian.org > Usertags: piuparts > > Hi, > > during a test with piuparts I noticed your package failed to install > because it tries to overwrite other packages files without declaring a > Breaks+Replaces relation. D'oh, forgot about it, fix is queued in git. We'll move this to unstable soon enough, so it will be uploaded as part of that. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1036920: systemd: please ship a placeholder in /usr/lib/modules-load.d/
Control: severity -1 important On Mon, 29 May 2023 14:42:14 +0200 Andreas Beckmann wrote: > Package: systemd > Version: 252.6-1 > Severity: serious > User: debian...@lists.debian.org > Usertags: piuparts Given what was discussed: - bookworm is in hard freeze - there is no functional impact - unmerged-usr paths are no longer supported - as soon as trixie opens for business we might just canonicalize everything (assuming all the ducks will be in a row) if it's all right with you Andreas, I am going to go ahead and downgrade this. If we don't manage to canonicalize early in trixie's cycle we can revisit. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1036920: systemd: please ship a placeholder in /usr/lib/modules-load.d/
On Mon, 29 May 2023 15:17:51 +0200 Andreas Beckmann wrote: > On 29/05/2023 14.57, Luca Boccassi wrote: > >> Side question first: does systemd evaluate both > >> /usr/lib/modules-load.d/* and /lib/modules-load.d/* ? > >> Otherwise all packages shipping something in /lib/modules-load.d/ are > >> broken on unmerged-/usr because their config snippets are not being > >> taken into account. > > > > The correct path since bullseye was /usr/lib/modules-load.d, see: > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971282 > > I read this as these packages have been buggy on unmerged-/usr in > bullseye. Why weren't there bugs filed? Good question, I guess nobody ever noticed because most users are on merged-usr anyway? But as you can see from the bug, it's been years. > > Anyway, we don't really care about what happens on unmerged > > installations, as they are no longer supported since Bookworm. > > Well, there is still limited support, e.g. for buildd usage. But > probably (hopefully?) for the last time. IIRC the plan was to switch buildds as soon as bookworm ships, but I don't think that's finalised. Also I don't think it's supported to install and load kernel modules for a package build, at least I've never came across that, but I might be wrong. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1036920: systemd: please ship a placeholder in /usr/lib/modules-load.d/
On Mon, 29 May 2023 at 14:07, Andreas Beckmann wrote: > > On 29/05/2023 14.57, Luca Boccassi wrote: > > Wouldn't the correct workaround be to list /usr/lib/modules-load.d in > > systemd.dirs so that dpkg leaves it alone? Seems way too late for > > Bookworm though? > > for dpkg, /usr/lib/modules-load.d is already owned by systemd, dpkg only > accidentally deletes it while removing /lib/modules-load.d > > That's the reason for adding some placeholder file there, to prevent > accidental removal of the (no longer empty) directory. > Could be part of the first bookworm point release. Does it matter that much if the empty directory is removed? Next time a package shipping a modules-load config is installed it will be just re-added, no? Or are there functional issues? Kind regards, Luca Boccassi
Bug#1036920: systemd: please ship a placeholder in /usr/lib/modules-load.d/
On Mon, 29 May 2023 14:42:14 +0200 Andreas Beckmann wrote: > Package: systemd > Version: 252.6-1 > Severity: serious > User: debian...@lists.debian.org > Usertags: piuparts > > Hi, > > during a test with piuparts I noticed your package ships an empty > directory (/usr/lib/modules-load.d/) which disappears after installation > and removal of another package (e.g. multipath-tools) in a merged- /usr > setup. This is not a bug in the other package, but an effect of our > merged-/usr implementation. > > Side question first: does systemd evaluate both > /usr/lib/modules-load.d/* and /lib/modules-load.d/* ? > Otherwise all packages shipping something in /lib/modules-load.d/ are > broken on unmerged-/usr because their config snippets are not being > taken into account. The correct path since bullseye was /usr/lib/modules-load.d, see: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971282 Anyway, we don't really care about what happens on unmerged installations, as they are no longer supported since Bookworm. > This is happening to trigger the bug: > > systemd ships /usr/lib/modules-load.d/ (empty directory) > multipath-tools ships /lib/modules-load.d/multipath.conf > dpkg doesn't know that /lib/modules-load.d/ and /usr/lib/modules- load.d/ > are the same, and therefore removal of multipath-tools causes removal of > * /lib/modules-load.d/multipath.conf (OK) > * /lib/modules-load.d/ (if it was the last owner of that directory), while > it effectively is /usr/lib/modules-load.d/ getting removed > > When adding a placeholder file, it needs to be something that is ignored > by the processing of the .d directory (the pattern could be *.conf, but I > might be mistaken here). > > An alternative to shipping a placeholder file could be shipping > /lib/modules-load.d/ as additional empty directory, but I don't know > whether this would be allowed w.r.t. merged-/usr. > > > From the attached log (scroll to the bottom...): > > 0m39.2s ERROR: FAIL: After purging files have disappeared: > /usr/lib/modules-load.d/ owned by: systemd > > > This is not caught by default piuparts tests as there is no test with > systemd explicitly installed. > > I could not reproduce this issue in bullseye (and haven't tried to > reproduce it in earlier releases). Wouldn't the correct workaround be to list /usr/lib/modules-load.d in systemd.dirs so that dpkg leaves it alone? Seems way too late for Bookworm though? -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1033167: usrmerge: messes with /etc/shells
On Sun, 19 Mar 2023 17:22:11 +0100 Helmut Grohne wrote: > I've prepared an update for debianutils and tested it in the > following > cases: > * Installation on a pre-merged chroot -> /usr/bin/sh is added to >/etc/shells. > * Installation on a chroot merged by usrmerge -> no difference > * Installation on an unmerged system. Manual merge without >convert-etc-shells. Manual update-shells. -> Looks the same as > after >convert-etc-shells. > > Does anyone see any bugs? Not an expert in update-shells, but cannot see anything obviously wrong with the patch. Only comment I'd make is maybe to split the latter half of the changes, which seems unrelated and adding previously missing quotes, in a different patch. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1035543: init-system-helpers: bla bla
On Fri, 05 May 2023 11:04:29 +0200 Andreas Beckmann wrote: > Package: init-system-helpers > Version: 1.65.2 > Severity: serious > User: debian...@lists.debian.org > Usertags: piuparts > Control: affects -1 e2fsprogs > > Hi, > > many piuparts bullseye2bookworm tests are curently failing with > > 0m50.4s ERROR: FAIL: After purging files have disappeared: > /etc/systemd/system/multi-user.target.wants/ not owned > /etc/systemd/system/multi-user.target.wants/e2scrub_reap.service -> /lib/systemd/system/e2scrub_reap.service not owned > > This is a new systemd unit in package e2fsprogs. If this failure is > actually e2fsprogs's fault by incorrectly using the helpers, please > reassign the bug there (with instructions how to do it correctly). Isn't this a variation of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031695 ? -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1032937: breaks upgrades if systemd-resolved can't run
Control: severity -1 wishlist Control: tags -1 wontfix On Tue, 14 Mar 2023 15:05:20 +0100 Bastian Blank wrote: > Control: severity -1 serious > > Let's make this RC, as it breaks updates. > > The systemd-resolved package modifies a global config file > /etc/resolv.conf. This breaks any name resolution if resolved is not > running. Especially if it can't run at all. > > | root@debian-sid:~# ls -al /etc/resolv.conf > | lrwxrwxrwx 1 root root 40 Mar 14 14:03 /etc/resolv.conf -> /../run/systemd/resolve/stub-resolv.conf > | root@debian-sid:~# getent hosts heise.de > | 2a02:2e0:3fe:1001:302:: heise.de > | root@debian-sid:~# systemctl stop systemd-resolved > | root@debian-sid:~# getent hosts heise.de > | root@debian-sid:~# > > Sorry, but the only person to know if resolved can be used is the admin, > not a package. Exactly, so the admin shouldn't install a package that in the description says: "Installing this package automatically overwrites /etc/resolv.conf and switches it to be managed by systemd-resolved." if that's not what they want to achieve. I agree that the /etc/resolv.conf interface is garbage, but there's nothing we can do about it, that's just how it works. This is the only way read-only images can be supported sanely. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1026883: ovn-octavia-provider: autopkgtest fails with openvswitch 3.1 on armhf/armel/i386
Source: ovn-octavia-provider Version: 3.0.0-1 Severity: serious Justification: stops other packages from migrating to testing X-Debbugs-CC: pkg-dpdk-de...@lists.alioth.debian.org z...@debian.org Dear Maintainer(s), The dpdk+ovs+ovn transition is in progress, and ovn-octavia-provider's autopkgtest are failing on armhf/armel/i386: https://ci.debian.net/data/autopkgtest/testing/armel/o/ovn-octavia-provider/29567216/log.gz https://ci.debian.net/data/autopkgtest/testing/armhf/o/ovn-octavia-provider/29567217/log.gz https://ci.debian.net/data/autopkgtest/testing/i386/o/ovn-octavia-provider/29567218/log.gz In a few days I will NMU to disable the failing tests as a quick workaround, unless the problem is sorted out beforehand. Kind regards, Luca Boccassi
Bug#1026773: libcap2: autopkgtest failures block other packages from migrating
Source: libcap2 Version: 1:2.66-2 Severity: serious Jutsification: stops other packages from migrating to testing Hi, The autopkgtest run for the latest version of libcap2 in unstable fails on all architectures: autopkgtest [18:14:20]: test upstream-nonroot: - - - - - - - - - - results - - - - - - - - - - upstream-nonroot FAIL stderr: dpkg-architecture: warning: cannot determine CC system type, falling back to default (native compilation) https://ci.debian.net/packages/libc/libcap2/testing/amd64/ This stops unrelated packages from migrating to testing. Please consider either fixing the tests or removing them to unblock other packages. Thanks! Kind regards, Luca Boccassi
Bug#1024856: marked as pending in azure-cli
Control: tag -1 pending Hello, Bug #1024856 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/140f1848074139754e4562cf608a6f383f0b30e8 Add patch to fix build with Python 3.11 Closes: #1024856 (this message was generated automatically) -- Greetings https://bugs.debian.org/1024856
Bug#1023621: azure-cli - incomplete dependences: ModuleNotFoundError
Control: tags -1 -moreinfo Control: reassign -1 python3-azure Control: close -1 20221101+git-1 On Tue, 08 Nov 2022 11:36:56 + Luca Boccassi wrote: > Control: tags -1 moreinfo > > On Mon, 07 Nov 2022 19:36:40 +0100 Bastian Blank > wrote: > > Package: azure-cli > > Version: 2.42.0-1 > > Severity: serious > > > > Simple VM operations, like start, fail with ModuleNotFoundError. So > some > > dependencies are incorrect. > > Did you have the new python3-azure that just migrated to testing? If > not, can you try again and let me know if it helps? Cannot reproduce this anymore with the new python3-azure, so closing. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1023621: azure-cli - incomplete dependences: ModuleNotFoundError
Control: tags -1 moreinfo On Mon, 07 Nov 2022 19:36:40 +0100 Bastian Blank wrote: > Package: azure-cli > Version: 2.42.0-1 > Severity: serious > > Simple VM operations, like start, fail with ModuleNotFoundError. So some > dependencies are incorrect. Did you have the new python3-azure that just migrated to testing? If not, can you try again and let me know if it helps? -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1023442: marked as pending in systemd
Control: tag -1 pending Hello, Bug #1023442 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/b7d780064dfee3b42bc11b093a40633b94fd538d Drop :native suffix from python3-pyparsing build dependency Closes: #1023442 (this message was generated automatically) -- Greetings https://bugs.debian.org/1023442
Bug#1023248: marked as pending in systemd
Control: tag -1 pending Hello, Bug #1023248 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/b6e55a055e7fe21c76c71eb133de14811c4bb6c7 Let dh_installsysusers fix the /var/log/journal permissions dh_installsysusers adds a systemd-sysusers in #DEBHELPER#. Otherwise it fails with: /usr/lib/tmpfiles.d/systemd.conf:28: Failed to resolve group 'systemd-journal'. Regression of fa0aade329. Closes: #1023248 (this message was generated automatically) -- Greetings https://bugs.debian.org/1023248
Bug#1023124: libsystemd-shared-251.so: cannot open shared object file
Control: tags -1 -moreinfo Control: close -1 On Sun, 30 Oct 2022 14:56:08 +0100 Salvo Tomaselli wrote: > systemd-machine-id-setup: /usr/bin/systemd-machine-id-setup > /bin/systemd-machine-id-setup > /usr/share/man/man1/systemd-machine-id-setup.1.gz > > > stat /usr/bin/systemd-machine-id-setup /bin/systemd-machine-id-setup > File: /usr/bin/systemd-machine-id-setup > Size: 18928 Blocks: 40 IO Block: 4096 regular file > Device: 259,5 Inode: 4201937 Links: 1 > Access: (0755/-rwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root) > Access: 2022-10-30 13:34:13.098418093 +0100 > Modify: 2022-08-14 20:06:18.0 +0200 > Change: 2022-08-22 15:25:56.730012624 +0200 > Birth: 2022-08-22 15:25:56.610011671 +0200 > File: /bin/systemd-machine-id-setup > Size: 18928 Blocks: 40 IO Block: 4096 regular file > Device: 259,5 Inode: 8650854 Links: 1 > Access: (0755/-rwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root) > Access: 2022-10-30 13:38:20.0 +0100 > Modify: 2022-10-14 16:34:00.0 +0200 > Change: 2022-10-30 13:38:20.944385494 +0100 > Birth: 2022-10-30 13:38:20.816384357 +0100 > > > > It seems my system is in a weird status from some previous issues… > Maybe originating when apt told me to split /usr, then I had some > issues and had to manually install a bunch of packages. Yes, your system is in a bad state and needs to be fixed, and it has nothing to do with the systemd packages or this update, so I'll close this now. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1022488: azure-cosmos-python: FTBFS: TypeError: dist must be a Distribution instance
On Sun, 23 Oct 2022 15:38:40 +0200 Lucas Nussbaum
wrote:
> Source: azure-cosmos-python
> Version: 3.1.1-4
> Severity: serious
> Justification: FTBFS
> Tags: bookworm sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20221023 ftbfs-bookworm
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
>
>
> Relevant part (hopefully):
> > debian/rules clean
> > dh clean --with python3 --buildsystem=pybuild
> > dh_auto_clean -O--buildsystem=pybuild
> > I: pybuild base:240: python3.10 setup.py clean
> > /<>/setup.py:3: DeprecationWarning: The distutils
package is deprecated and slated for removal in Python 3.12. Use
setuptools or check PEP 632 for potential alternatives
> > from distutils.core import setup
> > /usr/lib/python3/dist-packages/_distutils_hack/__init__.py:18:
UserWarning: Distutils was imported before Setuptools, but importing
Setuptools also replaces the `distutils` module in `sys.modules`. This
may lead to undesirable behaviors or errors. To avoid these issues,
avoid using distutils directly, ensure that setuptools is installed in
the traditional way (e.g. not an editable install), and/or make sure
that setuptools is always imported before distutils.
> > warnings.warn(
> > /usr/lib/python3/dist-packages/_distutils_hack/__init__.py:33:
UserWarning: Setuptools is replacing distutils.
> > warnings.warn("Setuptools is replacing distutils.")
> > /usr/lib/python3.10/distutils/dist.py:274: UserWarning: Unknown
distribution option: 'install_requires'
> > warnings.warn(msg)
> > running clean
> > Traceback (most recent call last):
> > File "/<>/setup.py", line 6, in
> > setup(name='azure-cosmos',
> > File "/usr/lib/python3.10/distutils/core.py", line 148, in setup
> > dist.run_commands()
> > File "/usr/lib/python3.10/distutils/dist.py", line 966, in
run_commands
> > self.run_command(cmd)
> > File "/usr/lib/python3.10/distutils/dist.py", line 983, in
run_command
> > cmd_obj = self.get_command_obj(command)
> > File "/usr/lib/python3.10/distutils/dist.py", line 858, in
get_command_obj
> > cmd_obj = self.command_obj[command] = klass(self)
> > File "/usr/lib/python3/dist-packages/setuptools/__init__.py",
line 158, in __init__
> > super().__init__(dist)
> > File "/usr/lib/python3/dist-
packages/setuptools/_distutils/cmd.py", line 59, in __init__
> > raise TypeError("dist must be a Distribution instance")
> > TypeError: dist must be a Distribution instance
> > E: pybuild pybuild:379: clean: plugin distutils failed with: exit
code=1: python3.10 setup.py clean
> > dh_auto_clean: error: pybuild --clean -i python{version} -p 3.10
returned exit code 13
> > make: *** [debian/rules:6: clean] Error 25
>
>
> The full build log is available from:
>
http://qa-logs.debian.net/2022/10/23/azure-cosmos-python_3.1.1-4_unstable.log
>
> All bugs filed during this archive rebuild are listed at:
>
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-20221023;users=lu...@debian.org
> or:
>
https://udd.debian.org/bugs/?release=na=ign=7=7=only=ftbfs-20221023=lu...@debian.org=1=1=1=1#results
>
> A list of current common problems and possible solutions is available
at
> http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to
contribute!
>
This is just calling:
from distutils.core import setup
import setuptools
setup(name='azure-cosmos',
version='3.1.1',
description='Azure Cosmos Python SDK',
author="Microsoft",
author_email="askdo...@microsoft.com",
maintainer="Microsoft",
maintainer_email="askdo...@microsoft.com",
url="https://github.com/Azure/azure-documentdb-python;,
license='MIT',
install_requires=['six >=1.6', 'requests>=2.10.0'],
classifiers=[
'License :: OSI Approved :: MIT License',
'Intended Audience :: Developers',
'Natural Language :: English',
'Operating System :: OS Independent',
'Programming Language :: Python',
'Programming Language :: Python :: 2.7',
'Programming Language :: Python :: 3.3',
'Programming Language :: Python :: 3.4',
'Programming Language :: Python :: 3.5',
'Programming Language :: Python :: Implementation :: CPython',
'Topic :: Software Development :: Libraries :: Python Modules'
],
packages=setuptools.find_packages(exclude=['test', 'test.*']))
I don't see how it can be anything else than a problem in distutils itself?
--
Kind regards,
Luca Boccassi
signature.asc
Description: This is a digitally signed message part
