Re: Build failed in Hudson: 3.HEAD-i386-FreeBSD-6.4 #444

This is on west: checking sasl/sasl.h usability... no checking sasl/sasl.h presence... no checking for sasl/sasl.h... no checking sasl.h usability... no checking sasl.h presence... no checking for sasl.h... no checking for sasl_errstring in -lsasl2... no checking for sasl_errstring in

Re: Build failed in Hudson: 3.HEAD-i386-FreeBSD-6.4 #444

On Thu, 19 Aug 2010 08:10:01 +0200, Kinkie gkin...@gmail.com wrote: This is on west: checking sasl/sasl.h usability... no checking sasl/sasl.h presence... no checking for sasl/sasl.h... no checking sasl.h usability... no checking sasl.h presence... no checking for sasl.h... no checking

Hudson build is back to normal: 3.HEAD-i386-FreeBSD-6.4 #446

See http://build.squid-cache.org/job/3.HEAD-i386-FreeBSD-6.4/446/changes

Re: Build failed in Hudson: 3.HEAD-i386-FreeBSD-6.4 #444

/usr/local/include/sasl/sasl.h exists currently on west. Unless someone answered your plea and installed it between now and the test it appears to be a configure problem. Worked around by specifying CPPFLAGS and LDFLAGS for extra include paths (in the node properties, not in the projects'

Build failed in Hudson: 3.HEAD-amd64-CentOS-5.3 #762

See http://build.squid-cache.org/job/3.HEAD-amd64-CentOS-5.3/762/changes Changes: [Francesco Chemolli kin...@squid-cache.org] configure.in fix: properly pass default hosts_file option around during build. [Amos Jeffries amosjeffr...@squid-cache.org] Bundle the purge and hexd tools with Squid

Re: [PATCH] Compliance: rename Trailers header to Trailer everywhere.

On 08/18/2010 10:09 PM, Alex Rousskov wrote: Compliance: rename Trailers header to Trailer everywhere. RFC 2616 section 13.5.1 has a typo in Trailers header name. The correct name is Trailer. See http://trac.tools.ietf.org/wg/httpbis/trac/ticket/9 Co-Advisor test cases:

[PREVIEW] 1xx response forwarding

On Mon, 16 Aug 2010 15:53:42 -0600, Alex Rousskov rouss...@measurement-factory.com wrote: Hello, We need to forward 1xx control messages from servers to clients. I see two implementation options: 1. Use Store. Squid client side expects responses via storeClientCopy, so we will be

[PATCH] Compliance: respond to OPTIONS requests with zero Max-Forwards value.

Compliance: respond to OPTIONS requests with zero Max-Forwards value. RFC 2616 section 9.2 says that a proxy MUST NOT forward requests with a zero Max-Forwards value. RFC 2616 does not define proper OPTIONS responses, so we consider successful responses optional and reply with 501 Not

Build failed in Hudson: 3.HEAD-amd64-CentOS-5.3 #763

See http://build.squid-cache.org/job/3.HEAD-amd64-CentOS-5.3/763/changes Changes: [Automatic source maintenance squid...@squid-cache.org] SourceFormat Enforcement [Francesco Chemolli kin...@squid-cache.org] configure.in fix: properly pass default hosts_file option around during build.

compat/unsafe.h

Stumbled over compat/unsafe.h again when trying to compile trunk after the purge merge. Imho these rules in compat/unsafe.h should be dropped, replaced by coding standards for the different sections and auditing. - The rules originally come from lazyness in Squid-2 where we did not want to check

[MERGE] Kill compat/unsafe.h, not really needed and causes more grief than gain

# Bazaar merge directive format 2 (Bazaar 0.90) # revision_id: hen...@henriknordstrom.net-20100820031034-\ # 0o3f9jw06pqkgmwa # target_branch: http://www.squid-cache.org/bzr/squid3/trunk/ # testament_sha1: 7c770c668bbf0875624a280061c125890faeda6d # timestamp: 2010-08-20 05:10:39 +0200 #

Build failed in Hudson: 3.HEAD-amd64-CentOS-5.3 #764

See http://build.squid-cache.org/job/3.HEAD-amd64-CentOS-5.3/764/changes Changes: [Henrik Nordstrom hen...@henriknordstrom.net] Kill redundant hexd program from purge. There is too many other tools for producing a readable hexdump of a file. [Henrik Nordstrom hen...@henriknordstrom.net] Also

Re: [MERGE] Kill compat/unsafe.h, not really needed and causes more grief than gain

+1 --     /kinkie