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
вт, 29 дек. 2020 г. в 17:15, Tim Düsterhus :
> Ilya,
>
> Am 29.12.20 um 13:01 schrieb Илья Шипицин:
> > It is coverity weirdness. Build was submitted. If you follow to findings,
> > dates are updated
>
> Perfect, thanks. Looking at the overview page:
> https://scan.coverity.com/projects/haproxy
>
> I am not sure we will import the second patch for the reg test: it makes
usage of curl. We try to not use external programs for reg tests except
if there is no choice.
Fine by me. I actually meant to say that my second attempt at writing a reg
attempt should replace that patch. Apparently I
NFP WORKSHOPS
18 Blake Street, York YO1 8QG 01133 280988
Affordable Training Courses for Charities, Schools & Public Sector
Organisations
This email has been sent to haproxy@formilux.org
CLICK TO UNSUBSCRIBE FROM LIST
Alternatively send a blank e-mail to unsubscr...@nfpmail2001.co.uk
Ilya,
Am 29.12.20 um 13:01 schrieb Илья Шипицин:
> It is coverity weirdness. Build was submitted. If you follow to findings,
> dates are updated
Perfect, thanks. Looking at the overview page:
https://scan.coverity.com/projects/haproxy
It appears as if the "Components" list is outdated since the
It is coverity weirdness. Build was submitted. If you follow to findings,
dates are updated
On Tue, Dec 29, 2020, 4:47 PM Tim Düsterhus wrote:
> Willy,
>
> Am 28.12.20 um 12:05 schrieb Willy Tarreau:
> > Thanks to the name, I found it in a mail from Ilya on 2019-08-06 and
> > just uploaded it
Willy,
Am 28.12.20 um 12:05 schrieb Willy Tarreau:
> Thanks to the name, I found it in a mail from Ilya on 2019-08-06 and
> just uploaded it according to your procedure.
>
> Just push the patch now. Let's see if it works.
>
At least the build ran tonight:
This patch fixes GitHub Issue #988. Commit
ce9e7b25217c46db1ac636b2c885a05bf91ae57e
was not sufficient, because it fell back to a hash comparison if the bitmap
of known encodings was not acceptable instead of directly returning the the
cached response is not compatible.
This patch also extends
Remi,
Am 29.12.20 um 10:31 schrieb Remi Tricot-Le Breton:
> Concerning the vary.vtc, the new behavior can be explained as follows :
> Because of the absence of content-encoding in the second response of the
> vtc, its encoding is set to "identity", which is accepted by default by
> any client not
Willy,
Am 29.12.20 um 07:52 schrieb Willy Tarreau:
> Thanks for this, but while your patch looks valid, the regtest fails
> for me:
>
> [...]
Oh, indeed. I only tested the reg-test I modified and forgot to run all
the cache tests after finishing up my changes :-(
> I don't know if it's the
On 12/19/20 9:07 AM, Thayne McCombs wrote:
From 731d6a00f3cf0c70d7a8a916e1984c225f3a9dd6 Mon Sep 17 00:00:00 2001
From: Thayne McCombs
Date: Sat, 19 Dec 2020 00:59:35 -0700
Subject: [PATCH] Add test for stickiness using the server address for the
server key
---
On 12/16/20 8:39 AM, Thayne McCombs wrote:
On 12/10/20 1:31 AM, Frederic Lecaille wrote:
It would be preferable to send all your patches, so that others than me
may review your work (no diff between different versions of patches) and
continue to split your work in several patches.
Ok, here is
Hello Willy, Tim,
On 29/12/2020 07:52, Willy Tarreau wrote:
Hi Tim,
On Mon, Dec 28, 2020 at 12:47:52PM +0100, Tim Duesterhus wrote:
This patch fixes GitHub Issue #988. Commit
ce9e7b25217c46db1ac636b2c885a05bf91ae57e
was not sufficient, because it fell back to a hash comparison if the bitmap
13 matches
Mail list logo
