PU request sent!
https://bugs.debian.org/852040
Thanks again,
Michael
On 01/18/2017 03:25 PM, Adrian Bunk wrote:
> after a discussion with someone who ran into this bug in stable I have
> set the severity to serious, since this should IMHO also be fixed in
> stable.
This does look like a good patch to backport to stable. I'll get this
commited to git and work on
Hi,
after a discussion with someone who ran into this bug in stable I have
set the severity to serious, since this should IMHO also be fixed in
stable.
It is a very nasty bug when something works on the first execution of
a command but not on subsequent executions, and the fix looks really
Control: tags -1 + pending
Committed to master for next upload. Thanks, Daniel!
--
Kind regards,
Michael
Thank you for the details.
On 04/30/2015 02:41 AM, Daniel Lutz wrote:
The hooks in /etc/ca-certificates/update.d are called to re-add/
update/replace certificates in $CERTSDIR, but not for those in
$LOCALCERTSDIR. Is this intended behaviour?
It seems that this has just never come up, so it
For example, the file /etc/ssl/certs/java/cacerts, managed by
the package ca-certificates-java, won't be re-created correctly
if it was removed before.
The cacerts keystore was removed? Removed by what?
I actually manually removed /etc/ssl/java/cacerts myself.
I tried to force the
Package: ca-certificates
Version: 20141019
Tags: patch
If update-ca-certificates is called with the --fresh option,
it doesn't correctly re-add certificates in
/usr/local/share/ca-certificates. These are ignored.
Although /etc/ssl/certs/ca-certificates.crt is re-created
correctly, extension
On 04/28/2015 07:26 AM, Daniel Lutz wrote:
If update-ca-certificates is called with the --fresh option,
it doesn't correctly re-add certificates in
/usr/local/share/ca-certificates. These are ignored.
They are not ignored. If they exist, they are trusted. Period.
Although
8 matches
Mail list logo
