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 local
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, 20
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/b
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
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
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
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
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 '
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, Ma
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
> > be
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 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
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/deletion
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 bee
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
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 "experim
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,
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 a
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). Macr
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 arch
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
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
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
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 thin
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
db
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
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 tw
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
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
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
> >
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.
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
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
>
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?
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
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. Subs
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 h
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
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 WIN
> 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.
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.apac
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
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
43 matches
Mail list logo
