Subject: bug#844: systemd-boot-efi: Broken man pages

From: murzik <[email-masked]>
Date: Mon, 25 Mar 2024 09:59:08 +1100

Package: systemd-boot-efi
X-Debbugs-Cc: [email-masked]
Version: 252.22-1~deb12u1
Severity: minor

Dear Maintainer,
Looks like linuxia32.efi.stub and linuxx64.efi.stub man pages are 
broken.
The package was installed from the repositories via APT and passes 
integrity tests.
[✖ user@host ~ ]$ man linuxia32.efi.stub
man: can't resolve man7/systemd-stub.7
No manual entry for linuxia32.efi.stub

[✖ user@host ~ ]$ man linuxx64.efi.stub
man: can't resolve man7/systemd-stub.7
No manual entry for linuxx64.efi.stub

-- System Information:
Distributor ID: Devuan
Description: Devuan GNU/Linux 5 (daedalus)
Release: 5
Codename: daedalus
Architecture: x86_64

Kernel: Linux 6.1.0-18-amd64 (SMP w/6 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: OpenRC (via /run/openrc), PID 1: openrc-init

-- no debconf information

---

From: Mark Hindley <[email-masked]>
Date: Mon, 25 Mar 2024 21:34:03 +0000

Control: tags -1 debian

>    Package: systemd-boot-efi

This is not a forked package and Devuan uses Debian's packages directly without
recompilation. 

>    man: can't resolve man7/systemd-stub.7

man7/systemd-stub.7 is contained in bin:systemd[1]. So you have uncovered a
missing dependency: systemd-boot-efi should depend on systemd.

In principle, this should be reported to Debian's BTS to be fixed. However, if
it was fixed in Debian, systemd-boot-efi would become unavailable in Devuan as
the systemd package and its rdepends are banned and removed by amprolla. That
may not be what you want to achieve.

The choice is yours.

Mark

[1]  https://packages.debian.org/search?suite=bookworm&arch=any&mode=filename&searchon=contents&keywords=systemd-stub

---

From: murzik <[email-masked]>
Date: Wed, 03 Apr 2024 22:07:50 +1100

oh.. sad. anyway, thanks for letting me know. This error will 100% be 
revealed sooner or later. maybe its possible to just replace 
systemd-stub-efi with systemd-srub-efi-standalone? It will be extremely 
strange if the only way to use sd-stub in devuan is to dig into the 
meason config and build systemd yourself. Also, implementing a 
standalone package will be extremely simple - nothing other than 
editing the meson config is required. Also, there is already a 
ready-made config and implementation: 
<https://github.com/schreiberstein/systemd-efi-stub-standalone>
As far as I can tell, the project has experience in this.
we already have systemd-bootchart; systmed-sysusers-standalone; 
systemd-tpmfiles-standalone; systemd-oomd.. I don't think adding one 
standalone package will be a problem.

On Mon, Mar 25 2024 at 09:34:03 PM +00:00:00, Mark Hindley 
<[email-masked]> wrote:
>> <mailto:[email-masked]>
> [1]  
> <https://packages.debian.org/search?suite=bookworm&arch=any&mode=filename&searchon=contents&keywords=systemd-stub>
>

---

From: Mark Hindley <[email-masked]>
Date: Wed, 3 Apr 2024 13:11:15 +0100

>    standalone package will be a problem.

All of those are Debian packages. Devuan doesn't produce any systemd 
standalone packages.

Mark

---

From: murzik <[email-masked]>
Date: Thu, 04 Apr 2024 13:23:34 +1100

Interesting. but it seems to me that adding a dependency on systemd 
because of one (!!) documentation file will be a very strange decision. 
this file will most likely be moved from the systemd package, or even 
just a copy of it added to the package.
Also, I found an alternative - stubby core.
so even if a dependency on systemd is added, it shouldn't cause any 
inconvenience
Interesting. but it seems to me that adding a dependency on systemd 
because of one (!!) documentation file will be a very strange decision. 
this file will most likely be moved from the systemd package, or even 
just a copy of it added to the package.
Also, I found an alternative - stubby core.
so even if a dependency on systemd is added, it shouldn't cause any 
inconvenience
Interesting. but it seems to me that adding a dependency on systemd 
because of one (!!) documentation file will be a very strange decision. 
this file will most likely be moved from the systemd package, or even 
just a copy of it added to the package.
Also, I found an alternative - stubby core.
so even if a dependency on systemd is added, it shouldn't cause any 
inconvenience
Interesting. but it seems to me that adding a dependency on systemd 
because of one (!!) documentation file will be a very strange decision. 
this file will most likely be moved from the systemd package, or even 
just a copy of it added to the package.
Also, I found an alternative - stubby 
https://github.com/puzzleos/stubby.
so even if a dependency on systemd is added, it shouldn't cause any 
inconvenience.
I'll report it to debian bug tracker later.

---

From: murzik <[email-masked]>
Date: Thu, 04 Apr 2024 13:33:38 +1100

<https://github.com/puzzleos/stubby>.

On Thu, Apr 4 2024 at 01:23:34 PM +11:00:00, murzik 
<[email-masked]> wrote:
> because of one (!!) documentation file will be a very strange 
> decision. this file will most likely be moved from the systemd 
> package, or even just a copy of it added to the package.
> because of one (!!) documentation file will be a very strange 
> decision. this file will most likely be moved from the systemd 
> package, or even just a copy of it added to the package.
> because of one (!!) documentation file will be a very strange 
> decision. this file will most likely be moved from the systemd 
> package, or even just a copy of it added to the package.
> because of one (!!) documentation file will be a very strange 
> decision. this file will most likely be moved from the systemd 
> package, or even just a copy of it added to the package.