Nabble - APR Dev (Apache Portable Runtime)

Re: svn commit: r891488 - in /apr/apr/trunk: build/aprenv.py build/apu-iconv.m4 configure.in include/apu.h.in include/apu.hnw include/apu.hw test/testxlate.c xlate/xlate.c

2009-12-17T09:57:24Z

On 17.12.2009 18:46, William A. Rowe Jr. wrote:

> Ruediger Pluem wrote:
>> On 17.12.2009 00:53, wrowe@... wrote:
>>> Author: wrowe
>>> Date: Wed Dec 16 23:53:16 2009
>>> New Revision: 891488
>
>> Please fix or revert.
>
> Will do. I presume you replaced with the immediate-prior rev of apu_config.h
> before your test?
>
>

yes.

Regards

Rüdiger

Re: svn commit: r891488 - in /apr/apr/trunk: build/aprenv.py build/apu-iconv.m4 configure.in include/apu.h.in include/apu.hnw include/apu.hw test/testxlate.c xlate/xlate.c

2009-12-17T09:46:25Z

Ruediger Pluem wrote:
> On 17.12.2009 00:53, wrowe@... wrote:
>> Author: wrowe
>> Date: Wed Dec 16 23:53:16 2009
>> New Revision: 891488

> Please fix or revert.

Will do. I presume you replaced with the immediate-prior rev of apu_config.h
before your test?

Re: svn commit: r891488 - in /apr/apr/trunk: build/aprenv.py build/apu-iconv.m4 configure.in include/apu.h.in include/apu.hnw include/apu.hw test/testxlate.c xlate/xlate.c

2009-12-17T09:22:46Z

On 17.12.2009 00:53, wrowe@... wrote:

> Author: wrowe
> Date: Wed Dec 16 23:53:16 2009
> New Revision: 891488
>
> URL: http://svn.apache.org/viewvc?rev=891488&view=rev
> Log:
> remove apr-iconv references; it was built upon apr so cannot exist before apr
>
> Modified:
> apr/apr/trunk/build/aprenv.py
> apr/apr/trunk/build/apu-iconv.m4
> apr/apr/trunk/configure.in
> apr/apr/trunk/include/apu.h.in
> apr/apr/trunk/include/apu.hnw
> apr/apr/trunk/include/apu.hw
> apr/apr/trunk/test/testxlate.c
> apr/apr/trunk/xlate/xlate.c
>

This breaks compilation of trunk.

In file included from crypto/apr_md4.c:42:
./include/apr_md4.h:74:5: error: token "@" is not valid in preprocessor expressions
./include/apr_md4.h:86:5: error: token "@" is not valid in preprocessor expressions
crypto/apr_md4.c:123:5: error: token "@" is not valid in preprocessor expressions
crypto/apr_md4.c:130:5: error: token "@" is not valid in preprocessor expressions
crypto/apr_md4.c:164:5: error: token "@" is not valid in preprocessor expressions
crypto/apr_md4.c:180:6: error: token "@" is not valid in preprocessor expressions
crypto/apr_md4.c: In function ‘apr_md4_update’:
crypto/apr_md4.c:197: error: ‘apr_md4_ctx_t’ has no member named ‘xlate’
crypto/apr_md4.c:198: error: ‘inbytes_left’ undeclared (first use in this function)
crypto/apr_md4.c:198: error: (Each undeclared identifier is reported only once
crypto/apr_md4.c:198: error: for each function it appears in.)
crypto/apr_md4.c:198: error: ‘outbytes_left’ undeclared (first use in this function)
crypto/apr_md4.c:199: error: ‘apr_md4_ctx_t’ has no member named ‘xlate’
crypto/apr_md4.c:210: error: ‘apr_md4_ctx_t’ has no member named ‘xlate’
crypto/apr_md4.c:213: error: ‘apr_md4_ctx_t’ has no member named ‘xlate’
crypto/apr_md4.c:229: error: ‘apr_md4_ctx_t’ has no member named ‘xlate’
crypto/apr_md4.c:231: error: ‘apr_md4_ctx_t’ has no member named ‘xlate’
crypto/apr_md4.c:255:5: error: token "@" is not valid in preprocessor expressions
make[3]: *** [crypto/apr_md4.lo] Fehler 1
make[3]: *** Warte auf noch nicht beendete Prozesse...
make[2]: *** [all-recursive] Fehler 1
make[1]: *** [all-recursive] Fehler 1
make: *** [all-recursive] Fehler 1

Please fix or revert.

Regards

Rüdiger

Re: svn commit: r891507 - /apr/apr/trunk/include/private/apu_config.h

2009-12-17T09:16:00Z

On 17.12.2009 02:20, wrowe@... wrote:

> Author: wrowe
> Date: Thu Dec 17 01:20:30 2009
> New Revision: 891507
>
> URL: http://svn.apache.org/viewvc?rev=891507&view=rev
> Log:
> This is a generated artifact, not to be checked in!
>
> Removed:
> apr/apr/trunk/include/private/apu_config.h
>
>

It does not seem to get generated and thus breaks compilation of trunk.
Please fix or revert.

Regards

Rüdiger

Re: APR library + Solaris 5.10 + 64bit problem

2009-12-16T10:17:19Z

On Wed, Dec 16, 2009 at 1:12 PM, Semyon <semyon.karev@...> wrote:
>
> It does not help, I also tryed APR 1.4.1 - it does not work

Post to the Tomcat users list perhaps?

I don't know how the native connector works, other than that it uses
some APR code that recently need fixes for Solaris. (And now you have
those fixes.)

>
>
> Jeff Trawick wrote:
>>
>> On Wed, Dec 16, 2009 at 11:55 AM, Semyon <semyon.karev@...> wrote:
>>
>>> I've got a problem after building native library for Tomcat.
>>> Settings:
>>> Tomcat 6.0.20
>>> APR 1.3.9
>>> JNI 1.1.16
>>> JDK 1.6_u17
>>> OS: SunOS 5.10 sparcv9
>>> compiler: gcc -m64
>>>
>>> It has built ok, and APR has gone all tests (gmake test). Tomcat starts
>>> well
>>> with APR libs. But when I'm trying to make HTTPS connection with server
>>> from
>>> firefox browser, I'm getting error like "Connection Interrupted". HTTP
>>> connection works well. I've tryed to use Internet Explorer 6 - it works
>>> well.
>>> I suppose that there is something wrong with 64bit build version, because
>>> before I built native library with 32bit and everything works well!
>>
>> You need some post-APR 1.3.9 fixes.
>>
>> Get the latest port.c from svn (or
>> http://svn.apache.org/viewvc/apr/apr/branches/1.3.x/poll/unix/port.c?view=log)
>> and copy that over APR 1.3.9's poll/unix/port.c and report back on how
>> that works.
>>
>>
>
> --
> View this message in context: http://old.nabble.com/APR-library-%2B-Solaris-5.10-%2B-64bit-problem-tp26814474p26815791.html
> Sent from the APR Dev (Apache Portable Runtime) mailing list archive at Nabble.com.
>
>

--
Born in Roswell... married an alien...

Re: APR library + Solaris 5.10 + 64bit problem

2009-12-16T10:12:11Z

It does not help, I also tryed APR 1.4.1 - it does not work

Jeff Trawick wrote:

On Wed, Dec 16, 2009 at 11:55 AM, Semyon <semyon.karev@gmail.com> wrote:

> I've got a problem after building native library for Tomcat.
> Settings:
> Tomcat 6.0.20
> APR 1.3.9
> JNI 1.1.16
> JDK 1.6_u17
> OS: SunOS 5.10 sparcv9
> compiler: gcc -m64
>
> It has built ok, and APR has gone all tests (gmake test). Tomcat starts well
> with APR libs. But when I'm trying to make HTTPS connection with server from
> firefox browser, I'm getting error like "Connection Interrupted". HTTP
> connection works well. I've tryed to use Internet Explorer 6 - it works
> well.
> I suppose that there is something wrong with 64bit build version, because
> before I built native library with 32bit and everything works well!

You need some post-APR 1.3.9 fixes.

Get the latest port.c from svn (or
http://svn.apache.org/viewvc/apr/apr/branches/1.3.x/poll/unix/port.c?view=log)
and copy that over APR 1.3.9's poll/unix/port.c and report back on how
that works.

Re: [VOTE] APR versioning rules w.r.t. released snapshots

2009-12-16T10:11:25Z

Branko Čibej wrote:
>
> (And maybe it's just me, but I prefer debugging a consistent abort on
> start-up than a random abort because of ABI mismatch).

True :)

Re: APR library + Solaris 5.10 + 64bit problem

2009-12-16T09:01:59Z

On Wed, Dec 16, 2009 at 11:55 AM, Semyon <semyon.karev@...> wrote:

> I've got a problem after building native library for Tomcat.
> Settings:
> Tomcat 6.0.20
> APR 1.3.9
> JNI 1.1.16
> JDK 1.6_u17
> OS: SunOS 5.10 sparcv9
> compiler: gcc -m64
>
> It has built ok, and APR has gone all tests (gmake test). Tomcat starts well
> with APR libs. But when I'm trying to make HTTPS connection with server from
> firefox browser, I'm getting error like "Connection Interrupted". HTTP
> connection works well. I've tryed to use Internet Explorer 6 - it works
> well.
> I suppose that there is something wrong with 64bit build version, because
> before I built native library with 32bit and everything works well!

You need some post-APR 1.3.9 fixes.

Get the latest port.c from svn (or
http://svn.apache.org/viewvc/apr/apr/branches/1.3.x/poll/unix/port.c?view=log)
and copy that over APR 1.3.9's poll/unix/port.c and report back on how
that works.

APR library + Solaris 5.10 + 64bit problem

2009-12-16T08:55:46Z

Hello, all!

I've got a problem after building native library for Tomcat.
Settings:
Tomcat 6.0.20
APR 1.3.9
JNI 1.1.16
JDK 1.6_u17
OS: SunOS 5.10 sparcv9
compiler: gcc -m64

It has built ok, and APR has gone all tests (gmake test). Tomcat starts well with APR libs. But when I'm trying to make HTTPS connection with server from firefox browser, I'm getting error like "Connection Interrupted". HTTP connection works well. I've tryed to use Internet Explorer 6 - it works well.
I suppose that there is something wrong with 64bit build version, because before I built native library with 32bit and everything works well!

Is anybody know about such problem?
Thank's

Re: [VOTE] APR versioning rules w.r.t. released snapshots

2009-12-16T00:48:38Z

William A. Rowe Jr. wrote:

> Branko Čibej wrote:
>
>> Paul Querna wrote:
>>
>>> On Tue, Dec 15, 2009 at 2:05 PM, William A. Rowe Jr.
>>> <wrowe@...> wrote:
>>>
>>>
>>>> Should apr_initialize and friends be programmed to go 'bang' and drop out
>>>> with a stderr emit, if compiled against a x.y.0-dev release and run against
>>>> x.y.*[1-9]? Or, at least a stderr warning at initialization time?
>>>>
>>>> Seems like a simple, sensible fix.
>>>>
>>> No, APR is a library, it has no ownership over stderr/stdout.
>>>
>> OK, stderr isn't a good idea, but APR can abort, right.
>>
>
> Well, if not stderr, then what? In this context (startup) stderr has a well
> defined meaning. I have no problem with my versions for HP/UX hacked with
> the [rejected] patch to allow HP libdld to emit a sensible message about what
> function could not be resolved by apr_dso(). There is no way to ask HP/UX
> for the contents of that message programatically. And by jove, libdld is ...
> wait for it ... a library! :)
>
> So for APR 2 I can see an optional behavior to allow/prohibit emitting any
> messages to stderr. That would cover both Paul's and other use cases.
>
> And apr_initialize() could certainly return APR_SUCCESS or a failure code
> that maps to 'wrong apr version' or some such, at APR 2.0.
>
> But abort() seems too unilateral, let the app author decide how pedantic
> to be, or how to exit gracefully, if there is no indication of what exactly
> was the problem?
>

How is aborting on memory allocation failure any different from aborting
on version mismatch? As for indication of failure -- by zeus, if
inspecting a core dump doesn't help, then nothing will. :) Especially if
we document that an abort in apr-initialize most likely means you
diddled with your library versions.

(And maybe it's just me, but I prefer debugging a consistent abort on
start-up than a random abort because of ABI mismatch).

-- Brane

Re: [VOTE] APR versioning rules w.r.t. released snapshots

2009-12-15T20:50:01Z

Branko Čibej wrote:

> Paul Querna wrote:
>> On Tue, Dec 15, 2009 at 2:05 PM, William A. Rowe Jr.
>> <wrowe@...> wrote:
>>
>>> Should apr_initialize and friends be programmed to go 'bang' and drop out
>>> with a stderr emit, if compiled against a x.y.0-dev release and run against
>>> x.y.*[1-9]? Or, at least a stderr warning at initialization time?
>>>
>>> Seems like a simple, sensible fix.
>>
>> No, APR is a library, it has no ownership over stderr/stdout.
>
> OK, stderr isn't a good idea, but APR can abort, right.

Well, if not stderr, then what? In this context (startup) stderr has a well
defined meaning. I have no problem with my versions for HP/UX hacked with
the [rejected] patch to allow HP libdld to emit a sensible message about what
function could not be resolved by apr_dso(). There is no way to ask HP/UX
for the contents of that message programatically. And by jove, libdld is ...
wait for it ... a library! :)

So for APR 2 I can see an optional behavior to allow/prohibit emitting any
messages to stderr. That would cover both Paul's and other use cases.

And apr_initialize() could certainly return APR_SUCCESS or a failure code
that maps to 'wrong apr version' or some such, at APR 2.0.

But abort() seems too unilateral, let the app author decide how pedantic
to be, or how to exit gracefully, if there is no indication of what exactly
was the problem?

Re: [VOTE] APR versioning rules w.r.t. released snapshots

2009-12-15T15:21:44Z

On Tue, Dec 15, 2009 at 12:38 PM, William A. Rowe Jr.
<wrowe@...> wrote:
> [You are wrong, FWIW. BadCA was one of the first adopters of the original
> crypto interfaces. I don't know that it was ported to the current iteration
> of the crypto interface.]
>

http://svn.apache.org/viewvc//labs/badca/

BadCA hasn't been updated in 2 years, and was never ported to the APR
Crypto interfaces. (best laid plans of mice and men, etc)

Re: svn commit: r890781 - /apr/apr-util/branches/1.4.x/STATUS

2009-12-15T15:15:14Z

On Tue, Dec 15, 2009 at 5:43 PM, Graham Leggett <minfrin@...> wrote:
> Jeff Trawick wrote:
>
>> *my "why are hooks in apr?" lament in the commit log was referring to
>> APR[-Util] as a whole; what besides httpd actually uses these?
>
> A system developed for one of my current clients uses APR provided hooks
> extensively.

thanks for the info!

Re: [VOTE] APR versioning rules w.r.t. released snapshots

2009-12-15T15:08:17Z

Paul Querna wrote:

> On Tue, Dec 15, 2009 at 2:05 PM, William A. Rowe Jr.
> <wrowe@...> wrote:
>
>> Branko Čibej wrote:
>>
>>> William A. Rowe Jr. wrote:
>>>
>>>> Unfortunately the APR versioning rules do not tell the developer not to compile
>>>> against or link to -dev, while this gives the user no indication of what they
>>>> are doing to their APR installation.
>>>>
>>>>
>>> in that, you're correct. One would expect that developers do assume
>>> that, but it needs to be documented. Why not add that bit to
>>> versioning.html? It's quite a reasonable addition.
>>>
>>> For example, Subversion, which uses the exact same versioning rules as
>>> APR, regularly ships rlease candidates marked "-rc" and no-one worries
>>> about breaking the ABI to fix a bug between an RC and a release.
>>>
>> Should apr_initialize and friends be programmed to go 'bang' and drop out
>> with a stderr emit, if compiled against a x.y.0-dev release and run against
>> x.y.*[1-9]? Or, at least a stderr warning at initialization time?
>>
>> Seems like a simple, sensible fix.
>>
>>
>
>
> No, APR is a library, it has no ownership over stderr/stdout.
>

OK, stderr isn't a good idea, but APR can abort, right.

-- Brane

Re: [VOTE] APR versioning rules w.r.t. released snapshots

2009-12-15T15:01:04Z

On Tue, 2009-12-15 at 15:05 +0000, Joe Orton wrote:
> Should the APR project treat those snapshots as "releases" for
> versioning purposes?

Without actually casting a vote (because doing so seems to be
contentious in itself), I would say no. Generally speaking, APR folks
don't have control over what httpd folks bundle in their alpha releases.
So, APR should not care for decisions made by httpd. IMHO etc.

--
Bojan

Re: svn commit: r890781 - /apr/apr-util/branches/1.4.x/STATUS

2009-12-15T14:43:01Z

Jeff Trawick wrote:

> *my "why are hooks in apr?" lament in the commit log was referring to
> APR[-Util] as a whole; what besides httpd actually uses these?

A system developed for one of my current clients uses APR provided hooks
extensively.

Regards,
Graham
--

Re: [VOTE] APR versioning rules w.r.t. released snapshots

2009-12-15T14:42:46Z

William A. Rowe Jr. wrote:

> Branko Čibej wrote:
>
>> William A. Rowe Jr. wrote:
>>
>>> Unfortunately the APR versioning rules do not tell the developer not to compile
>>> against or link to -dev, while this gives the user no indication of what they
>>> are doing to their APR installation.
>>>
>>>
>> in that, you're correct. One would expect that developers do assume
>> that, but it needs to be documented. Why not add that bit to
>> versioning.html? It's quite a reasonable addition.
>>
>> For example, Subversion, which uses the exact same versioning rules as
>> APR, regularly ships rlease candidates marked "-rc" and no-one worries
>> about breaking the ABI to fix a bug between an RC and a release.
>>
>
> Should apr_initialize and friends be programmed to go 'bang' and drop out
> with a stderr emit, if compiled against a x.y.0-dev release and run against
> x.y.*[1-9]? Or, at least a stderr warning at initialization time?
>
> Seems like a simple, sensible fix.
>

Yes, it does. A runtime version check in apr_initialize is an eminently
good idea. I'll see about adding one, like, right now.

-- Brane

Re: [VOTE] APR versioning rules w.r.t. released snapshots

2009-12-15T14:42:29Z

On Tue, Dec 15, 2009 at 2:05 PM, William A. Rowe Jr.
<wrowe@...> wrote:

> Branko Čibej wrote:
>> William A. Rowe Jr. wrote:
>>> Unfortunately the APR versioning rules do not tell the developer not to compile
>>> against or link to -dev, while this gives the user no indication of what they
>>> are doing to their APR installation.
>>>
>>
>> in that, you're correct. One would expect that developers do assume
>> that, but it needs to be documented. Why not add that bit to
>> versioning.html? It's quite a reasonable addition.
>>
>> For example, Subversion, which uses the exact same versioning rules as
>> APR, regularly ships rlease candidates marked "-rc" and no-one worries
>> about breaking the ABI to fix a bug between an RC and a release.
>
> Should apr_initialize and friends be programmed to go 'bang' and drop out
> with a stderr emit, if compiled against a x.y.0-dev release and run against
> x.y.*[1-9]? Or, at least a stderr warning at initialization time?
>
> Seems like a simple, sensible fix.
>

No, APR is a library, it has no ownership over stderr/stdout.

Re: svn commit: r890781 - /apr/apr-util/branches/1.4.x/STATUS

2009-12-15T14:14:09Z

On Tue, Dec 15, 2009 at 4:55 PM, William A. Rowe Jr.
<wrowe@...> wrote:

>>
>> RELEASE SHOWSTOPPERS:
>>
>> + * Resolve hook probe support; current APR-Util 1.4.0-dev has only the
>> + --enable-dtrace configure option which can't be used in a general
>> + purpose build of APR-Util. See this thread:
>> + http://www.mail-archive.com/dev@.../msg22534.html
>> +
>
> To clarify, is the suggestion to move hooks to apr? I'm not 100% clear.

(oops, my lackadaisical STATUS commit log led you astray*)

no; I'm just warning that I intend to replace the curent DTrace-only
hook probe support in the 1.4.x branch with something more generally
useful, at the same time axing the configure-time enable-ment of
probes which meant that any app using hooks that built against that
APR-Util include directory had to also implement the probes

I'll first commit my current patch with some commentary fixes to trunk
in the a.m. unless someone has some concerns that need to be
addressed.

*my "why are hooks in apr?" lament in the commit log was referring to
APR[-Util] as a whole; what besides httpd actually uses these?

Re: [VOTE] APR versioning rules w.r.t. released snapshots

2009-12-15T14:05:27Z

Branko Čibej wrote:

> William A. Rowe Jr. wrote:
>> Unfortunately the APR versioning rules do not tell the developer not to compile
>> against or link to -dev, while this gives the user no indication of what they
>> are doing to their APR installation.
>>
>
> in that, you're correct. One would expect that developers do assume
> that, but it needs to be documented. Why not add that bit to
> versioning.html? It's quite a reasonable addition.
>
> For example, Subversion, which uses the exact same versioning rules as
> APR, regularly ships rlease candidates marked "-rc" and no-one worries
> about breaking the ABI to fix a bug between an RC and a release.

Should apr_initialize and friends be programmed to go 'bang' and drop out
with a stderr emit, if compiled against a x.y.0-dev release and run against
x.y.*[1-9]? Or, at least a stderr warning at initialization time?

Seems like a simple, sensible fix.

Re: svn commit: r890781 - /apr/apr-util/branches/1.4.x/STATUS

2009-12-15T13:55:56Z

>
> RELEASE SHOWSTOPPERS:
>
> + * Resolve hook probe support; current APR-Util 1.4.0-dev has only the
> + --enable-dtrace configure option which can't be used in a general
> + purpose build of APR-Util. See this thread:
> + http://www.mail-archive.com/dev@.../msg22534.html
> +

To clarify, is the suggestion to move hooks to apr? I'm not 100% clear.

If so, I'm all for scuttling 1.4.1 since I also want to see us introduce
incomplete type macros in 1.4 to solve problems similar to those encountered
in the apr_crypto_t types. Although it appears this may not help the current
crypto_t problems since it the context omitted the crypto_device_t *.

Let us know.

Re: [VOTE] APR versioning rules w.r.t. released snapshots

2009-12-15T13:42:25Z

Joe Orton schrieb:
> Snapshots of the APR and APR-util 1.4.x trees have been distributed by
> as part of the httpd 2.3.4 alpha release. Should the APR project treat
> those snapshots as "releases" for versioning purposes? In other words,
> should we ensure future APR/APR-util releases maintain source and binary
> backwards compatibility with those snapshots as required by the
> versioning guidelines, http://apr.apache.org/versioning.html?
>
> Please vote:
>
[X] No

Gün.

Re: [VOTE] APR versioning rules w.r.t. released snapshots

2009-12-15T13:38:55Z

William A. Rowe Jr. wrote:
> Unfortunately the APR versioning rules do not tell the developer not to compile
> against or link to -dev, while this gives the user no indication of what they
> are doing to their APR installation.
>

in that, you're correct. One would expect that developers do assume
that, but it needs to be documented. Why not add that bit to
versioning.html? It's quite a reasonable addition.

For example, Subversion, which uses the exact same versioning rules as
APR, regularly ships rlease candidates marked "-rc" and no-one worries
about breaking the ABI to fix a bug between an RC and a release.

-- Brane

Re: [VOTE] APR versioning rules w.r.t. released snapshots

2009-12-15T13:31:22Z

William A. Rowe Jr. wrote:

> Paul Querna wrote:
>
>> On Tue, Dec 15, 2009 at 12:59 PM, Branko Čibej <brane@...> wrote:
>>
>>> Specifically: if I build and install the APR from that bespoke httpd
>>> tarball, what does apr-1-config --version say?
>>>
>>> * If the answer is 1.4.0, the user will believe they just installed
>>> an APR release.
>>> * If the answer is 1.4.0-dev, then it's clearly a development
>>> snapshot and all bets are off.
>>>
>> Exactly!
>>
>
> Correct, it is internally labeled 1.4.0-dev. It is not externally (plainly
> visible to the user) as an apr-dev. The artifact is httpd-2.3.4-alpha-deps.tar
>
>
>> from the dev snapshot version bundled with httpd 2.3.4-alpha:
>> #define APR_MAJOR_VERSION 1
>> #define APR_MINOR_VERSION 4
>> #define APR_PATCH_VERSION 0
>> #define APR_IS_DEV_VERSION
>>
>
> Unfortunately the APR versioning rules do not tell the developer not to compile
> against or link to -dev, while this gives the user no indication of what they
> are doing to their APR installation.
>
> Perhaps a future solution is to change the APR detection .m4 that we provide,
> to emit a loud ./configure results? E.g. warnings like
>
> You are building against an installed apr 1.4.1-dev.
> This is not a released version of the apr library.
>
> You are linking against a PRE-RELEASE version of apr-1.4.0,
> binary compatibility is not assured. Upgrade of this apr
> package should be expected to break this installed package.
>
> And on the side of APR's own ./configure --prefix=/old-apr-prefix
>
> YOU ARE REPLACING A MORE RECENT apr-1.4.1 with apr-1.4.0-dev. ARE YOU SURE?
>
> If these already existed, all of my objections would have been moot.
>

Oh, but such warnings can be retrofitted on a web page somewhere, in
this particular case I'd suggest the httpd pages since that's where the
release came from. We can add these warnings to configury right now and
before the real httpd and/or apr-1.4 releases.

-- Brane

Re: [VOTE] APR versioning rules w.r.t. released snapshots

2009-12-15T13:28:34Z

Paul Querna wrote:

>> Specifically: if I build and install the APR from that bespoke httpd
>> tarball, what does apr-1-config --version say?
>>
>> * If the answer is 1.4.0, the user will believe they just installed
>> an APR release.
>> * If the answer is 1.4.0-dev, then it's clearly a development
>> snapshot and all bets are off.
>>
>
> Exactly!
>
> from the dev snapshot version bundled with httpd 2.3.4-alpha:
> #define APR_MAJOR_VERSION 1
> #define APR_MINOR_VERSION 4
> #define APR_PATCH_VERSION 0
> #define APR_IS_DEV_VERSION
>

In that case, I think there's nothing more to discuss. Let's fix what
needs to be fixed, and release a proper APR-1.4.0 in time for the real,
non-alpha httpd release.

-- Brane

Re: [VOTE] APR versioning rules w.r.t. released snapshots

2009-12-15T13:28:24Z

Paul Querna wrote:

> On Tue, Dec 15, 2009 at 12:59 PM, Branko Čibej <brane@...> wrote:
>>
>> Specifically: if I build and install the APR from that bespoke httpd
>> tarball, what does apr-1-config --version say?
>>
>> * If the answer is 1.4.0, the user will believe they just installed
>> an APR release.
>> * If the answer is 1.4.0-dev, then it's clearly a development
>> snapshot and all bets are off.
>
> Exactly!

Correct, it is internally labeled 1.4.0-dev. It is not externally (plainly
visible to the user) as an apr-dev. The artifact is httpd-2.3.4-alpha-deps.tar

> from the dev snapshot version bundled with httpd 2.3.4-alpha:
> #define APR_MAJOR_VERSION 1
> #define APR_MINOR_VERSION 4
> #define APR_PATCH_VERSION 0
> #define APR_IS_DEV_VERSION

Unfortunately the APR versioning rules do not tell the developer not to compile
against or link to -dev, while this gives the user no indication of what they
are doing to their APR installation.

Perhaps a future solution is to change the APR detection .m4 that we provide,
to emit a loud ./configure results? E.g. warnings like

You are building against an installed apr 1.4.1-dev.
This is not a released version of the apr library.

You are linking against a PRE-RELEASE version of apr-1.4.0,
binary compatibility is not assured. Upgrade of this apr
package should be expected to break this installed package.

And on the side of APR's own ./configure --prefix=/old-apr-prefix

YOU ARE REPLACING A MORE RECENT apr-1.4.1 with apr-1.4.0-dev. ARE YOU SURE?

If these already existed, all of my objections would have been moot.

Re: [VOTE] APR versioning rules w.r.t. released snapshots

2009-12-15T13:16:58Z

On Tue, Dec 15, 2009 at 12:59 PM, Branko Čibej <brane@...> wrote:

> I'm not going to cast a vote here because I think the vote is a)
> premature, b) not carried out in the proper forum.
>
> If we assume that any part of APR that's bundled with httpd does not
> constitute an APR release -- and note that we're talking about related
> projects within the ASF, not some random pair of projects -- then httpd
> has no business bundling unreleased APR bits in its release tarballs,
> but should only used released APR versions and/or point at existing APR
> tarballs.
>
> I completely agree with Bill that it's entirely irrelevant whether a
> release is named alpha or don't-touch or whatever; if it's in /dist,
> it's a release. The only question is if it's also a release of APR or not.
>
> Bill's concerns about not intercoursing users by breaking a released ABI
> are valid.
> Everybody else's responses that "it's an alpha" are ... at this time
> indeterminate, and IMNSHO not subject to politics (i.e., voting) but to
> technical arguments. "It's just a few users" is not a technical
> argument, I think you'll all agree.
>
> Specifically: if I build and install the APR from that bespoke httpd
> tarball, what does apr-1-config --version say?
>
> * If the answer is 1.4.0, the user will believe they just installed
> an APR release.
> * If the answer is 1.4.0-dev, then it's clearly a development
> snapshot and all bets are off.

Exactly!

from the dev snapshot version bundled with httpd 2.3.4-alpha:
#define APR_MAJOR_VERSION 1
#define APR_MINOR_VERSION 4
#define APR_PATCH_VERSION 0
#define APR_IS_DEV_VERSION

Re: [VOTE] APR versioning rules w.r.t. released snapshots

2009-12-15T12:59:39Z

I'm not going to cast a vote here because I think the vote is a)
premature, b) not carried out in the proper forum.

If we assume that any part of APR that's bundled with httpd does not
constitute an APR release -- and note that we're talking about related
projects within the ASF, not some random pair of projects -- then httpd
has no business bundling unreleased APR bits in its release tarballs,
but should only used released APR versions and/or point at existing APR
tarballs.

I completely agree with Bill that it's entirely irrelevant whether a
release is named alpha or don't-touch or whatever; if it's in /dist,
it's a release. The only question is if it's also a release of APR or not.

Bill's concerns about not intercoursing users by breaking a released ABI
are valid.
Everybody else's responses that "it's an alpha" are ... at this time
indeterminate, and IMNSHO not subject to politics (i.e., voting) but to
technical arguments. "It's just a few users" is not a technical
argument, I think you'll all agree.

Specifically: if I build and install the APR from that bespoke httpd
tarball, what does apr-1-config --version say?

* If the answer is 1.4.0, the user will believe they just installed
an APR release.
* If the answer is 1.4.0-dev, then it's clearly a development
snapshot and all bets are off.

This is not about which project within the ASF released something; for
all I care, you guys can go to a gym with a boxing ring somewhere and
debate it out there. This is about user expectations. Httpd has a
different versioning policy, modules can and do get broken between minor
releases. APR's policy is stricter than that, and for example implies
that we can't fix a released, broken crypto API before APR-2.0.

Since we're both in the same ASF boat, we may want to keep this in mind
when solving the problem.

-- Brane

Re: Quick things, apr/apr-util releases

2009-12-15T12:58:58Z

On Tuesday 15 December 2009, William A. Rowe Jr. wrote:
> Not quite; the scenario that follows is;
>
> - user builds/installs apr-util-1.4.1 w/ crypto
> - user builds/installs crypto-using application

The probability that this happens before the user installs
httpd-2.3.x-alpha with x > 4 and an included, released apr 1.4.y is
_very_ close to zero. I don't think it makes sense to spend developer
time for this corner case.

But I am not an apr committer, of course.

Cheers,
Stefan

Re: [VOTE] APR versioning rules w.r.t. released snapshots

2009-12-15T12:50:51Z

Jeff Trawick wrote:
>
> We disagree on whether or not the httpd 2.3.4 prereqs tarball
> constitutes an APR release. Leave it at that.

Actually we don't disagree. Its an ASF release and not an APR release,
and we all agree on that. I suggest that it's trivial to work around
binary compatibility in *most* respects, e.g. DTRACE maintainer macros
excepted, and this becomes a silly-vote thread of the people who had
championed the release.

You asked, and I answered, that it's perfectly sane to offer some
snapshots as the reference of the perhaps-to-be-released API in our
/dev/dist/ area, etc. This was before the ASF /dist/ release occured.
There were very trivial ways to satisfy my early objections rather than
steamroll over them. And now we have specific applications where that
release now creates 'headaches' and disruption for the users of APR.

> It is not helpful in
> any way to refer to my vote as unethical or as a slight of hand.

It is simply contradictory and inconsistent. I maintain voting to this
contraction is invalid. But more importantly, I am looking forwards to
hearing the opinions of those who didn't already have this argument, as
they are the ones who had nothing to do with the anticipated state of the
user's machines. Are they satisfied testing for and excluding 1.4.0-dev,
and having their app break if the user installs httpd-2.3.4? None of the
folks who were part of this thread have that answer.

I am sorry if 'unethical' was an overly-harsh way of answering this vote.

Better yet, let my vetos stand and let me demonstrate that the workaround
is trivial, rather than pursuing such a thread, and disrupting APR development.
Where the workaround is not possible, I'm either going to concede that 1.5.0
resolves the ambiguity or we are living with the problem with proper cautions
to the users at apr.apache.org/httpd.apache.org.

Re: [VOTE] APR versioning rules w.r.t. released snapshots

2009-12-15T12:38:11Z

Joe Orton wrote:
>
> I am asking people to vote on whether the APR project considers that
> release of the ASF to be significant for APR library versioning
> purposes. That is a decision which can be made by the APR project, as
> we agreed in the other thread.

And I've spelled out why this discussion is so silly. Irrespective of
"rules", there are conventions. APR has a convention for testing if
the version is appropriate. httpd release has set down the benchmark
to use for that test.

You discount that users don't simply hit http://www.apache.org/dist/httpd/
and download the most-current thing they see. Especially those who are
early adopters/bleeding edge sorts of fans.

It's a really *stupid* debate, and even stranger when the two strongest
voices for versioning, compatibility and expectations chime in on the
side of violating the principal of least surprise.

But what is more aggravating is that it's TRIVIAL to work around the
actual compatibility issues. I just pointed out how to do so, and spare
us a more bogus implementation of apr_crypto_error, and offered to solve
the apr_crypto_t partial-unwrapping puzzle for incomplete types.

I conceded to Paul that keeping compatibility has to fall within reason.
Solving the DTRACE mess will fall outside of that reason, but I don't
expect anyone deploying DTRACE is doing so arbitrarily for the reasons
he pointed out in the thread.

On the bigger picture of "does httpd project bind apr's decisions?" you
cannot even suggest that three APR committers voting to ship something
that is based on pre-release APR, disruptive to users, reflects well on
predictability in the APR library.

If you want to start a *useful* vote thread, start one which formally
modifies the versioning contract, and let's put an MMN in there or introduce
other mechanics for determining the presence or absence of API's. That would
solve this and many more problems we and our users struggle with, trying
to advance the library without disrupting users' installations. Or solve
the question of how the APR project will put forward alpha or beta or even
formalize the snapshot (vs. release) process for the wider community to then
review the API. How do we do last-calls?

These would all be worthwhile discussions that would improve adoption of APR,
instead of lowering confidence in its adoption.

[You are wrong, FWIW. BadCA was one of the first adopters of the original
crypto interfaces. I don't know that it was ported to the current iteration
of the crypto interface.]

Re: [VOTE] APR versioning rules w.r.t. released snapshots

2009-12-15T12:28:19Z

On Tue, Dec 15, 2009 at 1:58 PM, William A. Rowe Jr.
<wrowe@...> wrote:

> Jeff Trawick wrote:
>> On Tue, Dec 15, 2009 at 10:05 AM, Joe Orton <jorton@...> wrote:
>>> Snapshots of the APR and APR-util 1.4.x trees have been distributed by
>>> as part of the httpd 2.3.4 alpha release. Should the APR project treat
>>> those snapshots as "releases" for versioning purposes? In other words,
>>> should we ensure future APR/APR-util releases maintain source and binary
>>> backwards compatibility with those snapshots as required by the
>>> versioning guidelines, http://apr.apache.org/versioning.html?
>>>
>>> Please vote:
>>>
>>> [ ] Yes
>>
>> [X] No
>
> You cannot ethically vote to release ASF software at one project and
> declare it not-released at another project. That slight of hand renders
> your vote invalid.

We disagree on whether or not the httpd 2.3.4 prereqs tarball
constitutes an APR release. Leave it at that. It is not helpful in
any way to refer to my vote as unethical or as a slight of hand.

Re: [VOTE] APR versioning rules w.r.t. released snapshots

2009-12-15T12:17:46Z

On Tue, Dec 15, 2009 at 02:00:00PM -0500, William Rowe wrote:

> Joe Orton wrote:
> > On Tue, Dec 15, 2009 at 03:05:29PM +0000, Joe Orton wrote:
> >> [ ] Yes
> >> [X] No
> >
> > I vote no: what other ASF projects ship has no bearing on API
> > commitments made by the APR project.
>
>
> You cannot ethically vote to release ASF software at one project and
> declare it not-released at another project. That slight of hand renders
> your vote invalid.

Say *what* now? This is getting silly. In case it is unclear to
anybody else voting, I am not asking you to vote on whether the httpd
alpha is a release of the ASF. I'd hope the answer to that question was
obvious to everybody.

I am asking people to vote on whether the APR project considers that
release of the ASF to be significant for APR library versioning
purposes. That is a decision which can be made by the APR project, as
we agreed in the other thread.

I'm sorry if the wording of the vote didn't make that clear enough. If
any voter was not clear about this when voting, please reconsider your
position.

Regards, Joe

Re: Quick things, apr/apr-util releases

2009-12-15T12:03:40Z

On Tue, Dec 15, 2009 at 11:50 AM, William A. Rowe Jr.
<wrowe@...> wrote:

> Jeff Trawick wrote:
>>
>> I thought that was covered by
>>
>> "Paul and I agree that we shouldn't be working to accommodate a
>> *developer* who programs against an API that shipped by httpd labeled
>> '-alpha'. It wasn't an apr-util release, they shouldn't have any such
>> expectations."
>
> Not quite; the scenario that follows is;
>
> - user builds/installs apr-util-1.4.1 w/ crypto
> - user builds/installs crypto-using application
> - user builds/installs httpd-2.3.4-alpha, not replacing crypto modules
> (not even realizing they are borking their 1.4.1 install).
>
> Maintaining consistency means that they won't crash when running the
> arbitrary app. Breaking the structure means that it will randomly crash
> when attempting to use the crypto api calls.

No, the only known application in the universe using these APIs, from
a dev snapshot of APR is mod_session_crypto, an optional module for
httpd, disabled by default, and only distributed in httpd's alpha
release.

An 'estimate' of 10,000 users is completely bogus Bil.

Like I said before, there aren't any users using this who aren't
probably subscribed to dev@httpd. (And by users, I think there is
about a 50% chance they are also committers!)

From the vote so far before you claim to have 'invalidated' it, there
is a clear consensus that httpd's bundling of a dev release of APR
would not trigger the ABI stability rules, but this fighting over an
unused module from an alpha release triggering ABI stability rules is
insane, and it severely demotivates me from being involved with the
APR project.

-Paul

Re: Quick things, apr/apr-util releases

2009-12-15T11:50:40Z

Jeff Trawick wrote:
>
> I thought that was covered by
>
> "Paul and I agree that we shouldn't be working to accommodate a
> *developer* who programs against an API that shipped by httpd labeled
> '-alpha'. It wasn't an apr-util release, they shouldn't have any such
> expectations."

Not quite; the scenario that follows is;

- user builds/installs apr-util-1.4.1 w/ crypto
- user builds/installs crypto-using application
- user builds/installs httpd-2.3.4-alpha, not replacing crypto modules
(not even realizing they are borking their 1.4.1 install).

Maintaining consistency means that they won't crash when running the
arbitrary app. Breaking the structure means that it will randomly crash
when attempting to use the crypto api calls.

Rather than trying to vote away the mess, maybe the solution is to give
apr ./configure some magic to note that they are installing an older
version of apr on top of a newer, already-installed version?