From dridi at varni.sh Fri May 3 08:51:45 2019 From: dridi at varni.sh (Dridi Boukelmoune) Date: Fri, 3 May 2019 10:51:45 +0200 Subject: VIP23 (VSL refactoring) design sketch In-Reply-To: <3980.1555097051@critter.freebsd.dk> References: <82919b48-25e0-d22f-1029-6d17db040519@uplex.de> <12535.1554880438@critter.freebsd.dk> <6f019e96-358a-65c3-10af-872b448b4cda@uplex.de> <93c9d1d0-9d1c-ba23-a7aa-cc5e597d171e@uplex.de> <1798.1554905266@critter.freebsd.dk> <9c60775c-1ea6-4383-4f32-b1fc2f38a0b5@uplex.de>

<3980.1555097051@critter.freebsd.dk> Message-ID: On Fri, Apr 12, 2019 at 9:24 PM Poul-Henning Kamp wrote: > > -------- > In message , Dridi Boukelmoune writes: > > >Interesting, for textual logs the effect of vsl_reclen is > >straightforward but how should we deal with binary records truncation? > > Maybe redefine the limit to apply to individual strings (ie: header > values) rather than the full record ? > > >> Some other lessons learned: > >> > >> The binary records are not necessarily shorter than the ASCII-formatted > >> records. > > It is incredible how often people overlook this. I've been ranting > about it for almost two decades now, in particular in context of the > userland/kernel API. > > Imagine if in addition to errno there also were a const char *errstr > which the kernel could fill out, that would do *wonders*, in particular > for EINVAL. > > My favourite example was a Nx64 card where the driver spent more > than 35kloc of source code on defining a ton of structs for ioctl(2) > usage but no matter what the kernel found deficient, the only thing > it told you was return(EINVAL). > > I threw out the entire thing and added a single ioctl which passed a > struct with an input string, containing a command like > "set chan 4 ts 4-12" > and another string out with an error message like: > "channel 11 already allocated to chan 5" > didn't even spend 1kloc on it... I have given a bit more thought to this and going with structured binary VSL records will have more consequences than a blank-separated list of fields. First we lose the ability to treat the whole record as a single sting out of the box. The client will need to reconstruct the string from the various field types that may constitute a record. Think string and regex operators. Then we further the disconnect between today's VSL parsing and VSL query parsing. Query parsing of strings does already support quoted strings, and they are not mandatory. We can even query a prefix containing blanks by quoting the prefix: -q 'VCL_Log:"just because" eq "we can"' My attempt at solving this (#2872) was bringing back consistency by allowing fields to be quoted. I'm glad with the turbo-encabulator-friendly outcome for Backend_health, but we need to consider the std.log() escape hatch over which we have no input control, and for which we can't currently provide a VCC interface to describe the fields, pass them as a vararg and still ensure at "compile time" that arguments match the spec. Sure, VCC could learn to do that but it sounds a tiny bit complicated. Finally, regarding the VSL file header that we'd hypothetically dump with varnishlog -w in the future (which I really hope we do), we could consider making this a VSL record itself that is not subject to vsl_reclen, querying or filtering, for the needs of dynamic VSLs, so that whenever something changes VSL clients see an update. It would then be varnishlog -w's job to build such a synthetic record in the VSL file before dumping actual logs. Dridi From geoff at uplex.de Fri May 3 10:07:17 2019 From: geoff at uplex.de (Geoff Simmons) Date: Fri, 3 May 2019 12:07:17 +0200 Subject: VIP23 (VSL refactoring) design sketch In-Reply-To: References: <82919b48-25e0-d22f-1029-6d17db040519@uplex.de> <12535.1554880438@critter.freebsd.dk> <6f019e96-358a-65c3-10af-872b448b4cda@uplex.de> <93c9d1d0-9d1c-ba23-a7aa-cc5e597d171e@uplex.de> <1798.1554905266@critter.freebsd.dk> <9c60775c-1ea6-4383-4f32-b1fc2f38a0b5@uplex.de>

<3980.1555097051@critter.freebsd.dk> Message-ID: On 5/3/19 10:51, Dridi Boukelmoune wrote: > > First we lose the ability to treat the whole record as a single sting > out of the box. The client will need to reconstruct the string from > the various field types that may constitute a record. Think string and > regex operators. Yes, Martin and I recently had a conversation about this on #hacking. For the string equality comparisons (eq and ne), we could conceivably look into the comparison string and see if it has blanks that cross field boundaries. But as you pointed out, some VSL payloads have blanks that are not field separators (VCL_Log, FetchError, etc). For regex comparisons, where the pattern could include things like "\s", ".*", "\W" and so forth, detecting whether the pattern might match a field-separating blank has the look of a sophisticated computer science-y problem. Martin and I agreed that, at least in the first iteration, for VSLQ queries with a string operator (equality or regex) we should render the formatted payload into a temporary buffer and run the comparison against that. Once we have it all working, maybe we could consider more clever solutions, but I'd be surprised if we'd gain much from getting clever. I think that an important part of this will be to emphasize in the docs that authors of VSL queries should use field[n] indices and numeric comparisons whenever it's appropriate. My (admittedly evidence-free) impression is that not everyone uses them when they could. Say you're scanning backend logs for fetches to backend foo, like this: -q 'BackendOpen ~ "foo"' Since the backend name is the second field, it would be better as: -q 'BackendOpen[2] eq "foo"' Or to look for backend fetches that take longer than 1 second, it wouldn't surprise me if some people are doing something like: -q 'Timestamp:Beresp ~ "[1-9]\.\d*$"' When it should be: -q 'Timestamp:Beresp[3] > 1.0' We'll do much better if we can narrow the query to a field, and if we don't have to convert numbers at all. And we should make sure that users know about it. > Finally, regarding the VSL file header that we'd hypothetically dump > with varnishlog -w in the future (which I really hope we do), we could > consider making this a VSL record itself that is not subject to > vsl_reclen, querying or filtering, for the needs of dynamic VSLs, so > that whenever something changes VSL clients see an update. It would > then be varnishlog -w's job to build such a synthetic record in the > VSL file before dumping actual logs. I agree, and I'd say that when we do have meta-data entries in the log, it should be possible for them to appear at any time, in both log files and in-memory logs. That would put us on the path to dynamic SLT tags. But we're not planning for that in the first iteration. phk has said that he doesn't foresee dynamic VSL by the September release. And I agree that we should get the rest working first. Best, Geoff -- ** * * UPLEX - Nils Goroll Systemoptimierung Scheffelstra?e 32 22301 Hamburg Tel +49 40 2880 5731 Mob +49 176 636 90917 Fax +49 40 42949753 http://uplex.de -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From dridi at varni.sh Fri May 3 13:07:17 2019 From: dridi at varni.sh (Dridi Boukelmoune) Date: Fri, 3 May 2019 15:07:17 +0200 Subject: VIP23 (VSL refactoring) design sketch In-Reply-To: References: <82919b48-25e0-d22f-1029-6d17db040519@uplex.de> <12535.1554880438@critter.freebsd.dk> <6f019e96-358a-65c3-10af-872b448b4cda@uplex.de> <93c9d1d0-9d1c-ba23-a7aa-cc5e597d171e@uplex.de> <1798.1554905266@critter.freebsd.dk> <9c60775c-1ea6-4383-4f32-b1fc2f38a0b5@uplex.de>

<3980.1555097051@critter.freebsd.dk>

Message-ID: On Fri, May 3, 2019 at 12:07 PM Geoff Simmons wrote: > > On 5/3/19 10:51, Dridi Boukelmoune wrote: > > > > First we lose the ability to treat the whole record as a single sting > > out of the box. The client will need to reconstruct the string from > > the various field types that may constitute a record. Think string and > > regex operators. > > Yes, Martin and I recently had a conversation about this on #hacking. > For the string equality comparisons (eq and ne), we could conceivably > look into the comparison string and see if it has blanks that cross > field boundaries. But as you pointed out, some VSL payloads have blanks > that are not field separators (VCL_Log, FetchError, etc). > > For regex comparisons, where the pattern could include things like "\s", > ".*", "\W" and so forth, detecting whether the pattern might match a > field-separating blank has the look of a sophisticated computer > science-y problem. Does it have to though? We only use those as raw strings, and never as regular expression patterns. > Martin and I agreed that, at least in the first iteration, for VSLQ > queries with a string operator (equality or regex) we should render the > formatted payload into a temporary buffer and run the comparison against > that. Once we have it all working, maybe we could consider more clever > solutions, but I'd be surprised if we'd gain much from getting clever. Ack, that's the logical thing to start with. > I think that an important part of this will be to emphasize in the docs > that authors of VSL queries should use field[n] indices and numeric > comparisons whenever it's appropriate. My (admittedly evidence-free) > impression is that not everyone uses them when they could. Well, today the fields need to be dup'ed anyway when we need a null terminated string so that will indeed need to be documented that field operations become much cheaper than record operations. > Say you're scanning backend logs for fetches to backend foo, like this: > > -q 'BackendOpen ~ "foo"' > > Since the backend name is the second field, it would be better as: > > -q 'BackendOpen[2] eq "foo"' > > Or to look for backend fetches that take longer than 1 second, it > wouldn't surprise me if some people are doing something like: > > -q 'Timestamp:Beresp ~ "[1-9]\.\d*$"' > > When it should be: > > -q 'Timestamp:Beresp[3] > 1.0' Agreed, I sometimes realize after running a long query on a VSL of the GB persuasion that I could have done better. > We'll do much better if we can narrow the query to a field, and if we > don't have to convert numbers at all. And we should make sure that users > know about it. Make the field index mandatory with [0] meaning the whole record and people will learn :p > > Finally, regarding the VSL file header that we'd hypothetically dump > > with varnishlog -w in the future (which I really hope we do), we could > > consider making this a VSL record itself that is not subject to > > vsl_reclen, querying or filtering, for the needs of dynamic VSLs, so > > that whenever something changes VSL clients see an update. It would > > then be varnishlog -w's job to build such a synthetic record in the > > VSL file before dumping actual logs. > > I agree, and I'd say that when we do have meta-data entries in the log, > it should be possible for them to appear at any time, in both log files > and in-memory logs. That would put us on the path to dynamic SLT tags. > > But we're not planning for that in the first iteration. phk has said > that he doesn't foresee dynamic VSL by the September release. And I > agree that we should get the rest working first. I disagree. If we draft a plan that 1) changes the in-memory AND on-disk format and 2) has later a possibility for dynamic VSLs we should make this part of the first iteration. We shouldn't change the format of such a critical piece of the infrastructure every other release. Also by making this both a synthetic record for live log consumer by libvarnishapi and in the future something that varnishd may produce then it becomes a no brainer for varnishlog. It just writes it on disk like any other log record. It may need some intelligence though when logs are rotated, like varnishlog asking for a synthetic record again. Dridi From dridi at varni.sh Sat May 4 09:49:07 2019 From: dridi at varni.sh (Dridi Boukelmoune) Date: Sat, 4 May 2019 11:49:07 +0200 Subject: VIP23 (VSL refactoring) design sketch In-Reply-To: References: <82919b48-25e0-d22f-1029-6d17db040519@uplex.de> <12535.1554880438@critter.freebsd.dk> <6f019e96-358a-65c3-10af-872b448b4cda@uplex.de> <93c9d1d0-9d1c-ba23-a7aa-cc5e597d171e@uplex.de> <1798.1554905266@critter.freebsd.dk> <9c60775c-1ea6-4383-4f32-b1fc2f38a0b5@uplex.de>

<3980.1555097051@critter.freebsd.dk>

Message-ID: On Fri, May 3, 2019 at 3:07 PM Dridi Boukelmoune wrote: > > On Fri, May 3, 2019 at 12:07 PM Geoff Simmons wrote: > > > > On 5/3/19 10:51, Dridi Boukelmoune wrote: > > > > > > First we lose the ability to treat the whole record as a single sting > > > out of the box. The client will need to reconstruct the string from > > > the various field types that may constitute a record. Think string and > > > regex operators. > > > > Yes, Martin and I recently had a conversation about this on #hacking. > > For the string equality comparisons (eq and ne), we could conceivably > > look into the comparison string and see if it has blanks that cross > > field boundaries. But as you pointed out, some VSL payloads have blanks > > that are not field separators (VCL_Log, FetchError, etc). > > > > For regex comparisons, where the pattern could include things like "\s", > > ".*", "\W" and so forth, detecting whether the pattern might match a > > field-separating blank has the look of a sophisticated computer > > science-y problem. > > Does it have to though? We only use those as raw strings, and never as > regular expression patterns. By the way, yes I'm aware that quoting fields containing blanks would introduce the need of escaping at the very least double quotes and the escape character. > > Martin and I agreed that, at least in the first iteration, for VSLQ > > queries with a string operator (equality or regex) we should render the > > formatted payload into a temporary buffer and run the comparison against > > that. Once we have it all working, maybe we could consider more clever > > solutions, but I'd be surprised if we'd gain much from getting clever. > > Ack, that's the logical thing to start with. One request I forgot to make in this area, when you rebuild the complete record, it would be nice to enclose fields that contain blanks with double quotes, so that we can have the same syntax on 6.0 since we're going to maintain it for a while and I would like to solve the querying problem there too. > > I think that an important part of this will be to emphasize in the docs > > that authors of VSL queries should use field[n] indices and numeric > > comparisons whenever it's appropriate. My (admittedly evidence-free) > > impression is that not everyone uses them when they could. > > Well, today the fields need to be dup'ed anyway when we need a null > terminated string so that will indeed need to be documented that field > operations become much cheaper than record operations. > > > Say you're scanning backend logs for fetches to backend foo, like this: > > > > -q 'BackendOpen ~ "foo"' > > > > Since the backend name is the second field, it would be better as: > > > > -q 'BackendOpen[2] eq "foo"' > > > > Or to look for backend fetches that take longer than 1 second, it > > wouldn't surprise me if some people are doing something like: > > > > -q 'Timestamp:Beresp ~ "[1-9]\.\d*$"' > > > > When it should be: > > > > -q 'Timestamp:Beresp[3] > 1.0' > > Agreed, I sometimes realize after running a long query on a VSL of the > GB persuasion that I could have done better. > > > We'll do much better if we can narrow the query to a field, and if we > > don't have to convert numbers at all. And we should make sure that users > > know about it. > > Make the field index mandatory with [0] meaning the whole record and > people will learn :p > > > > Finally, regarding the VSL file header that we'd hypothetically dump > > > with varnishlog -w in the future (which I really hope we do), we could > > > consider making this a VSL record itself that is not subject to > > > vsl_reclen, querying or filtering, for the needs of dynamic VSLs, so > > > that whenever something changes VSL clients see an update. It would > > > then be varnishlog -w's job to build such a synthetic record in the > > > VSL file before dumping actual logs. > > > > I agree, and I'd say that when we do have meta-data entries in the log, > > it should be possible for them to appear at any time, in both log files > > and in-memory logs. That would put us on the path to dynamic SLT tags. > > > > But we're not planning for that in the first iteration. phk has said > > that he doesn't foresee dynamic VSL by the September release. And I > > agree that we should get the rest working first. > > I disagree. If we draft a plan that 1) changes the in-memory AND > on-disk format and 2) has later a possibility for dynamic VSLs we > should make this part of the first iteration. We shouldn't change the > format of such a critical piece of the infrastructure every other > release. > > Also by making this both a synthetic record for live log consumer by > libvarnishapi and in the future something that varnishd may produce > then it becomes a no brainer for varnishlog. It just writes it on disk > like any other log record. It may need some intelligence though when > logs are rotated, like varnishlog asking for a synthetic record again. > > Dridi From scan-admin at coverity.com Sun May 5 11:24:42 2019 From: scan-admin at coverity.com (scan-admin at coverity.com) Date: Sun, 05 May 2019 11:24:42 +0000 (UTC) Subject: Coverity Scan: Analysis completed for varnish Message-ID: <5ccec7f9f269b_79772ac098f38f58463e@appnode-2.mail> Your request for analysis of varnish has been completed successfully. The results are available at https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V05UPxvVjWch-2Bd2MGckcRaZSCEJOPR4AEUn0hVASTtlJ23U2ffwbN1LtJbHcOCfQg-3D-3D_wrU9d1VlqIiuL6N0zVMze4Ep-2FR7u99vtLlE-2BlH3ENQBdpGgEAStooGe8CxoOeycupWqV-2Fgf9EB-2F0eclVz2d-2B0O4sqzYOUVaxjn26E-2BnYQArMUCS1-2FtkyNy-2FR01qECGQM3r8weCn1sYc2azueXQ6GONNiVTXJ-2BmUM-2FPjuVm-2FVUpFeXPkPvRKv-2BaqEfCi2IQp13LK-2B-2BTSb1U1FGPMDCUJEoWv6EI-2FxaVTm1d2nCQ-2FyGuo-3D Build ID: 254645 Analysis Summary: New defects found: 0 Defects eliminated: 4 From geoff at uplex.de Mon May 6 18:24:47 2019 From: geoff at uplex.de (Geoff Simmons) Date: Mon, 6 May 2019 20:24:47 +0200 Subject: VIP23 (VSL refactoring) SLT inventory In-Reply-To: References: <82919b48-25e0-d22f-1029-6d17db040519@uplex.de> <12535.1554880438@critter.freebsd.dk> <6f019e96-358a-65c3-10af-872b448b4cda@uplex.de> <93c9d1d0-9d1c-ba23-a7aa-cc5e597d171e@uplex.de> <1798.1554905266@critter.freebsd.dk> <9c60775c-1ea6-4383-4f32-b1fc2f38a0b5@uplex.de>

<3980.1555097051@critter.freebsd.dk>

Message-ID: To help get an overview of what the VSL refactoring will be all about, I applied some grep-foo to current master to find the VSL*() calls in the code, so that we can see how log data are currently formatted by varnishd. Results are on the github wiki: https://github.com/varnishcache/varnish-cache/wiki/SLT-inventory This has: * non-Timestamp VSL*() calls sorted by SLT_* tag, where an SLT_ tag is identifiable in the code. * VSLb_ts*() calls (Timestamp logging) * Some notes about logging struct http (headers & URL & method & reason & so forth), since that is all encapsulated by functions in cache_http.c, and hence does appear in a grep for "SLT_". My grep-foo skillz are average, so I may have missed some things, but nevertheless this gives us a fair amount of info. One thing I noticed (that I didn't know before) is that VSL_bin() is used if and only if the tag is SLT_H2*. That is, the "binary format" function is used exactly and only for the H2 tags. Best, Geoff -- ** * * UPLEX - Nils Goroll Systemoptimierung Scheffelstra?e 32 22301 Hamburg Tel +49 40 2880 5731 Mob +49 176 636 90917 Fax +49 40 42949753 http://uplex.de -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From scan-admin at coverity.com Sun May 12 11:25:24 2019 From: scan-admin at coverity.com (scan-admin at coverity.com) Date: Sun, 12 May 2019 11:25:24 +0000 (UTC) Subject: Coverity Scan: Analysis completed for varnish Message-ID: <5cd802a3efadc_22452ac098f38f5846b1@appnode-2.mail> Your request for analysis of varnish has been completed successfully. The results are available at https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V05UPxvVjWch-2Bd2MGckcRaZSCEJOPR4AEUn0hVASTtlJ23U2ffwbN1LtJbHcOCfQg-3D-3D_wrU9d1VlqIiuL6N0zVMze4Ep-2FR7u99vtLlE-2BlH3ENQD0dh1RBxZ5s88c1t4D6mjqhGe7vTGOxsUecY7d1KKed72bJsQe7gm5CzkxBuYwwuLpXtoc5iJPgA2qXvDaJ2DafO2yDk9HMf7nIr35P-2FIMveZsr7qotjw3D7IjvJtGm-2B7yhpnUapdglA5APQMUtsz4o7nSUJ29bpKyaNidzOX4SNwDIXn8vYpu2iMkflZt8dQ-3D Build ID: 255583 Analysis Summary: New defects found: 2 Defects eliminated: 5 If you have difficulty understanding any defects, email us at scan-admin at coverity.com, or post your question to StackOverflow at https://u2389337.ct.sendgrid.net/wf/click?upn=OgIsEqWzmIl4S-2FzEUMxLXL-2BukuZt9UUdRZhgmgzAKchwAzH1nH3073xDEXNRgHN6zzUI-2FRfbrE6mNOeeukHUQw-3D-3D_wrU9d1VlqIiuL6N0zVMze4Ep-2FR7u99vtLlE-2BlH3ENQD0dh1RBxZ5s88c1t4D6mjqhGe7vTGOxsUecY7d1KKed3qnonHsq6aowt7Ok-2FehkECWJswKeQFqO6G-2BWs31UcLxmfJp5pQS0kiFyloKI-2Bv6g0g-2BWA1yK9zgJRgs7I5lnpmTGSDBoEX2YzVEDEHWUQe8zIyjTK7qKLXXwD5y5iPgsQ42zKulfNWGSrHjLPYqm5g-3D From phk at phk.freebsd.dk Tue May 14 06:04:56 2019 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Tue, 14 May 2019 06:04:56 +0000 Subject: varnish gcov Message-ID: <32184.1557813896@critter.freebsd.dk> After a lot of comparisons I have changed the GCOV to use LLVM-8.0 because it is about twice as fast and (IMO) more honest than the GCC6 we used. This means that the overall score dropped a little bit. I also rescaled the "sparklines" to make incremental changes in the range we care about stand out more. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From kn at openbsd.org Tue May 14 15:43:57 2019 From: kn at openbsd.org (Klemens Nanni) Date: Tue, 14 May 2019 17:43:57 +0200 Subject: [PATCH] Prefer Python 3 tools Message-ID: <20190514154357.rsdkwmaqlsquqwsa@eru.my.domain> The last three commits already made configure recommend installing Python 3 packages and look for versioned executables, however with a low priority. This is a problem on systems such as OpenBSD 6.5 with a default Python version at 2.7, where 3.7 flavored Python packages get installed with a "-3" binary suffix. That is, when both rst2man and rst2man-3 are installed at configure time, the lower version will be picked unless explicitly passed through `--with-feature' arguments. Regardless of this specific case, trying more specificly versioned tool names first seems correctly in line with recent development and less error prone, so change it accordingly. --- configure.ac | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/configure.ac b/configure.ac index fe4225069..fbfea3e45 100644 --- a/configure.ac +++ b/configure.ac @@ -41,7 +41,7 @@ AC_ARG_WITH([rst2man], AS_HELP_STRING([--with-rst2man=PATH], [Location of rst2man (auto)]), [RST2MAN="$withval"], AC_CHECK_PROGS(RST2MAN, - [rst2man rst2man.py rst2man-3.6 rst2man-3], + [rst2man-3.6 rst2man-3 rst2man rst2man.py], [no])) if test "x$RST2MAN" = "xno"; then AC_MSG_ERROR( @@ -52,7 +52,7 @@ AC_ARG_WITH([sphinx-build], AS_HELP_STRING([--with-sphinx-build=PATH], [Location of sphinx-build (auto)]), [SPHINX="$withval"], AC_CHECK_PROGS(SPHINX, - [sphinx-build sphinx-build-3.6 sphinx-build-3], + [sphinx-build-3.6 sphinx-build-3 sphinx-build], [no])) if test "x$SPHINX" = "xno"; then AC_MSG_ERROR( @@ -63,7 +63,7 @@ AC_ARG_WITH([rst2html], AS_HELP_STRING([--with-rst2html=PATH], [Location of rst2html (auto)]), [RST2HTML="$withval"], AC_CHECK_PROGS(RST2HTML, - [rst2html rst2html.py rst2html-3.6 rst2html-3], + [rst2html-3.6 rst2html-3 rst2html rst2html.py], "no")) if test "x$RST2HTML" = "xno"; then -- 2.21.0 From scan-admin at coverity.com Sun May 19 11:23:41 2019 From: scan-admin at coverity.com (scan-admin at coverity.com) Date: Sun, 19 May 2019 11:23:41 +0000 (UTC) Subject: Coverity Scan: Analysis failed for varnish Message-ID: <5ce13cbd6ef17_25e02ac098f38f58466d@appnode-2.mail> Your request for analysis of varnish is failed. Analysis status: No action need The problem is on the Coverity server, and we will address it. Your request will be automatically submitted for analysis. If you do not see your build being analyzed, please email scan-admin at coverity.com. From fgsch at lodoss.net Sun May 26 10:29:37 2019 From: fgsch at lodoss.net (Federico Schwindt) Date: Sun, 26 May 2019 11:29:37 +0100 Subject: [PATCH] Prefer Python 3 tools In-Reply-To: <20190514154357.rsdkwmaqlsquqwsa@eru.my.domain> References: <20190514154357.rsdkwmaqlsquqwsa@eru.my.domain> Message-ID: Thanks for the PR. Makes sense. I've merged it. Best. On Tue, May 14, 2019 at 4:47 PM Klemens Nanni wrote: > The last three commits already made configure recommend installing > Python 3 packages and look for versioned executables, however with a low > priority. > > This is a problem on systems such as OpenBSD 6.5 with a default Python > version at 2.7, where 3.7 flavored Python packages get installed with > a "-3" binary suffix. That is, when both rst2man and rst2man-3 are > installed at configure time, the lower version will be picked unless > explicitly passed through `--with-feature' arguments. > > Regardless of this specific case, trying more specificly versioned tool > names first seems correctly in line with recent development and less > error prone, so change it accordingly. > --- > configure.ac | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/configure.ac b/configure.ac > index fe4225069..fbfea3e45 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -41,7 +41,7 @@ AC_ARG_WITH([rst2man], > AS_HELP_STRING([--with-rst2man=PATH], [Location of rst2man (auto)]), > [RST2MAN="$withval"], > AC_CHECK_PROGS(RST2MAN, > - [rst2man rst2man.py rst2man-3.6 rst2man-3], > + [rst2man-3.6 rst2man-3 rst2man rst2man.py], > [no])) > if test "x$RST2MAN" = "xno"; then > AC_MSG_ERROR( > @@ -52,7 +52,7 @@ AC_ARG_WITH([sphinx-build], > AS_HELP_STRING([--with-sphinx-build=PATH], [Location of sphinx-build > (auto)]), > [SPHINX="$withval"], > AC_CHECK_PROGS(SPHINX, > - [sphinx-build sphinx-build-3.6 sphinx-build-3], > + [sphinx-build-3.6 sphinx-build-3 sphinx-build], > [no])) > if test "x$SPHINX" = "xno"; then > AC_MSG_ERROR( > @@ -63,7 +63,7 @@ AC_ARG_WITH([rst2html], > AS_HELP_STRING([--with-rst2html=PATH], [Location of rst2html (auto)]), > [RST2HTML="$withval"], > AC_CHECK_PROGS(RST2HTML, > - [rst2html rst2html.py rst2html-3.6 rst2html-3], > + [rst2html-3.6 rst2html-3 rst2html rst2html.py], > "no")) > > if test "x$RST2HTML" = "xno"; then > -- > 2.21.0 > > > _______________________________________________ > varnish-dev mailing list > varnish-dev at varnish-cache.org > https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From scan-admin at coverity.com Sun May 26 11:27:18 2019 From: scan-admin at coverity.com (scan-admin at coverity.com) Date: Sun, 26 May 2019 11:27:18 +0000 (UTC) Subject: Coverity Scan: Analysis completed for varnish Message-ID: <5cea7815a2f0d_43b92ac098f38f584620@appnode-2.mail> Your request for analysis of varnish has been completed successfully. The results are available at https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V05UPxvVjWch-2Bd2MGckcRaZSCEJOPR4AEUn0hVASTtlJ23U2ffwbN1LtJbHcOCfQg-3D-3D_wrU9d1VlqIiuL6N0zVMze4Ep-2FR7u99vtLlE-2BlH3ENQAH6iQsWSvChHPzaDPQwwDifB8Gi1ZDPs9BiwZNksALkPPiushULDg7kz5SWGRxypcMQLlwcooVtvJTdeCAxmWKMTC4SnbVWnsu-2Fcw0vbkFNz5maCJnfdC7C8wp04YbGXbg0Q3h6BLOdVqtejyq5G4VJxOg7f0krhuke2VjoV49ys4iSVjKEEsBBuQOYjavO44-3D Build ID: 257234 Analysis Summary: New defects found: 1 Defects eliminated: 5 If you have difficulty understanding any defects, email us at scan-admin at coverity.com, or post your question to StackOverflow at https://u2389337.ct.sendgrid.net/wf/click?upn=OgIsEqWzmIl4S-2FzEUMxLXL-2BukuZt9UUdRZhgmgzAKchwAzH1nH3073xDEXNRgHN6zzUI-2FRfbrE6mNOeeukHUQw-3D-3D_wrU9d1VlqIiuL6N0zVMze4Ep-2FR7u99vtLlE-2BlH3ENQAH6iQsWSvChHPzaDPQwwDifB8Gi1ZDPs9BiwZNksALkHeIzew7ZFna-2F7bRsQ1BGHcfQ2GjlXR-2BgLPN9GTmI2hR2UslFkRhtgChtsJxXNPH24RoilzZwegS-2Ft9Aelr16fKqa-2FyBR8XX6W9tGy7YiLnFsR1J21kWLsg0fpyj5yGwkzzL3BJR7g8zcYIa1dt5eos-3D From scan-admin at coverity.com Tue May 28 21:46:16 2019 From: scan-admin at coverity.com (scan-admin at coverity.com) Date: Tue, 28 May 2019 21:46:16 +0000 (UTC) Subject: Coverity Scan: Analysis completed for varnish Message-ID: <5cedac283e359_43e52ac098f38f58465@appnode-2.mail> Your request for analysis of varnish has been completed successfully. The results are available at https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V05UPxvVjWch-2Bd2MGckcRaZSCEJOPR4AEUn0hVASTtlJ23U2ffwbN1LtJbHcOCfQg-3D-3D_wrU9d1VlqIiuL6N0zVMze4Ep-2FR7u99vtLlE-2BlH3ENQACO-2BCJgwFUVbof54kqDBxGcVNlVvLZvTKiXhYbA-2Fbt1aJr6LH25pBJywrnhALGGPIhKIUTKu18pwgu462bIsUVJBsbEMlAjDJ2k7sRin7iuAFi-2F0cJ2IKMaiIJfKBC5Cn-2BjRg-2Bdzr8j4C7tcS8G3r3a9I362h0irXu5-2ByozM75T3eHpN32PJSfjwi0Kqm2uqs-3D Build ID: 258549 Analysis Summary: New defects found: 0 Defects eliminated: 2