Thanks for testing. The release is approved:
PMC votes: +1 from ylavic, jfclere, jorton
I will promote the release and announce it.
Regards, Joe
-
To unsubscribe, e-mail: dev-unsubscr...@perl.apache.org
For additional
On Thu, Aug 18, 2022 at 12:31:56PM +0100, Joe Orton wrote:
> Hi, I've prepared a candidate release tarball for libapreq2 v2.17 here:
>
> https://dist.apache.org/repos/dist/dev/httpd/libapreq/
>
> I would like to call a VOTE over the next week to release this candidate
>
On Sun, Aug 21, 2022 at 04:28:25PM -0400, Edward J. Sabol wrote:
> "make test" reported no errors. However, the following tests were skipped:
>
> t/cgi.t .. skipped: cannot find one of cgi.c or cgid.c
>
> t/apreq/cgi.t skipped: cannot find one of cgi.c or cgid.c
>
Hi, I've prepared a candidate release tarball for libapreq2 v2.17 here:
https://dist.apache.org/repos/dist/dev/httpd/libapreq/
I would like to call a VOTE over the next week to release this candidate
tarball as v2.17:
[ ] +1: It's not just good, it's good enough!
[ ] +0: Let's have a talk.
[ ]
On Mon, Mar 22, 2021 at 06:14:35PM +, Steve Hay wrote:
> Success! We now have libapreq2-2.16 correctly indexed on (Meta)CPAN:
>
> https://metacpan.org/release/SHAY/libapreq2-2.16
>
> Thanks to Joe and all the testers/voters for getting this update done.
Nice, thanks Steve!
Regards, Joe
Thanks for testing again, the vote has passed:
PMC votes: +1 from rpluem, ylavic, jorton
Community: +1 stevehay
I'll promote the release & send the announcement mail.
Regards, Joe
-
To unsubscribe, e-mail:
On Wed, Mar 10, 2021 at 04:05:14PM +, Joe Orton wrote:
> I would like to call a VOTE over the next week to release this candidate
> tarball as v2.16:
>
> [X] +1: It's not just good, it's good enough!
> [ ] +0: Let's have a talk.
> [ ] -1: There's trouble in paradise. H
On Wed, Mar 10, 2021 at 04:05:16PM +, Joe Orton wrote:
> Hi, I've prepared a candidate release tarball for libapreq2 v2.15 here:
You can see I'm still an amateur at this - should read ^^ v2.16
-
To unsubscribe, e-m
Hi, I've prepared a candidate release tarball for libapreq2 v2.15 here:
https://dist.apache.org/repos/dist/dev/httpd/libapreq/
This release is to address an issue blocking the upload to CPAN.
I would like to call a VOTE over the next week to release this candidate
tarball as v2.16:
[ ] +1:
On Wed, Jul 03, 2019 at 08:45:36AM +0100, Steve Hay wrote:
> Please download, test, and report back on this Apache-Test 1.41
> release candidate.
>
> https://dist.apache.org/repos/dist/dev/perl/Apache-Test-1.41-rc1.tar.gz
>
> MD5 = 7933d3a6a762f087bf7883a1ac2086eb
> SHA1 =
On Tue, Jun 25, 2013 at 12:16:04AM +0300, Niko Tyni wrote:
Ah, I was thinking about hunting for relative configuration file names,
but I guess it's more about the log directories and stuff like that?
I can see SYSCONFDIR isn't ideal either for those but I still
think it's better than nothing
On Sun, Jun 23, 2013 at 11:51:25PM +0300, Niko Tyni wrote:
Starting with 2.4, Apache needs to read its configuration file even to
report its version and build parameters with the -V option, probably
because the MPM module can be chosen at run time.
However, the system Apache configuration
On Sun, Jun 23, 2013 at 11:10:20PM +0300, Niko Tyni wrote:
Quoting http://httpd.apache.org/docs/trunk/developer/new_api_2_4.html:
Create run-time files such as shared memory files, pid files, etc.
Use ap_runtime_dir_relative() so that the global configuration for the
location of
On Tue, Jun 18, 2013 at 09:43:10PM +0300, Niko Tyni wrote:
Debian and Ubuntu packaged versions of Apache2 don't define PREFIX,
so 'make test' output is filled with warnings like
APXS (/usr/bin/apxs2) query for PREFIX failed
OK - devil's advocate time. That's a packaging bug, so the test
On Wed, Aug 01, 2012 at 01:41:34PM -0700, Fred Moyer wrote:
The reason this test failure occurs is because the RedHat rpm devs
patched the version component code to replace 'Unix' with @VENDOR@, in
these cases either Centos or Fedora. But their patch isn't complete -
they didn't patch the
CC'ing test-dev@.
On Thu, Jan 20, 2011 at 12:00:41PM -0500, Jim Jagielski wrote:
On the latest Fedora, -times=X no longer works:
t/modules/rewrite.t .. ok
t/modules/rewrite.t .. ok
You already have a parser for (t/modules/rewrite.t). Perhaps you have run the
same test twice. at
On Fri, Oct 16, 2009 at 03:32:04PM -0400, Jeff Trawick wrote:
..
--- Apache-Test/lib/Apache/TestConfigParse.pm (revision 822728)
+++ Apache-Test/lib/Apache/TestConfigParse.pm (working copy)
@@ -224,15 +224,15 @@
$name = $modname_alias{$name} if $modname_alias{$name};
-#
On Wed, Apr 02, 2008 at 03:15:19PM +0100, Joe Orton wrote:
On Tue, Apr 01, 2008 at 11:26:43PM -0700, Philippe M. Chiasson wrote:
The mod_perl 2.0.4 release candidate 1 Works with Perl 5.10 is ready. It
can be downloaded here:
http://www.apache.org/~gozer/mp2/mod_perl-2.0.4-rc1.tar.gz
On Sat, Nov 24, 2007 at 11:50:54AM -0500, William McKee wrote:
...
I did try to run TEST using the -httpd_conf option as follows but it's
still trying to inherit from /etc/apache2/httpd.conf:
./t/TEST -httpd_conf=/etc/apache2/apache2.conf -conf -trace=debug
Ah, OK. A::TestConfig is
On Mon, Nov 19, 2007 at 11:45:59PM -0500, William McKee wrote:
On Mon, Nov 19, 2007 at 09:31:30AM +, Joe Orton wrote:
Debian/Ubuntu does not use httpd.conf to load modules; it uses
apache2.conf and loads the modules from a directory
(/etc/apache2/mods-enabled). mod_env, which
On Wed, Nov 21, 2007 at 11:31:27AM -0800, Fred Moyer wrote:
Geoffrey Young wrote:
fwiw, I just watched fred get caught by this exact thing at apachecon -
don't forget to nuke ~/.apache-test beforehand :)
Yeah that was no fun, and I don't think it was the first time it happened
to me. This
On Wed, Nov 21, 2007 at 07:35:37PM +, Joe Orton wrote:
On Wed, Nov 21, 2007 at 11:31:27AM -0800, Fred Moyer wrote:
Geoffrey Young wrote:
fwiw, I just watched fred get caught by this exact thing at apachecon -
don't forget to nuke ~/.apache-test beforehand :)
Yeah that was no fun
On Sun, Nov 18, 2007 at 12:30:22PM -0500, William McKee wrote:
...
Debian/Ubuntu does not use httpd.conf to load modules; it uses
apache2.conf and loads the modules from a directory
(/etc/apache2/mods-enabled). mod_env, which provides the PassEnv
directive, is being loaded in this way. I guess
Is it necessary or desirable for all of the ModPerl::* modules bundled
with mod_perl to be installed? Many of these are very specific to the
mod_perl build process and would seem to have little or no use to
anything external.
I've been looking at this w.r.t the Fedora mod_perl package; the
On Thu, May 04, 2006 at 01:55:01PM +0100, Darryl Miles wrote:
I am auditing upgrading my development systems for HTTP 2.2.0 usage and
thought I should bring your attention the failed test cases. The host
linux system does not have any apache 2.2.x installation and no system
libaprutil-1
On Fri, Feb 03, 2006 at 08:32:50PM -0500, Joe Schaefer wrote:
Philippe M. Chiasson [EMAIL PROTECTED] writes:
Just for the record, this change had *nothing* to do with httpd-2.2, it was
experienced under 2.2, but only because I built it with
-DAPR_POOL_DEBUG.
It's actually a function
On Thu, Dec 15, 2005 at 01:26:59PM -0500, Geoffrey Young wrote:
if ($self-{MP_MAINTAINER}) {
$self-{MP_DEBUG} = 1;
-if ($self-perl_config('gccversion')) {
-#same as --with-maintainter-mode
-$ccopts .= $Wall -DAP_DEBUG;
-
On Wed, Dec 14, 2005 at 01:32:21AM -0500, Philip M. Gollucci wrote:
Hi All,
I'm thinking we should roll the 2.0.3 release soonish.
1. Fix the Apache2::Reload regression with mod_perl.pm
2. Update the docs to say we support 2.2.0 to avoid endless stream
of questions. I got a lot of
On Wed, Dec 14, 2005 at 09:52:46AM -0500, Geoffrey Young wrote:
the two things that I'd like to get out in the next release are
- make sure that 2.2 tests cleanly, which apparenty it doesn't.
- remove the pod glue that's probably pointless now and adds a truckload
of time to the
On Wed, Dec 14, 2005 at 10:27:57AM -0800, Stas Bekman wrote:
Geoffrey Young wrote:
Philip M. Gollucci wrote:
Hi All,
I'm thinking we should roll the 2.0.3 release soonish.
1. Fix the Apache2::Reload regression with mod_perl.pm
2. Update the docs to say we support 2.2.0 to avoid
Does anyone know why mod_perl is defining AP_HAVE_DESIGNATED_INITIALIZER
and AP_DEBUG for debug builds? (I'd check the history but minotaur is
down again)
These are really up to httpd to define, or not. On the trunk (and
hopefully soon also 2.2.x), AP_HAVE_DESIGNATED_INITIALIZER is defined
On Wed, Sep 28, 2005 at 11:08:58AM -0400, Geoffrey Young wrote:
Philip M. Gollucci wrote:
2.0.47 bus core dumps when you attempt to run it despite compiling under
maintainer mode.
I believe this is your same core dump mentioned above.
yeah, sounds like it. mod_perl won't even build for
On Fri, Sep 23, 2005 at 10:12:18AM -0400, Geoffrey Young wrote:
This was discussed a while back. I don't think it makes sense for
mod_perl to set r-proxyreq to anything other than PROXYREQ_REVERSE;
this fixes the failure, Geoff may disagree still though ;)
:)
ok, in all honesty I get
On Wed, Sep 28, 2005 at 10:38:58AM -0400, Geoffrey Young wrote:
Joe Orton wrote:
ok, joe, thanks for responding.
I don't know what to take away from all the joint questions, though... guess
we all need some more (round) tuits :)
I'll second that :)
But either
way: setting
On Fri, Sep 23, 2005 at 04:51:17AM -0400, Philip M. Gollucci wrote:
Joe Orton wrote:
On Mon, Sep 12, 2005 at 03:42:28AM -0400, Philip M. Gollucci wrote:
Philip M. Gollucci wrote:
What happens is:
requested: http://localhost:8536/TestModules__proxy
proxied to: http://localhost:8536
The APR base64 encode/decode functions expect unsigned char * arguments
for the raw binary input/output buffers. gcc 4.x now warns for pointer
signedness mismatches like this; casting is really the only way.
(alternatively, if you dislike this, the warning can be turned off)
Also the
The wrong APR generation is being picked up now the httpd trunk has
bumped to 2.3.x; here's a fix. Actually perhaps a better fix would be
to invert the logic; e.g. m/20\d+/ ? 0 : 1
--- lib/Apache2/Build.pm.orig 2005-07-19 09:44:18.0 +0100
+++ lib/Apache2/Build.pm2005-07-19
On Tue, Jul 19, 2005 at 08:22:23AM -0400, Geoffrey Young wrote:
Joe Orton wrote:
The APR base64 encode/decode functions expect unsigned char * arguments
for the raw binary input/output buffers. gcc 4.x now warns for pointer
signedness mismatches like this; casting is really the only way
On Thu, Jun 02, 2005 at 01:10:11PM -0700, Philippe M. Chiasson wrote:
Joe Orton wrote:
But 2.0.x does not support LFS, people who build with
-D_FILE_OFFSET_BITS=64 are playing with fire and should completely
expect everything to burn down around them at any moment. This
combination
On Wed, Jun 01, 2005 at 05:09:59PM -0700, Philippe M. Chiasson wrote:
Ian Holsman wrote:
Philippe M. Chiasson wrote:
Ian Holsman wrote:
I just tried this on a EL3 machine, and it goes further (ie.. it can
start apache)
the version of perl is the same, but the httpd on EL3 is
On Fri, May 13, 2005 at 11:58:05AM -0400, Stas Bekman wrote:
Joe Orton wrote:
the script does the merge from between 165203 and HEAD of the trunk into
that working copy, and resets the merge-point property to the revision
number of the HEAD, ready for next time. So finally you just commit
On Tue, May 17, 2005 at 11:02:17AM -0400, Stas Bekman wrote:
Joe Orton wrote:
On Fri, May 13, 2005 at 11:58:05AM -0400, Stas Bekman wrote:
Joe Orton wrote:
the script does the merge from between 165203 and HEAD of the trunk into
that working copy, and resets the merge-point property
On Tue, May 17, 2005 at 11:32:07AM -0400, Stas Bekman wrote:
Joe Orton wrote:
[...]
% svn info . | sed -n '/^URL/{s,/branches/.*,,;s/^URL://;p}'
https://svn.apache.org/repos/asf/perl/modperl/trunk
That's the trunk, not a branch. The script should be run from a
checkout of the *branch
On Tue, May 17, 2005 at 04:14:27PM -0400, Stas Bekman wrote:
Joe Orton wrote:
You should remove the merge-point property from the branch before
merging it back, though, since there's little point in having that on
the trunk.
May be it's a good idea to then script that merge-point removal
On Thu, May 12, 2005 at 04:06:06PM -0400, Stas Bekman wrote:
Joe Orton wrote:
You can use a semi-automated technique by recording the last-merge-point
as a property; I've been using this script:
http://people.apache.org/~jorton/svn.remerge
for one of my projects, it seems to work quite
On Wed, May 11, 2005 at 02:58:30PM -0400, Stas Bekman wrote:
Markus Wichitill wrote:
Stas Bekman wrote:
Seeing how painful was the last branch's merge, I was wondering if
there is an automatic way to keep the branch in sync with the trunk.
Unfortunately not, that would require merge
On Wed, Apr 20, 2005 at 11:37:57AM -0400, Stas Bekman wrote:
Geoffrey Young wrote:
Stas Bekman wrote:
Thanks Torsten. Hopefully this was the last thing lost in the merging of
the rename branch, which was promised to just work.
yeah, well, I'm sorry about that. I did the best I could.
On Thu, Apr 21, 2005 at 10:36:55AM -0400, Geoffrey Young wrote:
It may be easier to blame the tool but SVN just does what you tell it,
there is no automatic branch merging. SVN is little more advanced than
CVS in this regard; it relies on some external mechanism (e.g. human
beans) to
On Sun, Mar 27, 2005 at 08:06:39PM -0500, Stas Bekman wrote:
My problem is that I can't see how can I stick a call to
MP_CLONE_INSERT_OBJ() inside the mp_xs_APR__Pool_2obj(ptr) wrapper. Since
it's usually used as:
RETVAL = mp_xs_APR__Pool_2obj(ptr);
Is there some C trick to have
On Wed, Feb 23, 2005 at 09:42:12AM +, Joe Orton wrote:
On Tue, Feb 22, 2005 at 10:52:57PM -0800, Justin Erenkrantz wrote:
The issue with this is that wildcard IP addresses aren't really supposed to
be explicit in Listen statements. httpd has a bunch of logic for inferring
the right
On Mon, Feb 14, 2005 at 08:53:44AM -0500, Geoffrey Young wrote:
looks ok to me, though it means that in addition to
have_module('mod_rewrite.c');
have_module('mod_rewrite');
working
have_module('rewrite');
have_module('rewrite.c');
will also work. hopefully that is
On Tue, Feb 08, 2005 at 08:36:49PM -0500, Stas Bekman wrote:
Steve Hay wrote:
[...]
Yes - adding the sleep 2 before print 'parent' does indeed fix it.
(Your changed version still didn't work without that sleep, though.)
Yes, I know. And if you uncomment out the 3 join calls? It
On Mon, Feb 07, 2005 at 05:39:03PM +, Steve Hay wrote:
What is it with tests called ithreads.t?
Here's what I get @rev151728:
This started failing in my Linux builds too as of 2005-02-05 on:
Perl 5.8.5 on ppc, Perl 5.8.5 on i386, Perl 5.8.3 on i386
but is passing on:
Perl 5.8.0 on
On Wed, Jan 05, 2005 at 02:09:52PM -0500, Stas Bekman wrote:
Gisle Aas wrote:
Stas Bekman [EMAIL PROTECTED] writes:
How do I check the limit for pthread_key_create on linux?
On my Gentoo box I find the limit here:
$ grep PTHREAD_KEYS_MAX /usr/include/bits/local_lim.h
Hi folks, this fixes the build against the httpd trunk which renamed the
mis-named ap_http_method macro to ap_http_scheme:
Index: xs/Apache/RequestRec/Apache__RequestRec.h
===
--- xs/Apache/RequestRec/Apache__RequestRec.h (revision
On Thu, Jan 06, 2005 at 12:04:04PM -0800, Philippe M. Chiasson wrote:
Once again, a leaner cleaner way to implement our own X-Powered-By
header ala PHP. (missing docs/tests)
FWIW I think X-Powered-By: is a trend of really poor taste. If every
module or filter decided that it was too important
Hi, we had a mod_perl user on Fedora Core report an example of this
error: http://www.gossamer-threads.com/lists/modperl/modperl/62201
I'm trying to get more information on the repro case so I can check it
out locally, but it seems that the proposed patch didn't make it to CVS.
Was that an
On Fri, Nov 26, 2004 at 04:37:49PM -0500, Stas Bekman wrote:
I can't recall whether this was discussed before, but t/modules/proxy.t
fails with httpd-2.1. Is anybody following the mod_proxy changes?
I'll note that this may get fixed such that it only works for enabling a
reverse-proxy decision
On Wed, Dec 01, 2004 at 09:40:54AM -0500, Stas Bekman wrote:
Joe Orton wrote:
On Fri, Nov 26, 2004 at 04:37:49PM -0500, Stas Bekman wrote:
I can't recall whether this was discussed before, but t/modules/proxy.t
fails with httpd-2.1. Is anybody following the mod_proxy changes?
I'll note
On Wed, Dec 01, 2004 at 10:59:22AM -0500, Geoffrey Young wrote:
...
now, I _think_ joes argument is that for the second part the server should
be required to set 'ProxyRequest On' in httpd.conf, which indicates the
arrangement the client and server have agreed upon.
Yes, that's an accurate
On Wed, Dec 01, 2004 at 10:43:22AM -0500, Joe Schaefer wrote:
Stas Bekman [EMAIL PROTECTED] writes:
One needs to go through a deprecation cycle before any backwards
compatibility in the same generation of the project can be dropped.
Heh, a search for deprecation cycle on marc's [EMAIL
On Mon, Nov 29, 2004 at 09:30:24AM -0500, Geoffrey Young wrote:
Stas Bekman wrote:
I can't recall whether this was discussed before, but t/modules/proxy.t
fails with httpd-2.1. Is anybody following the mod_proxy changes?
yes, joe orton and I have been following this. IIRC what
On Fri, Nov 19, 2004 at 09:07:58PM -0800, Garrett Rooney wrote:
Stas Bekman wrote:
I find the fact that svn dumps its file copies into the same tree with
the source files pretty annoying, since it's no longer possible to grep
files, since you get dups, and do other things. Is there a way to
On Mon, Nov 15, 2004 at 12:33:18PM -0800, Geoffrey Young wrote:
When the spamassassin group made the switch, they added a file to the
CVS at the top level, telling everyone still checking it out that it was
obsolete and to use svn instead. I hope that happens with mod_perl's
tree, too. I
On Thu, Oct 07, 2004 at 04:04:16PM -0400, Geoffrey Young wrote:
hi all...
just FYI, 2.1 is failing t/modules/proxy.t with a 404. I've spent some time
this afternoon trying to see what (of importance) has changed in between 2.0
and HEAD but I can't see where it is at the moment.
I tracked
On Mon, Oct 11, 2004 at 09:26:37AM -0400, Geoffrey Young wrote:
Joe Orton wrote:
as far as the fact that mod_proxy in HEAD refuses to
act as a forward proxy unless ProxyRequests On has been configured.
So adding ProxyRequests On as below fixes the test but whether this
should actually
On Thu, Oct 07, 2004 at 09:20:23AM -0400, Joe Schaefer wrote:
Philippe M. Chiasson [EMAIL PROTECTED] writes:
[...]
#2 0x0021b45c in apr_bucket_alloc_create_ex (allocator=0x0) at
apr_buckets_alloc.c:67
#3 0x0021b405 in apr_bucket_alloc_create (p=0x9353f70) at
On Thu, Oct 07, 2004 at 04:04:16PM -0400, Geoffrey Young wrote:
hi all...
just FYI, 2.1 is failing t/modules/proxy.t with a 404. I've spent some time
this afternoon trying to see what (of importance) has changed in between 2.0
and HEAD but I can't see where it is at the moment.
I don't
New build break with older compilers, from a declaration after a
statement:
--- xs/Apache/RequestUtil/Apache__RequestUtil.h 4 Oct 2004 19:27:37 - 1.26
+++ xs/Apache/RequestUtil/Apache__RequestUtil.h 5 Oct 2004 10:32:34 -
@@ -306,10 +306,12 @@
const char *retval =
On Fri, Oct 01, 2004 at 01:10:37PM -0400, Joe Schaefer wrote:
I cranked up httpd via gdb and stepped through the test.
Here's the first bad stack frame I see- notice first two
arguments to apr_pcalloc_debug are mangled (they *should*
be (pool=0x2f01080, size=16) at modperl_module.c:39-
Is
On Mon, Sep 20, 2004 at 09:38:37PM -0400, Stas Bekman wrote:
Joe Orton wrote:
There was a Satisfy merging regression in 2.0.51 which Rici Lake tracked
down, these problems should go away if you apply this patch:
http://cvs.apache.org/viewcvs.cgi/httpd-2.0/server/core.c?r1=1.285r2=1.286
I
On Sat, Sep 18, 2004 at 09:30:49AM -0400, Stas Bekman wrote:
SMOKE has found that:
t/TEST -v t/api/access2.t t/api/access.t
(both run in the same interpreters)
breaks t/api/access.t
# testing : satisfies
# expected: 2
# received: 0
not ok 5
There was a Satisfy merging regression
installations of apr-util and apr, where apr-util has been installed
with a different includedir to apr.
Submitted by: Joe Orton
hey joe :)
did this patch alone really solve the problem for you? I can't get mod_perl
to compile against httpd-2.1-rc1 with an external apr/apu.
Oh
This supports building against a separate apr-util (i.e. where the
apr-util installed $includedir != apr $includedir), and also uses the
output of `apxs -q APR_CONFIG` where available to pick up ap[ru]-config.
I haven't tested that this doesn't break the build against 2.0.x but it
Should Be OK
On Wed, Aug 18, 2004 at 10:54:13AM -0700, Stas Bekman wrote:
Joe Orton wrote:
Thanks Joe.
Any chance this can be rewritten to find out what syntax to use (2.0 or
2.1) once and not do that repeatedly? This function is the cause of the
slow configuration (too many shell calls), so trying
On Wed, Aug 18, 2004 at 07:55:25PM +0100, Joe Orton wrote:
On Wed, Aug 18, 2004 at 10:54:13AM -0700, Stas Bekman wrote:
Joe Orton wrote:
Thanks Joe.
Any chance this can be rewritten to find out what syntax to use (2.0 or
2.1) once and not do that repeatedly? This function is the cause
On Thu, Jul 01, 2004 at 04:52:50PM -0700, Philippe M. Chiasson wrote:
Nah, in the case of APR_BUCKET_DEBUG, it only makes one little extra
check when deleting buckets in apr_bucket_free :
It also turns on consistency checks in the brigade manipulation macros
in apr_buckets.h.
On Tue, Jun 29, 2004 at 04:52:31PM -0700, Stas Bekman wrote:
Philippe M. Chiasson wrote:
-8-- Start Bug Report 8--
1. Problem Description:
protocol/echo_bbs2 is failing with a core dump when calling
$bb-cleanup
diff -u -I$Id -r1.2 echo_bbs2.pm
---
message from Joe Orton [EMAIL PROTECTED] -
From: Joe Orton [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Mail-Followup-To: [EMAIL PROTECTED]
Date: Thu, 17 Jun 2004 10:46:37 +0100
Subject: destroying passed brigades
User-Agent: Mutt/1.4.1i
Any further thoughts on this, Cliff
On Sat, Jun 19, 2004 at 11:17:28PM +0300, Stas Bekman wrote:
Joe Orton wrote:
Hiya folks, just wondering what impact (if any) these changes I've been
working on would have on mod_perl and filters implemented using
mod_perl?
The change is simply that after calling ap_pass_brigade
On Mon, May 24, 2004 at 01:07:45PM -0700, Stas Bekman wrote:
How did you run that script? ModPerl/Const/Const.so is not supposed to be
loaded when mod_perl is running. I've double checked with Apache::VMonitor.
Ah, OK, sorry. The script I have just uses nm -D to examine object
files directly,
On the subject of duplicate symbol definitions, I ran the script I have
to check for such things against mod_perl and it found a few already,
using mod_perl 1.99_12 (httpd-2.0.49, perl 5.8.3).
mod_perl.so ModPerl/Const/Const.so = modperl_constants_group_lookup_apache
mod_perl.so
I think I understand the issue now (but my coffee has nearly run out),
and I've asked [EMAIL PROTECTED] for clarification. Meanwhile there is an double
negative bug in echo_block.pm: it tries to clear the NONBLOCK flag, then
fails if it is cleared.
--- protocol/TestProtocol/echo_block.pm 4 May
Having looked at this more I don't understand why it's failing, and the
Solaris build environment I was using is acting up so I can't get
anything to build...
apr_socket_recv, and hence the socket bucket -read function, looks like
it should do the right thing for a non-blocking socket, and that's
On Thu, May 06, 2004 at 08:48:40PM -0700, Stas Bekman wrote:
Joe, I've committed a workaround for the non-blocking socket issue so
people won't send complaints. But the bug in Apache didn't go away, so we
still need that to get fixed. Thanks. To expose it back, just unroll this
change.
OK,
Actually, the O_NONBLOCK thing is new behaviour introduced in 2.0.49
with the multi-listen DoS security fix... so maybe this is a recent
regression, and it really counts as an httpd bug. (or have you been
getting these similar failure reports on Solaris/... for ages?)
joe
With a HEAD of 2.0 and mod_perl built on Solaris 7/x86 against Perl
5.6.1 (-Uuselargefiles) I got:
Failed Test Status Wstat Total Fail Failed List of
Failed
t/apr-ext/uuid.t 0
On Wed, Apr 07, 2004 at 09:51:56AM -0700, Stas Bekman wrote:
Joe Orton wrote:
...
t/filter/both_str_con_add.t42 50.00% 3-4
t/protocol/echo.t 31 33.33% 3
t/protocol/echo_filter.t 31 33.33% 3
These three
The issue with the echo.t test on Solaris is that the socket is in
non-blocking mode on the server, so on the second recv() the server just
returns EINTR as there's no data available.
but... the fact that this works on Linux means that the socket has been
left in blocking mode there, and it
On Wed, Apr 07, 2004 at 01:44:23PM -0700, Stas Bekman wrote:
Joe Orton wrote:
The issue with the echo.t test on Solaris is that the socket is in
non-blocking mode on the server, so on the second recv() the server just
returns EINTR as there's no data available.
Coolio, Joe. So should we set
On Sun, Apr 04, 2004 at 09:51:38PM -0700, Stas Bekman wrote:
Geoffrey Young wrote:
you mean that -D_FILE_OFFSET_BITS=64 ought to be stripped from $perl_cflags
and perl recompiled, not that mod_perl can get away with simply not
including that value when it itself is compiled. if it were
On Sun, Apr 04, 2004 at 09:40:18PM -0700, Stas Bekman wrote:
Joe Orton wrote:
OK, let's do the background... on Unix systems where by default off_t is
a long, a 32-bit integer, there are two different ways to get large
file support, i.e. the ability to manipulate files bigger than 2Gb
On Mon, Apr 05, 2004 at 11:30:19AM -0700, Stas Bekman wrote:
Joe Orton wrote:
Great. It looks like mod_perl is not pulling in all the right variables
from apxs though still. APR HEAD will break if -D_LARGEFILE64_SOURCE is
not defined when including apr.h on many platforms. On Linux you get
I think I answered this one pre-emptively in my background post :)
On Mon, Apr 05, 2004 at 01:33:16PM -0700, Stas Bekman wrote:
There is one more bit that is not clear to me:
httpd 2.1 gives me: -D_LARGEFILE64_SOURCE
... this is what's needed for using approach (2) to Doing LFS
perl gives
On Mon, Apr 05, 2004 at 01:11:05PM -0700, Stas Bekman wrote:
Joe Orton wrote:
[...]
If you want to be conservative, just stick with EXTRA_CPPFLAGS; this
should be sufficient to make sure apr.h can be safely included. The
problem is if you use EXTRA_CFLAGS you need NOTEST_CPPFLAGS normally
On Mon, Apr 05, 2004 at 02:00:58PM -0700, Stas Bekman wrote:
...
since we look for /-D_FILE_OFFSET_BITS=64/ and we don't find it on the
apache side we strip /-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64/, but
now that I've added EXTRA_CPPFLAGS, I get -D_LARGEFILE64_SOURCE pushed
in. Isn't
The concrete proposal:
1. mod_perl should be extracting the output of `apr-config --cflags`
`apr-config --cppflags` at some point. This can either be done by using
apr-config directly, or by getting it out of `apxs -q EXTRA_CFLAGS` and
`apxs -q EXTRA_CPPFLAGS`.
(apxs in 2.0 sucks really because
OK, let's do the background... on Unix systems where by default off_t is
a long, a 32-bit integer, there are two different ways to get large
file support, i.e. the ability to manipulate files bigger than 2Gb:
1) you compile using -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64. This
makes sys/types.h
I actually can't convince myself that changing APR_HAS_LARGE_FILES to be
0 on APR HEAD when LFS support is *enabled* is the right thing to do; it
just doesn't make sense.
I think the right way to solve this is to make mod_perl's
has_large_files_conflict/strip_lfs functions a bit more smarter,
On Thu, Apr 01, 2004 at 02:49:56PM -0800, Stas Bekman wrote:
Joe Orton wrote:
I actually can't convince myself that changing APR_HAS_LARGE_FILES to be
0 on APR HEAD when LFS support is *enabled* is the right thing to do; it
just doesn't make sense.
I think the right way to solve
100 matches
Mail list logo
