Bojan Smojver wrote:
On Mon, 2007-06-04 at 17:49 -0500, William A. Rowe, Jr. wrote:
[+1] apr-iconv-1.2.0
And +1 to all three packages, here.
I'm finally in one place, with connectivity, at last. I'll stage these
all up with updated web content tomorrow (and probably tackle placing
our
Bojan Smojver wrote:
On Mon, 2007-06-04 at 17:49 -0500, William A. Rowe, Jr. wrote:
[+1] apr-iconv-1.2.0
Fedora 7, i386, builds against APR 1.2.9 (both against APR build tree
and installed APR).
One note, though. Without --prefix option to configure, the build fails
Looks like
On Mon, 2007-06-04 at 17:49 -0500, William A. Rowe, Jr. wrote:
[+1] apr-iconv-1.2.0
Fedora 7, i386, builds against APR 1.2.9 (both against APR build tree
and installed APR).
One note, though. Without --prefix option to configure, the build fails
with:
William A. Rowe, Jr. wrote:
That's +4 for apr's (+5 once I vote), +1 for apr-iconv (+2 once I vote).
I'll chime in and close this round of release votes once I have
one more +/- apr-iconv 1.2.0.
Ping?
William A. Rowe, Jr. wrote:
http://apr.apache.org/dev/dist/
+/-1? Package to release
[ ] apr-0.9.14
[ ] apr-1.2.9
[ ] apr-iconv-1.2.0
Three packages so far to consider, votes welcome
We are at 2x +1 for apr 0.9.14 and apr 1.2.9
We are at no votes for apr-iconv 1.2.0.
On Jun 4, 2007, at 3:49 PM, William A. Rowe, Jr. wrote:
http://apr.apache.org/dev/dist/
+/-1? Package to release
[+1] apr-0.9.14
[+1] apr-1.2.9
[+1] apr-iconv-1.2.0
Three packages so far to consider, votes welcome
FreeBSD 6.1 and 4.11, see below. +1 for release. Both
On 6/6/07, Colm MacCarthaigh [EMAIL PROTECTED] wrote:
On Thu, Jun 07, 2007 at 12:24:07AM +0300, Lucian Adrian Grijincu wrote:
1. kill AI_ADDRCONFIG for APR_UNSPEC
In my opinion, AI_ADDRCONFIG is a useful default flag and prevents
unneccessary delay and lookups.
+1
4. Add
On 06/07/2007 12:10 AM, William A. Rowe, Jr. wrote:
Ruediger Pluem wrote:
On 06/06/2007 11:45 PM, William A. Rowe, Jr. wrote:
I'm quite partial to your third solution, I trust from performance that
this is the greatest net efficiency (but per platform tests would be needed
to confirm this).
On 6/7/07, William A. Rowe, Jr. [EMAIL PROTECTED] wrote:
Lucian Adrian Grijincu wrote:
I hear that there are real performance reasons to maintain
AI_ADDRCONFIG for AF_UNSPEC:
http://www.ops.ietf.org/lists/v6ops/v6ops.2003/msg01377.html
I first though we could do a strcmp to check for
On 6/7/07, Colm MacCarthaigh [EMAIL PROTECTED] wrote:
On Thu, Jun 07, 2007 at 12:24:07AM +0300, Lucian Adrian Grijincu wrote:
1. kill AI_ADDRCONFIG for APR_UNSPEC
In my opinion, AI_ADDRCONFIG is a useful default flag and prevents
unneccessary delay and lookups.
2. document ::1 and any other
On 6/7/07, Colm MacCarthaigh [EMAIL PROTECTED] wrote:
On Thu, Jun 07, 2007 at 03:06:10AM +0300, Lucian Adrian Grijincu wrote:
You said (or so I understood) that APR should add a new flag
(APR_NUMERIC_ADDRESS) to it's API. When a programmer wants to use
::1 in a call to apr_sockaddr_info_get,
On Thu, Jun 07, 2007 at 12:03:03AM +0200, Ruediger Pluem wrote:
On 06/06/2007 11:45 PM, William A. Rowe, Jr. wrote:
I'm quite partial to your third solution, I trust from performance that
this is the greatest net efficiency (but per platform tests would be needed
to confirm this). This is
Joe Orton wrote:
I was hoping to see this get some testing on some more exotic/less
modern systems, to try to flush out any regressions :(
Well the new logic is quite clean. Someday a lcllibpth like variable
that perl builds would be sweet (for searching the unusual/platform
specific
Davi Arnaut wrote:
Bojan Smojver wrote:
On Wed, 2007-06-06 at 09:38 +1000, Bojan Smojver wrote:
testlfs : Line 265: Large Files not supported
Or is this just a misleading message saying these things are enabled by
default on this platform?
Good question. LFS doesn't exist
Disclaimer: I haven't checked to see if this is the right behaviour, I
have an exam tomorow :(
Ubuntu 7.04 32 bit
testsockets : \Segmentation fault (core dumped)
I've tested it twice, with a clean checkout of trunk both times; same behaviour.
All tests before this one worked fine.
--
I took http://apr.apache.org/dev/dist/apr-1.2.9.tar.gz
Hope I'm on target now:)
I've done two tests. One in which I ran buildconf myself and one without.
For each test I then ran:
./configure
make
make test
Both failed with:
testsockets : \/bin/bash: line 1: 10039 Segmentation fault
the cause: segmentation fault at:
rv = apr_socket_bind(sock, to);
from static void sendto_receivefrom(abts_case *tc, void *data)
from testsockets.c
the second parameter given is NULL:
apr_socket_bind (sock=0x80d3c78, sa=0x0) at network_io/unix/sockets.c:154
the NULL value comes from
William A. Rowe, Jr. wrote:
Davi Arnaut wrote:
Bojan Smojver wrote:
On Wed, 2007-06-06 at 09:38 +1000, Bojan Smojver wrote:
testlfs : Line 265: Large Files not supported
Or is this just a misleading message saying these things are enabled by
default on this platform?
Good
On Mon, Jun 04, 2007 at 05:49:43PM -0500, William Rowe wrote:
http://apr.apache.org/dev/dist/
+/-1? Package to release
[+1] apr-0.9.14
[+1] apr-1.2.9
These both show no regressions on Linux/i386 and x86_64.
w.r.t. APR_HAS_LARGE_FILES, please see list archives for rationale, it
Lucian Adrian Grijincu wrote:
the cause: segmentation fault at:
rv = apr_socket_bind(sock, to);
from static void sendto_receivefrom(abts_case *tc, void *data)
from testsockets.c
the second parameter given is NULL:
apr_socket_bind (sock=0x80d3c78, sa=0x0) at
On Wed, Jun 06, 2007 at 11:40:41AM +0300, Lucian Adrian Grijincu wrote:
I took http://apr.apache.org/dev/dist/apr-1.2.9.tar.gz
Hope I'm on target now:)
I've done two tests. One in which I ran buildconf myself and one without.
For each test I then ran:
./configure
make
make test
Both
I've gotten it down to this:
int getaddrinfo(const char *node, const char *service,
const struct addrinfo *hints,
struct addrinfo **res);
getaddrinfo hates ::1 as a node parameter.
I've attached a tester for getaddrinfo (based on Ulrich Drepper's
Lucian Adrian Grijincu wrote:
I've gotten it down to this:
int getaddrinfo(const char *node, const char *service,
const struct addrinfo *hints,
struct addrinfo **res);
getaddrinfo hates ::1 as a node parameter.
I've attached a tester for
On Wed, Jun 06, 2007 at 06:06:44PM +0300, Lucian Adrian Grijincu wrote:
$./test ::1 ssh
./test: getaddrinfo: Address family for hostname not supported
$ telnet ::1 ssh
Trying ::1...
Connected to ::1.
That makes little sense. I presume you do in fact have the ipv6
module loaded (lsmod |
Joe Orton wrote:
On Wed, Jun 06, 2007 at 06:06:44PM +0300, Lucian Adrian Grijincu wrote:
$./test ::1 ssh
./test: getaddrinfo: Address family for hostname not supported
$ telnet ::1 ssh
Trying ::1...
Connected to ::1.
That makes little sense. I presume you do in fact have the ipv6
On 6/6/07, Davi Arnaut [EMAIL PROTECTED] wrote:
Joe Orton wrote:
On Wed, Jun 06, 2007 at 06:06:44PM +0300, Lucian Adrian Grijincu wrote:
$./test ::1 ssh
./test: getaddrinfo: Address family for hostname not supported
$ telnet ::1 ssh
Trying ::1...
Connected to ::1.
That makes little
Lucian Adrian Grijincu wrote:
I took http://apr.apache.org/dev/dist/apr-1.2.9.tar.gz
Hope I'm on target now:)
I've done two tests. One in which I ran buildconf myself and one without.
For each test I then ran:
./configure
make
make test
Both failed with:
testsockets :
On Mon, 2007-06-04 at 17:49 -0500, William A. Rowe, Jr. wrote:
http://apr.apache.org/dev/dist/
+/-1? Package to release
[ ] apr-0.9.14
[+1] apr-1.2.9
[ ] apr-iconv-1.2.0
Three packages so far to consider, votes welcome
Fedora 7 i386 and x86_64.
PS. Thanks everyone for
Davi Arnaut wrote:
William A. Rowe, Jr. wrote:
But no, we should probably figure out how to report this case more
intellegently in testlfs so people don't panic. LARGE_FILES, imho,
should not be set where special handling of the file offsets didn't
happen.
I think that
Davi Arnaut wrote:
See my email about it, message id [EMAIL PROTECTED]
It boils down to a combination of ai_flags = AI_ADDRCONFIG and ::1
(loopback address). The test is wrong, it should expect a failure (with
the current network_io code adding the AI_ADDRCONFIG flag).
Thanks for the
On 6/7/07, William A. Rowe, Jr. [EMAIL PROTECTED] wrote:
Lucian Adrian Grijincu wrote:
I took http://apr.apache.org/dev/dist/apr-1.2.9.tar.gz
Hope I'm on target now:)
I've done two tests. One in which I ran buildconf myself and one without.
For each test I then ran:
./configure
make
make
William A. Rowe, Jr. wrote:
would you try running within gdb and give us the where's? You might
need to recompile with CFLAGS=-g for debugging symbols.
someday I'll learn to read forward to the end before clicking send on
the smaller random replies :) Nicely done with your diagnostics. On
Lucian Adrian Grijincu wrote:
I hear that there are real performance reasons to maintain
AI_ADDRCONFIG for AF_UNSPEC:
http://www.ops.ietf.org/lists/v6ops/v6ops.2003/msg01377.html
I first though we could do a strcmp to check for 127.0.0.1 or ::1,
but it's not going to work, because users
On 06/06/2007 11:45 PM, William A. Rowe, Jr. wrote:
I'm quite partial to your third solution, I trust from performance that
this is the greatest net efficiency (but per platform tests would be needed
to confirm this). This is worth dumping 1.2.9 and rerolling 1.2.10 IMHO
(along with
Ruediger Pluem wrote:
On 06/06/2007 11:45 PM, William A. Rowe, Jr. wrote:
I'm quite partial to your third solution, I trust from performance that
this is the greatest net efficiency (but per platform tests would be needed
to confirm this). This is worth dumping 1.2.9 and rerolling 1.2.10
On Wed, Jun 06, 2007 at 03:05:17PM -0300, Davi Arnaut wrote:
It boils down to a combination of ai_flags = AI_ADDRCONFIG and ::1
(loopback address). The test is wrong, it should expect a failure (with
the current network_io code adding the AI_ADDRCONFIG flag).
O.k., I think you're
On Thu, Jun 07, 2007 at 12:24:07AM +0300, Lucian Adrian Grijincu wrote:
1. kill AI_ADDRCONFIG for APR_UNSPEC
In my opinion, AI_ADDRCONFIG is a useful default flag and prevents
unneccessary delay and lookups.
2. document ::1 and any other link-local addresses and hostnames as
invalid if
On Wed, Jun 06, 2007 at 01:39:52PM -0300, Davi Arnaut wrote:
digging deeper we get into network_io/unix/soccaddr.c, where there's a
this call
error = getaddrinfo(hostname, servname, hints, ai_list);
This returns -9 which gai_strerror says it means Address family for
hostname not
Colm MacCarthaigh wrote:
On Wed, Jun 06, 2007 at 03:05:17PM -0300, Davi Arnaut wrote:
It boils down to a combination of ai_flags = AI_ADDRCONFIG and ::1
(loopback address). The test is wrong, it should expect a failure (with
the current network_io code adding the AI_ADDRCONFIG flag).
O.k.,
On Thu, Jun 07, 2007 at 02:06:49AM +0300, Lucian Adrian Grijincu wrote:
snip from=man getaddrinfo(3)
If hints.ai_flags contains the
AI_NUMERICHOST flag then the node parameter must be a numerical
network
address. The AI_NUMERICHOST flag suppresses any potentially
Colm MacCarthaigh wrote:
Looking at the test, I think we should have two tests, one for IPv6
and one for IPv4. Run them both, allow the IPv6 one to fail (if the
module is not loaded or whatever). Does that seem acceptable to
people ? I volunteer to help make the changes anyway, the current
On Wed, Jun 06, 2007 at 08:32:12PM -0300, Davi Arnaut wrote:
/Users/davi/gai $ ./gai -na ::1
getaddrinfo(::1, NULL, {.family=AF_UNSPEC,
.hints=0|AI_ADDRCONFIG|AI_NUMERICHOST}) = 0:
family=30, proto= 6 inet6: addr=::1, port=0, flowinfo=0
How come this succeeded? The system doesn't have any
On Wed, Jun 06, 2007 at 06:36:52PM -0500, William A. Rowe, Jr. wrote:
+1 - that sounds like a great solution. Do you want me to hold off on
the 1.2.10 tag for a day or two to slip this in, now that we know what
the case is?
Nah, it's been like that for ages :-)
--
Colm MacCárthaigh
Colm MacCarthaigh wrote:
On Wed, Jun 06, 2007 at 08:32:12PM -0300, Davi Arnaut wrote:
/Users/davi/gai $ ./gai -na ::1
getaddrinfo(::1, NULL, {.family=AF_UNSPEC,
.hints=0|AI_ADDRCONFIG|AI_NUMERICHOST}) = 0:
family=30, proto= 6 inet6: addr=::1, port=0, flowinfo=0
How come this succeeded? The
On Wed, Jun 06, 2007 at 08:49:06PM -0300, Davi Arnaut wrote:
Why wouldn't that fail?
Sorry, it should have been:
getaddrinfo(::1, NULL, {.family=AF_UNSPEC, .hints=0|AI_ADDRCONFIG}) = 0:
family=30, proto= 6 inet6: addr=::1, port=0, flowinfo=0
Last question (sorry for wasting your
On Thu, Jun 07, 2007 at 03:06:10AM +0300, Lucian Adrian Grijincu wrote:
You said (or so I understood) that APR should add a new flag
(APR_NUMERIC_ADDRESS) to it's API. When a programmer wants to use
::1 in a call to apr_sockaddr_info_get, they should pass in this
flag as well, to be sure that
On Thu, Jun 07, 2007 at 03:38:39AM +0300, Lucian Adrian Grijincu wrote:
a) either have different behaviour on different platforms (Ubuntu 7.4
(and everything based on it) vs. the rest).
AI_ADDRCONFIG behaviour is not supported on plenty of platforms yet,
yes, but it's backwards compatible,
Colm MacCarthaigh wrote:
On Wed, Jun 06, 2007 at 06:36:52PM -0500, William A. Rowe, Jr. wrote:
+1 - that sounds like a great solution. Do you want me to hold off on
the 1.2.10 tag for a day or two to slip this in, now that we know what
the case is?
Nah, it's been like that for ages :-)
On 6/4/2007 at 4:49 PM, in message [EMAIL PROTECTED], William
A. Rowe, Jr. [EMAIL PROTECTED] wrote:
http://apr.apache.org/dev/dist/
+/-1? Package to release
[ +1 ] apr-0.9.14
[ +1 ] apr-1.2.9
[ na ] apr-iconv-1.2.0
Three packages so far to consider, votes welcome
On Mon, 2007-06-04 at 17:49 -0500, William A. Rowe, Jr. wrote:
http://apr.apache.org/dev/dist/
+/-1? Package to release
[ ] apr-0.9.14
[ ] apr-1.2.9
[ ] apr-iconv-1.2.0
Three packages so far to consider, votes welcome
APR Compiles and passes tests when built as an RPM
Bojan Smojver wrote:
On Wed, 2007-06-06 at 09:38 +1000, Bojan Smojver wrote:
testlfs : Line 265: Large Files not supported
Or is this just a misleading message saying these things are enabled by
default on this platform?
Good question. LFS doesn't exist for 64 bit
http://apr.apache.org/dev/dist/
+/-1? Package to release
[ ] apr-0.9.14
[ ] apr-1.2.9
[ ] apr-iconv-1.2.0
Three packages so far to consider, votes welcome
52 matches
Mail list logo
