On Sat, May 30, 2009 at 9:39 PM, Sander Temme wrote:
>
> On May 29, 2009, at 1:08 AM, William A. Rowe, Jr. wrote:
>
> Candidates in the usual location, may take up to an hour to sync.
>> Letting this vote run through midnight Monday morning, my time,
>> so depending on my weekend I'll either sta
On Thu, May 21, 2009 at 5:57 PM, Bojan Smojver wrote:
> On Thu, 2009-05-21 at 14:59 -0500, William A. Rowe, Jr. wrote:
> > If you want to grab any safe, low risk low hanging fruit, have at it.
>
> We need to backport this, right?
>
> http://svn.apache.org/viewvc?view=rev&revision=768417
for sur
On Fri, May 15, 2009 at 3:26 PM, Jeff Trawick wrote:
> mod_p hooks the post_config more than once, including really_last. mod_s's
> post_config has to run after mod_p's post_config (both of them) for one of
> its features to work. I tried adding "mod_p.c" to th
mod_p hooks the post_config more than once, including really_last. mod_s's
post_config has to run after mod_p's post_config (both of them) for one of
its features to work. I tried adding "mod_p.c" to the predecessor list in
mod_s, but it wasn't effective, as predecessor processing doesn't account
On Thu, May 7, 2009 at 10:55 AM, Edmund Wong wrote:
> Jeff Trawick wrote:
>
> Shouldn't APR_POOL_DECLARE_ACCESSOR(file) become
>>>
>>> APR_DECLARE(apr_pool_t *) apr_file_pool_get(apr_file_t *thefile); ?
>>>
>>
>>
>> yes, it does; so t
On Thu, May 7, 2009 at 9:47 AM, Edmund Wong wrote:
> Given the following declaration:
>
> #define APR_POOL_DECLARE_ACCESSOR(type) \
>APR_DECLARE(apr_pool_t *) apr_##type##_pool_get \
>(const apr_##type##_t *the##type)
>
> In the docstring above it, it says:
>
> APR_POOL_DECLARE_ACCESS
On Fri, Apr 24, 2009 at 4:10 PM, C. Michael Pilato wrote:
> [Please Cc: me in responses -- I think I still have APR commit privs, but
> I'm not active here and not subscribed to the mailing lists.]
>
> In the past couple of weeks, I've seen two different reports of what
> appears
> to be corrupti
On Fri, Apr 24, 2009 at 2:10 PM, venkatnv wrote:
>
> Well ... i think we found the root cause, in one of the libraries being
> used,
> the mutex was not being initialized. Thanks!
>
>
> venkatnv wrote:
> >
> > We are observing issues with pthread Mutexes on Apache22/Solaris10. Not
> > sure if thi
(I'm not subscribed to d...@perl...)
On Mon, Apr 20, 2009 at 6:18 PM, Marc Adkins wrote:
> I found this in mod_perl but the issue can be demonstrated without Perl.
>
> Attempting to open a file for append using the following flags:
>
> APR_BUFFERED | APR_BINARY | APR_CREATE | APR_APPEND
>
>
> w
On Wed, Apr 8, 2009 at 11:00 AM, Jim Jagielski wrote:
>
> On Mar 30, 2009, at 3:02 PM, Jim Jagielski wrote:
>
>>
>> Yep... I will try to recreate on Ubuntu in addition to the
>> OS X testing.
>>
>>
> OK This seems unrelated (maybe) to the new pool...
>
> The cause for the slowdown was due to
On Fri, Jan 23, 2009 at 11:14 AM, Joe Orton wrote:
> On Fri, Jan 23, 2009 at 07:10:36AM -0500, Jeff Trawick wrote:
> > On Fri, Jan 23, 2009 at 7:00 AM, Eric Covener wrote:
> > > On Fri, Jan 23, 2009 at 3:46 AM, Graham Leggett
> wrote:
> > > > This is the firs
On Mon, Mar 30, 2009 at 2:33 PM, Jeff Trawick wrote:
>
>
> On Mon, Mar 30, 2009 at 2:07 PM, Jim Jagielski wrote:
>
>> Anyone know if:
>>
>> # POSIX semaphores and cross-process pthread mutexes are not
>> # used by default since they have less desirable
On Mon, Mar 30, 2009 at 2:07 PM, Jim Jagielski wrote:
> Anyone know if:
>
> # POSIX semaphores and cross-process pthread mutexes are not
> # used by default since they have less desirable behaviour when
> # e.g. a process holding the mutex segfaults.
>
> is still applicable, at least for posix
On Thu, Mar 26, 2009 at 8:24 PM, wrote:
>
> > APR_POLLSET_THREADSAFE isn't supported with all
> > implementations. I expect that apr_pollset_create() is
> > returning APR_ENOTIMPL, and the crash is due to an
> > uninitialized pollset.
>
> Excellent point - I should have checked for a return code
On Thu, Mar 26, 2009 at 3:54 PM, wrote:
I've got Cygwin's libapr1 1.3.3-1
>
> I've built Ganglia (3.1.0) from source and it works.
>
> I then modify this line of code in gmond.c, adding the flag
> APR_POLLSET_THREADSAFE:
>
> apr_pollset_create(&listen_channels, total_listen_channels,
> global_co
On Thu, Mar 26, 2009 at 11:03 AM, Paul Querna wrote:
> I believe Platforms that have no one around to support should be
> removed (svn history will always be there, and they can always be
> rebuilt). In APR especially the operating systems with different
> implementations, I would prefer to just
On Wed, Mar 25, 2009 at 10:13 AM, SAMEER KUMAR wrote:
> I have downloaded APR and installed it on my Fedora 9 machine using the
> configure and make commands. I tested the installation with testall. But I
> am not able to use this in my programs and not able to link to the header
> files in APR.
On Tue, Mar 24, 2009 at 12:33 PM, Graham Leggett wrote:
> Jeff Trawick wrote:
>
> any counter-knowledge/opinions on the following?
>>
>> assert(only httpd uses apr LDAP)
>>
>
> Can you cite references to show this is so? I would be very hard pressed to
> ass
On Tue, Mar 24, 2009 at 11:26 AM, Justin Erenkrantz
wrote:
> So, during the conversations we've had here in Amsterdam regarding
> combining APR and APR-util (see post from Paul), one of the big
> stumbling blocks has been our treatment of the LDAP interfaces via
> APR-util.
>
> The crux of the iss
On Fri, Feb 27, 2009 at 10:48 AM, Guilherme Namen wrote:
> After i compiled apr in FreeBsd 7 i run tests and the testpoll fail
> whith segmentation fault. The gdb said that the bug are in testpoll.c
> file line 389.
> I execute:
> o ./configure --enable-threads
> o make
> o make test
>
> So
On Tue, Feb 24, 2009 at 7:06 AM, Joe Orton wrote:
> On Mon, Feb 23, 2009 at 03:52:44PM -0500, Jeff Trawick wrote:
> > Surely this is a FAQ, but I couldn't find it. Why aren't user CFLAGS
> > included in "apr-1-config --cflags"?
> > A notable example
Surely this is a FAQ, but I couldn't find it. Why aren't user CFLAGS
included in "apr-1-config --cflags"?
A notable example of where this hurts is with a 64-bit APR build, where
anything which uses that APR must also be 64-bit but the "CFLAGS=-m64" or
similar which APR was built with aren't report
On Sat, Feb 21, 2009 at 5:22 PM, wrote:
> Author: trawick
> Date: Sat Feb 21 22:22:34 2009
> New Revision: 746597
>
> URL: http://svn.apache.org/viewvc?rev=746597&view=rev
> Log:
> simplifications and minor improvements to error reporting and
> pathlength
I think there may still be feedback iss
On Mon, Feb 9, 2009 at 4:25 AM, Mladen Turk wrote:
> That makes me think we can have that generic, allowing
> different pollset providers for non-windows platforms
> as well (If it makes sense of course), eg. something
> like we have for proc_mutex.
> (apr_proc_mutex_unix_lock_methods_t would act
On Mon, Jan 26, 2009 at 10:02 AM, wrote:
> Author: trawick
> Date: Mon Jan 26 15:02:22 2009
> New Revision: 737705
>
> URL: http://svn.apache.org/viewvc?rev=737705&view=rev
> Log:
> Support ldap library names with non-alphanumeric characters, such
> as libldap-2.4.so.
>
> Modified: apr/apr-util/t
On Fri, Jan 23, 2009 at 7:40 AM, Greg Stein wrote:
> On Fri, Jan 23, 2009 at 13:24, Jeff Trawick wrote:
> > On Fri, Jan 23, 2009 at 5:31 AM, Greg Stein wrote:
> >>
> >> Check for ebcdic? Are we *really* going to continue support for that?
> >> Seriousl
On Fri, Jan 23, 2009 at 5:31 AM, Greg Stein wrote:
> Check for ebcdic? Are we *really* going to continue support for that?
> Seriously, folks.
What is the better criteria?
* offends sensibility of at least one APR contributor
* actively used by and depended on by multiple APR contributors (and
On Fri, Jan 23, 2009 at 7:00 AM, Eric Covener wrote:
> On Fri, Jan 23, 2009 at 3:46 AM, Graham Leggett wrote:
> > This is the first time I have heard of ldap_r. Is there a reason why we
> > can't just try bind to ldap_r first, and if that fails fall back to ldap?
>
> I think that's the way to go
Is it expected that for threaded use I should build apr-util with
--with-ldap=ldap_r
instead of the default?
I haven't found clear info on this topic.
(On Ubuntu 8.10 and OS X, libldap_r and libldap point to the same place. On
RHEL 5, there are two distinct libraries.)
Thanks!
--
Born in Ros
On Fri, Jan 16, 2009 at 3:02 PM, Graham Leggett wrote:
> Jeff Trawick wrote:
>
> With Ubuntu's packaging of OpenLDAP 2.4.9 and whatever OpenLDAP is in
>> Leopard.latest, LDAP_OPT_REFHOPLIMIT is defined in ldap.h but the library
>> returns an error when trying to
On Fri, Jan 16, 2009 at 4:07 PM, Paul J. Reder wrote:
>
>
> Jeff Trawick wrote:
>
>> With Ubuntu's packaging of OpenLDAP 2.4.9 and whatever OpenLDAP is in
>> Leopard.latest, LDAP_OPT_REFHOPLIMIT is defined in ldap.h but the library
>> returns an error when
With Ubuntu's packaging of OpenLDAP 2.4.9 and whatever OpenLDAP is in
Leopard.latest, LDAP_OPT_REFHOPLIMIT is defined in ldap.h but the library
returns an error when trying to set it to 5 (httpd LDAP's default value).
This is apparently a wide-spread issue (
http://article.gmane.org/gmane.network.o
On 11/12/08, Mladen Turk <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Here is a patch that adds two new functions to rmm for obtaining
> the first and next allocated memory blocks.
First line of comment for next fn needs to be tweaked (!first).
> This is useful in searching or maintaining the entire rmm a
On Tue, Sep 9, 2008 at 7:16 AM, <[EMAIL PROTECTED]> wrote:
> Author: minfrin
> Date: Tue Sep 9 04:16:56 2008
> New Revision: 693436
>
> URL: http://svn.apache.org/viewvc?rev=693436&view=rev
> Log:
> Move APU_HAVE_CRYPTO from private apu_config.h to public apu.h.
>
>
> Modified: apr/apr-util/trun
On Sat, Aug 9, 2008 at 10:37 AM, William A. Rowe, Jr.
<[EMAIL PROTECTED]>wrote:
> Available in the usual; http://apr.apache.org/dev/dist/, win32
> with exported .mak files to follow as soon as I have a bit of
> free time, busy weekend here so likely on Sunday eve (when I'll
> look also at committi
On Thu, Aug 14, 2008 at 1:36 AM, William A. Rowe, Jr.
<[EMAIL PROTECTED]>wrote:
> Available in the usual; http://apr.apache.org/dev/dist/ 1-60 minutes from
> now, win32 with exported .mak to follow now that I have some free cycles
> come tomorrow.
>
> +/-1
[+1] Release apr-util-1.3.4
(tested
On Thu, Aug 7, 2008 at 7:47 PM, <[EMAIL PROTECTED]> wrote:
> Author: bojan
> Date: Thu Aug 7 16:47:12 2008
> New Revision: 683756
>
> URL: http://svn.apache.org/viewvc?rev=683756&view=rev
> Log:
> Fix memcache memory leak without use of pre_cleanup in reslist.
>
> Modified:
>apr/apr-util/bran
On Sat, Aug 9, 2008 at 10:37 AM, William A. Rowe, Jr.
<[EMAIL PROTECTED]>wrote:
> Available in the usual; http://apr.apache.org/dev/dist/, win32
> with exported .mak files to follow as soon as I have a bit of
> free time, busy weekend here so likely on Sunday eve (when I'll
> look also at committi
On Thu, Jul 3, 2008 at 1:41 PM, Steve Comstock <[EMAIL PROTECTED]>
wrote:
> We pick up the story of our intrepid adventurer
> trying to port Apache 2.2.9 to z/OS 1.9. ...
>
Let Greg know that you've switched mailing lists, and keep me off the cc ;)
He likely made more progress that he didn't shar
On Fri, Jun 13, 2008 at 9:21 PM, Bojan Smojver <[EMAIL PROTECTED]> wrote:
> Quoting Garrett Rooney <[EMAIL PROTECTED]>:
>
>> Honestly, I loathe tabs as much as the next guy, but I actually
>> dislike the idea of wholesale reformatting because it makes it harder
>> to figure out where a bit of code
On Fri, May 2, 2008 at 2:09 PM, William A. Rowe, Jr.
<[EMAIL PROTECTED]> wrote:
> Chris Taylor seems to have identified a significant bug here, but some
> effort at comparing different OS's man pages is probably worthwhile before
> we accept the patch on it's face;
>
> https://issues.apache.org/bug
On Jan 11, 2008 3:20 PM, Tim Bray <[EMAIL PROTECTED]> wrote:
> I got here because apr_global_mutex_create() was acting weird, so I
> wanted to step into it with the debugger. So I went to apr and did
>
> CFLAGS=-g ./configure
> make
you had already built httpd 2.2.6 at this point, and it was us
On Dec 5, 2007 10:42 AM, David Jones <[EMAIL PROTECTED]> wrote:
> currently in the z/OS specific implementation of dso.c it is returning errno
> directly asis on several functions.
> It should be setting the returned status to expected values consistent with
> the unix and other implementations.
>
On Dec 1, 2007 12:06 PM, Graham Leggett <[EMAIL PROTECTED]> wrote:
> Supporting a certificate label isn't something easily done within the
> current API, and the API cannot be changed until APR v2.
Solvable via apr_foo_ex() in apr 1.3, right?
On Nov 15, 2007 4:26 PM, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote:
> Please provide your input to release.
>[ +1] APR-iconv-1.2.1
diffs from prior release look reasonable (punted on reviewing Windows
build changes just as I normally punt on testing them)
I had to manually define API_U
On Nov 25, 2007 11:32 AM, Learning apr <[EMAIL PROTECTED]> wrote:
> If I hope to include apr_thread_pool.c into the apr-util-1.2.8-win32-src,
> what else files should I take except apr_thread_pool.h and
> apr_thread_pool.c?
no idea; you could try treating apr_thread_pool.c as part of your
applica
On Nov 25, 2007 2:54 AM, Learning apr <[EMAIL PROTECTED]> wrote:
> I downloaded apr-util-1.2.10-win32-src and apr-util-1.2.8-win32-src. But I
> can not find the file apr_thread_pool.h from include\ and apr_thread_pool.c
> from misc\. Which version includes those files?
The thread pool header file
On Nov 19, 2007 3:47 PM, Ruediger Pluem <[EMAIL PROTECTED]> wrote:
>
>
> On 11/19/2007 12:38 AM, Bojan Smojver wrote:
> > On Thu, 2007-11-15 at 16:26 -0500, William A. Rowe, Jr. wrote:
> >> Please provide your input to release.
> >>
> >>[+1] APR-0.9.17
> >>[+1] APR-1.2.12
> >>[-1] APR-u
On Nov 16, 2007 4:32 PM, David Jones <[EMAIL PROTECTED]> wrote:
> A read on /dev/random (and /dev/urandom) returns a 0 instead of a -1 to
> indicate an error on zOS levels 1.6 and prior.
> This puts apr/misc/unix/rand.c and therefore /test/testrandom into an
> infinite loop.
> For zOS 1.7 and above
On Nov 15, 2007 4:26 PM, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote:
> Please provide your input to release.
>
>[ ] APR-0.9.17
>[+1] APR-1.2.12
>[+1] APR-util-1.2.11
>[ ] APR-iconv-1.2.1
Solaris 10/x86_64
Sun Studio 11
apr 1.2.11 vs. apr 1.2.12
tested in 32-bit and 64-bit
On Nov 15, 2007 6:19 PM, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote:
> Lucian Adrian Grijincu wrote:
> > On Nov 15, 2007 11:26 PM, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote:
> >> Please provide your input to release.
> > Ubuntu 7.10 kernel 2.6.22-14, x86
> > testsock: //bin/ba
On Nov 17, 2007 2:53 PM, <[EMAIL PROTECTED]> wrote:
> Author: trawick
> Date: Sat Nov 17 11:53:37 2007
> New Revision: 595995
>
> URL: http://svn.apache.org/viewvc?rev=595995&view=rev
> Log:
> revert r595989 and r595994
>
> These were some of the few correctly ordered comparisons
> in the director
On Nov 17, 2007 2:39 PM, <[EMAIL PROTECTED]> wrote:
> Author: trawick
> Date: Sat Nov 17 11:39:15 2007
> New Revision: 595994
>
> URL: http://svn.apache.org/viewvc?rev=595994&view=rev
> Log:
> fix another reversal of expected and actual
whoops, these two changes were wrong and most other tests in
On Nov 12, 2007 6:56 PM, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote:
>
> Jeff Trawick wrote:
> > Are there still showstoppers for rolling 1.2.12?
>
> Thank you for raising the question, I was spinning around talking to folks
> at AC about any issues they were aware
On Oct 15, 2007 12:38 AM, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote:
> Here's my list of open issues which should probably be determined before
> we roll out 1.2.x, I was hoping we were further along than this on Unix
> in particular;
Are there still showstoppers for rolling 1.2.12?
On Nov 8, 2007 9:05 AM, David Jones <[EMAIL PROTECTED]> wrote:
> on zos an apr_dso_load followed by an apr_dso_unload can cause an 0c4
> due to only 8 bytes being alloc'd for the res_handle instead of the
> necessary 24 bytes
committed to trunk, 1.2.x, and 0.9.x; thanks!
On Nov 7, 2007 1:45 AM, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote:
> William A. Rowe, Jr. wrote:
> >
> > This flaw is significant. Need a fast solution. Thoughts?
>
> My personal thought is that this is not a regression, and we should just
> go ahead, tag 1.2 and resolve it later.
+1; not a
On Nov 3, 2007 5:57 AM, Jeff Trawick <[EMAIL PROTECTED]> wrote:
> On 11/2/07, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote:
> > I'm verifying non-breakage on aix and hp pa-risc (no ia32/64 boxes around),
> > and am backporting DSO detection if I don't f
On 11/3/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Author: trawick
> Date: Sat Nov 3 07:07:50 2007
> New Revision: 591624
>
> URL: http://svn.apache.org/viewvc?rev=591624&view=rev
> Log:
> add missing autoconf/m4 quoting to correct the dso implementation
> choice on older Darwin/OS X as we
On 11/3/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Author: trawick
> Date: Sat Nov 3 06:17:21 2007
> New Revision: 591616
>
> URL: http://svn.apache.org/viewvc?rev=591616&view=rev
> Log:
> Merge r551917 from trunk to fix APR_SSIZE_T_FMT for older Darwin/OS
> X.
>
> original commit msg:
>
>
On 11/2/07, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote:
> William A. Rowe, Jr. wrote:
> >> * maybe some other issue I don't know about
> >
> > Darwin 9. It's a clusterfuck, since we picked up on sendfile, and then
> > told them ever-so-nicely we can't compile sendrecv.c. Joy :)
> >
> > So - b
On 10/15/07, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote:
> Here's my list of open issues which should probably be determined before
> we roll out 1.2.x, I was hoping we were further along than this on Unix
> in particular;
Are you asking if these are regressions since the prior 1.2.x release
(
On 10/30/07, jean-frederic clere <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > Author: trawick
> > Date: Mon Oct 29 13:36:08 2007
> > New Revision: 589846
> >
> > URL: http://svn.apache.org/viewvc?rev=589846&view=rev
> > Log:
> > AIX C compiler won't add to void * in picky mode
>
> It s
On 10/29/07, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > Author: trawick
> > Date: Mon Oct 29 16:36:09 2007
> > New Revision: 589911
> >
> > URL: http://svn.apache.org/viewvc?rev=589911&view=rev
> > Log:
> > when !APR_HAS_RANDOM, use a lame initial "random" number
On 10/29/07, Joe Orton <[EMAIL PROTECTED]> wrote:
> On Wed, Oct 24, 2007 at 10:28:24PM -, William Rowe wrote:
> > Author: wrowe
> > Date: Wed Oct 24 15:28:18 2007
> > New Revision: 588061
> >
> > URL: http://svn.apache.org/viewvc?rev=588061&view=rev
> > Log:
> > Perhaps smaller than long, perha
On 10/23/07, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote:
> Jeff and Martin especially, a question here...
>
> Author: wrowe
> Date: Tue Oct 23 02:52:53 2007
> New Revision: 587434
>
> URL: http://svn.apache.org/viewvc?rev=587434&view=rev
> Log:
> Folks, I'd appreciate if this received extra att
On 10/19/07, David Jones <[EMAIL PROTECTED]> wrote:
>
> revision 554995 introduced apr_atomic_xchgptr, but did not have the os390
> implementation.
>
> This will allow test/testatomic.c at trunk (it tests apr_atomic_xchgptr for
> all platforms) to compile and tests successfully on zOS.
committed;
On 10/16/07, David Jones <[EMAIL PROTECTED]> wrote:
> Create a z/OS implementation of apr_atomic_casptr.
Please double-check/test-compile what I just committed to trunk and
the 1.2.x branch. I tweaked whitespace and comments ever so slightly.
On 10/17/07, David Jones <[EMAIL PROTECTED]> wrote:
> apr/test/testatomic.c trunk doesn't compile due to implicit, as
> apr_atomic_xchgptr is not defined in os390/atomic.c,
> doesn't have anything to do with apr_atomic_casptr.
Thanks for the explanation. I'll commit the apr_atomic_casptr() implem
On 10/16/07, David Jones <[EMAIL PROTECTED]> wrote:
> Create a z/OS implementation of apr_atomic_casptr.
> Passes apr/test/testatomic at trunk, at 554294 level, which does not include
> the following test of apr_atomic_xchgptr (which does not yet have a zOS
> implementation, but is also not in htt
On 10/11/07, Eric Covener <[EMAIL PROTECTED]> wrote:
> On 10/11/07, Jeff Trawick <[EMAIL PROTECTED]> wrote:
> > On 10/11/07, Eric Covener <[EMAIL PROTECTED]> wrote:
> > >
> > > http://people.apache.org/~covener/1.2.x-win32-pipetimeout.diff
> >
&g
On 10/11/07, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > Changes for APR 1.2.12
> >
> > + *) apr_procattr_io_set() on Windows: Set pipe handles non-blocking as
> > + appropriate based on the input parameters. PR 43522.
> > + [Eric Covener ]
>
> would it
On 10/11/07, Eric Covener <[EMAIL PROTECTED]> wrote:
> On 10/10/07, Jeff Trawick <[EMAIL PROTECTED]> wrote:
> > It's in trunk now.
> >
> > Do you have a patch for the 1.2.x branch, which has diverged with the
> > segregation of APR_NO_FILE?
>
On 10/8/07, Eric Covener <[EMAIL PROTECTED]> wrote:
> On 10/6/07, Jeff Trawick <[EMAIL PROTECTED]> wrote:
> > http://issues.apache.org/bugzilla/show_bug.cgi?id=43563
> >
> > This patch looks reasonable to me; any thoughts from the Windows crowd?
> >
On 10/8/07, Eric Covener <[EMAIL PROTECTED]> wrote:
> On 10/6/07, Jeff Trawick <[EMAIL PROTECTED]> wrote:
> > http://issues.apache.org/bugzilla/show_bug.cgi?id=43563
> >
> > This patch looks reasonable to me; any thoughts from the Windows crowd?
> >
On 10/3/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Author: gregames
> Date: Wed Oct 3 12:21:13 2007
> New Revision: 581697
>
> URL: http://svn.apache.org/viewvc?rev=581697&view=rev
> Log:
> make md5 hash files portable between EBCDIC and ASCII platforms.
any objections for putting this in
On 10/8/07, Eric Covener <[EMAIL PROTECTED]> wrote:
> On 10/6/07, Jeff Trawick <[EMAIL PROTECTED]> wrote:
> > http://issues.apache.org/bugzilla/show_bug.cgi?id=43563
> >
> > This patch looks reasonable to me; any thoughts from the Windows crowd?
> >
http://issues.apache.org/bugzilla/show_bug.cgi?id=43563
This patch looks reasonable to me; any thoughts from the Windows crowd?
--
Born in Roswell... married an alien...
On 10/5/07, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote:
> Jeff Trawick wrote:
> > On 10/5/07, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote:
> >> I really wonder, if z/OS is so crippled, if we shouldn't simply
> >> recommend using apr-iconv
On 10/5/07, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote:
> I really wonder, if z/OS is so crippled, if we shouldn't simply
> recommend using apr-iconv?
that's a lot of punishment for not supporting "ISO-8859-1" ;) users
of apr apps can't use the same transformations that they use with
other ap
On 10/3/07, David Jones <[EMAIL PROTECTED]> wrote:
>
> zOS only recognizes the string "ISO8859-1", other platforms now use
> "ISO-8859-1". zOS is using
> native iconv, not apr-iconv, so can not use apr-iconv/ccs/charset.aliases to
> map the strings.
Also, that particular charset alias support has
On 10/3/07, David Jones <[EMAIL PROTECTED]> wrote:
> The MOD_NAME define in testdso.c needs to be changed to support zOS.
committed, thanks, etc.
(alternative subject: Jeff asks dumb FAQ about apr-util version expectations)
AFAICT, apr-util is picking up
./build/rules.mk:APR_DOTTED_VERSION=1.2.11
./build/rules.mk:LINK = $(LIBTOOL) $(LTFLAGS) --mode=link
$(LT_LDFLAGS) $(COMPILE) -version-info 2:11:2 $(ALL_LDFLAGS) -o $@
from apr's
On 9/7/07, Martin Kraemer <[EMAIL PROTECTED]> wrote:
> On Fri, Sep 07, 2007 at 01:12:05AM -0500, William A. Rowe, Jr. wrote:
> > But my first argument remains; if we break the expected
> > behavior, we instantly render all previous generated hashes irreconcilable.
> >
> > So it really seems like an
On 8/19/07, Eric Covener <[EMAIL PROTECTED]> wrote:
> A thread in proc1 will get EDEADLK from fcntl() on the LDAP mutex
>
> A potential for deadlock occurs if a process controlling a
> locked region is put to sleep by attempting to lock another
> process' locked region. If the sys
On 7/25/07, Paul J. Reder <[EMAIL PROTECTED]> wrote:
> Attached is an update that (for the time being) disables APR_HAS_LDAP_SSL
> if APR_HAS_TIVOLI_LDAPSDK is set. Later, when the rest of the SSL code gets
> added to the IBM Tivoli portions of the ldap modules, the disable code can
> be removed.
On 7/26/07, Paul J. Reder <[EMAIL PROTECTED]> wrote:
... So I wanted to get the basics of recognizing
the libs in to the build first, *then* the fun could begin.
+1; haven't had a chance to try your second patch though
On 7/18/07, Paul J. Reder <[EMAIL PROTECTED]> wrote:
Since I don't seem to have karma to commit to APR/APR-util trunks, I'm
attaching a patch that adds the ability to identify the existence of IBM's
Tivoli Directory Server LDAP client SDK. APR will then be able to look
for APR_HAS_TIVOLI_LDAPSDK
On 6/26/07, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote:
Eric Covener wrote:
> On 6/25/07, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote:
>> * At run-time this should probably be determined by parsing first the
>>LC_CTYPE, or LC_ALL in it's absense, or the fallback to the LANG
>>envv
On 6/6/07, Colm MacCarthaigh <[EMAIL PROTECTED]> wrote:
On Thu, Jun 07, 2007 at 12:24:07AM +0300, Lucian Adrian Grijincu wrote:
> 1. kill AI_ADDRCONFIG for APR_UNSPEC
In my opinion, AI_ADDRCONFIG is a useful default flag and prevents
unneccessary delay and lookups.
+1
4. Add APR_NUMERIC_ADDR
On 3/28/07, Wakan <[EMAIL PROTECTED]> wrote:
Hi,
is it possibile to write a server program using APR (of course) and the
apache MPMs module
to manage connections? it is part of APR?
If is it possibile to use it, in which way? Are there some examples?
The MPMs are part of Apache httpd.
The expec
On 3/28/07, Matthew Devine <[EMAIL PROTECTED]> wrote:
I'm trying to compile the apr, apr-util and apr-iconv projects on my Fedora
box, latest versions downloaded today. I am able to successfully configure,
make, make install both apr & apr-util. Then I can sucessfully configure
apr-iconv but wh
On 3/9/07, Stefan Ruppert <[EMAIL PROTECTED]> wrote:
Hi all,
I just wanted to install the APR trunk version on a solaris 2.8 box. But
the compilation failed because of the following error in the file
misc/unix/env.c :
fix committed; that path also needed an include of apr_strings.h
thanks!
On 2/3/07, Nick Kew <[EMAIL PROTECTED]> wrote:
Someone on IRC #apache just reported a stupid error message:
(20014)Error string not specified yet: Error retrieving pid
file /var/run/apache2.pid
20014 is APR_EGENERAL
I suspect that this is from httpd/server/log.c:read_pid() returning
AP
On 1/23/07, David Jones <[EMAIL PROTECTED]> wrote:
Yes, +1
On 1/16/07, Jeff Trawick <[EMAIL PROTECTED]> wrote:
> We shouldn't be defining PTHREAD_ symbols for applications. For APR,
> the application passes in zero or non-zero.
>
> How about changing thread.
On 1/28/07, генерал Пурпоз <[EMAIL PROTECTED]> wrote:
I'm porting the APR|APR-UTIL v1.2.8 to QNX4 - a UNIX clone.
Despite it's name - the APR is not so easily portable. The v1.2.8 is
far less friendly than the v0.9.12 (which is bundled with the SVN
v1.4.3).
All the particular feature
On 1/26/07, Nick Kew <[EMAIL PROTECTED]> wrote:
> >> Apache httpd and bundled libraries do not maintain their own time
> >> zone information. Instead, information is retrieved from the
> >> operating system. Relevant operating system updates must be
> >> applied and the web server restarted to
On 1/25/07, Jim Jagielski <[EMAIL PROTECTED]> wrote:
We did it with Y2K so +1...
Is there anything to say other than (for httpd, for example):
Apache httpd and bundled libraries do not maintain their own time zone
information. Instead, information is retrieved from the operating
system. Rele
In this code, a Unix-style signum|exitcode|bits is passed to the
maintenance function from within apr_proc_other_child_refresh().
waitret = waitpid(ocr->proc->pid, &status, WNOHANG);
if (waitret == ocr->proc->pid) {
ocr->proc = NULL;
(*ocr->maintenance) (APR_OC_REASON_DEATH, o
Index: include/apr_thread_proc.h
===
--- include/apr_thread_proc.h (revision 499409)
+++ include/apr_thread_proc.h (working copy)
@@ -675,6 +675,8 @@
* and should be replaced in the APR 1.0 API with a bitflag of which
* proc->in
701 - 800 of 1860 matches
Mail list logo
