I think perhaps that we should be more selective in the certs we add to
ca-certificates.crt. Debian has a configuration file
/etc/ca-certificates.conf, and only adds certificates that are
explicitly listed there to ca-certificates.crt.
Several of the certs in /etc/ssl/certs have comments like thi
Mark H Weaver skribis:
> Paul van der Walt writes:
>
>> * gnu/packages/pdf.scm (djvulibre): New variable.
>> ---
>> gnu/packages/pdf.scm | 20
>> 1 file changed, 20 insertions(+)
>
> The package looks good, but I'm not sure it belongs in pdf.scm. Maybe
> the answer is to r
On Tue, Mar 03, 2015 at 03:27:57AM -0500, Mark H Weaver wrote:
> I think perhaps that we should be more selective in the certs we add to
> ca-certificates.crt. Debian has a configuration file
> /etc/ca-certificates.conf, and only adds certificates that are
> explicitly listed there to ca-certifica
Federico Beffa skribis:
> l...@gnu.org (Ludovic Courtès) writes:
>
>>> +(substitute* (list "testsuite/timeout/Makefile"
>>> + "testsuite/timeout/timeout.py"
>>> + "testsuite/timeout/timeout.hs"
>>> +
Mark H Weaver skribis:
> I think perhaps that we should be more selective in the certs we add to
> ca-certificates.crt. Debian has a configuration file
> /etc/ca-certificates.conf, and only adds certificates that are
> explicitly listed there to ca-certificates.crt.
Based on what you write, I a
On 2015-03-03 at 13:19, quoth Ludovic Courtès:
> Mark H Weaver skribis:
>
>> Paul van der Walt writes:
>>
>>> * gnu/packages/pdf.scm (djvulibre): New variable.
>>> ---
>>> gnu/packages/pdf.scm | 20
>>> 1 file changed, 20 insertions(+)
>>
>> The package looks good, but I'm
Mark H Weaver skribis:
> l...@gnu.org (Ludovic Courtès) writes:
>
>> Mark H Weaver skribis:
>>
>>> In order to support multiple packages containing CA certs, it would be
>>> good to handle creation of the single-file cert bundle in the profile
>>> generation code, analogous to our handling of in
On Tue, Mar 03, 2015 at 01:43:38PM +0100, Ludovic Courtès wrote:
> I just checked the source and OpenSSL itself does not use SSL_CERT_FILE
> nor SSL_CERT_DIR at all. Lynx does use SSL_CERT_FILE, but that’s really
> in Lynx, not in libssl. So I don’t think there should be a search path
> specifica
l...@gnu.org (Ludovic Courtès) writes:
>> - It tries to find libid3tag and libmad via pkg-config even though they
>> don't install .pc files. Perhaps we can generate them manually in the
>> install phase of those packages, or maybe they just don't get
>> installed due to a bug. Perhaps the
l...@gnu.org (Ludovic Courtès) writes:
> I’ve applied it locally and will push shortly.
It might be too late, but I have a nitpick on my macro: the implicit
quoting of phase names 1. makes it impossible to provide them
dynamically (e.g. procedure argument), 2. might give an illusion that
they're
l...@gnu.org (Ludovic Courtès) writes:
> Mark H Weaver skribis:
>
>> I think perhaps that we should be more selective in the certs we add to
>> ca-certificates.crt. Debian has a configuration file
>> /etc/ca-certificates.conf, and only adds certificates that are
>> explicitly listed there to ca-
Mark H Weaver skribis:
> Fedora's system for handling CA certificates seems to be vastly more
> sophisticated than Debian's. All of the single-file bundles are
> considered "legacy", and Fedora is able to produce multiple bundles
> containing certs trusted for different purposes.
>
> Doing this
Andreas Enge skribis:
> privat@debian:/tmp/openssl-1.0.2$ find -type f -exec grep -H SSL_CERT_FILE {}
> \;
> ./crypto/cryptlib.h:# define X509_CERT_FILE_EVP "SSL_CERT_FILE"
Indeed, I stand corrected.
And Lynx does fiddle with it, but only when built with GnuTLS:
#ifdef USE_GNUTLS_INCL
taylanbayi...@gmail.com (Taylan Ulrich "Bayırlı/Kammer") skribis:
> l...@gnu.org (Ludovic Courtès) writes:
>
>>> - It tries to find libid3tag and libmad via pkg-config even though they
>>> don't install .pc files. Perhaps we can generate them manually in the
>>> install phase of those package
taylanbayi...@gmail.com (Taylan Ulrich "Bayırlı/Kammer") skribis:
> l...@gnu.org (Ludovic Courtès) writes:
>
>> I’ve applied it locally and will push shortly.
>
> It might be too late, but I have a nitpick on my macro: the implicit
> quoting of phase names 1. makes it impossible to provide them
>
Hello!
I’m considering applying this so that Bash completions would work
out-of-the-box. Apparently handling of completions is not fully
standardized; this approach is based on the suggestions of the
‘bash-completion’ package on one hand the the Bash manual on the other.
Thoughts?
Thanks,
Ludo’
l...@gnu.org (Ludovic Courtès) writes:
> Sorry for not being clear: I think we should avoid diverging from
> upstream in this way, especially if there’s just one package that makes
> the incorrect assumption. So I would rather not add those .pc files.
All clear. (No worries; it was my idea to c
l...@gnu.org (Ludovic Courtès) writes:
> I actually agree. Well, next round?
If you want. :-) I thought it might be too much to have a second commit
that touches all recipes where 'modify-phases' is used, but maybe I'm
being too pedantic.
> In think Guile 2.1 is standards-compliant in that resp
Mark H Weaver writes:
>> From dbf194fdfd5baf9b79ebc7ba3c60835421cce12a Mon Sep 17 00:00:00 2001
>> From: Ricardo Wurmus
>> Date: Sun, 1 Mar 2015 13:35:06 +0100
>> Subject: [PATCH 1/2] gnu: Add clalsadrv.
>>
>> * gnu/packages/audio.scm (clalsadrv): New variable.
>> ---
>> gnu/packages/audio.scm
Ricardo Wurmus writes:
> The problem here is that the library is not installed to /lib, but to
> /lib64 or /libmips64. I'll see if I can coerce it to install the
> library to /lib on all platforms.
zita-alsa-pcmi has the very same problem. I'll take care of both of
them.
~~ Ricardo
20 matches
Mail list logo
