Re: do we want to keep CentOS 6 builds?

2020-11-15 Thread John Lauro 
CentOS 6 isn't EOL until the end of the month, so there is a couple of more
weeks left.

There is at least one place to pay for support through 2024.
($3/month/server)

Might be good to keep for a a bit past EOL, as I know when migrating
services sometimes I'll throw a proxy server on the old server to the new
one...  and there will likely be some that don't make the Nov 30th deadline
to retire all Centos 6 servers.


On Sun, Nov 15, 2020 at 11:15 AM Илья Шипицин  wrote:

> Hello,
>
> we still run cirrus-ci builds.
> CentOS 6 is EOL.
>
> should we drop it?
>
> Ilya
>

Re: [PATCH] remote couple of travis jobs (migrated to github actions), unmark arm64 as allowed to fail

2020-11-15 Thread Илья Шипицин 
One of those jobs uses ERR=
I keep an eye on them:) will remove them sometimes

On Sun, Nov 15, 2020, 11:16 PM Tim Düsterhus  wrote:

> Ilya,
>
> Am 11.11.20 um 19:18 schrieb Илья Шипицин:
> > Hi,
> >
> > some travis-ci cleanup.
> >
> > Ilya
> >
>
> I believe these can be removed as well, can't they?
>
>   - os: linux
> if: type == push
> compiler: clang
> env: TARGET=linux-glibc LIBRESSL_VERSION=3.1.1 CC=clang-9
> name: libressl-3.1.1
>   - os: linux
> env: DEBUG_OPTIONS=""
> if: type == cron
> compiler: clang
> env: TARGET=linux-glibc LIBRESSL_VERSION=3.0.2 CC=clang-9
> name: libressl-3.0.2 | ERR=
>   - os: linux
> if: type == push
> compiler: clang
> env: TARGET=linux-glibc FLAGS= CC=clang-9
> name: FLAGS=
>   - os: linux
> if: type == cron
> compiler: clang
> env: TARGET=linux-glibc FLAGS="USE_SLZ=1 USE_PCRE2=1 USE_PCRE2_JIT=1
> USE_LUA=1 USE_OPENSSL=1 USE_SYSTEMD=1 USE_WURFL=1
> WURFL_INC=contrib/wurfl WURFL_LIB=contrib/wurfl USE_51DEGREES=1" CC=clang-9
> before_script:
>   - git clone https://github.com/wtarreau/libslz
>   - cd libslz && make && make PREFIX=${HOME}/opt install && cd ..
>   - export SLZ_INC=${HOME}/opt/include SLZ_LIB=${HOME}/opt/lib
>   - export ADDLIB="-Wl,-rpath,$SLZ_LIB"
> name: openssl-1.1.1 | slz | pcre2
>
> Best regards
> Tim Düsterhus
>

Re: [PATCH] remote couple of travis jobs (migrated to github actions), unmark arm64 as allowed to fail

2020-11-15 Thread Tim Düsterhus 
Ilya,

Am 11.11.20 um 19:18 schrieb Илья Шипицин:
> Hi,
> 
> some travis-ci cleanup.
> 
> Ilya
> 

I believe these can be removed as well, can't they?

  - os: linux
if: type == push
compiler: clang
env: TARGET=linux-glibc LIBRESSL_VERSION=3.1.1 CC=clang-9
name: libressl-3.1.1
  - os: linux
env: DEBUG_OPTIONS=""
if: type == cron
compiler: clang
env: TARGET=linux-glibc LIBRESSL_VERSION=3.0.2 CC=clang-9
name: libressl-3.0.2 | ERR=
  - os: linux
if: type == push
compiler: clang
env: TARGET=linux-glibc FLAGS= CC=clang-9
name: FLAGS=
  - os: linux
if: type == cron
compiler: clang
env: TARGET=linux-glibc FLAGS="USE_SLZ=1 USE_PCRE2=1 USE_PCRE2_JIT=1
USE_LUA=1 USE_OPENSSL=1 USE_SYSTEMD=1 USE_WURFL=1
WURFL_INC=contrib/wurfl WURFL_LIB=contrib/wurfl USE_51DEGREES=1" CC=clang-9
before_script:
  - git clone https://github.com/wtarreau/libslz
  - cd libslz && make && make PREFIX=${HOME}/opt install && cd ..
  - export SLZ_INC=${HOME}/opt/include SLZ_LIB=${HOME}/opt/lib
  - export ADDLIB="-Wl,-rpath,$SLZ_LIB"
name: openssl-1.1.1 | slz | pcre2

Best regards
Tim Düsterhus

Re: do we want to keep CentOS 6 builds?

2020-11-15 Thread Lukas Tribus 
Hello,

On Sun, 15 Nov 2020 at 17:14, Илья Шипицин  wrote:
>
> Hello,
>
> we still run cirrus-ci builds.
> CentOS 6 is EOL.
>
> should we drop it?

I think CentOs6 gives us good feedback about older operating systems
that we may not necessarily want to break.

The question for me is not so much whether we want to test with CentOs
6, it's more about do we want to be aware and fix build issues with
those old systems? If the answer to the latter is yes, then we should
keep the tests. If the answer is no, then we should drop them of
course.

How much of a burden is it to a) keep testing and b) keep supporting
(by making sure it builds) on old kernels, libc and libraries?

I don't have a strong opinion, but I would tend to keep the support
(even though it's EOL). However if this is a continued pain in the
ass, for example with openssl, then it's probably better to drop it.


Lukas

Re: do we want to keep CentOS 6 builds?

2020-11-15 Thread Tim Düsterhus 
Ilya,

Am 15.11.20 um 17:14 schrieb Илья Шипицин:
> we still run cirrus-ci builds.
> CentOS 6 is EOL.
> 
> should we drop it?
> 

If it's EOL and they did not upgrade the OS then they are either lazy or
interesting in "stability". Either way they are probably not going to
upgrade HAProxy any further.

I'd say that keeping the CentOS 6 builds is a waste of effort.
Especially since they are limiting us with regard to the supported SSL
version from my understanding (I might be wrong there, but I believe
this is what https://github.com/haproxy/haproxy/issues/944 is about).

Best regards
Tim Düsterhus

do we want to keep CentOS 6 builds?

2020-11-15 Thread Илья Шипицин 
Hello,

we still run cirrus-ci builds.
CentOS 6 is EOL.

should we drop it?

Ilya

[PATCH v2] REGTESTS: converter: add url_dec test

2020-11-15 Thread William Dauchy 
while looking at `url_dec` implementation I realised there was not yet a
simple test to avoid future regressions.
This one is testing simple case, including the "+" behaviour depending
on the argument passed to `url_dec`

Signed-off-by: William Dauchy 
---
 reg-tests/converter/url_dec.vtc | 38 +
 1 file changed, 38 insertions(+)
 create mode 100644 reg-tests/converter/url_dec.vtc

diff --git a/reg-tests/converter/url_dec.vtc b/reg-tests/converter/url_dec.vtc
new file mode 100644
index 0..464c35a27
--- /dev/null
+++ b/reg-tests/converter/url_dec.vtc
@@ -0,0 +1,38 @@
+varnishtest "url_dec converter Test"
+
+#REQUIRE_VERSION=1.6
+
+feature ignore_unknown_macro
+
+server s1 {
+   rxreq
+   txresp
+} -repeat 2 -start
+
+haproxy h1 -conf {
+defaults
+   mode http
+   timeout connect 1s
+   timeout client  1s
+   timeout server  1s
+
+frontend fe
+   bind "fd@${fe}"
+
+   http-request  set-var(txn.url) url
+   http-response set-header url_dec0 "%[var(txn.url),url_dec]"
+   http-response set-header url_dec1 "%[var(txn.url),url_dec(1)]"
+
+   default_backend be
+
+backend be
+   server s1 ${s1_addr}:${s1_port}
+} -start
+
+client c1 -connect ${h1_fe_sock} {
+   txreq -url "/bla+%20?foo%3Dbar%2B42+42%20"
+   rxresp
+   expect resp.http.url_dec0 == "/bla+ ?foo=bar+42 42 "
+   expect resp.http.url_dec1 == "/bla  ?foo=bar+42 42 "
+   expect resp.status == 200
+} -run
-- 
2.29.2

Re: [PATCH] REGTESTS: converter: add url_dec test

2020-11-15 Thread William Dauchy 
Hi Tim,

thanks for the review.

On Sun, Nov 15, 2020 at 1:50 PM Tim Düsterhus  wrote:
> Am 15.11.20 um 13:45 schrieb William Dauchy:
> > +#REQUIRE_OPTION=OPENSSL
>
> I don't believe OPENSSL is required. The test passes for me even without
> compiling with SSL.

true bad copy/paste on my side.

> > +client c1 -connect ${h1_fe_sock} {
> > + txreq -url "/bla+?foo%3Dbar%2B42+42"
>
> Maybe add %20 to the string to test the other variant of encoding a space?

fixed in v2 even though %20 is not much different than other encoded
characters to my knowledge.
--
William

Re: [PATCH] REGTESTS: converter: add url_dec test

2020-11-15 Thread Tim Düsterhus 
William,

Am 15.11.20 um 13:45 schrieb William Dauchy:
> +#REQUIRE_OPTION=OPENSSL

I don't believe OPENSSL is required. The test passes for me even without
compiling with SSL.

> +client c1 -connect ${h1_fe_sock} {
> + txreq -url "/bla+?foo%3Dbar%2B42+42"

Maybe add %20 to the string to test the other variant of encoding a space?

> + rxresp
> + expect resp.http.url_dec0 == "/bla+?foo=bar+42 42"
> + expect resp.http.url_dec1 == "/bla ?foo=bar+42 42"
> + expect resp.status == 200
> +} -run
> 

Best regards
Tim Düsterhus

[PATCH] REGTESTS: converter: add url_dec test

2020-11-15 Thread William Dauchy 
while looking at `url_dec` implementation I realised there was not yet a
simple test to avoid future regressions.
This one is testing simple case, including the "+" behaviour depending
on the argument passed to `url_dec`

Signed-off-by: William Dauchy 
---
 reg-tests/converter/url_dec.vtc | 39 +
 1 file changed, 39 insertions(+)
 create mode 100644 reg-tests/converter/url_dec.vtc

diff --git a/reg-tests/converter/url_dec.vtc b/reg-tests/converter/url_dec.vtc
new file mode 100644
index 0..52b3b61ca
--- /dev/null
+++ b/reg-tests/converter/url_dec.vtc
@@ -0,0 +1,39 @@
+varnishtest "url_dec converter Test"
+
+#REQUIRE_VERSION=1.6
+#REQUIRE_OPTION=OPENSSL
+
+feature ignore_unknown_macro
+
+server s1 {
+   rxreq
+   txresp
+} -repeat 2 -start
+
+haproxy h1 -conf {
+defaults
+   mode http
+   timeout connect 1s
+   timeout client  1s
+   timeout server  1s
+
+frontend fe
+   bind "fd@${fe}"
+
+   http-request  set-var(txn.url) url
+   http-response set-header url_dec0 "%[var(txn.url),url_dec]"
+   http-response set-header url_dec1 "%[var(txn.url),url_dec(1)]"
+
+   default_backend be
+
+backend be
+   server s1 ${s1_addr}:${s1_port}
+} -start
+
+client c1 -connect ${h1_fe_sock} {
+   txreq -url "/bla+?foo%3Dbar%2B42+42"
+   rxresp
+   expect resp.http.url_dec0 == "/bla+?foo=bar+42 42"
+   expect resp.http.url_dec1 == "/bla ?foo=bar+42 42"
+   expect resp.status == 200
+} -run
-- 
2.29.2