From martin at varnish-software.com Thu Feb 6 13:41:23 2014 From: martin at varnish-software.com (Martin Blix Grydeland) Date: Thu, 6 Feb 2014 14:41:23 +0100 Subject: Varnishhist In-Reply-To: <52F0FCF0.3060105@smartjog.com> References: <52F0FCF0.3060105@smartjog.com> Message-ID: Hiya Guillaume, The patches looks good, and quite complete. Though there are some structure things that I believe needs to be addressed here. Where varnishtop concerns itself with single log records and keeps statistics on how many occurrences of these it finds, varnishhist concerns itself with transactions. A transaction here then is the complete set of log records for some activity, e.g. a client request. So a single request transaction then should make a single data point for the graph, where the necessary information (e.g. size of data / hit flag) is extracted from those log records belonging to that transaction. The current loop design in accumulate() gets this wrong, where the data point adding is done once for every log record instead of once per transaction. This makes a lot more data points than should have been inserted, using mostly bogus data. So I think the following changes has to be made: - accumulate() outer loop should skip transactions of the wrong type. correct type would be client requests (and possibly backend requests?) - accumulate() inner loop needs to run over the log records and extract the necessary information (HIT flag, size/timing etc.). Should also make sure a ReqEnd record has been seen to filter out e.g. restarts. - accumulate() should then add data point only when inner loop sees it has the information necessary (e.g. found the log record that had the field we search for) - The -g option should be limited. Since we are looking for transactions only, the "raw" grouping mode doesn't make any sense (it makes every log record reported seen as a transaction in itself from the API). varnishncsa does something similar there. - The -i -I -x -X options I think should be removed. These options are there to filter output of utilities, controlling which records should go into the output. But since varnishhist deals with the transaction level they aren't applicable. (Also makes the call to VSL_Match() in the loop superfluous) - Some thought needs to be put into whether we support backend requests. First iteration could perhaps just look at client requests, and remove the -b and -c options too. Backend transactions can then be added later. Regards, Martin Blix Grydeland On 4 February 2014 15:45, Guillaume Quintard < guillaume.quintard at smartjog.com> wrote: > Here are the patches. They should be pretty complete compared to the > varnishtop ones :-) Let me know if you are missing something. > > I haven't touched the Makefile.phk though, as varnishadm was failing > too, and IIRC, autotools are here to last. You may want to rename the > "-p period" argument, but other than that, I think the work is done. > > EDIT: patches! > > -- > Guillaume Quintard > > -- *Martin Blix Grydeland* Senior Developer | Varnish Software AS Cell: +47 21 98 92 60 We Make Websites Fly! -------------- next part -------------- An HTML attachment was scrubbed... URL: From guillaume.quintard at smartjog.com Thu Feb 6 15:30:42 2014 From: guillaume.quintard at smartjog.com (Guillaume Quintard) Date: Thu, 6 Feb 2014 16:30:42 +0100 Subject: Varnishhist In-Reply-To: References: <52F0FCF0.3060105@smartjog.com> Message-ID: <52F3AAA2.60306@smartjog.com> Indeed, I was a bit careless with that accumulate function. Let me fix that and offer a patches additional series. -- Guillaume Quintard From phk at phk.freebsd.dk Mon Feb 17 08:56:49 2014 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 17 Feb 2014 08:56:49 +0000 Subject: 4.0 into the home-stretch Message-ID: <61169.1392627409@critter.freebsd.dk> Last wednesday I went to Oslo and tried to hammer out a plan for releasing 4.0-R with the V-S crew. The big thing is documentation, there is a lot of docs to be written and you are all cordially invited to help out :-) We also hashed out a plan for the backend-fetch-retry-error issue that keeps confounding me, and I think it will hold up. On the client side: vcl_error{} becomes vcl_synth{} The client side alyways get an object back from a fetch, fetch failures will be handled on the backend side. The object we get back may be a 503 and it may be a pass, but it is an object. This laves only one "internal" error on the client side: Restarting too many times. We will handle this by making an attempt to restart past $max_restarts turn into: return(synth(503)); On the backend side: vcl_backend_fetch{} Prepares the the request to be sent to the backend. If we get a reply from the backend, we got to vcl_backend_response{} which can return 'deliver', 'retry' or 'abandon' (pass is done by setting beresp.do_pass, because it is orthogonal) If we do not get a reply or if v_b_r returns 'abandon' we end up in vcl_backend_error{}, which in the builtin-vcl creates a 503 pass error page like vcl_error{} does today. Possible returns are retry and deliver. Too may retries take you to v_b_e{}. I was proposed to make obj.* entirely read-only. Changing obj.ttl was essentially done to hack up grace, and no longer makes any sense. Obj.hits and obj.last_use are of speculative use at best, mostly for debugging, and it's questionable if they should live on individual objects or on the objhdr in the first place. Making objects read/only once created, will allow us to implement more efficient stevedore modules (at least we think so). We also want to move the LRU processing into the stevedores, but that does not have to happen for 4.0, that can be done later. Martin promised to sort out the new tool-lib he made before 4.0 X-Forward-For and Connection: close for pipe will be moved to C-code: They can be fixed in VCL if people have special requirements. I need to implement the acct/stats VSL records (per VDD13Q4 and subsequent email threads). Anything missing ? We're currently aiming at a release in the april 1st time frame. -- 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 fgsch at lodoss.net Mon Feb 17 19:41:53 2014 From: fgsch at lodoss.net (Federico G. Schwindt) Date: Mon, 17 Feb 2014 19:41:53 +0000 Subject: PATCH: remove backward compat 1/2 Message-ID: <20140217194153.ba0421ed34937f0ffa2c4ecb@lodoss.net> Hi, As discussed on irc, since varnish 4 needs manual updating it might be time to gc some of the backward compatibility foo. The diff below gc "remove" and the ".request" and ".response" variants in favour of "unset", ".method" and ".reason". Tests to follow. f.- diff --git a/doc/sphinx/reference/vcl.rst b/doc/sphinx/reference/vcl.rst index 8cb7439..9f384f8 100644 --- a/doc/sphinx/reference/vcl.rst +++ b/doc/sphinx/reference/vcl.rst @@ -662,9 +662,6 @@ server.identity req.method The request type (e.g. "GET", "HEAD"). -req.request - For backward compatibility. Same as req.method. - req.url The requested URL. @@ -714,9 +711,6 @@ request (either for a cache miss or for pass or pipe mode): bereq.method The request type (e.g. "GET", "HEAD"). -bereq.request - For backward compatibility. Same as bereq.method. - bereq.url The requested URL. @@ -759,9 +753,6 @@ beresp.status beresp.reason The HTTP status message returned by the server. -beresp.response - For backward compatibility. Same as beresp.reason. - beresp.http.header The corresponding HTTP header. @@ -821,9 +812,6 @@ obj.status obj.reason The HTTP status message returned by the server. -obj.response - For backward compatibility. Same as obj.reason. - obj.http.header The corresponding HTTP header. @@ -859,9 +847,6 @@ resp.status resp.reason The HTTP status message that will be returned. -resp.response - For backward compatibility. Same as resp.reason. - resp.http.header The corresponding HTTP header. diff --git a/lib/libvcc/generate.py b/lib/libvcc/generate.py index 01a6243..466bf6b 100755 --- a/lib/libvcc/generate.py +++ b/lib/libvcc/generate.py @@ -578,11 +578,6 @@ The client's IP address. # Backwards compatibility: aliases = [ - ('req.request', 'req.method'), - ('bereq.request', 'bereq.method'), - ('beresp.response', 'beresp.reason'), - ('resp.response', 'resp.reason'), - ('obj.response', 'obj.reason'), ] stv_variables = ( diff --git a/lib/libvcc/vcc_action.c b/lib/libvcc/vcc_action.c index 7e9bf2e..b0f7d98 100644 --- a/lib/libvcc/vcc_action.c +++ b/lib/libvcc/vcc_action.c @@ -411,7 +411,6 @@ static struct action_table { { "hash_data", parse_hash_data, VCL_MET_HASH }, { "new", parse_new, VCL_MET_INIT}, { "purge", parse_purge, VCL_MET_MISS | VCL_MET_HIT }, - { "remove", parse_unset }, /* backward compatibility */ { "return", parse_return }, { "rollback", parse_rollback }, { "set", parse_set }, From fgsch at lodoss.net Mon Feb 17 19:43:11 2014 From: fgsch at lodoss.net (Federico G. Schwindt) Date: Mon, 17 Feb 2014 19:43:11 +0000 Subject: PATCH: remove backward compat 2/2 Message-ID: <20140217194311.c8bee3462f056aa82d195ec1@lodoss.net> And the tests. f.- diff --git a/bin/varnishtest/tests/b00018.vtc b/bin/varnishtest/tests/b00018.vtc index 3989b57..682c19c 100644 --- a/bin/varnishtest/tests/b00018.vtc +++ b/bin/varnishtest/tests/b00018.vtc @@ -9,7 +9,7 @@ varnish v1 -vcl+backend { sub vcl_backend_response { set beresp.http.Foo = "bar"; set beresp.status = 523; - set beresp.response = "not ok"; + set beresp.reason = "not ok"; set beresp.uncacheable = true; set beresp.ttl = 0s; return (deliver); diff --git a/bin/varnishtest/tests/b00019.vtc b/bin/varnishtest/tests/b00019.vtc index 6b33702..597e8b9 100644 --- a/bin/varnishtest/tests/b00019.vtc +++ b/bin/varnishtest/tests/b00019.vtc @@ -28,13 +28,13 @@ varnish v1 -vcl+backend { sub vcl_error { if (req.restarts == 2) { set obj.status = 200; - set obj.response = "restart=2"; + set obj.reason = "restart=2"; } elsif (req.restarts > 2) { set obj.status = 501; - set obj.response = "restart>2"; + set obj.reason = "restart>2"; } elsif (req.restarts < 2) { set obj.status = 500; - set obj.response = "restart<2"; + set obj.reason = "restart<2"; } } } -start diff --git a/bin/varnishtest/tests/b00035.vtc b/bin/varnishtest/tests/b00035.vtc deleted file mode 100644 index dbe8a6f..0000000 --- a/bin/varnishtest/tests/b00035.vtc +++ /dev/null @@ -1,26 +0,0 @@ -varnishtest "{be}req.request compat check" - -server s1 { - rxreq - expect req.method == "GETABCD" - txresp -} -start - -varnish v1 -vcl+backend { - - sub vcl_recv { - set req.method = req.request + "A"; - set req.request = req.method + "B"; - return (pass); - } - - sub vcl_backend_fetch { - set bereq.method = bereq.request + "C"; - set bereq.request = bereq.method + "D"; - } -} -start - -client c1 { - txreq - rxresp -} -run diff --git a/bin/varnishtest/tests/b00036.vtc b/bin/varnishtest/tests/b00036.vtc index cb0b6e5..4cd6e17 100644 --- a/bin/varnishtest/tests/b00036.vtc +++ b/bin/varnishtest/tests/b00036.vtc @@ -9,7 +9,7 @@ server s1 { varnish v1 -vcl+backend { sub vcl_recv { - if (req.request == "PURGE") { + if (req.method == "PURGE") { return (purge); } } diff --git a/bin/varnishtest/tests/r00292.vtc b/bin/varnishtest/tests/r00292.vtc index f6bc807..4972188 100644 --- a/bin/varnishtest/tests/r00292.vtc +++ b/bin/varnishtest/tests/r00292.vtc @@ -18,8 +18,8 @@ server s1 { varnish v1 -vcl+backend { sub vcl_recv { - remove req.http.hdr1; - remove req.http.hdr5; + unset req.http.hdr1; + unset req.http.hdr5; } } -start diff --git a/bin/varnishtest/tests/r00494.vtc b/bin/varnishtest/tests/r00494.vtc index 31a9d6e..cb0bbe8 100644 --- a/bin/varnishtest/tests/r00494.vtc +++ b/bin/varnishtest/tests/r00494.vtc @@ -11,7 +11,7 @@ server s1 { varnish v1 -vcl+backend { sub vcl_backend_response { set beresp.http.bar = beresp.http.foo; - remove beresp.http.foo; + unset beresp.http.foo; } } -start diff --git a/bin/varnishtest/tests/r00965.vtc b/bin/varnishtest/tests/r00965.vtc index 72317de..ccd01b5 100644 --- a/bin/varnishtest/tests/r00965.vtc +++ b/bin/varnishtest/tests/r00965.vtc @@ -8,7 +8,7 @@ server s1 { varnish v1 -vcl+backend { sub vcl_recv { if (req.http.X-Banned == "check") { - remove req.http.X-Banned; + unset req.http.X-Banned; } elseif (req.restarts == 0) { set req.http.X-Banned = "check"; if (req.http.x-pass) { diff --git a/bin/varnishtest/tests/v00001.vtc b/bin/varnishtest/tests/v00001.vtc index 4f77f25..1798ec9 100644 --- a/bin/varnishtest/tests/v00001.vtc +++ b/bin/varnishtest/tests/v00001.vtc @@ -1,4 +1,4 @@ -varnishtest "VCL/VRT: url/request/proto/response/status" +varnishtest "VCL/VRT: url/request/proto/reason/status" server s1 { @@ -28,14 +28,14 @@ varnish v1 -vcl+backend { } sub vcl_backend_response { set beresp.http.foobar = - beresp.proto + beresp.response + beresp.status; + beresp.proto + beresp.reason + beresp.status; set beresp.proto = "HTTP/1.2"; - set beresp.response = "For circular files"; + set beresp.reason = "For circular files"; set beresp.status = 903; } sub vcl_deliver { set resp.proto = "HTTP/1.2"; - set resp.response = "Naah, lets fail it"; + set resp.reason = "Naah, lets fail it"; set resp.status = 904; # XXX should be moved to it's own test set resp.http.x-served-by-hostname = server.hostname; From fgsch at lodoss.net Tue Feb 18 22:32:31 2014 From: fgsch at lodoss.net (Federico Schwindt) Date: Tue, 18 Feb 2014 22:32:31 +0000 Subject: 4.0 into the home-stretch In-Reply-To: <61169.1392627409@critter.freebsd.dk> References: <61169.1392627409@critter.freebsd.dk> Message-ID: Some comments below. > This laves only one "internal" error on the client side: > Restarting too many times. We will handle this by making > an attempt to restart past $max_restarts turn into: > > return(synth(503)); Can we apply the same logic for 400s or anything that we cannot parse (talking about CVE-2013-4484 mostly here) ? In some (most?) situations people might want to show a customised error page and not the 400 currently returned by varnish. > If we get a reply from the backend, we got to vcl_backend_response{} > which can return 'deliver', 'retry' or 'abandon' (pass is done > by setting beresp.do_pass, because it is orthogonal) I believe you meant beresp.uncacheable here. > I was proposed to make obj.* entirely read-only. Question: in the new world if you want to, say do a redirect, where and which variable you'll need to set? Currently this is done in vcl_error{} changing obj.http.Location and obj.status. On Mon, Feb 17, 2014 at 8:56 AM, Poul-Henning Kamp wrote: > > Last wednesday I went to Oslo and tried to hammer out a plan for releasing > 4.0-R with the V-S crew. > > The big thing is documentation, there is a lot of docs to be written > and you are all cordially invited to help out :-) > > We also hashed out a plan for the backend-fetch-retry-error issue that > keeps confounding me, and I think it will hold up. > > On the client side: > > vcl_error{} becomes vcl_synth{} > > The client side alyways get an object back from a fetch, > fetch failures will be handled on the backend side. The > object we get back may be a 503 and it may be a pass, but > it is an object. > > This laves only one "internal" error on the client side: > Restarting too many times. We will handle this by making > an attempt to restart past $max_restarts turn into: > > return(synth(503)); > > On the backend side: > > vcl_backend_fetch{} Prepares the the request to be sent to > the backend. > > If we get a reply from the backend, we got to > vcl_backend_response{} > which can return 'deliver', 'retry' or 'abandon' (pass is done > by setting beresp.do_pass, because it is orthogonal) > > If we do not get a reply or if v_b_r returns 'abandon' we end up > in vcl_backend_error{}, which in the builtin-vcl creates a 503 > pass error page like vcl_error{} does today. Possible returns > are retry and deliver. > > Too may retries take you to v_b_e{}. > > I was proposed to make obj.* entirely read-only. > > Changing obj.ttl was essentially done to hack up grace, and no longer > makes any sense. > > Obj.hits and obj.last_use are of speculative use at best, mostly > for debugging, and it's questionable if they should live on individual > objects or on the objhdr in the first place. > > Making objects read/only once created, will allow us to implement > more efficient stevedore modules (at least we think so). > > We also want to move the LRU processing into the stevedores, but > that does not have to happen for 4.0, that can be done later. > > Martin promised to sort out the new tool-lib he made before 4.0 > > X-Forward-For and Connection: close for pipe will be moved to > C-code: They can be fixed in VCL if people have special requirements. > > I need to implement the acct/stats VSL records (per VDD13Q4 and > subsequent email threads). > > Anything missing ? > > We're currently aiming at a release in the april 1st time frame. > > > -- > 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. > > _______________________________________________ > 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 phk at phk.freebsd.dk Wed Feb 19 07:54:40 2014 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Wed, 19 Feb 2014 07:54:40 +0000 Subject: 4.0 into the home-stretch In-Reply-To: References: <61169.1392627409@critter.freebsd.dk> Message-ID: <71140.1392796480@critter.freebsd.dk> In message , Federico Schwindt writes: >> This laves only one "internal" error on the client side: >> Restarting too many times. We will handle this by making >> an attempt to restart past $max_restarts turn into: >> >> return(synth(503)); > >Can we apply the same logic for 400s or anything that we cannot parse >(talking about CVE-2013-4484 mostly here) ? As a result of that CVE, I took the decision that if Varnish cannot parse the complete request it is not safe to call VCL with partial information. >In some (most?) situations people might want to show a customised error >page and not the 400 currently returned by varnish. I do appreciate that, but seriously: Who but script-kiddie robots get 400 in the first place ? And if they get 400 on one transaction, what reason do we have to belive they will not also get it for any other transaction ? >> If we get a reply from the backend, we got to vcl_backend_response{} >> which can return 'deliver', 'retry' or 'abandon' (pass is done >> by setting beresp.do_pass, because it is orthogonal) > >I believe you meant beresp.uncacheable here. yes :-) >> I was proposed to make obj.* entirely read-only. > >Question: in the new world if you want to, say do a redirect, where and >which variable you'll need to set? >Currently this is done in vcl_error{} changing obj.http.Location and >obj.status. vcl_error{} becomes vcl_synth{} for just that kind of job. -- 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 lkarsten at varnish-software.com Wed Feb 19 09:27:44 2014 From: lkarsten at varnish-software.com (Lasse Karstensen) Date: Wed, 19 Feb 2014 10:27:44 +0100 Subject: Announcing Varnish Developer Day 2014Q1 (2014-03-18) Message-ID: <20140219092743.GA21990@immer.varnish-software.com> Dear Varnish developers. The Varnish developer day for Q1 2014 will be held in Paris, France on Tuesday, March 18th 2014. Our sponsor for the meeting is SmartJog. We have a wiki page for the details, including list of participants. https://www.varnish-cache.org/trac/wiki/VDD14Q1 Please add/mark yourself as attending/confirmed as usual. -- Lasse Karstensen Release manager From guillaume.quintard at smartjog.com Wed Feb 19 09:54:29 2014 From: guillaume.quintard at smartjog.com (Guillaume Quintard) Date: Wed, 19 Feb 2014 10:54:29 +0100 Subject: Announcing Varnish Developer Day 2014Q1 (2014-03-18) In-Reply-To: <20140219092743.GA21990@immer.varnish-software.com> References: <20140219092743.GA21990@immer.varnish-software.com> Message-ID: <53047F55.4060404@smartjog.com> On 02/19/2014 10:27 AM, Lasse Karstensen wrote: > The Varnish developer day for Q1 2014 will be held in Paris, France on > > Tuesday, March 18th 2014. > > Our sponsor for the meeting is SmartJog. > > We have a wiki page for the details, including list of participants. > > https://www.varnish-cache.org/trac/wiki/VDD14Q1 > > Please add/mark yourself as attending/confirmed as usual. Hi all, First, please let me say it will be a pleasure to host this VDD, and I hope it will be as productive as the last one. Second, I do have a minor precision on the name, we had a rebranding, and we are now called Arkena (http://www.arkena.com/). Anyway, see you in a month! -- Guillaume Quintard From phk at phk.freebsd.dk Wed Feb 19 10:06:18 2014 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Wed, 19 Feb 2014 10:06:18 +0000 Subject: Announcing Varnish Developer Day 2014Q1 (2014-03-18) In-Reply-To: <53047F55.4060404@smartjog.com> References: <20140219092743.GA21990@immer.varnish-software.com> <53047F55.4060404@smartjog.com> Message-ID: <19094.1392804378@critter.freebsd.dk> In message <53047F55.4060404 at smartjog.com>, Guillaume Quintard writes: >First, please let me say it will be a pleasure to host this VDD, and I >hope it will be as productive as the last one. And thanks for hosting it, much appreciated! -- 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 perbu at varnish-software.com Fri Feb 21 10:19:22 2014 From: perbu at varnish-software.com (Per Buer) Date: Fri, 21 Feb 2014 11:19:22 +0100 Subject: director error messages Message-ID: Hi. I'm going through the docs and updating the various bits to V4. When testing the directors I ran into the following error message: :varnish perbu$ ./bin/varnishd/varnishd -a :2000 -d -f /tmp/test.vcl Message from VCC-compiler: Not running as root, no priv-sep Missing errorhandling code in parse_new(), vcc_action.c line 193: Condition((sy2) != 0) not true. Running VCC-compiler failed, signal 6 VCL compilation failed This is the VCL I tried to compile: vcl 4.0; backend server1 { .host = "192.168.0.10"; } backend server2{ .host = "192.168.0.10"; } sub vcl_init { new bar = directors.round_robin(); bar.add_backend(server1, server2); } The error message isn't really helpful and I think this is a bug in the VCL parser/compiler. -- *Per Buer* CTO | Varnish Software Phone: +47 958 39 117 | Skype: per.buer We Make Websites Fly! Winner of the Red Herring Top 100 Global Award 2013 -------------- next part -------------- An HTML attachment was scrubbed... URL: From perbu at varnish-software.com Fri Feb 21 10:47:13 2014 From: perbu at varnish-software.com (Per Buer) Date: Fri, 21 Feb 2014 11:47:13 +0100 Subject: director error messages In-Reply-To: References: Message-ID: Hi, On Fri, Feb 21, 2014 at 11:19 AM, Per Buer wrote: > Hi. > > I'm going through the docs and updating the various bits to V4. When > testing the directors I ran into the following error message: > > :varnish perbu$ ./bin/varnishd/varnishd -a :2000 -d -f /tmp/test.vcl > Message from VCC-compiler: > Not running as root, no priv-sep > Missing errorhandling code in parse_new(), vcc_action.c line 193: > Condition((sy2) != 0) not true. > Running VCC-compiler failed, signal 6 > > VCL compilation failed > > > (..) > sub vcl_init { > new bar = directors.round_robin(); > bar.add_backend(server1, server2); > } > > > The error message isn't really helpful and I think this is a bug in the > VCL parser/compiler. > (I know what the error in the VCL is.) -- *Per Buer* CTO | Varnish Software Phone: +47 958 39 117 | Skype: per.buer We Make Websites Fly! Winner of the Red Herring Top 100 Global Award 2013 -------------- next part -------------- An HTML attachment was scrubbed... URL: From tfheen at fastly.com Tue Feb 25 13:26:27 2014 From: tfheen at fastly.com (Tollef Fog Heen) Date: Tue, 25 Feb 2014 14:26:27 +0100 Subject: [master] 6737d14 Ignore various autogenerated files In-Reply-To: References: Message-ID: 2014-02-24 9:42 GMT+01:00 Per Buer : > # Various auto-tools artifacts > @@ -78,6 +79,8 @@ cscope.*out > /man/vsc2rst > /man/*.7 > /man/*.1 > +/bin/*/*.1 > +/bin/*/*.rst > None of those should be generated any longer. Which files do you have there, and do they reappear if you clean your source tree properly first? -------------- next part -------------- An HTML attachment was scrubbed... URL: From perbu at varnish-software.com Tue Feb 25 15:01:53 2014 From: perbu at varnish-software.com (Per Buer) Date: Tue, 25 Feb 2014 16:01:53 +0100 Subject: [master] 6737d14 Ignore various autogenerated files In-Reply-To: References: Message-ID: On Tue, Feb 25, 2014 at 2:26 PM, Tollef Fog Heen wrote: > 2014-02-24 9:42 GMT+01:00 Per Buer : > >> # Various auto-tools artifacts >> @@ -78,6 +79,8 @@ cscope.*out >> /man/vsc2rst >> /man/*.7 >> /man/*.1 >> +/bin/*/*.1 >> +/bin/*/*.rst >> > > None of those should be generated any longer. Which files do you have > there, and do they reappear if you clean your source tree properly first? > If I run "make clean" they are still present in my checkout. >From "git status": # bin/varnishadm/varnishadm.1 # bin/varnishd/varnishd.1 # bin/varnishhist/varnishhist.1 # bin/varnishlog/varnishlog.1 # bin/varnishlog/varnishlog_options.rst # bin/varnishlog/varnishlog_synopsis.rst # bin/varnishncsa/varnishncsa.1 # bin/varnishncsa/varnishncsa_options.rst # bin/varnishncsa/varnishncsa_synopsis.rst # bin/varnishreplay/varnishreplay.1 # bin/varnishsizes/ # bin/varnishstat/varnishstat.1 # bin/varnishtest/varnishtest.1 # bin/varnishtop/varnishtop.1 -- *Per Buer* CTO | Varnish Software Phone: +47 958 39 117 | Skype: per.buer We Make Websites Fly! Winner of the Red Herring Top 100 Global Award 2013 -------------- next part -------------- An HTML attachment was scrubbed... URL: From tfheen at fastly.com Tue Feb 25 15:03:39 2014 From: tfheen at fastly.com (Tollef Fog Heen) Date: Tue, 25 Feb 2014 16:03:39 +0100 Subject: [master] 6737d14 Ignore various autogenerated files In-Reply-To: References: Message-ID: 2014-02-25 16:01 GMT+01:00 Per Buer : > On Tue, Feb 25, 2014 at 2:26 PM, Tollef Fog Heen wrote: > >> 2014-02-24 9:42 GMT+01:00 Per Buer : >> >>> # Various auto-tools artifacts >>> @@ -78,6 +79,8 @@ cscope.*out >>> /man/vsc2rst >>> /man/*.7 >>> /man/*.1 >>> +/bin/*/*.1 >>> +/bin/*/*.rst >>> >> >> None of those should be generated any longer. Which files do you have >> there, and do they reappear if you clean your source tree properly first? >> > > If I run "make clean" they are still present in my checkout. > Try running git clean -fdx first and then autoreconf, configure, make - Tollfe -------------- next part -------------- An HTML attachment was scrubbed... URL: From perbu at varnish-software.com Tue Feb 25 15:20:41 2014 From: perbu at varnish-software.com (Per Buer) Date: Tue, 25 Feb 2014 16:20:41 +0100 Subject: [master] 6737d14 Ignore various autogenerated files In-Reply-To: References: Message-ID: On Tue, Feb 25, 2014 at 4:03 PM, Tollef Fog Heen wrote: > 2014-02-25 16:01 GMT+01:00 Per Buer : > > On Tue, Feb 25, 2014 at 2:26 PM, Tollef Fog Heen wrote: >> >>> 2014-02-24 9:42 GMT+01:00 Per Buer : >>> >>>> # Various auto-tools artifacts >>>> @@ -78,6 +79,8 @@ cscope.*out >>>> /man/vsc2rst >>>> /man/*.7 >>>> /man/*.1 >>>> +/bin/*/*.1 >>>> +/bin/*/*.rst >>>> >>> >>> None of those should be generated any longer. Which files do you have >>> there, and do they reappear if you clean your source tree properly first? >>> >> >> If I run "make clean" they are still present in my checkout. >> > > Try running git clean -fdx first and then autoreconf, configure, make > It's clean now. Git has stopped complaining. Show we remove the two lines from gitignore? - Tollfe > Is this your USA-friendly name now? :-) Per. -- *Per Buer* CTO | Varnish Software Phone: +47 958 39 117 | Skype: per.buer We Make Websites Fly! Winner of the Red Herring Top 100 Global Award 2013 -------------- next part -------------- An HTML attachment was scrubbed... URL: From tfheen at fastly.com Tue Feb 25 17:08:13 2014 From: tfheen at fastly.com (Tollef Fog Heen) Date: Tue, 25 Feb 2014 18:08:13 +0100 Subject: [master] 6737d14 Ignore various autogenerated files In-Reply-To: References: Message-ID: 2014-02-25 16:20 GMT+01:00 Per Buer : > It's clean now. Git has stopped complaining. Show we remove the two lines > from gitignore? > Yes, please. > - Tollfe >> > > Is this your USA-friendly name now? :-) > :-P Tollef actually works surprisingly well in English considering its roots. - Tollef -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin at varnish-software.com Wed Feb 26 16:08:22 2014 From: martin at varnish-software.com (Martin Blix Grydeland) Date: Wed, 26 Feb 2014 17:08:22 +0100 Subject: Varnishhist In-Reply-To: <52F3AAA2.60306@smartjog.com> References: <52F0FCF0.3060105@smartjog.com> <52F3AAA2.60306@smartjog.com> Message-ID: Patches has been merged. Thanks Guillaume for the good work :) Martin On 6 February 2014 16:30, Guillaume Quintard < guillaume.quintard at smartjog.com> wrote: > Indeed, I was a bit careless with that accumulate function. Let me fix > that and offer a patches additional series. > > -- > Guillaume Quintard > > -- *Martin Blix Grydeland* Senior Developer | Varnish Software AS Cell: +47 21 98 92 60 We Make Websites Fly! -------------- next part -------------- An HTML attachment was scrubbed... URL: