You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by William A Rowe Jr <wr...@rowe-clan.net> on 2017/10/18 14:58:59 UTC
[Vote] apr-1.6.3, apr-util-1.6.1, apr-iconv-1.2.2 releases
Please cast your votes on the following candidate packages;
Release apr-1.6.3
[ ] +1 looks good
[ ] +/-0 since
[ ] -1 because
Release apr-util-1.6.1
[ ] +1 looks good
[ ] +/-0 since
[ ] -1 because
Release apr-iconv-1.2.2
[ ] +1 looks good
[ ] +/-0 since
[ ] -1 because
Note that Visual Studio 2015, at least, broke the apr-iconv build
altogether so it is overdue a refresh. I understand few here build
on windows, and fewer still don't swap apr-iconv out for libiconv.
Since this is a supported build combination for apr-util-1.6.1, please
offer to review to get us to 3 PMC voters.
Re: [Vote] apr-1.6.3, apr-util-1.6.1, apr-iconv-1.2.2 releases
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Wed, Oct 18, 2017 at 9:58 AM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
> Please cast your votes on the following candidate packages;
>
> Release apr-1.6.3
[ X ] +1 looks good
All good, reviewed on 3x flavors linux and Windows testing httpd 2.4.29
> Release apr-util-1.6.1
> [ ] +1 looks good
[ X ] +1 looks good
Mostly good, reviewed on 3x flavors linux and Windows testing httpd
2.4.29. Some Windows build needs further enhancement which can be
captured as 1.6.2, and some of us Windows folks are excited to
substitute libxml2 for expat in 1.7.0.
> Release apr-iconv-1.2.2
[ X ] +1 looks good
All good, reviewed on 3x flavors linux and Windows testing httpd
2.4.29 (and we have sufficient voters, TY folks!)
Re: [Vote] apr-1.6.3, apr-util-1.6.1, apr-iconv-1.2.2 releases
Posted by Michal Karm <mi...@gmail.com>.
On 10/18/2017 11:13 PM, Gregg Smith wrote:
> On 10/18/2017 7:58 AM, William A Rowe Jr wrote:
>> Please cast your votes on the following candidate packages;
>
> I'm not there to vote yet, my question is how did you expect us to build APU
> with a precompiled lib and this lib put where?
>
> Looking at both makafile.win and libaprutil.mak I see not much for pointers
> here. I see an include of ./xml/expat/lib in libaprutil.mak so do I really
> have to put expat in the xml folder? Seem it should be outside the apr-util
> folder so the include would be like /I ../expat/lib
>
> Further, no /libpath: pointing to where libexpat.lib is grabbed from at apu's
> linking. I don't remember vc ever being that smart to just find it, it knew it
> was in ./xml/libR because that's where it put xml.lib, which we don't have
> anymore.
>
> cmake -G "NMake Makefiles" -DCMAKE_BUILD_TYPE=Release -DBUILD_shared=OFF
> gives me an expat.lib, not libexpat.lib, so unless I'm missing something
> really obvious that's right under my nose, I don't get it :)
This works for me as far as expat goes (NSS tests prolem in another thread):
https://github.com/modcluster/ci.modcluster.io/blob/6a01bf9f015224271078336eebab4e258b8f9196/windows/apr-util/build.bat#L24
expat is built here:
https://ci.modcluster.io/job/libexpat-windows/17/label=w2k12r2/consoleText
by https://github.com/modcluster/ci.modcluster.io/tree/master/windows/libexpat
Cheers
-K-
>
>
Michal Karm Babacek
--
Sent from my Hosaka Ono-Sendai Cyberspace 7
Re: [Vote] apr-1.6.3, apr-util-1.6.1, apr-iconv-1.2.2 releases
Posted by Gregg Smith <gl...@gknw.net>.
On 10/19/2017 1:49 PM, Gregg Smith wrote:
> Now, seeing Steffen's problems and what Michal had to go through to get
> this to build for him, so I'm -1 with apu 1.6.1.
Sorry, I meant -0 as I'm not going to stop this from going out. I am
still quite unhappy this was done midstream.
I'll personally revert this portion in my copy till it gets working and
publish a patch somewhere for others that don't want to deal with this
headache.
Re: [Vote] apr-1.6.3, apr-util-1.6.1, apr-iconv-1.2.2 releases
Posted by Gregg Smith <gl...@gknw.net>.
On 10/18/2017 7:41 PM, William A Rowe Jr wrote:
> Two additional footnotes...
>
> On Wed, Oct 18, 2017 at 4:13 PM, Gregg Smith <gl...@gknw.net> wrote:
>> On 10/18/2017 7:58 AM, William A Rowe Jr wrote:
>>>
>>> Please cast your votes on the following candidate packages;
>>
>>
>> I'm not there to vote yet, my question is how did you expect us to build APU
>> with a precompiled lib and this lib put where?
>
> That was addressed in my first response...\
No, you told me to see CHANGES and makefile.win. If you had really read
what I said you would have realized I already did, at least makefile.win
which didn't give me any clues, nor did CHANGES.
*) Win32: Introduce XML_PARSER build-time variable to select the expat
library name to be linked to libaprutil-1.dll. See Makefile.win
*) Win32: Removed lingering xml/xml.dsp project forked from the expat
Project in the 1.9x era. Use expat's maintained build schema instead,
prior to building apr-util.
It's big info is look at makafile.win which I did, and stated such from
the beginning, see the first quoted line below
.
>
>> Looking at both makafile.win and libaprutil.mak I see not much for pointers
>> here. I see an include of ./xml/expat/lib in libaprutil.mak so do I really
>> have to put expat in the xml folder? Seem it should be outside the apr-util
>> folder so the include would be like /I ../expat/lib
>
> I am 100% in agreement that moving forwards, we suggest a path of
> ../expat/ vs expecting anyone to embed some other project's sources
> deep within ./xml/expat - that seems absurd. OTOH for those doing
> so, I don't think we need to break them...
>
You should have done this now. You've already upset the flow so just
take it all the way. This is why I was against this in the first place
and said this should not be done till 1.7, regardless of said "promise,"
we should just say opps, sorry and move forward with 1.7 where we will
promise again yet have something in svn showing just that so it's not
another hollow promise.
>> Further, no /libpath: pointing to where libexpat.lib is grabbed from at
>> apu's linking. I don't remember vc ever being that smart to just find it, it
>> knew it was in ./xml/libR because that's where it put xml.lib, which we
>> don't have anymore.
>
> Adding doubled /I /LIBPATH "default" options isn't silly, it's actually a
> good idea... with that said...
As I said, there is "no /LIBPATH present" so how is it even doubled? VC
cannot find the lib. So what your saying here is silly.
>
>> cmake -G "NMake Makefiles" -DCMAKE_BUILD_TYPE=Release -DBUILD_shared=OFF
>> gives me an expat.lib, not libexpat.lib, so unless I'm missing something
>> really obvious that's right under my nose, I don't get it :)
>
> As I pointed out in the prior email, there is resolution logic already within
> the cmake model. If there are bugs, we should send those upstream.
There's no bug that I know of upstream.
>
> My own build model is one component at a time, never changing the LIB
> or INCLUDE path, but just layering one by one by one. Pretty much like
> every *nix environment out there. At minimum, cmake can resolve this if
> the LIB and INCLUDE path point to this target.
>
This ain't Unix and I'm tired of that rationale.
> When we first started debating, we hotly contested whether an expat
> xml.dsp project belonged in the apr-util tree, after APR PMC voted to
> expel this component from our own maintenance. I understood the pain
> of extracting this and have always invited dialog and participation about
> the resolution of this unsustainable situation.
>
> If you have more and better ideas to offer, that DON'T involve this
> project substituting its logic for the expat project's logic, please bring
> them here, I'm all ears.
>
I did in the beginning, leave as is and do whatever your heart desires
in 1.7. Even go as far and ask the others to put there attention to 1.7
instead of 1.6.
I told you off-list I wasn't going to have a veto war with you but this
is rediculous and I am really tempted to back out on that and veto this
mess.
Other things of note. XML_PARSER=libxml doesn't get to libaprutil.mak, I
get an error about ".lib," meaning it didn't get passed (even though it
does with $(XMLOPTS), VC just doesn't do it. I believe this is the
reason I just sent a flag from .win to the .mak files and repeated the
THIS=that in the .maks for OpenSSL 1.1.0.
Now, seeing Steffen's problems and what Michal had to go through to get
this to build for him, so I'm -1 with apu 1.6.1.
If you want to continue down this road then I ask you to create a
readme.win file explaining what us stupid people need to do, how you
expect us to build expat (so someone doesn't foolishly think they can
build it with cmake as I did) and where to place it before we start the
apu build, fix the makefiles and as Steffen suggested, do something with
cvtdsp.pl to handle the change to the .dsps (too bad cvtdsp's in apr).
I didn't pay much attention to apr or apr-iconv but since both get built
before apu IIRC I'll have a look and vote on those.
Re: [Vote] apr-1.6.3, apr-util-1.6.1, apr-iconv-1.2.2 releases
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
Two additional footnotes...
On Wed, Oct 18, 2017 at 4:13 PM, Gregg Smith <gl...@gknw.net> wrote:
> On 10/18/2017 7:58 AM, William A Rowe Jr wrote:
>>
>> Please cast your votes on the following candidate packages;
>
>
> I'm not there to vote yet, my question is how did you expect us to build APU
> with a precompiled lib and this lib put where?
That was addressed in my first response...
> Looking at both makafile.win and libaprutil.mak I see not much for pointers
> here. I see an include of ./xml/expat/lib in libaprutil.mak so do I really
> have to put expat in the xml folder? Seem it should be outside the apr-util
> folder so the include would be like /I ../expat/lib
I am 100% in agreement that moving forwards, we suggest a path of
../expat/ vs expecting anyone to embed some other project's sources
deep within ./xml/expat - that seems absurd. OTOH for those doing
so, I don't think we need to break them...
> Further, no /libpath: pointing to where libexpat.lib is grabbed from at
> apu's linking. I don't remember vc ever being that smart to just find it, it
> knew it was in ./xml/libR because that's where it put xml.lib, which we
> don't have anymore.
Adding doubled /I /LIBPATH "default" options isn't silly, it's actually a
good idea... with that said...
> cmake -G "NMake Makefiles" -DCMAKE_BUILD_TYPE=Release -DBUILD_shared=OFF
> gives me an expat.lib, not libexpat.lib, so unless I'm missing something
> really obvious that's right under my nose, I don't get it :)
As I pointed out in the prior email, there is resolution logic already within
the cmake model. If there are bugs, we should send those upstream.
My own build model is one component at a time, never changing the LIB
or INCLUDE path, but just layering one by one by one. Pretty much like
every *nix environment out there. At minimum, cmake can resolve this if
the LIB and INCLUDE path point to this target.
When we first started debating, we hotly contested whether an expat
xml.dsp project belonged in the apr-util tree, after APR PMC voted to
expel this component from our own maintenance. I understood the pain
of extracting this and have always invited dialog and participation about
the resolution of this unsustainable situation.
If you have more and better ideas to offer, that DON'T involve this
project substituting its logic for the expat project's logic, please bring
them here, I'm all ears.
Re: [Vote] apr-1.6.3, apr-util-1.6.1, apr-iconv-1.2.2 releases
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
See CHANGES, which points you to the contents of Makefile.win which
documents a new variable pointed out in CHANGES, XML_PARSER,
which is the name of whatever library you like.
As documented everywhere, if you want to use dbm or dbd or openssl
linkages, you add these to the INCLUDE and LIB paths for any microsoft
toolchain component, this hasn't changed in 30 years.
For the cmake build specifically, we do try to add the expat path, we will
simply trust cmake. See your FindEXPAT.* files in your cmake tree on
that feature set and detection options.
On Wed, Oct 18, 2017 at 4:13 PM, Gregg Smith <gl...@gknw.net> wrote:
> On 10/18/2017 7:58 AM, William A Rowe Jr wrote:
>>
>> Please cast your votes on the following candidate packages;
>
>
> I'm not there to vote yet, my question is how did you expect us to build APU
> with a precompiled lib and this lib put where?
>
> Looking at both makafile.win and libaprutil.mak I see not much for pointers
> here. I see an include of ./xml/expat/lib in libaprutil.mak so do I really
> have to put expat in the xml folder? Seem it should be outside the apr-util
> folder so the include would be like /I ../expat/lib
>
> Further, no /libpath: pointing to where libexpat.lib is grabbed from at
> apu's linking. I don't remember vc ever being that smart to just find it, it
> knew it was in ./xml/libR because that's where it put xml.lib, which we
> don't have anymore.
>
> cmake -G "NMake Makefiles" -DCMAKE_BUILD_TYPE=Release -DBUILD_shared=OFF
> gives me an expat.lib, not libexpat.lib, so unless I'm missing something
> really obvious that's right under my nose, I don't get it :)
>
Re: [Vote] apr-1.6.3, apr-util-1.6.1, apr-iconv-1.2.2 releases
Posted by Steffen <in...@apachelounge.com>.
I put in under the xml folder.
To get libexpat.lib double click the included lib/expat.vcxproj and convert it.
Build expat
The .dll and lib is created in expat/win32/bin
To reduce the size of the libexpat.dll set in properties/linker/debugging/generate debug info to No.
For the C99 issue with VC11, see www.apachelounge.com/viewtopic.php?t=7777
Found glitches in the libaprutil.dsp
- Missing in line LINK the path to libexpat.dll: /libpath:"..\..\srclib\apr-util\xml\expat/lib
- With converting the libaprutil.dsp to a .vcxproj the $(XML_PARSER) is not filled in:
....<AdditionalDependencies>$(XML_PARSER).lib;ws2_32.lib;mswsock.lib;........
Adding XML_PARSER=libexpat to the .dsp does not help, so replaced $(XML_PARSER) with libexpat.
Only solution I see, is to add to apr cvtdsp.pl the parser to be used by replacing $(XML_PARSER).
Did not build with cmake and .mak files.
For the time being I stick with the former xml build, I see no advantage.
> Op 18 okt. 2017 om 23:13 heeft Gregg Smith <gl...@gknw.net> het volgende geschreven:
>
>> On 10/18/2017 7:58 AM, William A Rowe Jr wrote:
>> Please cast your votes on the following candidate packages;
>
> I'm not there to vote yet, my question is how did you expect us to build APU with a precompiled lib and this lib put where?
>
> Looking at both makafile.win and libaprutil.mak I see not much for pointers here. I see an include of ./xml/expat/lib in libaprutil.mak so do I really have to put expat in the xml folder? Seem it should be outside the apr-util folder so the include would be like /I ../expat/lib
>
> Further, no /libpath: pointing to where libexpat.lib is grabbed from at apu's linking. I don't remember vc ever being that smart to just find it, it knew it was in ./xml/libR because that's where it put xml.lib, which we don't have anymore.
>
> cmake -G "NMake Makefiles" -DCMAKE_BUILD_TYPE=Release -DBUILD_shared=OFF
> gives me an expat.lib, not libexpat.lib, so unless I'm missing something really obvious that's right under my nose, I don't get it :)
>
Re: [Vote] apr-1.6.3, apr-util-1.6.1, apr-iconv-1.2.2 releases
Posted by Gregg Smith <gl...@gknw.net>.
On 10/18/2017 7:58 AM, William A Rowe Jr wrote:
> Please cast your votes on the following candidate packages;
I'm not there to vote yet, my question is how did you expect us to build
APU with a precompiled lib and this lib put where?
Looking at both makafile.win and libaprutil.mak I see not much for
pointers here. I see an include of ./xml/expat/lib in libaprutil.mak so
do I really have to put expat in the xml folder? Seem it should be
outside the apr-util folder so the include would be like /I ../expat/lib
Further, no /libpath: pointing to where libexpat.lib is grabbed from at
apu's linking. I don't remember vc ever being that smart to just find
it, it knew it was in ./xml/libR because that's where it put xml.lib,
which we don't have anymore.
cmake -G "NMake Makefiles" -DCMAKE_BUILD_TYPE=Release -DBUILD_shared=OFF
gives me an expat.lib, not libexpat.lib, so unless I'm missing something
really obvious that's right under my nose, I don't get it :)
Re: [Vote] apr-1.6.3, apr-util-1.6.1, apr-iconv-1.2.2 releases
Posted by Nick Kew <ni...@apache.org>.
> On 18 Oct 2017, at 15:58, William A Rowe Jr <wr...@rowe-clan.net> wrote:
>
> Please cast your votes on the following candidate packages;
>
> Release apr-1.6.3
> [ ] +1 looks good
> [ ] +/-0 since
> [ ] -1 because
+1
>
> Release apr-util-1.6.1
> [ ] +1 looks good
> [ ] +/-0 since
> [ ] -1 because
+1
> Release apr-iconv-1.2.2
> [ ] +1 looks good
> [ ] +/-0 since
> [ ] -1 because
+0
Will revisit if this one stalls due solely to lack of votes.
Thanks for driving the release!
—
Nick Kew
Re: [Vote] apr-1.6.3, apr-util-1.6.1, apr-iconv-1.2.2 releases
Posted by Steffen <in...@apachelounge.com>.
Good to go all three on Windows.
Thanks Bill for RM, and the expat notes we can solve.
> Op 18 okt. 2017 om 16:58 heeft William A Rowe Jr <wr...@rowe-clan.net> het volgende geschreven:
>
> Please cast your votes on the following candidate packages;
>
> Release apr-1.6.3
> [ ] +1 looks good
> [ ] +/-0 since
> [ ] -1 because
>
> Release apr-util-1.6.1
> [ ] +1 looks good
> [ ] +/-0 since
> [ ] -1 because
>
> Release apr-iconv-1.2.2
> [ ] +1 looks good
> [ ] +/-0 since
> [ ] -1 because
>
>
> Note that Visual Studio 2015, at least, broke the apr-iconv build
> altogether so it is overdue a refresh. I understand few here build
> on windows, and fewer still don't swap apr-iconv out for libiconv.
> Since this is a supported build combination for apr-util-1.6.1, please
> offer to review to get us to 3 PMC voters.
Re: [Vote] apr-1.6.3, apr-util-1.6.1, apr-iconv-1.2.2 releases
Posted by Yann Ylavic <yl...@gmail.com>.
On Wed, Oct 18, 2017 at 4:58 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
>
> Release apr-1.6.3
[X] +1 looks good
>
> Release apr-util-1.6.1
[X] +1 looks good
>
> Release apr-iconv-1.2.2
[X] +1 looks good
Tested on debian(s).
Thanks Bill!
Re: [Vote] apr-1.6.3, apr-util-1.6.1, apr-iconv-1.2.2 releases
Posted by Rainer Jung <ra...@kippdata.de>.
Am 18.10.2017 um 16:58 schrieb William A Rowe Jr:
> Please cast your votes on the following candidate packages;
>
> Release apr-1.6.3
> [XX] +1 looks good
> [ ] +/-0 since
> [ ] -1 because
>
> Release apr-util-1.6.1
> [XX] +1 looks good
> [ ] +/-0 since
> [ ] -1 because
>
> Release apr-iconv-1.2.2
> [XX] +1 looks good
> [ ] +/-0 since
> [ ] -1 because
General comments:
- Announcement and changes download file not yet present for check.
- you might want to add your (sub?) key to the KEYS file
Detailed APR test results:
- files signed, checksums correct
- svn compared with gz, bz2 and zip only minor differences
(libtool m4 files in gz and bz2, which seem to not get
cleaned up by buildconf)
- I built and made check on the following platforms:
- Solaris 8 Sparc, gcc 4.1.2
- Solaris 10 Sparc, gcc 7.1.0
- SuSE Linux Enterprise 10 32, 10, 11 and 12 64 Bit
- RedHat Enterprise Linux 6 and 7 64 Bit
- config.guess timestamp='2017-09-16',
pretty much up-to-date
- config.sub timestamp='2017-09-16'
pretty much up-to-date
- all builds succeeded
- all "make check" ran fine, except for
- binding to ::1 on Solaris with only IPv4 active,
not a regression:
testsockets: Line 131: Could not bind socket (126):
Cannot assign requested address
Line 189: Condition is false, but expected true
FAILED 1 of 7
- Solaris 8 (not a regression):
testsock: Line 116: Problem generating sockaddr (670008):
host/servname not known
Segmentation Fault (coredump)
- Some warnings during "make check":
- Solaris 8+10 (not a regression)
testsock: Line 433: Cannot test if connect completes synchronously
SUCCESS
- Solaris 8+10, OK doesn't know how to cork
testsockopt: Line 84: TCP isn't corkable
SUCCESS
- Solaris 8, OK doesn't have "unsetenv"
testenv: Line 75: apr_env_delete
Line 106: apr_env (skip recycle test_emptyenv)
SUCCESS
- Solaris 8, OK doesn't support pollcb
testpoll: Line 584: pollcb interface not supported
Line 611: pollcb interface not supported
Line 637: pollcb interface not supported
Line 653: pollcb interface not supported
Line 836: pollcb interface not supported
Line 733: pollcb interface not supported
SUCCESS
- Linux only 64 Bits: OK, no LFS needed on 64 Bit OS
testlfs: Line 349: LFS support a no-op in 64-bit builds
SUCCESS
- tests succeed for apr-util 1.6.1 on top of apr 1.6.3
for all of the above platforms (all observed test failures
are old and not related to the new version).
Detailed APR-UTIL test results:
- svn compared with gz, bz2 and zip only expected differences
- files signed, checksums correct
- I built and made check on the following platforms:
- Solaris 8 Sparc, gcc 4.1.2
- Solaris 10 Sparc, gcc 7.1.0
- SuSE Linux Enterprise 10 32, 10, 11 and 12 64 Bit
- RedHat Enterprise Linux 6 and 7 64 Bit
- using all combinations of:
- apr 1.6.3
- expat 2.2.4
- OpenSSL 1.0.2l (plus some patches)
- dso disable / enable
- Berkeley DB 6.1.19
- sqlite 3.20.1
- mysql 6.1.10
- oracle 11.2.0.2.0 (Solaris 10), resp. 10.2.0.5.0 (Solaris 8)
- platform nss (Solaris 10 and RHEL 6)
- make check for all builds was successful
Detailed APR-ICONV test results:
- svn compared with gz, bz2 and zip only expected differences
- but autom4te.cache could probably be removed before packaging
tar.gz and tar.bz2
- files signed, checksums correct
- builds fine in combination with APR 1.6.3
- some compiler warnings
- no check/test make target
I did not actually try to use the build result.
Additional test info:
- httpd test framework looks good for httpd 2.4.29
using apr/apu 1.6.3/1.6.1 on Solaris 10, SLES 11+12 and RHEL 6+7
(reallyall module set, shared and static linking,
MPMs prefork, worker and event, log level trace8)
I need to give it a final look, details will follow on dev@httpd.
Thanks!
Rainer
Re: [Vote] apr-1.6.3, apr-util-1.6.1, apr-iconv-1.2.2 releases
Posted by Jim Jagielski <ji...@jaguNET.com>.
I've built and tested on macOS 10.12. All good.
+1 (binding)
Thx for RMing!
> On Oct 18, 2017, at 10:58 AM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
>
> Please cast your votes on the following candidate packages;
>
> Release apr-1.6.3
> [ ] +1 looks good
> [ ] +/-0 since
> [ ] -1 because
>
> Release apr-util-1.6.1
> [ ] +1 looks good
> [ ] +/-0 since
> [ ] -1 because
>
> Release apr-iconv-1.2.2
> [ ] +1 looks good
> [ ] +/-0 since
> [ ] -1 because
>
>
> Note that Visual Studio 2015, at least, broke the apr-iconv build
> altogether so it is overdue a refresh. I understand few here build
> on windows, and fewer still don't swap apr-iconv out for libiconv.
> Since this is a supported build combination for apr-util-1.6.1, please
> offer to review to get us to 3 PMC voters.
Re: [Vote] apr-1.6.3, apr-util-1.6.1, apr-iconv-1.2.2 releases
Posted by Nick Kew <ni...@apache.org>.
On Wed, 18 Oct 2017 09:58:59 -0500
William A Rowe Jr <wr...@rowe-clan.net> wrote:
> Please cast your votes on the following candidate packages;
>
> Release apr-1.6.3
> [ ] +1 looks good
> [ ] +/-0 since
> [ ] -1 because
All good on Linux. Pending testing on Mac and static
review of changes before my +1. Will complete review
tomorrow.
> Release apr-util-1.6.1
> [ ] +1 looks good
> [ ] +/-0 since
> [ ] -1 because
As above.
> Release apr-iconv-1.2.2
> [ ] +1 looks good
> [ ] +/-0 since
> [ ] -1 because
Wow! I don't think I've ever built or looked at
apr-iconv before. Builds successfully on Linux,
but since the issues you've dealt with concern
Windows, I'm not able to review them.
--
Nick Kew
Re: [Vote] apr-1.6.3, apr-util-1.6.1, apr-iconv-1.2.2 releases
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Wed, Oct 18, 2017 at 9:58 AM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
> Please cast your votes on the following candidate packages;
>
> Release apr-1.6.3
> [ ] +1 looks good
> [ ] +/-0 since
> [ ] -1 because
>
> Release apr-util-1.6.1
> [ ] +1 looks good
> [ ] +/-0 since
> [ ] -1 because
>
> Release apr-iconv-1.2.2
> [ ] +1 looks good
> [ ] +/-0 since
> [ ] -1 because
which may be found at http://apr.apache.org/dev/dist/
Re: [Vote] apr-1.6.3, apr-util-1.6.1, apr-iconv-1.2.2 releases
Posted by Noel Butler <no...@ausics.net>.
On 19/10/2017 00:58, William A Rowe Jr wrote:
> Please cast your votes on the following candidate packages;
>
> Release apr-1.6.3
> [ ] +1 looks good
> [ ] +/-0 since
> [ ] -1 because
>
> Release apr-util-1.6.1
> [ ] +1 looks good
> [ ] +/-0 since
> [ ] -1 because
These two all good used with include apr with httpd 2.4.29 on Slackware
> 13
--
Kind Regards,
Noel Butler
This Email, including any attachments, may contain legally privileged
information, therefore remains confidential and subject to copyright
protected under international law. You may not disseminate, discuss, or
reveal, any part, to anyone, without the authors express written
authority to do so. If you are not the intended recipient, please notify
the sender then delete all copies of this message including attachments,
immediately. Confidentiality, copyright, and legal privilege are not
waived or lost by reason of the mistaken delivery of this message. Only
PDF [1] and ODF [2] documents accepted, please do not send proprietary
formatted documents
Links:
------
[1] http://www.adobe.com/
[2] http://en.wikipedia.org/wiki/OpenDocument