On Fri, 2010-01-08 at 11:15 +1100, Bojan Smojver wrote:
Why can't we just use malloc() for this and hang a cleanup off the
pool? It would use less memory anyway than having another pool for
this.
Quick and dirty example of what I mean here.
--
Bojan
Index: tables/apr_hash.c
On Fri, 2010-01-08 at 11:35 +1100, Bojan Smojver wrote:
+ mem = calloc(max + 1, sizeof(*ht-array));
+ apr_pool_cleanup_register(ht-pool, mem,
+ array_cleanup,apr_pool_cleanup_null);
No, I don't think that's going to work. Again, memory may vanish before
another
On Fri, 2010-01-08 at 11:39 +1100, Bojan Smojver wrote:
No, I don't think that's going to work. Again, memory may vanish
before another cleanup runs.
Essentially, this reduces is to the problem of a sibling pool, for which
the cleanup is hanging off the pool, but with lower memory use. Still
On Mon, 2009-12-21 at 20:35 +0100, Guenter Knauf wrote:
I think we need a way to distribute alpha releases, just same as what
we do with httpd.
Why don't we just do what many other projects do - pronounce that for
any odd minor release no versioning rules apply, whatsoever. So, if
somebody
On Mon, 2009-12-21 at 21:25 +, wr...@apache.org wrote:
- * The ASF licenses this file to You under the Apache License, Version 2.0
+ * The ASF licenses this file to You under the Apache License, 3 2.0
Was this change intentional?
--
Bojan
On Mon, 2009-12-21 at 23:55 +0100, Branko Čibej wrote:
Perfectly OK to invent safeguards that prevent people from being
tripped by half-baked unreleased APIs, but to nuke the whole version
numbering paradigm is nonsense.
Speaking pragmatically, would skipping odd minor release versions (i.e.
On Mon, 2009-12-21 at 17:01 -0600, William A. Rowe Jr. wrote:
I don't think Bojan actually suggests we nuke it.
No, no nuking at all. Just bit of skipping.
The suggestion is that all n.even releases would be ABI stable. n.odd
releases would be purely alpha- and beta-, with clear notices to
On Tue, 2009-12-15 at 15:05 +, Joe Orton wrote:
Should the APR project treat those snapshots as releases for
versioning purposes?
Without actually casting a vote (because doing so seems to be
contentious in itself), I would say no. Generally speaking, APR folks
don't have control over what
On Wed, 2009-12-09 at 23:02 -0600, William A. Rowe Jr. wrote:
So it truly runs without threads on 1.4.x?
I'm guessing r680514 is the answer. Trunk has essentially the same file,
bar namespace changes.
--
Bojan
On Thu, 2009-12-10 at 16:12 +1100, Bojan Smojver wrote:
I'm guessing r680514 is the answer. Trunk has essentially the same
file, bar namespace changes.
You can also have a look at this:
https://issues.apache.org/bugzilla/show_bug.cgi?id=24325
--
Bojan
On Wed, 2009-12-09 at 23:35 -0600, William A. Rowe Jr. wrote:
That doesn't begin to explain to me why it differs between the 1.3 and
1.4 branches. Only why it might differ between 1.x and 2.x. I'm very
confused.
My guess is that if someone had 1.3.x compiled without threads, having
this
On Wed, 2009-12-09 at 23:35 -0600, William A. Rowe Jr. wrote:
That doesn't begin to explain to me why it differs between the 1.3 and
1.4 branches.
BTW, this change was made before branching of 1.4.x, on the trunk. So,
when 1.4.x was created, that was already in there.
--
Bojan
On Thu, 2009-12-03 at 12:57 +0100, Edgar Frank wrote:
Regarding this and trying to work around the problem, I found no
possibility to decouple the two brigades.
Have you tried removing the buckets from the brigade with
APR_BUCKET_REMOVE() and then putting it in the second brigade?
As for
On Fri, 2009-12-04 at 07:52 +0100, Edgar Frank wrote:
But after Grahams
reply, I'm going to think about it twice.
Yeah, if you're doing anything with APR and you pool lifetimes are not
clear, there will be trouble.
--
Bojan
We have effectively this code closing the file in apr_file_close():
---
static apr_status_t file_cleanup(apr_file_t *file, int is_child)
{
apr_status_t rv = APR_SUCCESS;
if (close(file-filedes) == 0) {
file-filedes = -1;
---
If someone calls
On Fri, 2009-10-30 at 10:26 +0100, Stefan Ruppert wrote:
first of all the question is if the apr_file_t handle can be safely
used from different threads? e.g. is APR file wrapper thread safe? And
I don't think so!
It isn't safe. Not even with APR_FOPEN_XTHREAD.
This whole thing is related to
On Fri, 2009-10-30 at 12:01 +0100, Stefan Ruppert wrote:
I don't know the concept behind APR_FOPEN_XTHREAD, but after a quick
look into the trunk source code this seems to only protect the
buffered io but not the file structure itself.
From my point of view if an application needs to
On Wed, 2009-10-28 at 12:40 +0200, Viktor Griph wrote:
And as far as I can tell it was enough to load both the mod_auth_mysql
modue and the mod_dbd module and speciy DBDriver mysql in the config
for apache2 -t to crash (after outputing Syntax OK).
Right.
That other backtrace - that's not from
On Wed, 2009-10-28 at 23:15 +0200, Viktor Griph wrote:
It was from apache, but since the segfault was in an apr component I
though this was the rigt place to report it.
This was the right place to report it for sure. I was just trying to
figure out the sequence of events.
--
Bojan
On Fri, 2009-10-16 at 15:26 +0700, Yuri V. Vishnevskiy wrote:
For some reason in my program I need two file handlers of stdout
stream.
If you duplicate the descriptor with apr_file_dup() instead of calling
apr_file_open_stdout() twice, does it still do the same?
--
Bojan
On Mon, 2009-10-12 at 09:21 +0200, Henk van de Kamer wrote:
So which one is correct?
Something's not right there. The latest is 1.3.9. You can grab it form
main distribution directory, a bit further down on the same page.
--
Bojan
On Sat, 2009-10-10 at 10:55 +0400, Kevac Marko wrote:
For example, we are using information from MYSQL_FIELD structure,
which, again, is not available from apr_dbd.h functions. Anyway, with
some dark hack magic one can access it (of course in non-portable
manner).
I'm guessing you are getting
On Fri, 2009-10-09 at 13:21 +0400, Kevac Marko wrote:
I would like to head word or two from apr-lib mantainers about this
patch.
I've seen it, but I'm ENOTIME right now. When I get some time, I'll
review it.
--
Bojan
On Fri, 2009-10-09 at 13:39 +0400, Kevac Marko wrote:
Thank you. I am ready to comment on everything or fix anything, but i
would not like for patches just to vanish in depths of history.
Got it. No worries. Also, I see you filed bugs, so this will definitely
haunt us :-)
--
Bojan
On Thu, 2009-10-01 at 14:10 +0400, Kevac Marko wrote:
+if (fields[6].value != NULL) {
+if (strstr(fields[6].value, CLIENT_FOUND_ROWS)) {
+flags |= CLIENT_FOUND_ROWS;
+}
+else if (strstr(fields[6].value, CLIENT_MULTI_STATEMENTS))
{
+flags
On Thu, 2009-10-01 at 14:20 +0400, Kevac Marko wrote:
Without this attribute set, max_length field is not filled for
prepared statements.
I'm not seeing use of max_length in the driver. Can you elaborate a bit
more what this is for?
From what I can see we rely on buffer_length for prepared
On Thu, 2009-10-01 at 20:40 +0200, Branko Čibej wrote:
I think it's a good idea on general principles to hide the SVN admin
area from the Web The admin area isn't part of the public repository..
+1 (because it looks nicer)
--
Bojan
On Tue, 2009-09-29 at 09:35 -0700, Jeff Barnes wrote:
Can someone point out some error or provide some guidance?
Looks like your generated C file is missing some includes. Have a look
at the generated file and try to compile it by hand. Also, I'm guessing
@LIBAPR@ is not blank, right?
--
Bojan
Graham,
Is you key in this file: http://www.apache.org/dist/apr/KEYS
--
Bojan
On Fri, 2009-09-25 at 02:08 +0200, Graham Leggett wrote:
I thought it was, but no - it is now.
Thanks!
--
Bojan
On Sat, 2009-09-19 at 23:34 +0700, Yuri V. Vishnevskiy wrote:
I have a problem with using stdout stream opened by
apr_file_open_stdout()
function. If I open several stdout handlers in my program then it
crashes
when calls apr_file_close() function more than one time.
Could you run it
On Sun, 2009-09-20 at 09:56 +0700, Yuri V. Vishnevskiy wrote:
Here is a call stack:
test.exe!_crt_debugger_hook(int _Reserved=2) Line 62 C
Thanks.
I just now realised this is Windows. I guess someone else will have to
have a look. I don't have that platform and I'm not at all familiar
On Thu, 2009-08-20 at 15:34 +1000, Bojan Smojver wrote:
Yeah, this may be a problem. If the same file descriptor is opened
after the exec() call closes it, we may close someone else's open
descriptor.
Ah, scrap that. I have no idea why, but I keep thinking of fork() when
it's exec(). Go figure
On Thu, 2009-08-20 at 17:08 +1000, Jack Andrews wrote:
i think he's asking us to confirm or deny patterns that he has
found that could indicate another bug that has a similar
fix to a bug that was fixed previously.
Yeah, something like that:
--
It would be greatly
On Thu, 2009-08-20 at 17:49 -0400, Gang wrote:
We are trying to understand this problem in the following way. In the
file file_io/unix/open.c, since there exists the codes (line 166 to
180) which have already set FD_CLOEXEC if APR_FOPEN_NOCLEANUP was not
set, so the codes (line 214 to 218) do
On Thu, 2009-08-20 at 17:49 -0400, Gang wrote:
Besides the possible bug 3.1 we mentioned in the last email, we have
found a similar problem 3.2 as well.
According to the bug-fix pattern in the function “apr_file_mktemp()”,
we think that APR may also set “flags |= FD_CLOEXEC” (line 279 to
On Thu, 2009-08-20 at 19:50 -0400, Gang Shu wrote:
Sorry for bothering again. I made a typing mistake in the former
emails.
Don't worrye - helping us find bugs is no bother!
For 3:
The original bug-fix should exist in Filename:
network_io/unix/sockets.c, Function:
On Thu, 2009-08-20 at 01:08 -0400, Gang Shu wrote:
We applied our approach in your newest release APR
1.3.8 and we have identified a few potential bugs as follows.
Could you please send proposed patches as plain text attachments. They
should be diffs against the trunk.
--
Bojan
On Thu, 2009-08-20 at 01:08 -0400, Gang Shu wrote:
We’ve found two potential bugs where “file_lock(thefile)” and
“file_unlock(thefile)” are missing.
The locks are used when the file is buffered. They should generally not
be required when the file is not buffered (the kernel takes care of its
On Thu, 2009-08-20 at 01:08 -0400, Gang Shu wrote:
“there is a (possibly brief) period of time between the return of the
open() call or other function creating a file descriptor and the
fcntl() call to set the flag, so we believe that an object is changed
to rely on FD_CLOEXEC for closure
On Thu, 2009-08-20 at 01:08 -0400, Gang Shu wrote:
3. Analyzed bug-fix: 46425
(https://issues.apache.org/bugzilla/show_bug.cgi?id=46425)
The comment of this bug-fix is as follows:
“apr should set FD_CLOEXEC if APR_FOPEN_NOCLEANUP is not set. This
would in general help with security and
On Wed, 2009-08-12 at 14:51 -0700, Michael Spiegle wrote:
I have a module I am writing which implements a content-generator and
a filter. If I make a sub-request from within my content-generator,
the filter's (request_rec*)f-r only points to the original request.
How do I access the current
On Mon, 2009-08-10 at 10:15 -0500, William A. Rowe, Jr. wrote:
The idea is to pull in only the bindings used
Yeah, I thought so too. I kinda remember a discussion along those lines
on the list...
--
Bojan
On Tue, 2009-08-11 at 01:22 +0200, Guenter Knauf wrote:
I'm perfectly fine, and even agree with your both ideas and thoughts
as long as you dont force every developer to adopt them! Why dont you
want to allow developers to choose what's best for their
application/platform? Is that too much
I'm guessing most people on the list would already have this, but here
it is nevertheless. We don't have user/announce list, it goes to dev.
--
Bojan
---BeginMessage---
Sign up for ApacheCon US by 14 August and save up to $500!
This year's ApacheCon US promises to deliver our most extensive
On Tue, 2009-08-04 at 17:07 -0500, William A. Rowe, Jr. wrote:
[+1] Release apr 1.3.8 as GA
[+1] Release apr-util 1.3.9 as GA
Good signatures. Good checksums.
All tests pass on Fedora 11, i686 and RHEL4, i686.
Apache 2.2.12 and libapreq2 2.12 appear to work with it.
--
Bojan
On Sat, 2009-08-01 at 09:42 +0200, Ruediger Pluem wrote:
Shouldn't this be
#include mysql/my_sys.h
instead above?
It should, but even with that change, it breaks here on Fedora 11:
In file included from dbd/apr_dbd_mysql.c:38:
/usr/include/mysql/my_global.h:648:
On Mon, 2009-08-03 at 10:58 +0200, Rüdiger Plüm wrote:
Bill, does this work on Windows as well?
Doesn't this patch bring us back where we were (roughly)?
--
Bojan
On Mon, 2009-08-03 at 11:17 +0200, Ruediger Pluem wrote:
Not really.
That's why I said roughly ;-)
--
Bojan
On Mon, 2009-08-03 at 11:17 +0200, Ruediger Pluem wrote:
my patch reverses the ordering Bill introduced
Which makes me think, maybe we'll need to thrown in some #ifdef WIN32's
or something.
--
Bojan
On Mon, 2009-08-03 at 09:36 -0500, William A. Rowe, Jr. wrote:
#define HAVE_THAT_H in a .c source?
seriously
WOW! I have no idea why exactly that was in. I'm betting it was some
kind of testing code in the working copy that got committed by mistake.
AFAIK, it was committed in r82 if niq's old
I didn't get any feedback yet from the bug reporter here:
https://issues.apache.org/bugzilla/show_bug.cgi?id=47590
But I'm guessing it's a trivial fix along the lines of what we've seen
before, where we pass in default environment, so that the child runs OK
when compiled with the Intel compiler.
On Tue, 2009-08-04 at 00:25 +0100, Nick Kew wrote:
Hmmm? That's entirely possible (though the name doesn't look like a
particularly likely candidate for my debug code), but your reference
eludes me.
From whence is that #define?
r82 in your old repo. You were just changing the licensing
On Mon, 2009-08-03 at 18:30 -0500, William A. Rowe, Jr. wrote:
I'll hold up just a bit while commits continue, go ahead.
Done.
--
Bojan
On Fri, 2009-07-31 at 11:11 +0200, Graham Leggett wrote:
I find my_init() defined here:
mysql/mysql_com.h
/* Some other useful functions */
my_bool my_init(void);
I suspect we may not be including this header.
We are not including mysql/mysql_com.h directly.
MySQL 5.0 manual says:
On Fri, 2009-07-31 at 12:57 +0200, Graham Leggett wrote:
Is my_init() a public mysql function? We might be using the wrong init
procedure.
That manual seems to claim so:
http://dev.mysql.com/doc/refman/5.1/en/my-init.html
http://dev.mysql.com/doc/refman/5.0/en/my-init.html
--
Bojan
@@
-*- coding: utf-8
-*-
Changes for APR 2.0.0
- *) Pass default environment to testflock and testoc children.
+ *) Pass default environment to testflock and testoc children, so that
+ tests run when APR is compiled with Intel C Compiler.
[Bojan Smojver
On Sat, 2009-08-01 at 00:40 +, wr...@apache.org wrote:
Reorder the config into sanity, prefer include/mysql/ structure
if found, and *be consistent*.
On Fedora 11, i686, I get this:
-
In file included from dbd/apr_dbd_mysql.c:38:
/usr/include/mysql/my_global.h:648:
On Wed, 2009-07-22 at 05:15 -0500, Rhys Ulerich wrote:
Yes, I see the same problem on 1.3.6.
BTW, this is a problem related to code of the actual tests, not APR
itself. So, no big deal.
--
Bojan
On Tue, 2009-07-21 at 16:34 -0500, Rhys Ulerich wrote:
On the same Ubuntu 8.04 / 64-bit system with Intel 10.1 compilers I
see this from make check:
testflock : \tryread: error while loading shared libraries:
libimf.so: cannot open shared object file: No such file or directory
On Mon, 2009-07-20 at 17:21 -0400, Jim Jagielski wrote:
Release candidate tarballs in usual location
(http://apr.apache.org/dev/dist/
)
[not for distribution]. Vote starts as we speak and will run for
48 hours.
+1
Good signatures, good MD5s.
All tests pass on Fedora 11 (i686) and RHEL4
On Wed, 2009-07-22 at 00:27 -0500, Rhys Ulerich wrote:
LD_LIBRARY_PATH is set in my environment. libimf.so is in a
nonstandard directory present in LD_LIBRARY_PATH. ldd finds libimf.so
because it is in my LD_LIBRARY_PATH. I'm aftraid I can't give more
solid answers than these-- due to some
On Wed, 2009-07-22 at 15:46 +1000, Bojan Smojver wrote:
Maybe we need to add APR_PROGRAM_ENV to procattr there?
See if this works for you.
--
Bojan
Index: test/testflock.c
===
--- test/testflock.c (revision 796615)
+++ test
On Mon, 2009-07-20 at 08:13 +0200, Tollef Fog Heen wrote:
You could force it on using apr_cv_epoll=yes ./configure and such, but
ugh and eww.
Ah, yes. There is always that too (note to self: edit Rawhide spec file
when APR 1.3.7 gets released).
Debian does have a minimum kernel version that's
On Sun, 2009-07-19 at 08:18 +0200, Tollef Fog Heen wrote:
Since I'm one of those Debian people who wanted the runtime detection
in the past: No, we can't do that.
The apr (and all other packages) are built by build daemons on various
different architectures. We, as the packagers of apr,
On Sun, 2009-07-19 at 21:52 +0200, Tollef Fog Heen wrote:
Not doing run-time detection means that everybody using Debian and
derived distros (including Ubuntu) will get the castrated version
where any and all features of new kernel versions are not used, so not
doing runtime detection also has
On Fri, 2009-07-17 at 09:13 -0400, Dan Poirier wrote:
I came across one little thing that seems to have been missed:
Thanks. Applied.
--
Bojan
On Thu, 2009-07-16 at 09:27 +0100, Joe Orton wrote:
In the past I have argued we should never do runtime platform feature
detection, i.e., if accept4() works at build-time, we can presume it
works at run-time. I think I need to soften that position now; use of
a modern userspace on an older
On Thu, 2009-07-16 at 20:42 +0200, Ruediger Pluem wrote:
Does fixing this issue warrant yet another apr release?
My vote would be yes. Version numbers are cheap.
--
Bojan
On Thu, 2009-07-16 at 17:16 -0700, Gregg L. Smith wrote:
Please fix this before you do
Linking...
Creating library Release/libaprutil-1.lib and object
Release/libaprutil-1.exp
apr_buckets_alloc.obj : error LNK2001: unresolved external symbol
_apr_pool_allocator_get
On Wed, 2009-07-15 at 14:07 +1000, Bojan Smojver wrote:
Can you tell me if the attached runs and detects things properly on
your system?
OK, this is probably slightly better.
--
Bojan
Index: configure.in
===
--- configure.in
On Wed, 2009-07-15 at 13:09 +0200, Aleric Inglewood wrote:
Now we have to decide whether to use one APR memory pool per thread or,
to allow multiple thread to use the same apr_pool_t undercertain
circumstances.
This is a cut'n'paste of my own reply from an old thread (no other
committer
On Thu, 2009-07-16 at 01:39 +, bo...@apache.org wrote:
Use more elaborate checks for epoll_create1, dup3 and accept4.
This requires review folks. There is code in the tests that can
potentially hang the configure process. It does work on my Fedora 11 box
(which has the functions) and on
On Wed, 2009-07-15 at 19:09 -0700, Michael Spiegle wrote:
IMO, the TTL value
should be in seconds which seems more natural to me, but accurate
documentation would have worked too.
Thanks. Committed to trunk now.
--
Bojan
On Thu, 2009-07-16 at 14:30 +1000, Bojan Smojver wrote:
--- docs/doxygen.conf (revision 794505)
+++ docs/doxygen.conf (working copy)
@@ -18,11 +18,7 @@
APR_DECLARE_INHERIT_SET(x)=apr_status_t
apr_##x##_inherit_set(apr_##x##_t *the##x) \
APR_DECLARE_INHERIT_UNSET(x
On Tue, 2009-07-14 at 00:22 -0500, William A. Rowe, Jr. wrote:
FYI only the 1st and 3rd bits of the patch you quoted were necessary,
the second bit was already set volatile.
Yeah, sorry about that. Just did a really quick diff on my local trees
here.
From memory, the only thing that should
On Tue, 2009-07-14 at 14:12 -0400, Chetan Reddy wrote:
confdefs.h also has HAVE_DUP3 set to 1 even though a simple test
program calling dup3 returns -1 with errno 38 (Function not
implemented). So i guess we'd need similar checks for dup3.
OK, thanks. So we'll need to check for that one too.
On Wed, 2009-07-15 at 09:38 +1000, Bojan Smojver wrote:
Probably prudent to do all of them the same way as epoll_create().
Can you tell me if the attached runs and detects things properly on your
system?
--
Bojan
Index: configure.in
On Thu, 2009-07-09 at 13:54 -0400, Chetan Reddy wrote:
configure.in in apr-1.3.6 checks for epoll_create1 using
AC_CHECK_FUNCS . Instead, should it have a check similar to the check
for epoll_create? i can create a patch if someone can confirm that
this is indeed the problem.
I've seen you
On Mon, 2009-07-13 at 17:19 -0500, Rhys Ulerich wrote:
These entries appear in pkg-config output because @EXTRA_CPPFLAGS@ and
@EXTRA_CFLAGS@ are present in apr.pc.in.
How did you configure apr? I have this in my config.nice:
--
CFLAGS=-g -O0 -Wall -fstack-protector; export
On Mon, 2009-07-13 at 19:30 -0500, Rhys Ulerich wrote:
What happens for you when you don't set CFLAGS prior to
running ./configure?
Hmm, what do you know:
-
-DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -g -O2
-pthread
On Mon, 2009-07-13 at 20:26 -0500, William A. Rowe, Jr. wrote:
Why are all my APR_BRIGADE_INSERT_HEAD(b, eos); and similar statements
now causing;
ftp_request.c:76: warning: dereferencing type-punned pointer will
break
strict-aliasing rules
ftp_request.c:76: warning: dereferencing
On Mon, 2009-07-13 at 20:50 -0500, William A. Rowe, Jr. wrote:
../../apr-0.9/strings/apr_snprintf.c: In function ‘conv_os_thread_t’:
../../apr-0.9/strings/apr_snprintf.c:511: warning: dereferencing
type-punned
pointer will break strict-aliasing rules
Must be a different issue then.
--
Bojan
On Mon, 2009-07-13 at 20:50 -0500, William A. Rowe, Jr. wrote:
No improvement :( And still have;
So, just to be clear, when you apply r662299 to 0.9.x, no warnings go
away, right?
--
Bojan
On Sat, 2009-07-11 at 16:11 +, stri...@apache.org wrote:
Link again on OS X, where fdatasync() does not seem to exist.
Thanks for picking that up (I don't have OS X). If we do want to make
all these calls work tighter on OS X, we can also apply F_FULLFSYNC, as
per:
On Thu, 2009-07-09 at 13:54 -0400, Chetan Reddy wrote:
apr builds on my machine(debian testing using kernel 2.6.26) with
HAVE_EPOLL_CREATE1 even though the function isn't implemented on my
system (it's only available since 2.6.27[1]). this causes httpd(with
worker mpm) to segault on startup.
[+1]: apr-1.3.6
[+1]: apr-util-1.3.8
Good signatures, good checksums. All tests pass on Fedora 11 i686. A
brief Apache 2.2.11 test worked too.
PS. Just a reminder that folks running stuff like CGI, PHP, Perl etc.
under Apache (or anything that may call execve()) should verify that all
of their
On Wed, 2009-07-01 at 08:31 -0400, Jeff Trawick wrote:
IMO the better way to handle this would have been
int ret, tmpret;
and using tmpret when the function-wide ret shouldn't be touched
Overloading ret and the semi-hidden setting of the function-wide ret
make this code less clear than
On Wed, 2009-07-01 at 20:35 -0400, Jeff Trawick wrote:
not a -1; just something to think about in the future
OK, thanks.
--
Bojan
On Tue, 2009-06-30 at 07:55 -0400, Jeff Trawick wrote:
We didn't get any further than this on the db build compatibility
issue, right?
The --avoid-dbm options is now in. Meaning, by default, we give people
DB libs once we release the new 1.3.x.
--
Bojan
On Tue, 2009-06-30 at 11:12 -0500, William A. Rowe, Jr. wrote:
Is there anything else blocking a bugfix release on the 3rd if I tag
again later today?
I'm good.
--
Bojan
On Tue, 2009-06-23 at 22:07 +0200, Stefan Fritsch wrote:
there is a long standing bug in the Linux/hppa kernel that flock()
returns EAGAIN and not EWOULDBLOCK. On all other architectures, these
two are defined to be the same. This causes testprocmutex to fail.
Yeah, in fact, I see this in
On Wed, 2009-06-24 at 09:26 +1000, Bojan Smojver wrote:
I'm not sure what
other Unix flavours have here...
BTW, POSIX claims that it is OK for these two to have the same value. It
doesn't mandate it, but that would seem to suggest that they can be
treated as one and the same error.
http
On Mon, 2009-06-22 at 23:54 +, bo...@apache.org wrote:
Backport r747990, r748361, r748371, r748565, r748988, r749810, r783958
from the trunk.
Set CLOEXEC flags where appropriate.
Given there were no -1 voices to my e-mail, here is another chance to do
the same through CTR. Have at it
On Fri, 2009-06-19 at 21:08 +0200, Ruediger Pluem wrote:
I guess you mean exec instead of fork here correct?
Its finally a patch about CLOEXEC.
Yeah, sorry. Got my wires crossed.
--
Bojan
On Sat, 2009-06-20 at 09:50 +1000, Bojan Smojver wrote:
Yeah, sorry. Got my wires crossed.
Just to avoid any confusion caused by my shitty summary, here is what we
are trying to address:
http://udrepper.livejournal.com/20407.html
Obviously, we are attempting to use new calls where possible
On Thu, 2009-06-18 at 13:22 +0200, Gavin Sherry wrote:
Do, we're trying to store r0 (int 6144) at 4(r5) = 4 + 844(r2) above.
Seems like this should all work fine... remarkably trivial stuff. I've
even tried two different versions of GCC with the same result. :(
So, if you stop and try to
On Thu, 2009-06-18 at 22:30 +0200, Gavin Sherry wrote:
I reverted to an older compiler (gcc 4.0.0, shipped by IBM) and the
tests pass. So, this seems to be a compiler bug for this platform.
I'm glad you nailed it. You may want to let GCC guys know.
Thanks for your help.
You are welcome.
--
On Wed, 2009-06-17 at 10:49 +1000, Bojan Smojver wrote:
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
On Fri, 2009-06-19 at 00:26 -0500, William A. Rowe, Jr. wrote:
I don't have an objection, it seems you thought this out, but I don't
always seem to have a buy in over what is compatibility - you might
want the opinion of one or more port maintainers ;)
OK, I'll be waiting for more opinions on
101 - 200 of 930 matches
Mail list logo
