On Thu, 2009-06-18 at 00:51 +0200, Gavin Sherry wrote:
497 proc_mutex_unlock_it.l_pid = 0; /* pid not
actually interesting */
What's in proc_mutex_unlock_it when this happens? What's its size?
Can you tell us what your fcntl.h holds for struct flock?
PS. I do not have access
On Thu, 2009-06-18 at 02:18 +0200, Gavin Sherry wrote:
$2 = 24
ptype proc_mutex_unlock_it
type = struct flock {
short l_type;
short l_whence;
off_t l_start;
off_t l_len;
unsigned int l_sysid;
pid_t l_pid;
int l_vfs;
}
I'm guessing here: short 2 bytes, off_t
On Thu, 2009-06-18 at 02:45 +0200, Gavin Sherry wrote:
No, it comes to 24 bytes. short = 2 + 2, off_t = 4 + 4, + 4 + 4 + 4 =
24. off_t = 4 for this build because I've forced it to 32 bit (gcc
-m32) based on some other requirements.
OK. Hmm, interesting. So, it segfaults on assigning l_pid.
On Thu, 2009-06-18 at 03:12 +0200, Gavin Sherry wrote:
It's a little late my time to decipher this.
I'll bet on of of the load/store thingies. Try with si/ni to determine
where exactly it dies. Yeah, I know - not much help :-(
--
Bojan
On Fri, 2009-06-12 at 14:03 +1000, Bojan Smojver wrote:
On Fri, 2009-06-12 at 13:26 +1000, Bojan Smojver wrote:
Before we even contemplate having this in 1.3.x
And if you want to play with it in 1.3.x, here is the patch. It should
save you some conflict resolution.
Just wanted to gather
On Tue, 2009-06-16 at 00:41 +0200, Jack Andrews wrote:
feedback welcome - it can probably be improved
Did you really want to use functions for casting?
--
Bojan
On Sun, 2009-06-14 at 07:40 +, bo...@apache.org wrote:
Modified: apr/apr-util/trunk/misc/apr_queue.c
Sorry guys :-( Old habits die hard.
--
Bojan
On Sat, 2009-06-13 at 22:40 -0700, Neil Conway wrote:
The previous doc text suggested that apr_queue_trypush() in apr-util
blocks if the queue is full, which is happily not what actually
happens.
Done. Thanks for your patch!
--
Bojan
Not sure if anyone finds this useful. Let me know.
PS. Windows bit is a complete guess. OS2 bit I had no idea about, so
just stubs.
--
Bojan
Index: include/apr_file_io.h
===
--- include/apr_file_io.h (revision 783964)
+++
On Thu, 2009-06-11 at 18:10 +0200, Stefan Fritsch wrote:
I finally got around to test the stderr reopening behaviour with the
various FD_CLOEXEC bits in trunk. I noticed that this still does not
work, i.e. when mod_php exec()s another program, stderr gets closed.
The problem is in
On Thu, 2009-06-11 at 18:10 +0200, Stefan Fritsch wrote:
With the patch, I think the FD_CLOEXEC bits can be backported to 1.4.
The relevant commits are
747990
748361
748371
748565
748988
749810
And now:
783958
--
Bojan
On Fri, 2009-06-12 at 03:21 +, bo...@apache.org wrote:
Backport r747990, r748361, r748371, r748565, r748988, r749810, r783958
from the trunk.
Set CLOEXEC flags where appropriate.
I know I just painted a really big target on my back. That's cool folks.
After all, this is 1.4.x, so I maybe
On Fri, 2009-06-12 at 13:26 +1000, Bojan Smojver wrote:
Before we even contemplate having this in 1.3.x
And if you want to play with it in 1.3.x, here is the patch. It should
save you some conflict resolution.
--
Bojan
Property changes
On Tue, 2009-06-09 at 14:33 -0500, William A. Rowe, Jr. wrote:
Shouldn't this be == above like in the case for the output file
descriptors?
Sure looks that way.
Worthy of a quick release (if it's the cause of fd leaks)?
If we combine that with APU's --libs thing and the (uncommitted) DSO
On Wed, 2009-06-10 at 20:54 +0200, Ruediger Pluem wrote:
On 06/10/2009 05:56 AM, Bojan Smojver wrote:
On Wed, 2009-06-10 at 13:51 +1000, Bojan Smojver wrote:
Actually, that LDAP thing is not required.
So, here are the two patches. One for trunk (for now, until this gets
fixed properly
On Wed, 2009-06-10 at 18:58 +0200, Arfrever Frehtes Taifersar Arahesis
wrote:
As a Subversion developer, I would not like to see more useless
libraries in the output of `apu-1-config --libs`. apu-1-config doesn't
ignore unrecognized options, so we couldn't unconditionally pass
--avoid-dbm
On Thu, 2009-06-11 at 07:44 +1000, Bojan Smojver wrote:
We do this in libapreq2:
Actually, thanks for reminding me to do the new option for libapreq2:
http://svn.apache.org/viewvc?view=revrevision=783546
--
Bojan
On Wed, 2009-06-10 at 23:54 +, bo...@apache.org wrote:
Fix race conditions in initialisation of DBD, DBM and DSO.
For 2.0, this is just a temporary solution, until this is
re-engineered.
This commit (and its backports) is counting on CTR folks. I am no locks
expert by any stretch of
On Wed, 2009-06-10 at 20:54 +0200, Arfrever Frehtes Taifersar Arahesis
wrote:
2009-06-06 18:43:43 Arfrever Frehtes Taifersar Arahesis napisał(a):
The following revisions were backported to APR-Util 1.3.x branch, but not
1.4.x:
r780411
r781403
Please backport them to APR-Util 1.4.x
On Thu, 2009-06-11 at 07:37 +1000, Bojan Smojver wrote:
I think not, because after the if/else, we still have work to do. We
need to find the symbol for our DB engine (either from the hash or by
dso_load), which depends on type, which can be different from call to
call. No?
I verified
On Tue, 2009-06-09 at 02:24 -0400, Philip M. Gollucci wrote:
No I just want SUBVERSION to be able to tell that APR-UTIL was
compiled with ANY BDB support.
If I do 'grep -rl apr_dbm *' in subversion-1.6.2 source, I don't get any
hits. You sure SVN actually uses that?
BTW, have you tried
On Tue, 2009-06-09 at 03:18 -0400, Philip M. Gollucci wrote:
libsvn_fs_base is compiled if BDB support is detected.
I think it calls Berkeley DB API directly, not via APU. Hence, the fact
that -ldb was part of apu-1-config --libs, was just a historical
accident.
If a program calls apr_dbm*(),
On Tue, 2009-06-09 at 03:35 -0400, Philip M. Gollucci wrote:
Excellent, Bojan, now I've got the history and why, and understand
whats happened. I don't think teaching subversion about this fact
will be sufficient --
There are over 56 apps in the freebsd ports tree with over 900 depends
On Tue, 2009-06-09 at 17:29 +1000, Bojan Smojver wrote:
PS. We do have a workaround for ldap along these lines, where we
report ldap in --libs, unless --avoid-ldap is passed to the config
script. Maybe we should do this here, to avoid breaking compilation
compatibility. Opinions?
Quick
On Tue, 2009-06-09 at 18:01 +1000, Bojan Smojver wrote:
Quick and dirty...
Or to preserve the original order, this one.
--
Bojan
Index: apu-config.in
===
--- apu-config.in (revision 782876)
+++ apu-config.in (working copy
On Tue, 2009-06-09 at 10:58 -0500, William A. Rowe, Jr. wrote:
You are not missing anything, and solutions are welcomed.
I'm not sure that I'm addressing the right problem here. So, limit
yourself to rocks of no more than 2kg when throwing.
Obviously, there is no guarantee that int's are
On Wed, 2009-06-10 at 10:53 +1000, Bojan Smojver wrote:
also initialise it from apr_initialize()
Eh, which is already the case.
--
Bojan
On Tue, 2009-06-09 at 20:01 -0500, William A. Rowe, Jr. wrote:
In trunk, you mean :)
You are right. Fooled again by grep (also returns things within
comments :-).
--
Bojan
On Wed, 2009-06-10 at 10:53 +1000, Bojan Smojver wrote:
so we can replace the int's with apr_uint32_t
Just for the record.
--
Bojan
Index: misc/apu_dso.c
===
--- misc/apu_dso.c (revision 783165)
+++ misc/apu_dso.c (working copy
On Wed, 2009-06-10 at 11:13 +1000, Bojan Smojver wrote:
Just for the record.
Or, maybe even this. Compiles and passes make check (surprisingly!).
--
Bojan
Index: misc/apu_dso.c
===
--- misc/apu_dso.c (revision 783165)
+++ misc
On Wed, 2009-06-10 at 11:34 +1000, Bojan Smojver wrote:
Or, maybe even this. Compiles and passes make check (surprisingly!).
Here is a go-crazy patch. Deals with LDAP, DBD, DBM and DSO init itself.
--
Bojan
Index: ldap/apr_ldap_stub.c
On Wed, 2009-06-10 at 12:19 +1000, Bojan Smojver wrote:
Deals with LDAP, DBD, DBM and DSO init itself.
Actually, that LDAP thing is not required.
--
Bojan
On Wed, 2009-06-10 at 13:51 +1000, Bojan Smojver wrote:
Actually, that LDAP thing is not required.
So, here are the two patches. One for trunk (for now, until this gets
fixed properly) and one for 1.3.x/1.4.x.
--
Bojan
Index: dbd/apr_dbd.c
On Mon, 2009-06-08 at 23:16 -0400, Philip M. Gollucci wrote:
-ldb* is never added to APRUTIL_EXPORT_LIBS so that apu-config.in -
apu-1-config can report on whats there using (i.e. from subversion)
Probably the result of moving the DBM (not DBD) to DSO.
--
Bojan
On Tue, 2009-06-09 at 14:13 +1000, Bojan Smojver wrote:
Probably the result of moving the DBM (not DBD) to DSO.
BTW, does it work when you use --with-berkeley-db with Subversion's
configure? I seem to be able to build it that way (1.6.2) on Linux...
--
Bojan
On Wed, 2009-06-03 at 11:19 -0500, William A. Rowe, Jr. wrote:
[+1] Release apr 1.3.5 as GA
[+1] Release apr-util 1.3.7 as GA
Good signatures. Good checksums.
Tested on Fedora 11, i686.
--
Bojan
On Wed, 2009-06-03 at 11:25 -0500, William A. Rowe, Jr. wrote:
[+1] Release apr 0.9.18 as GA
[+1] Release apr-util 0.9.17 as GA
Good signatures. Good checksums.
Tested on Fedora 11, i686.
The only thing that fails is this (APR):
-
starting consumer.
Name-based
On Tue, 2009-06-02 at 10:50 -0500, William A. Rowe, Jr. wrote:
1 from bojan,
jim and I'm a little confused why a not-a-regression test module flaw
would halt a release
Practical reasons only. We already had fixes committed and it looked
like APR was going to be re-rolled, so doing APU as well
On Mon, 2009-06-01 at 17:14 +0200, Arfrever Frehtes Taifersar Arahesis
wrote:
./configure --without-ldap
Technically, you have a point. In practice, just don't pass anything to
configure regarding ldap and it won't be included. Does that work for
you?
--
Bojan
On Sat, 2009-05-30 at 23:55 -0700, Sander Temme wrote:
#0 0x000103a7 in send0_pollset (tc=0xb508, data=0x0) at
testpoll.c:389
If you stop there and have a look at the vars, anything that GDB doesn't
like? Wrong alignment and such?
--
Bojan
On Fri, 2009-05-29 at 03:08 -0500, William A. Rowe, Jr. wrote:
[+1] Release apr 1.3.4 as GA
[-1] Release apr-util 1.3.5 as GA
--
$ ./testall -v testdbm
testdbm : |Line 175: expected 0, but saw 20019
FAILED 1 of 2
Failed TestsTotal FailFailed
On Sun, 2009-05-31 at 09:15 -0700, Sander Temme wrote:
Looks like descs has not been filled in:
(gdb) p descs
$8 = (const apr_pollfd_t *) 0x0
Should that be NULL after the poll?
Maybe you need to step into apr_pollset_poll() on line 384, to see what
happens to descs there. Looks like
On Sun, 2009-05-31 at 05:21 -0700, Jeff Trawick wrote:
FWIW, make check has been causing a system panic for me on at least
10.5.5-10.5.7. As Paul mentioned earlier (somewhere), this is
triggered by our kqueue() use (which has no issues AFAICT on FreeBSD).
I don't recall other people reporting
On Sat, 2009-05-30 at 21:39 -0700, Sander Temme wrote:
testpoll: |/bin/sh: line 1: 1831 Bus
error ./$prog
Programs failed: testall
make[1]: *** [check] Error 138
make: *** [check] Error 2
What does gdb tell you?
--
Bojan
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=revrevision=768417
--
Bojan
On Thu, 2009-05-21 at 17:59 -0400, Jeff Trawick wrote:
for sure
OK, shall merge to 1.3.x and 1.4.x. Not sure if it's required for 0.9.x.
Will have a look.
--
Bojan
On Fri, 2009-05-22 at 00:12 +0200, Stefan Fritsch wrote:
Don't forget CVE-2009-0023.
Not familiar. Is that the buckets/apr_brigade.c off by one thing?
--
Bojan
On Fri, 2009-05-22 at 00:29 +0200, Stefan Fritsch wrote:
No. It was discussed with secur...@apache.org in January. William Rowe
knows about it.
OK, I'll leave it up to him then.
--
Bojan
On Mon, 2009-04-20 at 11:45 +0100, Dave Ingram wrote:
Does anyone have any suggestions as to how I could
emulate this for systems using older versions of apr-util?
One (terrible) way to do it is here:
http://www.rexursive.com/svn/mod_spin/trunk/src/db.c
Look for words: BIG TIME CHEATING in
On Wed, 2009-04-08 at 14:14 +0100, Daniel Pocock wrote:
The only thing that seems out of place is apr-1-config, as there is no
bin64 or bin32 directory. If the 32 bit and 64 bit packages are
installed concurrently, then one of them overwrites the other's
apr-1-config.
You can have a look at
On Thu, 2009-03-26 at 21:32 +0100, Branko Čibej wrote:
Maybe it's just me, but all that seems like a monumental waste of
time.
I don't really have the right to comment here, because I put zero effort
into this, but it does look that way, doesn't it?
On the other hand, there are patches that
On Thu, 2009-03-26 at 13:09 +0100, LAUPRETRE François (P) wrote:
The project is named managelogs. The URL is
http://managelogs.tekwire.net.
It's been added to the open source section. It should appear shortly. If
something is not correct, let me know and I'll fix.
Thank you for you submission!
On Tue, 2009-03-24 at 11:26 +0100, Justin Erenkrantz wrote:
[x] Fix the LDAP interface to be a complete/full LDAP abstraction
[ ] Remove the LDAP interfaces from APR
Provided most of the code can be taken from mod_ldap. In other words,
more people can use it if it is in APR.
But, if it is hard
On Wed, 2009-03-25 at 01:34 +0200, Graham Leggett wrote:
mod_ldap is an LDAP cache, it isn't an LDAP abstraction layer (that's
what apr-ldap is for).
I meant, maybe there is code in there that already abstract a lot of
that stuff, which can then be reused, given it works with many LDAP
On Sun, 2009-03-22 at 16:19 -0700, Oftenwrong Soong wrote:
The projects using APR page at apr.apache.org/projects.html lists JXTA-C as
one of the projects. Unfortunately the link is no longer valid.
The correct link is:
https://jxta-c.dev.java.net/
Thanks. Should be corrected shortly.
Would there be interest in having them in APR 2.0/1.4? They would be the
fsync()/fdatasync() counterparts.
--
Bojan
On Sun, 2009-03-08 at 19:57 -0400, Eric Covener wrote:
It occured to me just after changing this macro that its addition
broke versioning rules when it was added to 1.2.x post-release.
The new macro has already been in a release, 1.2.12. Is it better to
leave it or pull it?
The damage has
On Tue, 2009-03-03 at 21:51 +0100, Stefan Fritsch wrote:
The problem with the CLOEXEC-patch is that apr_file_dup2() now only
checks for APR_INHERIT but not for APR_FILE_NOCLEANUP to determine if
FD_CLOEXEC should be set. But APR_FILE_NOCLEANUP should imply
APR_INHERIT and the new
On Tue, 2009-03-03 at 21:51 +0100, Stefan Fritsch wrote:
The problem with the CLOEXEC-patch is that apr_file_dup2() now only
checks for APR_INHERIT but not for APR_FILE_NOCLEANUP to determine if
FD_CLOEXEC should be set. But APR_FILE_NOCLEANUP should imply
APR_INHERIT and the new
On Tue, 2009-03-03 at 22:57 +0100, Stefan Fritsch wrote:
Yes (with old_file-flags instead of flag).
Cut'n'paste is a wonderful thing. Most of the time ;-)
--
Bojan
On Tue, 2009-03-03 at 17:57 -0600, William A. Rowe, Jr. wrote:
Setting the flag is sufficient.
The fact that a handle shouldn't be closed on exec in an apr-sense makes
no difference to whether it should be closed on non-apr exec() calls.
Just before I make the change, let me understand this
On Tue, 2009-03-03 at 18:08 -0600, William A. Rowe, Jr. wrote:
I believe that is correct. Anyone else care to validate? As far as I know
this change is a noop, until the introduction of this most recent file
inheritance patch for CLOEXEC.
After reading apr_os_file_put() (which is used to
On Mon, 2009-03-02 at 17:07 -0600, William A. Rowe, Jr. wrote:
This entire patch set has me increasingly worried, as it has the strong
potential of destabilizing many apr apps.
The _intention_ of the patch (at least as interpreted by me) is that if
the file has APR_INHERIT_SET flag turned
On Sat, 2009-02-28 at 17:27 +0100, Stefan Fritsch wrote:
No problem. Thanks for commiting the patch. BTW, I think a CHANGES
entry would be good, too. And Arkadiusz Miskiewicz did a part of the
patch.
Done.
Are parts of this suitable for backport to 1.3/1.4?
I would hope so.
The change
On Fri, 2009-02-27 at 15:54 +, rpl...@apache.org wrote:
Author: rpluem
Date: Fri Feb 27 15:54:37 2009
New Revision: 748565
URL: http://svn.apache.org/viewvc?rev=748565view=rev
Log:
* One missing unroll of APR_SET_FD_CLOEXEC.
Thanks. I must have been on drugs :-(
--
Bojan
On Fri, 2009-02-27 at 20:22 +, bo...@apache.org wrote:
+Patch by Stefan Fritsch sf sfritsch.de.
Apologies Stefan for not doing this earlier. Not sure how I missed it.
--
Bojan
On Thu, 2009-02-26 at 14:58 +0100, Ruediger Pluem wrote:
IMHO doing a return in a macro that is just a block not a function
is bad. What if the return parameter of the function is not an int?
Furthermore it is a side effect that makes it hard to read the code.
Thanks for reviewing! I'll
On Thu, 2009-02-26 at 02:41 +, bo...@apache.org wrote:
Author: bojan
Date: Thu Feb 26 02:41:21 2009
New Revision: 747990
URL: http://svn.apache.org/viewvc?rev=747990view=rev
Log:
Set CLOEXEC flags where appropriate. Either use new O_CLOEXEC flag and
associated functions, such as
On Mon, 2009-02-23 at 21:47 -0600, William A. Rowe, Jr. wrote:
stupid question, but did you validate the licensing implications of
this particular commit?
Not sure what you mean. Is our trunk licensed differently than 1.3.x?
--
Bojan
On Mon, 2009-02-23 at 22:14 -0600, William A. Rowe, Jr. wrote:
But did you check what
this step now absorbs into the finished package?
No, not really. I'll check before the release. In the meantime, it's in
SVN, which should be OK.
Not sure if this may be relevant:
On Tue, 2009-02-24 at 15:57 +1100, Bojan Smojver wrote:
I'll check before the release.
argz.m4:
# This file is free software; the Free Software Foundation gives
# unlimited permission to copy and/or distribute it, with or without
# modifications, as long
On Mon, 2009-01-05 at 13:07 +0200, Sami Tolvanen wrote:
I would appreciate it if someone more familiar with the memcache code
could review the patch and let me know if there are any gotchas with
this approach. Unless there's a better way for fixing the memory leak
without modifying the API, I
On Sun, 2008-12-21 at 03:22 +, Nick Kew wrote:
If he confirms that, we can deliver a
fix by ensuring all drivers return memory that'll remain for the
lifetime of a pool.
Or, we can just document the fact that we are using memory here that may
not survive and it is user's responsibility to
On Wed, 2008-12-17 at 19:07 +0300, Ury Stankevich wrote:
1. can we improve APR_BRIGADE_CHECK_CONSISTENCY to check
bucket/brigade pools to complain
if bucket is allocated _not_ from the same pool as brigade ( and not
it ancestor)?
2. how we can safely move bucket from one pool to another ?
On Wed, 2008-11-12 at 15:45 +0100, Mladen Turk wrote:
If the dbd module is compiled with
APU_DSO_BUILD it is still defined inside apu.h
which is IMHO wrong.
For example
#define APU_HAVE_SQLITE3 1
is present although the apr_dbd_sqlite3 module
was build.
I was under perception that
On Wed, 2008-08-27 at 11:04 +1000, Bojan Smojver wrote:
Do you have an opinion on this one for instance:
https://issues.apache.org/bugzilla/show_bug.cgi?id=45679
We cannot decide if there is some kind of historical trickery going on
there on not.
Any comments?
--
Bojan
On Mon, 2008-11-10 at 21:35 -0600, William A. Rowe, Jr. wrote:
wow - you plan to build itanium 32 bit? now that's one ancient piece of
scrap metal ;-P
http://en.wikipedia.org/wiki/IA-32
--
Bojan
On Sun, 2008-11-09 at 20:26 +0100, Branko Čibej wrote:
Every major Linux distro in the world has some kind of APR package that
you can probably use. In this case its really best to rely on vendors to
do the right thing.
Exactly. And these folks also solved the dual-arch problem for you
On Sun, 2008-10-12 at 19:11 +0100, Dave Ingram wrote:
Actually, it turns out that apr_dbd_prepare() is destroying its
arguments no matter whether it succeeds or not. What's going on? Does
anyone have any handy examples of how to use the DBD code?
My best bet is that you have pool
On Fri, 2008-10-03 at 08:50 -0700, Tim Bray wrote:
Um, I know that. But apr_file_mktemp doesn't let you control where
the temp file goes, right?
If you give it full pathname in the template, doesn't that allow you to
put it where you want it?
--
Bojan
On Thu, 2008-10-02 at 23:40 -0700, Tim Bray wrote:
status = apr_file_open(fp, tempname, APR_FOPEN_WRITE |
APR_FOPEN_CREATE, PERMS, pool);
Where does the tempname come from?
--
Bojan
On Thu, 2008-10-02 at 21:08 -0700, peter baer wrote:
Also, if you look at the apr_reslist_create() documentation, it states
that the ttl if non-zero, sets the maximum amount of time a resource
may be available while exceeding the soft limit. . Why then is the
destructor being called for all
Hi to group.
New source of rbd you tube. Free and easy to download
http://videos.videosextube2009.com/rbd-you-tube.html
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Esthetics group.
To post to this group, send
On Thu, 2008-09-11 at 16:58 +0530, Kusuma Pabba wrote:
i am new to tomcat
Wrong list (this is APR development). Try Tomcat user list.
The information contained in this electronic message and any
attachments to this message are intended for the exclusive use of the
addressee(s)
Sorry, but
On Wed, 2008-09-10 at 18:38 -0700, peter baer wrote:
This never used to happen on
earlier versions.
Resource list code in memcache changed slightly with 1.3.4 (some memory
leaks were closed).
I have attached a test program (main.c) showing how I triggered this
issue. It has a hard min of 32,
On Wed, 2008-09-03 at 17:08 +0100, Ian Gardner wrote:
Each thread calls apr_thread_mutex_destroy on a different mutex, but in
the same pool.
Looking naively at apr_pool_cleanup_kill it would appear to be modifying
pool state variables without any sort of concurrency protection which
could
On Thu, 2008-08-28 at 11:57 -0700, Warren L Dodge wrote:
testvsn : FAILED 2 of 2
Could you go into test directory and run:
./testall -v testvsn
This should print a bit more info about the failures.
--
Bojan
On Mon, 2008-08-25 at 23:30 -0500, William A. Rowe, Jr. wrote:
I'm thinking this is a healthy time to start crawling through bugzilla
Do you have an opinion on this one for instance:
https://issues.apache.org/bugzilla/show_bug.cgi?id=45679
We cannot decide if there is some kind of historical
On Thu, 2008-08-14 at 00:36 -0500, William A. Rowe, Jr. wrote:
+/-1
[+1] Release apr-util-1.3.4
Good signatures, good checksums.
Fedora 9, i386/x86_64, all tests passed.
--
Bojan
On Wed, 2008-08-13 at 12:59 -0400, Olivier Beaton wrote:
After a nearly 2 month wait for the latest release and svn
trunk to compile I've lost a lot of faith.
You have to understand that people working on APR/APU a volunteers.
--
Bojan
On Wed, 2008-08-13 at 21:51 -0400, Bob Rossi wrote:
Sure, but what should we do, isn't one of the goals of apr to be
portable?
It is. Unfortunately, not everyone has or is familiar with all
platforms. For instance, I have no idea what mingw actually is, I never
used it or compiled anything on
On Tue, 2008-08-12 at 11:11 -0400, Jeff Trawick wrote:
That free() must be inside a check for APR_HAS_THREADS (potentially
extremely painful to diagnose, but for a minority of
platforms/builds).
That's my bad guys :-( Thanks for catching it. And thanks Ruediger for
fixing it.
I hereby change
On Tue, 2008-08-12 at 18:28 -0500, William A. Rowe, Jr. wrote:
We might want to note this one in CHANGES, if only to communicate why
there was no 1.3.3 apr-util?
Done.
--
Bojan
On Tue, 2008-08-12 at 18:22 -0500, William A. Rowe, Jr. wrote:
That's a pretty major headache,
Yeah, pretty embarrassing, actually :-(
and if this is the only delta between
1.3.3 and 1.3.4, I'd permit an abbreviated vote of 36 hours to release
1.3.4 apr-util so we can announce both at once.
On Sun, 2008-08-10 at 02:34 +0200, Rainer Jung wrote:
Failed TestsTotal FailFailed %
===
testsock8 1 12.50%
Line 92: Problem getting http service (2): No such file or directory
That's ignorable,
On Fri, 2008-08-08 at 20:57 +, [EMAIL PROTECTED] wrote:
Backport r683771 from the trunk.
Fix APR_PID_T_FMT detection on Solaris.
Patch by Rainer Jung rainer.jung kippdata.de.
Nobody complained, so in it goes. Please pay attention to this when
testing 1.3.3.
And yes, I did forget to put
On Fri, 2008-08-08 at 16:35 -0500, William A. Rowe, Jr. wrote:
Great, I presume both you and Rainer are now happy with this blended
solution to Davi's initial report.
Rainer is the author of the patch, so he's obviously OK with it. Eric
also confirmed that it fixes the issue. I can't see any
On Thu, 2008-08-07 at 05:56 +, [EMAIL PROTECTED] wrote:
Destroy already created resources if create fails
Nice catch! We should earmark this one for backport to 1.3.x if nobody
objects.
--
Bojan
On Thu, 2008-08-07 at 06:57 +, [EMAIL PROTECTED] wrote:
Add API that allows to setup the cleanup order after the reslist was created
Cool. This closes the whole should we backport and changing the order
of cleanups saga :-)
--
Bojan
On Thu, 2008-08-07 at 09:52 +0200, Mladen Turk wrote:
We might also backport the apr_reslist_cleanup_order_set
but of course not set it up as exported but only usable
inside apr-util if that'll help unifying memcache.
Whatever the list prefers on this one is good for me. We can either go
with
201 - 300 of 930 matches
Mail list logo
