Re: Linking coreutils against OpenSSL
On Fri, 10 Nov 2023 at 02:26, Simon Richter wrote: > > Hi, > > > What would you think about having coreutils Depend on libssl3? This > > would make the libssl3 package essential, which is potentially > > undesirable, but it also has the potential for serious user time savings > > (on recent Intel CPUs, OpenSSL’s SHA-256 is over five times faster than > > coreutils’ internal implementation). > > That is only on amd64 though. > > On ARM and riscv64, OpenSSL is slightly slower than coreutils' > sha256sum, so this would introduce an additional dependency and degrade > performance. The best choice there is the kernel crypto API, which knows > about offload hardware and special CPU instructions, both of which are > common. Per-architecture dependencies are possible though, so maybe starting to add the libssl dependency only on amd64 is a good starting point, and then users of other architectures can request to be added too if it is beneficial for them.
Re: Linking coreutils against OpenSSL
On Fri, Nov 10, 2023 at 10:38:13AM +, Luca Boccassi wrote: > On Fri, 10 Nov 2023 at 02:26, Simon Richter wrote: > > > > Hi, > > > > > What would you think about having coreutils Depend on libssl3? This > > > would make the libssl3 package essential, which is potentially > > > undesirable, but it also has the potential for serious user time savings > > > (on recent Intel CPUs, OpenSSL’s SHA-256 is over five times faster than > > > coreutils’ internal implementation). > > > > That is only on amd64 though. > > > > On ARM and riscv64, OpenSSL is slightly slower than coreutils' > > sha256sum, so this would introduce an additional dependency and degrade > > performance. The best choice there is the kernel crypto API, which knows > > about offload hardware and special CPU instructions, both of which are > > common. > > Per-architecture dependencies are possible though, so maybe starting > to add the libssl dependency only on amd64 is a good starting point, > and then users of other architectures can request to be added too if > it is beneficial for them. > Per architecture does cause problems if we end up with a two tier system where some architectures can never catch up or if we have users who assume that Debian will work similarly on every architecture. It may also introduce code complexity which is undesirable in the longer term. Just my 0.02 - I have no particular viewpoint in the best course of action overall. Andy [amaca...@debian.org]
Re: Linking coreutils against OpenSSL
Luca Boccassi writes: > On Thu, 9 Nov 2023 at 22:54, Benjamin Barenblat wrote: >> What would you think about having coreutils Depend on libssl3? This >> would make the libssl3 package essential, which is potentially >> undesirable, but it also has the potential for serious user time savings >> (on recent Intel CPUs, OpenSSL’s SHA-256 is over five times faster than >> coreutils’ internal implementation). > > This sounds great. systemd also uses OpenSSL for various things, so > libssl3 is pretty much a given on any bootable installation anyway > already. I have no particular opinion on the proposal to make coreutils Depend on libssl3; but there are plenty of bootable Debian systems without systemd, so I'd like to gently push back on the idea that the only bootable Debian systems are those using systemd as init. Thanks, Matthew [commenting here, but I see at least one repetition of the claim in the thread] -- "At least you know where you are with Microsoft." "True. I just wish I'd brought a paddle." http://www.debian.org
Re: Linking coreutils against OpenSSL
In my opinion, this is yet another reason to use a proper cryptography library (openssl, gnutls or gcrypt) instead of a custom implementation for this kind of algorithm. Over time, when these libraries add support for cryptography acceleration instructions for more architectures, all programs will benefit from it. I would expect that many rich ARM SoCs for phones, laptops and servers already have something and that openssl supports it already. What device did you run your benchmark on? Regards Stephan signature.asc Description: This is a digitally signed message part
Re: Linking coreutils against OpenSSL
On Fri, 10 Nov 2023 at 11:54, Matthew Vernon wrote: > > Luca Boccassi writes: > > > On Thu, 9 Nov 2023 at 22:54, Benjamin Barenblat wrote: > > >> What would you think about having coreutils Depend on libssl3? This > >> would make the libssl3 package essential, which is potentially > >> undesirable, but it also has the potential for serious user time savings > >> (on recent Intel CPUs, OpenSSL’s SHA-256 is over five times faster than > >> coreutils’ internal implementation). > > > > This sounds great. systemd also uses OpenSSL for various things, so > > libssl3 is pretty much a given on any bootable installation anyway > > already. > > I have no particular opinion on the proposal to make coreutils Depend > on libssl3; but there are plenty of bootable Debian systems without > systemd, so I'd like to gently push back on the idea that the only > bootable Debian systems are those using systemd as init. > > Thanks, > > Matthew > [commenting here, but I see at least one repetition of the claim in the > thread] 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.
Bug#1055740: ITP: golang-github-humanlogio-humanlog -- Logs for humans to read.
Package: wnpp Severity: wishlist Owner: Maytham Alsudany * Package name: golang-github-humanlogio-humanlog Version : 0.7.6-1 Upstream Author : Antoine Grondin * URL : https://github.com/humanlogio/humanlog * License : Apache-2.0 Programming Lang: Go Description : Logs for humans to read. Read structured logs from stdin and print them back to stdout, but in a prettier and more human-readable format. This is a dependency of the upcoming lazygit package, and I intend to maintain it within the Debian Go Packaging team.
Bug#1055741: ITP: golang-connectrpc-connect -- The Go implementation of Connect: Protobuf RPC that works.
Package: wnpp Severity: wishlist Owner: Maytham Alsudany * Package name: golang-connectrpc-connect Version : 1.12.0-1 Upstream Author : Connect * URL : https://github.com/connectrpc/connect-go * License : Apache-2.0 Programming Lang: Go Description : The Go implementation of Connect: Protobuf RPC that works. Connect is a slim library for building browser and gRPC-compatible HTTP APIs. You write a short Protocol Buffer schema and implement your application logic, and Connect generates code to handle marshaling, routing, compression, and content type negotiation. It also generates an idiomatic, type-safe client. Handlers and clients support three protocols: gRPC, gRPC-Web, and Connect's own protocol. . The Connect protocol is a simple protocol that works over HTTP/1.1 or HTTP/2. It takes the best portions of gRPC and gRPC-Web, including streaming, and packages them into a protocol that works equally well in browsers, monoliths, and microservices. Calling a Connect API is as easy as using curl. This is an indirect dependency of the upcoming lazygit package. I intend to maintain this package within the Debian Go Packaging team.
Re: Linking coreutils against OpenSSL
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. Bjørn
Re: Linking coreutils against OpenSSL
On Fri, Nov 10, 2023 at 10:38:13AM +, Luca Boccassi wrote: Per-architecture dependencies are possible though, so maybe starting to add the libssl dependency only on amd64 is a good starting point, and then users of other architectures can request to be added too if it is beneficial for them. I haven't seen any objections to the basic idea, so I'm starting here: coreutils 9.4-2 will link to libcrypto if there's a gpl-compatible version available at build time, but I've added the build-dependency as linux-amd64 only for now. That should make it fairly straightforward for people to control the linking on other architectures by controlling their build environment. Going forward, depending on feedback, I can roll this back, expand the build-dep, and/or make the configure option also depend on the arch.
Re: Linking coreutils against OpenSSL
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.
Re: Linking coreutils against OpenSSL
Hi, On Fri, 2023-11-10 at 14:45 +0100, Bjørn Mork wrote: > 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. Do you have any data to back up this claim? Or is it just a totally made up guess and one could just as well claim that those are the least valuable 0.61%? Ansgar
Re: Linking coreutils against OpenSSL
On Fri, 2023-11-10 at 08:48 -0500, Michael Stone wrote: > On Fri, Nov 10, 2023 at 10:38:13AM +, Luca Boccassi wrote: > > Per-architecture dependencies are possible though, so maybe starting > > to add the libssl dependency only on amd64 is a good starting point, > > and then users of other architectures can request to be added too if > > it is beneficial for them. > > I haven't seen any objections to the basic idea, so I'm starting here: > coreutils 9.4-2 will link to libcrypto if there's a gpl-compatible > version available at build time, but I've added the build-dependency as > linux-amd64 only for now. That should make it fairly straightforward for > people to control the linking on other architectures by controlling > their build environment. Going forward, depending on feedback, I can > roll this back, expand the build-dep, and/or make the configure option > also depend on the arch. Please avoid producing different results depending on the build environment. That just results in non-reproducible issues in unclean environments (suddenly different dependencies, different features, ...). Please consider to just use openssl everywhere or also explicitly disable/enable build options per arch. (Personally I would in this case probably just enable openssl everywhere and recommend people to improve openssl in case it is slower than the built-in implementation; openssl is probably use widely enough to warrant that.) Ansgar
Re: Linking coreutils against OpenSSL
On Fri, 10 Nov 2023 at 13:48, Michael Stone wrote: > > On Fri, Nov 10, 2023 at 10:38:13AM +, Luca Boccassi wrote: > >Per-architecture dependencies are possible though, so maybe starting > >to add the libssl dependency only on amd64 is a good starting point, > >and then users of other architectures can request to be added too if > >it is beneficial for them. > > I haven't seen any objections to the basic idea, so I'm starting here: > coreutils 9.4-2 will link to libcrypto if there's a gpl-compatible > version available at build time, but I've added the build-dependency as > linux-amd64 only for now. That should make it fairly straightforward for > people to control the linking on other architectures by controlling > their build environment. Going forward, depending on feedback, I can > roll this back, expand the build-dep, and/or make the configure option > also depend on the arch. Very nice, thank you for this work!
Re: Linking coreutils against OpenSSL
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. -- PEB signature.asc Description: PGP signature
Re: Linking coreutils against OpenSSL
On Fri, Nov 10, 2023 at 03:10:42PM +0100, Ansgar wrote: Please avoid producing different results depending on the build environment. That just results in non-reproducible issues in unclean environments (suddenly different dependencies, different features, ...). I think that is an acceptable tradeoff at this time; the only difference will be the dependencies, but that is the intent. Automated buildd packages should be stable. Based on further experience and feedback, one of the other options could be chosen instead. (I'm particularly interested in hearing from people who compare the different builds on arm, as that is where there's been an assertion of a performance regression.)
Re: Linking coreutils against OpenSSL
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?
Re: Linking coreutils against OpenSSL
Hi, On 11/10/23 21:07, Stephan Verbücheln wrote: In my opinion, this is yet another reason to use a proper cryptography library (openssl, gnutls or gcrypt) instead of a custom implementation for this kind of algorithm. Yes and no. The reason several of our core tools bring their own functions is to specifically reduce the Essential package set. Hence this thread: we need to weigh the benefits against the drawbacks here. In coreutils' case, I think the benefits are kind of qualified by the number of direct users. Basically, few people have use cases that require them to routinely verify checksums with the tools from coreutils[1]. The main benefit of this move is that container images will shrink because libssl becomes part of the base layer, so fewer copies of it will be kept in stacked layers. I would disregard this as a benefit, otherwise we could make a case that more packages should be Essential. The actual drawbacks for users are minimal too: - systemd pulls it in anyway - apt will pull it in on the remaining systems I don't quite see the appeal of OpenSSL as a dependency for apt either. I have 2 Gbps Internet at home, and a laptop I bought in 2012, and apt is never CPU bound. I could see the benefit of gzip offloading into the kernel crypto engine, that would be noticeable to me and at least two other people. We already have two other such libraries in the quasi-essential set: libcrypt, and the Linux kernel. libcrypt: + already in the quasi-essential set (no extra space) - still slow kernel: + No extra space needed + Support for offload engines that use privileged access - Invisible dependency OpenSSL: + Handwritten optimized assembler functions for a set of architectures - Horrible code The optimized assembler function brings a massive speedup on amd64, which is what triggered this thread. The ARM NEON assembler code gives a moderate speedup for hashing compared to autovectorized generic code, but in general vector units are the wrong tool for cryptographic hashes, so I'm not surprised it isn't an order of magnitude. Over time, when these libraries add support for cryptography acceleration instructions for more architectures, all programs will benefit from it. Yes, but crypto acceleration in instruction form is difficult to implement in RISC architectures -- which is why these usually have separate DMA capable devices, and work queues managed in the kernel. I would expect that many rich ARM SoCs for phones, laptops and servers already have something and that openssl supports it already. What device did you run your benchmark on? I used a Zynq SoC, and just tested a random file I had that fit into memory, running sha256sum and kcapi-dgst -c sha256 five times each. OpenSSL is a bit faster (going from 1 minute to 45 seconds), but in a real world application I'd give this an offload engine on the FPGA side if it was a hot path, and ignore it if it was not. In summary, I don't believe this change has any measurable effect beyond growing the Essential set and improving artificial benchmarks, so I'm pretty lukewarm about this. Simon [1] "debootstrap george" is an outlier and should not have been counted
Re: Linking coreutils against OpenSSL
On Sat, Nov 11, 2023 at 12:55:16AM +0900, Simon Richter wrote: > Hi, > > On 11/10/23 21:07, Stephan Verbücheln wrote: > > > In my opinion, this is yet another reason to use a proper cryptography > > library (openssl, gnutls or gcrypt) instead of a custom implementation > > for this kind of algorithm. > > Yes and no. The reason several of our core tools bring their own functions > is to specifically reduce the Essential package set. Hence this thread: we > need to weigh the benefits against the drawbacks here. > > In coreutils' case, I think the benefits are kind of qualified by the number > of direct users. Basically, few people have use cases that require them to > routinely verify checksums with the tools from coreutils[1]. > > The main benefit of this move is that container images will shrink because > libssl becomes part of the base layer, so fewer copies of it will be kept in > stacked layers. I would disregard this as a benefit, otherwise we could make > a case that more packages should be Essential. > > The actual drawbacks for users are minimal too: > - systemd pulls it in anyway > - apt will pull it in on the remaining systems > > I don't quite see the appeal of OpenSSL as a dependency for apt either. I > have 2 Gbps Internet at home, and a laptop I bought in 2012, and apt is > never CPU bound. I could see the benefit of gzip offloading into the kernel > crypto engine, that would be noticeable to me and at least two other people. It's not a performance issue for APT, but: 1) we use libgcrypt in libapt-pkg, which needs global initialization. Libraries should not be doing the initialization, we're basically misusing it. The reason we use a library is to not have to vendorize the hashing algorithms. But more importantly, OpenSSL is the right choice because: 2) We use GnuTLS for the https support and that has various little incompatibilities that break it with some servers, certificates, or oppressive government firewalls, causing people not to be able to download their updates via https. Hence want to replace that with OpenSSL -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en
Debian Med video meeting tomorrow Saturday 2023-11-11 19:00 UTC
Hi, this is the call for the next video meeting of the Debian Med team that are an established means to organise the tasks inside our team. Meetings usually take us only 15-20min depending what we are talking about and how many people are joining. The next meeting is tomorrow https://www.timeanddate.com/worldclock/fixedtime.html?iso=2023T19 Despite technical issues of the last meeting I think we stick to the known Debian Social channel https://jitsi.debian.social/DebianMedCovid19 The topic is what contributors have done in the past period and to coordinate the work until the next meeting. For those who are interested in hot topics we want to tackle, here are some items: - BioConductor transition - Python 3.12 transition - Outreachy candidates Newcomers are always welcome. See you tomorrow Andreas. -- http://fam-tille.de
reference Debian package of multiple binaries sharing one man page
Hello, I seek a maintained Debian package which provides multiple binaries sharing one man page in common -- do you know an example? 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] After passing section 12.1 of the Debian Policy Manual, Jens Schweikhart's manual[3] appeared suitable here because of the following section 4: ---8>< --- Here is how to do it: If you want to have your man page available under the names `foo' and `bar' in section 1, then put the man page in foo.1 and have bar.1 look like this: .so man1/foo.1 It is important to specify the man1/ directory part as well as the file name `foo.1' because when groff is run by the browser it will have the manual base directory as its current working directory (cwd) and groff interprets .so arguments relative to the cwd. ---8>< --- However, there still is some detail I did not understand well enough; the additional line ``` .so man1/mdl.1 ``` in my file `/debian/markdownlint.1`[4] and followed by the call of ```shell sbuild -A -d unstable --source ``` yields for example the following warning ```shell ... Processing triggers for libc-bin (2.37-12) ... Running lintian... W: markdownlint: groff-message -:7: warning: failed .so request [usr/share/man/man1/markdownlint.1.gz:2] W: markdownlint: groff-message can't open man1/mdl.1: No such file or directory [usr/share/man/man1/markdownlint.1.gz:1] W: markdownlint: groff-message troff::7: error: can't open 'man1/mdl.1': No such file or directory [usr/share/man/man1/markdownlint.1.gz:3] W: markdownlint: no-manual-page [usr/bin/mdl] I: Lintian run was successful. +--+ | Post Build | +--+ ... ``` Regards, Norwid [1] https://tracker.debian.org/pkg/ruby-mdl [2] https://udd.debian.org/lintian/?packages=ruby-mdl [3] http://www.schweikhardt.net/man_page_howto.html#q4 [4] https://salsa.debian.org/nbehrnd/markdownlint_test/-/blob/master/debian/markdownlint.1
Re: Linking coreutils against OpenSSL
Hi, On 11/11/23 03:34, Julian Andres Klode wrote: 1) we use libgcrypt in libapt-pkg, which needs global initialization. Libraries should not be doing the initialization, we're basically misusing it. I remember that KiCad had problems with OpenSSL for this exact reason -- we were using libcurl from multiple threads from different plugins, and OpenSSL required us to initialize some locking mechanism from the KiCad main program so plugins could operate safely, breaking the abstraction. For this reason, KiCad had a direct dependency on OpenSSL for years, even if libcurl was provided by libcurl-gnutls -- can't know whether libcurl pulls in openssl, so we need to initialize it. We removed that code a while ago after the offending plugins were removed, and it seems the OpenSSL API has removed the CRYPTO_set_locking_functions call since then so there is a good chance that they've cleaned up a bit. There are still some globals, but mostly for malloc replacements, so I guess these can be ignored. Simon
main-dev
Hello, This is about evolving Debian further, for getting beyond a growing pain. In upstream sources are many libraries, crates, modules and such[0]. Those files are needed during development[1] and packaged for Debian for that reason. They are not needed for running the compiled program. What I want, is to explore if we put those libraries in a special corner of the Debian Package Archive, something like 'main-dev'. Having a different kind of packages means we can threat them differently. Which benefits will it bring? One such thing could be that multiple versions of same library exist. ( foo version 0.2 needing baz v0.3.4 and bar v2.0 needing baz v0.3.3 ) Actual goal I want to achieve (goal we Debian should want to achieve) is having various ways to improve the process of getting upstream development files into Debian. Yeah, currently I think it is too tedious to keep with the pace of upstream. What would be needed to catch-up? Regards Geert Stappers [0] to complete the list, additions welcome. [1] Also for building and reproducible rebuilding -- Silence is hard to parse
Re: main-dev
Le ven. 10 nov. 2023 à 22:22, Geert Stappers a écrit : > > Hello, > > > This is about evolving Debian further, for getting beyond a growing pain. > > > In upstream sources are many libraries, crates, modules and such[0]. > Those files are needed during development[1] and packaged for Debian > for that reason. They are not needed for running the compiled program. > > What I want, is to explore if we put those libraries in a special corner > of the Debian Package Archive, something like 'main-dev'. > > Having a different kind of packages means we can threat them differently. > Which benefits will it bring? > > One such thing could be that multiple versions of same library exist. > ( foo version 0.2 needing baz v0.3.4 and bar v2.0 needing baz v0.3.3 ) > > Actual goal I want to achieve (goal we Debian should want to achieve) is > having various ways to improve the process of getting upstream development > files into Debian. Yeah, currently I think it is too tedious to keep > with the pace of upstream. > > What would be needed to catch-up? > Automated updates, and automated crash bug reports (with statistics notifications).
Re: reference Debian package of multiple binaries sharing one man page
Am 10. November 2023 20:20:35 MEZ schrieb Norwid Behrnd : >Hello, > >I seek a maintained Debian package which provides multiple binaries sharing one >man page in common -- do you know an example? > faust mfh.her.fsr IOhannes
Re: Linking coreutils against OpenSSL
https://lists.debian.org/debian-arm/2021/06/msg1.html is the start of a thread about support for encryption in HW, which AFAIK uses the Crypto API. That's available on a number of arm64 devices. It may be useful to specify/detail a test so that people can (uniformly) test the performance on their devices (on various architectures). I did an OpenSSH/OpenSSL test, but I actually don't know if those were good tests. Still far from being an expert, but I was recently involved with testing a Crypto implementation for rk3566 (based) devices and noticed the results were rather mixed. It was much slower with 16 bytes, but significantly faster with 16384 bytes and the 'turnover' point was around 1024 bytes. In the discussion that followed, the point was made that HW-based Crypto would be much energy efficient and it would free up the CPU to do other things. So that could also be a factor that could be considered. Personally I don't have a problem with linking to OpenSSL, but I'm not a subject matter expert. HTH PS: The 'argument' wrt a certain package of Priority: important (not Essential) makes my blood boil, so this will likely be my only contribution to this thread. signature.asc Description: This is a digitally signed message part.
Re: Linking coreutils against OpenSSL
On Thu, Nov 09, 2023 at 11:13:51PM +, Luca Boccassi wrote: > > Alternatively, what would you think about making sha256sum etc. > > divertible and providing implementations both with and without the > > OpenSSL dependency? > > Please, no, no more diversion/alternatives/shenanigans, it's just huge > and convoluted complications for no real gain. Agreed, let's not. 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? - Ted
Re: Linking coreutils against OpenSSL
Hi, On 2023-11-09 07:31, Theodore Ts'o wrote: > 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? This idea seems appealing to me. In terms of costs vs benefits, adding OpenSSL to essential has a fairly high cost for unclear benefits. Costs, from Policy 3.8 [1]: "Maintainers should take great care in adding any programs, interfaces, or functionality to essential packages. Packages may assume that functionality provided by essential packages is always available without declaring explicit dependencies, which means that removing functionality from the Essential set is very difficult and is almost never done. Any capability added to an essential package therefore creates an obligation to support that capability as part of the Essential set in perpetuity." Can we quantify the benefits? Not in terms of artificial benchmarks, but real use cases if possible. [1] https://www.debian.org/doc/debian-policy/ch-binary.html#essential-packages
Re: main-dev
Am 10.11.23 um 22:21 schrieb Geert Stappers: What I want, is to explore if we put those libraries in a special corner of the Debian Package Archive, something like 'main-dev'. Having a different kind of packages means we can threat them differently. Which benefits will it bring? Hi Geert, There has been some discussion into that direction on a Debian bugreport [0], might be helpful to connect this discussion thread to that discussion. The bug report has not seen any activity for quite some time though. Regards, Wolfgang. [0] https://bugs.debian.org/949163
Re: reference Debian package of multiple binaries sharing one man page
On Fri, Nov 10, 2023 at 08:20:35PM +0100, Norwid Behrnd wrote: > Hello, > > I seek a maintained Debian package which provides multiple binaries sharing > one > man page in common -- do you know an example? devscripts - it links debchange.1 to dch.1 via debian/links (dh_link) $grep -r dch debian/links /usr/bin/debchange /usr/bin/dch -- tobi
Re: Linking coreutils against OpenSSL
On Sat, Nov 11, 2023 at 06:52:50AM +0100, Emanuele Rocca wrote: > Hi, > > On 2023-11-09 07:31, Theodore Ts'o wrote: > > 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? > > This idea seems appealing to me. > WRT dlopen(), this is never an appealing solution because you do not get any type-checking, you have to make sourceful changes for an soname bump. It is an interface you can use for loading plugins (that is, you should be in control of what the interface is that you are loading from the library object), but it's not really usable for stuff that is outside of your control. > In terms of costs vs benefits, adding OpenSSL to essential has a fairly > high cost for unclear benefits. > > Costs, from Policy 3.8 [1]: > > "Maintainers should take great care in adding any programs, interfaces, > or functionality to essential packages. Packages may assume that > functionality provided by essential packages is always available without > declaring explicit dependencies, which means that removing functionality > from the Essential set is very difficult and is almost never done. Any > capability added to an essential package therefore creates an obligation > to support that capability as part of the Essential set in perpetuity." > > Can we quantify the benefits? Not in terms of artificial benchmarks, but > real use cases if possible. > > [1] https://www.debian.org/doc/debian-policy/ch-binary.html#essential-packages I do not think this is a reasonable argument to make. While libraries are dependencies of Essential packages, they themselves are distinctively not Essential, they are pseudo-essential. The rules here don't apply to pseudo-essential library packages because quite frankly, they would have to apply to the specific soname because that is the provided interface. But since libraries frequently change their soname, they can't be considered subject to essential clauses because every soname bump, you'd be removing a package from the essential set and adding a new one to it. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en
