Build failed in Hudson: 3.HEAD-i386-Debian-sid #622

2011-03-11 Thread noc 
See 

Changes:

[Amos Jeffries ] Remove redundant FTP/Gopher checks

Identified by ICC.

[Amos Jeffries ] ICC build issue in ConnStateData::getConn

ICC complains about:
"type qualifier on return type is meaningless
inline ConnStateData * const getConn() const;
"

I believe this is const-correct. The incorrect version would be "& const"
But there is no harm in combining the two getConn() methods.

--
[...truncated 6572 lines...]
:56:
 undefined reference to `WriteRequest::CBDATA_WriteRequest'
fs/.libs/libfs.a(store_io_ufs.o): In function `UFSStoreState::doWrite()':
:298:
 undefined reference to `WriteRequest::WriteRequest(char const*, long, unsigned 
int, void (*)(void*))'
fs/.libs/libfs.a(store_io_ufs.o): In function `UFSStoreState::freePending()':
:425:
 undefined reference to `linklistShift'
:434:
 undefined reference to `linklistShift'
fs/.libs/libfs.a(store_io_ufs.o): In function `UFSStoreState::kickReadQueue()':
:446:
 undefined reference to `linklistShift'
fs/.libs/libfs.a(store_io_ufs.o): In function `UFSStoreState::queueRead(char*, 
unsigned int, long, void (*)(void*, char const*, int, RefCount), 
void*)':
:480:
 undefined reference to `linklistPush'
fs/.libs/libfs.a(store_io_ufs.o): In function `ReadRequest::operator 
new(unsigned int)':
:55:
 undefined reference to `ReadRequest::CBDATA_ReadRequest'
fs/.libs/libfs.a(store_io_ufs.o): In function `UFSStoreState::read_(char*, 
unsigned int, long, void (*)(void*, char const*, int, RefCount), 
void*)':
:222:
 undefined reference to `ReadRequest::ReadRequest(char*, long, unsigned int)'
fs/.libs/libfs.a(store_io_ufs.o): In function `UFSStoreState::queueWrite(char 
const*, unsigned int, long, void (*)(void*))':
:555:
 undefined reference to `linklistPush'
fs/.libs/libfs.a(store_io_ufs.o): In function `~UFSStoreState':
:414:
 undefined reference to `StoreIOState::~StoreIOState()'
:414:
 undefined reference to `StoreIOState::~StoreIOState()'
:414:
 undefined reference to `StoreIOState::~StoreIOState()'
:414:
 undefined reference to `StoreIOState::~StoreIOState()'
fs/.libs/libfs.a(store_io_ufs.o): In function `UFSStoreState':
:402:
 undefined reference to `StoreIOState::StoreIOState()'
:402:
 undefined reference to `StoreIOState::~StoreIOState()'
:402:
 undefined reference to `StoreIOState::StoreIOState()'
:402:
 undefined reference to `StoreIOState::~StoreIOState()'
fs/.libs/libfs.a(store_io_ufs.o): In function `UFSStr

Build failed in Hudson: 3.HEAD-i386-Debian-sid #621

2011-03-11 Thread noc 
See 

--
[...truncated 6576 lines...]
:56:
 undefined reference to `WriteRequest::CBDATA_WriteRequest'
fs/.libs/libfs.a(store_io_ufs.o): In function `UFSStoreState::doWrite()':
:298:
 undefined reference to `WriteRequest::WriteRequest(char const*, long, unsigned 
int, void (*)(void*))'
fs/.libs/libfs.a(store_io_ufs.o): In function `UFSStoreState::freePending()':
:425:
 undefined reference to `linklistShift'
:434:
 undefined reference to `linklistShift'
fs/.libs/libfs.a(store_io_ufs.o): In function `UFSStoreState::kickReadQueue()':
:446:
 undefined reference to `linklistShift'
fs/.libs/libfs.a(store_io_ufs.o): In function `UFSStoreState::queueRead(char*, 
unsigned int, long, void (*)(void*, char const*, int, RefCount), 
void*)':
:480:
 undefined reference to `linklistPush'
fs/.libs/libfs.a(store_io_ufs.o): In function `ReadRequest::operator 
new(unsigned int)':
:55:
 undefined reference to `ReadRequest::CBDATA_ReadRequest'
fs/.libs/libfs.a(store_io_ufs.o): In function `UFSStoreState::read_(char*, 
unsigned int, long, void (*)(void*, char const*, int, RefCount), 
void*)':
:222:
 undefined reference to `ReadRequest::ReadRequest(char*, long, unsigned int)'
fs/.libs/libfs.a(store_io_ufs.o): In function `UFSStoreState::queueWrite(char 
const*, unsigned int, long, void (*)(void*))':
:555:
 undefined reference to `linklistPush'
fs/.libs/libfs.a(store_io_ufs.o): In function `~UFSStoreState':
:414:
 undefined reference to `StoreIOState::~StoreIOState()'
:414:
 undefined reference to `StoreIOState::~StoreIOState()'
:414:
 undefined reference to `StoreIOState::~StoreIOState()'
:414:
 undefined reference to `StoreIOState::~StoreIOState()'
fs/.libs/libfs.a(store_io_ufs.o): In function `UFSStoreState':
:402:
 undefined reference to `StoreIOState::StoreIOState()'
:402:
 undefined reference to `StoreIOState::~StoreIOState()'
:402:
 undefined reference to `StoreIOState::StoreIOState()'
:402:
 undefined reference to `StoreIOState::~StoreIOState()'
fs/.libs/libfs.a(store_io_ufs.o): In function `UFSStrategy::create(SwapDir*, 
StoreEntry*, void (*)(void*, int, RefCount), void (*)(void*, int, 
RefCount), void*)':
:610:
 undefined reference to `typeinfo for StoreIOState'
fs/.libs/libfs.a(store_io_ufs.o): In function `UFSStrategy::open(SwapDir*, 
StoreEntry

Re: [RFC] straightening out unit-test dependencies

2011-03-11 Thread Amos Jeffries 

On 22/02/11 14:17, Alex Rousskov wrote:

On 02/18/2011 12:56 AM, Amos Jeffries wrote:

During the shuffling work for SourceLayout I keep running headlong into
the few remaining unit tests which include nearly all of the squid
sources due to legacy design.

This is further hampered by the fact that the worst ones appear short
but make use of nested $() sub-list includes. So not only do they have
dependency on the .cc files but on the .cc files incuded by otehr unit
tests as well.

Does anyone object to a patch which unwinds these nested $() lists and
makes the remaining messy unit tests include their full minimal list of
.cc directly?


FWIW, I cannot object to anything you think will fix test cases! We all
know how much time is often wasted on trying to make them work again
after moving a few misplaced code lines.

I am sure there are useful cases somewhere, but I wonder whether the net
result has been positive so far (rhetorical). I would not object to
removing or disabling poorly written cases either.


Thank you,

Alex.


For the record this is now done. rev11276

Amos
--
Please be using
  Current Stable Squid 2.7.STABLE9 or 3.1.11
  Beta testers wanted for 3.2.0.5

Build failed in Hudson: 3.HEAD-i386-Debian-sid #620

2011-03-11 Thread noc 
See 

--
Started by upstream project "3.HEAD-amd64-CentOS-5.3" build number 1197
Building remotely on rio.treenet
ERROR: Failed to clean the workspace
hudson.util.IOException2: remote file operation failed: 
 at 
hudson.remoting.Channel@5b6ef20:rio.treenet
at hudson.FilePath.act(FilePath.java:752)
at hudson.FilePath.act(FilePath.java:738)
at hudson.FilePath.deleteRecursive(FilePath.java:822)
at hudson.plugins.bazaar.BazaarSCM.clone(BazaarSCM.java:227)
at hudson.plugins.bazaar.BazaarSCM.checkout(BazaarSCM.java:194)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1171)
at 
hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:499)
at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:415)
at hudson.model.Run.run(Run.java:1362)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:145)
Caused by: java.io.IOException: Unable to delete 

at hudson.Util.deleteFile(Util.java:263)
at hudson.Util.deleteRecursive(Util.java:305)
at hudson.Util.deleteContentsRecursive(Util.java:224)
at hudson.Util.deleteRecursive(Util.java:304)
at hudson.Util.deleteContentsRecursive(Util.java:224)
at hudson.Util.deleteRecursive(Util.java:304)
at hudson.Util.deleteContentsRecursive(Util.java:224)
at hudson.Util.deleteRecursive(Util.java:304)
at hudson.Util.deleteContentsRecursive(Util.java:224)
at hudson.Util.deleteRecursive(Util.java:304)
at hudson.Util.deleteContentsRecursive(Util.java:224)
at hudson.Util.deleteRecursive(Util.java:304)
at hudson.FilePath$9.invoke(FilePath.java:824)
at hudson.FilePath$9.invoke(FilePath.java:822)
at hudson.FilePath$FileCallableWrapper.call(FilePath.java:1931)
at hudson.remoting.UserRequest.perform(UserRequest.java:114)
at hudson.remoting.UserRequest.perform(UserRequest.java:48)
at hudson.remoting.Request$2.run(Request.java:270)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)

Re: %adapt::

2011-03-11 Thread Amos Jeffries 

On 12/03/11 12:59, Alex Rousskov wrote:

Hello,

 All of the following is related to the %adapt::

No need for new names IMO.
 We have headers" and 

IMO:
 * Change existing parameterized adapt::happens with parameterized adapt:: * Add new parameterized adapt::ICAP headers. As per the documented semantics of  * Implement non-parameterized adapt::headers (somehow).


Amos
--
Please be using
  Current Stable Squid 2.7.STABLE9 or 3.1.11
  Beta testers wanted for 3.2.0.5

%adapt::

2011-03-11 Thread Alex Rousskov 
Hello,

All of the following is related to the %adapt::

Build failed in Hudson: 3.HEAD-i386-Debian-sid #619

2011-03-11 Thread noc 
See 

--
Started by upstream project "3.HEAD-amd64-CentOS-5.3" build number 1196
Building remotely on rio.treenet
ERROR: Failed to clean the workspace
hudson.util.IOException2: remote file operation failed: 
 at 
hudson.remoting.Channel@5b6ef20:rio.treenet
at hudson.FilePath.act(FilePath.java:752)
at hudson.FilePath.act(FilePath.java:738)
at hudson.FilePath.deleteRecursive(FilePath.java:822)
at hudson.plugins.bazaar.BazaarSCM.clone(BazaarSCM.java:227)
at hudson.plugins.bazaar.BazaarSCM.checkout(BazaarSCM.java:194)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1171)
at 
hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:499)
at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:415)
at hudson.model.Run.run(Run.java:1362)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:145)
Caused by: java.io.IOException: Unable to delete 

at hudson.Util.deleteFile(Util.java:263)
at hudson.Util.deleteRecursive(Util.java:305)
at hudson.Util.deleteContentsRecursive(Util.java:224)
at hudson.Util.deleteRecursive(Util.java:304)
at hudson.Util.deleteContentsRecursive(Util.java:224)
at hudson.Util.deleteRecursive(Util.java:304)
at hudson.Util.deleteContentsRecursive(Util.java:224)
at hudson.Util.deleteRecursive(Util.java:304)
at hudson.Util.deleteContentsRecursive(Util.java:224)
at hudson.Util.deleteRecursive(Util.java:304)
at hudson.Util.deleteContentsRecursive(Util.java:224)
at hudson.Util.deleteRecursive(Util.java:304)
at hudson.FilePath$9.invoke(FilePath.java:824)
at hudson.FilePath$9.invoke(FilePath.java:822)
at hudson.FilePath$FileCallableWrapper.call(FilePath.java:1931)
at hudson.remoting.UserRequest.perform(UserRequest.java:114)
at hudson.remoting.UserRequest.perform(UserRequest.java:48)
at hudson.remoting.Request$2.run(Request.java:270)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)

Build failed in Hudson: 3.HEAD-i386-Debian-sid #618

2011-03-11 Thread noc 
See 

--
Started by upstream project "3.HEAD-amd64-CentOS-5.3" build number 1195
Building remotely on rio.treenet
ERROR: Failed to clean the workspace
hudson.util.IOException2: remote file operation failed: 
 at 
hudson.remoting.Channel@5b6ef20:rio.treenet
at hudson.FilePath.act(FilePath.java:752)
at hudson.FilePath.act(FilePath.java:738)
at hudson.FilePath.deleteRecursive(FilePath.java:822)
at hudson.plugins.bazaar.BazaarSCM.clone(BazaarSCM.java:227)
at hudson.plugins.bazaar.BazaarSCM.checkout(BazaarSCM.java:194)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1171)
at 
hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:499)
at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:415)
at hudson.model.Run.run(Run.java:1362)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:145)
Caused by: java.io.IOException: Unable to delete 

at hudson.Util.deleteFile(Util.java:263)
at hudson.Util.deleteRecursive(Util.java:305)
at hudson.Util.deleteContentsRecursive(Util.java:224)
at hudson.Util.deleteRecursive(Util.java:304)
at hudson.Util.deleteContentsRecursive(Util.java:224)
at hudson.Util.deleteRecursive(Util.java:304)
at hudson.Util.deleteContentsRecursive(Util.java:224)
at hudson.Util.deleteRecursive(Util.java:304)
at hudson.Util.deleteContentsRecursive(Util.java:224)
at hudson.Util.deleteRecursive(Util.java:304)
at hudson.Util.deleteContentsRecursive(Util.java:224)
at hudson.Util.deleteRecursive(Util.java:304)
at hudson.FilePath$9.invoke(FilePath.java:824)
at hudson.FilePath$9.invoke(FilePath.java:822)
at hudson.FilePath$FileCallableWrapper.call(FilePath.java:1931)
at hudson.remoting.UserRequest.perform(UserRequest.java:114)
at hudson.remoting.UserRequest.perform(UserRequest.java:48)
at hudson.remoting.Request$2.run(Request.java:270)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)

Build failed in Hudson: 3.HEAD-i386-Debian-sid #617

2011-03-11 Thread noc 
See 

--
Started by upstream project "3.HEAD-amd64-CentOS-5.3" build number 1194
Building remotely on rio.treenet
ERROR: Failed to clean the workspace
hudson.util.IOException2: remote file operation failed: 
 at 
hudson.remoting.Channel@5b6ef20:rio.treenet
at hudson.FilePath.act(FilePath.java:752)
at hudson.FilePath.act(FilePath.java:738)
at hudson.FilePath.deleteRecursive(FilePath.java:822)
at hudson.plugins.bazaar.BazaarSCM.clone(BazaarSCM.java:227)
at hudson.plugins.bazaar.BazaarSCM.checkout(BazaarSCM.java:194)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1171)
at 
hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:499)
at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:415)
at hudson.model.Run.run(Run.java:1362)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:145)
Caused by: java.io.IOException: Unable to delete 

at hudson.Util.deleteFile(Util.java:263)
at hudson.Util.deleteRecursive(Util.java:305)
at hudson.Util.deleteContentsRecursive(Util.java:224)
at hudson.Util.deleteRecursive(Util.java:304)
at hudson.Util.deleteContentsRecursive(Util.java:224)
at hudson.Util.deleteRecursive(Util.java:304)
at hudson.Util.deleteContentsRecursive(Util.java:224)
at hudson.Util.deleteRecursive(Util.java:304)
at hudson.Util.deleteContentsRecursive(Util.java:224)
at hudson.Util.deleteRecursive(Util.java:304)
at hudson.Util.deleteContentsRecursive(Util.java:224)
at hudson.Util.deleteRecursive(Util.java:304)
at hudson.FilePath$9.invoke(FilePath.java:824)
at hudson.FilePath$9.invoke(FilePath.java:822)
at hudson.FilePath$FileCallableWrapper.call(FilePath.java:1931)
at hudson.remoting.UserRequest.perform(UserRequest.java:114)
at hudson.remoting.UserRequest.perform(UserRequest.java:48)
at hudson.remoting.Request$2.run(Request.java:270)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)

Re: New external_acl helper squid_kerb_ldap

2011-03-11 Thread Markus Moeller 

Hi Amos,

  Could you let me know what are valid respones from the negotiate helper 
compared to ntlm helper ? It seems I have to translate them.


Thank you
Markus


"Markus Moeller"  wrote in message 
news:ilcv9m$kra$1...@dough.gmane.org...

Hi Amos,

  When I use my wrapper I had to modify the samba ntlm_auth helper to 
return another AF string.  I run 3.0.STABLE25 and

/usr/bin/ntlm_auth -V
Version 3.5.4-2489-SUSE-SL11.3


FATAL: authenticateNegotiateHandleReply: *** Unsupported helper response 
***, 'AF WIN2003R2\administrator'


Would it be possible that the Negotiate reply handler accepts both formats 
? I used


auth_param negotiate program /usr/sbin/negotiate_wrapper -d --ntlm 
/usr/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp --kerberos 
/usr/sbin/squid_kerb_auth -d -s GSS_C_NO_NAME



Thank you
Markus


2011/03/10 22:44:34| negotiate_wrapper: Got 'YR 
TlRMTVNTUAABB4IIogAFAs4ODw==' from squid 
(length: 59).
2011/03/10 22:44:34| negotiate_wrapper: Decode 
'TlRMTVNTUAABB4IIogAFAs4ODw==' (decoded 
length: 40).

2011/03/10 22:44:34| negotiate_wrapper: received type 1 NTLM token
2011/03/10 22:44:34| negotiate_wrapper: Got 'KK 
TlRMTVNTUAADGAAYAIAYABgAmBIAEgBIGgAaAFoMAAwAdACwBYKIogUCzg4PVwBJAE4AMgAwADAAMwBSADIAQQBkAG0AaQBuAGkAcwB0AHIAYQB0AG8AcgBXADIASwAzAFIAMgCkBlG0MZTzRwBFkwULOmCaiWNR/69aXr44O8ZJJ/pEwzE=' 
from squid (length: 239).
2011/03/10 22:44:34| negotiate_wrapper: Decode 
'TlRMTVNTUAADGAAYAIAYABgAmBIAEgBIGgAaAFoMAAwAdACwBYKIogUCzg4PVwBJAE4AMgAwADAAMwBSADIAQQBkAG0AaQBuAGkAcwB0AHIAYQB0AG8AcgBXADIASwAzAFIAMgCkBlG0MZTzRwBFkwULOmCaiWNR/69aXr44O8ZJJ/pEwzE=' 
(decoded length: 176).

2011/03/10 22:44:34| negotiate_wrapper: received type 3 NTLM token
2011/03/10 22:44:35| storeDirWriteCleanLogs: Starting...
2011/03/10 22:44:35| WARNING: Closing open FD   25
2011/03/10 22:44:35|   Finished.  Wrote 2747 entries.
2011/03/10 22:44:35|   Took 0.00 seconds (1852326.37 entries/sec).
FATAL: authenticateNegotiateHandleReply: *** Unsupported helper response 
***, 'AF WIN2003R2\administrator'


Squid Cache (Version 3.0.STABLE25): Terminated abnormally.
CPU Usage: 0.225 seconds = 0.017 user + 0.208 sys
Maximum Resident Size: 39392 KB
Page faults with physical i/o: 0
Memory usage for squid via mallinfo():
   total space in arena:3244 KB
   Ordinary blocks: 3163 KB  7 blks
   Small blocks:   0 KB  0 blks
   Holding blocks:  3664 KB 13 blks
   Free Small blocks:  0 KB
   Free Ordinary blocks:  80 KB
   Total in use:6827 KB 210%
   Total free:80 KB 2%
2011/03/10 22:44:38| Starting Squid Cache version 3.0.STABLE25 for 
i686-suse-linux-gnu...




"Amos Jeffries"  wrote in message 
news:4c651eb3.6020...@treenet.co.nz...

Markus Moeller wrote:


"Amos Jeffries"  wrote in message 
news:4c5187d2.5010...@treenet.co.nz...

Markus Moeller wrote:

Hi Amos,


Hi Amos



  How does your time look like now ?

Regards
Markus



Looks passable. I have not had time for a detailed view of the logics.
I'll commit this tomorrow with a name tweak, the naming scheme has been 
through the external acl helpers too now. I'll just tack ext_ on the 
front and _acl on the back of the existing binary name and update the 
docs to match.


One thing that worries me still is the RUN_IFELSE autoconf macros still 
being added to configure.in. I'm sure there is a macro that checked for 
defined values of things inside headers without running stuff. If you 
can try and find that it would be great not to have to run anything on 
build.




I have 4 RUN_IFELSE.

The first is to check to check that ldap works with the provided 
libraries. Is that unusual ? Any other suggestion how to check ?


Um, okay. Thats reasonable on build. Duplicating at run-time may also be 
useful since the particular run-time libraries are not always the ones 
built against.


The other three are to determine the LDAP vendor, which is a define 
statement in one of the ldap header files and as it is a string in a 
define I can not use any header grep nor proprocessor checks ( at least 
I do not know of any).


Nasty. Oh well.


Okay. Have applied to Squid-3.HEAD with the extra ext_*_acl bits on the 
binary name and docs for the current naming style.


Amos
--
Please be using
  Current Stable Squid 2.7.STABLE9 or 3.1.6
  Beta testers wanted for 3.2.0.1

Build failed in Hudson: 3.HEAD-i386-Debian-sid #616

2011-03-11 Thread noc 
See 

Changes:

[Automatic source maintenance ] SourceFormat 
Enforcement

--
[...truncated 8432 lines...]
:56:
 undefined reference to `WriteRequest::CBDATA_WriteRequest'
fs/.libs/libfs.a(store_io_ufs.o): In function `UFSStoreState::doWrite()':
:298:
 undefined reference to `WriteRequest::WriteRequest(char const*, long, unsigned 
int, void (*)(void*))'
fs/.libs/libfs.a(store_io_ufs.o): In function `UFSStoreState::freePending()':
:425:
 undefined reference to `linklistShift'
:434:
 undefined reference to `linklistShift'
fs/.libs/libfs.a(store_io_ufs.o): In function `UFSStoreState::kickReadQueue()':
:446:
 undefined reference to `linklistShift'
fs/.libs/libfs.a(store_io_ufs.o): In function `UFSStoreState::queueRead(char*, 
unsigned int, long, void (*)(void*, char const*, int, RefCount), 
void*)':
:480:
 undefined reference to `linklistPush'
fs/.libs/libfs.a(store_io_ufs.o): In function `ReadRequest::operator 
new(unsigned int)':
:55:
 undefined reference to `ReadRequest::CBDATA_ReadRequest'
fs/.libs/libfs.a(store_io_ufs.o): In function `UFSStoreState::read_(char*, 
unsigned int, long, void (*)(void*, char const*, int, RefCount), 
void*)':
:222:
 undefined reference to `ReadRequest::ReadRequest(char*, long, unsigned int)'
fs/.libs/libfs.a(store_io_ufs.o): In function `UFSStoreState::queueWrite(char 
const*, unsigned int, long, void (*)(void*))':
:555:
 undefined reference to `linklistPush'
fs/.libs/libfs.a(store_io_ufs.o): In function `~UFSStoreState':
:414:
 undefined reference to `StoreIOState::~StoreIOState()'
:414:
 undefined reference to `StoreIOState::~StoreIOState()'
:414:
 undefined reference to `StoreIOState::~StoreIOState()'
:414:
 undefined reference to `StoreIOState::~StoreIOState()'
fs/.libs/libfs.a(store_io_ufs.o): In function `UFSStoreState':
:402:
 undefined reference to `StoreIOState::StoreIOState()'
:402:
 undefined reference to `StoreIOState::~StoreIOState()'
:402:
 undefined reference to `StoreIOState::StoreIOState()'
:402:
 undefined reference to `StoreIOState::~StoreIOState()'
fs/.libs/libfs.a(store_io_ufs.o): In function `UFSStrategy::create(SwapDir*, 
StoreEntry*, void (*)(void*, int, RefCount), void (*)(void*, int, 
RefCount), void*)':
:610:
 undefined reference to `typeinfo for StoreIOState'
fs/.libs/l

Re: New external_acl helper squid_kerb_ldap

2011-03-11 Thread Markus Moeller 

Hi Amos,

  When I use my wrapper I had to modify the samba ntlm_auth helper to 
return another AF string.  I run 3.0.STABLE25 and

/usr/bin/ntlm_auth -V
Version 3.5.4-2489-SUSE-SL11.3


FATAL: authenticateNegotiateHandleReply: *** Unsupported helper response 
***, 'AF WIN2003R2\administrator'


Would it be possible that the Negotiate reply handler accepts both formats ? 
I used


auth_param negotiate program /usr/sbin/negotiate_wrapper -d --ntlm 
/usr/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp --kerberos 
/usr/sbin/squid_kerb_auth -d -s GSS_C_NO_NAME



Thank you
Markus


2011/03/10 22:44:34| negotiate_wrapper: Got 'YR 
TlRMTVNTUAABB4IIogAFAs4ODw==' from squid 
(length: 59).
2011/03/10 22:44:34| negotiate_wrapper: Decode 
'TlRMTVNTUAABB4IIogAFAs4ODw==' (decoded length: 
40).

2011/03/10 22:44:34| negotiate_wrapper: received type 1 NTLM token
2011/03/10 22:44:34| negotiate_wrapper: Got 'KK 
TlRMTVNTUAADGAAYAIAYABgAmBIAEgBIGgAaAFoMAAwAdACwBYKIogUCzg4PVwBJAE4AMgAwADAAMwBSADIAQQBkAG0AaQBuAGkAcwB0AHIAYQB0AG8AcgBXADIASwAzAFIAMgCkBlG0MZTzRwBFkwULOmCaiWNR/69aXr44O8ZJJ/pEwzE=' 
from squid (length: 239).
2011/03/10 22:44:34| negotiate_wrapper: Decode 
'TlRMTVNTUAADGAAYAIAYABgAmBIAEgBIGgAaAFoMAAwAdACwBYKIogUCzg4PVwBJAE4AMgAwADAAMwBSADIAQQBkAG0AaQBuAGkAcwB0AHIAYQB0AG8AcgBXADIASwAzAFIAMgCkBlG0MZTzRwBFkwULOmCaiWNR/69aXr44O8ZJJ/pEwzE=' 
(decoded length: 176).

2011/03/10 22:44:34| negotiate_wrapper: received type 3 NTLM token
2011/03/10 22:44:35| storeDirWriteCleanLogs: Starting...
2011/03/10 22:44:35| WARNING: Closing open FD   25
2011/03/10 22:44:35|   Finished.  Wrote 2747 entries.
2011/03/10 22:44:35|   Took 0.00 seconds (1852326.37 entries/sec).
FATAL: authenticateNegotiateHandleReply: *** Unsupported helper response 
***, 'AF WIN2003R2\administrator'


Squid Cache (Version 3.0.STABLE25): Terminated abnormally.
CPU Usage: 0.225 seconds = 0.017 user + 0.208 sys
Maximum Resident Size: 39392 KB
Page faults with physical i/o: 0
Memory usage for squid via mallinfo():
   total space in arena:3244 KB
   Ordinary blocks: 3163 KB  7 blks
   Small blocks:   0 KB  0 blks
   Holding blocks:  3664 KB 13 blks
   Free Small blocks:  0 KB
   Free Ordinary blocks:  80 KB
   Total in use:6827 KB 210%
   Total free:80 KB 2%
2011/03/10 22:44:38| Starting Squid Cache version 3.0.STABLE25 for 
i686-suse-linux-gnu...




"Amos Jeffries"  wrote in message 
news:4c651eb3.6020...@treenet.co.nz...

Markus Moeller wrote:


"Amos Jeffries"  wrote in message 
news:4c5187d2.5010...@treenet.co.nz...

Markus Moeller wrote:

Hi Amos,


Hi Amos



  How does your time look like now ?

Regards
Markus



Looks passable. I have not had time for a detailed view of the logics.
I'll commit this tomorrow with a name tweak, the naming scheme has been 
through the external acl helpers too now. I'll just tack ext_ on the 
front and _acl on the back of the existing binary name and update the 
docs to match.


One thing that worries me still is the RUN_IFELSE autoconf macros still 
being added to configure.in. I'm sure there is a macro that checked for 
defined values of things inside headers without running stuff. If you 
can try and find that it would be great not to have to run anything on 
build.




I have 4 RUN_IFELSE.

The first is to check to check that ldap works with the provided 
libraries. Is that unusual ? Any other suggestion how to check ?


Um, okay. Thats reasonable on build. Duplicating at run-time may also be 
useful since the particular run-time libraries are not always the ones 
built against.


The other three are to determine the LDAP vendor, which is a define 
statement in one of the ldap header files and as it is a string in a 
define I can not use any header grep nor proprocessor checks ( at least I 
do not know of any).


Nasty. Oh well.


Okay. Have applied to Squid-3.HEAD with the extra ext_*_acl bits on the 
binary name and docs for the current naming style.


Amos
--
Please be using
  Current Stable Squid 2.7.STABLE9 or 3.1.6
  Beta testers wanted for 3.2.0.1

Re: FYI: http timeout headers

2011-03-11 Thread Amos Jeffries 

On 11/03/11 11:57, Robert Collins wrote:

On Fri, Mar 11, 2011 at 11:16 AM, Mark Nottingham  wrote:

Right. I think the authors hope that intermediaries (proxies and gateways) will 
adapt their policies (within configured limits) based upon what they see in 
incoming connection-timeout headers, and rewrite the outgoing 
connection-timeout headers appropriately.

I'm not sure whether that will happen, hence my question. I'm even less sure 
about the use cases for request-timeout, for the reasons you mention.


I suspect that this is overengineering : scalable proxies really
shouldn't need special handling for very long requests, and proxies
that need special handling will still want timeouts to guard against
e.g. roaming clients leaving stale connections.

Simply recommending that intermediaries depend on TCP to time out
connections might be sufficient, simpler, and allow room for clean
layering to deal with roaming clients and the like without making
requests larger.

-Rob



 I think Squid has not traditionally obeyed the TTLs in Keep-Alive: 
anyway. Which is part of where this problem arises.  I may be wrong, 
through I did not see any such timeout code when changing the pconns 
recently.
  Patches to make IdleConnList obey Keep-Alive headers which are 
already being sent by many sites would be welcome.



The tricky bits as Robert said come when desired TTL is longer than 
Squid config TTL. Providing an HTTP control to force it longer will not 
be accepted lightly by the site admins and will lead to calls for yet 
another violation override-* directive which makes the whole system and 
standard useless and worse; leas to false expectations.



Also, what happens once Squid obeys both?
  Keep-Alive: 300
  Connection-Timeout: 3600

I like the idea of the timeout applying to upgraded requests despite the 
data transferred (and by extension CONNECT). It means we can cut 
connections at X seconds even if there are bytes flowing still or 
recently. (Reading the words as stated, they might not have foreseen 
that interpretation).


Though I fail to see where the timeouts would not more reasonably be 
accomplished by standard parameter definitions for Keep-Alive.


IMHO they would be better defining params for the Keep-Alive: and 
Expect: headers. Such that the client can "Expect: keep-alive" with some 
TTL Keep-Alive: values. Any knowing step in the chain can 417 it with 
failure details, or the thing can succeed and acts as they desire.



/rant warning/

Off the topic of this draft. It references long-polling being cut as one 
of its basic problems being solved.


 Firstly I've been reminded repeatedly that there are numerous networks 
where the admin is penalized if a request takes more than X 
milliseconds. Implications there are clear.


 Secondly are my own experiences with certain sites. These channels 
long-poll for hours! When the game player is not present they just 
continue until cut. Several such channels are open at any given time 
from a single page, greatly restricting the browsers few 
connections-per-proxy. The long-poll itself is the cause of many slow 
client experiences to my knowledge.

 /rant

Amos
--
Please be using
  Current Stable Squid 2.7.STABLE9 or 3.1.11
  Beta testers wanted for 3.2.0.5