On 10/9/2010 4:49 AM, wr...@apache.org wrote:
Author: wrowe
Date: Sat Oct 9 09:49:24 2010
New Revision: 1006125
URL: http://svn.apache.org/viewvc?rev=1006125view=rev
Log:
Catch up to 1.95.7 changes
I believe all is well from my test builds, so I think we are good to TR :)
Thanks for the
+/-1
[+1] Release apr 0.9.19 as GA
[+1] Release apr-util 0.9.18 as GA
We'll have cycles to let this go the full 72 hours, I expect to leave the
httpd votes open that long. Although there will be a .19/.18 based tag
of httpd today, I intend to withdraw and reroll 2.0 with fresh 0.9 tags
On 10/8/2010 1:53 PM, rj...@apache.org wrote:
Author: rjung
Date: Fri Oct 8 18:53:30 2010
New Revision: 1005955
URL: http://svn.apache.org/viewvc?rev=1005955view=rev
Log:
Fix expat version in Windows build file.
Modified:
apr/apr-util/branches/1.5.x/xml/expat/lib/expat.dsp
Two
Two major consumers of apr are the httpd and svn projects. Many/most
of our subscribers are their subscribers. We know how httpd list
processing is configured... how is the svn dev@ list configured?
On 10/7/2010 5:29 AM, Graham Leggett wrote:
We will still need to make releases on apr-util in the v1.x series, and we
may need to
bump v1.3 to v1.4, etc. For this, we need a properly functional trunk,
otherwise those
following the standard svn conventions face problems.
Yes, and no.
On 10/5/2010 2:40 AM, Joe Orton wrote:
Any objection to renaming the apr-util 1.5.x branch to trunk? It is
the trunk for that tree now.
Counting up the opinions posted on the list...
[ ] Rename 1.5.x to trunk
jorton, rjung, minfrin, trawick, jim
[ ] apr/ is 'apr-util/ trunk', stub
On 10/5/2010 2:40 AM, Joe Orton wrote:
Any objection to renaming the apr-util 1.5.x branch to trunk? It is
the trunk for that tree now.
-.5, because for the confusion it saves the dozen of us, many more dozens
will be confused by checking out apr and apr-util trunks as they have in
the past,
On 10/5/2010 10:24 AM, Nick Kew wrote:
But it does perhaps highlight a need to be clearer about where we are.
Might another idea be to have an apr-util/trunk/ containing nothing
but a README explaining the situation?
+1
On 10/5/2010 2:40 AM, Joe Orton wrote:
Any objection to renaming the apr-util 1.5.x branch to trunk? It is
the trunk for that tree now.
Let us know if Nick's suggested change satisfies, I've drafted a trunk
which explains things...
Bill
On 10/5/2010 5:46 PM, Guenter Knauf wrote:
Hi all,
with almost all other lists we have set the reply-to address to the list, so
if you just
hit reply then post goes to list as it should be - why the heck is that not
true for the
d...@apr list??
sure, I only need to take care of it, and
On 10/1/2010 10:47 PM, Guenter Knauf wrote:
would be nice if we could get an APR 1.4.x release too for next httpd
releases.
Adapting to this set of changes for apu-0.9.x is far more important than dealing
with apr. A release would be nice, but is certainly not urgent.
On 10/2/2010 4:10 PM, Jeff Trawick wrote:
On Fri, Oct 1, 2010 at 4:41 PM, William A. Rowe Jr. wr...@rowe-clan.net
wrote:
On 10/1/2010 7:10 AM, Jeff Trawick wrote:
Bill, are you able to prepare the apr-util 1.3.10 source packages for
Windows?
(I don't think those are the .zip files created
On 10/1/2010 8:22 AM, Jeff Trawick wrote:
Tarballs are at http://apr.apache.org/dev/dist/. Windows packages are
not yet available.
Due to the inclusion of a fix for a potential DOS that could affect
some library consumers, I hope to get enough feedback within 24 hours
to release.
+/-1
On 10/1/2010 7:10 AM, Jeff Trawick wrote:
Bill, are you able to prepare the apr-util 1.3.10 source packages for Windows?
(I don't think those are the .zip files created by the roll script)
Actually, now they are. The svn export --native-eol crlf works on any platform,
zip works on any
On 9/30/2010 11:05 AM, Joe Orton wrote:
On Tue, Sep 28, 2010 at 07:05:09AM -0400, Jeff Trawick wrote:
any concerns about the timing?
any additional fixes people would like to see in that release?
1.3.x branch looks good to me; I've had a trawl through bugzilla and
can't find any
On 9/30/2010 6:42 PM, Jeff Trawick wrote:
Yep, looks like NetWare fixes for expat are in 1.5.x but not 1.3.x. I
will probably wait for Günter to say something on the status there.
That seems sensible, but the trees should be the same, probably applying
his patches to 1.3 would be sufficient
On 9/30/2010 9:41 PM, Guenter Knauf wrote:
Am 01.10.2010 04:38, schrieb William A. Rowe Jr.:
Hmmm?
apr-util-1.4 isn't released. We are shipping this from
www.apache.org/dist/apr/ ???
I know, but if I now modify 1.4 apr then I can no longer build 1.4 apu with
any apr ...
Joe, cant you
On 9/29/2010 3:11 AM, Joe Orton wrote:
Bumping to a later 1.95.x+patches seems feasible actually, yeah, nice
idea. I'm going to try to get this done today; I'll probably break the
Win32 build (at least!) so help might be required!
And I'll unbreak Win32 this evening - thanks much, here's
On 9/28/2010 10:22 AM, Joe Orton wrote:
On Tue, Sep 28, 2010 at 07:05:09AM -0400, Jeff Trawick wrote:
any concerns about the timing?
any additional fixes people would like to see in that release?
I have been trying to backport security fixes for CVE-2009-3720 and
CVE-2009-3560 to the
On 9/8/2010 4:56 AM, Oscar Pernas wrote:
Im using apr to throw new threads for making callbacks. My problem is that
when I have
made exactly 632 calls to the function throwOnMessage, the thread onMessage
is not throwed
by it anymore, the thread is not created (I've put traces into the
On 9/8/2010 11:39 AM, Oscar Pernas wrote:
If i set the thread as detached, that I think is that I need (same that the
old code that
I sent)
//detaching the thread
apr_threadattr_detach_set(thd_attr,1);
What I have to do to reap and free all resources when this thread dies?
Likely, you
On 9/8/2010 12:03 PM, Oscar Pernas wrote:
Ok, but, If the thread is detached means that I dont know (and i dont want to
know) when
the thread dies, when I am going to delete its pool if I dont know when is
going to dead?
the only one that knows when is going to finish is itself, but if i
On 9/1/2010 1:11 PM, Guenter Knauf wrote:
so the public API changes depending on APR_HAVE_STRUCT_RLIMIT which I think
is wrong; we
need to remove the ifdef and all platforms which have
APR_HAVE_STRUCT_RLIMIT=0 need to
provide a stub like in beos/proc.c:
APR_DECLARE(apr_status_t)
On 8/20/2010 10:01 PM, Bert Huijben wrote:
-Original Message-
From: Erik Huelsmann [mailto:ehu...@gmail.com]
Sent: vrijdag 20 augustus 2010 13:20
To: William A. Rowe Jr.
Cc: dev@apr.apache.org
Subject: Re: Thread handle leak in APR
On Fri, Aug 20, 2010 at 8:30 PM, William A. Rowe
On 8/22/2010 5:55 PM, Oscar Pernas wrote:
Hi all, I'm new with apr, and I am looking for the way to implements
semaphores with apr, is currently supported by the library? Anyone knows
a good book to read about all things that apr has?
Nick's Apache Modules book covers not only the httpd API
On 8/20/2010 1:08 PM, Guenter Knauf wrote:
Hi Prathima,
Am 20.08.2010 09:04, schrieb Prathima Dandapani -X (pdandapa - HCL at
Cisco):
Steps used to compile Apache is as follows.
Run Setenv.cmd from the Windows-Server-2003-R2-Platform-SDK installed
directory
Run vcvars32.bat from VC++
On 8/3/2010 1:35 AM, Guenter Knauf wrote:
fine so far, but also bad since shouldnt we at least make sure that APR
itself builds without apu.h? There are still a bunch of headers which
want to include apu.h - is it ok that I change them all to apr.h, or do
I have to mimic this dummy apu.h
On 7/26/2010 5:30 AM, Rainer Jung wrote:
I'm a bit undecided whether to port some changes between APR and
APR-UTIL branches:
- r780882 (wrowe): fix vpath building for xml/expat (removing
configure target in Makefile.in)
The change is in the 1.3.x branch, but neither in any older nor newer
On 7/26/2010 10:10 AM, Rainer Jung wrote:
On 26.07.2010 15:47, William A. Rowe Jr. wrote:
On 7/26/2010 5:30 AM, Rainer Jung wrote:
I'm a bit undecided whether to port some changes between APR and
APR-UTIL branches:
- r780882 (wrowe): fix vpath building for xml/expat (removing
configure
On 7/5/2010 4:30 PM, Greg Stein wrote:
On Mon, Jul 5, 2010 at 16:33, William A. Rowe Jr. wr...@rowe-clan.net wrote:
On 7/5/2010 2:49 PM, Greg Stein wrote:
Applied to trunk in r960671.
I'm unclear on backporting/releases right now, so that hasn't been
done. We should do that before new branch
On 7/5/2010 2:49 PM, Greg Stein wrote:
Applied to trunk in r960671.
I'm unclear on backporting/releases right now, so that hasn't been
done. We should do that before new branch releases.
I'm 99.5% sure the mutex locking existing before I had added the XTHREAD
flag. The .5% leaves me
This patch isn't valid.
Other applications will play games with comparisons. Comparisons require
users to call TRUEPATH. What seems to be needed here is for apr_pathname_cwd
to be returning a true path.
All other comparisons are intrinsically invalid, and this has the potential
to introduce
On 7/5/2010 8:04 AM, Sam Carleton wrote:
Thank you very much for the enlightenment. Considering my use of Apache
is in a custom app where all my code is in either an Apache Module or
Axis2/C service, I tend to forget about the bigger picture like those
using PHP, Perl and such. Again, I do
On 7/5/2010 3:46 PM, Bert Huijben wrote:
Too bad, that without this patch you can't call the truepath support on a
merged path and that Windows has 26 (or 27) current directories while APR
assumes that there is only one.
Hold up... are you trying to merge non-normalized paths?
I need to
On 7/4/2010 4:52 PM, Sam Carleton wrote:
On Sun, Jul 4, 2010 at 1:27 AM, William A. Rowe Jr. wr...@rowe-clan.net
wrote:
On 7/3/2010 8:53 AM, Sam Carleton wrote:
Why? why why why? I simply don't get it
Sam, please don't waste your energy venting at APR or any other open
source effort
On 7/2/2010 7:53 PM, Sam Carleton wrote:
Do I need to compile the whole apr library, per the instructions on the
web site or should I be able to simply convert the apr_dbd_sqlite3.dsp
project to a Visual Studio 2008 project and compile it?
Twofold question. First, db providers should be
On 7/3/2010 8:53 AM, Sam Carleton wrote:
Why? why why why? I simply don't get it
Sam, please don't waste your energy venting at APR or any other open
source effort, take your issues to MS just as we've all tried.
We don't get it either, but it is what it is.
An OT reply, since you are asking an httpd question on the -wrong-
list...
On 7/3/2010 8:53 AM, Sam Carleton wrote:
So why is it still using
a compiler that is 10-years-old!
Apache httpd seeks to keep binary compatibility, and that rather means
keeping the same low level msvcr dependencies, as
On 5/21/2010 7:39 AM, Jeff Trawick wrote:
On Thu, May 20, 2010 at 4:22 PM, William A. Rowe Jr.
wr...@rowe-clan.net wrote:
On 5/20/2010 10:11 AM, Jeff Trawick wrote:
lame question months late:
What is the compilation environment in which this ANSI_FS code is
compiled -- i.e., WINNT
On 5/21/2010 10:25 AM, Jeff Trawick wrote:
Nope, because the Release9x flavor now would allow both NT and ANSI to
coexist. If the manually toggle for only ANSI, that is just the sort of
hack you describe.
apr_arch_misc.h says
#if defined(_WIN32_WCE) || defined(WINNT)
#define
On 5/20/2010 10:11 AM, Jeff Trawick wrote:
lame question months late:
What is the compilation environment in which this ANSI_FS code is
compiled -- i.e., WINNT is not defined?
Correct; windows 9x compatible versions such as APR 1.3.x and prior.
I'm tempted to gut this code, but understood
On 5/2/2010 11:59 AM, Martin Hauner wrote:
another build issue, this time on mingw. somehow configure doesn't
properly replace libtools path and trying to find it at /libtool:
Does the attached patch remedy this? If so, one of us will backport,
it was apparently committed only to the 1.4
On 4/26/2010 2:19 PM, Jeff Trawick wrote:
So I don't think there's any hidden reason why a mutex should always
be obtained on Windows. I too wouldn't be surprised if the fix breaks
some app code somewhere.
Keep in mind fd-based operations are atomic on Unix, but not so on windows.
Going over the blockers to 2.0, here seem to be our choices since nobody appears
to have the time or interest in ensuring apr_ldap becomes fully modular;
[ ] Abandon apr_ldap_* API's to httpd 2.3 ldap, including required autoconf
[ ] Keep apr_ldap_* within apr project, as an independent
On 4/25/2010 10:56 AM, William A. Rowe Jr. wrote:
Going over the blockers to 2.0, here seem to be our choices since nobody
appears
to have the time or interest in ensuring apr_ldap becomes fully modular;
[X] Abandon apr_ldap_* API's to httpd 2.3 ldap, including required autoconf
On 4/23/2010 7:58 AM, Jim Jagielski wrote:
For those who are working on httpd trunk and Linux, what
are you using?
Expat 2.0.1 or os vendor expat
On 4/12/2010 3:48 PM, Роман Донченко wrote:
F:\Tempsvn ci testwc -m В лесу родилась ёлочка.
Adding testwc\test.txt
Transmitting file data .
Committed revision 1.
FWIW, when an app is linked to aprapp.lib, or apr_initialize() is invoked,
env tables and command line args are handled
On 4/13/2010 5:57 AM, Роман Донченко wrote:
William A. Rowe Jr. wr...@rowe-clan.net писал в своём письме Tue, 13
Apr 2010 15:10:30 +0500:
On 4/12/2010 3:48 PM, Роман Донченко wrote:
F:\Tempsvn ci testwc -m В лесу родилась ёлочка.
Adding testwc\test.txt
Transmitting file data
On 4/13/2010 9:29 AM, Роман Донченко wrote:
getpwuid_t returns the raw byte representation of the username, which is
in the locale encoding (well, Unix being byte-oriented, it can be an
arbitrary binary string, but presumably the sysadmin uses the same
encoding everywhere).
The difference
On 4/13/2010 12:00 PM, Branko Čibej wrote:
Well no, but ... as a matter of fact, most of the locale stuff in
Subversion on Windows, starting with command-line parsing (we don't use
apr_app_initialize) all the way to printing to the console (we don't use
the wide-character printf variants) is
On 4/13/2010 11:27 AM, Роман Донченко wrote:
Frustratingly, even wprintf will not output Unicode characters to a
console, it will transform them into chars according to the current C
locale (there are so many current locales, it's nauseating). To *really*
print wide characters to the
On 4/9/2010 9:21 PM, Hyrum K. Wright wrote:
Speaking as one of the Subversion committers in question, I tend to
agree with this sentiment. It really doesn't make much sense to
grandfather an entire group of people into the project: just because
somebody knows and understands the Subversion
On 4/7/2010 8:56 PM, Bojan Smojver wrote:
On Thu, 2010-04-08 at 00:37 +0100, Nick Kew wrote:
Who do you have in mind, or are you suggesting a blanket commit?
For instance, Hyrum K. Wright submitted a patch for apr_hash and asked
about it a few times. My understanding is that he's a
By rights, we should be moving apr_support.h out of include/, that was a first
mistake. I have the same understanding as you, Mladen, but the authors of the
httpd mod_reqtimeout seem to be reaching their fingers into this header.
On 4/7/2010 6:29 AM, Mladen Turk wrote:
Hi,
Will you do
On 4/7/2010 12:14 PM, Jeff Trawick wrote:
On Wed, Apr 7, 2010 at 12:59 PM, Ruediger Pluem rpl...@apache.org wrote:
On 07.04.2010 13:31, William A. Rowe Jr. wrote:
By rights, we should be moving apr_support.h out of include/, that was a
first
mistake. I have the same understanding as you
On 4/2/2010 7:35 PM, Jeff Trawick wrote:
On Fri, Apr 2, 2010 at 4:50 PM, Stuart Smith stu24m...@yahoo.com wrote:
Hello,
I noticed that the win32 archive download link available on the download
page:
http://apr.apache.org/download.cgi
mentions that archives will be available shortly and
On 3/24/2010 3:49 PM, sidinsd wrote:
sidinsd wrote:
It is almost as if the linking in of the apr_initialize() code somehow
screws everything up. Has anybody heard of such a problem?
Well, I figured this one out myself. Apparently, the libapr1-dll file must
be in the same directory as the
On 3/13/2010 9:54 AM, Graham Leggett wrote:
To zoom out a bit to put this into context, right now APR has no support
for non blocking behaviour at all, and this is the problem I would like
to fix. Using apr_os_file_put(), while functional, isn't portable, and
as a result a user of the API is
On 3/13/2010 5:44 PM, Bojan Smojver wrote:
On Fri, 2010-03-12 at 13:30 +, Joe Orton wrote:
I'd expect to see some description of exactly what the new APR_FOPEN_*
flag changes w.r.t. method calls; does it affect just read/write, what
about flush, sync, etc? Can I presume POSIX semantics
On 3/12/2010 5:21 AM, Greg Stein wrote:
It is *totally* fine to add a 'const' to a parameter that was not
there before. That does not change the ABI whatsoever, and it will not
break the API for callers. It merely gives them more information at
compile time.
int oldfunc (const char
On 3/12/2010 4:48 AM, Bert Huijben wrote:
Why do we even have this block?
Why, indeed?
CreateHardLinkA is only implemented in Windows 2000 and later, which implies
unicode support.
(Why support an ansi version of an API that is only implemented on unicode
capable systems?)
Because
On 3/12/2010 10:50 AM, Hyrum K. Wright wrote:
On Mar 12, 2010, at 10:39 AM, William A. Rowe Jr. wrote:
On 3/12/2010 5:21 AM, Greg Stein wrote:
It is *totally* fine to add a 'const' to a parameter that was not
there before. That does not change the ABI whatsoever, and it will not
break
On 3/12/2010 1:39 PM, Greg Stein wrote:
Of course not. I have NO IDEA what the hell you're talking about. Why
would you even attempt to assign an int function return to a char
* variable? And that function is declared to take a parameter which
you didn't give it. It's just nonsense code.
[obviously, had not had enough coffee]
On 3/12/2010 1:39 PM, Greg Stein wrote:
We're talking about a function prototype that current says:
APR_DECLARE(void) apr_hash_this(apr_hash_index_t *hi, const void **key,
apr_ssize_t *klen, void **val);
and add a
On 3/9/2010 5:52 AM, Graham Leggett wrote:
On 09 Mar 2010, at 1:46 PM, Jeff Trawick wrote:
Hmmm - in that case it may make sense to drop the ifdef entirely,
and if a
unix platform is found to not support O_BLOCK, we can then make a
call then
as what to do. The ifdef could in theory be
On 3/9/2010 11:48 AM, Jeff Trawick wrote:
On Tue, Mar 9, 2010 at 11:19 AM, Hyrum K. Wright
hyrum_wri...@mail.utexas.edu wrote:
In using the apr_hash datastructure in Subversion, we've found that we
often only want the key or value from a hash. Furthermore, casting
the various return
On 3/9/2010 3:37 PM, Hyrum K. Wright wrote:
I'm also planning a followup which const-ifies the apr_hash_index_t params to
these functions, as well as apr_hash_this(). Thoughts?
Note const'ness will only be alterable with apr 2.0 forwards.
I'm eyeballs to alligators here, so I won't have a
On 3/8/2010 2:17 PM, Graf Laszlo wrote:
Can somebody help me?
Not exactly here. This is a development list for the apr library, and your
questions go pretty far afield.
If you are asking about -module authoring-, there is a list just for that.
See
On 3/7/2010 4:54 PM, Jeff Trawick wrote:
On Sun, Mar 7, 2010 at 10:24 AM, minf...@apache.org wrote:
Author: minfrin
Date: Sun Mar 7 15:24:36 2010
New Revision: 920017
URL: http://svn.apache.org/viewvc?rev=920017view=rev
Log:
Backport r920016:
Enable platform specific support for the
On 3/4/2010 5:34 AM, Graf Laszlo wrote:
Is there a way to scan the shared library for its types and functions
without knowing what is in there?
Yes. Your questions suggest that you should do a web search for a C development
or unix development FAQ (and specifically the unix platform you are
On 3/1/2010 2:14 PM, Graham Leggett wrote:
On 01 Mar 2010, at 9:45 PM, minf...@apache.org wrote:
URL: http://svn.apache.org/viewvc?rev=917675view=rev
Log:
Use the APR_FOPEN_* constants instead of the deprecated APR_* constants
within the file_io code.
Question: do we remove APR_READ and
On 3/1/2010 6:07 PM, minf...@apache.org wrote:
Author: minfrin
Date: Tue Mar 2 00:06:59 2010
New Revision: 917814
URL: http://svn.apache.org/viewvc?rev=917814view=rev
Log:
Backport r917675: Use the APR_FOPEN_* constants instead of the
deprecated APR_* constants within the file_io code.
On 3/1/2010 6:25 PM, Graham Leggett wrote:
On 02 Mar 2010, at 2:17 AM, minf...@apache.org wrote:
URL: http://svn.apache.org/viewvc?rev=917819view=rev
Log:
Enable platform specific support for the opening of a file or
pipe in non blocking module through the APR_FOPEN_NONBLOCK flag.
On 2/27/2010 8:19 AM, Graham Leggett wrote:
Hi all,
I am trying to open a fifo on disk with the O_NONBLOCK flag set, and I
notice that apr's apr_file_open() cannot do this.
As a result, if nobody else is already reading from the fifo,
apr_file_open blocks, and this is the behaviour I want
On 2/19/2010 5:48 AM, Jeff Trawick wrote:
On Mon, Feb 15, 2010 at 3:24 PM, Jeff Trawick traw...@gmail.com wrote:
nice-to-haves:
Win32 source flavor of release tarballs, for both 1.4.2 and 1.3.12
I guess I'm waiting for Bill to say go ahead without them or I'm
trying to get caught up.
All
On 2/19/2010 11:09 AM, Jeff Trawick wrote:
That's a good solution.
Just an observation, we should probably duplicate for a day while mirrors
pick up the 1.x and then remove the old 1.3/1.4 files.
And did we want to mention the 'improvements' offered in 1.4 for developers
in the final 1.4.2
On 2/16/2010 8:42 AM, raj reddy wrote:
Hi All,
This is in reference to Windows:
I am building a module that has a requirement to support IPV6. Kindly
let me know, if the present libapr that comes with apache install
supports IPV6 by default? If not where can i download it?
Not by
On 2/11/2010 6:10 AM, Jeff Trawick wrote:
On Wed, Feb 10, 2010 at 6:39 PM, Bojan Smojver bo...@rexursive.com wrote:
On Sat, 2010-02-06 at 20:47 -0500, Jeff Trawick wrote:
[+1] Release apr-1.3.12
That's the third binding vote. Barring any other odd reports in the
next 6 or so hours, I'll
On 2/6/2010 7:47 PM, Jeff Trawick wrote:
See http://apr.apache.org/dev/dist/ for the candidate distribution
files (no Windows source yet -- Bill, is it correct that the one
generated by release.sh is not used?).
Correct, it's used verbatim, with the addition of .mak files which had
changed
On 2/4/2010 5:58 PM, Nick Kew wrote:
On 4 Feb 2010, at 21:03, Tollef Fog Heen wrote:
]] Nick Kew
| I don't know if it comes under any of the FSF's exceptions for the
| core toolchain (as in, compiling with gcc and linking glibc doesn't
| bring you under GPL).
It's a shell script.
On 2/5/2010 10:25 AM, Jeff Trawick wrote:
I noticed this when reviewing the 1.3.10 tarballs (still on my
machine). Should I retag 1.3.10 to avoid potential user confusion?
or just skip 1.3.10 and call it 1.3.11; I don't care either way
(If I hadn't sat back so long watching Bill crank
On 2/5/2010 1:40 PM, Jeff Trawick wrote:
On Fri, Feb 5, 2010 at 1:37 PM, William A. Rowe Jr. wr...@rowe-clan.net
wrote:
On 2/5/2010 10:25 AM, Jeff Trawick wrote:
I noticed this when reviewing the 1.3.10 tarballs (still on my
machine). Should I retag 1.3.10 to avoid potential user confusion
On 2/4/2010 5:58 PM, Nick Kew wrote:
On 4 Feb 2010, at 21:03, Tollef Fog Heen wrote:
]] Nick Kew
| I don't know if it comes under any of the FSF's exceptions for the
| core toolchain (as in, compiling with gcc and linking glibc doesn't
| bring you under GPL).
It's a shell script.
On 2/3/2010 1:50 PM, rpl...@apache.org wrote:
+APR_DECLARE(apr_status_t) apr_file_rotating_check_manual(apr_file_t
*thefile, apr_time_t time);
_check is the verb (method) - or _manual_check if you want to be wordy.
Can we fix this this to conform to style?
On 1/21/2010 10:44 AM, William A. Rowe Jr. wrote:
Hi folks,
There is a new candidate at the usual location,
http://apr.apache.org/dev/dist/ for an apr 1.4.2 release. The only
major delta from what the overwhelmingly positive 1.4.1 candidate is
reverting the breaking API change in 1.3.9
On 1/21/2010 4:47 AM, Graham Leggett wrote:
On 20 Jan 2010, at 8:32 AM, William A. Rowe Jr. wrote:
/* Private functions */
-void apr_pollset_drain_wakeup_pipe(apr_pollset_t *pollset);
+apr_status_t create_wakeup_pipe(apr_pool_t *pool, apr_pollfd_t *pfd,
apr_file_t **wakeup_pipe
On 1/21/2010 10:15 AM, Graham Leggett wrote:
On 18 Jan 2010, at 11:23 PM, William A. Rowe Jr. wrote:
Graham, what's your preference; drop the api from 1.4.1 for
extensibility in
1.5.0, or go with the 'static' provider model that was previously in
1.4-dev,
until it's similarly refactored
Hi folks,
There is a new candidate at the usual location,
http://apr.apache.org/dev/dist/ for an apr 1.4.2 release. The only
major delta from what the overwhelmingly positive 1.4.1 candidate is
reverting the breaking API change in 1.3.9 that svn reported, which
scuttled the earlier attempt.
On 1/19/2010 5:19 AM, Bert Huijben wrote:
Ping,
This issue (and mailinglist thread) is now more than two months old. The
latest patch adds a testcase showing the issue in the APR testsuite. (There
is also an XFail test in the subversion testsuite for this issue)
The patch was
On 1/19/2010 5:19 AM, Bert Huijben wrote:
The patch was written on the 1.4.x branch but I svn switch'ed it to trunk for
easy application.
I would suggest one bit of alternate code that is a bit more condensed, any
concern?;
+static int same_drive(const char *path1, const char *path2)
+{
+
On 1/16/2010 2:53 AM, minf...@apache.org wrote:
/* Private functions */
-void apr_pollset_drain_wakeup_pipe(apr_pollset_t *pollset);
+apr_status_t create_wakeup_pipe(apr_pool_t *pool, apr_pollfd_t *pfd,
apr_file_t **wakeup_pipe);
+apr_status_t close_wakeup_pipe(apr_file_t **wakeup_pipe);
We have really trimmed down the footprint of apr as a loadable library,
so the very last not-dynamic component is expat.
It's small and lightweight, and I just wanted to confirm that the devs
are all comfortable that xml is pervasive enough to merit binding expat
with libdl every time a user
by rethinking
the underlying ctx's so the crypto cxt references the driver, etc, but I'm
not to keen on letting it disrupt the release of other new 1.4 features
by yesterday.
On 1/17/2010 4:52 AM, William A. Rowe Jr. wrote:
On 12/15/2009 4:57 AM, Graham Leggett wrote:
William A. Rowe Jr. wrote
On 1/17/2010 4:57 AM, William A. Rowe Jr. wrote:
On 1/7/2010 9:12 AM, Bert Huijben wrote:
Looking at apr's 1.3.x branch:
In r817810 a change to the hash table implementation was introduced,
which moves the data of a hash table from the main pool to a subpool (as
seen from the pool passed
On 1/7/2010 6:06 PM, Bojan Smojver wrote:
On Thu, 2010-01-07 at 16:26 +0100, Ruediger Pluem wrote:
This sounds like a valid point.
+1
I would propose to revert r817810 / r817809 (for 1.3.x / 1.4.x) and
only keep r817806 (trunk). Graham?
IMHO we can backport this again later if the
On 12/15/2009 4:57 AM, Graham Leggett wrote:
William A. Rowe Jr. wrote:
As I mentioned, the actual contents of the structure are flexible IMHO.
As a user, folks aren't expected to know the difference, but as a developer,
something clearly labeled -alpha should be expected to be changing
On 1/7/2010 9:12 AM, Bert Huijben wrote:
Looking at apr's 1.3.x branch:
In r817810 a change to the hash table implementation was introduced,
which moves the data of a hash table from the main pool to a subpool (as
seen from the pool passed to apr_hash_make). This makes the contents of
the
On 1/16/2010 3:11 AM, Graham Leggett wrote:
On 15 Dec 2009, at 8:52 PM, William A. Rowe Jr. wrote:
My gut says hold off releasing apr-1.4.1 for just a bit to see if this
feature would be the solution.
I've come up with r899910, and it seems to work. Can you give it the
once over for me
Guenter Knauf wrote:
So the older getpassword isn't threadsafe, getpass_r is present, and as I
I really wonder from what you take this knowledge?
From commit comments I had inferred it..
Oh, so this then makes it valid to break it??
I didn't say that. Refer to the prior commit message when
In light of current events, here's a policy statement I'd like to propose
for consideration (just a discussion item at this point);
The APR project strongly discourages any release of the APR software
with modifications of the API. This includes shipping .0-dev pre
release source code
701 - 800 of 3066 matches
Mail list logo
