Re: expat removed from APR project (Re: [VOTE] Release Apache httpd 2.4.28 as GA)

2017-10-02 Thread William A Rowe Jr 
On Thu, Sep 28, 2017 at 10:57 PM, Greg Stein  wrote:
> On Wed, Sep 27, 2017 at 12:10 PM, William A Rowe Jr 
> wrote:
>>...
>>
>> After deeper consideration, this was fundamentally wrong.
>>
>> For those less familiar with the Win32 build, we failed to decouple
>> a "project" called "xml" which was, in fact, our idea of how expat
>> should be built.
>
> Strictly speaking, the xml module is an API that creates a memory-efficient
> DOM of an XML document, so that mod_dav could easily consume it. The API
> originated from mod_dav's needs.
>
> Another way to view it, is that Expat is a streaming/callback model, but
> mod_dav needed a random-access model. The xml code and API is that bridge.

Actually, you are confusing the xml win32 project that is a specific
build of the old
1.95 expat for static linkage with the apr_xml_*() API... so the 'xml'
project that
had to go away was the one in conflict with the expat 2.2.x project.
Think in terms
of using the 12 year old autoconf/makefile.in on an n+1 release of any library.

>> Already, apr-util has crypto libs, dbm providers, dbd providers, all
>> but one are external libraries maintained by external groups with
>> their own recommended build mechansims.
>
> More background: Expat *source* was added to the apr-util library back in
> 1999 or 2000 or somesuch. At the time, the library wasn't normally packaged
> and easily available. The choice was made to include it, to help downstream
> users in a "batteries included" form, but have enough autoconf magic to also
> use a pre-installed Expat package.

... as well as our own expat .dsp files for dynamic and static
linkage, to mirror
what we were doing for apr and httpd. Back in those days, there wasn't great
windows build support for expat on win32.

> Nowadays, it makes no sense to keep carrying around the Expat source.
>
> Regarding whether to use Expat and/or libxml under the API covers ... I
> don't have any insight or opinion on that. ... I just have insight on the
> API and Expat's presence cuz, well, it's my fault :-)

And mine - for the win32 schema.

One more important note, AIUI subversion still requires direct access to the
expat API, at this time libxml2 would not be a drop-in-replacement for the
mod_dav_svn and other binaries from the subversion project.

Unless I'm misunderstanding that state of affairs?

buildbot success in on apr-trunk

2017-10-02 Thread buildbot 
The Buildbot has detected a restored build on builder apr-trunk while building 
. Full details are available at:
https://ci.apache.org/builders/apr-trunk/builds/169

Buildbot URL: https://ci.apache.org/

Buildslave for this Build: orcus_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 'on-apr-commit' triggered 
this build
Build Source Stamp: [branch apr/apr/trunk] 1810452
Blamelist: jim

Build succeeded!

Sincerely,
 -The Buildbot

buildbot failure in on apr-trunk

2017-10-02 Thread buildbot 
The Buildbot has detected a new failure on builder apr-trunk while building . 
Full details are available at:
https://ci.apache.org/builders/apr-trunk/builds/168

Buildbot URL: https://ci.apache.org/

Buildslave for this Build: orcus_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 'on-apr-commit' triggered 
this build
Build Source Stamp: [branch apr/apr/trunk] 1810450
Blamelist: jim

BUILD FAILED: failed Configure

Sincerely,
 -The Buildbot

buildbot failure in on apr-x64-macosx-trunk

2017-10-02 Thread buildbot 
The Buildbot has detected a new failure on builder apr-x64-macosx-trunk while 
building . Full details are available at:
https://ci.apache.org/builders/apr-x64-macosx-trunk/builds/40

Buildbot URL: https://ci.apache.org/

Buildslave for this Build: svn-x64-macosx-dgvrs

Build Reason: The AnyBranchScheduler scheduler named 'on-apr-commit' triggered 
this build
Build Source Stamp: [branch apr/apr/trunk] 1810450
Blamelist: jim

BUILD FAILED: failed Build

Sincerely,
 -The Buildbot