Re: Fwd: Better Windows support for Bazaar.
> On Thu, 2009-04-30 at 15:10 +1200, Amos Jeffries wrote: > >> > Well if it can reduce the 2-3 MB bzr currently insists on telling me >> its >> > transferred just to save a few lines of patch I think its worth it. >> > >> >> Just did this for me: > >> [\ ]952kB @1kB/s | Running post_commit hooks >> [bzr-email] - Stage 6/6 >> rio:# >> >> ... 2-lines in only 1 MB :( >> It did get to ~100kB/s in the middle so the slowness is not as bad as it >> looks from that. > > Thats not upgraded yet though :) Oh I see. I thought you were saying you got 12KB transfer on the existing bzr. Well, with a 2-order of magnitude reduction in bandwidth. +1+1+1... Amos
Re: Fwd: Better Windows support for Bazaar.
On Thu, 2009-04-30 at 15:10 +1200, Amos Jeffries wrote: > > Well if it can reduce the 2-3 MB bzr currently insists on telling me its > > transferred just to save a few lines of patch I think its worth it. > > > > Just did this for me: > [\ ]952kB @1kB/s | Running post_commit hooks > [bzr-email] - Stage 6/6 > rio:# > > ... 2-lines in only 1 MB :( > It did get to ~100kB/s in the middle so the slowness is not as bad as it > looks from that. Thats not upgraded yet though :) -Rob signature.asc Description: This is a digitally signed message part
Re: Fwd: Better Windows support for Bazaar.
>> On Wed, 2009-04-29 at 16:45 -0600, Alex Rousskov wrote: >>> On 04/16/2009 12:26 PM, Guido Serassio wrote: >>> >>> > But is not clear to me if Bazaar on squid-cache.org should be >>> upgraded >>> > with the rc version to support new functionality. >>> >>> Can you ask Karl? He seems to be willing to help. >> >> 1.14 has been released [yesterday], so we *can* upgrade squid-cache.org. >> We don't need to - the support for line ending filtering is entirely a >> local working configuration, the trunk branch and server have no need to >> change. >> >> I think we should upgrade bzr, as the 1.14 server is much more >> efficient. >> >> -Rob >> > > Well if it can reduce the 2-3 MB bzr currently insists on telling me its > transferred just to save a few lines of patch I think its worth it. > Just did this for me: rio:# bzr diff === modified file 'src/debug.cc' --- src/debug.cc2009-04-12 08:17:19 + +++ src/debug.cc2009-04-30 02:58:54 + @@ -456,6 +456,8 @@ #endif /* HAVE_SYSLOG */ +/* Pre-Init TZ env, see bug #2656 */ +tzset(); } void rio:# bzr commit Committing to: . modified src/debug.cc [##\ ] 11kB @2kB/s | Collecting changes [Directory 88] - Stage 1/6 [#/ ] 12kB @0kB/s | Uploading data to master branch - Stage 4/6 ... [- ]949kB @1kB/s | Uploading data to master branch - Stage:Finishing pack 5/5 Committed revision 9669. [\ ]952kB @1kB/s | Running post_commit hooks [bzr-email] - Stage 6/6 rio:# ... 2-lines in only 1 MB :( It did get to ~100kB/s in the middle so the slowness is not as bad as it looks from that. Amos
Re: status of bugs 2540 and 2541
> Hi, > > Sent these patches quite some time ago. > > Thanks, > > Matt > They got lost in the data heap that is Squid-2 bugs. The Squid-2 is being left mostly fallow these days as the active developers are all working on Squid-3. Since the Squid-3 code is identical in these spots, if we can work out the correct fixes they are likely to be fixed there first and back-ported. 2450: The URL normalization does appear to be incomplete. A new option is not needed though. I'd prefer if the normalization was fixed to make vport usable this way. 2451: I'm not keen on adding goto to the code. See bug report for new patch. Also, I would like to add some unit-tests to verify the correct behavior in future. Are you able to specify the input states to strListGetItem() that you see triggering this failure and what is expected to be correct handling. Thanks Amos
Re: Fwd: Better Windows support for Bazaar.
On Thu, 2009-04-30 at 12:52 +1200, Amos Jeffries wrote: > Well if it can reduce the 2-3 MB bzr currently insists on telling me its > transferred just to save a few lines of patch I think its worth it. For me, pushing a single patch, is ~128kb of traffic (the counter measures both directions). -Rob signature.asc Description: This is a digitally signed message part
Re: Fwd: Better Windows support for Bazaar.
> On Wed, 2009-04-29 at 16:45 -0600, Alex Rousskov wrote: >> On 04/16/2009 12:26 PM, Guido Serassio wrote: >> >> > But is not clear to me if Bazaar on squid-cache.org should be upgraded >> > with the rc version to support new functionality. >> >> Can you ask Karl? He seems to be willing to help. > > 1.14 has been released [yesterday], so we *can* upgrade squid-cache.org. > We don't need to - the support for line ending filtering is entirely a > local working configuration, the trunk branch and server have no need to > change. > > I think we should upgrade bzr, as the 1.14 server is much more > efficient. > > -Rob > Well if it can reduce the 2-3 MB bzr currently insists on telling me its transferred just to save a few lines of patch I think its worth it. Amos
Re: Is heap used?
> On Wed, Apr 29, 2009 at 5:09 PM, Amos Jeffries > wrote: >> Kinkie wrote: >>> >>> Hi all, >>> Â while walking the sources to check for documentation to write, I've >>> noticed that the heap code (defined in include/heap.h and lib/heap.c) >>> doesn't seem to be used anywhere. >>> Is it confirmed? If so, is there any good reason not to remove it? >>> >> >> A lot of the lib/*.c files are auto-inserted in place of missing system >> files by configure. I expect its needed on some system somewhere for the >> librepl.la stuff. > > Gah! You're right. My grep attempt somehow missed it. > Thanks for pointing out. > You can ignore lib/* entirely if you like. I'm going to have to troll through it and shuffle stuff out anyways so the documentation may change a little then anyways. Some is external code we can't just add to randomly either without copyright updates etc. Amos
status of bugs 2540 and 2541
Hi, Sent these patches quite some time ago. Thanks, Matt
Re: Fwd: Better Windows support for Bazaar.
On Wed, 2009-04-29 at 16:45 -0600, Alex Rousskov wrote: > On 04/16/2009 12:26 PM, Guido Serassio wrote: > > > But is not clear to me if Bazaar on squid-cache.org should be upgraded > > with the rc version to support new functionality. > > Can you ask Karl? He seems to be willing to help. 1.14 has been released [yesterday], so we *can* upgrade squid-cache.org. We don't need to - the support for line ending filtering is entirely a local working configuration, the trunk branch and server have no need to change. I think we should upgrade bzr, as the 1.14 server is much more efficient. -Rob signature.asc Description: This is a digitally signed message part
Re: Fwd: Better Windows support for Bazaar.
On 04/16/2009 12:26 PM, Guido Serassio wrote: > But is not clear to me if Bazaar on squid-cache.org should be upgraded > with the rc version to support new functionality. Can you ask Karl? He seems to be willing to help. Thank you, Alex. > Regards > > Guido > >> From: "Karl Fogel" >> To: "Guido Serassio" , >> "Segreteria Acme Consulting S.r.l." >> Cc: "Sidnei da Silva" , >> "Martin Aspeli" , >> "Christian Robottom Reis" >> Reply-To: "Karl Fogel" >> >> Hi -- we saw your page about how Squid 3 development was being delayed >> by Bazaar's problems on Windows: >> >> http://squid.acmeconsulting.it/ >> >> Clicking on "Squid 3 for Windows" shows the reasons: >> >>"The development of Squid 3 for Windows (3.0 and 3.1 branches) is >>stopped since the bazaar migration of the Squid 3 VCS because the >>inability of Bazaar to handle correctly real multiplatforms >>development projects. [...]" >> >> It's improved now. You might already know: the end-of-line conversion >> feature has landed in Bazaar. It's in the 1.14 release candidate, and >> it would be great if you could test it. The feature's behavior is >> described at: http://tinyurl.com/bzr-eol >> >> You can get 1.14rc1 from http://bazaar-vcs.org/Download, which links to >> bzr-1.14rc1.tar.gz... >> >> ...which of course should *also* be available as bzr-1.14rc1.zip! >> >> We are aware of this discrepancy. Right now, we're working on making >> Windows installers available for the Bazaar nightly snapshots, so that >> Windows-based developers can use the latest code as easily as anyone >> else. As part of that process, we might also be able to make release >> candidates available in .zip and/or installer form. In the meantime, >> the 1.14rc1 source dist is available, and has the improved line-ending >> support. >> >> It would be great if you could: >> >> a) Use it, and let us know on baz...@lists.canonical.com if the >> line-ending conversion support solves your problem. >> >> b) Change the "Squid 3 for Windows" page to encourage other >> people to try 1.14rc1 too. >> >> The more Windows developers use Bazaar, the better its Windows support >> will get. For our part, we will work on making those Windows >> installers. If you want, I can let you know when they're done. >> >> Best, >> -Karl Fogel >> > > > - > > Guido Serassio > Acme Consulting S.r.l. - Microsoft Certified Partner > Via Lucia Savarino, 1 10098 - Rivoli (TO) - ITALY > Tel. : +39.011.9530135 Fax. : +39.011.9781115 > Email: guido.seras...@acmeconsulting.it > WWW: http://www.acmeconsulting.it/
Re: conflict in parameter
FYI: Original Message Subject:conflict in parameter Date: Mon, 20 Apr 2009 06:15:09 -0400 From: nima chavooshi To: i...@squid-cache.org Hi thanks for your efforts There is conflict with "pipeline_prefetch" parameter in config squid, when this parameter is set "on",web sites need to user authentication (for example pass-trough ntlm method), unfortunately is not prompt user and password. My idea is that this parameter conflict with pass-trough ntlm, but this conflict is not mentioned anywhere on squid document. If my tolds are correct please add notice for this conflict thanks in advanced -- N.Chavoshi
Re: Is heap used?
On Wed, Apr 29, 2009 at 5:09 PM, Amos Jeffries wrote: > Kinkie wrote: >> >> Hi all, >> while walking the sources to check for documentation to write, I've >> noticed that the heap code (defined in include/heap.h and lib/heap.c) >> doesn't seem to be used anywhere. >> Is it confirmed? If so, is there any good reason not to remove it? >> > > A lot of the lib/*.c files are auto-inserted in place of missing system > files by configure. I expect its needed on some system somewhere for the > librepl.la stuff. Gah! You're right. My grep attempt somehow missed it. Thanks for pointing out. -- /kinkie
Re: Is heap used?
Kinkie wrote: Hi all, while walking the sources to check for documentation to write, I've noticed that the heap code (defined in include/heap.h and lib/heap.c) doesn't seem to be used anywhere. Is it confirmed? If so, is there any good reason not to remove it? A lot of the lib/*.c files are auto-inserted in place of missing system files by configure. I expect its needed on some system somewhere for the librepl.la stuff. Amos -- Please be using Current Stable Squid 2.7.STABLE6 or 3.0.STABLE14 Current Beta Squid 3.1.0.7
Re: r9630 and debug_options rotate=N setting
On 04/29/2009 01:59 AM, Amos Jeffries wrote: > Alex Rousskov wrote: >> On 04/12/2009 02:17 AM, Amos Jeffries wrote: >>> revno: 9630 >>> ... >>>- adds debug_options rotate=N setting >>> >>> logfile_rotate >>> +No longer controls cache.log rotation. Use debug_options >>> rotate=N instead. >> >> This change seems rather odd, backward-incompatible, > > Fully backward compatible. Its an optional argument which can be placed > anywhere on the debug_options list of optional arguments. And likewise > specified as many time 0-N as wanted with last configured being used. It is not backward compatible because an old, working squid.conf with logfile_rotate has to be modified to preserve the old behavior: debug_options may need to be added and rotate parameter would have to be set to whatever logfile_rotate is set to. That change of the default behavior is the primary reason I am complaining. >> and inconvenient in >> many typical setups where all logs must be rotated and archived >> together. > > Explicitly does not alter the timing of rotation. Merely the number of > logs kept when rotated. This is to improve system reliability when > running with ALL,9 or other likewise verbose debug levels (thus its > linkage with the debug_options). > > One of the big hassles I've had and others appear to be in the same boat > is requiring many access.log to be kept (365 for me). Yet only really > needing one or two cache.log for administrative debugging purposes. I fully understand the motivation, but I do not think we should inconvenience others who rely on the old, very reasonable behavior, especially when there is such an easy fix -- use logfile_rotate as the default for rotate=N. >> Could you please restore the old behavior _if_ no explicit >> "debug_options rotate=N" was specified? > > If unspecified, a default is set to 1. That can be changed to 10 again > in debug.cc and cf.data.pre. It should be whatever logfile_rotate is set to (including its default setting). > You _could_ explicitly link it back to the Config logfile_rotate setting > just or a default on legacy occasions but that again makes debug depend > on ::Config which spoils the effect of removing the circular > dependencies liblogs.la -> squid -> debug.* ->liblogs.la . I have not analyzed this dependence, but I am sure there is a technical solution there. The user-facing side should not suffer just because we are moving some files around! I can help with resolving the dependencies if needed. >> Also, does not the new rotate option belong to cache_log? Debug_options >> are about debugging and not cache log file maintenance... > > cache.log being about debugging I picked this to be its control point. > > Good point, though cache_log will need a new parser and type for that > parser to be able to add any options. At which point I think it might > be worth merging debug_options and cache_log together completely. > > But thats a much bigger change. Do you think it worth doing? > ie cache_log [rotate=N] ALL,1 [...] IMO, it makes more sense than the current approach, but my primary concern is the default behavior when rotate=N is not specified. If you move rotate=N to cache_log, you should probably make that option available for all logs. Thank you, Alex.
Is heap used?
Hi all, while walking the sources to check for documentation to write, I've noticed that the heap code (defined in include/heap.h and lib/heap.c) doesn't seem to be used anywhere. Is it confirmed? If so, is there any good reason not to remove it? -- /kinkie
Re: Introducing myself
Alistair Reay wrote: Hi Alex, I think that'd be a good idea. The main thing stopping my company using Squid 3 is the lack of collapsed_forwarding. I'll find out who in the dev community is working on this and lend a hand. Right now. Nobody I know of. We are concentrating on the shuffling needed to get 3.1 out the door properly. It's on the must-do list of stuff hoping to be in the next release though. So any help you can give that way would be a step forward. IIRC there is an old port for 3.0 which Henrick started on the old devel.squid-cache.org CVS. I think it was either not quite complete enough or waiting some tested before merging and got left to long. It needs checking to see how relevant it is now and updating if it's still useful or re-writing if not. P.S. Hi Alistair :) It's good to see other interest here in NZ. Amos Cheers Al -Original Message- From: Alex Rousskov [mailto:rouss...@measurement-factory.com] Sent: Wednesday, 29 April 2009 7:01 a.m. To: Alistair Reay Cc: squid-dev@squid-cache.org Subject: Re: Introducing myself On 04/20/2009 10:10 PM, Alistair Reay wrote: Hi everyone, I'd like to introduce myself to the dev team and start helping out. My name is Alistair Reay and I'm a system engineer at a large New Zealand broadcaster that uses Squid and other open-source software extensively. Using squid we've built the nations largest and cheapest commercial CDN for our VOD offering so I've got a vested interest in helping Squid kick more ass. Although I'm not a professional developer, I have a lot of interest in contributing code to this project and I've created a production-ready load balancer project in SourceForge called Octopus http://sourceforge.net/projects/octopuslb/ that works really well behind Squid. Anyway, the first thing I'd like to do is investigate how refresh_stale_hit works and try to improve it. I searched to squid-users mail list and found this thread of conversation which is what I'd like to implement in Squid2.7. If you'll have me, I'll subscribe to this mailing list and make a new topic about this feature request then start work. http://www.squid-cache.org/mail-archive/squid-users/200609/0162.html User's query/request (also what I'd like to be able to do) http://www.squid-cache.org/mail-archive/squid-users/200609/0167.html Henrik's response Hi Alistair, If you have some cycles to spare, please consider helping with porting Squid2 features you use to Squid3. This will both help current Squid3 users and will ensure a smooth upgrade path for your production caches. If you work on something new, please consider writing a Squid3 patch (and a Squid2 patch if necessary). Thank you, Alex. == For more information on the Television New Zealand Group, visit us online at tvnz.co.nz == CAUTION: This e-mail and any attachment(s) contain information that is intended to be read only by the named recipient(s). This information is not to be used or stored by any other person and/or organisation. -- Please be using Current Stable Squid 2.7.STABLE6 or 3.0.STABLE14 Current Beta Squid 3.1.0.7
RE: Introducing myself
Hi Alex, I think that'd be a good idea. The main thing stopping my company using Squid 3 is the lack of collapsed_forwarding. I'll find out who in the dev community is working on this and lend a hand. Cheers Al -Original Message- From: Alex Rousskov [mailto:rouss...@measurement-factory.com] Sent: Wednesday, 29 April 2009 7:01 a.m. To: Alistair Reay Cc: squid-dev@squid-cache.org Subject: Re: Introducing myself On 04/20/2009 10:10 PM, Alistair Reay wrote: > Hi everyone, > > I'd like to introduce myself to the dev team and start helping out. > > My name is Alistair Reay and I'm a system engineer at a large New > Zealand broadcaster that uses Squid and other open-source software > extensively. Using squid we've built the nations largest and cheapest > commercial CDN for our VOD offering so I've got a vested interest in > helping Squid kick more ass. Although I'm not a professional developer, > I have a lot of interest in contributing code to this project and I've > created a production-ready load balancer project in SourceForge called > Octopus http://sourceforge.net/projects/octopuslb/ that works really > well behind Squid. > > Anyway, the first thing I'd like to do is investigate how > refresh_stale_hit works and try to improve it. I searched to squid-users > mail list and found this thread of conversation which is what I'd like > to implement in Squid2.7. If you'll have me, I'll subscribe to this > mailing list and make a new topic about this feature request then start > work. > > http://www.squid-cache.org/mail-archive/squid-users/200609/0162.html > User's query/request (also what I'd like to be able to do) > http://www.squid-cache.org/mail-archive/squid-users/200609/0167.html > Henrik's response Hi Alistair, If you have some cycles to spare, please consider helping with porting Squid2 features you use to Squid3. This will both help current Squid3 users and will ensure a smooth upgrade path for your production caches. If you work on something new, please consider writing a Squid3 patch (and a Squid2 patch if necessary). Thank you, Alex. == For more information on the Television New Zealand Group, visit us online at tvnz.co.nz == CAUTION: This e-mail and any attachment(s) contain information that is intended to be read only by the named recipient(s). This information is not to be used or stored by any other person and/or organisation.
Re: r9630 and debug_options rotate=N setting
Alex Rousskov wrote: On 04/12/2009 02:17 AM, Amos Jeffries wrote: revno: 9630 ... - adds debug_options rotate=N setting logfile_rotate + No longer controls cache.log rotation. Use debug_options rotate=N instead. This change seems rather odd, backward-incompatible, Fully backward compatible. Its an optional argument which can be placed anywhere on the debug_options list of optional arguments. And likewise specified as many time 0-N as wanted with last configured being used. and inconvenient in many typical setups where all logs must be rotated and archived together. Explicitly does not alter the timing of rotation. Merely the number of logs kept when rotated. This is to improve system reliability when running with ALL,9 or other likewise verbose debug levels (thus its linkage with the debug_options). One of the big hassles I've had and others appear to be in the same boat is requiring many access.log to be kept (365 for me). Yet only really needing one or two cache.log for administrative debugging purposes. Could you please restore the old behavior _if_ no explicit "debug_options rotate=N" was specified? If unspecified, a default is set to 1. That can be changed to 10 again in debug.cc and cf.data.pre. You _could_ explicitly link it back to the Config logfile_rotate setting just or a default on legacy occasions but that again makes debug depend on ::Config which spoils the effect of removing the circular dependencies liblogs.la -> squid -> debug.* ->liblogs.la . Also, does not the new rotate option belong to cache_log? Debug_options are about debugging and not cache log file maintenance... cache.log being about debugging I picked this to be its control point. Good point, though cache_log will need a new parser and type for that parser to be able to add any options. At which point I think it might be worth merging debug_options and cache_log together completely. But thats a much bigger change. Do you think it worth doing? ie cache_log [rotate=N] ALL,1 [...] Amos -- Please be using Current Stable Squid 2.7.STABLE6 or 3.0.STABLE14 Current Beta Squid 3.1.0.7
