Bug#1070673: azure-cli: contains telemetry
Control: tags -1 wontfix Control: close -1 On Mon, 6 May 2024 21:50:40 + "brian m. carlson" wrote: > Source: azure-cli > Version: 2.50.0-2 > Severity: normal > > The documentation in this package indicates that telemetry collection is > on by default, and I don't see any patches that indicate that that has > been removed. > > Debian should not ship software that sends telemetry by default because > it violates the privacy of users, and it is typically only in the > interest of the maintainer, not the users. It's not reasonable to > expect users to configure every package they might install separately > not to send telemetry, since that's impractical and it's nearly > impossible to configure every piece of software to do so, especially in > environments like containers where users' settings are often not > persisted. > > Please remove the telemetry functionality from the package or ensure > that it is rendered completely nonfunctional, and add a note to the > README.Debian indicating this change so that users can feel more > confident in using the package. The entire and sole purpose of this package is to interact with a public cloud, using your account and your internet connection. If you are afraid of some unspecified telemetry, you really should not be using a public cloud in the first place. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1059857: discrepancy between upstream and downstream .service files
On Tue, 2 Jan 2024 18:49:59 +0100 Chris Hofstaedtler wrote: > Hi! > > On Tue, Jan 02, 2024 at 02:19:39PM +0100, Michael Biebl wrote: > > today I wanted to enable the iSCSI test in systemd: > > https://salsa.debian.org/systemd-team/systemd/-/blob/debian/master/test/TEST-64-UDEV-STORAGE/test.sh?ref_type=heads#L29-34 > > > > For that I added test dependency on open-iscsi and tgt. > > Unfortunately, this failed: > > ``` > > W: Failed to install '/usr/lib/systemd/system/iscsi-init.service' > > I: Skipping program /usr/lib/systemd/system/iscsi-init.service as it cannot be found and is flagged to be optional > > W: Failed to install '/usr/lib/systemd/system/iscsi-onboot.service' > > I: Skipping program /usr/lib/systemd/system/iscsi-onboot.service as it cannot be found and is flagged to be optional > > W: Failed to install '/usr/lib/systemd/system/iscsi- shutdown.service' > > I: Skipping program /usr/lib/systemd/system/iscsi-shutdown.service as it cannot be found and is flagged to be optional > > W: Failed to install '/usr/lib/systemd/system/iscsi.service' > > F: Failed to install /usr/lib/systemd/system/iscsi.service > > make: Leaving directory '/tmp/autopkgtest.yvEXDQ/build.n6X/real- tree/test/TEST-64-UDEV-STORAGE' > > [13:12:37] --x-- Result of TEST-64-UDEV-STORAGE: 2 --x-- > > ``` > > > > I notice that the Debian open-iscsi package ships custom service files > > with a custom naming: > [..] > > > > Would it be possible to use the upstream service files or at least align > > the names? > > As noted briefly on IRC, TTBOMK each distro has its own service > files, and upstream has yet another set of them. The names referend > in your systemd test output look Fedora-specific to me. > > IMO these things would be interesting to consider (in any order): > *) teach systemd tests about the Debian/Ubuntu setup > *) try to converge more towards the upstream set, if that one is > actually complete. Note that you don't need to rename them, just add aliases - assuming they provide similar enough functionality of course. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#996202: EFI Secure Boot for systemd-boot
On Fri, 10 May 2024 at 15:51, Luca Boccassi wrote: > > On Fri, 10 May 2024 at 15:49, Steve McIntyre wrote: > > > > On Fri, May 10, 2024 at 03:44:35PM +0100, Luca Boccassi wrote: > > >On Fri, 10 May 2024 at 15:36, Steve McIntyre wrote: > > >> On Fri, May 10, 2024 at 04:29:00PM +0200, Ansgar wrote: > > >> > > >> >Maybe we should use a non-trusted cert for the initial setup and only > > >> >switch to a proper cert once everything is confirmed to be working as > > >> >expected? > > >> > > >> Hmmm, maybe? Luca? > > > > > >What do you mean precisely here? A DSA-managed cert used by FTP to > > >sign but that doesn't chain to the Debian CA? Or to do something > > >completely local to the systemd-boot package? > > > > Exactly the former - we can use a test key for signing systemd-boot to > > start with. Once we're happy all round, we can switch to a cert in the > > chain. > > > > >I am fine with any approach that lets us move forward, if that needs > > >to be some intermediate testing stage that's fine by me. > > > > Cool. > > Ok, sounds good to me, thanks. > > DSA, now that FTP Team has acked with this suggestion to use a test > cert first, are you happy to proceed or is there anything else you > need from me? Thanks! As suggested by DSA, I filed a ticket on RT about this: https://rt.debian.org/Ticket/Display.html?id=9506
Bug#1071603: systemd-udevd.service: kdump : failed to call kexec_load system call : Operation not permitted
Control: reassign -1 kdump-tools 1:1.8.1 On Wed, 22 May 2024 00:46:42 -0700 Yong Wang wrote: > Package: udev > Version: 252.22-1~deb12u1 > Severity: important > X-Debbugs-Cc: yongw...@nvidia.com > > Dear Maintainer, > > The error shows up every time when cpu "online" event triggers "kdump-config try-reload", > with error message : "kdump-config: failed to unload kdump kernel" (in syslog), due to > kexec_load system call (belongs to "@reboot" set) is missing in whitelist i.e. "SystemCallFilter" > setting in systemd-udevd.service. > In SMP system, performing the following command can trigger cpu "online" event: > echo 0 > /sys/devices/system/cpu/cpu1/online > echo 1 > /sys/devices/system/cpu/cpu1/online > kdump kernel is expected to be unloaded and reloaded successfully in this scenario rather than > getting such error message. There is no such rule in the udev package, it comes from kdump-tools: https://sources.debian.org/data/main/k/kdump-tools/1%3A1.10.3/debian/kdump-tools.udev If a package adds rules that require additional permissions, then it's that package that needs to ship a drop-in to allow them, otherwise the attack surface is increased even for those that don't use it. kdump-tools maintainers, please ship a drop-in like this together with your udev rule: /usr/lib/systemd/system/systemd-udevd.service.d/debian-kdump-tools- kexec.conf [Service] SystemCallFilter=@reboot (note that I haven't tested this) -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1071629: loginctl.1: some remarks and editorial changes for this man page
Control: tags -1 -patch wontfix Control: close -1 On Wed, 22 May 2024 15:11:06 + Bjarni Ingi Gislason wrote: > Package: systemd > Version: 255.5-1 > Severity: minor > Tags: patch > > Dear Maintainer, > > here are some notes and editorial fixes for the manual 'loginctl.1'. > > The patch is in the attachment. These manpages are generated from XML, so they cannot be patched. If you have fixes, please submit them directly upstream: https://github.com/systemd/systemd/blob/main/man/loginctl.xml -- 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#1071599: netplan.io: nocheck profile FTBFS
Source: netplan.io Severity: important Trying a build with the nocheck profile+option fails as meson expects pytest to be present: Program pytest-3 pytest3 found: NO ../meson.build:28:9: ERROR: Program 'pytest-3 pytest3' not found or not executable -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1071592: fails to enable LVM on crypt during boot, rendering the system unbootable
Control: reassign -1 dracut 060+5-1 On Tue, 21 May 2024 21:47:37 +0200 Evgeni Golov wrote: > Package: systemd > Version: 256~rc2-3 > Severity: important > > Ohai, > > I am filing this against systemd, as that's the package that triggers > the issue when upgraded, but it very well might be in dracut, so please > re-assign as you see fit. > Also filing this "only" as important, as it's breaking a non-default > setup and I did not verify this on any other system. > > My laptop is running sid with / on LVM on crypt. I am using dracut for > initrd generation. > > With the upgrade to systemd 256 (from 255.5) it fails to boot: > 1. asks for my passphrase > 2. systemd-cryptsetup@.service starts > 3. dev-mapper--.device runs forever, never reaching completion > > I can get it to boot by: > 1. rd.break=pre-mount in the bootloader to interrupt dracut > 2. lvm lvchange -ae / in the dracut shell > > I am aware of #1071278 but I do have dracut 060+5-8 which is supposed to > have all the required fixes. > > Downgrading systemd to 255.5-1 and regenerating the initrd fixes the > boot process. It's probably the same issue with missing libraries, but I do not use either dracut nor LVM so I cannot help, reassigning to dracut so that you might get some help with debugging and finding out what the actual issue is -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1050256: AppArmor breaks locking non-fs Unix sockets
On Sun, 28 Jan 2024 10:57:03 +0100 Salvatore Bonaccorso
wrote:
> Hi John,
>
> On Sun, Jan 28, 2024 at 12:43:33AM -0800, John Johansen wrote:
> > On 12/30/23 20:24, Mathias Gibbens wrote:
> > > On Sat, 2023-12-30 at 16:44 +0100, Salvatore Bonaccorso wrote:
> > > > John, did you had a chance to work on this backport for 6.1.y
stable
> > > > upstream so we could pick it downstream in Debian in one of the
next
> > > > stable imports? Cherry-picking 1cf26c3d2c4c ("apparmor: fix
apparmor
> > > > mediating locking non-fs unix sockets") does not work, if not
> > > > havinging the work around e2967ede2297 ("apparmor: compute
policydb
> > > > permission on profile load") AFAICS, so that needs a 6.1.y
specific
> > > > backport submitted to sta...@vger.kernel.org ?
> > > >
> > > > I think we could have people from this bug as well providing a
> > > > Tested-by when necessary. I'm not feeling confident enough to
be able
> > > > to provide myself such a patch to sent to stable (and you only
giving
> > > > an Acked-by/Reviewed-by), so if you can help out here with your
> > > > upstream hat on that would be more than appreciated and welcome
:)
> > > >
> > > > Thanks a lot for your work!
> > >
> > > I played around with this a bit the past week as well, and
came to
> > > the same conclusion as Salvatore did that commits e2967ede2297
and
> > > 1cf26c3d2c4c need to be cherry-picked back to the 6.1 stable
tree.
> > >
> > > I've attached the two commits rebased onto 6.1.y as patches to
this
> > > message. Commit e2967ede2297 needed a little bit of touchup to
apply
> > > cleanly, and 1cf26c3d2c4c just needed adjustments for line number
> > > changes. I included some comments at the top of each patch.
> > >
> > > With these two commits cherry-picked on top of the 6.1.69
kernel, I
> > > can boot a bookworm system and successfully start a service
within a
> > > container that utilizes `PrivateNetwork=yes`. Rebooting back into
an
> > > unpatched vanilla 6.1.69 kernel continues to show the problem.
> > >
> > > While I didn't see any immediate issues (ie, `aa-status` and
log
> > > files looked OK), I don't understand the changes in the first
commit
> > > well enough to be confident in sending these patches for
inclusion in
> > > the upstream stable tree on my own.
> > >
> > > Mathias
> >
> > Your backports look good to me, and you can stick my acked-by on
them.
> > The changes are strictly more than necessary for the fix. They are
> > part of a larger change set that is trying to cleanup the runtime
> > code by changing the permission mapping from a runtime operation
> > to something that is done only at policy load/unpack time.
> >
> > The advantage of this approach is that while it is a larger change
> > than strictly necessary. It is backporting patches that are already
> > upstream, keep the code closer and making backports easier.
> >
> > Georgia did a minimal backport fix by keeping the version as part
> > of policy and doing the permission mapping at runtime. I have
> > included that patch below. Its advantage is it is a minimal
> > change to fix the issue.
> >
> > I am happy with either version going into stable. Do you want to
> > send them or do you want me to do it?
> Thanks a lot, that is *really* much appreicated!
>
> if you can send them that would be great, because think then they
> come
> directly from you, the trust from Greg or Sasha is higher. otherwise
> I
> think they will then explicitly want an ack on that submission thread
> from you (or pointing to this Debian downstream bug).
>
> Greg will probably want the backport apporach of the two commits if
> it
> feasible and we do not expect regression from it. But you are
> definitively in a better position to judge this :)
>
> Thanks again!
>
> Regards,
> Salvatore
>
> p.s.: feel free to CC us as well in the upstream stable submission.
Hi John,
Is there any update on this? As far as I am aware this patch has not
been sent for backporting yet, so apparmor in 6.1 is still borken, and
the CI still fails because of it.
Is there any chance you could please take care of that, so that we can
finally fix this issue?
Thanks!
--
Kind regards,
Luca Boccassi
signature.asc
Description: This is a digitally signed message part
Bug#1071582: ip: Poor color choice for dark background
On Tue, 21 May 2024 at 16:41, Diederik de Haas wrote: > > On Tuesday, 21 May 2024 16:57:40 CEST Gedalya wrote: > > On 5/21/24 10:55 PM, Luca Boccassi wrote: > > > This has always been enabled by default, even in stable. > > > > What is the meaning of this line in the changelog for 6.9.0-1, and why does > > it correlate with an actual change in behavior? > > > > Quote: > > * Enable output with colors on terminals > > Can confirm that the output changed significantly. > Previously it was all gray-ish (on black) and after the upgrade it got all > colorful. > The (color) output I got when ssh-ed into another machine was (significantly) > different then on my local PC. And the blue of the IPv6 addresses is indeed > very hard to read. > > Took some screenshots to show it. If you don't like the default settings, please send a patch upstream to change them. I am not going to patch downstream (nor disable it) for personal preferences, so reporting it here is just a waste of time.
Bug#1071582: ip: Poor color choice for dark background
Control: close -1 wontfix Control: close -1 On Tue, 21 May 2024 at 15:51, Gedalya wrote: > > Package: iproute2 > Version: 6.9.0-1 > Severity: minor > > Hello, > > The newly enabled colored output is rather hard to read on dark backgrounds, > especially the deep blue color used for IPv6 addresses. > > Setting COLORFGBG=";0" as the manpage suggests helps a lot. > > Consider a scenario when this command is used under stress to manually bring > up networking from a VT. It's a rather basic command that would typically run > on a dark background and it's important for it to be accessible by default > without fiddling around too much. This has always been enabled by default, even in stable. As per manpage, you can disable it if you don't want it.
Bug#1071462: installing/upgrading libc6 does not work in sbuild when systemd is installed as ischroot declines
On Mon, 20 May 2024 at 15:11, Johannes Schauer Marin Rodrigues wrote: > > Hi, > > Quoting Aurelien Jarno (2024-05-20 11:49:32) > > > > > That's all legacy stuff and I really don't want to touch it anymore. > > > > > Going from the other side, maybe libc6.postinst could use something > > > > > more reliable than ischroot()? Is systemd-detect-virt able to figure > > > > > out the situation a bit better? > > > > Nope. > > > What's the output? With SYSTEMD_LOG_LEVEL=debug exported > > In sbuild using unshare chroot running in a VM: > > > > | SYSTEMD_LOG_LEVEL=debug /usr/bin/systemd-detect-virt > > | Failed to read $container of PID 1, ignoring: Permission denied > > | Found cgroup2 on /sys/fs/cgroup/, full unified hierarchy > > | Found container virtualization none. > > | Virtualization QEMU found in DMI (/sys/class/dmi/id/sys_vendor) > > | UML virtualization not found in /proc/cpuinfo. > > | Virtualization XEN not found, /proc/xen does not exist > > | Virtualization found, CPUID=KVMKVMKVM > > | Found VM virtualization kvm > > | kvm > > would it help (and be correct) if PID 1 in sbuild unshare mode would have the > "container" environment variable set to something? And/or if sbuild unshare > mode would create the file /run/systemd/container with some content? > > I'd need input from somebody who knows how containers (if this is one) are > supposed to work. :) Does it run in PID + mount + user namespaces, on a different filesystem than the host? If so, then yeah it does look like a container
Bug#1071462: installing/upgrading libc6 does not work in sbuild when systemd is installed as ischroot declines
On Mon, 20 May 2024 at 10:42, Aurelien Jarno wrote: > > On 2024-05-20 10:38, Chris Hofstaedtler wrote: > > * Johannes Schauer Marin Rodrigues [240520 07:35]: > > > [..] But maybe it [glibc's postinst] should be doing some > > > more involved checks about what PID 1 is? It could then make sure to only > > > call > > > systemd telinit if systemd is pid 1. [..] > > > > Well, that would probably suck. Putting the knowledge when to call > > telinit, and a specific telinit, into a ton of different things > > makes all those things hard to get right, hard to update, the usual. > > On the glibc side, this part has always been a pain to handle (a bit > less since upstart got removed). And the systemd decision to increase > the use of dlopen() will make this step even more necessary. > > Therefore I wonder if it could be solved using the trigger mechanism, > basically glibc saying "I got upgraded" and the packages, being systemd, > sysv or any other system can then decide what to do instead of > hardcoding that on the glibc side. > > That would also simplify the chrootless case a bit. Each package's postinst already needs to do the right thing on upgrade, so yeah that sounds like a good idea to me.
Bug#1071462: installing/upgrading libc6 does not work in sbuild when systemd is installed as ischroot declines
On Mon, 20 May 2024 at 10:49, Aurelien Jarno wrote: > > On 2024-05-20 10:40, Luca Boccassi wrote: > > On Mon, 20 May 2024 at 10:37, Aurelien Jarno wrote: > > > > > > On 2024-05-20 10:22, Luca Boccassi wrote: > > > > On Mon, 20 May 2024 at 10:20, Johannes Schauer Marin Rodrigues > > > > wrote: > > > > > > > > > > Hi, > > > > > > > > > > Quoting Chris Hofstaedtler (2024-05-20 10:38:04) > > > > > > * Johannes Schauer Marin Rodrigues [240520 > > > > > > 07:35]: > > > > > > > [..] But maybe it [glibc's postinst] should be doing some > > > > > > > more involved checks about what PID 1 is? It could then make sure > > > > > > > to only call > > > > > > > systemd telinit if systemd is pid 1. [..] > > > > > > > > > > > > Well, that would probably suck. Putting the knowledge when to call > > > > > > telinit, and a specific telinit, into a ton of different things > > > > > > makes all those things hard to get right, hard to update, the usual. > > > > > > > > > > > > I've checked the sysvinit and the systemd implementations now, and > > > > > > they are not that different. Both try to talk to their respective > > > > > > pid1 daemons first using their respective communication socket. > > > > > > > > > > > > But then, if that doesn't work, they diverge: > > > > > > - sysvinit's telinit just gives up > > > > > > - systemd's telinit, *as an explicit fallback*, sends signals. > > > > > > > > > > > > systemd's telinit (aka systemctl) helpfully exits if it detects > > > > > > being in a chroot, before doing any of that. > > > > > > > > > > > > IWSTM systemd's telinit could, if called as telinit, not do the > > > > > > fallback to stick with sysvinit's behaviour? > > > > > > > > > > > > As a bonus, sysvinit's telinit could also gain the chroot check, > > > > > > and glibc's > > > > > > postinst (and other places) can become simpler again. > > > > > > > > > > via irc, jochen also pointed out: telinit could be the component > > > > > which checks > > > > > what PID 1 actually is and only do its thing after it confirmed that > > > > > it is > > > > > indeed an init system like systemd that is providing PID 1? > > > > > > > > That's all legacy stuff and I really don't want to touch it anymore. > > > > Going from the other side, maybe libc6.postinst could use something > > > > more reliable than ischroot()? Is systemd-detect-virt able to figure > > > > out the situation a bit better? > > > > > > Nope. > > > > What's the output? With SYSTEMD_LOG_LEVEL=debug exported > > In sbuild using unshare chroot running in a VM: > > | SYSTEMD_LOG_LEVEL=debug /usr/bin/systemd-detect-virt > | Failed to read $container of PID 1, ignoring: Permission denied > | Found cgroup2 on /sys/fs/cgroup/, full unified hierarchy > | Found container virtualization none. > | Virtualization QEMU found in DMI (/sys/class/dmi/id/sys_vendor) > | UML virtualization not found in /proc/cpuinfo. > | Virtualization XEN not found, /proc/xen does not exist > | Virtualization found, CPUID=KVMKVMKVM > | Found VM virtualization kvm > | kvm Is sbuild running unshare with a user namespace (-U)? If so, systemd-detect-virt --private-users should catch that
Bug#1071462: installing/upgrading libc6 does not work in sbuild when systemd is installed as ischroot declines
On Mon, 20 May 2024 at 10:37, Aurelien Jarno wrote: > > On 2024-05-20 10:22, Luca Boccassi wrote: > > On Mon, 20 May 2024 at 10:20, Johannes Schauer Marin Rodrigues > > wrote: > > > > > > Hi, > > > > > > Quoting Chris Hofstaedtler (2024-05-20 10:38:04) > > > > * Johannes Schauer Marin Rodrigues [240520 07:35]: > > > > > [..] But maybe it [glibc's postinst] should be doing some > > > > > more involved checks about what PID 1 is? It could then make sure to > > > > > only call > > > > > systemd telinit if systemd is pid 1. [..] > > > > > > > > Well, that would probably suck. Putting the knowledge when to call > > > > telinit, and a specific telinit, into a ton of different things > > > > makes all those things hard to get right, hard to update, the usual. > > > > > > > > I've checked the sysvinit and the systemd implementations now, and > > > > they are not that different. Both try to talk to their respective > > > > pid1 daemons first using their respective communication socket. > > > > > > > > But then, if that doesn't work, they diverge: > > > > - sysvinit's telinit just gives up > > > > - systemd's telinit, *as an explicit fallback*, sends signals. > > > > > > > > systemd's telinit (aka systemctl) helpfully exits if it detects > > > > being in a chroot, before doing any of that. > > > > > > > > IWSTM systemd's telinit could, if called as telinit, not do the > > > > fallback to stick with sysvinit's behaviour? > > > > > > > > As a bonus, sysvinit's telinit could also gain the chroot check, and > > > > glibc's > > > > postinst (and other places) can become simpler again. > > > > > > via irc, jochen also pointed out: telinit could be the component which > > > checks > > > what PID 1 actually is and only do its thing after it confirmed that it is > > > indeed an init system like systemd that is providing PID 1? > > > > That's all legacy stuff and I really don't want to touch it anymore. > > Going from the other side, maybe libc6.postinst could use something > > more reliable than ischroot()? Is systemd-detect-virt able to figure > > out the situation a bit better? > > Nope. What's the output? With SYSTEMD_LOG_LEVEL=debug exported
Bug#1071462: installing/upgrading libc6 does not work in sbuild when systemd is installed as ischroot declines
On Mon, 20 May 2024 at 10:20, Johannes Schauer Marin Rodrigues wrote: > > Hi, > > Quoting Chris Hofstaedtler (2024-05-20 10:38:04) > > * Johannes Schauer Marin Rodrigues [240520 07:35]: > > > [..] But maybe it [glibc's postinst] should be doing some > > > more involved checks about what PID 1 is? It could then make sure to only > > > call > > > systemd telinit if systemd is pid 1. [..] > > > > Well, that would probably suck. Putting the knowledge when to call > > telinit, and a specific telinit, into a ton of different things > > makes all those things hard to get right, hard to update, the usual. > > > > I've checked the sysvinit and the systemd implementations now, and > > they are not that different. Both try to talk to their respective > > pid1 daemons first using their respective communication socket. > > > > But then, if that doesn't work, they diverge: > > - sysvinit's telinit just gives up > > - systemd's telinit, *as an explicit fallback*, sends signals. > > > > systemd's telinit (aka systemctl) helpfully exits if it detects > > being in a chroot, before doing any of that. > > > > IWSTM systemd's telinit could, if called as telinit, not do the > > fallback to stick with sysvinit's behaviour? > > > > As a bonus, sysvinit's telinit could also gain the chroot check, and glibc's > > postinst (and other places) can become simpler again. > > via irc, jochen also pointed out: telinit could be the component which checks > what PID 1 actually is and only do its thing after it confirmed that it is > indeed an init system like systemd that is providing PID 1? That's all legacy stuff and I really don't want to touch it anymore. Going from the other side, maybe libc6.postinst could use something more reliable than ischroot()? Is systemd-detect-virt able to figure out the situation a bit better?
Bug#1071447: iproute2: IPv6 route in VRF context fails with 'Invalid source address' due to default VRF check.
Control: tags -1 upstream On Sun, 19 May 2024 15:39:05 +0200 Tharyrok wrote: > Package: iproute2 > X-Debbugs-Cc: d...@tharyrok.eu > Version: 6.9.0-1 > Severity: normal > Tags: ipv6 > > Dear Maintainer, > > I am encountering an issue when adding an IPv6 route within a VRF > context on Debian using ifupdown2. The problem occurs when I attempt to > add an unreachable default route with a specific source address. I > receive an "Invalid source address" error. However, this issue does not > occur with IPv4 routes under similar conditions. Please report this upstream, there are no patches in Debian so the behaviour is just what upstream provides. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1071462: installing/upgrading libc6 does not work in sbuild when systemd is installed as ischroot declines
On Sun, 19 May 2024 18:42:17 +0200 Helmut Grohne wrote: > the init process should handle SIGTERM more like an init system would handle that This seems the obvious answer to me. sbuild is setting up a system such that its component runs as pid1, so it needs to behave like a pid1. We know this is special and requires supporting a number of interfaces. If a program doesn't, then it shouldn't be running as pid1 in a namespace. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1071420: linux-image-6.8.9-1-amd64: cannot mount btrfs root partition
Control: reassign -1 src:linux Control: severity -1 grave On Sun, 19 May 2024 15:25:06 +0200 Salvatore Bonaccorso wrote: > Control: reassign -1 src:systemd > > On Sat, May 18, 2024 at 10:25:14PM +0200, Matteo Settenvini wrote: > > Package: src:linux > > Version: 6.8.9-1 > > Severity: important > > Tags: upstream > > > > Dear Maintainer, > > > > booting kernel 6.8.9-1 with dracut, systemd, and btrfs as the root device fails > > to mount the root partition. I just tried the kernel from sid and it seems indeed \ > > affected. The 6.7 kernel from trixie is instead booting fine even after > > regenerating all initrds. > > > > According to bl...@debian.org, this is likely due to > > https://github.com/torvalds/linux/commit/a1912f712188291f9d7d434fba155461f1ebef66 > > > > See https://lwn.net/Articles/973997/ > > The deprecation was there for a while indeed and dropped by upstream > for 6.8-rc1. But it looks systemd is adressing this with > > https://github.com/systemd/systemd/commit/e3828d7103a99a15a1e947ba3063294ead590631 > > As we wont apply a local Debian patch unless upstream Linux decides to > facilitate this by adding a noop option back, then I think it's best > to reassign this bug to systemd and close it once the above change is > applied. Sorry, but I am reassigning back and bumping severity to stop migration, as this is a kernel regression, as a stable userspace interface was removed, which breaks booting existing systems. Hence I am quite sure the new kernel should not move to testing for the time being. We might (or might not, still to be seen, given detecting mount options that a kernel support is an absolute mess and it risks breaking booting with the LTS kernels) put in a workaround in userspace in a while, but this really should be reverted in the kernel. If mount options are no longer required, they should simply remain as no-ops. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1071108: RM: bpfcc [ppc64el] -- RoQA; FTBFS on ppc64el
On Fri, 17 May 2024 at 15:11, Luca Boccassi wrote: > > Control: tags -1 -moreinfo > > On Fri, 17 May 2024 at 15:03, Luca Boccassi wrote: > > > > On Fri, 17 May 2024 09:08:41 -0400 Scott Kitterman > > wrote: > > > On Tue, 14 May 2024 14:10:44 +0100 Luca Boccassi > > wrote: > > > > Package: ftp.debian.org > > > > Severity: normal > > > > X-Debbugs-CC: nil...@debian.org, r...@debian.org, vasu...@debian.org > > > > > > > > Hi, > > > > > > > > As per > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1070768 with > > > > the agreement of the maintainers I have NMUed bpfcc/0.29.1+ds-1.1 > > to > > > > remove ppc64el, as it has been failing to build for months and has > > kept > > > > the package out of testing. > > > > Please remove the ppc64el binary packages. > > > > > > This is going to be a little more complicated than that. > > > > > > Checking reverse dependencies... > > > # Broken Depends: > > > bpfcc: python3-bpfcc > > > bpftrace: bpftrace > > > golang-github-iovisor-gobpf: golang-github-iovisor-gobpf-dev > > > oci-seccomp-bpf-hook: oci-seccomp-bpf-hook > > > > > > For the arch: all packages like python3-bpfcc, there's nothing to > > do. For the > > > arch specific packages, bpftrace and oci-seccomp-bpf-hook, they will > > have to be > > > removed first. > > > > > > bpftrace should be just another rm bug. Once bpfcc is removed, it > > should no > > > longer build on ppc64el. oci-seccomp-bpf-hook on the other hand > > seems to be > > > more complicated. It does not appear that oci-seccomp-bpf-hook > > build-depends > > > on libbpfcc-dev, so even if it's ppc64el binary is removed, it would > > just > > > reappear after the next upload. > > > > I think for oci-seccomp-bpf-hook it's a transitive build dep, oci- > > seccomp-bpf-hook build deps on golang-github-iovisor-gobpf-dev which > > depends on libbpfcc-dev so it gets pulled in. So I think two RM bugs, > > one each for these two source packages, should be enough. I'll file > > them shortly. > > Actually golang-github-iovisor-gobpf-dev is arch: all, so only one > should be needed, no? > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1071275 > > Please correct me if I'm wrong bpfcc has migrated, nice - however, I forgot one RM request for bpftrace ppc64el, sorry about that: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1071423 This should also allow bpftrace to finally migrate again to testing.
Bug#1071423: RM: bpftrace [ppc64el] -- RoQA; FTBFS on ppc64el
Package: ftp.debian.org Severity: normal X-Debbugs-CC: ber...@debian.org As per https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1070768 with the agreement of the maintainers I have NMUed bpfcc/0.29.1+ds-1.1 to remove ppc64el, as it has been failing to build for months and has kept the package out of testing. As per https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1071108 there are additional packages that need to have the ppc64el build removed, and bpftrace is the last one of those, so please remove the bpftrace ppc64el binary package. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]
> > what would break where, and how to fix it? I only found autopkgtest > so > > far, which uses /tmp/ in the guest and expects it to survive across > > reboots, and I have a MR up already for that. Anything else? > > Perhaps whatever makes these files in /tmp? i think something to do > with > X/gdm/gnome? > > /tmp/.X0-lock > /tmp/.X1024-lock > /tmp/.X1025-lock > > /tmp/.X11-unix > /tmp/.X1-lock > > /tmp/.XIM-unix > > /tmp/.font-unix > > /tmp/.ICE-unix These are all already covered by /usr/lib/tmpfiles.d/x11.conf -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1071280: /bin/loginctl: -P not documented in man page
Control: tags -1 upstream On Fri, 17 May 2024 17:41:59 +0200 Yannik Enss wrote: > Package: systemd > Version: 252.22-1~deb12u1 > Severity: minor > File: /bin/loginctl > > Dear Maintainer, > > loginctl has a command line option "-P", listed in the --help output, > that combines the --value und --property= options. > > While documented in the --help output, it is not mentioned in the man page. Please send this upstream on https://github.com/systemd/systemd/issues/new as there are no downstream-only manpages. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
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#1071108: RM: bpfcc [ppc64el] -- RoQA; FTBFS on ppc64el
Control: tags -1 -moreinfo On Fri, 17 May 2024 at 15:03, Luca Boccassi wrote: > > On Fri, 17 May 2024 09:08:41 -0400 Scott Kitterman > wrote: > > On Tue, 14 May 2024 14:10:44 +0100 Luca Boccassi > wrote: > > > Package: ftp.debian.org > > > Severity: normal > > > X-Debbugs-CC: nil...@debian.org, r...@debian.org, vasu...@debian.org > > > > > > Hi, > > > > > > As per > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1070768 with > > > the agreement of the maintainers I have NMUed bpfcc/0.29.1+ds-1.1 > to > > > remove ppc64el, as it has been failing to build for months and has > kept > > > the package out of testing. > > > Please remove the ppc64el binary packages. > > > > This is going to be a little more complicated than that. > > > > Checking reverse dependencies... > > # Broken Depends: > > bpfcc: python3-bpfcc > > bpftrace: bpftrace > > golang-github-iovisor-gobpf: golang-github-iovisor-gobpf-dev > > oci-seccomp-bpf-hook: oci-seccomp-bpf-hook > > > > For the arch: all packages like python3-bpfcc, there's nothing to > do. For the > > arch specific packages, bpftrace and oci-seccomp-bpf-hook, they will > have to be > > removed first. > > > > bpftrace should be just another rm bug. Once bpfcc is removed, it > should no > > longer build on ppc64el. oci-seccomp-bpf-hook on the other hand > seems to be > > more complicated. It does not appear that oci-seccomp-bpf-hook > build-depends > > on libbpfcc-dev, so even if it's ppc64el binary is removed, it would > just > > reappear after the next upload. > > I think for oci-seccomp-bpf-hook it's a transitive build dep, oci- > seccomp-bpf-hook build deps on golang-github-iovisor-gobpf-dev which > depends on libbpfcc-dev so it gets pulled in. So I think two RM bugs, > one each for these two source packages, should be enough. I'll file > them shortly. Actually golang-github-iovisor-gobpf-dev is arch: all, so only one should be needed, no? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1071275 Please correct me if I'm wrong
Bug#1071275: RM: oci-seccomp-bpf-hook [ppc64el] -- RoQA; FTBFS on ppc64el
Package: ftp.debian.org Severity: normal X-Debbugs-CC: ca...@debian.org, team+pkg...@tracker.debian.org As per https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1070768 with the agreement of the maintainers I have NMUed bpfcc/0.29.1+ds-1.1 to remove ppc64el, as it has been failing to build for months and has kept the package out of testing. As per https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1071108 the removal is blocked by oci-seccomp-bpf-hook depending on bpfcc, so please remove the ppc64el binary packages. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1071108: RM: bpfcc [ppc64el] -- RoQA; FTBFS on ppc64el
On Fri, 17 May 2024 09:08:41 -0400 Scott Kitterman wrote: > On Tue, 14 May 2024 14:10:44 +0100 Luca Boccassi wrote: > > Package: ftp.debian.org > > Severity: normal > > X-Debbugs-CC: nil...@debian.org, r...@debian.org, vasu...@debian.org > > > > Hi, > > > > As per https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1070768 with > > the agreement of the maintainers I have NMUed bpfcc/0.29.1+ds-1.1 to > > remove ppc64el, as it has been failing to build for months and has kept > > the package out of testing. > > Please remove the ppc64el binary packages. > > This is going to be a little more complicated than that. > > Checking reverse dependencies... > # Broken Depends: > bpfcc: python3-bpfcc > bpftrace: bpftrace > golang-github-iovisor-gobpf: golang-github-iovisor-gobpf-dev > oci-seccomp-bpf-hook: oci-seccomp-bpf-hook > > For the arch: all packages like python3-bpfcc, there's nothing to do. For the > arch specific packages, bpftrace and oci-seccomp-bpf-hook, they will have to be > removed first. > > bpftrace should be just another rm bug. Once bpfcc is removed, it should no > longer build on ppc64el. oci-seccomp-bpf-hook on the other hand seems to be > more complicated. It does not appear that oci-seccomp-bpf-hook build-depends > on libbpfcc-dev, so even if it's ppc64el binary is removed, it would just > reappear after the next upload. I think for oci-seccomp-bpf-hook it's a transitive build dep, oci- seccomp-bpf-hook build deps on golang-github-iovisor-gobpf-dev which depends on libbpfcc-dev so it gets pulled in. So I think two RM bugs, one each for these two source packages, should be enough. I'll file them shortly. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
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#1071178: open-iscsi: uses /run/lock in early boot without dependency
Package: open-iscsi Version: 2.1.9-3 Severity: important Tags: patch A long time ago (#751392) a patch was added to systemd to make it create a tmpfs on /run/lock/ before starting any units, in order to deal with some debianisms and hysterical raisins. This patch was never accepted upstream. I am now doing spring cleaning, and this patch will be dropped, in favour of a standard early boot mount unit. This means any service potentially using /run/lock and running before sysinit.target (ie: DefaultDependencies=no) needs an explicit ordering statement to avoid the tmpfs being created on top of them while already running. This can be achieved with a simple drop-in. A patch is available as a MR on Salsa: https://salsa.debian.org/linux-blocks-team/open-iscsi/-/merge_requests/19 This package was flagged with codesearch queries, so if it's a false positive and these services do not actually use /run/lock please feel free to close this bug and the MR. I will upload a new version of systemd with run-lock.mount sometimes next week, but there's no need to wait as ordering is simply ignored if the referenced unit doesn't exist. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1071175: lvm2: uses /run/lock in early boot without dependency
Package: lvm2 Version: 2.03.22-1 Severity: important Tags: patch A long time ago (#751392) a patch was added to systemd to make it create a tmpfs on /run/lock/ before starting any units, in order to deal with some debianisms and hysterical raisins. This patch was never accepted upstream. I am now doing spring cleaning, and this patch will be dropped, in favour of a standard early boot mount unit. This means any service potentially using /run/lock and running before sysinit.target (ie: DefaultDependencies=no) needs an explicit ordering statement to avoid the tmpfs being created on top of them while already running. This can be achieved with a simple drop-in. A patch is available as a MR on Salsa: https://salsa.debian.org/lvm-team/lvm2/-/merge_requests/14 I will upload a new version of systemd with run-lock.mount sometimes next week, but there's no need to wait as ordering is simply ignored if the referenced unit doesn't exist. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1071109: RM: openconnect/experimental -- ROM; t64 transition not needed
Package: ftp.debian.org Severity: normal Hi, Please remove the t64 renamed packages of openconnect from experimental, the transition wasn't actually needed as per #1062838, and there likely won't be a new version to automatically prune it for some time. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1071108: RM: bpfcc [ppc64el] -- RoQA; FTBFS on ppc64el
Package: ftp.debian.org Severity: normal X-Debbugs-CC: nil...@debian.org, r...@debian.org, vasu...@debian.org Hi, As per https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1070768 with the agreement of the maintainers I have NMUed bpfcc/0.29.1+ds-1.1 to remove ppc64el, as it has been failing to build for months and has kept the package out of testing. Please remove the ppc64el binary packages. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1071092: systemd-resolved: Ping reply about 15 seconds after instead of near instantaneously
Control: found -1 252.11-1 Control: fixed -1 255.5-1 Control: fixed -1 252.24-1~deb12u1 Control: close -1 On Tue, 14 May 2024 09:13:20 +0200 Patrick ZAJDA wrote: > Package: systemd-resolved > Version: 254.5-1~bpo12+3 > Severity: normal > Tags: ipv6 upstream > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Dear Maintainer, > > I use Network-Manager as my network manager but this also applies for other E.G. same occurs with Systemd Network. > Until now, when sending a ping to a domain which resolves to an IPv6 address, it takes a very short delay to have an output returned. > But with SystemD-resolved, resolution takes about 15 seconds. > This issue should have been fixed upstream [1] but I don't precisely know which SystemD version solves it nor if it is stable. > It makes ping less efficient with this long delay before having a reply. > > It occurs with the Backport version as specified but also with the version in Bookworm (252.22-1~deb12u1). > > Could it be possible to backport the fix to Bookworm? > For bookworm-backports, is it planned to release a new version when available? There will be no more backports updates. -- 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#996202: EFI Secure Boot for systemd-boot
On Fri, 10 May 2024 at 15:49, Steve McIntyre wrote: > > On Fri, May 10, 2024 at 03:44:35PM +0100, Luca Boccassi wrote: > >On Fri, 10 May 2024 at 15:36, Steve McIntyre wrote: > >> On Fri, May 10, 2024 at 04:29:00PM +0200, Ansgar wrote: > >> > >> >Maybe we should use a non-trusted cert for the initial setup and only > >> >switch to a proper cert once everything is confirmed to be working as > >> >expected? > >> > >> Hmmm, maybe? Luca? > > > >What do you mean precisely here? A DSA-managed cert used by FTP to > >sign but that doesn't chain to the Debian CA? Or to do something > >completely local to the systemd-boot package? > > Exactly the former - we can use a test key for signing systemd-boot to > start with. Once we're happy all round, we can switch to a cert in the > chain. > > >I am fine with any approach that lets us move forward, if that needs > >to be some intermediate testing stage that's fine by me. > > Cool. Ok, sounds good to me, thanks. DSA, now that FTP Team has acked with this suggestion to use a test cert first, are you happy to proceed or is there anything else you need from me? Thanks!
Bug#996202: EFI Secure Boot for systemd-boot
On Fri, 10 May 2024 at 15:36, Steve McIntyre wrote: > > On Fri, May 10, 2024 at 04:29:00PM +0200, Ansgar wrote: > >Hi, > > > >On Fri, 2024-05-10 at 15:20 +0100, Luca Boccassi wrote: > >> On Thu, 04 Apr 2024 20:41:59 +0100 Luca Boccassi > >> > On IRC Steve mentioned that he's ok with proceeding with this. > >> > jcristau from DSA said that it's the FTP team that should confirm the > >> > request > >> > for the new intermediate signer cert for systemd-boot to DSA. > >> > > >> > FTP team, are you ok with proceeding with this? If so, would it be > >> > possible to have an ACK, please? Is there any more information required > >> > beforehand? > > > >As long as the security boot people are fine with this, I think this > >should be fine. (And AFAIU this seems to be the case.) > > Yes, I'm happy for us to add this. Please go ahead. > > >Maybe we should use a non-trusted cert for the initial setup and only > >switch to a proper cert once everything is confirmed to be working as > >expected? > > Hmmm, maybe? Luca? What do you mean precisely here? A DSA-managed cert used by FTP to sign but that doesn't chain to the Debian CA? Or to do something completely local to the systemd-boot package? I am fine with any approach that lets us move forward, if that needs to be some intermediate testing stage that's fine by me.
Bug#996202: EFI Secure Boot for systemd-boot
On Thu, 04 Apr 2024 20:41:59 +0100 Luca Boccassi wrote: > On Fri, 22 Mar 2024 18:13:35 +0000 Luca Boccassi > wrote: > > On Mon, 4 Mar 2024 at 23:58, Luca Boccassi wrote: > > > > > > On Mon, 4 Mar 2024 at 23:28, Steve McIntyre > wrote: > > > > > > > Modulo those questions, let's talk infrastructure. Off the top of > my > > > > head, in no particular order... > > > > > > > > * We'll need to create a new intermediate signing cert for > > > > systemd-boot (and another for UKI, I guess). Given recent > > > > discussions about changing the way we build and sign kernels, > we > > > > should also generate a new signer cert for those too. And if > we're > > > > going that far, we may as well generate a complete new set of > 2024 > > > > certs. [Sorry, rabbithole. :-)] We'll need to talk to DSA > about > > > > doing this piece. > > > > > > That makes sense to me, I guess DSA owns the machinery to do this? > > > > > > > * We'll probably need to add things to the signing setup for > > > > ftp-master. Nothing earth-shattering, just some config to > > > > recognise the new set of packages IIRC. I'm sure Bastian can > > > > manage this. :-) > > > > > > > > * Are people from the team ready to deal with long-term > security > > > > support for the systemd-boot chain? > > > > > > Speaking for myself, yes, I am already part of the team who is > > > responsible for that upstream, and I plan to be very strict about > not > > > carrying downstream patches for the signed components outside of > > > security fixes (and even then, prefer upstream stable point > releases > > > that I am also responsible for anyway). > > > > > > > That's all I can think of for now, but I wouldn't be surprised if > more > > > > comes to mind tomorrow... :-) > > > > > > Thanks for the feedback! > > > > Gentle ping on this - what are the next steps in order to make this > happen? > > On IRC Steve mentioned that he's ok with proceeding with this. jcristau > from DSA said that it's the FTP team that should confirm the request > for the new intermediate signer cert for systemd-boot to DSA. > > FTP team, are you ok with proceeding with this? If so, would it be > possible to have an ACK, please? Is there any more information required > beforehand? > > Thanks! Hello FTP Team, One more gentle ping to unblock progress on this. TIA! -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1069881: bookworm-pu: package systemd/252.24-1~deb12u1
Control: retitle -1 bookworm-pu: package systemd/252.25-1~deb12u1
On Fri, 26 Apr 2024 11:47:51 +0100 Luca Boccassi
wrote:
> Package: release.debian.org
> Severity: normal
> Tags: bookworm
> User: release.debian@packages.debian.org
> Usertags: pu
> X-Debbugs-Cc: pkg-systemd-maintain...@lists.alioth.debian.org
>
> Dear Release Team,
>
> We would like to upload the latest stable point release of systemd
252
> to bookworm-p-u. Stable release branches are maintained upstream with
> the intention of providing bug fixes only and no compatibility
> breakages, and with automated non-trivial CI jobs that also cover
> Debian and Ubuntu. I have already uploaded to p-u.
>
> Packaging changes are limited to refreshing patches. Debdiff
attached.
> The list of commits included can be seen at:
>
> https://github.com/systemd/systemd-stable/compare/v252.23...v252.24
I have uploaded the next point release now, 252.25. Same as before,
just refreshing patches. The debdiff excludes hwdb generated IDs.
List of changes:
https://github.com/systemd/systemd-stable/compare/v252.24...v252.25
--
Kind regards,
Luca Boccassi
diff -Nru --exclude pnp_id_registry.html --exclude acpi_id_registry.html --exclude parse_hwdb.py --exclude acpi_id_registry.csv --exclude pnp_id_registry.csv --exclude usb.ids --exclude pci.ids --exclude ma-large.txt --exclude ma-medium.txt --exclude ma-small.txt --exclude '*hwdb.patch' --exclude '*hwdb' systemd-252.24/debian/changelog systemd-252.25/debian/changelog
--- systemd-252.24/debian/changelog 2024-04-26 01:34:18.0 +0100
+++ systemd-252.25/debian/changelog 2024-05-09 18:11:06.0 +0100
@@ -1,3 +1,10 @@
+systemd (252.25-1~deb12u1) bookworm; urgency=medium
+
+ * New upstream version 252.25
+ * Refresh patches for v252.25
+
+ -- Luca Boccassi Thu, 09 May 2024 18:11:06 +0100
+
systemd (252.24-1~deb12u1) bookworm; urgency=medium
* New upstream version 252.24
diff -Nru --exclude pnp_id_registry.html --exclude acpi_id_registry.html --exclude parse_hwdb.py --exclude acpi_id_registry.csv --exclude pnp_id_registry.csv --exclude usb.ids --exclude pci.ids --exclude ma-large.txt --exclude ma-medium.txt --exclude ma-small.txt --exclude '*hwdb.patch' --exclude '*hwdb' systemd-252.24/debian/patches/debian/Don-t-enable-audit-by-default.patch systemd-252.25/debian/patches/debian/Don-t-enable-audit-by-default.patch
--- systemd-252.24/debian/patches/debian/Don-t-enable-audit-by-default.patch 2024-04-26 01:34:02.0 +0100
+++ systemd-252.25/debian/patches/debian/Don-t-enable-audit-by-default.patch 2024-05-09 18:10:47.0 +0100
@@ -29,7 +29,7 @@
diff --git a/src/journal/journald-server.c b/src/journal/journald-server.c
-index a78e2c0..efeb50c 100644
+index 863575c..1b9b8e1 100644
--- a/src/journal/journald-server.c
+++ b/src/journal/journald-server.c
@@ -2279,7 +2279,7 @@ int server_init(Server *s, const char *namespace) {
diff -Nru --exclude pnp_id_registry.html --exclude acpi_id_registry.html --exclude parse_hwdb.py --exclude acpi_id_registry.csv --exclude pnp_id_registry.csv --exclude usb.ids --exclude pci.ids --exclude ma-large.txt --exclude ma-medium.txt --exclude ma-small.txt --exclude '*hwdb.patch' --exclude '*hwdb' systemd-252.24/debian/patches/debian/Downgrade-a-couple-of-warnings-to-debug.patch systemd-252.25/debian/patches/debian/Downgrade-a-couple-of-warnings-to-debug.patch
--- systemd-252.24/debian/patches/debian/Downgrade-a-couple-of-warnings-to-debug.patch 2024-04-26 01:34:02.0 +0100
+++ systemd-252.25/debian/patches/debian/Downgrade-a-couple-of-warnings-to-debug.patch 2024-05-09 18:10:47.0 +0100
@@ -16,10 +16,10 @@
3 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/src/core/load-fragment.c b/src/core/load-fragment.c
-index 5f4d4b0..cf5e55f 100644
+index 11166f9..b049507 100644
--- a/src/core/load-fragment.c
+++ b/src/core/load-fragment.c
-@@ -543,6 +543,7 @@ static int patch_var_run(
+@@ -578,6 +578,7 @@ static int patch_var_run(
const char *e;
char *z;
@@ -27,7 +27,7 @@
e = path_startswith(*path, "/var/run/");
if (!e)
-@@ -552,7 +553,8 @@ static int patch_var_run(
+@@ -587,7 +588,8 @@ static int patch_var_run(
if (!z)
return log_oom();
@@ -51,10 +51,10 @@
"Please update package to include a native systemd unit file, in order to make it more safe and robust.", fpath);
diff --git a/src/tmpfiles/tmpfiles.c b/src/tmpfiles/tmpfiles.c
-index 281284c..8952a26 100644
+index a186246..83f3e5c 100644
--- a/src/tmpfiles/tmpfiles.c
+++ b/src/tmpfiles/tmpfiles.c
-@@ -2991,6 +2991,7 @@ static int specifier_expansion_from_arg(const Specifier *specifier_table, Item *
+@@ -2992,6 +2992,7 @@ static int specifier_expansion_from_arg(const Specifier *specifier_table, Item *
static int patch_var_run(const char *fname, unsigned li
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#1070704: More info
On Wed, 8 May 2024 12:00:34 +0200 Roderich Schupp wrote: > I just saw that the missing libkmod (dlopen'ed by udevadm) is already taken > care of by /usr/share/initramfs-tools/hooks/udev. > > In case you're wondering what caused libsystemd.so.0 to be included > in my initrd-img: it's linked by /usr/sbin/lvm which gets added by > /usr/share/initramfs-tools/hooks/lvm2 > > Cheers, Roderich Again, what was the issue exactly? kmod is already taken care of, that leaves gcrypt or lz4 which are only used for the journal, why would the abscence of those cause issues for cryptsetup? What was the actual error and what actually fixed it, precisely? -- Kind regards, Luca Boccassi
Bug#1070724: tmux: take flock on socket file/dir in /tmp/
On Wed, 8 May 2024 at 10:45, Luca Boccassi wrote: > > On Wed, 8 May 2024 at 08:20, Romain Francoise wrote: > > > > Hi Luca, > > > > Thanks for the heads up! Appreciate it. > > > > On Wed, May 8, 2024 at 1:33 AM Luca Boccassi wrote: > > > In order to avoid the /tmp/tmux-UID/default socket being deleted while > > > in use (e.g.: long term session), please patch tmux to take a flock(2) > > > on the directory while it's running, as per documentation: > > > > > > https://www.freedesktop.org/software/systemd/man/latest/tmpfiles.d.html#Age > > > > I'd rather ship a tmpfiles config snippet with an 'x' directive to > > skip the tmux directories. > > Will that continue to work? > > Yes. Please ship it under /usr/lib/tmpfiles.d, and give it a clear > prefix that identifies the package (eg: tmux-something.conf). Also > please understand that any user can define any cleanup rule they want > locally, and they will override what packages ship (this is by > design), so the flock solution would be safer. But it is up to you > what you choose of course. Also note that you can start shipping this drop-in immediately, no need to wait or coordinate
Bug#1070724: tmux: take flock on socket file/dir in /tmp/
On Wed, 8 May 2024 at 08:20, Romain Francoise wrote: > > Hi Luca, > > Thanks for the heads up! Appreciate it. > > On Wed, May 8, 2024 at 1:33 AM Luca Boccassi wrote: > > In order to avoid the /tmp/tmux-UID/default socket being deleted while > > in use (e.g.: long term session), please patch tmux to take a flock(2) > > on the directory while it's running, as per documentation: > > > > https://www.freedesktop.org/software/systemd/man/latest/tmpfiles.d.html#Age > > I'd rather ship a tmpfiles config snippet with an 'x' directive to > skip the tmux directories. > Will that continue to work? Yes. Please ship it under /usr/lib/tmpfiles.d, and give it a clear prefix that identifies the package (eg: tmux-something.conf). Also please understand that any user can define any cleanup rule they want locally, and they will override what packages ship (this is by design), so the flock solution would be safer. But it is up to you what you choose of course. > > Aside from this, it would be better to switch the location to > > XDG_RUNTIME_DIR (/run/user/UID), as a predictable name such as the one > > used by tmux can be easily hijacked by anything that manages to run > > before tmux is started, given /tmp is world writable by default. screen > > already switched some time ago to /run/. > > That's not something that I feel would be appropriate as a > Debian-specific change, but I can discuss it with the upstream author. > Not much chance of it happening though. Yes understood, that is something appropriate to do upstream and not downstream, I agree. I'd suggest to mention 'screen' as a factual example for this pattern, it might help.
Bug#1070725: ssh-agent: take flock on socket file/dir in /tmp
Package: openssh-client Severity: important Hi, The default tmpfiles.d/tmp.conf will soon start cleaning up /tmp/ once a day, automatically deleting files older than 10 days (ctime/mtime/atime are all taken into account). In order to avoid the ssh auth socket in /tmp being deleted while in use (e.g.: long term session), please patch ssh-agent to take a flock(2) on the /tmp/ssh-xxx directory while it's running, as per documentation: https://www.freedesktop.org/software/systemd/man/latest/tmpfiles.d.html#Age Aside from this, it would be better to switch the location to XDG_RUNTIME_DIR (/run/user/UID), as that's more appropriate for per- user-session ephemeral state. The ssh agent provided by gnupg already switched some time ago: SSH_AUTH_SOCK=/run/user/1000/gnupg/S.gpg-agent.ssh -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1070724: tmux: take flock on socket file/dir in /tmp/
Package: tmux Severity: important Hi, The default tmpfiles.d/tmp.conf will soon start cleaning up /tmp/ once a day, automatically deleting files older than 10 days (ctime/mtime/atime are all taken into account). In order to avoid the /tmp/tmux-UID/default socket being deleted while in use (e.g.: long term session), please patch tmux to take a flock(2) on the directory while it's running, as per documentation: https://www.freedesktop.org/software/systemd/man/latest/tmpfiles.d.html#Age Aside from this, it would be better to switch the location to XDG_RUNTIME_DIR (/run/user/UID), as a predictable name such as the one used by tmux can be easily hijacked by anything that manages to run before tmux is started, given /tmp is world writable by default. screen already switched some time ago to /run/. Thanks! -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1070704: Can't decrypt root device after upgrading to systemd v256 and rebuilding initramfs
Control: tags -1 moreinfo On Tue, 07 May 2024 16:14:30 +0200 Roderich Schupp wrote: > Package: systemd > Version: 256~rc1-1~exp2 > Severity: important > X-Debbugs-Cc: roderich.sch...@gmail.com > > I have a standard LUKS-encrypted root partition. > I upgraded systemd to v256 and ran update-initramfs. > I rebooted into the kernel with the updated initramfs, > but plymouth (instead of prompting for the password) now hangs and > just shows "cryptsetup: Waiting for encrypted source device > UUID=a75ad289-6ad8-4ac3-aebc-34a94cff72e4" > > I was able to boot into an older kernel with its initramfs built with the > previous version of systemd (255.5-1) and the diffed the two initrd.img. > Turns out that the initramfs built for v256 was missing some shared libraries > (see below for a list). For v255 these where linked by libsystemd.so.0 > or udevadm, but in v256 these libs are dlopen'ed, hence update- initramfs > doesn't detect them. > > As a workaround I dropped the following into > /etc/initramfs-tools/hooks/add-libs-for-systemd and reran update- initramfs: > > --- > #!/bin/sh > > set -e > > case "$1" in > prereqs) > exit 0 > ;; > esac > > . /usr/share/initramfs-tools/hook-functions > > copy_exec /usr/lib/x86_64-linux-gnu/libgcrypt.so.20 > copy_exec /usr/lib/x86_64-linux-gnu/libgpg-error.so.0 > copy_exec /usr/lib/x86_64-linux-gnu/libkmod.so.2 > copy_exec /usr/lib/x86_64-linux-gnu/liblz4.so.1 Which one of those libraries actually did make the difference, and what was the error message? -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1053678: partman-crypto: Requires separate /boot partition, even if not required
On Tue, 7 May 2024 at 00:18, Cyril Brulebois wrote: > > Luca Boccassi (2024-05-06): > > Pending at: > > https://salsa.debian.org/installer-team/partman-crypto/-/merge_requests/8 > > I'm not sure how often we change template types, but I suppose this > particular instance (error → boolean) makes sense and isn't problematic. > > Please mention “GRUB” (instead of “grub”) for consistency with upstream > and the rest of d-i though. (I know this is very minor but better catch > that early to avoid another l10n round later on.) Sure, fixed, thanks
Bug#1053678: partman-crypto: Requires separate /boot partition, even if not required
Control: tags -1 patch On Sun, 08 Oct 2023 17:57:01 -0400 Nicholas D Steeves wrote: > Jonathan Hettwer writes: > > > Package: partman-crypto > > Version: 121 > > Severity: normal > > Tags: d-i > > X-Debbugs-Cc: j24...@gmail.com > > > > Dear Maintainer, > > > > The `crypto_check_mountpoints` script prevents you from setting up an > > encrypted root filesystem without an additional unencrypted /boot > > filesystem. > > While this may be a requirement for e.g. grub2, it is not > > necessarily required when not using grub2 but using UKIs to build EFI > > executables that can directly mount the encrypted root filesystem. > > While UKIs aren't currently supported, I would still expect partman-crypto > > to let me partition an encrypted root filesystem without separate /boot > > filesystem, at least after having ignored the warnings or in combination > > with the `nobootloader` udeb. > > Quick note: systemd-boot works with kernel images + initramfs, without > UKI. After the systemd-boot menu, the user is prompted for the master > LUKS password, as usual, and I use the derived key script to then > unlocks a couple LUKS volumes. No LVM, no /boot. It seems to work > well, but yeah, it's not possible to do this with fresh install (I > manually migrated an old installation to new hardware). Pending at: https://salsa.debian.org/installer-team/partman-crypto/-/merge_requests/8 Test iso built by CI can be found here: https://salsa.debian.org/bluca/partman-crypto/-/jobs/5694502/artifacts/browse/debian/output/ Any help testing would be welcome -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1070473: debhelper: Run dh_installsysusers after dh_installtmpfiles
On Mon, 6 May 2024 at 12:41, Jeremy Bícha wrote: > > On Mon, May 6, 2024 at 7:33 AM Luca Boccassi wrote: > > Am I reading this correctly, that the package is using tmpfiles to > > create a home directory? I'm not sure that was foreseen as a use case > > to be honest, I'd bring it upstream > > Yes. Should I bring the issue upstream to systemd or upstream to > gnome-remote-desktop? Actually the manpage of sysusers.d suggests to do this: systemd-sysusers only sets the home directory record in the user database. To actually create the directory, consider adding a corresponding tmpfiles.d(5) fragment. So please open an issue upstream in the systemd repo with the reproducer for the race condition, as it sounds something that at least should be documented explicitly how to handle, at a minimum
Bug#1070473: debhelper: Run dh_installsysusers after dh_installtmpfiles
On Mon, 6 May 2024 at 12:27, Jeremy Bícha wrote: > > On Mon, May 6, 2024 at 2:06 AM Niels Thykier wrote: > > > > Jeremy Bícha: > > > Source: debhelper > > > Version: 13.15.3 > > > Control: affects -1 src:gnome-remote-desktop > > > X-Debbugs: syst...@packages.debian.org > > > > > > gnome-remote-desktop 46 upstream has decided to implement both > > > tmpfiles.d and sysusers.d to create a system user and its home > > > directory. systemd-tmpfiles needs to run before systemd-sysusers. If > > > not, on a new install, this command hangs for about 90 seconds: > > > > > > Creating user 'gnome-remote-desktop' (GNOME Remote Desktop) with UID > > > *** and GID ***. > > > > > > Then this error: > > > Could not execute systemctl: at /usr/bin/deb-systemd-invoke line 148. > > > > > > Then the installation completes successfully. > > > > > > Therefore, I recommend that debhelper automatically runs > > > dh_installtmpfiles before running dh_installsysusers in case any other > > > projects want to do what gnome-remote-desktop does. > > > > > > I was able to workaround this issue: > > > https://salsa.debian.org/gnome-team/gnome-remote-desktop/-/commit/8490919 > > > > > > Thank you, > > > Jeremy Bícha > > > > > > > Hi Michael and Luca > > > > What is the correct order for tmpfiles vs. sysusers? > > > > I thought the order was sysusers (to create the user) and then tmpfiles > > (to create files/directories and set ownership accordingly). In this bug > > report, the request is to have the directories first before the user is > > created. > > > > Could you please assert what the correct order is for the default case? > > There is a circular dependency here. > > $ cat /usr/lib/tmpfiles.d/gnome-remote-desktop-tmpfiles.conf > # tmpfiles.d file to ensure the existence of the home directory for > gnome-remote-desktop user > d /var/lib/gnome-remote-desktop 0700 gnome-remote-desktop gnome-remote-desktop > d /etc/gnome-remote-desktop 0755 gnome-remote-desktop gnome-remote-desktop > > $ cat /usr/lib/sysusers.d/gnome-remote-desktop-sysusers.conf > # sysusers.d file to ensure the existence of the gnome-remote-desktop user > u gnome-remote-desktop - "GNOME Remote Desktop" /var/lib/gnome-remote-desktop > > The 90 second hang if systemd-sysusers is run before > /var/lib/gnome-remote-desktop exists is annoying, but systemd-tmpfiles > errors if the gnome-remote-desktop user doesn't exist yet. > > Running tmpfiles, then sysusers, then tmpfiles again works except for > that 90 second hang. > > I had to remove the gnome-remote-desktop package, then remove the > gnome-remote-desktop user and the directories and then reboot to test > changes properly. > > Thank you, > Jeremy Bícha Am I reading this correctly, that the package is using tmpfiles to create a home directory? I'm not sure that was foreseen as a use case to be honest, I'd bring it upstream
Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]
On Mon, 6 May 2024 at 11:48, Michael Biebl wrote: > > Am 06.05.24 um 12:18 schrieb Luca Boccassi: > > Defaults are defaults, they are trivially and fully overridable where > > needed if needed. Especially container and VM managers these days can > > super trivially override them via SMBIOS Type11 strings or > > Credentials, ephemerally and without changing the guest image at all. > > > Aligning defaults across distros does have value. > That said, a distro like Debian has a larger scope than say a desktop > oriented one like Fedora. > Debian is used on a broad spectrum of systems: from embedded to server > to cloud to desktop. > So I think it is valuable to gather feedback from all affected parties > to make an informed decision. > > What upstream is doing should not be the only driving factor. It's impossible to have defaults that make everyone happy, there will always be someone who doesn't like any choice one might pick (there are people unhappy with the current ones too). Hence, I am not really looking for philosophical discussions or lists of personal preferences or hypotheticals, but for facts: what would break where, and how to fix it? I only found autopkgtest so far, which uses /tmp/ in the guest and expects it to survive across reboots, and I have a MR up already for that. Anything else?
Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]
On Mon, 6 May 2024 at 09:40, Michael Biebl wrote: > > We have two separate issues here: > > a/ /tmp-on-tmpfs > b/ time based clean-up of /tmp and /var/tmp > > I think it makes sense to discuss/handle those separately. > > Regarding a/: > tmp.mount as shipped by systemd uses the following mount options: > "mode=1777,strictatime,nosuid,nodev,size=50%" > > In the past there were concerns that those 50% of available RAM wasn't a > one-size-fits-all solution, especially for (LXC) containers and VMs > > One also needs to keep in mind that debian-installer still offers a > partitioning setup with /tmp on a separate partition. This will be > created via an entry in /etc/fstab. Such a /tmp entry in /etc/fstab will > override tmp.mount. > > If we go with a/, then I think d-i should be updated to no longer create > /tmp as a separate partition. > > > Regarding b/: > The current setup as used in Debian is to only clean /tmp on boot (which > is pointless with /tmp-on-tmpfs) and never clean up /var/tmp > > The tmpfiles rule tmp.conf as shipped by systemd upstream contains: > > q /tmp 1777 root root 10d > q /var/tmp 1777 root root 30d > > Files that are older then 10 days or 30 days are automatically cleaned > up. The age of the files are determined as such: > > "The age of a file system entry is determined from its last modification > timestamp (mtime), its last access timestamp (atime), and (except for > directories) its last status change timestamp (ctime). By default, any > of these three (or two) values will prevent cleanup if it is more recent > than the current time minus the age field." > > I'm not sure if we have software on long running servers which place > files in /tmp and /var/tmp and expect files to not be deleted during > runtime, even if not accessed for a long time. This is certainly an > issue to be aware of and keep an eye on. Defaults are defaults, they are trivially and fully overridable where needed if needed. Especially container and VM managers these days can super trivially override them via SMBIOS Type11 strings or Credentials, ephemerally and without changing the guest image at all.
Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]
On Mon, 6 May 2024 at 06:36, Paul Gevers wrote: > > Hi Luca, > > On 05-05-2024 10:04 p.m., Luca Boccassi wrote: > > > Hence, I intend to apply these changes in the next src:systemd upload > > to unstable, probably next week. > > > In case anybody is aware of packages/programs needing an update to cope > > with these changes, or any other issue, please let me know and I will > > file bugs. > > You filed MR341 against autopkgtest, thanks for that. Can you please > hold off a bit longer than only one week to get the infrastructure > updated? I'm confident that every test that has the needs-reboot > restriction will start failing (which are only 21 tests according to > codesearch). However, I fear that every test is at risk under common > circumstances. > > I don't want to be rushed into an autopkgtest update and an > infrastructure update for something that we can plan (there's always > risk involved and I want to have the time and peace to cope with the > process). Having said that, maybe we will be ready next week. Sure, no problem. That MR fixes autopkgtest for my local runs, let me know if something else is needed.
Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]
On Sun, 5 May 2024 at 22:22, Salvo Tomaselli wrote: > > > In case anybody is aware of packages/programs needing an update to cope > > with these changes, or any other issue, please let me know and I will > > file bugs. > > in localslackirc@.service > > ReadWritePaths=/var/tmp > > It uses /var/tmp because it needs a directory with 1777 permissions that is > permanent, to keep some status. > > The user it ends up using is configured by a seting, and is intended to be a > non-system user (and could be different users for the various instances). > > I guess the solution would be to create such a directory when installing, in / > var/lib/localslackirc instead of using /var/tmp and have the purge script > remove it. Services can use StateDirectory= and StateDirectoryMode= which should provide the same functionality, and is more appropriate for persistent state. /tmp/ and /var/tmp/ are meant to be scratch areas, rather than state storage.
Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]
On Tue, 5 Jul 2022 19:42:37 +0200 Michael Biebl wrote: > > Hi Eric > > On Fri, 31 Jul 2020 15:12:48 + Eric Desrochers > wrote: > > Package: systemd > > Version: 245.7-1 > > Severity: normal > > > > Dear Maintainer, > > > > Debian systemd implementation does not clean > > /var/tmp by default. > > > > * quilt patch: > > d/p/debian/Bring-tmpfiles.d-tmp.conf-in-line-with-Debian- defaul.patch > > > > * systemd-245.7/tmpfiles.d/tmp.conf: > > #q /var/tmp 1777 root root 30d > > > > The patch exist in Debian since 2012. > > > > The topic has been discussed and a few suggestion has been put on the > > table in the following Ubuntu bug: https://launchpad.net/bugs/1870585 > > > > I fill this bug today to start a conversation. > > I haven't received any further input from your side. > Are you still interested in this issue or not? > I wonder where to go from here and what to do about this bug report. I think it's been long enough, and for Trixie we should bring the defaults in line with upstream and other distributions, which means: - /tmp/ is a tmpfs - /var/tmp/ is cleaned up on a timer Hence, I intend to apply these changes in the next src:systemd upload to unstable, probably next week. This will be mentioned in NEWS (and I guess in the release notes when the time comes), together with the instructions to override for anybody wanting to keep the old behaviour, which is as trivial as: systemctl mask tmp.mount (or touch /etc/systemd/system/tmp.mount) touch /etc/tmpfiles.d/tmp.conf for the former and the latter respectively. In case anybody is aware of packages/programs needing an update to cope with these changes, or any other issue, please let me know and I will file bugs. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1004863: Bootstrapping a Fedora produces a system with an empty package database
On Mon, 22 Apr 2024 15:38:00 +0100 Luca Boccassi wrote: > On Sat, 20 Apr 2024 20:48:06 +0100 Luca Boccassi > wrote: > > On Mon, 15 Apr 2024 at 10:34, Peter Pentchev > wrote: > > > > > > On Sun, Apr 14, 2024 at 07:39:54PM +0100, Luca Boccassi wrote: > > > > > Le 2/13/22 à 09:00, Mihai Moldovan a écrit : > > > > > > > > > > > I'm pretty sure that we can, at some point in the future, > drop the > > > > > offending > > > > > > patch from the RPM package and all of this will be redundant. > It > > > > > just requires a > > > > > > bit of work to make sure that older use cases (mostly alien) > don't > > > > > break due to > > > > > > this, which might require a bit of development on RPM itself. > It's > > > > > on my TODO > > > > > > list for very rainy and boring days, but unfortunately > there's > > > > > almost always a > > > > > > truckload of other things to do, so I keep dragging it out. > > > > > > > > > > > > > > > > > > > > > > > > Mihai > > > > > > > > > > > > > > > > I fully agree on removing the RPM patch that causes all of our > issues > > > > > on packages depending on it. If needed, I'm willing to be part > of > > > > > reviewing what would be the impact of returning to a standard > RPM > > > > > package on Debian and to help into solving those issues. Don't > > > > > hesitate to ping me for that. > > > > > > > > I think the time has come to drop the RPM Debian-specific patches > and > > > > avoid these workarounds altogether. > > > > > > > > Once upon a time it made sense to redirect the RPM DB, and to go > out of > > > > our way to stop users installing RPMs locally, when RPMs were > popular > > > > as a way to distribute upstream applications. > > > > > > > > Nowadays, the most common way to distribute upstream apps is via > > > > Flatpak/Appimage/etc, or (thanks to Ubuntu's popularity) via deb > > > > repositories, so the chances someone tries to 'sudo rpm -i > foo.rpm' are > > > > very low. > > > > > > > > The main use of having rpm/dnf/zypper in Debian is not to convert > RPMs > > > > with Alien or so, but it's to be able to do cross-distribution > > > > bootstraps and image building using native tools, like we do in > mkosi > This is now in experimental, unless I hear something I'll upload to > unstable during the weekend. Uploaded to unstable. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1060422: partman-crypto: add support for new cryptsetup options for opal/sed
Control: tags -1 pending On Thu, 11 Jan 2024 19:55:18 + Luca Boccassi wrote: > On Thu, 11 Jan 2024 at 14:22, Holger Levsen wrote: > > > > On Thu, Jan 11, 2024 at 11:56:28AM +, Luca Boccassi wrote: > > [...] > > > How about if I changed the Description from: > > > Self-encrypting disk (opal with LUKS2) > > > to something like: > > > Firmware-backed self-encrypting disk (vendor-implemented OPAL with > > > LUKS2) > > > Would that suffice? If not, do you have an alternative wording in mind? > > > > sounds much better (and sufficient, for all the reasons you mentioned) > > to me, thanks! > > Thank you for the feedback, MR on Salsa is updated as described. Now that cryptsetup 2.7.0 is in testing, I'll team upload later tonight -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1070114: libbpf: CO-RE program build fails with gcc-bpf due to outdated headers
Package: libbpf Version: 1.1.0-1 The current version of libbpf is incompatible with gcc-bpf, as it's missing some changes that were added later to the implementation of bpf_core_type_id_kernel() as explained at: https://github.com/systemd/systemd/issues/31869#issuecomment-2083487648 More precisely, the fix is in this upstream commit: https://github.com/libbpf/libbpf/commit/b19fdbf1be21a28f88740375a575ebd9dfbea68f Which was part of the 1.4.0 release of last month, so packaging the latest release is enough to fix this issue, so please consider doing so at your earliest convenience. Thank you. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1069994: systemd-resolved: resolvectl dnssec failed for unsigned domains
On Sun, 28 Apr 2024 11:53:17 +0200 Adrien CLERC wrote: > Package: systemd-resolved > Version: 255.5-1 > Severity: important > > Dear Maintainer, > > Since 255.5-1, resolvectl produces the following: > > ❯ resolvectl query --validate=yes www.youtube.com > www.youtube.com: resolve call failed: DNSSEC validation failed: no- signature > > The domain is unsigned. It worked in 255.4-1+b1, but I'm unable to rollback, > since it depends on libsystemd which makes a lot of package unhappy with > dependencies. > > Did I miss something? > In the meantime, I'll use "DNSSEC=no", but that's not a definitive answer. > > Have a nice day, > Adrien > There are no resolved patches downstream, report this upstream -- Kind regards, Luca Boccassi
Bug#1068017: Y2038-safe replacements for utmp/wtmp and lastlog
On Fri, 26 Apr 2024 at 12:30, Chris Hofstaedtler wrote: > > Fellow Developers, > > you are probably aware of the time_t-64bit migration :-) > However, this does not magically transition all data formats to 64bit > times. One such instance is the set of utmp/wtmp and lastlog files. > > Thorsten Kukuk and others have been working on replacements for the > existing file formats and interfaces [1]; these are called wtmpdb > and lastlog2. > > Some parties have requested that we do something in Debian [2]. If > we use Thorsten's work (and why not?), this likely means introducing > new packages into the Priority: standard set, and changes to a few > other packages, esp. those that handle user sessions. > > Thorsten's code introduces new PAM modules to manage the new files, > so it should transparently work with most packages. Later, the > old interfaces can probably be turned off. This seems like a good > idea as a migration strategy to me. > A bonus seems to be that installs not wanting these features can > remove them - whereas today they are baked into everything. > > > On the wiki [0] I have summarized what I know; a list of initial > work items; and some open questions mostly concerned with upgrading. > > I invite you to read the wiki page and the background info, to > identify gaps, to provide insights on feasability and further > related comments. > I'm hoping that we can build consensus on this plan. > > Please keep #1068017 in CC: when discussing substantial matters > about this plan but drop it for only vaguely related sub-threads. > > Chris > > > [0] https://wiki.debian.org/pam_lastlog2%20and%20wtmpdb > [1] https://www.thkukuk.de/blog/Y2038_glibc_lastlog_64bit/ > [2] https://bugs.debian.org/1068017 Would be nice to drop things that are not used, but otherwise, option A looks good and broadly similar to what other distros are doing, so should be pretty safe. Thanks for taking care of this.
Bug#1069706: systemd unit files lack ordering wrt nss-user-lookup.target
On Thu, 25 Apr 2024 at 07:58, Rasmus Villemoes wrote: > > On 23/04/2024 13.23, Colin Watson wrote: > > On Tue, Apr 23, 2024 at 09:32:00AM +0200, Rasmus Villemoes wrote: > >> According to systemd.special(7) > >> > >> nss-user-lookup.target > >> > >> A target that should be used as synchronization point for all > >> regular UNIX user/group name service lookups. [...] All > >> services for which the availability of the full user/group > >> database is essential should be ordered after this target, but > >> not pull it in. All services which provide parts of the > >> user/group database should be ordered before this target, and > >> pull it in. > >> > >> I have a custom .service that does exactly as described in the second > >> part, i.e. provides part of the user/group database and says > >> Before=nss-user-lookup.target, Wants=nss-user-lookup.target > >> (concretely, it modifies /etc/shadow to update a default password, but > >> that's not really important). I believe sshd definitely belongs in the > >> former category, i.e. sshd should not be started until any such > >> service that updates the user/group database, such as updating > >> /etc/shadow, have run. > >> > >> Hence the ssh.service and ssh.socket files should add > >> > >> After=nss-user-lookup.target > >> > >> in their [Unit] sections. This is a no-op on systems that do not have > >> any service pulling in that target, but required for correctness on > >> systems that do. > >> > >> Of course, I could, and currently do, handle this via a drop-in config > >> fragment in some ssh.service.d/ directory. But this, and other similar > >> synchronization targets, exist so that one does not necessarily need > >> to know about every other service running on the system. > > > > This sounds like a reasonable proposal to me. I'm just CCing Debian's > > systemd maintainers for a quick review to make sure I'm not missing > > anything subtle. > > > > Thanks. > > I was a bit worried about not adding the After= to the socket, as I > assumed that when the sshd@foobar.service would be started "manually" > (i.e. activated by the socket unit), it would not form part of the whole > initial transaction and hence the sshd@.service's own After= > relationship would not be honored. > > But testing shows I was wrong, and indeed one can establish a connection > to port 22, but the sshd@foobar.service is then marked as waiting until > the appropriate target is reached. > > That said, I'm not sure there is that much value in enabling the socket > allowing connections to come in early, but it's not wrong wrt. > correctness. It's mostly a matter of what UX is better in case a > prerequisite for sshd takes a longish time to get up: not listening at > all on port 22, or accept connections but then just make it hang. The reason is to avoid connections failing because there's nothing open, and instead let them queue waiting for the service for a bit longer, which is better than retrying
Bug#1069787: debootstrap: autopkgtest fails since t64 migration
On Wed, 24 Apr 2024 19:16:51 +0100 Mark Hindley wrote: > Package: debootstrap > Version: 1.0.134 > Severity: important > Tags: patch > > > Dear Maintainer, > > The debian/tests/debian-testing autopkgtest has been broken on 64bit archs by > the t64 transition in trixie. Specifically the test includes gnupg as an > additional package. Gnupg depends on gpg-agent which depends on > libnpth0. However, in trixie, libnpth0 is now provided by libnpth0t64 which > debootstrap doesn't handle. > > I suggest changing the test to include gpgv which avoids the t64 transition > whilst providing similar functional coverage. > > Patch attached. Please send a merge request on Salsa -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1069706: systemd unit files lack ordering wrt nss-user-lookup.target
On Tue, 23 Apr 2024 12:23:21 +0100 Colin Watson wrote: > On Tue, Apr 23, 2024 at 09:32:00AM +0200, Rasmus Villemoes wrote: > > According to systemd.special(7) > > > > nss-user-lookup.target > > > > A target that should be used as synchronization point for all > > regular UNIX user/group name service lookups. [...] All > > services for which the availability of the full user/group > > database is essential should be ordered after this target, but > > not pull it in. All services which provide parts of the > > user/group database should be ordered before this target, and > > pull it in. > > > > I have a custom .service that does exactly as described in the second > > part, i.e. provides part of the user/group database and says > > Before=nss-user-lookup.target, Wants=nss-user-lookup.target > > (concretely, it modifies /etc/shadow to update a default password, but > > that's not really important). I believe sshd definitely belongs in the > > former category, i.e. sshd should not be started until any such > > service that updates the user/group database, such as updating > > /etc/shadow, have run. > > > > Hence the ssh.service and ssh.socket files should add > > > > After=nss-user-lookup.target > > > > in their [Unit] sections. This is a no-op on systems that do not have > > any service pulling in that target, but required for correctness on > > systems that do. > > > > Of course, I could, and currently do, handle this via a drop-in config > > fragment in some ssh.service.d/ directory. But this, and other similar > > synchronization targets, exist so that one does not necessarily need > > to know about every other service running on the system. > > This sounds like a reasonable proposal to me. I'm just CCing Debian's > systemd maintainers for a quick review to make sure I'm not missing > anything subtle. That sounds fine - maybe the service, but not the socket, so that connections can start to come in early. I also note there's accountsservice pulling that target in but it shouldn't, but that's a separate matter and can be handled upstream. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1069700: transition: rpm
Package: release.debian.org Control: affects -1 + src:rpm X-Debbugs-Cc: team+pkg-...@tracker.debian.org User: release.debian@packages.debian.org Usertags: transition Severity: normal Dear Release Team, A new RPM version is available and has been uploaded and accepted in experimental as version 4.19.1.1+dfsg-1~exp, and it introduces an ABI bump from soname version 9 to 10 for the library packages shipped from src:rpm. The reverse-build-depends on librpm-dev are: createrepo-c freeipa libdnf libdrpm libextractor libguestfs libmodulemd libsolv libzypp openscap zypper I have build-tested them all on amd64, only libdrpm needs changes but there's a new version that I just uploaded that works with both, so only binNMUs will be needed. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1004863: Bootstrapping a Fedora produces a system with an empty package database
On Sat, 20 Apr 2024 20:48:06 +0100 Luca Boccassi wrote: > On Mon, 15 Apr 2024 at 10:34, Peter Pentchev wrote: > > > > On Sun, Apr 14, 2024 at 07:39:54PM +0100, Luca Boccassi wrote: > > > > Le 2/13/22 à 09:00, Mihai Moldovan a écrit : > > > > > > > > > I'm pretty sure that we can, at some point in the future, drop the > > > > offending > > > > > patch from the RPM package and all of this will be redundant. It > > > > just requires a > > > > > bit of work to make sure that older use cases (mostly alien) don't > > > > break due to > > > > > this, which might require a bit of development on RPM itself. It's > > > > on my TODO > > > > > list for very rainy and boring days, but unfortunately there's > > > > almost always a > > > > > truckload of other things to do, so I keep dragging it out. > > > > > > > > > > > > > > > > > > > > Mihai > > > > > > > > > > > > > I fully agree on removing the RPM patch that causes all of our issues > > > > on packages depending on it. If needed, I'm willing to be part of > > > > reviewing what would be the impact of returning to a standard RPM > > > > package on Debian and to help into solving those issues. Don't > > > > hesitate to ping me for that. > > > > > > I think the time has come to drop the RPM Debian-specific patches and > > > avoid these workarounds altogether. > > > > > > Once upon a time it made sense to redirect the RPM DB, and to go out of > > > our way to stop users installing RPMs locally, when RPMs were popular > > > as a way to distribute upstream applications. > > > > > > Nowadays, the most common way to distribute upstream apps is via > > > Flatpak/Appimage/etc, or (thanks to Ubuntu's popularity) via deb > > > repositories, so the chances someone tries to 'sudo rpm -i foo.rpm' are > > > very low. > > > > > > The main use of having rpm/dnf/zypper in Debian is not to convert RPMs > > > with Alien or so, but it's to be able to do cross-distribution > > > bootstraps and image building using native tools, like we do in mkosi > > > (and in other tools as well). > > > > > > So these patches to print warnings and divert the database and so on > > > are a hindrance. > > > > > > Hence, for Trixie I think we should just drop them all. > > > > > > It should also make it easier to maintain the RPM stack, which has > > > languished. We are trying to move everything under the RPM Team Salsa > > > org, which should also help. > > > > > > If there are any objections please speak up. > > > > I've thought about making this change at least once a year, but > > I have always been, hm, should I say "too careful" (when of course > > I actually mean "too scared")... so if you feel the time has come, > > yeah, go ahead! This is now in experimental, unless I hear something I'll upload to unstable during the weekend. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1004863: Bootstrapping a Fedora produces a system with an empty package database
On Mon, 15 Apr 2024 at 10:34, Peter Pentchev wrote: > > On Sun, Apr 14, 2024 at 07:39:54PM +0100, Luca Boccassi wrote: > > > Le 2/13/22 à 09:00, Mihai Moldovan a écrit : > > > > > > > I'm pretty sure that we can, at some point in the future, drop the > > > offending > > > > patch from the RPM package and all of this will be redundant. It > > > just requires a > > > > bit of work to make sure that older use cases (mostly alien) don't > > > break due to > > > > this, which might require a bit of development on RPM itself. It's > > > on my TODO > > > > list for very rainy and boring days, but unfortunately there's > > > almost always a > > > > truckload of other things to do, so I keep dragging it out. > > > > > > > > > > > > > > > > Mihai > > > > > > > > > > I fully agree on removing the RPM patch that causes all of our issues > > > on packages depending on it. If needed, I'm willing to be part of > > > reviewing what would be the impact of returning to a standard RPM > > > package on Debian and to help into solving those issues. Don't > > > hesitate to ping me for that. > > > > I think the time has come to drop the RPM Debian-specific patches and > > avoid these workarounds altogether. > > > > Once upon a time it made sense to redirect the RPM DB, and to go out of > > our way to stop users installing RPMs locally, when RPMs were popular > > as a way to distribute upstream applications. > > > > Nowadays, the most common way to distribute upstream apps is via > > Flatpak/Appimage/etc, or (thanks to Ubuntu's popularity) via deb > > repositories, so the chances someone tries to 'sudo rpm -i foo.rpm' are > > very low. > > > > The main use of having rpm/dnf/zypper in Debian is not to convert RPMs > > with Alien or so, but it's to be able to do cross-distribution > > bootstraps and image building using native tools, like we do in mkosi > > (and in other tools as well). > > > > So these patches to print warnings and divert the database and so on > > are a hindrance. > > > > Hence, for Trixie I think we should just drop them all. > > > > It should also make it easier to maintain the RPM stack, which has > > languished. We are trying to move everything under the RPM Team Salsa > > org, which should also help. > > > > If there are any objections please speak up. > > I've thought about making this change at least once a year, but > I have always been, hm, should I say "too careful" (when of course > I actually mean "too scared")... so if you feel the time has come, > yeah, go ahead! > > G'luck, > Peter If there are no objections, I will do this next weekend.
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#1069159: systemd-timesyncd: Getting TAI time?
Control: tags -1 upstream Control: close -1 On Wed, 17 Apr 2024 10:30:06 +0200 Christophe Lohr wrote: > Package: systemd-timesyncd > Version: 255.4-1 > Severity: normal > X-Debbugs-Cc: christophe.l...@cegetel.net > > Dear Maintainer, > by default, timesyncd does not seem to provide TAI time to the system > (see https://www.bortzmeyer.org/tai-on-debian.html) > > Is there something to do for that? > > Best regards Please file requests for new features directly upstream https://github.com/systemd/systemd/issues/new?assignees==RFE+%F0%9F%8E%81==feature_request.yml -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1039260: mactelnet: ships sysv-init script without systemd unit
The devices are all configured already by the time a normal service is started, so you can omit it entirely then On Sun, 14 Apr 2024 at 20:26, Håkon Nessjøen wrote: > > It needs the devices, but not for them to have ip yet. > > søn. 14. apr. 2024 kl. 21:25 skrev Luca Boccassi : >> >> If it doesn't need the network to be configured then you can avoid any >> dependency at all. >> >> On Sun, 14 Apr 2024 at 20:22, Håkon Nessjøen >> wrote: >> > >> > Thanks for your help, so far. Great to hear that you are willing to >> > sponsor it! >> > >> > I will change the dependencies of the service file as you said, but since >> > it in theory works before you have an IP address, so it shouldn't need to >> > wait for a DHCP client to finish before starting up, is it possible that >> > there are other dependencies I should target? Or does it still give most >> > sense to use the dependencies you mentioned? I don't have very much >> > experience with the order of things in the systemd startup process. >> > >> > I will request an account for Salsa in the meantime. >> > >> > On Sun, 14 Apr 2024 at 21:06, Luca Boccassi wrote: >> >> >> >> Requires=systemd-networkd.service >> >> After=systemd-networkd.service >> >> >> >> if you want to order it after the network is available, instead of >> >> those two lines you should use: >> >> >> >> Wants=network-online.target >> >> After=network-online.target >> >> >> >> so that it works with other network managers too. Also if >> >> mactelnet-locales only install locales, then it should be architecture >> >> "all" instead of "any". Also, consider requesting an account for Salsa >> >> and moving the repository there. >> >> >> >> If you fix these things and close the changelog I can sponsor the upload. >> >> >> >> On Sun, 14 Apr 2024 at 19:48, Håkon Nessjøen >> >> wrote: >> >> > >> >> > Hi, >> >> > >> >> > In relation to a new upstream version of mactelnet, I have updated the >> >> > debian packaging for this new version, which uses systemd service file >> >> > instead of the old sysv-init. I just need to find a sponsor, so that >> >> > the package can be updated. My last sponsor stopped being a DM for 6 >> >> > years ago I think. I'm not sure if it is ok to use this bug as a reason >> >> > for updating the module to a new minor version, not just a patch or >> >> > debian patch. As mactelnet has new functionality, supporting newer >> >> > devices/authentication protocol. >> >> > >> >> > Looking at RFS requests, they seem to either be about new packages, >> >> > adopted packages, or just security fixes. But this is a new upstream >> >> > version. How should I go forward with this? >> >> > >> >> > On Mon, 26 Jun 2023 at 00:26, wrote: >> >> >> >> >> >> Package: mactelnet >> >> >> Severity: important >> >> >> User: bl...@debian.org >> >> >> Usertags: missing-systemd-service >> >> >> >> >> >> Dear Maintainer(s), >> >> >> >> >> >> mactelnet has been flagged by Lintian as shipping a sysv-init script >> >> >> without a corresponding systemd unit file. The default init system in >> >> >> Debian is systemd, and so far this worked because a transitional >> >> >> sysv-init-to-unit generator was shipped by systemd. This is in the >> >> >> process of being deprecated and will be removed by the time Trixie >> >> >> ships, so the remaining packages that ship init scripts without >> >> >> systemd units will stop working. >> >> >> >> >> >> There are various advantages to using native units, for example the >> >> >> legacy generator cannot tell the different between a oneshot service >> >> >> and a long running daemon. Also, sanboxing and security features >> >> >> become available for services. For more information, consult the >> >> >> systemd documentation: >> >> >> https://www.freedesktop.org/software/systemd/man/systemd.unit.html >> >> >> >> >> >> You can find the Lintian warning here: >> >> >> >> >> >> https://lintian.debian.org/sources/mactelnet >> >> >> >> >> >> In case this is a false positive, please add a Lintian override to >> >> >> silence it and then close this bug. >> >> >> >> >> >> Thanks!
Bug#1039260: mactelnet: ships sysv-init script without systemd unit
If it doesn't need the network to be configured then you can avoid any dependency at all. On Sun, 14 Apr 2024 at 20:22, Håkon Nessjøen wrote: > > Thanks for your help, so far. Great to hear that you are willing to sponsor > it! > > I will change the dependencies of the service file as you said, but since it > in theory works before you have an IP address, so it shouldn't need to wait > for a DHCP client to finish before starting up, is it possible that there are > other dependencies I should target? Or does it still give most sense to use > the dependencies you mentioned? I don't have very much experience with the > order of things in the systemd startup process. > > I will request an account for Salsa in the meantime. > > On Sun, 14 Apr 2024 at 21:06, Luca Boccassi wrote: >> >> Requires=systemd-networkd.service >> After=systemd-networkd.service >> >> if you want to order it after the network is available, instead of >> those two lines you should use: >> >> Wants=network-online.target >> After=network-online.target >> >> so that it works with other network managers too. Also if >> mactelnet-locales only install locales, then it should be architecture >> "all" instead of "any". Also, consider requesting an account for Salsa >> and moving the repository there. >> >> If you fix these things and close the changelog I can sponsor the upload. >> >> On Sun, 14 Apr 2024 at 19:48, Håkon Nessjøen >> wrote: >> > >> > Hi, >> > >> > In relation to a new upstream version of mactelnet, I have updated the >> > debian packaging for this new version, which uses systemd service file >> > instead of the old sysv-init. I just need to find a sponsor, so that the >> > package can be updated. My last sponsor stopped being a DM for 6 years ago >> > I think. I'm not sure if it is ok to use this bug as a reason for updating >> > the module to a new minor version, not just a patch or debian patch. As >> > mactelnet has new functionality, supporting newer devices/authentication >> > protocol. >> > >> > Looking at RFS requests, they seem to either be about new packages, >> > adopted packages, or just security fixes. But this is a new upstream >> > version. How should I go forward with this? >> > >> > On Mon, 26 Jun 2023 at 00:26, wrote: >> >> >> >> Package: mactelnet >> >> Severity: important >> >> User: bl...@debian.org >> >> Usertags: missing-systemd-service >> >> >> >> Dear Maintainer(s), >> >> >> >> mactelnet has been flagged by Lintian as shipping a sysv-init script >> >> without a corresponding systemd unit file. The default init system in >> >> Debian is systemd, and so far this worked because a transitional >> >> sysv-init-to-unit generator was shipped by systemd. This is in the >> >> process of being deprecated and will be removed by the time Trixie >> >> ships, so the remaining packages that ship init scripts without >> >> systemd units will stop working. >> >> >> >> There are various advantages to using native units, for example the >> >> legacy generator cannot tell the different between a oneshot service >> >> and a long running daemon. Also, sanboxing and security features >> >> become available for services. For more information, consult the >> >> systemd documentation: >> >> https://www.freedesktop.org/software/systemd/man/systemd.unit.html >> >> >> >> You can find the Lintian warning here: >> >> >> >> https://lintian.debian.org/sources/mactelnet >> >> >> >> In case this is a false positive, please add a Lintian override to >> >> silence it and then close this bug. >> >> >> >> Thanks!
Bug#1039260: mactelnet: ships sysv-init script without systemd unit
Requires=systemd-networkd.service After=systemd-networkd.service if you want to order it after the network is available, instead of those two lines you should use: Wants=network-online.target After=network-online.target so that it works with other network managers too. Also if mactelnet-locales only install locales, then it should be architecture "all" instead of "any". Also, consider requesting an account for Salsa and moving the repository there. If you fix these things and close the changelog I can sponsor the upload. On Sun, 14 Apr 2024 at 19:48, Håkon Nessjøen wrote: > > Hi, > > In relation to a new upstream version of mactelnet, I have updated the debian > packaging for this new version, which uses systemd service file instead of > the old sysv-init. I just need to find a sponsor, so that the package can be > updated. My last sponsor stopped being a DM for 6 years ago I think. I'm not > sure if it is ok to use this bug as a reason for updating the module to a new > minor version, not just a patch or debian patch. As mactelnet has new > functionality, supporting newer devices/authentication protocol. > > Looking at RFS requests, they seem to either be about new packages, adopted > packages, or just security fixes. But this is a new upstream version. How > should I go forward with this? > > On Mon, 26 Jun 2023 at 00:26, wrote: >> >> Package: mactelnet >> Severity: important >> User: bl...@debian.org >> Usertags: missing-systemd-service >> >> Dear Maintainer(s), >> >> mactelnet has been flagged by Lintian as shipping a sysv-init script >> without a corresponding systemd unit file. The default init system in >> Debian is systemd, and so far this worked because a transitional >> sysv-init-to-unit generator was shipped by systemd. This is in the >> process of being deprecated and will be removed by the time Trixie >> ships, so the remaining packages that ship init scripts without >> systemd units will stop working. >> >> There are various advantages to using native units, for example the >> legacy generator cannot tell the different between a oneshot service >> and a long running daemon. Also, sanboxing and security features >> become available for services. For more information, consult the >> systemd documentation: >> https://www.freedesktop.org/software/systemd/man/systemd.unit.html >> >> You can find the Lintian warning here: >> >> https://lintian.debian.org/sources/mactelnet >> >> In case this is a false positive, please add a Lintian override to >> silence it and then close this bug. >> >> Thanks!
Bug#1004863: Bootstrapping a Fedora produces a system with an empty package database
> Le 2/13/22 à 09:00, Mihai Moldovan a écrit : > > > I'm pretty sure that we can, at some point in the future, drop the > offending > > patch from the RPM package and all of this will be redundant. It > just requires a > > bit of work to make sure that older use cases (mostly alien) don't > break due to > > this, which might require a bit of development on RPM itself. It's > on my TODO > > list for very rainy and boring days, but unfortunately there's > almost always a > > truckload of other things to do, so I keep dragging it out. > > > > > > > > Mihai > > > > I fully agree on removing the RPM patch that causes all of our issues > on packages depending on it. If needed, I'm willing to be part of > reviewing what would be the impact of returning to a standard RPM > package on Debian and to help into solving those issues. Don't > hesitate to ping me for that. I think the time has come to drop the RPM Debian-specific patches and avoid these workarounds altogether. Once upon a time it made sense to redirect the RPM DB, and to go out of our way to stop users installing RPMs locally, when RPMs were popular as a way to distribute upstream applications. Nowadays, the most common way to distribute upstream apps is via Flatpak/Appimage/etc, or (thanks to Ubuntu's popularity) via deb repositories, so the chances someone tries to 'sudo rpm -i foo.rpm' are very low. The main use of having rpm/dnf/zypper in Debian is not to convert RPMs with Alien or so, but it's to be able to do cross-distribution bootstraps and image building using native tools, like we do in mkosi (and in other tools as well). So these patches to print warnings and divert the database and so on are a hindrance. Hence, for Trixie I think we should just drop them all. It should also make it easier to maintain the RPM stack, which has languished. We are trying to move everything under the RPM Team Salsa org, which should also help. If there are any objections please speak up. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1060594: dnf: Please switch Build-Depends to systemd-dev
Control: close -1 On Thu, 11 Jan 2024 23:36:51 +0100 bi...@debian.org wrote: > Source: dnf > Version: 4.14.0-4.1 > Severity: normal > User: pkg-systemd-maintain...@lists.alioth.debian.org > Usertags: systemd-dev > > Hi, > > your package dnf 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 DNF does not use systemd.pc, it uses systemd-tmpfiles during tests so that's probably why the build dep was added -- Kind regards, Luca Boccassi
Bug#1068868: ITP: python3-pyzmq -- Python bindings for 0MQ
On Fri, 12 Apr 2024 at 14:39, Cody Scott wrote: > > Package: wnpp > Severity: wishlist > Owner: Cody Scott > X-Debbugs-Cc: debian-de...@lists.debian.org, cody.sc...@giatec.ca > > * Package name: python3-pyzmq > Version : 25.1.2 > Upstream Contact: ZeroMQ > * URL : https://pyzmq.readthedocs.io/en/latest/ > * License : BSD > Programming Lang: Python > Description : Python bindings for 0MQ > > > This will be used by Python applications that use ZeroMQ. > > There doesn't appear to be any other Python bindings for ZeroMQ. > > I plan to maintain it and I'm looking for a sponsor. This is already in Debian: https://tracker.debian.org/pkg/pyzmq
Bug#996202: EFI Secure Boot for systemd-boot
On Fri, 22 Mar 2024 18:13:35 + Luca Boccassi wrote: > On Mon, 4 Mar 2024 at 23:58, Luca Boccassi wrote: > > > > On Mon, 4 Mar 2024 at 23:28, Steve McIntyre wrote: > > > > > Modulo those questions, let's talk infrastructure. Off the top of my > > > head, in no particular order... > > > > > > * We'll need to create a new intermediate signing cert for > > > systemd-boot (and another for UKI, I guess). Given recent > > > discussions about changing the way we build and sign kernels, we > > > should also generate a new signer cert for those too. And if we're > > > going that far, we may as well generate a complete new set of 2024 > > > certs. [Sorry, rabbithole. :-)] We'll need to talk to DSA about > > > doing this piece. > > > > That makes sense to me, I guess DSA owns the machinery to do this? > > > > > * We'll probably need to add things to the signing setup for > > > ftp-master. Nothing earth-shattering, just some config to > > > recognise the new set of packages IIRC. I'm sure Bastian can > > > manage this. :-) > > > > > > * Are people from the team ready to deal with long-term security > > > support for the systemd-boot chain? > > > > Speaking for myself, yes, I am already part of the team who is > > responsible for that upstream, and I plan to be very strict about not > > carrying downstream patches for the signed components outside of > > security fixes (and even then, prefer upstream stable point releases > > that I am also responsible for anyway). > > > > > That's all I can think of for now, but I wouldn't be surprised if more > > > comes to mind tomorrow... :-) > > > > Thanks for the feedback! > > Gentle ping on this - what are the next steps in order to make this happen? On IRC Steve mentioned that he's ok with proceeding with this. jcristau from DSA said that it's the FTP team that should confirm the request for the new intermediate signer cert for systemd-boot to DSA. FTP team, are you ok with proceeding with this? If so, would it be possible to have an ACK, please? Is there any more information required beforehand? Thanks! -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package
On Tue, 2 Apr 2024 at 16:52, Bastian Blank wrote: > > On Tue, Apr 02, 2024 at 03:59:25PM +0100, Luca Boccassi wrote: > > Let's look at this the other way around: if there was no dependency, in > > what scenario would things break and how? > > - linux-headers-bla and linux-image-bla are installed > - linux-image-bla is uipgraded > - no modules will be built, because the matching headers are missing Got it, thanks, that makes sense to me as a problem and it would be good to solve. Is the root cause that the image and the headers package are published and uploaded separately, due to signing?
Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package
On Tue, 2 Apr 2024 08:27:39 +0200 Bastian Blank wrote: > On Mon, Apr 01, 2024 at 09:25:40PM +0000, Luca Boccassi wrote: > > Why do dkms modules need the image installed to be built? At the very > > least they didn't use to, the headers were enough last time I had to > > deal with that stuff for the nvidia drivers > > dkms is used to build modules for the kernel that is just being > installed. To do that it needs also the headers in matching versions. > > As the image can't depend on the headers, some other way was needed. Sorry, I am still unable to understand the issue: dkms can and does build modules for all installed _headers_ (plural). The fact that the headers pull in a corresponding image does not change that fact, as far as I can tell. In fact, it doesn't need any images at all, again as far as I know. Let's look at this the other way around: if there was no dependency, in what scenario would things break and how? -- Kind regards, Luca Boccassi
Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package
On Mon, 1 Apr 2024 at 21:49, Bastian Blank wrote: > > Control: tags -1 wontfix > > On Thu, Feb 29, 2024 at 01:38:12PM +0100, Bastian Blank wrote: > > On Thu, Feb 29, 2024 at 12:12:21PM +0000, Luca Boccassi wrote: > > > With the new vmlinux.h shipped in the headers package, the BTF case > > > should be covered. > > As said, this dependency is to make sure kernel modules are properly > built. vmlinux.h is not for kernel modules. Why do dkms modules need the image installed to be built? At the very least they didn't use to, the headers were enough last time I had to deal with that stuff for the nvidia drivers
Bug#1064976: linux-headers-amd64: linux-headers-* incorrectly depends on linux-image-*
Control: tags -1 patch On Tue, 19 Mar 2024 12:32:16 + Colm Buckley wrote: > Package: linux-headers-amd64 > Version: 6.6.13-1~bpo12+1 > Followup-For: Bug #1064976 > X-Debbugs-Cc: c...@tuatha.org > > Can I suggest in the interim that Depends: be replaced with Recommends: > or Suggests: given that most installations won't actually need the image > package? MR to downgrade to recommends: https://salsa.debian.org/kernel-team/linux/-/merge_requests/1054 -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1064059: U-Boot: secure boot support
On Wed, 27 Mar 2024 at 07:57, Heinrich Schuchardt wrote: > > On 3/26/24 22:47, Vagrant Cascadian wrote: > > On 2024-02-16, Heinrich Schuchardt wrote: > >> debian/patches/qemu/efi-secure-boot.patch is not a good approach to > >> enabling secure boot with U-Boot. Variables entered via the command line > >> containing the security database will be stored on file but will not be > >> loaded into U-Boot on the next boot. > >> > >> If you want a version of U-Boot that supports secure boot properly, use > >> CONFIG_EFI_VARIABLES_PRESEED=y and provide a file with the security > >> database which will be built into U-Boot. tools/efivar.py can be used to > >> build that file. > >> > >> Separate U-Boot binaries for secure and non-secure would have to be > >> provided. > > > > Are you saying that individuals needing this support should build their > > own custom u-boot binaries to eanble secure boot ... or that we should > > provide separate packages in Debian with secure boot enabled? > > I would not see the benefit of providing U-Boot in a way that looks like > secure boot but does not provide security. Fortunately there's no such thing. Unless you run the required commands on boot, there's no difference and it very much does not "look like secure boot". > The only use case for an unsigned U-Boot with secure-boot enabled would > be for launching virtual machines. But there we can already use the edk2 > package. When I need to use edk2, I use edk2. If I am using uboot, it's because I want to use uboot. I am not sure why you want to break my use case for something that doesn't affect you in any way?
Bug#1064059: U-Boot: secure boot support
On Fri, 16 Feb 2024 15:57:13 +0100 Heinrich Schuchardt wrote: > Package: u-boot-qemu > Version: 2024.01+dfsg-1 > Severity: normal > > debian/patches/qemu/efi-secure-boot.patch is not a good approach to > enabling secure boot with U-Boot. Variables entered via the command line > containing the security database will be stored on file but will not be > loaded into U-Boot on the next boot. > > If you want a version of U-Boot that supports secure boot properly, use > CONFIG_EFI_VARIABLES_PRESEED=y and provide a file with the security > database which will be built into U-Boot. tools/efivar.py can be used to > build that file. > > Separate U-Boot binaries for secure and non-secure would have to be > provided. > > Existing EDK II packages provide secure boot. Hence I suggest to simply > drop patch debian/patches/qemu/efi-secure-boot.patch. This doesn't make any sense. If you want to embed a key database you can certainly do that, but you have to rebuild from sources anyway, so it has nothing to do with packaging and binaries available in Debian. The current configuration is very useful and works. If you don't want to use it, that's fine, simply don't load keys from the console, it's a no-op then, it doesn't have any impact unless the appropriate commands are ran at boot, so I don't see why it should be removed. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#996202: EFI Secure Boot for systemd-boot
On Mon, 4 Mar 2024 at 23:58, Luca Boccassi wrote: > > On Mon, 4 Mar 2024 at 23:28, Steve McIntyre wrote: > > > Modulo those questions, let's talk infrastructure. Off the top of my > > head, in no particular order... > > > > * We'll need to create a new intermediate signing cert for > > systemd-boot (and another for UKI, I guess). Given recent > > discussions about changing the way we build and sign kernels, we > > should also generate a new signer cert for those too. And if we're > > going that far, we may as well generate a complete new set of 2024 > > certs. [Sorry, rabbithole. :-)] We'll need to talk to DSA about > > doing this piece. > > That makes sense to me, I guess DSA owns the machinery to do this? > > > * We'll probably need to add things to the signing setup for > > ftp-master. Nothing earth-shattering, just some config to > > recognise the new set of packages IIRC. I'm sure Bastian can > > manage this. :-) > > > > * Are people from the team ready to deal with long-term security > > support for the systemd-boot chain? > > Speaking for myself, yes, I am already part of the team who is > responsible for that upstream, and I plan to be very strict about not > carrying downstream patches for the signed components outside of > security fixes (and even then, prefer upstream stable point releases > that I am also responsible for anyway). > > > That's all I can think of for now, but I wouldn't be surprised if more > > comes to mind tomorrow... :-) > > Thanks for the feedback! Gentle ping on this - what are the next steps in order to make this happen?
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#1066840: no mention of iproute2 6.7.0-2.1 in changelog
Control: tags -1 wontfix Control: close -1 On Thu, 14 Mar 2024 at 07:30, Aníbal Monsalve Salazar wrote: > > Package: iproute2 > Version: 6.8.0-1 > Severity: important > > Dear Maintainer, > > At https://tracker.debian.org/pkg/iproute2 it reads: > [2024-03-12] Accepted iproute2 6.7.0-2.1 (source) into unstable (Helmut > Grohne) > > I cannot find the changelog entry listed below for iproute2 6.7.0-2.1 in > the changelog of iproute2 6.8.0-1. > > iproute2 (6.7.0-2.1) unstable; urgency=medium > > * Non-maintainer upload. > * Explicitly depend on libtirpc-dev. (Closes: #1065214) > > -- Helmut Grohne Tue, 12 Mar 2024 09:03:30 +0100 That was intentional and in agreement with Helmut as the same fix was already queued in git before the NMU
Bug#1066077: usr-is-merged fails to install on a /usr-merged system
Control: tags -1 moreinfo On Tue, 12 Mar 2024 at 05:06, David W wrote: > > Package: usr-is-merged > Version: 39 > > When attempting to install, I received the following message: > > ** > * > * 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. > * > ** > > This despite the fact that I have version 39 of usrmerge installed, and the > symlinks were indeed set up correctly. > > In the end, it turned out to be because /usr itself was a symlink, and > although this causes no issues for either the merging process or any running > software, since the check is using "readlink -f" it erroneously fails. Why is /usr a symlink? How did you install your debian system?
Bug#1066076: Current loglevel in system.conf is too verbose by default
Control: tags -1 wontfix Control: close -1 On Mon, 11 Mar 2024 23:58:34 -0400 Neal wrote: > Package: systemd > Version: 255.4-1 > Severity: minor > File: /etc/systemd/system.conf > X-Debbugs-Cc: tombrown9...@gmail.com > > Dear Maintainer, > > Current kernel message verbosity during Debian boot significantly hampers the > ability to identify critical system alerts, with important messages quickly > lost in the noise. This situation presents challenges for both new and > experienced users; newcomers may find the volume of information daunting and > misinterpret its importance, while seasoned users may struggle to quickly > pinpoint vital warnings or errors. To address these concerns, it is proposed > that the default kernel log level be set to "Warning." This adjustment will > streamline the boot process, making critical messages more visible and less > likely to be overlooked. Such a change not only aids in diagnosing and > troubleshooting by highlighting essential alerts but also enhances the boot > experience for all users by focusing on the most pertinent information. The standard default is info so that there is a reasonable amount of information included in bug reports. It's just a default, and you can trivially override it on your machines as you see fit if it doesn't work for you. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
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#996202: EFI Secure Boot for systemd-boot
On Sat, 9 Mar 2024 at 09:59, Pascal Hambourg wrote: > > On 05/03/2024 at 00:58, Luca Boccassi wrote: > > On Mon, 4 Mar 2024 at 23:28, Steve McIntyre wrote: > >> > >> What's your plan for installing as the secondary boot loader for shim > >> to call? > > > > 'bootctl update' already recognises and prefers foo.efi.signed if > > present, so installing to the ESP is easy (PR still doesn't add the > > call, will probably add a trigger). > > > > But as you know Shim right now compiles in the filename of the second > > stage, so for now interested testers will have to manually rename the > > file in the ESP from systemd-bootx64.efi to grubx64.efi, which is of > > course not ideal - let's call it a technological preview. > > What about the installation of shim files into the ESP along with > systemd-boot ? Does bootctl take care of it ? If no, are there any plans > to integrate it ? It does not, there are plans to extend it to do so but it needs 2 things to happen in shim first: - support runtime configuration of second stage, rather than just build time - ie, we definitely do not want our tools to install 'grubx64.efi' as that would be invading someone else's namespace - support providing a version in the PE header so that updates can be done too, not just first installations https://github.com/systemd/systemd/pull/27322 > Also, are there any plans to support multiple ESPs for boot redundancy > (e.g. in software RAID setups) ? It's been asked multiple times, but nobody implemented it so far: https://github.com/systemd/systemd/issues/29948 https://github.com/systemd/systemd/issues/3252 Thing is, because the ESP content is trivial and can be recreated from packages every time if needed, it's not really a very interesting use case for us. if someone wants to do the work to get bootctl to duplicate the content and keep it in sync we can review it and there's no opposition in principle to have it, but we (core devs) are not going to implement it, someone who cares about the use case needs to do so.
Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package
On Mon, 4 Mar 2024 13:54:49 +0100 Bastian Blank wrote: > On Mon, Mar 04, 2024 at 11:28:12AM +0000, Luca Boccassi wrote: > > > But we where talking about kernel modules. > > There are kernel modules using BPF stuff? Never seen one, do you have > > an example? > > No idea, but they get linked BTF information, so you could use them. Sure, but it's a bit of an unusual case to say the least, and I'm not aware of dkms packages in Debian doing that (happy to stand corrected if that's not the case). So surely any out-of-distro dkms package doing that should just ensure they pull in the dependencies they need for it? Assuming it's even needed. As far as I understand, the point of vmlinux.h is that it gives the equivalent information generated from BTF. The issue is that pulling the headers package also pulls the image, initramfs and all that machinery. We are going to depend on the headers package in src:systemd from the next release to get the vmlinux.h, and pulling all that stuff too adds considerable weight to the build dependency installation job. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#996202: EFI Secure Boot for systemd-boot
On Mon, 4 Mar 2024 at 23:28, Steve McIntyre wrote: > > Hey folks, > > On Mon, Mar 04, 2024 at 02:13:25AM +, Luca Boccassi wrote: > >On Fri, 19 Nov 2021 09:33:00 +0100 Bastian Blank > >wrote: > >> Hi > >> > >> I'm rescinding this request. I've got a working prototype, but I > >don't > >> know where this would go. > >> > >> Bastian > > > >The upstream Shim reviewers group now accepts systemd-boot as a 2nd > >stage bootloader, trusted by Shim builds signed with the UEFI 3rd party > >CA. This clears the way for Debian's CA to sign systemd-boot, so I am > >reopening this bug. > > > >shim-review questionnaire update that allows systemd-boot: > > > >https://github.com/rhboot/shim-review/pull/357 > > > >MR on Salsa to add the usual template package, adapted from Bastian's > >MR from a couple of years ago: > > > >https://salsa.debian.org/systemd-team/systemd/-/merge_requests/252 > > > >Debian Shim maintainers, who do we need to seek approvals for this to > >happen? Shim maintainers first of course, anybody else? Release team? > >FTP team? > > OK, I can see what you're doing with templating here, and it looks > clear and obvious. But: this seems to be for standalone systemd-boot > rather than UKI? I thought UKI was the preferred way forward? When you have a headless system then yeah you can go straight to from a first stage to a UKI - but for any end-user system, sd-boot provides the graphical menu with entry selection and so on, which makes it very desirable for those use cases, so it's the natural first step. UKIs are a mean to ship initrd+kernel, but we need to build the initrd first, and we are quite far from there. I don't know yet how that will look like in details for Debian, we had some ideas, but nothing concrete so far, as it's an infrastructure question. When there's something, it won't be from src:systemd as that just builds the stub component. So I'm starting with the boot menu component, which can already be used with more traditional Type #1 third stages - config file plus signed kernel and ye olde initrd cpio. > I'm a little surprised to see you adding riscv64 stuff - AFAIK there's > nobody (yet) providing any root CA for riscv64? We certainly haven't > done anything with it in Debian yet. We build sd-boot for it, so I added it without thinking - but there's no shim so yeah, there's no point, I've dropped it now, thanks for pointing that out. I see there's an upstream PR for it: https://github.com/rhboot/shim/pull/641 so might add it back if that ends up being built after the next upstream release. > What's your plan for installing as the secondary boot loader for shim > to call? 'bootctl update' already recognises and prefers foo.efi.signed if present, so installing to the ESP is easy (PR still doesn't add the call, will probably add a trigger). But as you know Shim right now compiles in the filename of the second stage, so for now interested testers will have to manually rename the file in the ESP from systemd-bootx64.efi to grubx64.efi, which is of course not ideal - let's call it a technological preview. Fortunately as you might have heard in one of the meetings there's a PR in progress to let Shim be configured at runtime: https://github.com/rhboot/shim/pull/608 I hope we can get that sorted before Trixie freezes, and that's how I see the integration ultimately work. > Modulo those questions, let's talk infrastructure. Off the top of my > head, in no particular order... > > * We'll need to create a new intermediate signing cert for > systemd-boot (and another for UKI, I guess). Given recent > discussions about changing the way we build and sign kernels, we > should also generate a new signer cert for those too. And if we're > going that far, we may as well generate a complete new set of 2024 > certs. [Sorry, rabbithole. :-)] We'll need to talk to DSA about > doing this piece. That makes sense to me, I guess DSA owns the machinery to do this? > * We'll probably need to add things to the signing setup for > ftp-master. Nothing earth-shattering, just some config to > recognise the new set of packages IIRC. I'm sure Bastian can > manage this. :-) > > * Are people from the team ready to deal with long-term security > support for the systemd-boot chain? Speaking for myself, yes, I am already part of the team who is responsible for that upstream, and I plan to be very strict about not carrying downstream patches for the signed components outside of security fixes (and even then, prefer upstream stable point releases that I am also responsible for anyway). > That's all I can think of for now, but I wouldn't be surprised if more > comes to mind tomorrow... :-) Thanks for the feedback!
Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package
On Mon, 4 Mar 2024 at 10:32, Bastian Blank wrote: > > On Sat, Mar 02, 2024 at 12:40:07AM +, Luca Boccassi wrote: > > Yes precisely, the bpf program source can just include vmlinux.h and it > > should build and run as expected. > > But we where talking about kernel modules. > > Bastian There are kernel modules using BPF stuff? Never seen one, do you have an example?
Bug#996202: EFI Secure Boot for systemd-boot
On Fri, 19 Nov 2021 09:33:00 +0100 Bastian Blank wrote: > Hi > > I'm rescinding this request. I've got a working prototype, but I don't > know where this would go. > > Bastian The upstream Shim reviewers group now accepts systemd-boot as a 2nd stage bootloader, trusted by Shim builds signed with the UEFI 3rd party CA. This clears the way for Debian's CA to sign systemd-boot, so I am reopening this bug. shim-review questionnaire update that allows systemd-boot: https://github.com/rhboot/shim-review/pull/357 MR on Salsa to add the usual template package, adapted from Bastian's MR from a couple of years ago: https://salsa.debian.org/systemd-team/systemd/-/merge_requests/252 Debian Shim maintainers, who do we need to seek approvals for this to happen? Shim maintainers first of course, anybody else? Release team? FTP team? -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package
On Thu, 29 Feb 2024 14:23:05 + Colm Buckley wrote: > On Thu, 29 Feb 2024 13:38:12 +0100 Bastian Blank wrote: > > On Thu, Feb 29, 2024 at 12:12:21PM +0000, Luca Boccassi wrote: > > > With the new vmlinux.h shipped in the headers package, the BTF case > > > should be covered. > > > > The relevant code in Linux is: > > > > | quiet_cmd_btf_ko = BTF [M] $@ > > | cmd_btf_ko = > \ > > | if [ ! -f vmlinux ]; then > \ > > | printf "Skipping BTF generation for %s due to > unavailability of vmlinux\n" $@ 1>&2; \ > > | else > \ > > | LLVM_OBJCOPY="$(OBJCOPY)" $(PAHOLE) -J $(PAHOLE_FLAGS) > --btf_base vmlinux $@; \ > > | $(RESOLVE_BTFIDS) -b vmlinux $@; > \ > > | fi; > > > > Which change is needed here to use vmlinux.h instead? > > My understanding is that you don't need this command at all; the included > vmlinux.h already contains the necessary type definitions for libbpf, for > the kernel source version in question - ie: instead of needing to run > pahole or bpftool to extract these definitions from a specific vmlinux > image, this file is distributed with them already included. Yes precisely, the bpf program source can just include vmlinux.h and it should build and run as expected. -- Kind regards, Luca Boccassi 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#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package
On Thu, 29 Feb 2024 12:25:27 +0100 Bastian Blank wrote: > On Thu, Feb 29, 2024 at 11:03:11AM +, Colm Buckley wrote: > > Why was this never the case before? And can you be more precise about what > > "stuff" is missing? Is there a previous bug report I can reference? > > It complains loudly about BTF. With the new vmlinux.h shipped in the headers package, the BTF case should be covered. I think we should nudge packages to use that, rather than looking at the kernel image, or worse sysfs from the running kernel, which is completely wrong for obvious reasons. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
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#1062838: openconnect: NMU diff for 64-bit time_t transition
Control: tags -1 -pending Control: close -1 On Sat, 03 Feb 2024 11:31:57 -0800 David Woodhouse wrote: > This looks like overkill to me, for openconnect. > > There's precisely one function exported from libopenconnect which uses > time_t, and I suspect there aren't any *users* of that function in the > distribution anyway (neither openconnect(8) nor NetworkManager- > openconnect use it). So although it's not best practice, we could > actually get away with just *dropping* that function, and adding a new > function which returns either an explicit 64-bit value or a timespec or > something. > > Alternatively... on how many of our 64-bit architectures can we just > return the high 32 bits of the 64-bit time_t in a register that we > call-clobbered anyway — so callers who expect a 64-bit time_t get to > see it all, and callers who expect a 32-bit time_t just don't notice? > The contents of the *low* 32 bits are the same either way, right? > > It definitely doesn't seem like we need to switch to a new soname ... > except *are* you switching the soname? Or just the package name? It > looks like the symbol versions are remaining the *same*...? How does > that work? I agree, this is completely pointless. Even if the function was actually used, it's armv7 for crying out loud, nobody is going to use today's TLS protocols in 2038 on an armv7 box, they barely last a couple of years before vendors do incompatible changes. I'd much rather drop the armv7 build entirely if push came to shove. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
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.
