On Thu, Jul 30, 2020 at 08:25:16AM +0500, ??? wrote:
> > EXTRA_OBJS="contrib/prometheus-exporter/service-prometheus.o" CC=clang-9
> > > +name: libressl-2.9.2 | prometheus-exporte
> >
> > I guess this was "prometheus-exporter" above (missing "r") ?
> >
>
> oops.
> can you please fix
чт, 30 июл. 2020 г. в 07:48, Willy Tarreau :
> Hi Ilya,
>
> thanks for this. Two minor comments (just let me know, I can adjust
> the patches before merging them if you confirm):
>
> >- os: linux
> > if: type == cron
> > compiler: clang
> > env: TARGET=linux-glibc
Hi Ilya,
thanks for this. Two minor comments (just let me know, I can adjust
the patches before merging them if you confirm):
>- os: linux
> if: type == cron
> compiler: clang
> env: TARGET=linux-glibc LIBRESSL_VERSION=2.9.2
>
Hello,
I did not like SSL_LIB, SSL_INC after arm64 switched to stock lib (in an
ugly way).
let us make stock lib first class citizen.
Cheers,
Ilya Shipitcin
From 6ff056e7ded7784fcb4020ea8f37b12b23c855b6 Mon Sep 17 00:00:00 2001
From: Ilya Shipitsin
Date: Thu, 30 Jul 2020 01:47:55 +0500
On Wed, Jul 29, 2020 at 10:22:33PM +0500, Илья Шипицин wrote:
> Tim,
>
> there's also gitlab official mirror (ran by William)
> https://gitlab.com/haproxy.org/haproxy
>
>
> in theory we can use gitlab-ci as well :)
>
I don't want this to be considered an "official" mirror, I deliberately
ср, 29 июл. 2020 г. в 22:33, Tim Düsterhus :
> Ilya,
>
> Am 29.07.20 um 19:05 schrieb Илья Шипицин:
> >> Known issues:
> >> - Apparently the git commit is not properly detected during build. The
> HEAD
> >> currently shows as 2.3-dev1.
> >>
> >
> > there's something wrong with git checkout (or
Hello,
On Wed, 29 Jul 2020 at 19:19, Илья Шипицин wrote:
> however, ZLIB is enabled by default in many distros and docker images.
> any idea why ZLIB is chosen by default ?
Because zlib is known, packaged and used everywhere and by everyone
while slz is a niche library. It would need a
Ilya,
Am 29.07.20 um 19:05 schrieb Илья Шипицин:
>> Known issues:
>> - Apparently the git commit is not properly detected during build. The HEAD
>> currently shows as 2.3-dev1.
>>
>
> there's something wrong with git checkout (or the way we use it)
>
> have a look (do not ask me why, I've no
ср, 29 июл. 2020 г. в 22:27, Tim Düsterhus :
> Ilya,
>
> Am 29.07.20 um 19:22 schrieb Илья Шипицин:
> > there's also gitlab official mirror (ran by William)
> > https://gitlab.com/haproxy.org/haproxy
> >
> >
> > in theory we can use gitlab-ci as well :)
> >
>
> Please no more external services!
Ilya,
Am 29.07.20 um 18:55 schrieb Илья Шипицин:
>> +for ssl in [
>> + "stock",
>> + "OPENSSL_VERSION=1.0.2u",
>> + "OPENSSL_VERSION=1.1.0l",
>> + "OPENSSL_VERSION=1.1.1f",
>> + "LIBRESSL_VERSION=2.9.2",
>> +
Ilya,
Am 29.07.20 um 19:22 schrieb Илья Шипицин:
> there's also gitlab official mirror (ran by William)
> https://gitlab.com/haproxy.org/haproxy
>
>
> in theory we can use gitlab-ci as well :)
>
Please no more external services! I've specifically reimplemented the
Travis tests in GitHub
Ilya,
Am 29.07.20 um 18:58 schrieb Илья Шипицин:
> generally, there was an idea of keeping "developer velocity" as high as
> possible.
> i.e. to perform check in 3-5 min after the push.
>
> Github Actions allows 4 parallel builds (same as Travis CI), I thought of
> moving some builds to GH
Tim,
there's also gitlab official mirror (ran by William)
https://gitlab.com/haproxy.org/haproxy
in theory we can use gitlab-ci as well :)
ср, 29 июл. 2020 г. в 21:49, Tim Duesterhus :
> Travis is becoming overall increasingly unreliable lately. We've already
> seen that the timing sensitive
Hello,
I am running pretty big LB installation with http compression and SSL
termination enabled.
I was very surprised that 70-80% of cpu is spent on "gzip". Also, I found
that SLZ is much better than ZLIB in terms of cpu usage.
however, ZLIB is enabled by default in many distros and docker
ср, 29 июл. 2020 г. в 21:49, Tim Duesterhus :
> Travis is becoming overall increasingly unreliable lately. We've already
> seen that the timing sensitive tests regularly fail and thus they were
> disabled.
>
> GitHub Actions VMs are working well, possibly allowing to use custom
> runners
> for
generally, there was an idea of keeping "developer velocity" as high as
possible.
i.e. to perform check in 3-5 min after the push.
Github Actions allows 4 parallel builds (same as Travis CI), I thought of
moving some builds to GH actions.
also, that was a reason to move some rare configurations
ср, 29 июл. 2020 г. в 21:49, Tim Duesterhus :
> Travis is becoming overall increasingly unreliable lately. We've already
> seen that the timing sensitive tests regularly fail and thus they were
> disabled.
>
> GitHub Actions VMs are working well, possibly allowing to use custom
> runners
> for
Ilya,
List,
Am 29.07.20 um 18:49 schrieb Tim Duesterhus:
> [long snip]
You can find an example run of that GitHub Action workflow here:
https://github.com/TimWolla/haproxy/actions/runs/187396816
I've attached a screenshot of how nice it looks in the commit overview
compared to Travis.
The
Travis is becoming overall increasingly unreliable lately. We've already
seen that the timing sensitive tests regularly fail and thus they were
disabled.
GitHub Actions VMs are working well, possibly allowing to use custom runners
for special tasks in the future.
In addition to this better
Hello,
On Wed, 29 Jul 2020 at 11:16, Froehlich, Dominik
wrote:
>
> Hi Lukas,
>
> Thanks for the reply.
> My query goes along the lines of which Lua version is compatible with HAproxy
> and contains fixes to those CVEs.
> I could not find a specific instruction as to which Lua version can be
On Tue, Jul 28, 2020 at 02:58:57PM +0200, Baptiste wrote:
> Hi Jerome,
>
> Thanks a lot for the debugging and the fix.
> This is all good and can be applied.
Great, patch applied then. Thanks guys!
Willy
Patch applied, thanks guys!
Willy
On 7/29/20 11:16 AM, Froehlich, Dominik wrote:
Hi Lukas,
Thanks for the reply.
My query goes along the lines of which Lua version is compatible with HAproxy
and contains fixes to those CVEs.
I could not find a specific instruction as to which Lua version can be used to
build HAproxy / has
Hi Lukas,
Thanks for the reply.
My query goes along the lines of which Lua version is compatible with HAproxy
and contains fixes to those CVEs.
I could not find a specific instruction as to which Lua version can be used to
build HAproxy / has been tested for production use.
We are consuming a
Hello,
On Wed, 29 Jul 2020 at 10:23, Froehlich, Dominik
wrote:
>
> Hello everyone,
>
> Not sure if this is already addressed. Today I got a CVE report of several
> issues with Lua 5.3.5 up to 5.4.
>
> I believe Lua 5.4 is currently recommended to build with HAproxy 2.x?
>
> Before I open an
Hello haproxy.com
We are a web development company, with goals in harnessing our client's
online presence by making well structured and up to date websites and
mobile applications for them to explore more into the online business world.
If you have a website, we would like to do a first free
Hello everyone,
Not sure if this is already addressed. Today I got a CVE report of several
issues with Lua 5.3.5 up to 5.4.
I believe Lua 5.4 is currently recommended to build with HAproxy 2.x?
Before I open an issue on github I would like to ask if these are already known
/ addressed:
Lua
27 matches
Mail list logo
