unsubscribe
unsubscribe On Sat, Jun 15, 2019, 5:02 PM wrote: > Hi, > > This is a friendly bot that watches fixes pending for the next > haproxy-stable release! One such e-mail is sent periodically once patches > are waiting in the last maintenance branch, and an ideal release date is > computed based on the severity of these fixes and their merge date. > Responses to this mail must be sent to the mailing list. > > Last release 1.8.20 was issued on 2019/04/25. There are currently 11 > patches in the queue cut down this way: > - 2 MAJOR, first one merged on 2019/04/30 > - 6 MEDIUM, first one merged on 2019/04/29 > - 3 MINOR, first one merged on 2019/04/29 > > Thus the computed ideal release date for 1.8.21 would be 2019/05/14, which > was four weeks ago. > > The current list of patches in the queue is: > - MAJOR : map/acl: real fix segfault during show map/acl on CLI > - MAJOR : lb/threads: make sure the avoided server is not full on > second pass > - MEDIUM : listener: Fix how unlimited number of consecutive accepts > is handled > - MEDIUM : spoe: Don't use the SPOE applet after releasing it > - MEDIUM : port_range: Make the ring buffer lock-free. > - MEDIUM : contrib/modsecurity: If host header is NULL, don't try to > strdup it > - MEDIUM : spoe: arg len encoded in previous frag frame but len > changed > - MEDIUM : dns: make the port numbers unsigned > - MINOR : ssl_sock: Fix memory leak when disabling compression > - MINOR : http_fetch: Rely on the smp direction for "cookie()" and > "hdr()" > - MINOR : http: Call stream_inc_be_http_req_ctr() only one time per > request > > --- > The haproxy stable-bot is freely provided by HAProxy Technologies to help > improve the quality of each HAProxy release. If you have any issue with > these emails or if you want to suggest some improvements, please post them > on the list so that the solutions suiting the most users can be found. > >
stable-bot: WARNING: 30 bug fixes in queue for next release
Hi, This is a friendly bot that watches fixes pending for the next haproxy-stable release! One such e-mail is sent periodically once patches are waiting in the last maintenance branch, and an ideal release date is computed based on the severity of these fixes and their merge date. Responses to this mail must be sent to the mailing list. Last release 1.9.8 was issued on 2019/05/13. There are currently 30 patches in the queue cut down this way: - 1 MAJOR, first one merged on 2019/05/27 - 17 MEDIUM, first one merged on 2019/05/21 - 12 MINOR, first one merged on 2019/05/16 Thus the computed ideal release date for 1.9.9 would be 2019/06/10, which was one week ago. The current list of patches in the queue is: - MAJOR : lb/threads: make sure the avoided server is not full on second pass - MEDIUM : connection: Use the session to get the origin address if needed. - MEDIUM : vars: make the tcp/http unset-var() action support conditions - MEDIUM : mux-h1: only check input data for the current stream, not next one - MEDIUM : spoe: Don't use the SPOE applet after releasing it - MEDIUM : connection: fix multiple handshake polling issues - MEDIUM : vars: make sure the scope is always valid when accessing vars - MEDIUM : h2: Don't forget to set h2s->cs to NULL after having free'd cs. - MEDIUM : threads: Fix build for 32bits arch with dwcas. - MEDIUM : threads: fix double-word CAS on non-optimized 32-bit platforms - MEDIUM : queue: fix the tree walk in pendconn_redistribute. - MEDIUM : mux-h1: Don't switch the mux in BUSY mode on 1xx messages - MEDIUM : dns: make the port numbers unsigned - MEDIUM : http: fix "http-request reject" when not final - MEDIUM : mux-h1: Don't skip the TCP splicing when there is no more data to read - MEDIUM : proto-htx: Not forward too much data when 1xx reponses are handled - MEDIUM : WURFL: segfault in wurfl-get() with missing info. - MEDIUM : streams: Don't switch from SI_ST_CON to SI_ST_DIS on read0. - MINOR : channel/htx: Don't alter channel during forward for empty HTX message - MINOR : peers: Wrong stick-table update message building. - MINOR : mux-h2: Count EOM in bytes sent when a HEADERS frame is formatted - MINOR : deinit/threads: make hard-stop-after perform a clean exit - MINOR : mux-h1: Don't send more data than expected - MINOR : mux-h1: errflag must be set on H1S and not H1M during output processing - MINOR : mux-h1: Wake up the mux if it is busy when a 1xx response is handled - MINOR : time: make sure only one thread sets global_now at boot - MINOR : ssl_sock: Fix memory leak when disabling compression - MINOR : htx: Remove a forgotten while loop in htx_defrag() - MINOR : mux-h1: Report EOI instead EOS on parsing error or H2 upgrade - MINOR : http_fetch: Rely on the smp direction for "cookie()" and "hdr()" --- The haproxy stable-bot is freely provided by HAProxy Technologies to help improve the quality of each HAProxy release. If you have any issue with these emails or if you want to suggest some improvements, please post them on the list so that the solutions suiting the most users can be found.
stable-bot: WARNING: 11 bug fixes in queue for next release
Hi, This is a friendly bot that watches fixes pending for the next haproxy-stable release! One such e-mail is sent periodically once patches are waiting in the last maintenance branch, and an ideal release date is computed based on the severity of these fixes and their merge date. Responses to this mail must be sent to the mailing list. Last release 1.8.20 was issued on 2019/04/25. There are currently 11 patches in the queue cut down this way: - 2 MAJOR, first one merged on 2019/04/30 - 6 MEDIUM, first one merged on 2019/04/29 - 3 MINOR, first one merged on 2019/04/29 Thus the computed ideal release date for 1.8.21 would be 2019/05/14, which was four weeks ago. The current list of patches in the queue is: - MAJOR : map/acl: real fix segfault during show map/acl on CLI - MAJOR : lb/threads: make sure the avoided server is not full on second pass - MEDIUM : listener: Fix how unlimited number of consecutive accepts is handled - MEDIUM : spoe: Don't use the SPOE applet after releasing it - MEDIUM : port_range: Make the ring buffer lock-free. - MEDIUM : contrib/modsecurity: If host header is NULL, don't try to strdup it - MEDIUM : spoe: arg len encoded in previous frag frame but len changed - MEDIUM : dns: make the port numbers unsigned - MINOR : ssl_sock: Fix memory leak when disabling compression - MINOR : http_fetch: Rely on the smp direction for "cookie()" and "hdr()" - MINOR : http: Call stream_inc_be_http_req_ctr() only one time per request --- The haproxy stable-bot is freely provided by HAProxy Technologies to help improve the quality of each HAProxy release. If you have any issue with these emails or if you want to suggest some improvements, please post them on the list so that the solutions suiting the most users can be found.
Re: PATCH: travis-ci cleanup after build targets cleanup
On Sun, Jun 16, 2019 at 02:14:25AM +0500, ??? wrote: > hello, > > we do not need to enable TFO and GETADDRINFO anymore in travis-ci builds. Ah good catch, thank you Ilya. Willy
PATCH: travis-ci cleanup after build targets cleanup
hello,
we do not need to enable TFO and GETADDRINFO anymore in travis-ci builds.
Ilya Shipitsin
From cce91d6f2b6d22211d89f19e50c4b3addda27e34 Mon Sep 17 00:00:00 2001
From: Ilya Shipitsin
Date: Sun, 16 Jun 2019 01:19:27 +0500
Subject: [PATCH] BUILD: travis-ci: TFO and GETADDRINFO are now enabled by
default
---
.travis.yml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/.travis.yml b/.travis.yml
index fca839b2..c1d7b2d1 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -5,7 +5,7 @@ language: c
env:
global:
-- FLAGS="USE_ZLIB=1 USE_PCRE=1 USE_PCRE_JIT=1 USE_LUA=1 USE_OPENSSL=1 USE_GETADDRINFO=1 USE_TFO=1 USE_SYSTEMD=1 USE_WURFL=1 WURFL_INC=contrib/wurfl WURFL_LIB=contrib/wurfl USE_DEVICEATLAS=1 DEVICEATLAS_SRC=contrib/deviceatlas USE_51DEGREES=1"
+- FLAGS="USE_ZLIB=1 USE_PCRE=1 USE_PCRE_JIT=1 USE_LUA=1 USE_OPENSSL=1 USE_SYSTEMD=1 USE_WURFL=1 WURFL_INC=contrib/wurfl WURFL_LIB=contrib/wurfl USE_DEVICEATLAS=1 DEVICEATLAS_SRC=contrib/deviceatlas USE_51DEGREES=1"
- SSL_LIB=${HOME}/opt/lib
- SSL_INC=${HOME}/opt/include
- TMPDIR=/tmp
--
2.20.1
Re: ea8dd949e4ab7ddd94afdbf0e96087c883192217 breaks allow-0rtt
On Sun, Jun 16, 2019 at 04:10:16AM +0800, Igor Pav wrote: > Hi Olivier, > > 965e84e now fixed this, thanks! P.S I test it by using browser and squid > proxy. Awesome, guys, many thanks. Let's not touch any code anymore so that we can be happy for one or two hours after the release and before the next bug report strikes again :-) Cheers, Willy
Re: ea8dd949e4ab7ddd94afdbf0e96087c883192217 breaks allow-0rtt
Hi Olivier, 965e84e now fixed this, thanks! P.S I test it by using browser and squid proxy. On Sun, Jun 16, 2019 at 3:03 AM Olivier Houchard wrote: > > Hi Igor, > > On Sat, Jun 15, 2019 at 07:19:24PM +0800, Igor Pav wrote: > > Hi Olivier, > > > > Still suffering from 2.0-dev7-b6563f-41 :( > > > > I can't seem to reproduce it. > I found a potential issue, and 965e84e2df7ba448d887bd5e9e03d76b206d3eee may > help. > If it does not, how do you reproduce it ? Which client and which server do > you use ? > > Thanks ! > > Olivier
Re: [PATCH] DOC: Fix typos in CONTRIBUTING
On Sat, Jun 15, 2019 at 07:47:29PM +0200, Tim Duesterhus wrote: > Fixes typos introduced in 09e0d7422e64645ad6b03b66e94e5df80a6177fa > as well as anything found by `spell`. Thanks Tim. That's annoying because some typographic rules differ in french and english and some are the same. I'm careful each time but I still get some of them wrong :-/ Willy
Re: ea8dd949e4ab7ddd94afdbf0e96087c883192217 breaks allow-0rtt
Hi Igor, On Sat, Jun 15, 2019 at 07:19:24PM +0800, Igor Pav wrote: > Hi Olivier, > > Still suffering from 2.0-dev7-b6563f-41 :( > I can't seem to reproduce it. I found a potential issue, and 965e84e2df7ba448d887bd5e9e03d76b206d3eee may help. If it does not, how do you reproduce it ? Which client and which server do you use ? Thanks ! Olivier
[PATCH] DOC: Fix typos in CONTRIBUTING
Fixes typos introduced in 09e0d7422e64645ad6b03b66e94e5df80a6177fa as well as anything found by `spell`. --- CONTRIBUTING | 41 + 1 file changed, 21 insertions(+), 20 deletions(-) diff --git a/CONTRIBUTING b/CONTRIBUTING index 29a5c8d78..0fcd921e8 100644 --- a/CONTRIBUTING +++ b/CONTRIBUTING @@ -33,15 +33,15 @@ it takes a lot of time to develop the skills necessary to be autonomous in the project, and there is a very small core team helped by a small set of very active participants. While most of the core team members work on the code as part of their day job, most participants do it on a voluntary basis during -their spare time. The ideal model for developers is to spend their time : +their spare time. The ideal model for developers is to spend their time: 1) developing new features 2) fixing bugs 3) doing maintenance backports 4) reviewing other people's code It turns out that on a project like HAProxy, like many other similarly complex -projects, the time spent is exactly the opposite : - 1) reviewing other peopel's code +projects, the time spent is exactly the opposite: + 1) reviewing other people's code 2) doing maintenance backports 3) fixing bugs 4) developing new features @@ -130,11 +130,11 @@ on your work in progress. Also, don't waste your time with the doc when submitting patches for review, only add the doc with the patch you consider ready to merge (unless you need some help on the doc itself, of course). -Another important point concerns code portability. Haproxy requires gcc as the +Another important point concerns code portability. HAProxy requires gcc as the C compiler, and may or may not work with other compilers. However it's known to build using gcc 2.95 or any later version. As such, it is important to keep in mind that certain facilities offered by recent versions must not be used in the -code : +code: - declarations mixed in the code (requires gcc >= 3.x and is a bad practice) - GCC builtins without checking for their availability based on version and @@ -189,8 +189,8 @@ the person doing the work as by default this person will be mentioned as the work's author. -Rules : the 12 laws of patch contribution -- +Rules: the 12 laws of patch contribution + People contributing patches must apply the following rules. That may sound heavy at the beginning but it's common sense more than anything else and contributors @@ -263,7 +263,7 @@ do not think about them anymore after a few patches. necessarily belong to a dirty project. Be careful to the way the text you add is presented and indented. Be very careful about typos, usual mistakes such as double consonants when only one is needed or "it's" instead of - "its", don't mix US english and UK english in the same paragraph, etc. + "its", don't mix US English and UK English in the same paragraph, etc. When in doubt, check in a dictionary. Fixes for existing typos in the doc are always welcome and chasing them is a good way to become familiar with the project and to get other participants' respect and consideration. @@ -737,7 +737,8 @@ The area the patch applies to is quite important, because some areas are known to be similar in older versions, suggesting a backport might be desirable, and conversely, some areas are known to be specific to one version. The area is a single-word lowercase name the contributor find clear enough to describe what -part is being touched. The following tags are suggested but not limitative : +part is being touched. The following list of tags is suggested but not +exhaustive: - examples example files. Be careful, sometimes these files are packaged. @@ -913,33 +914,33 @@ What to do if your patch is ignored All patches merged are acknowledged by the maintainer who picked it. If you didn't get an acknowledgement, check the mailing list archives to see if your -mail was propely delivered there and possibly if anyone responded and you did +mail was properly delivered there and possibly if anyone responded and you did not get their response (please look at http://haproxy.org/ for the mailing list archive's address). -If you see that your mail is there but nobody responded, please recheck : +If you see that your mail is there but nobody responded, please recheck: - was the subject clearly indicating that it was a patch and/or that you were -seeking some review ? +seeking some review? - - was your e-mail mangled by your mail agent ? If so it's possible that + - was your email mangled by your mail agent? If so it's possible that nobody had the willingness yet to mention it. - - was your e-mail sent as HTML ? If so it definitely ended in spam boxes -regardless of the archives + - was your email sent as HTML? If so it definitely ended in spam boxes +regardless
Re: Does anyone still use examples/haproxy.spec ?
On Sat, Jun 15, 2019 at 05:46:52PM +0200, Tim Düsterhus wrote:
> No objections from my side (and it can always be retrieved back from
> git),
Sure, nothing is ever lost, my concern is essentially to be sure I'm
not ignoring an obvious use case and annoying some users for no reason.
> I'm replying, because I want to suggest to take a look at the
> other files in the folder as well:
Good point!
> - auth.cfg : 10 years and IMO explained well in the
> configuration.txt
> - check{,.conf}: 12 years
> - debug* : 14 years
deleted.
> - haproxy.init : 4 years
kept as it at least serves as a doc to differenciate reload vs restart
for simple use cases.
> - haproxy.vim : 12 years, apart from my clean-up commit from
> last month. Definitely needs to be updated, possibly with some automation.
yes I think it's useful to some users. kept for now.
> - init.haproxy : 14 years (why is there two 'init' files?!)
Deleted. It was used for our distro "formilux" but is even outdated for
this one.
> - ssl.cfg : 4 years with the most recent commit adding a
> 'verify none' which is questionable.
deleted, I agree with not spreading bad options by default.
> - stats_haproxy.sh : 12 years
I forgot about this one! Pavlos' haproxystats is way more complete and
powerful. Let's delete this one.
> - transparent_proxy.cfg: Effectively 4 years
OK let's keep this one for the time we don't have an updated architecture
manual and the wiki is not updated. PiBa contributed this one as it's not
obvious.
> - wurfl-example.cfg: Recent
kept.
And I'm moving seamless-reload.txt to doc/
> So if all the outdated files or files with questionable use are removed
> a fairly short list remains. The things that are useful (such as
> haproxy.vim) could be moved to contrib/
Good point. Now moved to contrib/syntax-highlight.
> and the examples folder outright
> removed. As history has shown the examples tend to be neglected.
Yes, one reason being that the directory used to look like a garbage dump
and wasn't quite attractive.
> Instead
> the configuration.txt should possibly expanded for more complex
> use-cases, because that one is actually kept recent.
Be careful, configuration.txt should only be a reference manual and
theorically should not go beyond simple examples to illustrate a
keyword. The rest really belongs to the architecture manual. The
difference between the two is simple :
- if you start from a config file, you look up keywords in the
config manual and you figure their details and limitations ;
- if you start from the need to implement something, you search
it in the architecture manual and you copy-paste a look-alike
config that you can then extend.
So normally there are no "use-cases" in configuration.txt by
definition.
OK I'm finishing to clear the outdated files now, thanks for pointing
these ones!
Willy
Re: Does anyone still use examples/haproxy.spec ?
On 19-06-15 17:46:52, Tim Düsterhus wrote:
>> [...]
>
> No objections from my side (and it can always be retrieved back from
> git), I'm replying, because I want to suggest to take a look at the
> other files in the folder as well:
>
> - auth.cfg : 10 years and IMO explained well in the
> configuration.txt
> - check{,.conf}: 12 years
> - debug* : 14 years
> - haproxy.init : 4 years
> - haproxy.vim : 12 years, apart from my clean-up commit from
> last month. Definitely needs to be updated, possibly with some automation.
> - init.haproxy : 14 years (why is there two 'init' files?!)
> - ssl.cfg : 4 years with the most recent commit adding a
> 'verify none' which is questionable.
> - stats_haproxy.sh : 12 years
> - transparent_proxy.cfg: Effectively 4 years
> - wurfl-example.cfg: Recent
>
> So if all the outdated files or files with questionable use are
> removed a fairly short list remains. The things that are useful (such
> as haproxy.vim) could be moved to contrib/ and the examples folder
> outright removed. As history has shown the examples tend to be
> neglected. Instead the configuration.txt should possibly expanded for
> more complex use-cases, because that one is actually kept recent.
Full ACK -- thanks for your mail, Tim.
Cheers,
Georg
signature.asc
Description: PGP signature
Re: Does anyone still use examples/haproxy.spec ?
Examples might go to github wiki, for example
On Sat, Jun 15, 2019, 8:49 PM Tim Düsterhus wrote:
> Willy,
>
> Am 14.06.19 um 18:50 schrieb Willy Tarreau:
> > Given that we're talking about one of our oldest files and that
> > approximately no changes to it were made in the last 16 years,
> > I'm having strong doubts about the fact that anyone uses it. I'm
> > pretty sure it has been superseded with better maintained failes
> > from the distros by now. Does anyone still use it and want me not
> > to delete it ? My fingers are itching around the enter key...
> >
>
> No objections from my side (and it can always be retrieved back from
> git), I'm replying, because I want to suggest to take a look at the
> other files in the folder as well:
>
> - auth.cfg : 10 years and IMO explained well in the
> configuration.txt
> - check{,.conf}: 12 years
> - debug* : 14 years
> - haproxy.init : 4 years
> - haproxy.vim : 12 years, apart from my clean-up commit from
> last month. Definitely needs to be updated, possibly with some automation.
> - init.haproxy : 14 years (why is there two 'init' files?!)
> - ssl.cfg : 4 years with the most recent commit adding a
> 'verify none' which is questionable.
> - stats_haproxy.sh : 12 years
> - transparent_proxy.cfg: Effectively 4 years
> - wurfl-example.cfg: Recent
>
> So if all the outdated files or files with questionable use are removed
> a fairly short list remains. The things that are useful (such as
> haproxy.vim) could be moved to contrib/ and the examples folder outright
> removed. As history has shown the examples tend to be neglected. Instead
> the configuration.txt should possibly expanded for more complex
> use-cases, because that one is actually kept recent.
>
> Best regards
> Tim Düsterhus
>
>
Re: Idea + question regarding the build targets
On 6/15/2019 2:54 AM, Willy Tarreau wrote: Actually maybe we should have some super-options separate from the target to decide what feature set to enable. Instead of having just TARGET being mandatory, we could have both TARGET and OPTIONS for example. Then one could just build like this : make TARGET=linux-glibc OPTIONS=all or : make TARGET=freebsd OPTIONS=ssl,zlib,pcre or : make TARGET=cygwin OPTIONS=ssl Sounds pretty good to me. I do have an idea there, described below. At this point we'll need to pursue this discussion for 2.1 I guess, and this will not prevent us from backporting some improvements to help users of 2.0. But let's not forget that novices should definitely use their distro's packages first. The discussion could turn into bikeshedding, but I bet the core team maintains enough authority that somebody can be the benevolent dictator. The only reason that I build haproxy from source is so that I can run the newest release in whichever X.Y version I'm going for -- distros do lag a bit in that regard, otherwise I would use the distro package. I do use distro packages for most software. Ubuntu doesn't lag as far behind as some of the other distros, and Ubuntu is my preferred flavor right now. At a previous job, I also compiled my own openssl, with static linking, because the load balancer machines were running CentOS 6 and the distro's openssl was ANCIENT. I'm currently using 1.8, because the bugs I've read about in 1.9 scare me a bit and I'm waiting for it to stabilize. I think I might switch to 1.9 after another release or two ... my interpretation of the grapevine says that the latest releases have worked out most of the problems. At the moment, here's the only shed colors I have thought of beyond the ideas I've read so far: * Have OPTIONS=default be possible. MAYBE have that be what the build does if the user doesn't include OPTIONS. With clear documentation in the README about what the default options are, I think an implicit OPTIONS=default could work well. * Have the build print out what options have been enabled, pause for some reasonably short time period so the user can see it, and then proceed. 5 seconds, maybe up to 10. If there's a sane cross-platform way to do it, provide an option for the user to press some key that skips the pause. The check I mentioned could happen right before that pause point, and if problems are detected, print an error and exit. You'll need to figure out whether or not to add "force" to the options, to go ahead and try a build even when the check detects a problem. I wish you and the community the best of luck in finding the precise path that's right for haproxy. Thanks, Shawn
Re: Does anyone still use examples/haproxy.spec ?
Willy,
Am 14.06.19 um 18:50 schrieb Willy Tarreau:
> Given that we're talking about one of our oldest files and that
> approximately no changes to it were made in the last 16 years,
> I'm having strong doubts about the fact that anyone uses it. I'm
> pretty sure it has been superseded with better maintained failes
> from the distros by now. Does anyone still use it and want me not
> to delete it ? My fingers are itching around the enter key...
>
No objections from my side (and it can always be retrieved back from
git), I'm replying, because I want to suggest to take a look at the
other files in the folder as well:
- auth.cfg : 10 years and IMO explained well in the
configuration.txt
- check{,.conf}: 12 years
- debug* : 14 years
- haproxy.init : 4 years
- haproxy.vim : 12 years, apart from my clean-up commit from
last month. Definitely needs to be updated, possibly with some automation.
- init.haproxy : 14 years (why is there two 'init' files?!)
- ssl.cfg : 4 years with the most recent commit adding a
'verify none' which is questionable.
- stats_haproxy.sh : 12 years
- transparent_proxy.cfg: Effectively 4 years
- wurfl-example.cfg: Recent
So if all the outdated files or files with questionable use are removed
a fairly short list remains. The things that are useful (such as
haproxy.vim) could be moved to contrib/ and the examples folder outright
removed. As history has shown the examples tend to be neglected. Instead
the configuration.txt should possibly expanded for more complex
use-cases, because that one is actually kept recent.
Best regards
Tim Düsterhus
Re: Idea + question regarding the build targets
On Sat, Jun 15, 2019 at 05:29:49PM +0200, Tim Düsterhus wrote: > Willy, > William, > > Am 14.06.19 um 22:41 schrieb Willy Tarreau: > > Maybe we could have a "recommended" variant for each of these based on what > > people "usually" enable in such environments. > > > > I've explained in Message-ID > 67c868d5-32bc-1a98-658e-486676099...@bastelstu.be why I consider this a > bad idea / useless effort. OK at least this means that this discussion deserves to be pursued beyond the release. > Regarding patches: They look good to me. Thanks! I'm currently applying minor cleanups and am going to merge them. Willy
Re: Idea + question regarding the build targets
Willy, William, Am 14.06.19 um 22:41 schrieb Willy Tarreau: > Maybe we could have a "recommended" variant for each of these based on what > people "usually" enable in such environments. > I've explained in Message-ID 67c868d5-32bc-1a98-658e-486676099...@bastelstu.be why I consider this a bad idea / useless effort. Regarding patches: They look good to me. Best regards Tim Düsterhus
Re: memory sanitizer finding
Hi Ilya, On Sat, Jun 15, 2019 at 05:56:06PM +0500, ??? wrote: > hello, > > *** h10.0 debug|==8132==WARNING: MemorySanitizer: > use-of-uninitialized-value > *** h10.0 debug|#0 0x7f37c06f1b60 > (/usr/lib/x86_64-linux-gnu/liblua5.3.so.0+0x15b60) > *** h10.0 debug|#1 0x7f37c06e355e in lua_pushstring > (/usr/lib/x86_64-linux-gnu/liblua5.3.so.0+0x755e) > *** h10.0 debug|#2 0x7f37c06f8a5c in luaL_requiref > (/usr/lib/x86_64-linux-gnu/liblua5.3.so.0+0x1ca5c) > *** h10.0 debug|#3 0x7f37c0703f63 in luaL_openlibs > (/usr/lib/x86_64-linux-gnu/liblua5.3.so.0+0x27f63) > *** h10.0 debug|#4 0x4e92e9 in hlua_init > /home/travis/build/chipitsine/haproxy/src/hlua.c:8355:2 > *** h10.1 debug|#5 0x6b3f58 in init > /home/travis/build/chipitsine/haproxy/src/haproxy.c:1391:2 > *** h10.1 debug|#6 0x6b3f58 in main > /home/travis/build/chipitsine/haproxy/src/haproxy.c:2714 > *** h10.1 debug|#7 0x7f37bf9a082f in __libc_start_main > (/lib/x86_64-linux-gnu/libc.so.6+0x2082f) > *** h10.1 debug|#8 0x435768 in _start > (/home/travis/build/chipitsine/haproxy/haproxy+0x435768) > *** h10.1 debug| > *** h10.1 debug|SUMMARY: MemorySanitizer: > use-of-uninitialized-value > (/usr/lib/x86_64-linux-gnu/liblua5.3.so.0+0x15b60) > *** h10.1 debug|Exiting > > > is it something we should address before 2.0 release ? I have absolutely no idea what is uninitialized there, as the line in question contains a call to luaL_openlibs(gL.T) after gL.T has been created by lua_newstate(). Thus it could even be possible that it's something internal to Lua itself. In any case this part hasn't changed for a while so if there's an issue there it's not new and we should not delay 2.0 just for this. > or should we ignore it ? Not yet, it still deserves some analysis I think before knowing if we can safely ignore it. Willy
memory sanitizer finding
hello, *** h10.0 debug|==8132==WARNING: MemorySanitizer: use-of-uninitialized-value *** h10.0 debug|#0 0x7f37c06f1b60 (/usr/lib/x86_64-linux-gnu/liblua5.3.so.0+0x15b60) *** h10.0 debug|#1 0x7f37c06e355e in lua_pushstring (/usr/lib/x86_64-linux-gnu/liblua5.3.so.0+0x755e) *** h10.0 debug|#2 0x7f37c06f8a5c in luaL_requiref (/usr/lib/x86_64-linux-gnu/liblua5.3.so.0+0x1ca5c) *** h10.0 debug|#3 0x7f37c0703f63 in luaL_openlibs (/usr/lib/x86_64-linux-gnu/liblua5.3.so.0+0x27f63) *** h10.0 debug|#4 0x4e92e9 in hlua_init /home/travis/build/chipitsine/haproxy/src/hlua.c:8355:2 *** h10.1 debug|#5 0x6b3f58 in init /home/travis/build/chipitsine/haproxy/src/haproxy.c:1391:2 *** h10.1 debug|#6 0x6b3f58 in main /home/travis/build/chipitsine/haproxy/src/haproxy.c:2714 *** h10.1 debug|#7 0x7f37bf9a082f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f) *** h10.1 debug|#8 0x435768 in _start (/home/travis/build/chipitsine/haproxy/haproxy+0x435768) *** h10.1 debug| *** h10.1 debug|SUMMARY: MemorySanitizer: use-of-uninitialized-value (/usr/lib/x86_64-linux-gnu/liblua5.3.so.0+0x15b60) *** h10.1 debug|Exiting is it something we should address before 2.0 release ? or should we ignore it ?
Re: ea8dd949e4ab7ddd94afdbf0e96087c883192217 breaks allow-0rtt
Hi Olivier, Still suffering from 2.0-dev7-b6563f-41 :( On Sat, Jun 15, 2019 at 5:37 PM Olivier Houchard wrote: > > Hi Igor, > > On Sat, Jun 15, 2019 at 03:00:23AM +0800, Igor Pav wrote: > > Hello, dev > > > > The commit of ea8dd949e4ab7ddd94afdbf0e96087c883192217 seems to break > > the allow-0rtt in server line, a connection will take very very long > > to complete. Remove allow-0rtt it turns normal. > > > > conf like: > > > > listen test > > mode tcp > > bind 0.0.0.0:88 > > default_backend tls > > backend tls > > mode tcp > > retry-on 0rtt-rejected conn-failure empty-response response-timeout > > server default x.x.x.x:4433 allow-0rtt ssl check inter 300s alpn h2 > > verify none > > > > Indeed, it was not working as expected when specifying the ALPN. I believe > this is now fixed, can you confirm it ? > > Thanks ! > > Olivier
Re: ea8dd949e4ab7ddd94afdbf0e96087c883192217 breaks allow-0rtt
Hi Igor, On Sat, Jun 15, 2019 at 03:00:23AM +0800, Igor Pav wrote: > Hello, dev > > The commit of ea8dd949e4ab7ddd94afdbf0e96087c883192217 seems to break > the allow-0rtt in server line, a connection will take very very long > to complete. Remove allow-0rtt it turns normal. > > conf like: > > listen test > mode tcp > bind 0.0.0.0:88 > default_backend tls > backend tls > mode tcp > retry-on 0rtt-rejected conn-failure empty-response response-timeout > server default x.x.x.x:4433 allow-0rtt ssl check inter 300s alpn h2 > verify none > Indeed, it was not working as expected when specifying the ALPN. I believe this is now fixed, can you confirm it ? Thanks ! Olivier
Re: Idea + question regarding the build targets
Hi Shawn, On Fri, Jun 14, 2019 at 09:03:33PM -0600, Shawn Heisey wrote: > What I've noticed is that for the most part, you can classify source code > downloaders in one of two camps: Either the complete novice, or the > experienced user. The complete novice wants steps that are very simple, and > the experienced user wants the build to be customizable with myriad knobs > and switches, and wants them all documented. I find that membership in an > "intermediate" camp is very small ... people tend to either remain novices > or gravitate towards expert. I totally agree. > Dividing the README into two parts, one for the novice and one for the > expert, would be reasonable to me. This is a good proposal. I think it's what I tried to do recently but maybe it's not enough. It starts with a "quick build & install" section proposing a command to type on most common platforms. > The haproxy build is one of the more complex that I've encountered. This is interesting because it's not the feedback I got nor my experience either. I got many times some in person greetings like "thank you for not pissing us off with autoconf", which I personally totally share. But I agree that the doc on the build process is probably lacking a lot. And what is not easy is to add extra defines, CFLAGS or LDFLAGS because we tried to remain mostly compatible with command lines people have been using for a while, resulting in multiple ways to do this. > I've > written a little shell script to handle building and installing it, because > I'll never remember all the make options I need without checking the docs: > > - > root@smeagol:/usr/local/src# cat new-haproxy > #!/bin/sh > if [ -e "$1" ]; then > if [ -d "$1" ]; then > cd $1 > make clean && > make TARGET=linux2628 USE_PCRE_JIT=1 USE_OPENSSL=1 USE_ZLIB=1 > USE_SYSTEMD=1 CPU=native > RETVAL="$?" > if [ "$RETVAL" = 0 ]; then > make install > else > echo Build failed\! skipping install\! > fi > else > echo location \($1\) is not a directory. > fi > else > echo location \($1\) does not exist. > fi > - So the really useful part of it is : make clean && make TARGET=linux2628 USE_PCRE_JIT=1 USE_OPENSSL=1 USE_ZLIB=1 USE_SYSTEMD=1 CPU=native && make install Right ? Thus I guess the complex aspect you're seeing here is to remember the names of the USE_* options and the target. In a patchset I'm going to merge now, I've improved this a bit so that the "help" target lists these options and the ones enabled or disabled on your current target. > It would be really nice if a novice could simply type "make install" and > have it build with "sane" options for whatever OS they're on. That's about what William proposed with the "recommended" options. But if we do so we need to do it cross-systems, as Linux clearly is the most used one but not the only one. > Maybe having > one static command (or set of commands) for almost every user isn't > achievable without additional software that you don't want to use, such as > autoconf. The problem with autoconf precisely is that it does *not* set the options the user *wants* but instead will prevent the user from having more options than what autoconf *believes* his *current* system supports. That makes a lot of wrongs resulting in every user having to spend countless hours reading horrible configure scripts to figure the secret "ac_cv_*" variables that have to be forced by hand to make the script believe it previously checked and found a usable result, or patch the script. And while this could be acceptable for a lot of software that you're going to run locally, it makes no sense for something like haproxy that you are rarely going to build from sources to use on your desktop machine or laptop : if you're just a novice user or a web application developer, and have an instance on your machine to test your application, you just want to pick the last version shipped with your distro. Tricking autoconf scripts to force them to build for your servers' options from your desktop is another level of difficulty that's a real pain even for advanced users. > That said, some simplification would be welcome. Aliases so that > "TARGET=linux" produces a generally useful build on most current Linux > distros would be AWESOME. That was William's proposal initially and I'd tend to agree on this. I'd like to see openssl enable by default on most platforms for example. > The build should, as much as possible, check that > all options requested are possible, and fail fast if they're not, with > useful error messages. We could possibly create a "check" target in the makefile to validate if it thinks it will be able to build, and possibly to suggest *some* package names depending on the system. > General statement, not directed specifically at haproxy: I find it > frustrating to have a build get started, run for several minutes, Often if it takes several minutes
