[RESULT: PASS] Re: [VOTE] Release libapreq2-2.17

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 commands

Re: [VOTE] Release libapreq2-2.17

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

Re: [VOTE] Release libapreq2-2.17

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 >

[VOTE] Release libapreq2-2.17

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. [ ]

Re: [RESULT: PASS] Re: [VOTE] Release libapreq2-2.16

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 --

[RESULT: PASS] Re: [VOTE] Release libapreq2-2.16

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: dev-unsubscr...@perl

Re: [VOTE] Release libapreq2-2.16

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 tr

Re: [VOTE] Release libapreq2-2.16

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 unsubs

[VOTE] Release libapreq2-2.16

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: It'

Re: [RELEASE CANDIDATE] Apache-Test-1.41 RC1

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 = 17aa9a8669023aa2f485aa

Re: [PATCH] Apache-Test: Fall back to SYSCONFDIR if PREFIX is not set

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 nothin

Re: [PATCH] Apache-Test: Fall back to SYSCONFDIR if PREFIX is not set

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 *

Re: [Apache-Test + httpd24] [PATCH] Set DefaultRuntimeDir on Apache 2.4

On Sun, Jun 23, 2013 at 11:10:20PM +0300, Niko Tyni wrote: > Quoting : > > 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

Re: [Apache-Test + httpd24] [PATCH] Run "httpd -V" with the test config

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 configurat

Re: t/api/server_const.t test failure from Red Hat developer vanity patches

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 s

Re: [RELEASE CANDIDATE] mod_perl-2.0.4 RC1

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.apa

Re: [RELEASE CANDIDATE] mod_perl-2.0.4 RC1

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 > > MD5: 1f0a941e8b5f26b6102126ae67ddbb43 > SHA1: 8b2ceede3c7

installed modules

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 lis

Re: MP2.0.2 + HTTPD 2.2.0 Linux test failures (libaprutil-1.so.0: cannot open shared object file)

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

Re: svn commit: r374792 - /perl/modperl/trunk/t/lib/TestAPRlib/table.pm

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

Re: [PATCH] stop defining AP_HAVE_DESIGNATED_INITIALIZER/AP_DEBUG

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"; > > -

Re: 2.0.3 and httpd 2.2

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

Re: 2.0.3 and httpd 2.2

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 i

Re: 2.0.3 and httpd 2.2

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

Re: [PATCH] stop defining AP_HAVE_DESIGNATED_INITIALIZER/AP_DEBUG

On Tue, Dec 13, 2005 at 09:42:25AM -0500, Geoffrey Young wrote: > Joe Orton wrote: > > 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) > > I w

[PATCH] stop defining AP_HAVE_DESIGNATED_INITIALIZER/AP_DEBUG

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 in

Re: maintainer mode (was Re: httpd 2.3.01 and t/modules/proxy.t)

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 bu

Re: httpd 2.3.01 and t/modules/proxy.t

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 :)

Re: httpd 2.3.01 and t/modules/proxy.t

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 ho

Re: httpd 2.3.01 and t/modules/proxy.t

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:

Re: httpd 2.3.01 and t/modules/proxy.t

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/TestModules__proxy_real > > > > > >But if I directly request > >http://localhost:8536/Tes

Re: [PATCH] fix warnings with gcc 4.x

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;

[PATCH] fix build for httpd trunk

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 0

[PATCH] fix warnings with gcc 4.x

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 mpxs_APR__B

Re: mod_perl2_current (from today) + EL4 == segfault

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

Re: mod_perl2_current (from today) + EL4 == segfault

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

Re: syncing branches with trunk, how?

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 i

Re: syncing branches with trunk, how?

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, no

Re: syncing branches with trunk, how?

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

Re: syncing branches with trunk, how?

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.

Re: syncing branches with trunk, how?

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 > >

Re: syncing branches with trunk, how?

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

Re: make DESTDIR=... install

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 > > bean

Re: make DESTDIR=... install

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 bes

Re: C question (was Re: [mp2] Our API is not perl thread-safe)

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

Re: New ModPerl-Registry/t/ithreads.t test fails on Win32

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 th

Re: New ModPerl-Registry/t/ithreads.t test fails on Win32

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

Re: [Patch mp2] X-Powered-By

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

[PATCH] fix 2.1 build for ap_http_method rename

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

Re: [Fwd: [PATCH] libperl leaks a THREAD_KEY each time it is reloaded]

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/l

"failed to get bucket brigade" errors

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 oversi

[PATCH] modperl_restart_count fix

Current SVN failed -Werror build on x86_64 due to casting between integers and pointer types: modperl_util.c: In function `modperl_restart_count_inc': modperl_util.c:814: warning: cast from pointer to integer of different size modperl_util.c:817: warning: cast to pointer from integer of different

Re: t/modules/proxy.t fails with httpd-2.1

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'

Re: t/modules/proxy.t fails with httpd-2.1

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 s

Re: t/modules/proxy.t fails with httpd-2.1

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 a

Re: t/modules/proxy.t fails with httpd-2.1

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 "decisi

Re: t/modules/proxy.t fails with httpd-2.1

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

Re: svn question

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 w

Re: [NOTICE] Subversion conversion

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,

Re: t/modules/proxy.t failure with 2.1

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"

Re: t/modules/proxy.t failure with 2.1

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 track

Re: t/modules/proxy.t failure with 2.1

On Fri, Oct 08, 2004 at 10:27:23AM -0400, Stas Bekman wrote: > Joe Orton wrote: > >On Fri, Oct 08, 2004 at 10:08:21AM -0400, Stas Bekman wrote: > > > >>And it'd be nice for the failing test to run t/REPORT and include it in > >>the output. W/o it we know alm

Re: t/modules/proxy.t failure with 2.1

On Fri, Oct 08, 2004 at 10:08:21AM -0400, Stas Bekman wrote: > And it'd be nice for the failing test to run t/REPORT and include it in > the output. W/o it we know almost nothing about what perl and apache > builds were used. I guessed you'd say that... I've changed the script to append ./t/REPO

Re: t/modules/proxy.t failure with 2.1

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

Re: t/apr/bucket is dumping core on me

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 > > APU_DEC

Re: [mp2] status with perl 5.6

On Tue, Sep 28, 2004 at 12:24:12AM -0400, Stas Bekman wrote: > I've gleaned out almost all the issues with mp2 and 5.6, all were just > test tweaks. The only remaining issue is failing: t/perl/api.t, but it > doesn't fail on its own, so I'm running the SMOKE for it now. Hopefully > will know the

[PATCH] Apache__RequestUtil.h fix

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 = ap_document_roo

Re: segfault in worker mpm

On Mon, Oct 04, 2004 at 10:03:51AM +0100, Joe Orton wrote: > On Sun, Oct 03, 2004 at 07:21:12PM -0400, Stas Bekman wrote: > > modperl-2.0 'make test' running under worker mpm (linux) always fails in > > t/filter/both_str_req_add.t and dumps core: > > That starte

Re: segfault in worker mpm

On Sun, Oct 03, 2004 at 07:21:12PM -0400, Stas Bekman wrote: > modperl-2.0 'make test' running under worker mpm (linux) always fails in > t/filter/both_str_req_add.t and dumps core: That started failing for me on October 2nd with mod_perl HEAD against tip-of-2.0 on amd64 with the attached backtra

Re: t/TEST t/directive/cmdparms.t segfaults w/5.8.5+ithreads

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

Re: [PATCH] Re: t/SMOKE points the finger at filter/out_bbs_filebucket.t

I'm not sure if you guys noticed but since I changed ap_save_brigade's handling of ENOTIMPL setasides on HEAD (motivated by a similar issue) there are now several tests always failing: t/filter/out_bbs_basic.t 255 65280?? ?? % ?? t/filter/out_bbs_ctx.t

Re: [PATCH] Re: segfault ap_save_brigage in the latest 2.0

On Wed, Sep 29, 2004 at 11:43:27PM -0400, Stas Bekman wrote: > Joe Schaefer wrote: > >>>t/api/aplog.t 351 2.86% 24 I wrote a fix for this one the other day since it was easy. --- response/TestAPI/aplog.pm 24 Sep 2004 19:55:35 - 1.21 +++ response/

Re: segfault ap_save_brigage in the latest 2.0

On Tue, Sep 28, 2004 at 06:55:32PM -0400, Stas Bekman wrote: > Joe Orton wrote: > >Index: modperl_filter.c > >=== > >RCS file: /home/cvspublic/modperl-2.0/src/modules/perl/modperl_filter.c,v > >retrievi

Re: segfault ap_save_brigage in the latest 2.0

On Tue, Sep 28, 2004 at 12:32:36PM -0400, Joe Schaefer wrote: > Stas Bekman <[EMAIL PROTECTED]> writes: > > [...] > > > > Any ideas about how to fix the segfaults at startup time too? > > > > I'll try to reproduce it now. > > I'm able to get these segfults now, but not reliably. BTW it was use

Re: segfault ap_save_brigage in the latest 2.0

Let's continue this on [EMAIL PROTECTED] since it doesn't seem like there's an httpd bug currently. On Mon, Sep 27, 2004 at 01:49:29PM -0400, Joe Schaefer wrote: > Joe Orton <[EMAIL PROTECTED]> writes: > > [...] > > > when it did start up it would

Re: t/api/access.t is broken

On Tue, Sep 21, 2004 at 09:25:53AM -0400, Geoffrey Young wrote: > I was able to confirm the breakage in 2.0.51 and that applying the patch to > APACHE_2_0_BRANCH fixed the issue exposed in the mp2 test suite. > > since the patch had sufficient votes to be backported from 2.1 to 2.0 I took > care o

Re: t/api/access.t is broken

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.

Re: t/api/access.t is broken

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 r

Re: cvs commit: modperl-2.0 Changes

, where httpd has been built against separate > > 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

Re: [PATCH] 2.1 build foo

On Wed, Aug 25, 2004 at 09:31:27AM -0700, Stas Bekman wrote: > Joe Orton wrote: > >The thing I really want is to fix out-of-tree apr-util builds anyway, > >can someone commit that half of the patch if it's OK? > > What problem does it solve? Is this something needed fo

Re: [PATCH] 2.1 build foo

On Tue, Aug 24, 2004 at 11:52:15PM -0700, Stas Bekman wrote: > but Joe, don't let this discussion get on your way, commit the thing > (after the 2.0 way) and we will optimise it later. But re-ordering the tests really defeats the point of the change (which was to *skip* all the messy 2.0 tests an

Re: [PATCH] 2.1 build foo

On Wed, Aug 18, 2004 at 12:34:01PM -0700, Stas Bekman wrote: > Joe Orton wrote: > >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: > >>&g

Re: [PATCH] 2.1 build foo

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

Re: [PATCH] 2.1 build foo

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 man

[PATCH] 2.1 build foo

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 Rea

Re: [mp2] protocol/echo_bbs2 on Win32

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. ---

Re: [mp2] protocol/echo_bbs2 on Win32

On Thu, Jul 01, 2004 at 02:06:33PM -0700, Stas Bekman wrote: ... > $7 = (struct apr_bucket *) 0x1011007 > (gdb) print *((*b)->list->prev) > Cannot access memory at address 0x1011007 > > I don't understand why it doesn't happen on my setup which seems to be > pretty close to philippe's one. I supp

Re: [Bug mp2] $bb->cleanup in protocol/echo_bbs2 dumps core

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

Re: Fwd: destroying passed brigades

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 sim

Fwd: destroying passed brigades

, joe (please CC me on replies) ----- Forwarded 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-

Re: duplicate symbols

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

duplicate symbols

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 ModPerl/Const/C

Re: O_NONBLOCK issue

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 20

O_NONBLOCK issue

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

Re: cvs commit: modperl-2.0/t/protocol/TestProtocol echo_filter.pm echo_timeout.pm

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.

O_NONBLOCK

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 -

Re: large file support

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 avail

Re: large file support

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 should

Re: large file support

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

Re: large file support

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 13

  1   2   >