Thanks for cooperation Chriss. I hope that there will be no
further complications.
On Tue, Sep 15, 2020 at 3:28 PM Chris Lamb wrote:
> Hi Tomas,
>
> > I believe it is a race condition because most issues with this suite are.
> > I created vm with 4 virtual cpus and unstable debian to simulate
Hi Tomas,
> I believe it is a race condition because most issues with this suite are.
> I created vm with 4 virtual cpus and unstable debian to simulate your
> environment but again the suite did not hang. Can you please change
> the "-j" options value passed to make to 1?
I just tried this and
Hi Chris,
I believe it is a race condition because most issues with this suite are.
I created vm with 4 virtual cpus and unstable debian to simulate your
environment but again the suite did not hang. Can you please change
the "-j" options value passed to make to 1?
I want to check if this is
Hi Tomas,
> debian unstable. But unfortunately i do not have a powerful
> debian machine so maybe i do not encounter some race condition
> that you do.
(Out of interest, why do you believe it is a race condition?)
Regards,
--
,''`.
: :' : Chris Lamb
`. `'`
You are right. It was not tested the same way as you do it,
but still i think that tls tests were executed for reasons which
are unrelated to this issue. I reproduced your test log bug i'm
still not encountering any issue on Fedora-rawhide neither
debian unstable. But unfortunately i do not have a
Hi Tomas,
> I can show you a test log from Fedora Rawhide where we have 1.6.7.
> https://tkorbar.fedorapeople.org/test.log
Thanks. Replying quickly, but I notice that "your" log does not say:
Running basic tests with TLS
This comes from upstream's Makefile.am. Are you sure you are building
Hi Chriss,
I'm the maintainer of memcached on Fedora and RHEL,
On Thu, 10 Sep 2020 22:58:03 - "Chris Lamb"
wrote:
> Hi Moises,
>
> > We run the tests afterward on a dedicated machine..
>
> The question here is not when or where these tests are run - can you
> reproduce these test failures at
Hi Moises,
> We run the tests afterward on a dedicated machine..
The question here is not when or where these tests are run - can you
reproduce these test failures at all on this other machine? I can
reproduce them locally here (NB. with TLS enabled during the build).
If you can/cannot, sharing
Hi Chris,
This is what I got from our side with the engineering team who takes care
of memcached on RHEL.
... the "Signal handled: Terminated." is a standard part of memcacheds test
suite log. Memcached is tested during build for its ability to respond to
multiple signals...
...we do not run
Hi Moises,
> memcached should enable TLS by default
I released this in memcached version 1.6.6-2. However, I continue to
experience a number of build failures. For example:
https://buildd.debian.org/status/fetch.php?pkg=memcached=amd64=1.6.7%2Bdfsg-1=1599310749=0
NB. the "Signal handled:
Package: memcached
Version: 1.6.6-1
Memcached supports TLS since version 1.5.13, but that has not been enabled
yet for this package.
More information about memcached with TLS:
https://github.com/memcached/memcached/wiki/TLS
Deployments of Memcached in cloud environments may need to encrypting
11 matches
Mail list logo
