Re: reference Debian package of multiple binaries sharing one man page

[Norwid Behrnd]

Hello,

On Sat, 11 Nov 2023 14:08:49 +0100
Alexander Sulfrian  wrote:

> 
> You will need a file mdl.1 with the following content:
> 
> .so man1/markdownlint.1
> 
> and markdownlint.1 should be the normal manpage without a .so line.
> 

This logic provides exactly the relay I sought out.  Thanks a lot, the problem
is resolved fully.

Norwid

Re: reference Debian package of multiple binaries sharing one man page

[Russ Allbery]

Norwid Behrnd  writes:

> Recently, I started to upgrade the Debian package about
> `markdownlint`,[1] a syntax checker.  The initially packaged version
> 0.12.0 provided a binary of name `ruby-mdl` which now becomes a
> transition dummy package in favour of the functionally updated
> `markdownlint`.

> I wonder how to properly prepare an adjusted man page for both binaries,
> because lintian warns about the absence for `usr/bin/mdl`.[2]

I think the problem is that you put the .so line in the wrong file.  It
should be the entire contents of the file corresponding to the deprecated
binary name, not a line in the file that represents the current binary
name.

The good news is that if you're using debhelper, you don't have to care
about how man handles these indirections and can just use a symlink.
Install the man page into usr/share/man/man1 under whatever name is
canonical (possibly by using dh_installman), and then create a symlink in
usr/share/man/man1 from the other man page name to that file.

dh_installman will then clean this all up for you and create proper .so
links and you don't have to care about the proper syntax.

-- 
Russ Allbery (r...@debian.org)  

Re: reference Debian package of multiple binaries sharing one man page

[Andrey Rakhmatullin]

On Fri, Nov 10, 2023 at 11:44:06AM -0800, Russ Allbery wrote:
> The good news is that if you're using debhelper, you don't have to care
> about how man handles these indirections and can just use a symlink.
> Install the man page into usr/share/man/man1 under whatever name is
> canonical (possibly by using dh_installman), and then create a symlink in
> usr/share/man/man1 from the other man page name to that file.
> 
> dh_installman will then clean this all up for you and create proper .so
> links and you don't have to care about the proper syntax.
Isn't it the other way around? The whole idea of using .so is to tell
dh_installman(1) to create symlinks.

Re: reference Debian package of multiple binaries sharing one man page

[Russ Allbery]

Andrey Rakhmatullin  writes:
> On Fri, Nov 10, 2023 at 11:44:06AM -0800, Russ Allbery wrote:

>> The good news is that if you're using debhelper, you don't have to care
>> about how man handles these indirections and can just use a symlink.
>> Install the man page into usr/share/man/man1 under whatever name is
>> canonical (possibly by using dh_installman), and then create a symlink
>> in usr/share/man/man1 from the other man page name to that file.

>> dh_installman will then clean this all up for you and create proper .so
>> links and you don't have to care about the proper syntax.

> Isn't it the other way around? The whole idea of using .so is to tell
> dh_installman(1) to create symlinks.

Oh, indeed, you're right and I misread that.  So I think you can just use
symlinks, period, and not worry about .so (although you have to handle
nodoc builds correctly).

-- 
Russ Allbery (r...@debian.org)  

Re: Linking coreutils against OpenSSL

[Florian Weimer]

* Theodore Ts'o:

> If you can get upstream a patch so that coreutils could try to dlopen
> OpenSSL and use it if it is available, but skip it if it is not, that
> might be one way to avoid OpenSSL going into essential.  The challenge
> is that OpenSSL is not known for its ability to maintain a stable ABI,
> but if we only care about supporting a specific version of OpenSSL
> (the one which is shipped with coreutils) and given that the fallback
> is a slower sha256sum, which IMHO is *not* a disaster, perhaps it's
> doable?

I think the OpenSSL 3 ABI should be stable for quite some time.  It's
probably not even necessary to use dlvsym instead of dlsym because I
think OpenSSL upstream just adds new functions if they need new
behaviors.

Bug#1055897: ITP: speakersafetyd -- speaker protection daemon for embedded Linux systems

[Andreas Henriksson]

Package: wnpp
Severity: wishlist
Owner: Andreas Henriksson 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: speakersafetyd
  Version : 0.1.4
  Upstream Contact: https://github.com/AsahiLinux/speakersafetyd/issues
* URL : https://github.com/AsahiLinux/speakersafetyd/
* License : MIT
  Programming Lang: Rust
  Description : speaker protection daemon for embedded Linux systems

Speaker protection for Apple Silicon (and potentially other) laptops
with built-in speakers. The Apple M1, M2, etc laptops do not have
protection for melting speakers in hardware, so need this (unlike
many other laptops). The implementation is generic enough that it
could in the future support other systems as well (eg. many embedded
systems might be in the same situation if they have speakers).

I hope to maintain this package in the rust-team (with the help of the
bananas-team).

Preliminary packaging available at:
https://salsa.debian.org/rust-team/debcargo-conf/-/merge_requests/560

See also:
https://wiki.debian.org/Teams/Bananas

Regards,
Andreas Henriksson

Re: reference Debian package of multiple binaries sharing one man page

[Norwid Behrnd]

On Mon, 13 Nov 2023 09:41:12 -0800
Russ Allbery  wrote:

> 
> Oh, indeed, you're right and I misread that.  So I think you can just use
> symlinks, period, and not worry about .so (although you have to handle
> nodoc builds correctly).
> 

Well, one file with a list like

```debian/markdownlint.manpages
debian/markdownlint.1
debian/mdl.1
debian/ruby-mdl.1
```

where the first one is the complete manpage, and the later files only contain
two line note of

```debian/mdl.1
.\"relay to markdownlint.1
.so man1/markdownlint.1
```

to indicate the complete manpage in the same folder might be equally acceptable
for a small package.  At least it was both considered good enough by lintian
after compiling the .deb as well as a subsequent local installation now
providing the functionality missed earlier.  Good enough for an upload to
mentors and a RFS.[1]

[1] https://mentors.debian.net/package/ruby-mdl/

Re: Linking coreutils against OpenSSL

[Pierre-Elliott Bécue]

Luca Boccassi  wrote on 10/11/2023 at 16:08:30+0100:

> On Fri, 10 Nov 2023 at 14:22, Pierre-Elliott Bécue  wrote:
>>
>> Luca Boccassi  wrote on 10/11/2023 at 15:00:24+0100:
>>
>> > On Fri, 10 Nov 2023 at 13:45, Bjørn Mork  wrote:
>> >>
>> >> Luca Boccassi  writes:
>> >>
>> >> > If we want to start nitpicking, then let's be exact: 0.61% of popcon.
>> >> > Whether that qualifies as "plenty" we'll leave as an exercise for the
>> >> > readers.
>> >>
>> >> I wonder if this sort of arrogant "don't care about minorities" attitude
>> >> will ever stop?  Was sort of hoping that things would quiet down when
>> >> everyone just gave up on the systemd and usr-merge crazyness. But it
>> >> seems the bullies continue on and on and on and on.
>> >>
>> >> I guess those 0.61% are run bt the most valuable Debian users out there.
>> >> I'm sorry to not be one of them, but that's the way things have become.
>> >> Not by choice.
>> >
>> > Having a 5x performance improvement in core utilities at zero cost for
>> > 99.39% of users and at the cost of an extra library that is already
>> > widely used for 0.61% --> bullying. Noted.
>>
>> The problem is not the argument but clearly the way you state it, which
>> is quite coherent with your way of answering most of the time.
>>
>> I know it's not mandatory, but a bit of empathy, a bit of caring and a
>> bit of "just because I can act bluntly with a pinch of contempt doesn't
>> mean I should" would be really appreciable.
>
> You know what else would be really appreciable? Not starting the
> usual, tired, old flamewar, with heavily emotionally charged language
> ("bullying", "contempt", "lack of empathy", "lack of caring", etc),
> when talking about something as trivial and harmless as installing a
> widely used and common library to get a 5x performance boost out of
> the core system. How about we do that instead? Because, just in case
> perspective was already lost, this is what started the tirade:
>
>> This sounds great. systemd also uses OpenSSL for various things, so
>> libssl3 is pretty much a given on any bootable installation anyway
>> already.
>
> IE: a supportive and appreciative comment, followed by a relevant and
> objective piece of information. Where's the bullying?

I'd like to extend an apology to Luca, my mail was intended to be
private, I used the wrong shortcut to reply. I'll therefore reply to
this second mail privately as it was first intended.

Regards,

-- 
PEB


signature.asc
Description: PGP signature

New Essential package procps-base

[Craig Small]

Hello,
  For quite some time (since 2006!) there has been a discussion at[1] about
changing from the sysvinit-utils version of pidof to the procps one. A
quick scan of the various distributions shows that only Debian and Ubuntu
(and I assume most other downstreams) use the sysvinit-utils version.

So to rehash some old drafts, here's the proposal.

What:
Create a new package procps-base. This uses the existing procps source
package and just enable building of pidof. procps-base will be an Essential
package and only contain pidof.

Why:
This would bring the pidof variant in line with other distributions.
sysvinit-utils would no longer need to be Essential (though that's a
separate issue) and would only have init-d-script, fstab-decode, and
killall5.

The majority of usage of pidof is in init or pre/post scripts, which really
should be using the LSB pidofproc function. That function in turn
optionally uses pidof if the pidfile parameter is not given. That's
probably a way forward for sometime in the future to not need procps-base
Essential, but it is a way off.

sysvinit-utils requires only libc6 while procps-base require libproc-2 but
this is the same library used for the ps,top,w etc tools which are
installed on most systems.


1: https://bugs.debian.org/810018