Re: cvs commit: squid3/src cf.data.pre
Henrik, IIRC you said you had a simple procedure for cross-porting changes like this to Squid2-HEAD? In the spirit of keeping the 2 and 3 cfg synced, this update should also be made to 2.6 Amos > amosjeffries2007/08/02 16:58:15 MDT > > Modified files: > src cf.data.pre > Log: > Add new section to squid.conf: ERROR PAGE CUSTOMISATION > > Moves existing error page rerlated options from MISC section to their > own. > Options moved are: > deny_info, error_directory, email_err_data, err_html_text > > Revision Changes Path > 1.445 +74 -64squid3/src/cf.data.pre > >
Re: dnsserver
> Hi! > Hey rafael. Welcome back. > I was playing with squid3-ipv6 branch two years ago, and I eventually I > got a > IPv6/IPv6 proxy. > I have taken an eye on Amos' work, and I can see a big effort I would > never > have achieved . I was not so skilled as him on squid3 (event-driven model, > etc...). > > Among others, you replace the gethosbyname by getaddrinfo(), the > rigthway.. > > No I'm back. I'm a bit more stronger with network protocols... > > Could I contribute under your managment and supervision? Most certainly. Right now we are stuck in a holding pattern waiting for 3.1 to be branched and finding new bugs. > Is the branch functional -though Beta- IPv4-IPv6 ? Yes its functional. As I put on the branch pages, I'm running it full-time on my laptop since early June. Others find the ocasional bug appearing as they try to build and run on other OS than mine. So far we have tests on: Ubuntu - works for me Debian - some known problems and AS4 - whatever that is, no problems reported since a syntax typo was fixed a few days ago. > I got one, but is somewhat > clumsy based on gethostbyname (plust res_init(..)... So, it works, but is > not > the way to follow... > > Let me know where I can work... But I'm not either full time or > professional. Sure. Your welcome. Most of the logics are what you and Xaun created way back. All I have done for most of the code is make a class. The page at http://devel.squid-cache.org/squid3-ipv6/IPAddress.html covers the API fairly well. > Heinrik, I'm also interested on ACL lists, when possible. > You have the best timing I have ever seen. :-) I just now received an email from one of the testers saying he found a problem in the IPv4 CIDR-ranged ACL. And am not able to spend any time coding this weekend. I will forwarded an intro email for and Bernhard. ( It sounds like an error in either the ACL parser or matchIPAddr() ) My very short outstanding TODO list is all in the branch NOTES-IPv6 file. Amos
Re: what about Armenian error pages?
> ons 2007-07-18 klockan 08:39 -0700 skrev Arthur Tumanyan: > >> > for example ERR_CONNECT_FAIL doesn't mention the requested server >> (%I), >> > and several pages don't include the mailto link where the English one >> > do.. >> > >> > and similar errors seem to be in other pages as well. > >> Well,is there a way to solve this problem? > > A second reading, comparing the English to the Armenian pages, by a > person being able to read both languages.. and then fix the mismatches. > > I can only do some very simple automated compares, like making sure the > same % codes is used in each page.. > > Armenian/ERR_ACCESS_DENIED %w mismatch (found , expected 2) > Armenian/ERR_CONNECT_FAIL %I mismatch (found , expected 1) > It looks to me like squid is doing translation the hard way and hit the natural consequence for it. What I think we should be doing here is having a 'dictionary' for each langauge containing a list of each unique sentence needed. Last time I wrote a translation system like this with mostly similar output, I found it easier to create a multiple dictionaries and insert them at build time into the pages, With a default language if any sentence was missing (allows for expansion in absence of translators). It kept the level of expertise needed in language translators to a minimum and kept the page layout and styles in one location. Would be a nice beginner project if you want to go ahead with it. Amos
Re: HEAD website projects.html,1.320,1.321
Hey Emilio, Firstly welcome aboard. There are a few more "!YOURTAG" need replacing in the new sections of projects.html. Also, take a look at the code for the the first few branches by Henrik to see a nicer way to detail multiple branches doing the same thing. Amos > Update of cvs.devel.squid-cache.org:/cvsroot/squid/website > > Modified Files: > projects.html > Log Message: > Added acl_urllist project description > >
tarball help
hey Guys, I'm thinking its about time I got around to making a source D/L tarball of the IPv6 branch. Am I correct is assuming that I can run bootstrap locally and bundle the results for people just to run configure and make themselves? or is there OS/system specific stuff the bootstrap needs to do? Amos
docs Project underway
I have just added my spare-time project about documenting the squid source code using doxygen to the current projects list (devel.squid-cache.org/projects.html#docs) The aim of this side-project is to make an all-new programmers guide based around code comments. Anyone altering the squid code can assist this project by using a few extra/new habits when they write code comments in the source altered. For starters: block comments (/* */) describing a method, etc. started with /** will be added as documentation when that code makes it into HEAD. Amos
Re: default user
> tis 2007-07-10 klockan 20:34 +1200 skrev Amos Jeffries: >> Duane Wessels wrote: >> >> > On Tue, 10 Jul 2007, Amos Jeffries wrote: >> > >> >> Hey guys, >> >> I find myself in need of a ./configure option to set the >> >> cache_effective_user other than 'nobody' on a per-dist basis, leaving >> >> the squid.conf setup as-is. >> >> Can someone please explain to me how the @HTTP_PORT@ etc get >> >> replaced in squid.conf / cf.data.pre >> >> I have tried modifying src/makefile.am and ./configure.in to no >> >> visible effect. >> > >> > Calling AC_DEFINE (etc) causes the variables to be set for autoconf. >> > After ./configure runs, you should see them in config.status. eg: >> > >> > s,@CACHE_HTTP_PORT@,3128,;t t >> > >> > >> > config.status does the substitutions from Makefile.in to Makefile. >> > for example: >> > >> > $ sh config.status >> > ... >> > config.status: creating src/Makefile >> > >> > >> > So in src/Makefile.in you have: >> > >> > DEFAULT_HTTP_PORT = @CACHE_HTTP_PORT@ >> > >> > While in src/Makefile you have: >> > >> > DEFAULT_HTTP_PORT = 3128 >> > >> > >> > Our src/Makefile (but you must edit src/Makefile.am of course) has >> > a long-ish sed commands to do very similar substitutions on the >> > cf.data.pre file: >> > >> > cf.data: cf.data.pre Makefile >> > sed "\ >> > [EMAIL PROTECTED]@%$(DEFAULT_HTTP_PORT)%g;\ >> > [EMAIL PROTECTED]@%$(DEFAULT_ICP_PORT)%g;\ >> > ... >> > >> >> Thanks Duane, >>What you have just written matched perfectly with my earlier reading >> straight from the code. So I still can't see whats going wrong here. >> >> >> > So if you want to add your own macro goop you have to (at least): >> > >> >- modify configure.in (if you want it to be set via ./configure) >> >> yes::: >> >> AC_ARG_WITH(cache-user, >> [ --with-cache-user=USER System user account for squid permissions. >> default: nobody], >> [ if tets -z "$withval"; then >> AC_DEFINE(cfg_CACHE_EFFECTIVE_USER, "$withval", [change User for >> squid to $withval]) >> else >> AC_DEFINE(cfg_CACHE_EFFECTIVE_USER, "nobody", [default User for >> squid]) >> fi >> ]) >> AC_SUBST(cfg_CACHE_EFFECTIVE_USER) > > You also need to assign the cfg_CACHE_EFFECTIVE_USER variable a value > > The following should work: > > cfg_CACHE_EFFECTIVE_USER="nobody" > AC_ARG_WITH(cache-user, > [ --with-cache-user=USER System user account for squid permissions. > default: nobody], > [ > cfg_CACHE_EFFECTIVE_USER="$withval" > ]) > AC_SUBST(cfg_CACHE_EFFECTIVE_USER) > > > You don't need AC_DEFINE. AC_DEFINE adds a C macro definition. > > Regards > Henrik > Eureka. As always Henrik is knows everything :-) It was those AC_DEFINE's Amos
Re: about cf.data.pre and squid compiling
> > I think,if i configured the squid with "--enable-shaga" option,the > "enable_shaga_engine" tag must be uncommented in squid.conf file,like > other > tags.Am i wrong? You are only seeing half the picture so far: cf.data.pre - defines 'squid.conf' values. configure.am - defines './configure --enable-* 'options It sounds like you still need to add the auto-tools script to handle --enable-shaga into configure.am. When that is done the 'Note:' bit will dissappear. Don't forget to run a full 'make -k distclean && ./bootstrap.sh' after changing the configure scripts Amos
Re: Squid and SIGPIPE
> On Thu, Jul 05, 2007, Amos Jeffries wrote: >> >> I have been overlooking these for a while on the assumption that it was >> gdb catching something when it should have left it. I have just started >> wondering if this was in fact bad unexpected behaviour for the squid >> signals. Should I be looking into it? > > Nope! > > put this in ~/.gdbinit: > > handle all nostop noprint > handle SIGSEGV stop > handle SIGPIPE stop > Oh great. Thanks Adrian. Amos
Re: [squid-users] Debugging delay pools
> Hello! > > Just a simple sanity check: > > debug_options ALL,1 77,10 > > Should print debug messages in the cache log about delay pools? > > This is using squid 2.6 stable 13. > > Is there an easy reference to list what source areas map to what > functions? I am using the table in "Squid: The definitive guide" as a > reference, but I am wondering if my 2004 edition is now outdated. > > Cheers, > > Matt > I've been having a nagging suspicion about the use of debug_options Is anyone able to set me straight on this I have been using "debug_options a,n b,n ALL,n" from old coder habits but a lot of examples that have been tossed around use ALL at the front. Is there any effect on output determined by the order? Amos
Re: [squid-users] caching data for thousands of nodes in a compute cluster
> Trying again, having got no response. Any reaction to my questions? > > - Dave > > On Tue, Jun 12, 2007 at 11:42:42AM -0500, Dave Dykstra wrote: >> On Tue, Jun 12, 2007 at 12:19:26AM +0200, Henrik Nordstrom wrote: >> > m??n 2007-06-11 klockan 15:17 -0500 skrev Dave Dykstra: >> > >> > > of jobs. It quickly becomes impractical to distribute all the data >> from >> > > just a few nodes running squid, so I am thinking about running squid >> on >> > > every node, especially as the number of CPU cores per node >> increases. >> > > The problem then is how to determine which peer to get data from. >> > >> > Multicast ICP sounds like it could be a reasonable option there. >> > >> > Regards >> > Henrik >> >> I considered that, but wouldn't multicasted ICP queries tend to get many >> hundreds of replies (on average, half the total number of squids)? It >> would only use the first response it got back, but it doesn't seem very >> efficient of network or compute resources to throw away all the others. >> Do you know of other people who have used multicast ICP for this type of >> application? >> >> The multicast TTL could help a little but probably not much. I expect >> the servers are usually organized in smaller groups, with better network >> connectivity within each group, but it isn't practical to ask the system >> administrators to tell us which servers are in which group so everything >> has to be automatic. They're very likely all on the same large subnet >> with the switches sorting out the routing, so it isn't clear that >> anything at squid's level would be able to tell how far away servers are >> other than by small differences in response time, or more likely >> throughput of large transfers. I also don't think we can really expect >> we know can know the names of all the peers in order to list them in >> "multicast-responder". >> >> - Dave > There are some neighbour-discovery features of IPv6 that offer options in this area. The drawbacks there are: The host network between squids MUST be able to handle IPv6 traffic properly, and with the current squid that means dual-stack linux in some form. It hasn't been written or even experimented with yet AFAIK. So some sponsorship will be needed to get me or someone doing it earlier than a few years away. Amos PS. yes folks squid3-ipv6 branch is in Beta testing now.
Re: Callbacks help please
> sön 2007-06-24 klockan 23:41 +1200 skrev Amos Jeffries: > >> > I'm trying to add CNAME capability so the absence of additional A or >> > will failover to looking them up. >> > (This is presently showing me the same 'can't connect to X website' we >> > get so many complaints about, maybe the same problem.) > > Should work fine to continue ignoring CNAME and do the failover to an A > when seeing a reply only having a CNAME and no . > >> Never mind. I think I have mucked up a suitable alternative. > > So what did you end up doing? > > Regards > Henrik > Altered ipcacheParse so that it returned -1 for *all* errors, 0 for 'no data yet', and N for data. Changed dummy_handler which did nothing to ipcacheHandleCnameRecurse which accepts the cbdata parameter as either an generic_cbdata(ipcache_entry) or null. On NULL it behaves as dummy_handler used to. With data it adds the DNS addrs found from the subquery to the entry passed in as parent. Then calls the parents callback instead. The single function, (name just slips my mind), which calls ipcacheParse altered to handle the new return cases and NOT add the entry to the live cache or call its callback IFF 0 received. Thus waiting until the child call returns. Amos
wiki usage
I have been giving some thought to the wiki recently. Namely in the areas of usability. As a newbie last year I found the squid wiki extremely difficult to use of find anything on. It's taken nearly three months for me to become familiar enough with it to identify what the problem was. I'm thinking there are a lot of others out there like me who are not familiar with wiki's but need to use it. The biggest problem was navigating to the content pages without knowing what was already available. For starters, kinkie, Is there any way you can get the TitleIndex page to drop into the menubar next to FindPage/HelpContents? Yes, I am aware of the catechism "If it needs an index it's too complicated" but that is exactly the problem we currently face with wikis. Amos
Re: transparent https interception
> ons 2007-06-20 klockan 11:52 +1200 skrev [EMAIL PROTECTED]: > >> I would need those above and also dstdomain and external ACL support (at >> least IP and domain passed to helper). > > There won't be any domains on such intercepted connections, just IP, and > if you are lucky the reverse lookup of that IP.. > > The actual requested domain is not available at the packet layer. > > Regards > Henrik > Ah, of course. Thanks. Amos
Re: transparent https interception
> Gah, I got another email about transparent https interception. > > I guess this means I'll just have to bloody write it. My main question > is which ACL types people would like to support. Initially it'd be > easy to support source and destination IP, logging the transaction > time and TX/RX bytes. > > Comments? > > Adrian > Thank you Adrian, This one would be very useful to me. I'll assist with the testing if you like. And I'll see about passing some donation your way once I've looked at the finances. I would need those above and also dstdomain and external ACL support (at least IP and domain passed to helper). IIRC, there was a patch somebody made earlier in the year to do generic tunnelling nicely. Amos
OS builds
There seem to be a FAQ in squid-users about not finding builds for certain OS, or old versions of RPMs etc. The idea that comes to me is that we need a list somewhere of the sources for OS-specific builds that are available along with some way of getting newer builds for common OS that have no active maintainer. Without knowing a lot about the sourceforge compile farm it seems to me we could possible leverage that. Has anyone looked at it before? Amos
Re: Removing cppunit
> On Fri, 2007-04-13 at 13:27 +1200, [EMAIL PROTECTED] wrote: >> > On Fri, 2007-04-13 at 12:45 +1200, [EMAIL PROTECTED] wrote: >> >> >> >> It has not been linked to the cppunit testers, but I have written a >> >> specific test app to check each function and proivide for maula-eye >> >> check >> >> in increments from simplest up for both ipv4-pure then dual protocol >> >> paths. >> >> Then it has spent nearly a month in live run tests within squid and >> >> manual >> >> debug traces. >> >> >> >> That said, if anyone can think of any asserts that should be in >> there, >> >> point them out. >> > >> > If the test logic is not hooked into 'make check', then it will not be >> > run regularly. Platform changes or subsequent untested changes to the >> > code base can introduce regressions. >> > >> > I think it should most definately be hooked into the cppunit test >> suite. >> > >> >> Um, which brings me to ... >> >> Alex: didn't you ask for cppunit to be removed from squid3? if not, I >> need >> a kick in the right direction on that. > > My understanding is that we want to remove cppunit (the program, > framework, or whatever it is) itself but leave Squid-specific test > cases. Somebody will need to install cppunit to actually use Squid test > cases. > > This is similar to any other third party tool like GCC or valgrind. We > do not distribute those with Squid, but have things that work with them. > > Running "make check" (or whatever it is) would run cppunit test cases if > somebody has cppunit installed and should skip them (with a warning) if > somebody does not have cppunit installed. > > If there is a special make target to force running cppunit test cases, > that target will fail if there is no cppunit installed. > > HTH, > > Alex. > Ah, doh! an homer would say. Yes that makes perfect sense now. Particularly after reading that bug report about it again. Okay so that shall be that order of business. Making cppunit an external optional developer/maintainer tool for testing. Looks like I shall be on it in a few hours. Amos
Re: Squid 3.0 bugs that need you.
> On Fri, 2007-04-13 at 12:45 +1200, [EMAIL PROTECTED] wrote: >> >> It has not been linked to the cppunit testers, but I have written a >> specific test app to check each function and proivide for maula-eye >> check >> in increments from simplest up for both ipv4-pure then dual protocol >> paths. >> Then it has spent nearly a month in live run tests within squid and >> manual >> debug traces. >> >> That said, if anyone can think of any asserts that should be in there, >> point them out. > > If the test logic is not hooked into 'make check', then it will not be > run regularly. Platform changes or subsequent untested changes to the > code base can introduce regressions. > > I think it should most definately be hooked into the cppunit test suite. > Um, which brings me to ... Alex: didn't you ask for cppunit to be removed from squid3? if not, I need a kick in the right direction on that. Amos
Re: Squid 3.0 bugs that need you.
> On Fri, 2007-04-13 at 01:40 +0200, Henrik Nordstrom wrote: >> >> > yay! this has been causing me some nightmares just thinking about >> it. >> > I'll get onto a purge this weekend unless there is anyone else who >> wants >> > to do it or veto it. >> > Speak up within 8 hours or I'll create a 'nocpp' branch and get to >> work. >> >> Should be trivial. It already supports out-of-tree cppunit if you have >> cppunit installed, and the cppunit requirements is only if your run >> "make test". > > Which everyone should do before committing, of course! > > This reminds me - Amos - your IPAddress patch, is the code thoroughly > unit tested? Thats as much a concern for me as is merging unused code. > I'd really hate to add more chunks of untested functionality > *particularly* when they are unused, as its easier for unused code to be > spectacularly broken and unnoticed than for used to code to be the same. > It has not been linked to the cppunit testers, but I have written a specific test app to check each function and proivide for maula-eye check in increments from simplest up for both ipv4-pure then dual protocol paths. Then it has spent nearly a month in live run tests within squid and manual debug traces. That said, if anyone can think of any asserts that should be in there, point them out. Amos
Re: IPv6 developments for HEAD
> On Wed, Apr 11, 2007, [EMAIL PROTECTED] wrote: >> > On Sat, 2007-04-07 at 17:24 +1200, Amos Jeffries wrote: >> >> Attached are two patches which constitute part of the core >> developments >> >> for protocol-independent handling of IP addresses in squid3. >> > >> > In your opinion, should these be committed to Squid 3.0? Are they >> likely >> > to cause short-term stability problems? Should they be applied to >> Squid >> > 3.1 instead? >> > >> > Thank you, >> > >> > Alex. >> > >> >> Yes. No. both?. >> >> I would like to see them in 3.0. >> >> The new object I am submitting is isolated 'infrastructure' which does >> not >> affect the rest of squid in any way. It is itself the stable base needed >> for future work. >> The update to rfc1035 is a reversal of previous changes which is again >> stabilising that area a little more. >> >> I'm still a little fuzzy on the consensus of what the difference between >> 3.0 and 3.1 is. I would like these to be applied to HEAD. > > Trouble is: squid-3 should've been released a long, long time ago and > users > should've been moved over to it. People kept commiting stuff to Squid-3 in > the hopes of "tidying stuff up" and people (somewhat) forgot that fixing > the > bugs and getting the release out there's more important. Agreed, which is the main reason I am witholding a further 170Kb of stable update in my feature branch until the next (PRE6?) release is out or shown to be too far away to matter. As someone who has happily been using 3.0-PRE5 in production for about 5 months now I'm thinking more in terms of 3.0-PRE5, 3.0-PRE6, 3.0-PRE7, working up towards 3.0-STABLE1 which has all the asked for features of 2.6-X than 3.0 / 3.1. > So my humble opinion as someone who isn't currently working on Squid-3: > fix whatever bugs people are seeing in production and get squid-3 stable. > Release as squid-3.0. Step back and re-assess the list of features > you'd like to see in squid-3.1. Be inundanted with bugs. Fix the bugs; > then > introduce agreed features. Release Squid-3.1. Be inundanted with bugs. > Reassess the list of features you'd like to see in Squid-3.2. etc, etc. > Question then becomes, where is the existing list of agreed features for 3.0-STABLE1 ?? > > Adrian > (Sounds like I want to be release manager, doesn't it? eep.) > > Trouble is the cleaner the code, the less bugs can hide in it. Personally I'm of the opinion that bugs should be fixed in the latest version and ported down to earlier versiosn that might need it rather than up. Promotig the use of later better code by all users. Amos
Re: IPv6 developments for HEAD
> On Sat, 2007-04-07 at 17:24 +1200, Amos Jeffries wrote: >> Attached are two patches which constitute part of the core developments >> for protocol-independent handling of IP addresses in squid3. > > In your opinion, should these be committed to Squid 3.0? Are they likely > to cause short-term stability problems? Should they be applied to Squid > 3.1 instead? > > Thank you, > > Alex. > Yes. No. both?. I would like to see them in 3.0. The new object I am submitting is isolated 'infrastructure' which does not affect the rest of squid in any way. It is itself the stable base needed for future work. The update to rfc1035 is a reversal of previous changes which is again stabilising that area a little more. I'm still a little fuzzy on the consensus of what the difference between 3.0 and 3.1 is. I would like these to be applied to HEAD. Amos
Re: squid 3 + content encode
> > here's some error after i did the bootstrap.sh: > > Bootstrapping > /usr/share/aclocal/pth.m4:43: warning: underquoted definition of > _AC_PTH_ERROR run info '(automake)Extending aclocal' > or see > http://sources.redhat.com/automake/automake.html#Extending-aclocal > /usr/share/aclocal/pth.m4:55: > warning: underquoted definition of > _AC_PTH_VERBOSE /usr/share/aclocal/pth.m4:61: warning: underquoted > definition of AC_CHECK_PTH configure.in:34: error: possibly undefined > macro: AC_LTDL_DLLIB If this token and others are legitimate, please > use m4_pattern_allow. See the Autoconf documentation. autoconf failed > Autotool bootstrapping failed. You will need to investigate and correct > before you can develop on this source tree > That looks awfully like the old problem of a missing libltdl-dev dependancy in some versions of libtools or automake. Amos
Re: HEAD website projects.html,1.307,1.308
> Hmm... I assume this was not intentional. > > What happened? > > Regards > Henrik > I went: cvs -q update cvs commit without noticing that the update had created a merge-clash patch for the changes you had made. When I found the .# patch file with your updates I checked and merged my update into that and replace the bad one temporarily committed. Why there was a merge-clash on every 'changesets' alteration in the first place I still don't know. The only real clash was both of us altering the squid3-ipv6 'view patch' line. Amos
Re: stuff in the Squid3 pipeline
> On Sun, 2007-03-18 at 21:32 -0700, Alex Rousskov wrote: >> On Sat, 2006-05-06 at 12:08 +1200, Doug Dixon wrote: >> > And as Henrik says, if you've got new stuff in the pipeline, please >> > shout now. We just need to agree which PRE it goes into - whether 4 >> > or later. >> >> The BodyPipe-related changes that currently live in squid3-icap branch >> are pretty much ready for being committed to HEAD. Those changes affect >> Squid core (as well as ICAP) and are meant to fix several POST-related >> bugs in Squid3. I hope these changes will be copied to HEAD in 14 days >> or so. > > Ha! Replying to messages sorted by subject can be humiliating: I did not > realize the above thread is almost a year old until I sent the carefully > crafted response :-). I should have listened to the inner voice being > surprised by the low Squid PRE number being discussed on that thread! > > Sorry for the noise, > > Alex. > hehe, no worries. It's good news anyway ... I'm just wondering which POST-related errors are fixed by that upgrade and what the timeline currently is on PRE6. Amos
MemPool and acl_ip_data
Is there anyone able to give me a good description of the how-and-why of MemPool? specifically the MEMPOOL_CLASS() macros and acl_ip_data. I have a segfault occuring when an acl_ip_data object is created. Following several others which appear properly, but definately during the new() somewhere in the inline MemPool functions. A close look at the MemPool code has only confused me terribly. Amos
Re: knowledge base stuff
> On Thu, Mar 01, 2007, kinkie wrote: > >> Not that I know of; that would reqire a full-blown CMS engine. >> I'll do some research, but I'm skeptic. >> >> It's probably also overkill: the current policy (write-access requires >> easily-given approval), together with the wiki's versioning capabilities >> (to roll back unapproved changes) and page change monitoring, should be >> adequate already. >> We could promote contributions in the KB pages themselves (i.e. a >> standard >> footer or something like that); maybe that'd help attract help. > > Its not all that important to start with. Lets get the bugs and kinks > worked > out of the new website and get that thing live first. I'll then put > feelers > into the Squid community and see if we can find ourselves one or two > interested > people to start fleshing out the Wiki and website with various articles. > A non-squid problem here has led me down an Idea path that I think may apply here to the KnowledgeBase concept you two are/were throwing around. I occurs to me that any kind of KB needs real-life problems and solution, must be user-driven, and have some form of unique problem identification. It seems to me that we already have a form of this in the squid-users mailing list. But that one is very cluttered with non-problem messages and with failed solution attempts. So it needs a bit of cleaning. What I am thinking of in a rough way is a KB which uses the squid-users msg-IDs as the unique ID for a problem (after all the original problem has been posted right?), and may in fact use the message itself from the archive to describe the problem. Where a solution has been found, references to the msg describin the solution could be used. (By 'references' I mean either a web link by msg-ID or a PHP include to show the archive content, descision to be made by the KB designer). Msg can continue to be posted to squid-users as normal, but the KB sumbission 'authorization' being to link the posts to the KB. Rather than ading an extra submission on part of the users, which is not that likely to get used anyway. That would leverage an enourmous pile existing problem-solutions and provide a framework for seamless and easy future additions. Might even drop the clutter of repeated problem requests. > > Whats missing/broken @ http://new.squid-cache.org/ besides the downloads? > I noticed the Advisories section showing a 404 last night. Amos
RE: squid3 comments
>> >> >> I know this is a minor problem, but I had problems getting the squid3 >> bootstrap.sh script to run, so I couldn't test the patch. I'm pretty >> sure >> it's got something to do with the version of automake and autoconf on my >> system, but I couldn't find a reference to which versions I needed for >> squid3. >> >> I really think that if squid3 needs a specific version of these programs >> for >> the bootstrap.sh script to run, then the script should check for the >> required version. From what I can tell the current script looks for a >> range >> of versions, most of which will not work. >> >> Can anyone tell me which versions of automake / autoconf are required >> for >> squid3? >> >> Steven >> > > Okay, I had several bootstrap problems myself due to those apps. > > Unfortunately it only shows you the versions (both expected and found) > _after_ it has located all the needed apps. > > If you can't see any details about the version it is looking for and the > one it found. Then you do not have one of the apps installed. Ah, here we are. Found my notes. (Please note that I am Debian based, the package names for your distro may be different). Working from a clean copy of the branch and getting bootstrap errors. I managed to get it going by installing: autoconf automake libtool to get the bootstrap running properly and displaying all action messages and then libltdl3-dev for a cryptic undefined macro error with no helpful references to say what was missing. This problem only appears to occur in the latest versions of libtool which displays as configure.in:34: error: possibly undefined macro: AC_LTDL_DLLIB If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. I am currently using: automake 1.10 autoconf 2.61 libtool 1.4.3 The bootstrap says it looks for these: WARNING: Cannot find automake version 1.9 1.7 1.6 1.5 Trying automake (GNU automake) 1.10 WARNING: Cannot find autoconf version 2.59 2.57 2.53 2.52 Trying autoconf (GNU Autoconf) 2.61 Amos
RE: squid3 comments
>> -Original Message- >> From: Guido Serassio [mailto:[EMAIL PROTECTED] >> Sent: Friday, 2 March 2007 5:51 AM >> To: Henrik Nordstrom; Jeremy Hall >> Cc: Squid Developers >> Subject: Re: squid3 comments >> >> >> I have always hoped than some other developer with a more strong C++ >> knowledge will try to fix them, but this was never happened: all >> Squid 3 peoples seems to like more the development of new features >> instead of fixing bugs. >> >> As example: I have arranged the TPROXY forward port done by Steven in >> November, but no one of the Squid 3 supporters seems to have tested >> it giving any kind of feedback, a little disappointing ... :-( >> So, sometimes I ask to me "why I'm still wasting my time on >> Squid 3 ?". >> > > > I know this is a minor problem, but I had problems getting the squid3 > bootstrap.sh script to run, so I couldn't test the patch. I'm pretty sure > it's got something to do with the version of automake and autoconf on my > system, but I couldn't find a reference to which versions I needed for > squid3. > > I really think that if squid3 needs a specific version of these programs > for > the bootstrap.sh script to run, then the script should check for the > required version. From what I can tell the current script looks for a > range > of versions, most of which will not work. > > Can anyone tell me which versions of automake / autoconf are required for > squid3? > > Steven > Okay, I had several bootstrap problems myself due to those apps. Unfortunately it only shows you the versions (both expected and found) _after_ it has located all the needed apps. If you can't see any details about the version it is looking for and the one it found. Then you do not have one of the apps installed. I do not presently have immediate access to my squid test machine so I can't give any more details for now. Give it a closer look and bets of luck. Amos
Re: locked out by partial cvsmerge
> On Tue, Feb 27, 2007, Alex Rousskov wrote: >> On Sat, 2007-02-24 at 08:43 +0100, Henrik Nordstrom wrote: >> >> > These locks gets cleared automatically after a while and the lock is >> now >> > gone. >> >> Thanks for the explanation and snipped details. Unfortunately, it looks >> like the problem is back and has even become worse as I see more locks >> (from other developers) getting stuck now: >> >> > cvs rtag: [21:28:08] waiting for rousskov's lock in >> /cvsroot/squid/squid3/lib/cppunit-1.10.0/doc >> > cvs rtag: [21:28:38] waiting for serassio's lock in >> /cvsroot/squid/squid3/lib/cppunit-1.10.0/doc >> > cvs rtag: [21:29:08] waiting for amosjeffries's lock in >> /cvsroot/squid/squid3/lib/cppunit-1.10.0/doc >> >> I am unable to merge with HEAD (using cvsmerge) because of this. >> >> Do you know whether there is something going on with SourceForge that >> increases the probability of these locks getting stuck? Anything we can >> do about it in the short term? > > I'm not sure to be honest; but do you think it'd be a good idea just to > shift this > development tree stuff back to a seperate repository or server over at > TMF? > It sounds like it'll be less of a headache now. > Or we could call a 48+ hour holiday for any usage of HEAD and see if the locks disappear. Mine was either created 18 hours ago now or 36. For my part I'm going to stop-work until this gets fixed or someone else can run a full cvsmerge HEAD without encountering it. Amos PS. I had this crazy Idea, that if re-running a cvsmerge with all (3 now) of our logins at the same time would play leap-frog with the locks and move them across the code and away eventually. But then I'll bet cvs has been coded secure enough so that hack is impossible too.
