Graham Leggett wrote:
> Joe Orton wrote:
>
>> So again, I guess I presumed back then, and would still now, that
>> these problems were understood and were going to be addressed. But
>> that didn't actually happen; the problems are still there. Again,
>> that is the basis of my veto.
>
> Yep, it
Joe Orton wrote:
> Per the other thread, the review for this has mostly been ignored. I
> have no wish to waste time banging my head against a wall, so I am:
>
> -1 on the addition of the SSL code, r415639 et al, on the basis that:
>
> a) the API is undocumented in basic ways for key functions;
Tollef Fog Heen wrote:
> * "William A. Rowe, Jr."
>
> | Does it make more sense for more complex functions to return a richer
> | result? Or how are you thinking of associating the error with the
> | additional information in a reentrant manner?
>
> I think I misunderstood David's proposal in t
Nick Kew wrote:
> On Thu, 29 Mar 2007 10:11:52 +0100
> David Reid <[EMAIL PROTECTED]> wrote:
>
>> I'd like to take Grahams idea for ldap and move it into "core" apr.
>> The idea would be morphed slightly to work as shown below.
>>
>> We a
I'd like to take Grahams idea for ldap and move it into "core" apr. The
idea would be morphed slightly to work as shown below.
We add a new structure, apr_err_generic_t which is used to contain
details of an error that can't be described by a single code. The intent
is that it's used when an under
Joe Orton wrote:
> On Wed, Mar 28, 2007 at 11:40:30AM +0100, David Reid wrote:
>> A while back there was a comment on this list that the ssl code should
>> be "ripped out" before the next release. There was no additional
>> information as to why, but that's
Joe Orton wrote:
> On Wed, Mar 28, 2007 at 10:09:43AM -0500, William Rowe wrote:
>>> Given Joe's stance (which I'm taking as a veto) I think removing it and
>>> starting a seperate "module" within apr's repo would make the most sense
>>> and should remove the veto from 1.3 - making everyone happy.
William A. Rowe, Jr. wrote:
> David Reid wrote:
>> A while back there was a comment on this list that the ssl code should
>> be "ripped out" before the next release. There was no additional
>> information as to why, but that's OK.
>
> Actually, I d
Joe Orton wrote:
> On Wed, Mar 28, 2007 at 11:40:30AM +0100, David Reid wrote:
>> A while back there was a comment on this list that the ssl code should
>> be "ripped out" before the next release. There was no additional
>> information as to why, but that's
A while back there was a comment on this list that the ssl code should
be "ripped out" before the next release. There was no additional
information as to why, but that's OK.
Maybe it should be removed into a seperate module along the same lines
as apr-iconv? Additionally we should look at what rea
The following patch allows NULL to be passed for either the uid or gid
(or both) should the caller only be interested in one or the other.
If folks think this is OK I'll adjust the docs when I commit.
Index: user/unix/userinfo.c
===
Joe Orton wrote:
> On Wed, Feb 14, 2007 at 04:21:09PM +0000, david reid wrote:
>> I've been contemplating some pieces of functionality for apr-util, but
>> run into the whole "it's a kitchen sink" thing again. We've discussed a
>> few times having apr-
William A. Rowe, Jr. wrote:
> david reid wrote:
>> For the build, I imagine something akin to apxs would be needed, which
>> would install both the module and the headers that it needed while
>> adjusting the build flags accordingly. Whether this is possible to do
>>
William A. Rowe, Jr. wrote:
> david reid wrote:
>> I've been contemplating some pieces of functionality for apr-util, but
>> run into the whole "it's a kitchen sink" thing again. We've discussed a
>> few times having apr-util modules dynamically loa
William A. Rowe, Jr. wrote:
> david reid wrote:
>> I've been contemplating some pieces of functionality for apr-util, but
>> run into the whole "it's a kitchen sink" thing again. We've discussed a
>> few times having apr-util modules dynamically loa
I've been contemplating some pieces of functionality for apr-util, but
run into the whole "it's a kitchen sink" thing again. We've discussed a
few times having apr-util modules dynamically loaded and I think it
might be time to look at making this a reality.
Thoughts?
--
david
http://feathercas
Chad Fox wrote:
> In the event that SSL_accept fails, openssl_get_error is called with
> newSock passed as the apr_ssl_socket_t argument. openssl_get_error
> expects to be able to access the element sslData->ssl of that structure,
> which hasn't been initialized. This can result in a seg fault if
Garrett Rooney wrote:
> On 8/14/06, david reid <[EMAIL PROTECTED]> wrote:
>> Garrett Rooney wrote:
>> > On 8/12/06, david reid <[EMAIL PROTECTED]> wrote:
>> >> After a discussion on irc, I've started lookign at adding pcre support
>>
Garrett Rooney wrote:
> On 8/12/06, david reid <[EMAIL PROTECTED]> wrote:
>> After a discussion on irc, I've started lookign at adding pcre support
>> to apr-util. The patch to start this off is below...
>>
>> Not perfect and not quite complete, but I said I&
After a discussion on irc, I've started lookign at adding pcre support
to apr-util. The patch to start this off is below...
Not perfect and not quite complete, but I said I'd post early on this
and let others look.
david
Property changes on: regex
___
More code taken from apreq - this time more modified to fit with apr and
even with a test case!
Really out the door this time :-)
Index: include/apr_strings.h
===
--- include/apr_strings.h (revision 416632)
+++ include/apr_stri
Nick Kew wrote:
> On Wednesday 02 August 2006 11:58, david reid wrote:
>> First pass at importing some apreq functions. Not yet had time to wirte
>> a test! Rushing out of door, so just a quick mail :-)
>
> fairy nuff1
>
>
>> +/**
>> + * @fn apr_size_t
First pass at importing some apreq functions. Not yet had time to wirte
a test! Rushing out of door, so just a quick mail :-)
More integration with apr_uri structure is planned, but not yet had time
to finish that bit :-)
-- Index: include/apr_uri.h
=
Nick Kew wrote:
> On Tuesday 01 August 2006 10:07, david reid wrote:
>> Having looked at these, they're small and self contained and would seem
>> to be a good fit for apr-util. Question is where/how would they go in?
>
> +1 in principle, and I agree apr_uri is not a gre
Having looked at these, they're small and self contained and would seem
to be a good fit for apr-util. Question is where/how would they go in?
The functionality revolves around uri's, but I'm not sure the existing
apr_uri_ stuff is a sensible match...
Once we have an answer I'll submit a patch :-)
Joe Orton wrote:
> On Fri, Jul 28, 2006 at 06:22:01PM +0100, david reid wrote:
>> While doing some work on mod_sparql I found that some of the
>> functionality i had assumed we already had in apr-util was actually
>> available in apreq. Further examination revealed various pa
While doing some work on mod_sparql I found that some of the
functionality i had assumed we already had in apr-util was actually
available in apreq. Further examination revealed various parts of the
library code that I feel really belong in apr-util.
I talked briefly with joes and he seemed to be
Nick Kew wrote:
> On Wednesday 19 July 2006 15:01, david reid wrote:
>> I'm starting to look at adding a mod_sparql to httpd,
>
> Nice!
>
>> but on thing that
>> will likely be needed is a "store" for RDF files. I suppose adding this
>>
I'm starting to look at adding a mod_sparql to httpd, but on thing that
will likely be needed is a "store" for RDF files. I suppose adding this
functionality to apr-util makes the most sense. The redland libraries
look like a reasonable base for the functionality (they work on most
os's including w
I realise I didn't attend the BOF but believe there was talk about
adding export data. The initial suggestion I saw was for an old
fashioned clunking system that just seems so 1990's, so I'm proposing a
slightly newer 2001-2002 model - following the rough outline of
projects.a.o whereby each pr
Justin Erenkrantz wrote:
On 6/30/06, Colm MacCarthaigh <[EMAIL PROTECTED]> wrote:
On Fri, Jun 30, 2006 at 07:30:04AM +0100, William A. Rowe, Jr. wrote:
> Notification solution;
>
> Post the following notice on our project-specific crypto notice page;
>
> http://apr.apache.org/crypto.html
My i
Justin Erenkrantz wrote:
On 6/30/06, *david reid* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Why not setup a system along the same lines as projects data? Each
project maintains a small rdf file with the information, then we can
aggregate at a project or
Colm MacCarthaigh wrote:
On Fri, Jun 30, 2006 at 09:20:10AM +0100, david reid wrote:
I guess people didn't debate using a distributed solution for
maintaining the list did they? That would seem to be an obvious way to go...
We did, and I don't think there are any legal problems with
I'd like to look at moving the sockaddr and related code out of
network_io and into their own directory. While I agree they are related
to network_io they really should be a separate entity as their use isn't
reliant on the network_io.
david
Colm MacCarthaigh wrote:
On Fri, Jun 30, 2006 at 07:30:04AM +0100, William A. Rowe, Jr. wrote:
Notification solution;
Post the following notice on our project-specific crypto notice page;
http://apr.apache.org/crypto.html
My impression of our outcome at the BoF was that it would probably b
I managed to move connect functionality over, and then it took me no
time to convert sockperf over to new api. with some mods to the app to
allow for more tests per iteration, here are the results.
NB These were done against the same echod running using the current api.
Current API
APR Test A
Justin Erenkrantz wrote:
On 6/28/06, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote:
The only problem I have with an apr_write, is that it's way to easy to
mis-use
apr_write when you ment to use apr_ssl_write explicitly, or
apr_registry_write,
or any thousands of other applications.
Hmm, eit
Justin Erenkrantz wrote:
On 6/25/06, david reid <[EMAIL PROTECTED]> wrote:
apr_io_file(...) will create a file io
apr_io_socket(...) a socket etc etc
Then we simply have
apr_read()
apr_write()
I think that should be apr_io_{read|write}. =) I don't think we want
to repeat the
o);
So, not a lot different really :-)
readv makes sense, as it is easy to simulate if the platform does not
have it.
That's what I figured. Was more curious why it wasn't already in. This
can be handled at the APR level as well, so means only one set of code
for it.
david
Cheers
I've done some work over last 24 hours and have an outline of
abstracting the io functions. The aim is to remove the distinction
between files, socket and pipes - replacing them with a single apr_io_t
type. The exercise of figure out how it should work certainly opened my
eyes to how complex we
Sander Temme wrote:
On Jun 24, 2006, at 8:48 PM, William A. Rowe, Jr. wrote:
Is there a reason for apr issues to continue to go to httpd.apache.org?
That is, is it time for a [EMAIL PROTECTED] mailing list?
+1, I'll be happy to set that up from the Bugzilla end tomorrow at the
Hackathon.
Max Bowsher wrote:
david reid wrote:
Given the talk over last few days about changes to error handling and
the io abstraction stuff, is it time to think about starting a 2.0
development branch?
If a branch is to be created, I'd suggest either a feature development
branch, or a 1.x mainte
Given the talk over last few days about changes to error handling and
the io abstraction stuff, is it time to think about starting a 2.0
development branch?
david
James Mansion wrote:
Let's at least not add this performance hit where it isn't needed, and leave
apr_socket_read/write alone. More that I think about it, an apr_io_XXX() API
for any application that prefers more abstraction would be a win, all around.
I'd be very keen on this. I've been expe
Does this seem like a sensible filename for a file within apr-util to
contain details of apr-util defined error codes? Obviously they can be
defined elsewhere, but having a central file to detail where they can be
found or simply defined within seems like a sensible plan.
Figured I'd check bef
I'd like to add a "reserved" range for error codes in apr-util. Given
that we allow 50,000 for the gap between apr codes and those we advise
apps to use (APR_OS_START_STATUS and APR_OS_START_USERERR) would using
the "2nd half" of that gap (or less) make sense for apr-util? It would
mean we avoid po
Paul Querna wrote:
> Nick Kew wrote:
>> On Thursday 22 June 2006 07:24, [EMAIL PROTECTED] wrote:
>>
>>>Summary: apr_socket_create calls unsupp'd
>>> SetHandleInformation
>>> on WinCE
>>>Product: APR
>>
>> Is it really appropriate to open a huge number of new bug reports here
Joe Orton wrote:
> On Tue, Jun 20, 2006 at 02:11:37PM -0700, Justin Erenkrantz wrote:
>> On 6/20/06, david reid <[EMAIL PROTECTED]> wrote:
>>> I'd like to commit this patch which adds an APR_ESSL error to APR. It's
>>> only use will be in the ssl code n
In fact I did outline my ideas in this piece of the proposed patch...
Good to know I wasn't going totally bonkers...
+/** An error has occurred in the SSL code.
+ * apr_ssl_socket_error() may be called to get a numeric error code
+ * apr_ssl_socket_error_string() may be called for an error desc
Mads Toftum wrote:
On Tue, Jun 20, 2006 at 10:01:22PM +0200, Graham Leggett wrote:
A number of apps I have encountered that use SSL hide the original error
from you, replacing it with something vague and misleading, and you're
off on a wild goose chase.
Generally agreed, although knowing the
I'd like to commit this patch which adds an APR_ESSL error to APR. It's
only use will be in the ssl code now in apr-util. Is this the right
place for it?
Index: ../apr/include/apr_errno.h
===
--- ../apr/include/apr_errno.h (revisi
Garrett Rooney wrote:
On 6/20/06, Justin Erenkrantz <[EMAIL PROTECTED]> wrote:
On 6/20/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> I've defaulted this to be 'ON' so we get reports of problems.
I would prefer that we don't turn SSL factories on by default just
yet. (httpd doesn't enable
Jeff Trawick wrote:
On 6/16/06, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote:
Jeff Trawick wrote:
> On 6/13/06, david reid <[EMAIL PROTECTED]> wrote:
>
>> The attached patch is a first pass at getting some support for using
>> openssl directly for ssl socket
Justin Erenkrantz wrote:
> On 6/13/06, david reid <[EMAIL PROTECTED]> wrote:
>> +static int sslInit = 0;
>> +
>> +static void initOpenSSL(void)
>> +{
>> +SSL_library_init();
>> +OpenSSL_add_all_algorithms();
>> +OpenSS
Jeff Trawick wrote:
> On 6/14/06, Jeff Trawick <[EMAIL PROTECTED]> wrote:
>> On 6/13/06, david reid <[EMAIL PROTECTED]> wrote:
>> > The attached patch is a first pass at getting some support for using
>> > openssl directly for ssl sockets within APR. I'
William A. Rowe, Jr. wrote:
> david reid wrote:
>> William A. Rowe, Jr. wrote:
>>
>>>
>>> I'm doing some similar work, not for sockets, but to scratch apr's
>>> implementation of hashing, etc from the library. Your ssl detection
>>> loo
William A. Rowe, Jr. wrote:
> Garrett Rooney wrote:
>> On 6/13/06, david reid <[EMAIL PROTECTED]> wrote:
>>
>>> The attached patch is a first pass at getting some support for using
>>> openssl directly for ssl sockets within APR. I've tried to be gene
The attached patch is a first pass at getting some support for using
openssl directly for ssl sockets within APR. I've tried to be generic in
the basic configure code, but the actaul guts are basically openssl related.
Disclaimer - this is based on some code I had written a while back and
never re
Mladen Turk wrote:
> Garrett Rooney wrote:
>
>>>
>>> URL: http://svn.apache.org/viewcvs?rev=368769&view=rev
>>> Log:
>>> Mark pool param for apr_file_remove and apr_file_rename
>>> as unused (because it is).
>>> Perhaps some day it will be removed from the API.
>>
>>
>> I'm not sure how I feel abo
If we find mysql.h as mysql/mysql.h then isn't there a good chance that
the library will be in mysql/libmysqlclient_r.so?
It is on my FreeBSD system...
david
Small patch that allows you to do silly things like
./configure --with-apr=srclib/apr --with-apr-util=srclib/apr-util
in httpd. Was useful for me, so who knows, someone else might find it
useful.
david
Index: srclib/apr/build/find_apr.m4
=
Colm MacCarthaigh wrote:
> On Sat, Nov 12, 2005 at 12:36:46PM +0000, David Reid wrote:
>
>>>This is going to need maintaining, not much, but over time, things will
>>>have to be changed. Not having it live in ASF svn would be a real pain.
>>>Is PD material current
Joe Orton wrote:
> On Fri, Nov 04, 2005 at 10:32:25PM +0000, David Reid wrote:
>
>>On helio.a.o IP addresses in the log have their last 2 parts repeated
>>and appended, so 24.5.108.151 gets shown as
>>
>>Client IP: 24.5.108.151108.151
>
>
> Can you run
Colm MacCarthaigh wrote:
> On Tue, Nov 08, 2005 at 02:57:09PM -0800, Justin Erenkrantz wrote:
>
>>I'd prefer that such an 'example' bundle be distributed separately from
>>APR, but it can be referred to in our release notes and on the website.
I'm very much +1 for this, but agree with Justin.
David Reid wrote:
> Colm MacCarthaigh wrote:
>
>>On Fri, Nov 04, 2005 at 10:32:25PM +, David Reid wrote:
>>
>>
>>>On helio.a.o IP addresses in the log have their last 2 parts repeated
>>>and appended, so 24.5.108.151 gets shown as
>>>
>>
Colm MacCarthaigh wrote:
> On Fri, Nov 04, 2005 at 10:32:25PM +0000, David Reid wrote:
>
>>On helio.a.o IP addresses in the log have their last 2 parts repeated
>>and appended, so 24.5.108.151 gets shown as
>>
>>Client IP: 24.5.108.151108.151
>>
>>I&#x
On helio.a.o IP addresses in the log have their last 2 parts repeated
and appended, so 24.5.108.151 gets shown as
Client IP: 24.5.108.151108.151
I'm guessing it's a 64-bit thing but while not fatal we should try and
fix it.
I'll try and run the tests to see if it shows up there unless anyone can
Justin Erenkrantz wrote:
--On Monday, March 7, 2005 10:47 PM -0600 "William A. Rowe, Jr."
<[EMAIL PROTECTED]> wrote:
I'd committed a patch to fix the version resource tag, it seems
we were broken when trying to build non-dev flavors of the .dll's.
What's consensus? Do we make the next release 1.
Jim Jagielski wrote:
Nick Kew wrote:
On Saturday 05 February 2005 21:15, David Reid wrote:
They do seem, as an organisation, to be quite well aware that
restricting their "reach" by licensing isn't helpful and therefore seem
qilling to talk about exceptions and different clauses,
Justin Erenkrantz wrote:
On Sat, Feb 05, 2005 at 11:07:20AM +, Nick Kew wrote:
I don't know if MySQL's exception for open source projects would cover us.
I'm not really happy with it: it looks to me like a potential torpedo under
the whole of MySQL's GPL licensing. It also raises ugly question
I was planning to copy this to [EMAIL PROTECTED], but their website just has a
contact form rather than any useful address, so I'm going to have to point
them to this post instead:-(
I'd have thought this was a sensible plan and hopefully someone here
know someone?
david
Garrett Rooney wrote:
Nick Kew wrote:
The apr_dbd code I posted a few days ago is in 'classic' APR shape.
Like, for example, apr_dbm, it allows different backends to be
configured or omitted, but only at build time.
This seems like the correct way to go.
I don't have APR karma, so I'm spared havin
Joe Orton wrote:
I'd like to propose also to drop autoconf 2.13 support on the trunk.
+1 from me
Mladen Turk wrote:
David Reid wrote:
>
> Thanks. Anyone from the world of windows care to comment...
>
Here are some windows comments :) .
Mladen - please don't take this personally - it's not directed at you
directly.
I had to go for a short break and count to ten before r
Justin Erenkrantz wrote:
--On Thursday, August 26, 2004 9:09 AM +0100 David Reid
<[EMAIL PROTECTED]> wrote:
new apr-util tarballs are now available at http://www.apache.org/~dreid/
So far I've seen only 1 +1 for a release. Anyone else care to vote?
+1. Passes testall for both apr a
new apr-util tarballs are now available at http://www.apache.org/~dreid/
So far I've seen only 1 +1 for a release. Anyone else care to vote?
david
Brad Nicholes wrote:
It doesn't build on NetWare either for the same reason that Graham
described.
OK. Well I'm gonna adjust the tags and then re-roll RC6. I'm not gonna
go to RC7 for this...
I'll post when the revised tarballs have replaced the old ones.
david
Brad
Brad Nicholes
Senior Softwa
http://www.apache.org/~dreid/
Test and let me know...
I'm away until Saturday, so the planned date is to roll it at the
weekend (Saturday pm).
Can people try to test things as far as they can by then? I'd *really*
like this to be the last one!
david
Justin Erenkrantz wrote:
--On Monday, August 9, 2004 12:36 PM +0100 David Reid
<[EMAIL PROTECTED]> wrote:
So, apart from the complaints about apr-util, are people happy that
apr RC5
is OK?
Releasing 1.0 with the known fact that autoconf-2.13 doesn't work with
find_apr.m4 seems fine
So, apart from the complaints about apr-util, are people happy that apr
RC5 is OK?
Are those who wanted the ldap code yanked now happy that it can be added
back in?
david
Justin Erenkrantz wrote:
--On Saturday, August 7, 2004 1:44 PM +1000 Brian Havard
<[EMAIL PROTECTED]> wrote:
The 2.13 macro is actually AC_MSG_WARN but when I tried using that it
still
failed while it was contained in the m4_if. Moving the line out of the
m4_if, having the $0 in there seems to c
Justin Erenkrantz wrote:
--On Tuesday, August 3, 2004 11:31 AM +0100 David Reid
<[EMAIL PROTECTED]> wrote:
Well, after what seems an eternity, RC5 is finally available.
I have changed the version files for HEAD in all 3 repositories to be
1.0.1-dev and the version files are tagged to g
Well, after what seems an eternity, RC5 is finally available.
I have changed the version files for HEAD in all 3 repositories to be
1.0.1-dev and the version files are tagged to give us 1.0.0.
APR has a lot of bumps and now includes the kpoll code (managing the
versions to include the other chan
Graham Leggett wrote:
William A. Rowe, Jr. wrote:
I would be +1 to simply remove auth_ldap from APR 1.0, and reintroduce
the entire feature in the new APR 1.1 (which we can start development
on immediately.) And that presumes httpd 2.1/2.2 will depend on the
1.1 release of apr-util.
I hate to hold
Justin Erenkrantz wrote:
--On Friday, July 30, 2004 8:33 AM -0400 Ryan Bloom <[EMAIL PROTECTED]>
wrote:
However, we need to remove the APR_STATUS_IS_SUCCESS macro before 1.0
goes
out, because otherwise we are stuck with it for a very long time.
It's gone now. ;-)
So I see. I'll tag & roll APR
from Brane? Is someone going to commit the
changes needed?
david
Ryan
On Fri, 30 Jul 2004 11:29:14 +0100, Max Bowsher <[EMAIL PROTECTED]> wrote:
David Reid wrote:
The whole "release 1.0" movement seems to have run out of steam, so I
propose that I'll just T&R what
The whole "release 1.0" movement seems to have run out of steam, so I
propose that I'll just T&R what we have as RC5 and then if it works
everywhere it'll be 1.0.0.
Personally I think that releasing without the apr-config stuff in place
would be a mistake, but there seem to be too many people r
Bill Stoddard wrote:
Justin Erenkrantz wrote:
--On Thursday, July 22, 2004 7:30 AM -0400 Jeff Trawick
<[EMAIL PROTECTED]> wrote:
On a slightly more interesting note, I committed something to APR HEAD
a few days ago and was faced with the question "darn, under what APR
release number do I put the
So, where do we stand on the config patches?
I'm holding off on RC5 until we get a solution in place, but I REALLY
don't want to wait more than another day or so...
david
> Joe Orton wrote:
> > On Wed, Jul 14, 2004 at 04:12:29PM +0100, Max Bowsher wrote:
> >> David Reid wrote:
> >>> Tarballs available at http://www.apache.org/~dreid/
> >>>
> >>> Test & report!
> >>
> >> RC4 is still inst
> --On Tuesday, July 13, 2004 8:32 PM -0700 Paul Querna
<[EMAIL PROTECTED]>
> wrote:
>
> > Failed on FreeBSD 5.2.1-p7:
> > When '--enable-threads' is passed, the final shared object does not link
> > against libc_r:
> >
> > $ ldd .libs/libapr-1.so.0
> > .libs/libapr-1.so.0:
> > libcryp
Tarballs available at http://www.apache.org/~dreid/
Test & report!
david
cvs server: Tagging memory
cvs server: Tagging memory/unix
cvs server: [10:35:56] waiting for brianp's lock in
/home/cvs/apr/memory/unix
cvs server: [10:36:26] waiting for brianp's lock in
/home/cvs/apr/memory/unix
cvs server: [10:36:56] waiting for brianp's lock in
/home/cvs/apr/memory/unix
cvs se
> On Mon, Jul 12, 2004 at 04:38:52PM +0100, David Reid wrote:
> > > David Reid wrote:
> > > I see that the changes to buildconf that add the version to the
specfile
> > > are missing - can you fix the tag on ./buildconf?
> >
> > I can do. That'll ne
> David Reid wrote:
>
> > So, tagged & rolled RC3 :-)
> >
> > I didn't include jlibtool.
> > Nor did I include the recent FreeBSD poll changes as I don't think we've
> > quite gotten the changes far enough to amke them suitable for a 1.
> So, tagged & rolled RC3 :-)
Any feedback?
Aim is to produce "final" 1.0 this week...
david
So, tagged & rolled RC3 :-)
I didn't include jlibtool.
Nor did I include the recent FreeBSD poll changes as I don't think we've
quite gotten the changes far enough to amke them suitable for a 1.0.0
release.
I removed the tag from the renames-pending file as I didn't think that
should really be in
I tagged RC2 as RC3 prior to going away, and will be aiming to bump the tag
on those files that need it. However, having waited there has been yet
another flurry of activity...so what files do people *think* I should be
tagging as RC3 that don't presently have the tag ? :-)
I'll aim to tag/roll la
> David Reid wrote:
>
> >Will: are you now happy and will you commit the change to stop installing
> >the header files for apr-iconv? That seems to be all we need to do
initially
> >to make it a private interface.
> >
> >
> I just committed a chan
1 - 100 of 398 matches
Mail list logo
