>I am getting the following error when running CGIs on the current
>version of NetWare (6.5 sp2):
> (32)Broken pipe: ap_content_length_filter: apr_bucket_read() failed
>I am working on tracking down the problem.
Changes done to mod_cgi.c, mod_include.(h & c) back in August 22, 2003
are expos
"Jean-Jacques Clar" <[EMAIL PROTECTED]> writes:
[...]
> Given there will be an rc3 can people look at the
> libtool patch and see if it's worthwhile incorporating? The poster
> said that it would help out a using project which IMHO makes it worth
> a look.
Geoff may have misspoke about my libt
I am getting the following error when running CGIs on the current
version of NetWare (6.5 sp2):
(32)Broken pipe: ap_content_length_filter: apr_bucket_read() failed
I am working on tracking down the problem.
JJ>>> "David Reid" <[EMAIL PROTECTED]> 6/30/2004 10:00:52 AM >>>
So, I fixed the incorr
> On Wed, Jun 30, 2004 at 05:00:52PM +0100, David Reid wrote:
>> So, I fixed the incorrect tag and rerolled. The revised tarballs
>> (correctly
>> named to keep Joe happy this time) are being uploaded into the usual
>> place,
>> http://www.apache.org/~dreid/ as I write this.
>>
>> I'll delete the o
Joe Orton <[EMAIL PROTECTED]> writes:
[...]
> The ltmaj fix is not necessary for APR, since APR embeds the major
> version in the library name to allow parallel installs of different
> major versions, so always passing CURRENT == AGE as the libtool
> interface versions is OK.
>
> I'm a little he
On Wed, Jun 30, 2004 at 05:00:52PM +0100, David Reid wrote:
> So, I fixed the incorrect tag and rerolled. The revised tarballs (correctly
> named to keep Joe happy this time) are being uploaded into the usual place,
> http://www.apache.org/~dreid/ as I write this.
>
> I'll delete the old tarballs
"David Reid" <[EMAIL PROTECTED]> writes:
[...]
> Let me retag and update the tarballs...
>
> No reason for an RC3, just a revised RC2 I think...
Also have a look at apr-util-1.0.rc2/test/testpass.c:
it isn't a program, so you probably need HEAD for that also.
--
Joe Schaefer
--On Wednesday, June 30, 2004 5:02 PM +0100 Joe Orton <[EMAIL PROTECTED]>
wrote:
I'm a little hesitant about gratuitously changing the soname just before
a major release, and after 1.0 it will be too late. Is there a reason
why you need the get-version.sh script included in APR to behave like
th
On Mon, Jun 21, 2004 at 01:02:58PM -0400, Joe Schaefer wrote:
> We've been using the build/get-version.sh script in
> httpd-apreq-2. The following patch corrects the
> libtool version string miscalculation (we let libtool
> generate the shared library version for libapreq2, so
> it's pretty well
So, I fixed the incorrect tag and rerolled. The revised tarballs (correctly
named to keep Joe happy this time) are being uploaded into the usual place,
http://www.apache.org/~dreid/ as I write this.
I'll delete the old tarballs to avoid confusion.
Now, just to be clear, I believe that there's a -
Joe Orton wrote:
Can you post them for review first?
The patch is to buildconf. It creates apr.spec from apr.spec.in on
platforms that support "cut".
On other platforms, this code is ignored.
The apr.spec.in file is modified to include the version number from
apr_version.h. Whether the apr.spec.
On Wed, Jun 30, 2004 at 05:27:22PM +0200, Graham Leggett wrote:
> Joe Orton wrote:
>
> >I found a cleaner way to make this work (fingers crossed); there should
> >be no hacks needed to make an RPM out of HEAD now for either apr or
> >apr-util.
>
> Ok - should I commit the RPM spec files setup I h
Joe Orton wrote:
I found a cleaner way to make this work (fingers crossed); there should
be no hacks needed to make an RPM out of HEAD now for either apr or
apr-util.
Ok - should I commit the RPM spec files setup I have so far (should not
affect existing setups, it's the same code that creates the
> On Wed, Jun 30, 2004 at 10:36:36AM -0400, Joe Schaefer wrote:
> > "David Reid" <[EMAIL PROTECTED]> writes:
> >
> > [...]
> >
> > > Now, can people test them and we'll see if we get enough +1's ?
> >
> > I'm running debian-amd64, however I don't believe the problem
> > below is platform-specifi
On Wed, Jun 23, 2004 at 06:46:07PM +0200, Graham Leggett wrote:
> Is the correct fix then to move the awk scripts from the source
> directory to the build directory? (When I looked last night the awk
> scripts seemed to live in apr/build already, unless you're referring to
> other scripts)
I fo
Same problem on RH Enterprise edition ...
yes it doesn't look like platform specific.
Joe Schaefer wrote:
"David Reid" <[EMAIL PROTECTED]> writes:
[...]
Now, can people test them and we'll see if we get enough +1's ?
I'm running debian-amd64, however I don't believe t
On Wed, Jun 30, 2004 at 10:36:36AM -0400, Joe Schaefer wrote:
> "David Reid" <[EMAIL PROTECTED]> writes:
>
> [...]
>
> > Now, can people test them and we'll see if we get enough +1's ?
>
> I'm running debian-amd64, however I don't believe the problem
> below is platform-specific:
...
> testloc
On Wed, 2004-06-30 at 04:56, Joe Orton wrote:
> > Install apr-config as apr-$(APR_MAJOR_VERSION)-config ?
>
> Greg wrote "remove" rather than "rename", though indeed, I guess
> renaming should work.
Renaming is also fine.
"David Reid" <[EMAIL PROTECTED]> writes:
[...]
> Now, can people test them and we'll see if we get enough +1's ?
I'm running debian-amd64, however I don't believe the problem
below is platform-specific:
% cd apr-1.0.rc2; ./configure && make
... builds ok ...
% make check
(cd test && mak
At 08:17 AM 6/30/2004, Jeff Trawick wrote:
>I like Joe's suggestion of catching it in the test suite. If the API is ever
>changed so that the caller specifies the length of their buffer, then there
>will be an interesting case which apr_snprintf() could catch.
Unfortunately, you would need to t
hi all...
Joe Schaefer wrote:
> We've been using the build/get-version.sh script in
> httpd-apreq-2. The following patch corrects the
> libtool version string miscalculation (we let libtool
> generate the shared library version for libapreq2, so
> it's pretty well-tested).
>
> The patch also i
> jorton 2004/06/30 06:16:54
>
> Modified:.configure.in config.layout
> Log:
> * configure.in, config.layout: Add -version suffix to default
> installbuilddir directory.
>
> Revision ChangesPath
> 1.593 +1 -1 apr/configure.in
This looks like a chan
Jim Jagielski wrote:
apr_snprintf(buf, 5, "%3d ", (int) size);
if (buf[3] != ' ') { /* catch overflow */
return strcpy(buf, "");
}
If I understand the problem correctly, doesn't snprintf() return
the number of bytes that would have been printed if there had been
no limit. Thus, can't we che
> At 07:06 AM 6/30/2004, David Reid wrote:
>
> >I haven't done apr-iconv as Will Rowe had some reservations about that
> >module. If someone who's more familiar wants to roll a tarball that's
> >compatible with rc2 that'd be great.
>
> Doesn't matter - now that you've tagged apr-util-1.0.0 - we are
At 03:56 AM 6/30/2004, Joe Orton wrote:
>On Wed, Jun 30, 2004 at 09:49:48AM +0100, Max Bowsher wrote:
>> Joe Orton wrote:
>> > On Tue, Jun 29, 2004 at 03:11:30PM -0400, Greg Hudson wrote:
>> > ...
>> >> So, please change the recently added pkgconfig support to install
>> >> apr-1.pc, so that upstre
At 07:06 AM 6/30/2004, David Reid wrote:
>I haven't done apr-iconv as Will Rowe had some reservations about that
>module. If someone who's more familiar wants to roll a tarball that's
>compatible with rc2 that'd be great.
Doesn't matter - now that you've tagged apr-util-1.0.0 - we are locked
into
On Wed, Jun 23, 2004 at 04:10:58PM +0200, jean-frederic clere wrote:
> >Why take a convset if this can only convert to EBCDIC? You know that the
> >tree is in UTF-8 so there is no other variable for the caller to
> >control.
>
> The convset I have used is ap_hdrs_from_ascii. (APR_DEFAULT_CHARSET,
Available at http://www.apache.org/~dreid/
I haven't done apr-iconv as Will Rowe had some reservations about that
module. If someone who's more familiar wants to roll a tarball that's
compatible with rc2 that'd be great.
They have just 1.0 in the filenames (sorry Joe) but that'll be fixed for the
On Wed, Jun 30, 2004 at 12:32:20PM +0100, David Reid wrote:
> Tagged!
>
> The files that have changed since RC1 are as follows (if any are missing
> please yell!)
Just a reminder that the version should always be "1.0.0" with all three
components, not "1.0", even in tags...
joe
> >
> > apr_snprintf(buf, 5, "%3d ", (int) size);
> > if (buf[3] != ' ') { /* catch overflow */
> > return strcpy(buf, "");
> > }
> >
>
> If I understand the problem correctly, doesn't snprintf() return
> the number of bytes that would have been printed if there had been
> no limit. Thu
Jeff Trawick wrote:
>
> >>reviewed but not approved ;)
> >>
> >>it still has the same bug (apr_snprintf() doesn't return < 0 either)
> >
> >
> > Care to supply a fixed version?
>
> IMHO the original version is sufficient for now. In fact, the new version
> isn't going to misbehave; it just in
Tagged!
Files that have been updated since RC1 are as follows
apr-util.pc.in
Makefile.in
STATUS
docs/doxygen.conf
test/testutil.c
test/testutil.h
test/testuri.c
test/teststrmatch.c
test/testpass.c
test/testbuckets.c
test/abts_tests.h
test/Makefile.in
I haven't (intentioally) included teh EBIDIC
Tagged!
The files that have changed since RC1 are as follows (if any are missing
please yell!)
Makefile.in
configure.in
CHANGES
STATUS
docs/doxygen.conf
include/apr_file_info.h
include/apr_thread_proc.h
shmem/beos/shm.c
test/abts.c
test/testlock.c
test/teststr.c
test/testutil.c
test/testprocmutex
Joe Orton wrote:
On Wed, Jun 30, 2004 at 06:00:29AM -0400, Jeff Trawick wrote:
IMHO the original version is sufficient for now.
Agreed.
Adding tests seems like the best way to protect against someone screwing
up in the future...
yes, that makes perfect sense to me
On Wed, Jun 30, 2004 at 06:00:29AM -0400, Jeff Trawick wrote:
> IMHO the original version is sufficient for now.
Agreed.
..
> Note that libc has to have broken sprintf() or somebody has to introduce a
> new bug into the apr_strfsize() function in order to have such an overflow
> anyway. Due to
David Reid wrote:
[EMAIL PROTECTED] wrote:
wrowe 2004/06/28 11:09:16
Modified:strings Tag: APR_0_9_BRANCH apr_strings.c
Log:
Avoid any edge case or clib bug that might result in a string
overflow of the fixed 5-byte buffer for our size function.
Returns the '' string when
On Wed, Jun 30, 2004 at 09:49:48AM +0100, Max Bowsher wrote:
> Joe Orton wrote:
> > On Tue, Jun 29, 2004 at 03:11:30PM -0400, Greg Hudson wrote:
> > ...
> >> So, please change the recently added pkgconfig support to install
> >> apr-1.pc, so that upstream packages will run "pkg-config --libs apr-1"
Joe Orton wrote:
> On Tue, Jun 29, 2004 at 03:11:30PM -0400, Greg Hudson wrote:
> ...
>> So, please change the recently added pkgconfig support to install
>> apr-1.pc, so that upstream packages will run "pkg-config --libs apr-1"
>> instead of just looking for any old version of APR. By itself, tha
On Tue, Jun 29, 2004 at 03:11:30PM -0400, Greg Hudson wrote:
...
> So, please change the recently added pkgconfig support to install
> apr-1.pc, so that upstream packages will run "pkg-config --libs apr-1"
> instead of just looking for any old version of APR. By itself, that
> won't help with the
39 matches
Mail list logo
