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 Open
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 debia
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,
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
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 hu
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
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
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
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.
Wh
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 usin
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-
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://ww
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 algori
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
function
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.
> >> > Whethe
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 tra
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
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 architect
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 arch
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 on
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 mino
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.
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 thing
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 : Th
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
Descri
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
> >> undesirab
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
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 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
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
30 matches
Mail list logo
