Still #ifdef WIN64 in APR
In APR 1.4.6 there is still a typo in the statements, causes crashes HTTPD in eg. setting on logging in mod_rewrite. In shm.c and apr.hw #ifdef WIN64 Sould be: #ifdef _WIN64 Steffen
Re: [RFC] try to solidify feature adoption criteria
On Wed, Feb 29, 2012 at 12:57 PM, Jeff Trawick wrote: > New features are a natural part of the software life-cycle, but they One obvious alternative is to simply document that new features of any magnitude can be added to trunk at will by any committer. Presence in a stable branch is subject to a level of documentation considered acceptable to other committers. Merging new features to an existing stable branch is subject to commit rules for that branch. --/-- Or just drop the documentation requirement. --/-- Not writing down any group think on this invites future conflict.
Re: Still #ifdef WIN64 in APR
On Thu, Mar 1, 2012 at 6:15 AM, Steffen wrote: > In APR 1.4.6 there is still a typo in the statements, causes crashes HTTPD > in eg. setting on logging in mod_rewrite. > > In shm.c and apr.hw > > #ifdef WIN64 > > Sould be: > > #ifdef _WIN64 > > > > Steffen Does this work for you? http://svn.apache.org/viewvc?view=revision&revision=1295535 (I'll move the fix back to 1.5 and 1.4 branches and retarget the bug to apr.) -- Born in Roswell... married an alien...
Re: Still #ifdef WIN64 in APR
> Does this work for you? > > http://svn.apache.org/viewvc?view=revision&revision=1295535 > > (I'll move the fix back to 1.5 and 1.4 branches and retarget the bug to apr.) Looks right here given the report and stackoverflow post.
Re: Still #ifdef WIN64 in APR
Anindya supplies already some time a build with the change, as far as I know, no issues reported. -Original Message- From: Jeff Trawick Sent: Thursday, March 01, 2012 1:30 PM Newsgroups: gmane.comp.apache.devel To: dev@httpd.apache.org ; APR Developer List Subject: Re: Still #ifdef WIN64 in APR On Thu, Mar 1, 2012 at 6:15 AM, Steffen wrote: In APR 1.4.6 there is still a typo in the statements, causes crashes HTTPD in eg. setting on logging in mod_rewrite. In shm.c and apr.hw #ifdef WIN64 Sould be: #ifdef _WIN64 Steffen Does this work for you? http://svn.apache.org/viewvc?view=revision&revision=1295535 (I'll move the fix back to 1.5 and 1.4 branches and retarget the bug to apr.) -- Born in Roswell... married an alien...
Re: Technical reasons for -1 votes (?)
On 2/29/2012 6:25 PM, Roy T. Fielding wrote: > On Feb 29, 2012, at 9:42 AM, William A. Rowe Jr. wrote: >> >> Let's take Roy's position on the attached vote discussion, it's relevant. >> These new modules are certainly additions/deletions to httpd. > > Yes, but they are modules. Hence, their mere existence in our tree > is not a technical reason to exclude them. We have a modular architecture > so that people who don't want a module don't have to build it. In fact, > it was exactly this type of argument in 1995 that caused rst to focus > on creating a modular architecture. Ok, so to clarify, you are reversing your answer to Joe? The LDAP changes were a change to a module. Not an httpd-wide API, just a module. So you are saying that your comment to Joe, "The API was moved to *this* project and all of the names were changed. It is, effectively, a new public API for this project." was a misinformed statement (as it moved the ldap code into mod_ldap and not into the core API). That veto was unjustified? Or rather, had we not exported a single symbol, then the veto was unjustified? > If there were dependencies or license conditions brought in that somehow > harmed the server without the module being active, then that would be a > technical objection. There was no such case for the ldap change, so you are saying that specific veto was unjustified, right? Anyways, all of this is distraction, let's drill in further to your analysis; > Traditionally, we have allowed any module that has at least one willing > volunteer committer to maintain it. And I agree with Jim, none of the > subprojects have been as successful as just placing the code in the > main tree. Allowed it by... voting to accept it, right? I accept that all of my colleagues have different rationals for their +/- votes. Right now, just about 3% of the committee are willing to entertain these module additions to httpd trunk and 1.5% are against adding these to trunk. I chalk this up to burnout, 2.4 was very complex to release and people know their +1 votes are commitments and alter the httpd tarball for better or worse. As Jim points out, "The fact is that once a project lives under the main tree, it's part of our shared project" is dead to right. Jim alone is voting with minfrin to support these living in that shared tree, and only I vote that we don't, at this time, until there are more committers who are willing to share Jim's position. If there was a vote to add this module to core, that would be lovely, we could vote on it. Sadly, minfrin offered no such vote, and whatever your conclusion on the 'better course' - it was not voted on, and you hadn't expressed a vote to adopt it in either case. > I have no idea why mod_fcgi is in a subproject. mod_ftp is there > because it isn't an HTTP server. mod_aspdotnet had all sorts of > licensing issues that I never quite figured out. Nonsequitor, if we want to launch into a discussion of subprojects vs. modules, that's great. That wasn't the conversation minfrin started, and that's why I have a VETO on the commit. Correct the mis-execution by conforming to the vote he held, or correct the vote instead. I've VETOED a commit which is something other than what was voted on because the project did not consent to his action. If there are two other committers who will vote with Jim for this project to accept one or more of these modules into trunk (rather than subproject), and someone will finish the ip-clearance, I'm great with that. If none of that happens I will revert this mess. > I see no reason not to commit mod_firehose, though I haven't had a > chance to look at the code myself. mod_firehose is already [erroniously] committed without ip-clearance. Only Jim agrees with minfrin that it belongs in trunk. If YOU want to vote for it to be in trunk, do that. So far, it was accepted by this project only as an additional subproject. Only you and Jim are defending this addition without ip-clearance. Perhaps you are signing up to do that ip-clearance, since it doesn't seem to be coming from the committer. I've voted against mod_policy and mod_combine until this mess is resolved. With sufficient +1's I would have withdrawn all objections, but right now I smell a code dump, and see nobody but Jim disagreeing with me. > Nor am I willing to respect a veto war based on the impact of past vetos. No, it's not a veto war. Only Jim has volunteered to maintain this code (or agreed to help minfrin do so). Right now minfrin blocks correcting mod_ldap, insists it's his project to finish his way, which hurts this project. So his assurance that he should "my intention is to continue to develop and support this" rings hollow. That is the ONLY relationship to the other veto I had quoted your opinion on, other than to point out that vetos are legitimate. Any assurance that he should be a sole maintainer of not one but three+ more httpd module additions seems foolish. > Now, if you'll excus
Re: Technical reasons for -1 votes (?)
On Mar 1, 2012 12:20 PM, "William A. Rowe Jr." wrote: >... > If there are two other committers who will vote with Jim for this > project to accept one or more of these modules into trunk (rather than > subproject), and someone will finish the ip-clearance, I'm great with > that. If none of that happens I will revert this mess. I support Jim. +1
[RE-VOTE] adoption of mod_firehose MODULE
Let's simply reset this whole mess. A proposal to adopt mod_firehose is attached. [ ] Option 1: adopt as trunk module [ ] Option 2: adopt only as subproject [ ] Option 3: do not adopt [Prior to this vote, option 2 had previously passed with minfrin, issac, sctemme, jim in support. Subsequently, wrowe endorsed option 2, while minfrin, jim introduced option 1. Please vote.] On 12/13/2011 9:19 AM, Graham Leggett wrote: > Hi all, > > I have concluded negotiation with the BBC to open source some httpd modules > that I wrote under the AL, and the BBC have very kindly agreed to donate the > code to the ASF[1], which I believe would fit well as subprojects of httpd, > and would like to know whether httpd would accept these. > > To be clear, this isn't a "code dump", my intention is to continue to develop > and support this moving forward, and hopefully expand the community around > them. > > - mod_firehose: "tcpdump for httpd" > > Based originally on mod_dumpio.c, mod_firehose is an httpd filter that writes > the contents of a request and/or a response to a file or pipe in such a way > that the requests can be reconstructed later using a second dedicated tool > called "firehose". > > It was initially developed to help debug restful services that were secured > with client certificates and therefore opaque to other tools like tcpdump or > tcpflow, but was then subsequently used to record "dirty traffic" for > subsequent replay for the purposes of testing. > > The module and the corresponding firehose demultiplexer was used to uncover > some of the more tricky bugs in mod_cache, as well as protocol > inconsistencies in backend services, and would prove very useful to anyone > deploying restful services. We have also intended it to be used to create a > "dark live" environment, where live traffic can be split off and diverted to > a staging environment to test whether a software update works correctly. > > The code is currently packaged as an RPM, wrapped in autotools, and a > snapshot is available here: > > http://people.apache.org/~minfrin/bbc-donated/mod_firehose/ > http://people.apache.org/~minfrin/bbc-donated/firehose/ > > The corresponding README documenting in more detail is here: > > http://people.apache.org/~minfrin/bbc-donated/mod_firehose/README > > The code itself is here: > > http://people.apache.org/~minfrin/bbc-donated/mod_firehose/mod_firehose.c > http://people.apache.org/~minfrin/bbc-donated/firehose/firehose.c > > Obviously the expectation is for the documentation to be completed and > fleshed out. > > [1] https://issues.apache.org/bugzilla/show_bug.cgi?id=52322 > > Regards, > Graham > -- > >
Re: [RE-VOTE] adoption of mod_firehose MODULE
On 3/1/2012 12:11 PM, William A. Rowe Jr. wrote: > > A proposal to adopt mod_firehose is attached. > > [ ] Option 1: adopt as trunk module > [X] Option 2: adopt only as subproject > [ ] Option 3: do not adopt
Re: Technical reasons for -1 votes (?)
On 2/29/2012 6:25 PM, Roy T. Fielding wrote: > > Yes, but they are modules. Hence, their mere existence in our tree > is not a technical reason to exclude them. We have a modular architecture > so that people who don't want a module don't have to build it. Which explains mod_macro how, exactly?
Re: [RE-VOTE] adoption of mod_firehose MODULE
On Mar 1, 2012, at 1:11 PM, William A. Rowe Jr. wrote: > Let's simply reset this whole mess. > > A proposal to adopt mod_firehose is attached. > > [X] Option 1: adopt as trunk module > [ ] Option 2: adopt only as subproject > [ ] Option 3: do not adopt >
Re: [RE-VOTE] adoption of mod_firehose MODULE
On Mar 1, 2012, at 10:11 AM, William A. Rowe Jr. wrote: > Let's simply reset this whole mess. > > A proposal to adopt mod_firehose is attached. > > [X] Option 1: adopt as trunk module > [ ] Option 2: adopt only as subproject > [ ] Option 3: do not adopt Dimpled chad: I would support option 2 if 1 doesn't have traction. S. -- scte...@apache.orghttp://www.temme.net/sander/ PGP FP: FC5A 6FC6 2E25 2DFD 8007 EE23 9BB8 63B0 F51B B88A View my availability: http://tungle.me/sctemme
Re: [RE-VOTE] adoption of mod_firehose MODULE
On 3/1/2012 12:40 PM, Sander Temme wrote: > > Dimpled chad: I would support option 2 if 1 doesn't have traction. Yup - that's implicit.
Re: [RE-VOTE] adoption of mod_firehose MODULE
On Mar 1, 2012 1:29 PM, "Jim Jagielski" wrote: > > > On Mar 1, 2012, at 1:11 PM, William A. Rowe Jr. wrote: > > > Let's simply reset this whole mess. > > > > A proposal to adopt mod_firehose is attached. > > > > [X] Option 1: adopt as trunk module > > [ ] Option 2: adopt only as subproject > > [ ] Option 3: do not adopt +1 for Option 1.
Re: Technical reasons for -1 votes (?)
On Mar 1, 2012, at 1:25 PM, William A. Rowe Jr. wrote: > On 2/29/2012 6:25 PM, Roy T. Fielding wrote: >> >> Yes, but they are modules. Hence, their mere existence in our tree >> is not a technical reason to exclude them. We have a modular architecture >> so that people who don't want a module don't have to build it. > > Which explains mod_macro how, exactly? > At this point, my head exploded Scanners-like...
Re: setting up testing
On Thu, Mar 1, 2012 at 2:50 PM, Michael Felt wrote: > Want to get started on this. I read the links from > http://httpd.apache.org/test/ and think I understand the flood subproject. > From reading the forums here recently I get the impression that more than > flood is being used, or even something other than flood. > > Looking for assistance and suggestions. perl framework... get svn on your AIX box if you don't have it already check out /httpd/test/framework/trunk/ perl Makefile.PL -apxs /path/to/apxs t/TEST t/TEST -clean No it won't be fun because things will fail and there will be many different reasons, few if any obvious ones :) You will likely need to install more Perl modules... Some old instructions of mine: perl -MCPAN -e 'shell' cpan>install Test::Harness cpan>install URI cpan>install LWP::Protocol::https cpan>install HTTP::DAV cpan>install Bundle::ApacheTest cpan>install LWP::Simple (dunno if this is current or everything you need on your level of AIX; this was for OpenSolaris a couple of years ago)
thread ID
Hello, I would need a memory buffer associated per worker thread (in the worker MPM) or to each process (in the prefork MPM). In order to do that, I would need a map thread<->buffer. So, I would need a sort of thread ID/key/handle that stays the same during the lifetime of the thread and no two threads in the same process can have the same ID/key/handle. What is the most portable way to get this thread ID? I thought of r->connection->id. It works but it is not very portable as it is not guaranteed that two connections created by the same thread will have the same id. They do for now. If r->connection->sbh was not opaque it would be great, because sbh->thread_num would be exactly what I need. I could also use pthread_self. It works too but, in general, it is not guaranteed that the worker threads are pthreads. Thank you for your help. Sorin _ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorization. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, France Telecom - Orange shall not be liable if this message was modified, changed or falsified. Thank you.
Re: [RE-VOTE] adoption of mod_firehose MODULE
Seems dangerous to even comment in this flow - but as I am all about thinking "testing" at the moment - is there any thought about how to test this. From a packaging point of view I would expect tooling to be able to test are "included" functions. As a user I would expect anything in trunk (what I would call main) to be guaranteed. I cannot have an opinion about the reasoning for placing something in, or not in "trunk", and I would expect something to at least have gone through some sort of testing process - live testing - before committing anything to a product/service. Before testing was completed I would only dare speaking of an intention to add. Isnt it something along the lines of: "The proof of the pudding is the eating". To me this is just mod_foo, and as far as I know it has never been tested. (If it is already in trunk maybe I have already compiled it and just do not know it :p) - and that alone would make me postpone a non-reversible decision. Makes me think of what someone old and wise said to me when I was young: you (or she) only has to say Yes, or even (yes) once. On Thu, Mar 1, 2012 at 8:33 PM, Greg Stein wrote: > > On Mar 1, 2012 1:29 PM, "Jim Jagielski" wrote: > > > > > > On Mar 1, 2012, at 1:11 PM, William A. Rowe Jr. wrote: > > > > > Let's simply reset this whole mess. > > > > > > A proposal to adopt mod_firehose is attached. > > > > > > [X] Option 1: adopt as trunk module > > > [ ] Option 2: adopt only as subproject > > > [ ] Option 3: do not adopt > > +1 for Option 1. >
Re: setting up testing
perl with -MCPAN I used to use a lot, getting svn - personal build via a personal build is a different story. Guess I'll have to hunt down a package of RPM's for now and solve the core dump problem (in sqlite3 I have found at least). Macros are nice for coding, but less nice when working through dbx (although I used to be an expert with both adb and debug.com) Sigh... Thanks Jeff! On Thu, Mar 1, 2012 at 9:01 PM, Jeff Trawick wrote: > On Thu, Mar 1, 2012 at 2:50 PM, Michael Felt wrote: > > Want to get started on this. I read the links from > > http://httpd.apache.org/test/ and think I understand the flood > subproject. > > From reading the forums here recently I get the impression that more than > > flood is being used, or even something other than flood. > > > > Looking for assistance and suggestions. > > perl framework... > > get svn on your AIX box if you don't have it already > > check out /httpd/test/framework/trunk/ > > perl Makefile.PL -apxs /path/to/apxs > t/TEST > t/TEST -clean > > No it won't be fun because things will fail and there will be many > different reasons, few if any obvious ones :) > > You will likely need to install more Perl modules... Some old > instructions of mine: > >perl -MCPAN -e 'shell' >cpan>install Test::Harness >cpan>install URI >cpan>install LWP::Protocol::https >cpan>install HTTP::DAV >cpan>install Bundle::ApacheTest >cpan>install LWP::Simple > > (dunno if this is current or everything you need on your level of AIX; > this was for OpenSolaris a couple of years ago) >
Re: setting up testing
One quick question: can I assume that the test is ideally in a different machine than the httpd system being tested, or do the tests assume localhost? On Thu, Mar 1, 2012 at 8:50 PM, Michael Felt wrote: > Want to get started on this. I read the links from > http://httpd.apache.org/test/ and think I understand the flood > subproject. From reading the forums here recently I get the impression that > more than flood is being used, or even something other than flood. > > Looking for assistance and suggestions. > > Michael >
Re: setting up testing
On Thu, Mar 1, 2012 at 3:17 PM, Michael Felt wrote: > One quick question: can I assume that the test is ideally in a different > machine than the httpd system being tested, or do the tests assume > localhost? To be honest I haven't looked, but I suspect it is local host only... Once you have the test suite installed somewhere, try t/TEST -help and you'll see a multitude of options, some of which are for controlling the test environment more closely than with the very basic instructions I gave. Come to think of it, try it first on Linux and get it running cleanly there with help of dev@ as necessary, then when on AIX and possibly stumbling through issues getting the right CPAN packages installed you'll already know what it is supposed to look like. And of course you can play with the available test variations. > > On Thu, Mar 1, 2012 at 8:50 PM, Michael Felt wrote: >> >> Want to get started on this. I read the links from >> http://httpd.apache.org/test/ and think I understand the flood subproject. >> From reading the forums here recently I get the impression that more than >> flood is being used, or even something other than flood. >> >> Looking for assistance and suggestions. >> >> Michael > > -- Born in Roswell... married an alien...
Re: TESTING of mod_firehose MODULE
On 3/1/2012 2:05 PM, Michael Felt wrote: > Seems dangerous to even comment in this flow - but as I am all about thinking > "testing" at > the moment - is there any thought about how to test this. From a packaging > point of view I > would expect tooling to be able to test are "included" functions. As a user I > would expect > anything in trunk (what I would call main) to be guaranteed. Changing the subject (please do this yourself next time)... 1. it is in trunk; if you've checked out trunk you likely compiled it and have bin/firehose and modules/mod_firehose.so - and can review the doc page. 2. if it weren't in trunk, the proposer included links to the module. Just drop it in and review it. 3. it's open source. The httpd legacy releases, current stable release and trunk development branch come with exactly one guarantee - if it's broke, you have all the pieces. Maybe I'm not understanding your question?
Re: setting up testing
On 3/1/2012 2:17 PM, Michael Felt wrote: > One quick question: can I assume that the test is ideally in a different > machine than the > httpd system being tested, or do the tests assume localhost? You can do either, see t/TEST --help
Re: Technical reasons for -1 votes (?)
On 3/1/2012 1:58 PM, Jim Jagielski wrote: > > On Mar 1, 2012, at 1:25 PM, William A. Rowe Jr. wrote: > >> On 2/29/2012 6:25 PM, Roy T. Fielding wrote: >>> >>> Yes, but they are modules. Hence, their mere existence in our tree >>> is not a technical reason to exclude them. We have a modular architecture >>> so that people who don't want a module don't have to build it. >> >> Which explains mod_macro how, exactly? > > At this point, my head exploded Scanners-like... Funny, mine had exploded at the dis-congruity of; >>> mod_ftp is there because it isn't an HTTP server. which is apropos of what? This isn't an ajp or scgi or fastcgi server either, it's an http server, which means we should pull out those interfaces?
Re: setting up testing
On Thu, Mar 1, 2012 at 3:14 PM, Michael Felt wrote: > perl with -MCPAN I used to use a lot, getting svn - personal build via a > personal build is a different story. Guess I'll have to hunt down a package > of RPM's for now and solve the core dump problem (in sqlite3 I have found at > least). Macros are nice for coding, but less nice when working through dbx > (although I used to be an expert with both adb and debug.com) I think I've suggested this before, but the path of least resistance on AIX is the java-based svnkit for svn.
Re: setting up testing
yes you have, and I lost the info ... will start the search now... first on linux: assumes you have a linux box ready and waiting, which i dont. However, in 20 minutes I can have a new clean AIX sandbox - so I'll suffer through a bit. CPAN works very well is my memory of it. On Thu, Mar 1, 2012 at 9:45 PM, Eric Covener wrote: > On Thu, Mar 1, 2012 at 3:14 PM, Michael Felt wrote: > > perl with -MCPAN I used to use a lot, getting svn - personal build via a > > personal build is a different story. Guess I'll have to hunt down a > package > > of RPM's for now and solve the core dump problem (in sqlite3 I have > found at > > least). Macros are nice for coding, but less nice when working through > dbx > > (although I used to be an expert with both adb and debug.com) > > I think I've suggested this before, but the path of least resistance > on AIX is the java-based svnkit for svn. >
Re: [RE-VOTE] adoption of mod_firehose MODULE
Modules do not have to be tested *before* they appear in trunk. That's putting the cart before the horse. Part of the development process (while in trunk) is doing the testing portion. And hey... if it never gets tested, then it gets marked as "experimental" and we all move on. Cheers, -g On Thu, Mar 1, 2012 at 15:05, Michael Felt wrote: > Seems dangerous to even comment in this flow - but as I am all about > thinking "testing" at the moment - is there any thought about how to test > this. From a packaging point of view I would expect tooling to be able to > test are "included" functions. As a user I would expect anything in trunk > (what I would call main) to be guaranteed. > > I cannot have an opinion about the reasoning for placing something in, or > not in "trunk", and I would expect something to at least have gone through > some sort of testing process - live testing - before committing anything to > a product/service. Before testing was completed I would only dare speaking > of an intention to add. > > Isnt it something along the lines of: "The proof of the pudding is the > eating". > > To me this is just mod_foo, and as far as I know it has never been tested. > (If it is already in trunk maybe I have already compiled it and just do not > know it :p) - and that alone would make me postpone a non-reversible > decision. > > Makes me think of what someone old and wise said to me when I was young: you > (or she) only has to say Yes, or even (yes) once. > > > On Thu, Mar 1, 2012 at 8:33 PM, Greg Stein wrote: >> >> >> On Mar 1, 2012 1:29 PM, "Jim Jagielski" wrote: >> > >> > >> > On Mar 1, 2012, at 1:11 PM, William A. Rowe Jr. wrote: >> > >> > > Let's simply reset this whole mess. >> > > >> > > A proposal to adopt mod_firehose is attached. >> > > >> > > [X] Option 1: adopt as trunk module >> > > [ ] Option 2: adopt only as subproject >> > > [ ] Option 3: do not adopt >> >> +1 for Option 1. > >
Re: [RE-VOTE] adoption of mod_firehose MODULE
On 3/1/2012 3:02 PM, Greg Stein wrote: > Modules do not have to be tested *before* they appear in trunk. That's > putting the cart before the horse. Part of the development process > (while in trunk) is doing the testing portion. And hey... if it never > gets tested, then it gets marked as "experimental" and we all move on. In fact there is an modules/experimental/ tree; mod_noloris is currently one such module. Of course, "if it never gets tested" is a handwave. There's obviously no way for the pmc to assert committers have tested it. The only filter is the acceptance vote. This submitted module was not committed to modules/experimental/, but rather in modules/debugging/ If your desire was to mark this module experimental, you may want to refine your vote to be more explicit. As a diagnostic tool this module is toxic in resource consumption, so in theory, any bugs in this tool are unlikely to cause more pain than using the tool in the first place.
Re: [RE-VOTE] adoption of mod_firehose MODULE
On Mar 1, 2012, at 4:02 PM, Greg Stein wrote: > Modules do not have to be tested *before* they appear in trunk. That's > putting the cart before the horse. Part of the development process > (while in trunk) is doing the testing portion. And hey... if it never > gets tested, then it gets marked as "experimental" and we all move on. This is why I'm not understanding why this particular module (or set of modules) is getting this level of debate and scrutiny. We're talking about adding them to trunk, not in a release. Presumably we wouldn't put them in a release if there was a problem with them. I've often thought that modules like, say, mod_ftp, would have a much greater chance of being successful if they were in trunk rather than it being several additional steps to obtain. I'm +1 to having this in trunk, but am voting based on the community aspects, rather than the technical ones. I figure the technical aspects will work themselves out in trunk ... or they won't, and we'll drop it from a release branch. -- Rich Bowen rbo...@rcbowen.com :: @rbowen rbo...@apache.org
Re: Win VC10 project files convert
On 2/26/2012 10:11 AM, Steffen wrote: When I recall on the list is stated that .dsw and .dsp files cannot directly be used by VC10, so we should drop them. Correct me if I have read/understood wrong. I will not state that the Express version doesn't, because by the time it came out, I had been used to the dual conversion process because the Pro beta did not. However, I can also recall a mail to dev that said same, and I believe this person was using the Express version. But in the MS docu I read: By using Visual C++ 2010, you can open and save a project that was built in Visual C++ version 6 or later. Visual C++ will convert the project automatically. The upgrade process creates project files that have the extension .vcxproj, and does not remove old project files (.dsp, .vcproj). Tried as test with APR, and yes double clicking the dsp, it converts and builds fine. Later I try HTTPD. I have the Pro version now and tried httpd package last night and the outcome was less than I'd hoped, it just did not do it correctly IMO. Which led to nothing being able to find libs to link to. I just now grabbed the vcproj files from my VC9 build and converted them, no problems so far. One thing I am now noticing is that project dependencies that were set in VC9 cannot be removed in VC10. Gregg
Re: Technical reasons for -1 votes (?)
On Mar 1, 2012, at 9:20 AM, William A. Rowe Jr. wrote: > On 2/29/2012 6:25 PM, Roy T. Fielding wrote: >> On Feb 29, 2012, at 9:42 AM, William A. Rowe Jr. wrote: >>> >>> Let's take Roy's position on the attached vote discussion, it's relevant. >>> These new modules are certainly additions/deletions to httpd. >> >> Yes, but they are modules. Hence, their mere existence in our tree >> is not a technical reason to exclude them. We have a modular architecture >> so that people who don't want a module don't have to build it. In fact, >> it was exactly this type of argument in 1995 that caused rst to focus >> on creating a modular architecture. > > Ok, so to clarify, you are reversing your answer to Joe? The LDAP changes > were a change to a module. Not an httpd-wide API, just a module. So you > are saying that your comment to Joe, "The API was moved to *this* project > and all of the names were changed. It is, effectively, a new public API > for this project." was a misinformed statement (as it moved the ldap code > into mod_ldap and not into the core API). That veto was unjustified? > > Or rather, had we not exported a single symbol, then the veto was unjustified? I don't remember the details, but it was presented by you as a new API. It was described by you as the addition of new LDAP libraries to httpd. And it was most certainly a change to the existing code in mod_ldap. Had it been presented as a new module with a new name and optional configuration, I would have said new modules only need one committer to maintain and a majority vote to decide if there is any objections. Quite frankly, I don't care either way for either change. What I care about is continual use of procedural bullshit to justify interference with other people scratching their own itches. If you don't like the module, then don't use it. If it has security holes or licensing issues, then those are grounds for a veto. If you don't like Grahams's attitude, that's too frigging bad -- find another way to vent your frustration or try to resolve it via the PMC, but don't mix it with a technical vote. >> If there were dependencies or license conditions brought in that somehow >> harmed the server without the module being active, then that would be a >> technical objection. > > There was no such case for the ldap change, so you are saying that specific > veto was unjustified, right? Anyways, all of this is distraction, let's > drill in further to your analysis; > >> Traditionally, we have allowed any module that has at least one willing >> volunteer committer to maintain it. And I agree with Jim, none of the >> subprojects have been as successful as just placing the code in the >> main tree. > > Allowed it by... voting to accept it, right? I accept that all of my > colleagues have different rationals for their +/- votes. Right now, just > about 3% of the committee are willing to entertain these module additions > to httpd trunk and 1.5% are against adding these to trunk. I chalk this > up to burnout, 2.4 was very complex to release and people know their +1 > votes are commitments and alter the httpd tarball for better or worse. If a vote is required (i.e., anyone objects), then it is a majority vote with minimal quorum (three +1s), as usual. > If there was a vote to add this module to core, that would be lovely, we > could vote on it. Sadly, minfrin offered no such vote, and whatever your > conclusion on the 'better course' - it was not voted on, and you hadn't > expressed a vote to adopt it in either case. I submit that there was confusion and the right thing to do would be to ask politely for the confusion to be resolved by an actual vote. It would help if you were not being an ass about it and randomly accusing people of nefarious behavior just because they don't give a damn about this particular difference of opinion. And it isn't Graham's responsibility to run the vote. >> I have no idea why mod_fcgi is in a subproject. mod_ftp is there >> because it isn't an HTTP server. mod_aspdotnet had all sorts of >> licensing issues that I never quite figured out. > > Nonsequitor, if we want to launch into a discussion of subprojects vs. > modules, that's great. That wasn't the conversation minfrin started, > and that's why I have a VETO on the commit. Correct the mis-execution > by conforming to the vote he held, or correct the vote instead. I've > VETOED a commit which is something other than what was voted on because > the project did not consent to his action. You are confused. You don't need to veto a non-event -- just conduct the vote properly and be done. > If there are two other committers who will vote with Jim for this > project to accept one or more of these modules into trunk (rather than > subproject), and someone will finish the ip-clearance, I'm great with > that. If none of that happens I will revert this mess. Fine with me, if you stop blathering about it and conduct the vote properly. You kn
Re: Technical reasons for -1 votes (?)
On Mar 1, 2012, at 12:28 PM, William A. Rowe Jr. wrote: > On 3/1/2012 1:58 PM, Jim Jagielski wrote: >> >> On Mar 1, 2012, at 1:25 PM, William A. Rowe Jr. wrote: >> >>> On 2/29/2012 6:25 PM, Roy T. Fielding wrote: Yes, but they are modules. Hence, their mere existence in our tree is not a technical reason to exclude them. We have a modular architecture so that people who don't want a module don't have to build it. >>> >>> Which explains mod_macro how, exactly? >> >> At this point, my head exploded Scanners-like... > > Funny, mine had exploded at the dis-congruity of; > mod_ftp is there because it isn't an HTTP server. > > which is apropos of what? It is a different product. If it were changed so that it could be meaningfully documented as part of the HTTP server, then I'd suggest it be moved to trunk too. > This isn't an ajp or scgi or fastcgi server > either, it's an http server, which means we should pull out those interfaces? Those are all gateway interfaces *used* by an HTTP server to communicate with a backend. If we had a better way to ship modular code, like CPAN or gem, they wouldn't be part of our core product. But we don't, so they are (or should be). Roy
Re: [RE-VOTE] adoption of mod_firehose MODULE
On Thu, Mar 1, 2012 at 16:30, Rich Bowen wrote: >... > I've often thought that modules like, say, mod_ftp, would have a much > greater chance of being successful if they were in trunk rather than it > being several additional steps to obtain. > > I'm +1 to having this in trunk, but am voting based on the community > aspects, rather than the technical ones. I figure the technical aspects will > work themselves out in trunk ... or they won't, and we'll drop it from a > release branch. Exactly. In the subversion project, we always strive to do development directly on trunk (rather than branches). Keeping stuff in trunk gives it many more eyeballs and testing. New features might be buggy on trunk, but "just don't use it yet" is a good response :-) Cheers, -g
Re: [RE-VOTE] adoption of mod_firehose MODULE
I learned something tonight :) On Thu, Mar 1, 2012 at 11:37 PM, Greg Stein wrote: > On Thu, Mar 1, 2012 at 16:30, Rich Bowen wrote: > >... > > I've often thought that modules like, say, mod_ftp, would have a much > > greater chance of being successful if they were in trunk rather than it > > being several additional steps to obtain. > > > > I'm +1 to having this in trunk, but am voting based on the community > > aspects, rather than the technical ones. I figure the technical aspects > will > > work themselves out in trunk ... or they won't, and we'll drop it from a > > release branch. > > Exactly. In the subversion project, we always strive to do development > directly on trunk (rather than branches). Keeping stuff in trunk gives > it many more eyeballs and testing. New features might be buggy on > trunk, but "just don't use it yet" is a good response :-) > > Cheers, > -g >
Re: setting up testing
trying: # svnkit-1.3.7/bin/jsvn checkout http://svn.apache.org/viewvc/httpd/test/framework/trunk test get: svn: Repository moved permanently to '/viewvc/httpd/test/framework/trunk'; please relocate svn: OPTIONS request failed on '/viewvc/httpd/test/framework/trunk' Explanation please. On Thu, Mar 1, 2012 at 9:01 PM, Jeff Trawick wrote: > On Thu, Mar 1, 2012 at 2:50 PM, Michael Felt wrote: > > Want to get started on this. I read the links from > > http://httpd.apache.org/test/ and think I understand the flood > subproject. > > From reading the forums here recently I get the impression that more than > > flood is being used, or even something other than flood. > > > > Looking for assistance and suggestions. > > perl framework... > > get svn on your AIX box if you don't have it already > > check out /httpd/test/framework/trunk/ > > perl Makefile.PL -apxs /path/to/apxs > t/TEST > t/TEST -clean > > No it won't be fun because things will fail and there will be many > different reasons, few if any obvious ones :) > > You will likely need to install more Perl modules... Some old > instructions of mine: > >perl -MCPAN -e 'shell' >cpan>install Test::Harness >cpan>install URI >cpan>install LWP::Protocol::https >cpan>install HTTP::DAV >cpan>install Bundle::ApacheTest >cpan>install LWP::Simple > > (dunno if this is current or everything you need on your level of AIX; > this was for OpenSolaris a couple of years ago) >
Re: setting up testing
On Thu, Mar 1, 2012 at 8:09 PM, Michael Felt wrote: > trying: > # svnkit-1.3.7/bin/jsvn checkout > http://svn.apache.org/viewvc/httpd/test/framework/trunk test > > get: > svn: Repository moved permanently to '/viewvc/httpd/test/framework/trunk'; > please relocate > svn: OPTIONS request failed on '/viewvc/httpd/test/framework/trunk' > > Explanation please. viewvc is a CGI script, not part of the svn path This page here has an example of checking out something under the httpd project: http://httpd.apache.org/dev/devnotes.html > > On Thu, Mar 1, 2012 at 9:01 PM, Jeff Trawick wrote: >> >> On Thu, Mar 1, 2012 at 2:50 PM, Michael Felt wrote: >> > Want to get started on this. I read the links from >> > http://httpd.apache.org/test/ and think I understand the flood >> > subproject. >> > From reading the forums here recently I get the impression that more >> > than >> > flood is being used, or even something other than flood. >> > >> > Looking for assistance and suggestions. >> >> perl framework... >> >> get svn on your AIX box if you don't have it already >> >> check out /httpd/test/framework/trunk/ >> >> perl Makefile.PL -apxs /path/to/apxs >> t/TEST >> t/TEST -clean >> >> No it won't be fun because things will fail and there will be many >> different reasons, few if any obvious ones :) >> >> You will likely need to install more Perl modules... Some old >> instructions of mine: >> >> perl -MCPAN -e 'shell' >> cpan>install Test::Harness >> cpan>install URI >> cpan>install LWP::Protocol::https >> cpan>install HTTP::DAV >> cpan>install Bundle::ApacheTest >> cpan>install LWP::Simple >> >> (dunno if this is current or everything you need on your level of AIX; >> this was for OpenSolaris a couple of years ago) > > -- Born in Roswell... married an alien...
IP Clearance? NAK
On 3/1/2012 4:17 PM, Roy T. Fielding wrote: > On Mar 1, 2012, at 9:20 AM, William A. Rowe Jr. wrote: > >> Perhaps you are signing up to do that ip-clearance, since it doesn't >> seem to be coming from the committer. > > IP clearance for an existing committer is BULLSHIT. I already cleared > that with Legal when I was chair of this project. Somehow, having chaired the HTTP Server project for 2 years, I had missed the memo. This information is not being communicated. Thank you for enlightening me, our chair Eric, and the rest of the TLP communities. The HTTP Server Project will proceed to ignore the IP Clearance process laid out by the Incubator for all incoming contributions from any actual project committer or their employer, until informed otherwise by the President of the foundation.
Re: IP Clearance? NAK
On Thu, Mar 1, 2012 at 20:52, William A. Rowe Jr. wrote: > On 3/1/2012 4:17 PM, Roy T. Fielding wrote: >> On Mar 1, 2012, at 9:20 AM, William A. Rowe Jr. wrote: >> >>> Perhaps you are signing up to do that ip-clearance, since it doesn't >>> seem to be coming from the committer. >> >> IP clearance for an existing committer is BULLSHIT. I already cleared >> that with Legal when I was chair of this project. > > Somehow, having chaired the HTTP Server project for 2 years, I had missed > the memo. This information is not being communicated. Thank you for > enlightening me, our chair Eric, and the rest of the TLP communities. > > The HTTP Server Project will proceed to ignore the IP Clearance process > laid out by the Incubator for all incoming contributions from any actual > project committer or their employer, until informed otherwise by the > President of the foundation. Why don't you stop with your passive-aggressive bullshit, and read the thread over on legal-discuss where we talked about fixing the "short form" IP Clearance process. The IP policies have not changed, but they *should*, along the lines Roy suggests in that thread. The HTTP PMC cannot ignore the clearance process. But we do need to fix the process. And we don't need your crap. -g
Re: IP Clearance? NAK
On 3/1/2012 9:08 PM, Greg Stein wrote: > > Why don't you stop with your passive-aggressive bullshit, and read the > thread over on legal-discuss where we talked about fixing the "short > form" IP Clearance process. The IP policies have not changed, but they > *should*, along the lines Roy suggests in that thread. Greg; Roy just stated, it's not applicable and invalid. Ergo the project will ignore this "process" until either 1. the Legal Committee or 2. the ASF President inform the HTTP project of specific external steps that it must follow with respect to IP intake offered by committers (and as proxy for their employers). Incubator isn't actually given any jurisdiction over projects. Legal committee is... and Roy states that Legal cleared HTTP from following this (quoting) BULLSHIT process in respect to committer contributions. I am getting incredibly frustrated with the fact that three founders and current board members have no common institutional memory. You three probably should just hang up the hats already if you can't agree for even a single day on a recollection any particular precedent. I might be passive aggressive some days, but I'm not a psychopathic schizophrenic as the three headed RoyGregJim beast is. In the meantime, there is a project to run. Roy acting as a former officer has informed Eric, the current chair, and myself, a former chair, of specific internal and official communication with the legal committee that this process is not applicable to contributions from committers, and we will respect Roy's recollection as former Chair until we hear otherwise from an officer (not a schizo Director) of the foundation.
Re: Technical reasons for -1 votes (?)
On 3/1/2012 4:17 PM, Roy T. Fielding wrote: > On Mar 1, 2012, at 9:20 AM, William A. Rowe Jr. wrote: > >> Or rather, had we not exported a single symbol, then the veto was >> unjustified? > > I don't remember the details, but it was presented by you as a new API. > It was described by you as the addition of new LDAP libraries to > httpd. And it was most certainly a change to the existing code in > mod_ldap. Roy, I'm sorry. Obviously I miscommunicated. It was a former API. The proposal was to fold that behavior into a single self-contained module. I will present this in the coming month in a manner that conforms to your understanding of a "module" vs. an "API", such that no individual can veto it, and the dozen+ of us can vote for it and be forever rid of the garbage former-API constraint, ignoring those crazy voices from the wilderness. > If a vote is required (i.e., anyone objects), then it is a majority vote > with minimal quorum (three +1s), as usual. That's the page I started on, thanks for confirming! These modules did NOT have majorities for inclusion in trunk. Tonight, one finally does. I never believed I had a veto, only 1 vote against blind implied consent. > I submit that there was confusion and the right thing to do would be to > ask politely for the confusion to be resolved by an actual vote. > It would help if you were not being an ass about it and randomly > accusing people of nefarious behavior just because they don't give > a damn about this particular difference of opinion. > > And it isn't Graham's responsibility to run the vote. Ah, but you see, that's the rub. There WAS a vote. A proposal was made by Graham, a vote was held by Graham, and a DIFFERENT course of action was followed by Graham. Amazingly, Graham ran the successful vote, for an altogether different outcome. That is what is objectionable; if there is anything in the past months demonstrates psychotic behavior, it is not my objections to what had transpired, but what actually transpired. Quoting the private list, where there is to be no development discussion (so ergo these comments cannot be confidential); On 12/8/2011 7:40 AM, Graham Leggett wrote: > On 08 Dec 2011, at 3:30 PM, William A. Rowe Jr. wrote: > >> But I think we are saying the same thing... I just wanted to be >> sure this was understood as "[poll] Potential Adoption of..." and >> not something actually "adopted" as in your message subject. > > The word "proposal" means exactly that, and I haven't seen any > misunderstanding so far from anybody. at which point, the entire discussion went sideways once Graham adopted the input of private@ development discussion into his next actions. As the Chief Agent and Advocate against dev discussions happening in private off of the dev list, I'm relying on you personally to ensure this doesn't reoccur.
Re: setting up testing
In other words, I needed to look lower at: so I should be using: "svn checkout" https://svn.apache.org/repos/asf/perl/Apache-Test/trunk Apache-Test Thanks On Fri, Mar 2, 2012 at 2:29 AM, Jeff Trawick wrote: > On Thu, Mar 1, 2012 at 8:09 PM, Michael Felt wrote: > > trying: > > # svnkit-1.3.7/bin/jsvn checkout > > http://svn.apache.org/viewvc/httpd/test/framework/trunk test > > > > get: > > svn: Repository moved permanently to > '/viewvc/httpd/test/framework/trunk'; > > please relocate > > svn: OPTIONS request failed on '/viewvc/httpd/test/framework/trunk' > > > > Explanation please. > > viewvc is a CGI script, not part of the svn path > > This page here has an example of checking out something under the httpd > project: > > http://httpd.apache.org/dev/devnotes.html > > > > > On Thu, Mar 1, 2012 at 9:01 PM, Jeff Trawick wrote: > >> > >> On Thu, Mar 1, 2012 at 2:50 PM, Michael Felt wrote: > >> > Want to get started on this. I read the links from > >> > http://httpd.apache.org/test/ and think I understand the flood > >> > subproject. > >> > From reading the forums here recently I get the impression that more > >> > than > >> > flood is being used, or even something other than flood. > >> > > >> > Looking for assistance and suggestions. > >> > >> perl framework... > >> > >> get svn on your AIX box if you don't have it already > >> > >> check out /httpd/test/framework/trunk/ > >> > >> perl Makefile.PL -apxs /path/to/apxs > >> t/TEST > >> t/TEST -clean > >> > >> No it won't be fun because things will fail and there will be many > >> different reasons, few if any obvious ones :) > >> > >> You will likely need to install more Perl modules... Some old > >> instructions of mine: > >> > >>perl -MCPAN -e 'shell' > >>cpan>install Test::Harness > >>cpan>install URI > >>cpan>install LWP::Protocol::https > >>cpan>install HTTP::DAV > >>cpan>install Bundle::ApacheTest > >>cpan>install LWP::Simple > >> > >> (dunno if this is current or everything you need on your level of AIX; > >> this was for OpenSolaris a couple of years ago) > > > > > > > > -- > Born in Roswell... married an alien... >
Re: setting up testing
Seems to have worked, and only a minor error/warning (I hope) - twice... Manifying blib/man3/Apache::TestHandler.3 lib/Apache/TestHandler.pm:106: Unknown command paragraph "=encoding utf8" So, I expect I'll still have to load more stuff from CPAN, once I find the start button... On Fri, Mar 2, 2012 at 8:34 AM, Michael Felt wrote: > In other words, I needed to look lower at: > > so I should be using: "svn checkout" > https://svn.apache.org/repos/asf/perl/Apache-Test/trunk Apache-Test > > Thanks > > > On Fri, Mar 2, 2012 at 2:29 AM, Jeff Trawick wrote: > >> On Thu, Mar 1, 2012 at 8:09 PM, Michael Felt wrote: >> > trying: >> > # svnkit-1.3.7/bin/jsvn checkout >> > http://svn.apache.org/viewvc/httpd/test/framework/trunk test >> > >> > get: >> > svn: Repository moved permanently to >> '/viewvc/httpd/test/framework/trunk'; >> > please relocate >> > svn: OPTIONS request failed on '/viewvc/httpd/test/framework/trunk' >> > >> > Explanation please. >> >> viewvc is a CGI script, not part of the svn path >> >> This page here has an example of checking out something under the httpd >> project: >> >> http://httpd.apache.org/dev/devnotes.html >> >> > >> > On Thu, Mar 1, 2012 at 9:01 PM, Jeff Trawick wrote: >> >> >> >> On Thu, Mar 1, 2012 at 2:50 PM, Michael Felt >> wrote: >> >> > Want to get started on this. I read the links from >> >> > http://httpd.apache.org/test/ and think I understand the flood >> >> > subproject. >> >> > From reading the forums here recently I get the impression that more >> >> > than >> >> > flood is being used, or even something other than flood. >> >> > >> >> > Looking for assistance and suggestions. >> >> >> >> perl framework... >> >> >> >> get svn on your AIX box if you don't have it already >> >> >> >> check out /httpd/test/framework/trunk/ >> >> >> >> perl Makefile.PL -apxs /path/to/apxs >> >> t/TEST >> >> t/TEST -clean >> >> >> >> No it won't be fun because things will fail and there will be many >> >> different reasons, few if any obvious ones :) >> >> >> >> You will likely need to install more Perl modules... Some old >> >> instructions of mine: >> >> >> >>perl -MCPAN -e 'shell' >> >>cpan>install Test::Harness >> >>cpan>install URI >> >>cpan>install LWP::Protocol::https >> >>cpan>install HTTP::DAV >> >>cpan>install Bundle::ApacheTest >> >>cpan>install LWP::Simple >> >> >> >> (dunno if this is current or everything you need on your level of AIX; >> >> this was for OpenSolaris a couple of years ago) >> > >> > >> >> >> >> -- >> Born in Roswell... married an alien... >> > >
Re: setting up testing
I have seen the name apxs many times in the past, t/TEST -help names an -apxs location of apxs (default is from Apache2::BuildConfig) Currently I have a partition (actually a WPAR) that only has perl updated via cpan and Apache-Test loaded. Since I wont be starting the httpd locally, do I still need apxs? It looks like it is used for start/stop/reconfig? Off to work, thanks again for the help! On Fri, Mar 2, 2012 at 8:42 AM, Michael Felt wrote: > Seems to have worked, and only a minor error/warning (I hope) - twice... > > Manifying blib/man3/Apache::TestHandler.3 > lib/Apache/TestHandler.pm:106: Unknown command paragraph "=encoding utf8" > > So, I expect I'll still have to load more stuff from CPAN, once I find the > start button... > > On Fri, Mar 2, 2012 at 8:34 AM, Michael Felt wrote: > >> In other words, I needed to look lower at: >> >> so I should be using: "svn checkout" >> https://svn.apache.org/repos/asf/perl/Apache-Test/trunk Apache-Test >> >> Thanks >> >> >> On Fri, Mar 2, 2012 at 2:29 AM, Jeff Trawick wrote: >> >>> On Thu, Mar 1, 2012 at 8:09 PM, Michael Felt wrote: >>> > trying: >>> > # svnkit-1.3.7/bin/jsvn checkout >>> > http://svn.apache.org/viewvc/httpd/test/framework/trunk test >>> > >>> > get: >>> > svn: Repository moved permanently to >>> '/viewvc/httpd/test/framework/trunk'; >>> > please relocate >>> > svn: OPTIONS request failed on '/viewvc/httpd/test/framework/trunk' >>> > >>> > Explanation please. >>> >>> viewvc is a CGI script, not part of the svn path >>> >>> This page here has an example of checking out something under the httpd >>> project: >>> >>> http://httpd.apache.org/dev/devnotes.html >>> >>> > >>> > On Thu, Mar 1, 2012 at 9:01 PM, Jeff Trawick >>> wrote: >>> >> >>> >> On Thu, Mar 1, 2012 at 2:50 PM, Michael Felt >>> wrote: >>> >> > Want to get started on this. I read the links from >>> >> > http://httpd.apache.org/test/ and think I understand the flood >>> >> > subproject. >>> >> > From reading the forums here recently I get the impression that more >>> >> > than >>> >> > flood is being used, or even something other than flood. >>> >> > >>> >> > Looking for assistance and suggestions. >>> >> >>> >> perl framework... >>> >> >>> >> get svn on your AIX box if you don't have it already >>> >> >>> >> check out /httpd/test/framework/trunk/ >>> >> >>> >> perl Makefile.PL -apxs /path/to/apxs >>> >> t/TEST >>> >> t/TEST -clean >>> >> >>> >> No it won't be fun because things will fail and there will be many >>> >> different reasons, few if any obvious ones :) >>> >> >>> >> You will likely need to install more Perl modules... Some old >>> >> instructions of mine: >>> >> >>> >>perl -MCPAN -e 'shell' >>> >>cpan>install Test::Harness >>> >>cpan>install URI >>> >>cpan>install LWP::Protocol::https >>> >>cpan>install HTTP::DAV >>> >>cpan>install Bundle::ApacheTest >>> >>cpan>install LWP::Simple >>> >> >>> >> (dunno if this is current or everything you need on your level of AIX; >>> >> this was for OpenSolaris a couple of years ago) >>> > >>> > >>> >>> >>> >>> -- >>> Born in Roswell... married an alien... >>> >> >> >