On Fri, 2008-07-25 at 00:17 +, [EMAIL PROTECTED] wrote:
Add apr_file_link() function.
PR 44841.
Patch by Mark Heily mark heily.com
Folks, this addition includes Windows code, which I am unable to review
at all (Unix code is very simple, though). So, I'm relying on CTR here!
--
Bojan
On Thu, 2008-07-24 at 23:35 -0400, Tom Donovan wrote:
I moved apr_file_link() to open.c for all platforms - r679652.
Also moved the tests to testfile vs. testfilecopy.
unix/copy.c is currently used for both unix windows, as it had no
platform-specific code before this.
Ah, wasn't aware
On Thu, 2008-07-17 at 05:45 +, [EMAIL PROTECTED] wrote:
Use apr_pool_pre_cleanup_register for reslist cleanup
Coming back to the original commit message and given the discussion on
the list, are we backporting this to 1.3.x or not?
--
Bojan
I think we should be a little bit more strict when it comes to resource
limits in reslist code. As per attached, it should not be possible to
set min to less than zero and hmax to zero, as both don't make sense.
Comments?
--
Bojan
Index: misc/apr_reslist.c
On Sun, 2008-07-27 at 13:50 +0100, Nick Kew wrote:
+1.
Here is a rough sketch, so please review. Please note the enforcement of
min, smax and hmax to 1.
--
Bojan
Index: include/apr_reslist.h
===
--- include/apr_reslist.h
On Sun, 2008-07-27 at 20:05 -0400, Bob Rossi wrote:
Ping. Anything I can do to help?
I think Bill had that one. He's a busy guy though, so it may be a
while...
PS. I'm not familiar with that platform at all, so I can't help :-(
--
Bojan
On Sun, 2008-07-27 at 19:19 -0500, William A. Rowe, Jr. wrote:
Or more to the point, when is 1.3.x ready to ship w.r.t. reslist? You'll
note there hasn't been a 1.3.3 tag since I've been watching all of this
activity, and didn't want to rush anyone.
There are several things that we can do
On Mon, 2008-07-28 at 10:30 +1000, Bojan Smojver wrote:
- implement when no_threads (patch also available)
Hmm, on second thought, it may be against the rules to backport this to
1.3.x.
If someone were to compile a program against 1.3.3 on a platform with no
threads, this program would not run
On Mon, 2008-07-28 at 20:45 +0200, Ruediger Pluem wrote:
Hm, of course still a lot of overhead to manage a single resource.
True. I first started writing the patch with just a (void *) pointing to
the resource, but then I realized that ttl actually may be useful for
recycling it. So, rather
On Mon, 2008-07-28 at 12:27 +0200, Mladen Turk wrote:
I plan to thoroughly test those changes against httpd this week.
So lets wait for a while. If that stops tagging 1.3.x, we can
postpone that for next tag.
OK. I'm also hoping we'll hear from others.
--
Bojan
On Mon, 2008-07-28 at 23:51 +0100, Joe Orton wrote:
It does seem like existing callers could reasonably depend on the
existing behaviour, and that changing it would break them.
The situation is quite complicated. Tricks like the ones from mod_dbd
(or malloc()/free() container + zero sub-pool
On Wed, 2008-07-30 at 06:53 -0400, Tom Donovan wrote:
Calling sqlite3_busy_timeout() in dbd_sqlite3_open might be better than using
the
do { ... apr_sleep() ... }
loop in dbd_sqlite3_select_internal.
Yeah, true. I may just rework it with that instead. Thanks for the hint!
Nevertheless,
On Thu, 2008-07-31 at 07:30 +1000, Bojan Smojver wrote:
I may just rework it with that instead.
On second thought, it may not be that simple, given the DBD mutex we
have in place...
--
Bojan
On Thu, 2008-07-31 at 07:30 +1000, Bojan Smojver wrote:
I could get about 40 times as many pages out.
Eh, not true, actually. Never mind - please ignore me :-(
--
Bojan
Quoting Joe Orton [EMAIL PROTECTED]:
I'd rather the decision was made by those who are more familiar with
this code than I. The fact that this change apparently does break an
existing caller does seem to back up the API change argument:
http://markmail.org/message/xjgaampnoru67pxr
I wasn't
After reading this article on LWN: http://lwn.net/Articles/292559/, it
occurred to me that it may be useful to pass this flag to open in
apr_file_open() on platforms that support it, in case someone decides to
fork()/execve() by non-APR means.
Of course, apr_file_inherit_[un]set() would have to
On Tue, 2008-08-05 at 14:57 -0500, William A. Rowe, Jr. wrote:
You have it upside down though, apr_file_inherit_[un]set should toggle
the CLOEXEC flag.
I was thinking something like this (untested).
--
Bojan
Index: file_io/unix/open.c
On Wed, 2008-08-06 at 14:00 +1000, Bojan Smojver wrote:
I was thinking something like this (untested).
Probably not complete. I guess we should check in file_cleanup() if the
error on close() is EBADF and not report it if O_CLOEXEC is defined. Or
something like that...
--
Bojan
On Wed, 2008-08-06 at 12:46 +0200, Ruediger Pluem wrote:
I am worried about the case that the destructor might allocate
memory from the pool for temporary purposes (ok that would be a
memory leak in the long run).
Not only that, but if you have a look at testreslist.c, you'll find
this:
On Wed, 2008-08-06 at 12:27 +0200, Mladen Turk wrote:
The major problem with invalidate is that blocking
destructors (socket shutdown for example)
are serialized, meaning that closing 100 sockets
is done one at a time instead by owning threads in
parallel.
Why don't you instead shut the
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
On Thu, 2008-08-07 at 15:08 -0500, William A. Rowe, Jr. wrote:
Here's an offer, I'll tag and roll 24 hours from now unless someone tells me
that the API remains broken w.r.t. reslist etc.
Not broken. In fact, the trunk changes have been addressed in an
entirely backward compatible way.
On the back of PR 45513
(https://issues.apache.org/bugzilla/show_bug.cgi?id=45513), shouldn't we
be moving that piece of code that manually overrides detection for
particular platforms to the very end, like we had it in 1.2.x?
Patch is attached. Please review, as it would be a good idea to put
On Fri, 2008-08-08 at 07:46 +1000, Bojan Smojver wrote:
On the back of PR 45513
(https://issues.apache.org/bugzilla/show_bug.cgi?id=45513)
Looks like this was busted in
http://svn.apache.org/viewvc?view=revrevision=554963
--
Bojan
On Fri, 2008-08-08 at 00:42 +0200, Peter Poeml wrote:
I am a heavy user of both mod_dbd and apr_memcache, and I'm
investigating an apr_memcache related memleak right now that I started
getting with 1.3.0, so I will give this a good testing in the next few
hours.
Latest patch for memcache
On Fri, 2008-08-08 at 07:46 +1000, Bojan Smojver wrote:
Patch is attached.
Just got feedback from the original bug reporter (Rainer Jung) and the
attached patch is incorrect. So, here is the patch submitted with the
bug report that fixes the issue on Solaris.
--
Bojan
--- configure.in-orig
On Fri, 2008-08-08 at 08:58 +1000, Bojan Smojver wrote:
Latest patch for memcache leak is attached.
That's for 1.3.x. The trunk should be OK, because it relies on
pre_cleanup.
PS. If the list thinks that it is better to have
apr_reslist_cleanup_order_set() in 1.3.x as non-public API
On Fri, 2008-08-08 at 01:40 +0200, Peter Poeml wrote:
That patch does the job as well.
OK, thanks. Committed to 1.3.x now in r683756.
Folks, this commit is quite obviously a hack around limitations of
reslist in 1.3.x. If the list decides it is better that we have
On Thu, 2008-08-07 at 17:55 -0500, William A. Rowe, Jr. wrote:
Thanks Peter, it begs the question from my last note, should we refuse
any 2.62 for packaging via our scripts, or just let it slide?
My gutcheck says simply refuse 2.62.
I would generate our configure with 2.61 (for which we
On Fri, 2008-08-08 at 03:45 +0200, Peter Poeml wrote:
So the usual stability of the
API isn't so important (yet) in my opionion.
The new API in reslist that switches the behaviour of cleanups cannot be
made public in 1.3.x, due to our versioning rules. But, we could do that
internally, if
On Fri, 2008-08-08 at 04:33 +, [EMAIL PROTECTED] wrote:
Warn reslist users of potential dangers related to sub-pool creation.
I did this for 1.3.x only on purpose. Trunk should probably get a
different comment.
--
Bojan
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 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 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 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 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 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-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 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 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 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
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-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
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 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 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 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 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-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 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 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 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 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 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 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 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 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 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 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
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-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.
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 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 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 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 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 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 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 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 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 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 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 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
601 - 700 of 930 matches
Mail list logo
