Re: [Vote] apr-iconv-1.1.1 candidate

[Garrett Rooney <ro...@electricjellyfish.net>]

On 10/3/05, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
> Ping(!)
>
> We have enough votes for 0.9.7 apr[-util/-iconv] and 1.2.2 apr[-util].
>
> Two more eyes on apr-iconv 1.1.1 are appreciated, since I would like to
> release all six candidates today (with an announce tommorrow after the
> mirrors have caught up.)

I just gave this a shot on RHEL 4, and ran into two problems.  First,
the headers don't seem to get installed by make install, which makes
it kind of hard to actually build software that uses apr-iconv. 
Second, I can't actually seem to make apr-util use apr-iconv in
preference to the system iconv support, so I can't really tell if it
works or not.  It does seem to build ok though, and the
APR_ICONV1_PATH change seems reasonable to me.

-garrett

Re: [Vote] apr-iconv-1.1.1 candidate

[Garrett Rooney <ro...@electricjellyfish.net>]

On 11/11/05, Garrett Rooney <ro...@electricjellyfish.net> wrote:

> I just gave this a shot on RHEL 4, and ran into two problems.  First,
> the headers don't seem to get installed by make install, which makes
> it kind of hard to actually build software that uses apr-iconv.
> Second, I can't actually seem to make apr-util use apr-iconv in
> preference to the system iconv support, so I can't really tell if it
> works or not.  It does seem to build ok though, and the
> APR_ICONV1_PATH change seems reasonable to me.

Actually, one more thing.  It seems to still be installing
libapriconv.so, not libapriconv-1.so, that doesn't seem right...

-garrett

Re: [Vote] apr-iconv-1.1.1 candidate

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

Thanks Garrett, that's 2.  Need a third before I roll a 2.1 beta binary of
httpd - any takers?

Garrett Rooney wrote:
> On 11/11/05, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
> 
> 
>>Thanks.  Is that a vote +/-1 or +/-0 for 1.1.1?  Obviously it's worth addressing
>>the items you pointed out which were broken since 1.0.0.
> 
> 
> If the problems have been there since 1.0.0, then consider this a +1,
> since the release seems like a clear improvement over the previous
> version.  We can always correct the remaining issues in the next
> release.
> 
> -garrett

Re: [Vote] apr-iconv-1.1.1 candidate

[Garrett Rooney <ro...@electricjellyfish.net>]

On 11/11/05, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:

> Thanks.  Is that a vote +/-1 or +/-0 for 1.1.1?  Obviously it's worth addressing
> the items you pointed out which were broken since 1.0.0.

If the problems have been there since 1.0.0, then consider this a +1,
since the release seems like a clear improvement over the previous
version.  We can always correct the remaining issues in the next
release.

-garrett

Re: [Vote] apr-iconv-1.1.1 candidate

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

Garrett Rooney wrote:
> On 10/3/05, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
> 
>>Two more eyes on apr-iconv 1.1.1 are appreciated, since I would like to
>>release all six candidates today (with an announce tommorrow after the
>>mirrors have caught up.)
> 
> I just gave this a shot on RHEL 4, and ran into two problems.  First,
> the headers don't seem to get installed by make install, which makes
> it kind of hard to actually build software that uses apr-iconv. 

Yup, apr-util is picky about finding them in-path or in ../apr-iconv, which
does suck.  We voted earlier that apriconv is an internal artifact of aprutil,
but suppose it does no harm to install that header file (if they want to use
whatever 'final release' of apriconv-1 until the end of time, even after we
find better solutions for apr_xlate, why hinder?)

> Second, I can't actually seem to make apr-util use apr-iconv in
> preference to the system iconv support, so I can't really tell if it
> works or not.  It does seem to build ok though, and the
> APR_ICONV1_PATH change seems reasonable to me.

Thanks.  Is that a vote +/-1 or +/-0 for 1.1.1?  Obviously it's worth addressing
the items you pointed out which were broken since 1.0.0.

One more note, libapriconv-1.so on unix is the correct name, but we create
libapriconv.so instead.  This is wrong, and really needs to be cleaned up in
any 1.2.0 release in the future (it needs a minor bump at least in the process
of correcting the flaw.)

Bill