Re: stable-bot: Bugfixes waiting for a release 2.2 (18), 2.1 (13), 2.0 (8), 1.8 (6)
Hi Daniel, On Wed, Aug 19, 2020 at 09:05:53AM -0400, Daniel Corbett wrote: > I was thinking to contribute the script to the contrib/ directory and > allow others to help improve it as well. > That's a good idea in my opinion. -- William Lallemand
Re: stable-bot: Bugfixes waiting for a release 2.2 (18), 2.1 (13), 2.0 (8), 1.8 (6)
Hello Tim, On 8/19/20 5:09 AM, Tim Düsterhus wrote: Daniel, The indentation is messed up here. Is this caused by the removal of 1.9? Yea, quite likely. I also have another proposal for readability of this list: Can the versions be ordered in descending order and possibly aligned within columns? Here's an example of what I'm thinking of: I'll see what I can do about fixing the indentations and improving the readability. The last time I tried improving the indentations it just didn't go well and I haven't had much time lately to work on it. I was thinking to contribute the script to the contrib/ directory and allow others to help improve it as well. Thanks, -- Daniel
Re: stable-bot: Bugfixes waiting for a release 2.2 (18), 2.1 (13), 2.0 (8), 1.8 (6)
On 19.08.20 11:42, Willy Tarreau wrote: Hi Aleks, On Wed, Aug 19, 2020 at 11:32:13AM +0200, Aleksandar Lazic wrote: Please can the following patch also be considered to be backported. OPTIM: startup: fast unique_id allocation for acl. http://git.haproxy.org/?p=haproxy-2.2.git;a=commit;h=f91ac19299fe216a793ba6550dca06b688b31549 Backported to which ones ? It's already in 2.2, 2.1 and 2.0, as well as the fix that Tim brought later since this patch alone caused some accidental breakage. If you're thinking about 1.8, I'm really not fond of backporting optimizations that far at the risk of breaking well-working setups. One of the reasons we now have a faster release cycle is to make sure users have plenty of choice of versions with a very limited risk of breakage, and that in order to maintain this we also avoid backporting what is not essential. And if you want my opinion, I think we still backport too much too far... (or at least too fast). Yep. I thought to 1.8 and I understand the reason why it was not backported. Thanks for answer. Regards, Willy
Re: [PATCH] MEDIUM: cfgparse: Emit hard error on truncated lines
On Wed, Aug 19, 2020 at 11:45:57AM +0200, Willy Tarreau wrote: > I retested at home on my other machine and it also fails 100% (so I messed > up this morning). Maybe a problem with your bash ? (private joke :-)). > Okay I can reproduce, yet another PEBKAC. :-) -- William Lallemand
Re: [PATCH] MEDIUM: cfgparse: Emit hard error on truncated lines
On Wed, Aug 19, 2020 at 11:38:51AM +0200, William Lallemand wrote: > On Wed, Aug 19, 2020 at 11:19:02AM +0200, Willy Tarreau wrote: > > On Wed, Aug 19, 2020 at 10:56:59AM +0200, Tim Düsterhus wrote: > > > William, > > > > > > Am 19.08.20 um 10:54 schrieb William Lallemand: > > > > I think it broke > > > > reg-tests/stick-table/converteers_ref_cnt_never_dec.vtc: > > > > > > > > https://travis-ci.com/github/haproxy/haproxy/jobs/375236964 > > > > > > > > But I can't reproduce localy. > > > > Strangely I didn't reproduce it this morning when applying them, so > > either it depends on the vtest version or I did something wrong in > > the test. Here I'm seeing fail 100%. > > > > That's surprising because vtest is built from the git during the CI > run. I tried with the latest vtest commit locally and I can't reproduce. > :/ I retested at home on my other machine and it also fails 100% (so I messed up this morning). Maybe a problem with your bash ? (private joke :-)). Willy
Re: stable-bot: Bugfixes waiting for a release 2.2 (18), 2.1 (13), 2.0 (8), 1.8 (6)
Hi Aleks, On Wed, Aug 19, 2020 at 11:32:13AM +0200, Aleksandar Lazic wrote: > Please can the following patch also be considered to be backported. > > OPTIM: startup: fast unique_id allocation for acl. > http://git.haproxy.org/?p=haproxy-2.2.git;a=commit;h=f91ac19299fe216a793ba6550dca06b688b31549 Backported to which ones ? It's already in 2.2, 2.1 and 2.0, as well as the fix that Tim brought later since this patch alone caused some accidental breakage. If you're thinking about 1.8, I'm really not fond of backporting optimizations that far at the risk of breaking well-working setups. One of the reasons we now have a faster release cycle is to make sure users have plenty of choice of versions with a very limited risk of breakage, and that in order to maintain this we also avoid backporting what is not essential. And if you want my opinion, I think we still backport too much too far... (or at least too fast). Regards, Willy
Re: [PATCH] MEDIUM: cfgparse: Emit hard error on truncated lines
On Wed, Aug 19, 2020 at 11:19:02AM +0200, Willy Tarreau wrote: > On Wed, Aug 19, 2020 at 10:56:59AM +0200, Tim Düsterhus wrote: > > William, > > > > Am 19.08.20 um 10:54 schrieb William Lallemand: > > > I think it broke > > > reg-tests/stick-table/converteers_ref_cnt_never_dec.vtc: > > > > > > https://travis-ci.com/github/haproxy/haproxy/jobs/375236964 > > > > > > But I can't reproduce localy. > > Strangely I didn't reproduce it this morning when applying them, so > either it depends on the vtest version or I did something wrong in > the test. Here I'm seeing fail 100%. > That's surprising because vtest is built from the git during the CI run. I tried with the latest vtest commit locally and I can't reproduce. :/ -- William Lallemand
Re: [PR] Prevent favicon.ico requests errors for stats page.
Hi, On Tue, Aug 18, 2020 at 10:23:08AM +0200, PR Bot wrote: > Patch title(s): >Prevent favicon.ico requests for stats page >Merge pull request #1 from zurikus/zurikus-patch-1 Thank you for this! I didn't even know it was possible to prevent the browser from requesting this file and it has been annoying me as well. Tested and confirmed, thus merged :-) Thanks! Willy
Re: stable-bot: Bugfixes waiting for a release 2.2 (18), 2.1 (13), 2.0 (8), 1.8 (6)
On 19.08.20 02:00, stable-...@haproxy.com 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 2.2.2 was issued on 2020-07-31. There are currently 18 patches in the queue cut down this way: - 1 MAJOR, first one merged on 2020-08-05 - 6 MEDIUM, first one merged on 2020-08-05 - 11 MINOR, first one merged on 2020-08-05 Thus the computed ideal release date for 2.2.3 would be 2020-08-19, which was within the last week. Last release 2.1.8 was issued on 2020-07-31. There are currently 13 patches in the queue cut down this way: - 4 MEDIUM, first one merged on 2020-08-05 - 9 MINOR, first one merged on 2020-08-11 Thus the computed ideal release date for 2.1.9 would be 2020-09-04, which is in three weeks or less. Last release 2.0.17 was issued on 2020-07-31. There are currently 8 patches in the queue cut down this way: - 4 MEDIUM, first one merged on 2020-08-05 - 4 MINOR, first one merged on 2020-08-11 Thus the computed ideal release date for 2.0.18 would be 2020-10-04, which is in seven weeks or less. Last release 1.8.26 was issued on 2020-08-03. There are currently 6 patches in the queue cut down this way: - 2 MEDIUM, first one merged on 2020-08-05 - 4 MINOR, first one merged on 2020-08-03 Please can the following patch also be considered to be backported. OPTIM: startup: fast unique_id allocation for acl. http://git.haproxy.org/?p=haproxy-2.2.git;a=commit;h=f91ac19299fe216a793ba6550dca06b688b31549 Thus the computed ideal release date for 1.8.27 would be 2020-10-26, which is in ten weeks or less. The current list of patches in the queue is: - 2.2 - MAJOR : dns: disabled servers through SRV records never recover - 2.2 - MEDIUM : ssl: fix the ssl-skip-self-issued-ca option - 1.8, 2.0 - MEDIUM : mux-h2: Don't fail if nothing is parsed for a legacy chunk response - 2.2 - MEDIUM : ssl: never generates the chain from the verify store - 2.0, 2.1, 2.2 - MEDIUM : mux-h1: Refresh H1 connection timeout after a synchronous send - 2.0, 2.1, 2.2 - MEDIUM : htx: smp_prefetch_htx() must always validate the direction - 2.1, 2.2 - MEDIUM : ssl: memory leak of ocsp data at SSL_CTX_free() - 1.8, 2.0, 2.1, 2.2- MEDIUM : map/lua: Return an error if a map is loaded during runtime - 2.1, 2.2 - MINOR : arg: Fix leaks during arguments validation for fetches/converters - 1.8, 2.0, 2.1, 2.2- MINOR : lua: Check argument type to convert it to IP mask in arg validation - 2.1, 2.2 - MINOR : ssl: fix memory leak at OCSP loading - 2.0, 2.1, 2.2 - MINOR : snapshots: leak of snapshots on deinit() - 1.8, 2.0, 2.1, 2.2- MINOR : stats: use strncmp() instead of memcmp() on health states - 2.2 - MINOR : ssl: ssl-skip-self-issued-ca requires >= 1.0.2 - 2.1, 2.2 - MINOR : lua: Duplicate map name to load it when a new Map object is created - 2.2 - MINOR : spoa-server: fix size_t format printing - 1.8, 2.0, 2.1, 2.2- MINOR : lua: Check argument type to convert it to IPv4/IPv6 arg validation - 1.8 - MINOR : dns: ignore trailing dot - 2.1, 2.2 - MINOR : converters: Store the sink in an arg pointer for debug() converter - 2.1, 2.2 - MINOR : lua: Duplicate lua strings in sample fetches/converters arg array
Re: [PATCH] MEDIUM: cfgparse: Emit hard error on truncated lines
On Wed, Aug 19, 2020 at 10:56:59AM +0200, Tim Düsterhus wrote: > William, > > Am 19.08.20 um 10:54 schrieb William Lallemand: > > I think it broke > > reg-tests/stick-table/converteers_ref_cnt_never_dec.vtc: > > > > https://travis-ci.com/github/haproxy/haproxy/jobs/375236964 > > > > But I can't reproduce localy. Strangely I didn't reproduce it this morning when applying them, so either it depends on the vtest version or I did something wrong in the test. Here I'm seeing fail 100%. > Looking at the test I would suspect that removing the indentation in > front of the brace in line 62 fixes the issue. But I did not test this > either: > > https://github.com/haproxy/haproxy/blob/ff4d86becd658f61e45692815f3b9e7a1e66107f/reg-tests/stick-table/converteers_ref_cnt_never_dec.vtc#L62 Confirmed, the spaces are sent to the output config file and cause the error. I'm going to fix that and push the fix. Willy > > Best regards > Tim Düsterhus
Re: stable-bot: Bugfixes waiting for a release 2.2 (18), 2.1 (13), 2.0 (8), 1.8 (6)
Daniel, Am 19.08.20 um 02:00 schrieb stable-...@haproxy.com: > The current list of patches in the queue is: > - 2.2 - MAJOR : dns: disabled servers through SRV > records never recover > - 2.2 - MEDIUM : ssl: fix the ssl-skip-self-issued-ca > option > - 1.8, 2.0 - MEDIUM : mux-h2: Don't fail if nothing is > parsed for a legacy chunk response > - 2.2 - MEDIUM : ssl: never generates the chain from > the verify store > - 2.0, 2.1, 2.2 - MEDIUM : mux-h1: Refresh H1 connection > timeout after a synchronous send > - 2.0, 2.1, 2.2 - MEDIUM : htx: smp_prefetch_htx() must always > validate the direction > - 2.1, 2.2 - MEDIUM : ssl: memory leak of ocsp data at > SSL_CTX_free() > - 1.8, 2.0, 2.1, 2.2- MEDIUM : map/lua: Return an error if a > map is loaded during runtime The indentation is messed up here. Is this caused by the removal of 1.9? > - 2.1, 2.2 - MINOR : arg: Fix leaks during arguments > validation for fetches/converters > - 1.8, 2.0, 2.1, 2.2- MINOR : lua: Check argument type to > convert it to IP mask in arg validation > - 2.1, 2.2 - MINOR : ssl: fix memory leak at OCSP loading > - 2.0, 2.1, 2.2 - MINOR : snapshots: leak of snapshots on > deinit() > - 1.8, 2.0, 2.1, 2.2- MINOR : stats: use strncmp() instead of > memcmp() on health states > - 2.2 - MINOR : ssl: ssl-skip-self-issued-ca > requires >= 1.0.2 > - 2.1, 2.2 - MINOR : lua: Duplicate map name to load it > when a new Map object is created > - 2.2 - MINOR : spoa-server: fix size_t format > printing > - 1.8, 2.0, 2.1, 2.2- MINOR : lua: Check argument type to > convert it to IPv4/IPv6 arg validation > - 1.8 - MINOR : dns: ignore trailing dot > - 2.1, 2.2 - MINOR : converters: Store the sink in an arg > pointer for debug() converter > - 2.1, 2.2 - MINOR : lua: Duplicate lua strings in sample > fetches/converters arg array > I also have another proposal for readability of this list: Can the versions be ordered in descending order and possibly aligned within columns? Here's an example of what I'm thinking of: - 2.2- MINOR: stuff - 2.2, 2.1 - MINOR: stuff - 2.2- MINOR: stuff - 2.2, 2.1, 2.0 - MINOR: stuff - 2.0, 1.8 - MINOR: stuff You can quickly scan the columns of your version that way and do not have to search for your version in each of the rows. Best regards Tim Düsterhus
Re: [PATCH] MEDIUM: cfgparse: Emit hard error on truncated lines
William, Am 19.08.20 um 10:54 schrieb William Lallemand: > I think it broke > reg-tests/stick-table/converteers_ref_cnt_never_dec.vtc: > > https://travis-ci.com/github/haproxy/haproxy/jobs/375236964 > > But I can't reproduce localy. Looking at the test I would suspect that removing the indentation in front of the brace in line 62 fixes the issue. But I did not test this either: https://github.com/haproxy/haproxy/blob/ff4d86becd658f61e45692815f3b9e7a1e66107f/reg-tests/stick-table/converteers_ref_cnt_never_dec.vtc#L62 Best regards Tim Düsterhus
Re: [PATCH] MEDIUM: cfgparse: Emit hard error on truncated lines
On Tue, Aug 18, 2020 at 10:00:04PM +0200, Tim Duesterhus wrote:
> As announced within the emitted log message this is going to become a hard
> error in 2.3. It's 2.3 time now, let's do this.
>
> see 2fd5bdb439da29f15381aeb57c51327ba57674fc
> ---
> src/cfgparse.c | 15 +++
> 1 file changed, 7 insertions(+), 8 deletions(-)
>
> diff --git a/src/cfgparse.c b/src/cfgparse.c
> index de82a9fd3..17db1fcae 100644
> --- a/src/cfgparse.c
> +++ b/src/cfgparse.c
> @@ -1876,11 +1876,11 @@ next_line:
> char *line = thisline;
>
> if (missing_lf != -1) {
> - ha_warning("parsing [%s:%d]: Stray NUL character at
> position %d. "
> -"This will become a hard error in HAProxy
> 2.3.\n",
> -file, linenum, (missing_lf + 1));
> - err_code |= ERR_WARN;
> + ha_alert("parsing [%s:%d]: Stray NUL character at
> position %d.\n",
> + file, linenum, (missing_lf + 1));
> + err_code |= ERR_ALERT | ERR_FATAL;
> missing_lf = -1;
> + break;
> }
>
> linenum++;
> @@ -2086,10 +2086,9 @@ next_line:
> }
>
> if (missing_lf != -1) {
> - ha_warning("parsing [%s:%d]: Missing LF on last line, file
> might have been truncated at position %d. "
> -"This will become a hard error in HAProxy 2.3.\n",
> -file, linenum, (missing_lf + 1));
> - err_code |= ERR_WARN;
> + ha_alert("parsing [%s:%d]: Missing LF on last line, file might
> have been truncated at position %d.\n",
> + file, linenum, (missing_lf + 1));
> + err_code |= ERR_ALERT | ERR_FATAL;
> }
>
> if (cs && cs->post_section_parser)
>
I think it broke
reg-tests/stick-table/converteers_ref_cnt_never_dec.vtc:
https://travis-ci.com/github/haproxy/haproxy/jobs/375236964
But I can't reproduce localy.
--
William Lallemand
