On Thu, Jan 14, 2021 at 07:03:37PM +0100, Kurt Roeckx wrote:
> There are a whole bunch of other issues and pull requests related to
> this. I hope this is the end of the regressions in the X509 code.
So there is something else now:
https://github.com/openssl/openssl/issues/13931
On Thu, Jan 14, 2021 at 07:03:37PM +0100, Kurt Roeckx wrote:
> There are a whole bunch of other issues and pull requests related to
> this. I hope this is the end of the regressions in the X509 code.
So there is something else now:
https://github.com/openssl/openssl/issues/13931
On Mon, Jan 25, 2021 at 09:42:14AM +0100, Miroslav Lichvar wrote:
> On Sun, Jan 24, 2021 at 01:45:34AM +0100, Kurt Roeckx wrote:
> > chronyc> selectdata
> > S Name/IP AddressAuth COpts EOpts Last Score
On Wed, Jan 20, 2021 at 10:15:17AM +0100, Miroslav Lichvar wrote:
> On Wed, Jan 20, 2021 at 10:03:57AM +0100, Karol Babioch wrote:
> > When I have something like this in my chrony.conf:
> >
> > > pool pool.example.com iburst maxsources 3
> >
> > Is NTS even possible in such a context? AFAIK only
On Tue, Jan 19, 2021 at 06:50:15PM +0100, Karol Babioch wrote:
> Hi,
>
> Am 19.01.21 um 18:18 schrieb Kurt Roeckx:
> > Using only the Let's Encrypt root CA is what you want to do.
> > The name in the certificate is checked against the hostname you've
> > put in the c
On Tue, Jan 19, 2021 at 04:51:39PM +0100, Karol Babioch wrote:
> Hi all,
>
> first of all let me thank you for being involved with the development
> and implementation of NTS. It's great to see NTS support in chrony!
>
> I'm still somewhat new to the topic, but read through the available
>
On 2021-01-19 11:02, Ramiro Muñoz wrote:
El martes, 19 de enero de 2021 a las 0:49:42 UTC+1, Matt Palmer escribió:
On Sun, Jan 17, 2021 at 12:51:29AM -0800, Ramiro Muñoz via dev-security-policy
wrote:
We don’t ask the community to disregard the data, on the contrary we ask
the community to
On Tue, Jan 19, 2021 at 10:55:28AM +0100, Agustin Martin wrote:
> One thing, do you know if processed vim dictionaries are arch:all?
I have no idea, but I assume it is.
Kurt
On Mon, Jan 18, 2021 at 07:34:55PM +0100, Agustin Martin wrote:
> > Note that I need to patch the .aff files to actually make it work
> > properly because vim doesn't implement all the same things
> > hunspell does.
>
> Knowing that vim does not use standard hunspell files makes things
> more
On Mon, Jan 18, 2021 at 01:22:48PM +0100, Agustin Martin wrote:
> El dom, 17 ene 2021 a las 16:06, Kurt Roeckx () escribió:
> >
> > Package: dictionaries-common-dev
> >
> > Hi,
> >
> > Vim has support for spellchecking using it's own spell check
> >
Package: dictionaries-common-dev
Hi,
Vim has support for spellchecking using it's own spell check
files. It can be generated based on hunspell .aff/.dic files, or
based on a wordlist. Files currently need to be placed in
/usr/share/vim/vim82/spell/
It would be good if we had a policy and helper
On Thu, Jan 14, 2021 at 09:13:49PM +0100, Sebastian Andrzej Siewior wrote:
> On 2021-01-14 19:03:37 [+0100], Kurt Roeckx wrote:
> > > Do you have pointers to upstream issues?
> >
> > There are a whole bunch of other issues and pull requests related to
> >
On Thu, Jan 14, 2021 at 09:13:49PM +0100, Sebastian Andrzej Siewior wrote:
> On 2021-01-14 19:03:37 [+0100], Kurt Roeckx wrote:
> > > Do you have pointers to upstream issues?
> >
> > There are a whole bunch of other issues and pull requests related to
> >
On Thu, Jan 14, 2021 at 09:13:49PM +0100, Sebastian Andrzej Siewior wrote:
> On 2021-01-14 19:03:37 [+0100], Kurt Roeckx wrote:
> > > Do you have pointers to upstream issues?
> >
> > There are a whole bunch of other issues and pull requests related to
> >
The branch master has been updated
via 8bbe05eafe1a554259e527f9ba3dd18e4b2e3a9a (commit)
from 89d554f676bdacf8497b41c8f2eae3b395bb2ff9 (commit)
- Log -
commit 8bbe05eafe1a554259e527f9ba3dd18e4b2e3a9a
Author: Kurt
On Thu, Jan 14, 2021 at 05:43:00PM +, Adam D. Barratt wrote:
> Hi,
>
> On Fri, 2021-01-08 at 23:59 +0100, Kurt Roeckx wrote:
> > On Fri, Jan 08, 2021 at 11:39:13PM +0100, Sebastian Andrzej Siewior
> > wrote:
> [...]
> > > The i release in unsta
On Thu, Jan 14, 2021 at 05:43:00PM +, Adam D. Barratt wrote:
> Hi,
>
> On Fri, 2021-01-08 at 23:59 +0100, Kurt Roeckx wrote:
> > On Fri, Jan 08, 2021 at 11:39:13PM +0100, Sebastian Andrzej Siewior
> > wrote:
> [...]
> > > The i release in unsta
On Thu, Jan 14, 2021 at 05:43:00PM +, Adam D. Barratt wrote:
> Hi,
>
> On Fri, 2021-01-08 at 23:59 +0100, Kurt Roeckx wrote:
> > On Fri, Jan 08, 2021 at 11:39:13PM +0100, Sebastian Andrzej Siewior
> > wrote:
> [...]
> > > The i release in unsta
On Fri, Jan 08, 2021 at 11:39:13PM +0100, Sebastian Andrzej Siewior wrote:
> On 2020-11-24 20:18:15 [+], Adam D. Barratt wrote:
>
> > At some point, could we please have a combined / single diff between
> > the current 1.1.1d-0+deb10u3 and the proposed 1.1.1h-0+deb10u1 (I
> > assume)?
>
>
On Fri, Jan 08, 2021 at 11:39:13PM +0100, Sebastian Andrzej Siewior wrote:
> On 2020-11-24 20:18:15 [+], Adam D. Barratt wrote:
>
> > At some point, could we please have a combined / single diff between
> > the current 1.1.1d-0+deb10u3 and the proposed 1.1.1h-0+deb10u1 (I
> > assume)?
>
>
On Fri, Jan 08, 2021 at 11:39:13PM +0100, Sebastian Andrzej Siewior wrote:
> On 2020-11-24 20:18:15 [+], Adam D. Barratt wrote:
>
> > At some point, could we please have a combined / single diff between
> > the current 1.1.1d-0+deb10u3 and the proposed 1.1.1h-0+deb10u1 (I
> > assume)?
>
>
On Fri, Jan 08, 2021 at 11:15:54AM +0100, Diederik de Haas wrote:
> Package: aspell-nl
> Version: 1:2.20.19-1
> Severity: normal
>
> Warning: The word "&" is invalid. The character '&' (U+26) may not appear at
> the beginning of a word. Skipping word.
[...]
> The 'aptitude safe-upgrade' finish
On Thu, Jan 07, 2021 at 09:31:17AM -0800, Aaron Gable wrote:
> In cases where we expect OpenSSL to be validating the chain, we expect that
> ISRG Root X1 is also in the trust store (unlike older versions of Android,
> where we know that it hasn't been added). As such, there will be two
>
On 2021-01-07 01:48, Aaron Gable wrote:
As mentioned in the blog post, and as we'll elaborate on further in an
upcoming post, one of the drawbacks of this arrangement is that there
actually is a class of clients for which chaining to an expired root
doesn't work: versions of OpenSSL prior to
On Tue, May 15, 2018 at 06:23:24PM +0200, Rene Engelhard wrote:
> # grep-dctrl -FBuild-Depends myspell-tools -sPackage
> # /var/lib/apt/lists/deb.debian.org_debian_dists_unstable_main_source_Sources
> Package: ifrench-gut
> Package: ispell-czech
> Package: norwegian
> Package: rus-ispell
That
On Tue, May 15, 2018 at 06:23:24PM +0200, Rene Engelhard wrote:
> # grep-dctrl -FBuild-Depends myspell-tools -sPackage
> # /var/lib/apt/lists/deb.debian.org_debian_dists_unstable_main_source_Sources
> Package: ifrench-gut
> Package: ispell-czech
> Package: norwegian
> Package: rus-ispell
That
reopen 977657
thanks
Hi,
The CI test still fails with 1.1.1i:
Testing package ssl:ssl
Script test_ssl.pl failed: Unknown message: exit(1)
% PL-Unit: ssl_options ... done
% PL-Unit: ssl_server . done
% PL-Unit: ssl_keys . done
% PL-Unit: ssl_certificates .
reopen 977657
thanks
Hi,
The CI test still fails with 1.1.1i:
Testing package ssl:ssl
Script test_ssl.pl failed: Unknown message: exit(1)
% PL-Unit: ssl_options ... done
% PL-Unit: ssl_server . done
% PL-Unit: ssl_keys . done
% PL-Unit: ssl_certificates .
On Fri, Dec 25, 2020 at 12:58:16PM +0100, Koos van den Hout wrote:
> > When I try to get a
> > time from it with date I get:
> >
> > $ rdate -npv 2001:980:14ca:2:123:123:123:123
> > rdate: Inconsistent times received from NTP server
> > rdate: Unable to get a reasonable time estimate
> >
> > Are
On Mon, Dec 21, 2020 at 05:58:55PM +0100, Michael Biebl wrote:
>
> Doing so now.
> If you feel comfortable sharing the above information via private
> email, you can send it to me directly. I'll promise to not disclose any
> information without your prior consent.
I can't reproduce it anymore
On Mon, Dec 21, 2020 at 05:58:55PM +0100, Michael Biebl wrote:
>
> Doing so now.
> If you feel comfortable sharing the above information via private
> email, you can send it to me directly. I'll promise to not disclose any
> information without your prior consent.
I can't reproduce it anymore
On Thu, Dec 24, 2020 at 07:34:10PM +0100, Rob Janssen wrote:
> Koos,
>
> I do have an IPv6-only server (that has been registered for quite some time)
> and it
> nicely sits at score 20.0
>
> So maybe there are routing issues towards that address or you have some
> firewall issue...
> (I cannot
Package: swi-prolog
Version: 8.2.3+dfsg-1
Severity: serious
Forwarded: https://github.com/SWI-Prolog/packages-ssl/issues/159
Tag: patch
Hi,
Swi-prolog is failing to build using OpenSSL 1.1.1i. I've attached
a patch that fixes it.
Kurt
--- packages/ssl/test_ssl.pl.orig 2020-12-18
Package: swi-prolog
Version: 8.2.3+dfsg-1
Severity: serious
Forwarded: https://github.com/SWI-Prolog/packages-ssl/issues/159
Tag: patch
Hi,
Swi-prolog is failing to build using OpenSSL 1.1.1i. I've attached
a patch that fixes it.
Kurt
--- packages/ssl/test_ssl.pl.orig 2020-12-18
Package: m2crypto
Version: 0.36.0-1
Severity: serious
Forwarded: https://gitlab.com/m2crypto/m2crypto/-/issues/289
Hi,
m2crypto is failing to build since the 1.1.1i version of OpenSSL,
see the upstream bug report for more details.
Kurt
Package: m2crypto
Version: 0.36.0-1
Severity: serious
Forwarded: https://gitlab.com/m2crypto/m2crypto/-/issues/289
Hi,
m2crypto is failing to build since the 1.1.1i version of OpenSSL,
see the upstream bug report for more details.
Kurt
On Tue, Dec 15, 2020 at 08:45:45AM +0100, Richard Levitte wrote:
> Whatever we decide on this, I would rather not burden provider authors
> with having to check for all sorts of things they aren't interested in.
I think you write the provider just a little bit different than
what you might be
On Tue, Dec 15, 2020 at 08:40:03AM +0100, Dmitry Belyavsky wrote:
>
> There are 2 variants of using OpenSSL.
> 1. Algorithm-agnostic. We can deal with most of the algorithms in a more or
> less similar way.
> That was the way we dealt with various algorithms in libcrypto since 1.0
> version.
>
>
On Mon, Dec 14, 2020 at 08:20:29PM +0100, Dmitry Belyavsky wrote:
> Dear Kurt,
>
>
> On Mon, Dec 14, 2020 at 3:59 PM Kurt Roeckx wrote:
>
> > Hi,
> >
> > doc/man3/OSSL_PARAM.pod current says:
> > Keys that a I or I doesn't recognise should
> > sim
Hi,
doc/man3/OSSL_PARAM.pod current says:
Keys that a I or I doesn't recognise should
simply be ignored. That in itself isn't an error.
The intention of that seems to be that you just pass all the data
you have, and that it takes data it needs. So you can pass it data
that it doesn't need
On Thu, Dec 10, 2020 at 05:14:00PM +0200, Cosmin Apreutesei wrote:
> Hello,
>
> I have a question regarding SSL_write() and returning SSL_ERROR_WANT_WRITE
> from the write callback.
>
> _After_ SSL_write() returns with SSL_ERROR_WANT_WRITE (because my write
> callback returned
On Fri, Dec 04, 2020 at 01:45:07PM +0100, Tomas Mraz wrote:
> topic: For 3.0 EVP_PKEY keys all algorithm implementations that were usable
>with 1.1.1 EVP_PKEY API or low level APIs without public component must
>stay usable.
>
>This overrules the
> * all
On Sat, Dec 05, 2020 at 02:13:32PM +0100, Matthias Klose wrote:
> Package: src:openssl
> Version: 1.1.1h-1
> Severity: serious
> Tags: sid bullseye patch
>
> Please backport https://github.com/openssl/openssl/pull/13585
>
> Without this patch, this causes python-asyncssh's tests to fail (and
On Sat, Dec 05, 2020 at 02:13:32PM +0100, Matthias Klose wrote:
> Package: src:openssl
> Version: 1.1.1h-1
> Severity: serious
> Tags: sid bullseye patch
>
> Please backport https://github.com/openssl/openssl/pull/13585
>
> Without this patch, this causes python-asyncssh's tests to fail (and
On Mon, Nov 30, 2020 at 02:03:15PM +0200, Nicola Tuveri wrote:
> Vote text
> -
>
> topic: In the context of the OpenSSL apps, the OTC qualifies as bug
>fixes the changes to return a failure exit status when a called
>function fails with an unhandled return value.
>
Hi,
I'm seeing dropped packets when talking to an NTS enabled server.
But I'm only seeing it on my home network, not on my server in the
datacenter. I currently see this using ptbnts1.ptb.de. I think I
had the same problem with nts.ntp.se, but it seems I changed from
an IPv4 address to an IPv6
On Mon, Nov 30, 2020 at 01:23:10PM +0100, Miroslav Lichvar wrote:
> > I currently need to change the permission of both /run/chrony and
> > /run/chrony/chronyd.sock to be able to access it from a non-root,
> > non-_chrony user.
>
> Would it work if /var/run/chrony had permissions 0775 and the
Hi,
I'm trying to generate graphs of the peers, and I would like to
use the ntpdata command to get to the variables. But it seems that
for some reason I'm unable to get to that data as a normal user.
The manpage says:
| Only the following monitoring commands, which do not affect the
| behaviour
On Sun, Nov 29, 2020 at 09:33:48PM +0100, Vincent Blut wrote:
> Control: tags -1 pending
>
> Le 2020-11-28T22:09+0100, Kurt Roeckx a écrit :
> > On Sat, Nov 28, 2020 at 07:54:05PM +0100, Vincent Blut wrote:
> > > Anyone willing to test the attached deb on Buster? FWIW, i
On Sat, Nov 28, 2020 at 07:54:05PM +0100, Vincent Blut wrote:
> Anyone willing to test the attached deb on Buster? FWIW, it seems to behave
> nicely on my VM.
It seems to be working fine for me.
I've enabled NTS on ntp.roeckx.be, both as client and server, and
both seem to be working fine.
It
On Fri, Nov 27, 2020 at 12:42:44PM +0100, Felix Bünemann wrote:
> Hi Kurt,
>
> > Am 26.11.2020 um 18:57 schrieb Kurt Roeckx :
> >
> > On Wed, Nov 25, 2020 at 09:17:13PM +0100, Felix Bünemann wrote:
> >>
> >> It is also unique cause it requires no co
On Fri, Oct 23, 2020 at 10:25:55PM +0200, Vincent Blut wrote:
> Hi Kurt,
>
> On 2020-10-22T13:58+0200, Kurt Roeckx wrote:
> > Package: chrony
> > Severity: wishlist
> >
> > Hi,
> >
> > Would it be possible to get chrony 4.0 in buster backports?
&
On Wed, Nov 25, 2020 at 09:17:13PM +0100, Felix Bünemann wrote:
>
> It is also unique cause it requires no code changes to support a new platform.
In a previous discussion we have talked about when a platform can
be added in an LTS release. I think that in general if it's only
configuration
On Tue, Nov 24, 2020 at 01:51:44PM +0200, Nicola Tuveri wrote:
> Background
> --
>
> This follows up on a [previous proposal] that was abandoned in favor of
> an OMC vote on the behavior change introduced in [PR#13359].
> Within today's OTC meeting this was further discussed with the
Package: rdiff-backup
Version: 2.0.5-1
Severity: important
Hi,
I recently found out that my backup has broken for months. It
seems that the version from testing doesn't want to talk to the
version from stable/buster.
It gives the following error:
Exception 'object.__new__(X): X is not a type
Package: gnupg
Version: 2.2.20-1
Hi,
When I do gnupg --export, I get the result in 0.3 seconds.
If I do --export --export-options export-minimal, it takes 14
seconds.
Kurt
On Tue, Nov 03, 2020 at 12:11:27PM +, Matt Caswell wrote:
>
> The proposal discussed was that while relaxing the conceptual model,
> most of the existing implementations would still require both. The EC
> implementation would be relaxed however. This essentially gives largely
> compatible
On Sun, Nov 15, 2020 at 07:25:59PM +0100, Vincent Blut wrote:
> Hi Kurt,
>
> On 2020-11-15T14:29+0100, Kurt Roeckx wrote:
> > Package: chrony
> > Version: 4.0-2
> > Severity: wishlist
> >
> > Hi,
> >
> > Could you please add the following line
On Sun, Nov 15, 2020 at 03:54:40PM +0100, Michael Biebl wrote:
> Am 15.11.20 um 15:26 schrieb Kurt Roeckx:
> > On Sun, Nov 15, 2020 at 02:43:52PM +0100, Michael Biebl wrote:
> > > You also mentioned, that this was logged directly to the console, instead
> > &
On Sun, Nov 15, 2020 at 03:54:40PM +0100, Michael Biebl wrote:
> Am 15.11.20 um 15:26 schrieb Kurt Roeckx:
> > On Sun, Nov 15, 2020 at 02:43:52PM +0100, Michael Biebl wrote:
> > > You also mentioned, that this was logged directly to the console, instead
> > &
On Sun, Nov 15, 2020 at 02:43:52PM +0100, Michael Biebl wrote:
> You also mentioned, that this was logged directly to the console, instead of
> just ending up in the journal, is this still the case?
Yes.
Kurt
On Sun, Nov 15, 2020 at 02:43:52PM +0100, Michael Biebl wrote:
> You also mentioned, that this was logged directly to the console, instead of
> just ending up in the journal, is this still the case?
Yes.
Kurt
Package: chrony
Version: 4.0-2
Severity: wishlist
Hi,
Could you please add the following line to the default chrony.conf
file:
leapsectz right/UTC
And add a Depends on tzdata, so that the timezone info is
available.
Kurt
reopen 971760
thanks
On Wed, Nov 11, 2020 at 08:53:53PM +0100, Michael Biebl wrote:
> Am Freitag, den 16.10.2020, 09:57 +0200 schrieb Kurt Roeckx:
> >
> > I'm using sysklogd.
>
> Given that sysklogd is no longer supported and available in the archive
> since a
reopen 971760
thanks
On Wed, Nov 11, 2020 at 08:53:53PM +0100, Michael Biebl wrote:
> Am Freitag, den 16.10.2020, 09:57 +0200 schrieb Kurt Roeckx:
> >
> > I'm using sysklogd.
>
> Given that sysklogd is no longer supported and available in the archive
> since a
On Tue, Nov 10, 2020 at 08:54:22PM +0100, László Böszörményi (GCS) wrote:
> On Fri, Nov 6, 2020 at 9:09 AM Michal Palenik wrote:
> > for those stumbling on this via searching, the workaround mentioned
> > above is:
> [...]
> > apt -t unstable install libssl1.1:amd64
> Thanks for possibly the
On Tue, Nov 10, 2020 at 08:54:22PM +0100, László Böszörményi (GCS) wrote:
> On Fri, Nov 6, 2020 at 9:09 AM Michal Palenik wrote:
> > for those stumbling on this via searching, the workaround mentioned
> > above is:
> [...]
> > apt -t unstable install libssl1.1:amd64
> Thanks for possibly the
On Wed, Nov 11, 2020 at 08:53:53PM +0100, Michael Biebl wrote:
> Hi Kurt
>
> Am Freitag, den 16.10.2020, 09:57 +0200 schrieb Kurt Roeckx:
> > On Thu, Oct 15, 2020 at 11:26:04PM +0200, Michael Biebl wrote:
> > > Am 06.10.20 um 23:36 schrieb Kurt Roeckx:
> > > >
On Wed, Nov 11, 2020 at 08:53:53PM +0100, Michael Biebl wrote:
> Hi Kurt
>
> Am Freitag, den 16.10.2020, 09:57 +0200 schrieb Kurt Roeckx:
> > On Thu, Oct 15, 2020 at 11:26:04PM +0200, Michael Biebl wrote:
> > > Am 06.10.20 um 23:36 schrieb Kurt Roeckx:
> > > >
Package: swi-prolog
Version: 8.2.1+dfsg-2
Severity: serious
Hi,
swi-prolog fails to build using OpenSSL 1.1.1h. See
https://ci.debian.net/data/autopkgtest/testing/amd64/s/swi-prolog/7715788/log.gz
for a log.
I've filed an upstream bug about this at:
Package: swi-prolog
Version: 8.2.1+dfsg-2
Severity: serious
Hi,
swi-prolog fails to build using OpenSSL 1.1.1h. See
https://ci.debian.net/data/autopkgtest/testing/amd64/s/swi-prolog/7715788/log.gz
for a log.
I've filed an upstream bug about this at:
--- Begin Message ---
Hello,
Part of the test suite for src:gromacs launches a MPI process that
connects to localhost. On the recently (?) added buildd x86-conova-01
*only*, this fails:
2: Test command: /usr/bin/mpiexec.mpich "-np" "2" "-host" "localhost"
Package: chrony
Severity: wishlist
Hi,
Would it be possible to get chrony 4.0 in buster backports?
Kurt
Hi,
It seems that we might start to interprete the no-xxx options
differently. In 1.1.1 it would completly disable the feature in
libcrypto, the apps and libssl. It seems that now the
interpretation changed to just disable the support for it in the
provider. You might load a different provider
On Thu, Oct 15, 2020 at 11:26:04PM +0200, Michael Biebl wrote:
> Am 06.10.20 um 23:36 schrieb Kurt Roeckx:
> > On Tue, Oct 06, 2020 at 10:57:12PM +0200, Michael Biebl wrote:
> >> Am 06.10.20 um 22:53 schrieb Kurt Roeckx:
> >>
> >>> What I all mentioned in m
On Thu, Oct 15, 2020 at 11:26:04PM +0200, Michael Biebl wrote:
> Am 06.10.20 um 23:36 schrieb Kurt Roeckx:
> > On Tue, Oct 06, 2020 at 10:57:12PM +0200, Michael Biebl wrote:
> >> Am 06.10.20 um 22:53 schrieb Kurt Roeckx:
> >>
> >>> What I all mentioned in m
On Fri, Oct 09, 2020 at 02:02:29PM +0200, Tomas Mraz wrote:
> topic: The PR #11359 (Allow to continue with further checks on
> UNABLE_TO_VERIFY_LEAF_SIGNATURE) is acceptable for 1.1.1 branch
> As the change is borderline on bug fix/behaviour change OTC needs
> to decide whether it is acceptable
On Thu, Oct 08, 2020 at 03:47:18PM +0100, Matt Caswell wrote:
> topic: The following items are required prerequisites for the first beta
> release:
> 1) EVP is the recommended API, it must be feature-complete compared with
> the functionality available using lower-level APIs.
>- Anything
The branch master has been updated
via 47690cd4ceb3a1cfdf097d575cb0d3cf9c6dac13 (commit)
from 8e596a93bc266259f1ef0d56601e58bbfe18317a (commit)
- Log -
commit 47690cd4ceb3a1cfdf097d575cb0d3cf9c6dac13
Author: Kurt
On Fri, Oct 09, 2020 at 03:00:00PM +0300, Nicola Tuveri wrote:
> topic: Hold online weekly OTC meetings starting on Tuesday 2020-10-13
>and until 3.0 beta1 is released, in lieu of the weekly "developer
>meetings".
+1
Kurt
On Wed, Oct 07, 2020 at 12:35:28PM +0100, Matt Caswell wrote:
> The following items are required prerequisites for the first beta release:
[...]
> * Address 3.0beta1 milestones.
So we now have a list here, with the last item pointing to a
different list. I suggest that we only have 1 list, and
On Wed, Oct 07, 2020 at 12:29:10PM +0100, Matt Caswell wrote:
> Issue #12612 exposes a problem with how we handle keys that contain
> private components but not public components.
>
> There is a widespread assumption in the code that keys with private
> components must have public components.
On Tue, Oct 06, 2020 at 10:57:12PM +0200, Michael Biebl wrote:
> Am 06.10.20 um 22:53 schrieb Kurt Roeckx:
>
> > What I all mentioned in my initial email:
> > - It gets logged to the kernel and console.
>
> I can't reproduce that. Do you have some custom syslog configurat
On Tue, Oct 06, 2020 at 10:57:12PM +0200, Michael Biebl wrote:
> Am 06.10.20 um 22:53 schrieb Kurt Roeckx:
>
> > What I all mentioned in my initial email:
> > - It gets logged to the kernel and console.
>
> I can't reproduce that. Do you have some custom syslog configu
On Tue, Oct 06, 2020 at 10:57:12PM +0200, Michael Biebl wrote:
> Am 06.10.20 um 22:53 schrieb Kurt Roeckx:
>
> > What I all mentioned in my initial email:
> > - It gets logged to the kernel and console.
>
> I can't reproduce that. Do you have some custom syslog configu
On Tue, Oct 06, 2020 at 10:33:29PM +0200, Michael Biebl wrote:
> Am 06.10.20 um 22:25 schrieb Kurt Roeckx:
> > On Tue, Oct 06, 2020 at 07:12:03PM +0200, Michael Biebl wrote:
> >> Control: tags -1 + moreinfo
> >>
> >> Is this a duplicate of
> >> http
On Tue, Oct 06, 2020 at 10:33:29PM +0200, Michael Biebl wrote:
> Am 06.10.20 um 22:25 schrieb Kurt Roeckx:
> > On Tue, Oct 06, 2020 at 07:12:03PM +0200, Michael Biebl wrote:
> >> Control: tags -1 + moreinfo
> >>
> >> Is this a duplicate of
> >> http
On Tue, Oct 06, 2020 at 07:12:03PM +0200, Michael Biebl wrote:
> Control: tags -1 + moreinfo
>
> Is this a duplicate of
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968116 ?
I looked at that, and at first sight it looked like something
else.
Kurt
Package: systemd
Version: 246.6-1
Hi,
After I log in as root on the console, I get the following message
on the console:
[ 75.568505] systemd-xdg-autostart-generator[1481]: Not generating service
for XDG autostart app-gsettings\x2ddata\x2dconvert-autostart.service, startup
phases are not
Package: systemd
Version: 246.6-1
Hi,
After I log in as root on the console, I get the following message
on the console:
[ 75.568505] systemd-xdg-autostart-generator[1481]: Not generating service
for XDG autostart app-gsettings\x2ddata\x2dconvert-autostart.service, startup
phases are not
On Wed, Sep 23, 2020 at 08:51:28PM +0200, Kurt Roeckx wrote:
> Hi,
>
> I would like to have a system so that we can tag issues as
> important. But I think they fall in a few categories:
> - Features for the next minor/major release (so 3.1 or 4.0)
> that we find important.
On Sun, Oct 04, 2020 at 02:55:11PM +0200, Paul Slootman wrote:
> On Sat 03 Oct 2020, Kurt Roeckx wrote:
> > On Sat, Oct 03, 2020 at 02:08:54PM +0200, Paul Slootman wrote:
> > > On Sat 03 Oct 2020, Kurt Roeckx wrote:
> > > >
> > > > I was transfering a lar
On Sat, Oct 03, 2020 at 02:08:54PM +0200, Paul Slootman wrote:
> On Sat 03 Oct 2020, Kurt Roeckx wrote:
> >
> > I was transfering a large file using rsync (3 TB). The connection
> > broke after about 1 TB. I was using the -P option. So I restarted
> > the transfer.
Package: rsync
Version: 3.1.3-6
Hi,
I was transfering a large file using rsync (3 TB). The connection
broke after about 1 TB. I was using the -P option. So I restarted
the transfer. But that transfer resulted in 100% CPU usage on the
sender side, and limiting the transfer to about 1.5 MB/s.
It
On Wed, Sep 30, 2020 at 01:57:34PM +, Dr. Matthias St. Pierre wrote:
> topic: OTC meeting will be called for next Tuesday
+1, but wondering why this needs a vote.
Kurt
On Mon, Sep 28, 2020 at 12:02:07PM +, Dr. Matthias St. Pierre wrote:
> topic: Accept the OTC voting policy as defined:
>
>The proposer of a vote is ultimately responsible for updating the
> votes.txt
>file in the repository. Outside of a face to face meeting, voters
> MUST
On Thu, Sep 24, 2020 at 12:33:56PM +1000, Dr Paul Dale wrote:
> I’m seeing quite a bit of activity going on which isn’t related to the
> 3.0beta1 milestone.
> We’re well past the cutoff date announced for new features in the code.
>
> Should we be limiting the “new” stuff going in?
>
> I’m fine
Hi,
I would like to have a system so that we can tag issues as
important. But I think they fall in a few categories:
- Features for the next minor/major release (so 3.1 or 4.0)
that we find important. I've created a new milestone for that:
https://github.com/openssl/openssl/milestone/18 (Post
On Thu, Sep 17, 2020 at 06:49:19PM +0200, Kurt Roeckx wrote:
> - It doesn't go into 3.0. No idea what the best way to tag them
> is.
So I've created a "Post 3.0.0" milestone for that.
Kurt
Author: olszomal
Date: Fri Jun 19 15:00:32 2020 +0200
Add const to 'ppin' function parameter
CLA: trivial
Reviewed-by: Kurt Roeckx
Reviewed-by: Matt Caswell
GH: #12205
(cherry picked from commit 434343f896a2bb3e5857cc9831c38f8cd1cceec1
401 - 500 of 14770 matches
Mail list logo
