You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Paul Querna <pa...@querna.org> on 2009/11/25 23:43:42 UTC
[VOTE] Release httpd 2.3.4-alpha
Test tarballs for Apache httpd 2.3.4-alpha are available at:
<http://httpd.apache.org/dev/dist/>
Your votes please;
+/- 1
[ ] Release httpd-2.3.4 as Alpha
Vote closes at 18:00 UTC on Monday November 30 2009.
May your Thanksgiving be filled with Turkey and httpd testing,
Thanks,
Paul
Re: [VOTE] Release httpd 2.3.4-alpha
Posted by Jeff Trawick <tr...@gmail.com>.
On Wed, Nov 25, 2009 at 5:43 PM, Paul Querna <pa...@querna.org> wrote:
> Test tarballs for Apache httpd 2.3.4-alpha are available at:
> <http://httpd.apache.org/dev/dist/>
>
> Your votes please;
>
[+1] Release httpd-2.3.4 as Alpha
tested with -deps tarball on OpenSolaris 2009.06 and OS X Leopard
OpenSolaris 2009.06:
event MPM used by default
only info.t testcase fails
OS X Leopard
worker MPM used by default
patch to Apache-Test/lib/Apache/TestConfig.pm needed to avoid Lockfile directive
a number of test failures, but comparing with 2.2.x HEAD the only
extra failure is the info.t failure discussed previously
I should dig into the failures in case some setup problem is hiding a
trunk problem. I'll do something about the TestConfig.pm issue.
Re: [VOTE] Release httpd 2.3.4-alpha
Posted by Rainer Jung <ra...@kippdata.de>.
On 25.11.2009 23:43, Paul Querna wrote:
> Test tarballs for Apache httpd 2.3.4-alpha are available at:
> <http://httpd.apache.org/dev/dist/>
>
> Your votes please;
>
> +/- 1
> [ ] Release httpd-2.3.4 as Alpha
>
> Vote closes at 18:00 UTC on Monday November 30 2009.
>
> May your Thanksgiving be filled with Turkey and httpd testing,
I'm +0 as an alpha.
I reported a crash a couple of minutes ago, but it's not clear at the
moment, whether it's only a problem in mod_logio (which is rarely used)
or a more general problem concerning optional function hooks and restarts.
Other small things:
1) Use of AP_LDAP_OPT_DEBUG in modules/ldap/util_ldap.c, already fixed
by Günter.
2) HTTP KeepAlive: there is still a problem with FD handling (no
surprise, because nothing changed since 2.3.1): see
http://marc.info/?t=123102466200005&r=1&w=2
In apr configure, there are (at least) two places with
$RM conftest*
but RM=rm and conftest* doesn't exist at that moment, so it obviously
produces
conftest*: No such file or directory
Line numbers are 13902 (and 13957) and also 15018. Don't know whether RM
should be "rm -f" or instead it should "$RM -f contest*".
3) configure in the expat directory throws a syntax error:
.../srclib/apr-util/xml/expat/configure[2462]: syntax error at line 3321
: `(' unexpected
It has to do with the function lt_if_append_uniq used there. If I
rebuild configure using the buildconf.sh script inside the expat
directory, the function is no longer used in the configure script and
the error is gone. It seems the function lt_if_append_uniq() comes from
libtool 2.2. I use 1.5.26. Looks like we have to agree on minimum
toolchain needed and fix documentation if we upgrade to libtool 2.2 as a
requirement.
Regards,
Rainer
Re: [VOTE] Release httpd 2.3.4-alpha
Posted by Jeff Trawick <tr...@gmail.com>.
On Sun, Nov 29, 2009 at 6:15 PM, Sander Temme <sc...@apache.org> wrote:
>
> The only failing test on Linux and BSD is the one for mod_info (which now has the MPM in the output).
The mod_info test is confused by the inability to map from
mpm_FOO_module to mod_mpm_FOO.c. t/httpd -verbose gives
actual:
core.c event.c httpd_core.c ...
expect:
core.c http_core.c ... mod_mpm_event.c ...
info.t already has this for an existing module with the same general problem:
if ($1 eq 'util_ldap.c') {
push(@actual,'mod_ldap.c');
} else {
push(@actual, $1);
}
We could add more special casing to info.c, but I'd prefer to rename
source files so that the straightforward mapping works for all bundled
modules. I also like the "mpm_" decoration on these special modules.
Re: [VOTE] Release httpd 2.3.4-alpha
Posted by Michael Felt <ma...@gmail.com>.
I pull zlib from a non-os location because the build does not/did not find
the os location. I should try removing it and see if configure can find it
in /usr/lib and/or /usr/local/lib - in both locations.
With building for AIX I am accesstomed to "issues" and I work a long time to
get as transparent a solution as possible. My time to work on things like
this is non-linear - some days I have time available, and then a week or
more I must leave it idle.
If my contribution is of any interest, please let me know, and I shall
contribute as I can. I do appreciate the open replies I have received since
joining the list last September.
I consider myself more a tester than a developer, but was told the test list
was being merged into dev. Hence, I also feel unqualified to vote - and
refrain from voting.
I have a question regarding pcre. What minimal level is needed. While I
cannot compile 8.0 without building a new build server maybe the 7.8
version, if that is minimal, is possible.
IF I understand some of the mails correctly, it is npot all of pcre that is
needed, just some particular parts - that may be different across different
distributions.
Whether it is before alpha, or after alpha - for me to build anything 2.3.+
I will need assistence with getting the needed parts built.
Many thanks for all the hard work
Michael
On Mon, Nov 30, 2009 at 8:32 PM, Sander Temme <sc...@apache.org> wrote:
>
> On Nov 30, 2009, at 12:19 PM, Michael Felt wrote:
>
> >
> >
> > update: what you probably already knew: httpd-2.2.14 included a srclib
> directory with pcre. That is missing in the alpha tarball.
> >
> > michael@x054:[/data/prj/alpha/httpd-2.3.4-alpha]find . | grep pcre
> > ./server/util_pcre.c
> >
> > How you deal with it is your concern, but anyone with AIX will have to
> create an adjusted system to build the sources.
>
> Yes, as Paul said this is deliberate: PCRE is no longer bundled.
>
> It now has the same status as Zlib, which I see from your original post you
> also pull in from a non-OS location.
>
> Whether we should include appropriate versions of libraries like libz and
> pcre in our Deps tarball is another discussion...
>
> S.
>
> --
> Sander Temme
> sctemme@apache.org
> PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF
>
>
>
>
Re: [VOTE] Release httpd 2.3.4-alpha
Posted by Sander Temme <sc...@apache.org>.
On Nov 30, 2009, at 12:19 PM, Michael Felt wrote:
>
>
> update: what you probably already knew: httpd-2.2.14 included a srclib directory with pcre. That is missing in the alpha tarball.
>
> michael@x054:[/data/prj/alpha/httpd-2.3.4-alpha]find . | grep pcre
> ./server/util_pcre.c
>
> How you deal with it is your concern, but anyone with AIX will have to create an adjusted system to build the sources.
Yes, as Paul said this is deliberate: PCRE is no longer bundled.
It now has the same status as Zlib, which I see from your original post you also pull in from a non-OS location.
Whether we should include appropriate versions of libraries like libz and pcre in our Deps tarball is another discussion...
S.
--
Sander Temme
sctemme@apache.org
PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF
Re: [VOTE] Release httpd 2.3.4-alpha
Posted by Michael Felt <ma...@gmail.com>.
one more little bit. It seems pcre 8.0 requires c++ to compile. (too bad
configure does not complain when it does't find it). I am going to have to
look for a new compiler to build pcre. So testing is stopped indefinitely.
Having what is needed, as httpd has done previously, and as php does, will
simplify things imho.
On Mon, Nov 30, 2009 at 9:19 PM, Michael Felt <ma...@gmail.com> wrote:
>
>
> update: what you probably already knew: httpd-2.2.14 included a srclib
> directory with pcre. That is missing in the alpha tarball.
>
> michael@x054:[/data/prj/alpha/httpd-2.3.4-alpha]find . | grep pcre
> ./server/util_pcre.c
>
> How you deal with it is your concern, but anyone with AIX will have to
> create an adjusted system to build the sources.
>
Re: [VOTE] Release httpd 2.3.4-alpha
Posted by Michael Felt <ma...@gmail.com>.
update: what you probably already knew: httpd-2.2.14 included a srclib
directory with pcre. That is missing in the alpha tarball.
michael@x054:[/data/prj/alpha/httpd-2.3.4-alpha]find . | grep pcre
./server/util_pcre.c
How you deal with it is your concern, but anyone with AIX will have to
create an adjusted system to build the sources.
Re: [VOTE] Release httpd 2.3.4-alpha
Posted by Paul Querna <pa...@querna.org>.
On Mon, Nov 30, 2009 at 12:09 PM, Michael Felt <ma...@gmail.com> wrote:
>
>
> Trying to build on AIX with same setup as for 2.2.14.
>
>
>
> After unpacking both tar files
> using:
> ./configure --prefix=/usr/local/apache2 \
> --enable-layout=Apache \
> --enable-module=so \
> --enable-mods-shared=most \
> --with-z=/data/prj/zlib-1.2.3
>
> end result is:
>
> configure: error: pcre-config for libpcre not found. PCRE is required and
> available from http://pcre.org/
>
> These are directories that did get a Makefile.
>
> michael@x054:[/data/prj/alpha/httpd-2.3.4-alpha]find . -name Makefile
> ./srclib/apr/test/internal/Makefile
> ./srclib/apr/test/Makefile
> ./srclib/apr/Makefile
> ./srclib/apr-util/test/Makefile
> ./srclib/apr-util/Makefile
> michael@x054:[/data/prj/alpha/httpd-2.3.4-alpha]
Yes, 2.3+ will not bundle libpcre.
Grab a copy from www.pcre.org, install it, and add
--with-pcre=/your/pcre/prefix to your config flags, and hopefully it
should all work.
Re: [VOTE] Release httpd 2.3.4-alpha
Posted by Eric Covener <co...@gmail.com>.
On Mon, Nov 30, 2009 at 3:09 PM, Michael Felt <ma...@gmail.com> wrote:
>
>
> Trying to build on AIX with same setup as for 2.2.14.
>
>
>
> After unpacking both tar files
> using:
> ./configure --prefix=/usr/local/apache2 \
> --enable-layout=Apache \
> --enable-module=so \
> --enable-mods-shared=most \
> --with-z=/data/prj/zlib-1.2.3
>
> end result is:
>
> configure: error: pcre-config for libpcre not found. PCRE is required and
> available from http://pcre.org/
pcre is no longer bundled in trunk.
--
Eric Covener
covener@gmail.com
Re: [VOTE] Release httpd 2.3.4-alpha
Posted by Michael Felt <ma...@gmail.com>.
Trying to build on AIX with same setup as for 2.2.14.
After unpacking both tar files
using:
./configure --prefix=/usr/local/apache2 \
--enable-layout=Apache \
--enable-module=so \
--enable-mods-shared=most \
--with-z=/data/prj/zlib-1.2.3
end result is:
configure: error: pcre-config for libpcre not found. PCRE is required and
available from http://pcre.org/
These are directories that did get a Makefile.
michael@x054:[/data/prj/alpha/httpd-2.3.4-alpha]find . -name Makefile
./srclib/apr/test/internal/Makefile
./srclib/apr/test/Makefile
./srclib/apr/Makefile
./srclib/apr-util/test/Makefile
./srclib/apr-util/Makefile
michael@x054:[/data/prj/alpha/httpd-2.3.4-alpha]
Re: [VOTE] Release httpd 2.3.4-alpha
Posted by Jeff Trawick <tr...@gmail.com>.
On Sun, Nov 29, 2009 at 6:15 PM, Sander Temme <sc...@apache.org> wrote:
>
> The only failing test on Linux and BSD is the one for mod_info (which now has the MPM in the output).
The same info.t test is also the only failure on OpenSolaris 2009.06.
Re: [VOTE] Release httpd 2.3.4-alpha
Posted by Sander Temme <sc...@apache.org>.
On Nov 25, 2009, at 2:43 PM, Paul Querna wrote:
> +/- 1
> [ ] Release httpd-2.3.4 as Alpha
+1 Set it Free.
Builds cleanly on MacOSX 10.6.2, Ubuntu 9.10 and FreeBSD 6-STABLE.
Need a copy of PCRE on the former, the pcre port/package on the other two.
Runs with Event MPM as the default and does well with the perl-framework.
The only failing test on Linux and BSD is the one for mod_info (which now has the MPM in the output). On MacOSX there are some failing tests:
t/apache/byterange.t (Wstat: 0 Tests: 165 Failed: 165)
Failed tests: 1-165
t/modules/include.t (Wstat: 0 Tests: 88 Failed: 1)
Failed test: 53
These have to do with some freak behaviour where things like %ld are printed to the client. Only happens on this platform.
We should revisit STATUS to see what's really stopping us from throwing this over the wall.
Anyone have anything to add to http://httpd.apache.org/docs/trunk/new_features_2_4.html to tell our user community why this is interesting?
S.
--
Sander Temme
sctemme@apache.org
PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF
Re: [RESULTS] [VOTE] Release httpd 2.3.4-alpha
Posted by Michael Felt <ma...@gmail.com>.
it is a script, r-x in all locations.
On Wed, Dec 9, 2009 at 9:24 PM, Eric Covener <co...@gmail.com> wrote:
> On Wed, Dec 9, 2009 at 3:01 PM, Michael Felt <ma...@gmail.com> wrote:
> > I confess to being a bit lost in all of this. I am still stuck with the
> pcre
> > issue, even after adding:
> > --with-pcre=/data/prj/pcre-8.00 \
> >
> > checking for pcre-config... false
> > configure: error: Did not find pcre-config script at /data/prj/pcre-8.00
> >
> > michael@x054:[/data/prj/alpha/httpd-2.3.4-alpha]cd /data/prj/pcre-8.00
> > michael@x054:[/data/prj/pcre-8.00]find . -name pcre-config
> > ./pcre-config
> > michael@x054:[/data/prj/pcre-8.00]
>
> Did your pcre-config get installed as non-executable?
>
> --
> Eric Covener
> covener@gmail.com
>
michael@x054:[/data/prj/pcre-8.00]find . -name pcre-config -ls
164079 2 -rwxrwx--x 1 michael www 1249 Dec 5 07:57
./pcre-config
executing as michael, not other.
Re: [RESULTS] [VOTE] Release httpd 2.3.4-alpha
Posted by Eric Covener <co...@gmail.com>.
On Wed, Dec 9, 2009 at 3:01 PM, Michael Felt <ma...@gmail.com> wrote:
> I confess to being a bit lost in all of this. I am still stuck with the pcre
> issue, even after adding:
> --with-pcre=/data/prj/pcre-8.00 \
>
> checking for pcre-config... false
> configure: error: Did not find pcre-config script at /data/prj/pcre-8.00
>
> michael@x054:[/data/prj/alpha/httpd-2.3.4-alpha]cd /data/prj/pcre-8.00
> michael@x054:[/data/prj/pcre-8.00]find . -name pcre-config
> ./pcre-config
> michael@x054:[/data/prj/pcre-8.00]
Did your pcre-config get installed as non-executable?
--
Eric Covener
covener@gmail.com
Re: [RESULTS] [VOTE] Release httpd 2.3.4-alpha
Posted by Michael Felt <ma...@gmail.com>.
michael@x054:[/data/prj/alpha/httpd-2.3.4-alpha]*grep -i pcre config.log*
$ ./configure --prefix=/usr/local/apache2 --enable-layout=Apache
--enable-module=so --enable-mods-shared=most --with-pcre=/data/prj/pcre-8.00
--with-z=/data/prj/zlib-1.2.3
configure:5490: checking for pcre-config
configure:5537: error: Did not find pcre-config script at
/data/prj/pcre-8.00
ac_cv_path_PCRE_CONFIG=false
PCRE_CONFIG='/data/prj/pcre-8.00'
PCRE_LIBS=''
On Thu, Dec 10, 2009 at 2:44 AM, William A. Rowe Jr. <wr...@rowe-clan.net>wrote:
> Michael Felt wrote:
> > I confess to being a bit lost in all of this. I am still stuck with the
> > pcre issue, even after adding:
> > --with-pcre=/data/prj/pcre-8.00 \
> >
> > checking for pcre-config... false
> > configure: error: Did not find pcre-config script at /data/prj/pcre-8.00
> >
> > michael@x054:[/data/prj/alpha/httpd-2.3.4-alpha]cd /data/prj/pcre-8.00
> > michael@x054:[/data/prj/pcre-8.00]find . -name pcre-config
> > ./pcre-config
> > michael@x054:[/data/prj/pcre-8.00]
> >
> > Suggestions? And I hope I am not just being blind...
>
> config.log? What does it say about pcre detection?
>
Re: [RESULTS] [VOTE] Release httpd 2.3.4-alpha
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
Michael Felt wrote:
> I confess to being a bit lost in all of this. I am still stuck with the
> pcre issue, even after adding:
> --with-pcre=/data/prj/pcre-8.00 \
>
> checking for pcre-config... false
> configure: error: Did not find pcre-config script at /data/prj/pcre-8.00
>
> michael@x054:[/data/prj/alpha/httpd-2.3.4-alpha]cd /data/prj/pcre-8.00
> michael@x054:[/data/prj/pcre-8.00]find . -name pcre-config
> ./pcre-config
> michael@x054:[/data/prj/pcre-8.00]
>
> Suggestions? And I hope I am not just being blind...
config.log? What does it say about pcre detection?
Re: [RESULTS] [VOTE] Release httpd 2.3.4-alpha
Posted by Michael Felt <ma...@gmail.com>.
Tom, thanks. Please check my new post. I made a new build system after all.
On Thu, Dec 10, 2009 at 3:53 PM, Tom Evans <te...@googlemail.com> wrote:
> On Thu, Dec 10, 2009 at 12:45 PM, Michael Felt <ma...@gmail.com> wrote:
> > well, for an alpha build I dont want to modify my standard build system
> too
> > much.
> >
> > So, if I understand you correctly I will have to run a make install for
> pcre
> > before this will have any chance to work.
> >
> > On Thu, Dec 10, 2009 at 2:38 PM, Tom Evans <te...@googlemail.com>
> wrote:
> >>
> >> On Thu, Dec 10, 2009 at 12:26 PM, Michael Felt <ma...@gmail.com>
> wrote:
> >> > michael@x054:[/data/prj/pcre-8.00]ls bin
> >> > ls: 0653-341 The file bin does not exist.
> >> > michael@x054:[/data/prj/pcre-8.00]mkdir bin
> >> > michael@x054:[/data/prj/pcre-8.00]ls *config
> >> > pcre-config
> >> > michael@x054:[/data/prj/pcre-8.00]ln *config bin
> >> > michael@x054:[/data/prj/pcre-8.00]
> >> >
> >> > * that seems to have solved the ./configure problem, but I suspect the
> >> > build
> >> > will not succeed. -lpcre is not in /usr/local/lib - it is still, at
> >> > best, in
> >> > the directory area of the project source.
> >> >
> >> > What does the --with-pcre=.... actually mean? I would hope it is not
> >> > just to
> >> > find the config program, that is no (longer?) stored in the ./bin/
> >> > directory
> >> > as expected.
> >> >
> >> > michael@x054:[/data/prj/alpha/httpd-2.3.4-alpha]grep pcre nohup.out
> >> > checking for pcre-config... false
> >> > configure: Using external PCRE library from
> >> > /data/prj/pcre-8.00/bin/pcre-config
> >> > setting PCRE_LIBS to "-L/usr/local/lib -lpcre"
> >> > michael@x054:[/data/prj/alpha/httpd-2.3.4-alpha]find /usr/local/lib
> >> > /data/prj/pcre* | grep libpcre
> >> > /data/prj/pcre-8.00/libpcreposix.la
> >> > /data/prj/pcre-8.00/libpcrecpp.pc.in
> >> > /data/prj/pcre-8.00/libpcre.pc.in
> >> > /data/prj/pcre-8.00/libpcreposix.pc.in
> >> > /data/prj/pcre-8.00/.libs/libpcre.exp
> >> > /data/prj/pcre-8.00/.libs/libpcre.so.0
> >> > /data/prj/pcre-8.00/.libs/libpcre.a
> >> > /data/prj/pcre-8.00/.libs/libpcre.lai
> >> > /data/prj/pcre-8.00/.libs/libpcre.la
> >> > /data/prj/pcre-8.00/.libs/libpcreposix.exp
> >> > /data/prj/pcre-8.00/.libs/libpcreposix.so.0
> >> > /data/prj/pcre-8.00/.libs/libpcreposix.a
> >> > /data/prj/pcre-8.00/.libs/libpcreposix.lai
> >> > /data/prj/pcre-8.00/.libs/libpcreposix.la
> >> > /data/prj/pcre-8.00/libpcre.pc
> >> > /data/prj/pcre-8.00/libpcreposix.pc
> >> > /data/prj/pcre-8.00/libpcrecpp.pc
> >> > /data/prj/pcre-8.00/libpcre.la
> >> >
> >>
> >> --with-pcre=<arg> is expecting pcre to be installed to the prefix arg.
> >> Typically, if you want to install/use software that is not part of
> >> your os, you would configure pcre with something like:
> >>
> >> ./configure --prefix=/opt
> >> make all install
> >>
> >> and then configuring apache is simply ./configure --with-pcre=/opt
> >>
> >> HTH
> >>
> >> Tom
> >
> >
>
> Only if you want --with-pcre to work in configure. You could also
> specify the include paths for pcre by setting the CFLAGS environment
> variable, the linker flags for pcre in LDFLAGS, etc.
>
> I would just install it tbh.
>
> Cheers
>
> Tom
>
Re: [RESULTS] [VOTE] Release httpd 2.3.4-alpha
Posted by Tom Evans <te...@googlemail.com>.
On Thu, Dec 10, 2009 at 12:45 PM, Michael Felt <ma...@gmail.com> wrote:
> well, for an alpha build I dont want to modify my standard build system too
> much.
>
> So, if I understand you correctly I will have to run a make install for pcre
> before this will have any chance to work.
>
> On Thu, Dec 10, 2009 at 2:38 PM, Tom Evans <te...@googlemail.com> wrote:
>>
>> On Thu, Dec 10, 2009 at 12:26 PM, Michael Felt <ma...@gmail.com> wrote:
>> > michael@x054:[/data/prj/pcre-8.00]ls bin
>> > ls: 0653-341 The file bin does not exist.
>> > michael@x054:[/data/prj/pcre-8.00]mkdir bin
>> > michael@x054:[/data/prj/pcre-8.00]ls *config
>> > pcre-config
>> > michael@x054:[/data/prj/pcre-8.00]ln *config bin
>> > michael@x054:[/data/prj/pcre-8.00]
>> >
>> > * that seems to have solved the ./configure problem, but I suspect the
>> > build
>> > will not succeed. -lpcre is not in /usr/local/lib - it is still, at
>> > best, in
>> > the directory area of the project source.
>> >
>> > What does the --with-pcre=.... actually mean? I would hope it is not
>> > just to
>> > find the config program, that is no (longer?) stored in the ./bin/
>> > directory
>> > as expected.
>> >
>> > michael@x054:[/data/prj/alpha/httpd-2.3.4-alpha]grep pcre nohup.out
>> > checking for pcre-config... false
>> > configure: Using external PCRE library from
>> > /data/prj/pcre-8.00/bin/pcre-config
>> > setting PCRE_LIBS to "-L/usr/local/lib -lpcre"
>> > michael@x054:[/data/prj/alpha/httpd-2.3.4-alpha]find /usr/local/lib
>> > /data/prj/pcre* | grep libpcre
>> > /data/prj/pcre-8.00/libpcreposix.la
>> > /data/prj/pcre-8.00/libpcrecpp.pc.in
>> > /data/prj/pcre-8.00/libpcre.pc.in
>> > /data/prj/pcre-8.00/libpcreposix.pc.in
>> > /data/prj/pcre-8.00/.libs/libpcre.exp
>> > /data/prj/pcre-8.00/.libs/libpcre.so.0
>> > /data/prj/pcre-8.00/.libs/libpcre.a
>> > /data/prj/pcre-8.00/.libs/libpcre.lai
>> > /data/prj/pcre-8.00/.libs/libpcre.la
>> > /data/prj/pcre-8.00/.libs/libpcreposix.exp
>> > /data/prj/pcre-8.00/.libs/libpcreposix.so.0
>> > /data/prj/pcre-8.00/.libs/libpcreposix.a
>> > /data/prj/pcre-8.00/.libs/libpcreposix.lai
>> > /data/prj/pcre-8.00/.libs/libpcreposix.la
>> > /data/prj/pcre-8.00/libpcre.pc
>> > /data/prj/pcre-8.00/libpcreposix.pc
>> > /data/prj/pcre-8.00/libpcrecpp.pc
>> > /data/prj/pcre-8.00/libpcre.la
>> >
>>
>> --with-pcre=<arg> is expecting pcre to be installed to the prefix arg.
>> Typically, if you want to install/use software that is not part of
>> your os, you would configure pcre with something like:
>>
>> ./configure --prefix=/opt
>> make all install
>>
>> and then configuring apache is simply ./configure --with-pcre=/opt
>>
>> HTH
>>
>> Tom
>
>
Only if you want --with-pcre to work in configure. You could also
specify the include paths for pcre by setting the CFLAGS environment
variable, the linker flags for pcre in LDFLAGS, etc.
I would just install it tbh.
Cheers
Tom
Re: [RESULTS] [VOTE] Release httpd 2.3.4-alpha
Posted by Michael Felt <ma...@gmail.com>.
well, for an alpha build I dont want to modify my standard build system too
much.
So, if I understand you correctly I will have to run a make install for pcre
before this will have any chance to work.
On Thu, Dec 10, 2009 at 2:38 PM, Tom Evans <te...@googlemail.com> wrote:
> On Thu, Dec 10, 2009 at 12:26 PM, Michael Felt <ma...@gmail.com> wrote:
> > michael@x054:[/data/prj/pcre-8.00]ls bin
> > ls: 0653-341 The file bin does not exist.
> > michael@x054:[/data/prj/pcre-8.00]mkdir bin
> > michael@x054:[/data/prj/pcre-8.00]ls *config
> > pcre-config
> > michael@x054:[/data/prj/pcre-8.00]ln *config bin
> > michael@x054:[/data/prj/pcre-8.00]
> >
> > * that seems to have solved the ./configure problem, but I suspect the
> build
> > will not succeed. -lpcre is not in /usr/local/lib - it is still, at best,
> in
> > the directory area of the project source.
> >
> > What does the --with-pcre=.... actually mean? I would hope it is not just
> to
> > find the config program, that is no (longer?) stored in the ./bin/
> directory
> > as expected.
> >
> > michael@x054:[/data/prj/alpha/httpd-2.3.4-alpha]grep pcre nohup.out
> > checking for pcre-config... false
> > configure: Using external PCRE library from
> > /data/prj/pcre-8.00/bin/pcre-config
> > setting PCRE_LIBS to "-L/usr/local/lib -lpcre"
> > michael@x054:[/data/prj/alpha/httpd-2.3.4-alpha]find /usr/local/lib
> > /data/prj/pcre* | grep libpcre
> > /data/prj/pcre-8.00/libpcreposix.la
> > /data/prj/pcre-8.00/libpcrecpp.pc.in
> > /data/prj/pcre-8.00/libpcre.pc.in
> > /data/prj/pcre-8.00/libpcreposix.pc.in
> > /data/prj/pcre-8.00/.libs/libpcre.exp
> > /data/prj/pcre-8.00/.libs/libpcre.so.0
> > /data/prj/pcre-8.00/.libs/libpcre.a
> > /data/prj/pcre-8.00/.libs/libpcre.lai
> > /data/prj/pcre-8.00/.libs/libpcre.la
> > /data/prj/pcre-8.00/.libs/libpcreposix.exp
> > /data/prj/pcre-8.00/.libs/libpcreposix.so.0
> > /data/prj/pcre-8.00/.libs/libpcreposix.a
> > /data/prj/pcre-8.00/.libs/libpcreposix.lai
> > /data/prj/pcre-8.00/.libs/libpcreposix.la
> > /data/prj/pcre-8.00/libpcre.pc
> > /data/prj/pcre-8.00/libpcreposix.pc
> > /data/prj/pcre-8.00/libpcrecpp.pc
> > /data/prj/pcre-8.00/libpcre.la
> >
>
> --with-pcre=<arg> is expecting pcre to be installed to the prefix arg.
> Typically, if you want to install/use software that is not part of
> your os, you would configure pcre with something like:
>
> ./configure --prefix=/opt
> make all install
>
> and then configuring apache is simply ./configure --with-pcre=/opt
>
> HTH
>
> Tom
>
Re: [RESULTS] [VOTE] Release httpd 2.3.4-alpha
Posted by Tom Evans <te...@googlemail.com>.
On Thu, Dec 10, 2009 at 12:26 PM, Michael Felt <ma...@gmail.com> wrote:
> michael@x054:[/data/prj/pcre-8.00]ls bin
> ls: 0653-341 The file bin does not exist.
> michael@x054:[/data/prj/pcre-8.00]mkdir bin
> michael@x054:[/data/prj/pcre-8.00]ls *config
> pcre-config
> michael@x054:[/data/prj/pcre-8.00]ln *config bin
> michael@x054:[/data/prj/pcre-8.00]
>
> * that seems to have solved the ./configure problem, but I suspect the build
> will not succeed. -lpcre is not in /usr/local/lib - it is still, at best, in
> the directory area of the project source.
>
> What does the --with-pcre=.... actually mean? I would hope it is not just to
> find the config program, that is no (longer?) stored in the ./bin/ directory
> as expected.
>
> michael@x054:[/data/prj/alpha/httpd-2.3.4-alpha]grep pcre nohup.out
> checking for pcre-config... false
> configure: Using external PCRE library from
> /data/prj/pcre-8.00/bin/pcre-config
> setting PCRE_LIBS to "-L/usr/local/lib -lpcre"
> michael@x054:[/data/prj/alpha/httpd-2.3.4-alpha]find /usr/local/lib
> /data/prj/pcre* | grep libpcre
> /data/prj/pcre-8.00/libpcreposix.la
> /data/prj/pcre-8.00/libpcrecpp.pc.in
> /data/prj/pcre-8.00/libpcre.pc.in
> /data/prj/pcre-8.00/libpcreposix.pc.in
> /data/prj/pcre-8.00/.libs/libpcre.exp
> /data/prj/pcre-8.00/.libs/libpcre.so.0
> /data/prj/pcre-8.00/.libs/libpcre.a
> /data/prj/pcre-8.00/.libs/libpcre.lai
> /data/prj/pcre-8.00/.libs/libpcre.la
> /data/prj/pcre-8.00/.libs/libpcreposix.exp
> /data/prj/pcre-8.00/.libs/libpcreposix.so.0
> /data/prj/pcre-8.00/.libs/libpcreposix.a
> /data/prj/pcre-8.00/.libs/libpcreposix.lai
> /data/prj/pcre-8.00/.libs/libpcreposix.la
> /data/prj/pcre-8.00/libpcre.pc
> /data/prj/pcre-8.00/libpcreposix.pc
> /data/prj/pcre-8.00/libpcrecpp.pc
> /data/prj/pcre-8.00/libpcre.la
>
--with-pcre=<arg> is expecting pcre to be installed to the prefix arg.
Typically, if you want to install/use software that is not part of
your os, you would configure pcre with something like:
./configure --prefix=/opt
make all install
and then configuring apache is simply ./configure --with-pcre=/opt
HTH
Tom
Re: [RESULTS] [VOTE] Release httpd 2.3.4-alpha
Posted by Michael Felt <ma...@gmail.com>.
michael@x054:[/data/prj/pcre-8.00]ls bin
ls: 0653-341 The file bin does not exist.
michael@x054:[/data/prj/pcre-8.00]mkdir bin
michael@x054:[/data/prj/pcre-8.00]ls *config
pcre-config
michael@x054:[/data/prj/pcre-8.00]ln *config bin
michael@x054:[/data/prj/pcre-8.00]
* that seems to have solved the ./configure problem, but I suspect the build
will not succeed. -lpcre is not in /usr/local/lib - it is still, at best, in
the directory area of the project source.
What does the --with-pcre=.... actually mean? I would hope it is not just to
find the config program, that is no (longer?) stored in the ./bin/ directory
as expected.
michael@x054:[/data/prj/alpha/httpd-2.3.4-alpha]*grep pcre nohup.out*
checking for pcre-config... false
configure: Using external PCRE library from
/data/prj/pcre-8.00/bin/pcre-config
setting PCRE_LIBS to "-L/usr/local/lib -lpcre"
michael@x054:[/data/prj/alpha/httpd-2.3.4-alpha]f*ind /usr/local/lib
/data/prj/pcre* | grep libpcre*
/data/prj/pcre-8.00/libpcreposix.la
/data/prj/pcre-8.00/libpcrecpp.pc.in
/data/prj/pcre-8.00/libpcre.pc.in
/data/prj/pcre-8.00/libpcreposix.pc.in
/data/prj/pcre-8.00/.libs/libpcre.exp
/data/prj/pcre-8.00/.libs/libpcre.so.0
/data/prj/pcre-8.00/.libs/libpcre.a
/data/prj/pcre-8.00/.libs/libpcre.lai
/data/prj/pcre-8.00/.libs/libpcre.la
/data/prj/pcre-8.00/.libs/libpcreposix.exp
/data/prj/pcre-8.00/.libs/libpcreposix.so.0
/data/prj/pcre-8.00/.libs/libpcreposix.a
/data/prj/pcre-8.00/.libs/libpcreposix.lai
/data/prj/pcre-8.00/.libs/libpcreposix.la
/data/prj/pcre-8.00/libpcre.pc
/data/prj/pcre-8.00/libpcreposix.pc
/data/prj/pcre-8.00/libpcrecpp.pc
/data/prj/pcre-8.00/libpcre.la
On Thu, Dec 10, 2009 at 1:49 PM, Bart van der Schans <
b.vanderschans@onehippo.com> wrote:
> On Wed, Dec 9, 2009 at 9:01 PM, Michael Felt <ma...@gmail.com> wrote:
> > I confess to being a bit lost in all of this. I am still stuck with the
> pcre
> > issue, even after adding:
> > --with-pcre=/data/prj/pcre-8.00 \
> >
> > checking for pcre-config... false
> > configure: error: Did not find pcre-config script at /data/prj/pcre-8.00
> >
> > michael@x054:[/data/prj/alpha/httpd-2.3.4-alpha]cd /data/prj/pcre-8.00
> > michael@x054:[/data/prj/pcre-8.00]find . -name pcre-config
> > ./pcre-config
> > michael@x054:[/data/prj/pcre-8.00]
> >
> > Suggestions? And I hope I am not just being blind...
>
> Doesn't configure check for -x "$with_pcre/bin/pcre-config"? Then you
> should have the pcre-config script in a bin sub folder.
>
> Bart
>
Re: [RESULTS] [VOTE] Release httpd 2.3.4-alpha
Posted by Bart van der Schans <b....@onehippo.com>.
On Wed, Dec 9, 2009 at 9:01 PM, Michael Felt <ma...@gmail.com> wrote:
> I confess to being a bit lost in all of this. I am still stuck with the pcre
> issue, even after adding:
> --with-pcre=/data/prj/pcre-8.00 \
>
> checking for pcre-config... false
> configure: error: Did not find pcre-config script at /data/prj/pcre-8.00
>
> michael@x054:[/data/prj/alpha/httpd-2.3.4-alpha]cd /data/prj/pcre-8.00
> michael@x054:[/data/prj/pcre-8.00]find . -name pcre-config
> ./pcre-config
> michael@x054:[/data/prj/pcre-8.00]
>
> Suggestions? And I hope I am not just being blind...
Doesn't configure check for -x "$with_pcre/bin/pcre-config"? Then you
should have the pcre-config script in a bin sub folder.
Bart
Re: [RESULTS] [VOTE] Release httpd 2.3.4-alpha
Posted by Michael Felt <ma...@gmail.com>.
I confess to being a bit lost in all of this. I am still stuck with the pcre
issue, even after adding:
--with-pcre=/data/prj/pcre-8.00 \
checking for pcre-config... false
configure: error: Did not find pcre-config script at /data/prj/pcre-8.00
michael@x054:[/data/prj/alpha/httpd-2.3.4-alpha]cd /data/prj/pcre-8.00
michael@x054:[/data/prj/pcre-8.00]find . -name pcre-config
./pcre-config
michael@x054:[/data/prj/pcre-8.00]
Suggestions? And I hope I am not just being blind...
On Tue, Dec 8, 2009 at 5:18 AM, William A. Rowe Jr. <wr...@rowe-clan.net>wrote:
>
>
> Anyway, 2.3.4 is done and waiting for your announce text, and is in no real
> hurry for that message since many of the people who would further review
> that
> alpha follow this list. But it would be helpful on the web site and
> especially
> in the /dist/ directory, for people who stumble upon 2.3.4-alpha and wonder
> what
> exactly it is.
>
>
Re: [RESULTS] [VOTE] Release httpd 2.3.4-alpha
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
Niklas Edmundsson wrote:
> On Thu, 3 Dec 2009, Paul Querna wrote:
>
>> Vote Results:
>> +1 (binding): Sander Temme, Paul Querna, Joe Orton, Niklas Edmundsson,
>> +1: Gregg Smith
>> +/-0: Rainer Jung
>> -1: William A. Rowe, Jr.
>>
>> Vote passes.
>
> Ehrm. I obviously should have changed the subject when I agreed to
> wrowe's statement about including PCRE in the deps tarball.
>
> It was not my intention to vote on the Alpha-release, but to concur with
> wrowe's statement, as can be seen in the archive at:
> http://mail-archives.apache.org/mod_mbox/httpd-dev/200912.mbox/<Pi...@hatchepsut.acc.umu.se>
>
> So, my vote is to be considered a false positive I'm afraid. I'll
> definitely be more careful about this in the future so automated voting
> counts don't get confused.
As it turns out, Jeff had also voted +1, so the vote count was previously;
+1 (binding): Sander Temme, Paul Querna, Joe Orton, Jeff Trawick
+1: Gregg Smith
+/-0: Rainer Jung
-1: William A. Rowe, Jr.
As my vote was against releasing -deps, and with -deps released, I was otherwise
+1 to the httpd-2.3.4-alpha.tar packages. Packages are not unreleased once they
have been released to the mirrors, and it's not like I haven't been criticized
for that in the past (thus there are a few -r2.msi packages floating around).
I apologize for perhaps not detailing my objections clearly enough when the
issues were first up, e.g. the way I put them in response to Joe Orton's post,
today. And I was equally dismayed that the release was shoved at /dist/, but
once that happened, my objections are entirely moot.
Paul, you prefer that I'm not so overbearing and pedantic, while I'd prefer
that you are more attentive to objections that are raised when they are first
raised, and probe for more information to solve them. There's plenty of room
to agree to disagree, and even more room to come up with agreeable resolutions.
If you need fewer emails, and faster bandwidth, I'm always happy to pound through
an entire disagreement with anyone on the irc httpd-dev channel in realtime, and
bring our thoughts back to this discussion list.
Anyway, 2.3.4 is done and waiting for your announce text, and is in no real
hurry for that message since many of the people who would further review that
alpha follow this list. But it would be helpful on the web site and especially
in the /dist/ directory, for people who stumble upon 2.3.4-alpha and wonder what
exactly it is.
Re: [RESULTS] [VOTE] Release httpd 2.3.4-alpha
Posted by Niklas Edmundsson <ni...@acc.umu.se>.
On Thu, 3 Dec 2009, Paul Querna wrote:
> Vote Results:
> +1 (binding): Sander Temme, Paul Querna, Joe Orton, Niklas Edmundsson,
> +1: Gregg Smith
> +/-0: Rainer Jung
> -1: William A. Rowe, Jr.
>
> Vote passes.
Ehrm. I obviously should have changed the subject when I agreed to
wrowe's statement about including PCRE in the deps tarball.
It was not my intention to vote on the Alpha-release, but to concur
with wrowe's statement, as can be seen in the archive at:
http://mail-archives.apache.org/mod_mbox/httpd-dev/200912.mbox/<Pi...@hatchepsut.acc.umu.se>
So, my vote is to be considered a false positive I'm afraid. I'll
definitely be more careful about this in the future so automated
voting counts don't get confused.
/Nikke
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Niklas Edmundsson, Admin @ {acc,hpc2n}.umu.se | nikke@acc.umu.se
---------------------------------------------------------------------------
Mr Garibaldi, it's a big universe.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Re: [RESULTS] [VOTE] Release httpd 2.3.4-alpha
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
Jeff Trawick wrote:
> On Thu, Dec 3, 2009 at 11:29 PM, William A. Rowe Jr.
>
>> As for broken versioning rules, please take that to APR.
>>
>> Perhaps in retrospect, APR would consider an even/odds approach as httpd
>> has for adding (even eliminating) interfaces during a development cycle.
>
> IMO the determination could be as simple as whether or not a release
> in the maj.min series has yet been declared GA.
Not sufficient, IMHO, unless we add the appropriate indicators to allow
feature tests in apr 2.0. E.g. the current test is VERSION_MAJOR >= 1
&& VERSION_MINOR >= 4 and the APR versioning contract says that test is
always sufficient.
This dialog reads like folks may assume the httpd MMN feature tests
work for APR functions, but there isn't such a feature test in APR.
Re: [RESULTS] [VOTE] Release httpd 2.3.4-alpha
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
Jeff Trawick wrote:
> On Thu, Dec 3, 2009 at 11:29 PM, William A. Rowe Jr.
> <wr...@rowe-clan.net> wrote:
>> Jeff Trawick wrote:
>>> On Thu, Dec 3, 2009 at 6:21 PM, William A. Rowe Jr. <wr...@rowe-clan.net> wrote:
>>>
>>>> Remember your -deps vote is to approve the release of apr 1.4.0-dev and the
>>>> apr-util 1.4.0 dev, and the API versioning rules will bind from that release
>>>> forwards.
>>> The APR versioning rules are hopelessly broken if a tarball snapshot
>>> of the 1.4.x branch before a GA release casts the API in stone.
>>>
>>> Surely I misunderstood you.
>> Is there a README indicating that the MAJOR/MINOR version tests for this
>> particular tarball are not relevant/complete? No.
>>
>> This is not a snapshot. It is labeled httpd-2.3.4-alpha.tar.xx release.
>> You surely don't misunderstand what I said.
>
> Why is something with version x.y.z-dev a release and not a snapshot?
Because snapshots don't live at http://www.apache.org/dist/, those are releases.
The trigger didn't occur until Paul svn mv'ed it into there. Snapshots reside
at http://svn.apache.org/snapshots/
>> As for broken versioning rules, please take that to APR.
>>
>> Perhaps in retrospect, APR would consider an even/odds approach as httpd
>> has for adding (even eliminating) interfaces during a development cycle.
>
> IMO the determination could be as simple as whether or not a release
> in the maj.min series has yet been declared GA.
Re: [RESULTS] [VOTE] Release httpd 2.3.4-alpha
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
Jeff Trawick wrote:
> On Thu, Dec 3, 2009 at 11:29 PM, William A. Rowe Jr.
> <wr...@rowe-clan.net> wrote:
>> Jeff Trawick wrote:
>>> On Thu, Dec 3, 2009 at 6:21 PM, William A. Rowe Jr. <wr...@rowe-clan.net> wrote:
>>>
>>>> Remember your -deps vote is to approve the release of apr 1.4.0-dev and the
>>>> apr-util 1.4.0 dev, and the API versioning rules will bind from that release
>>>> forwards.
>>> The APR versioning rules are hopelessly broken if a tarball snapshot
>>> of the 1.4.x branch before a GA release casts the API in stone.
>>>
>>> Surely I misunderstood you.
>> Is there a README indicating that the MAJOR/MINOR version tests for this
>> particular tarball are not relevant/complete? No.
>>
>> This is not a snapshot. It is labeled httpd-2.3.4-alpha.tar.xx release.
>> You surely don't misunderstand what I said.
>
> Why is something with version x.y.z-dev a release and not a snapshot?
Because snapshots don't live at http://www.apache.org/dist/, those are releases.
The trigger didn't occur until Paul svn mv'ed it into there. Snapshots reside
at http://svn.apache.org/snapshots/
>> As for broken versioning rules, please take that to APR.
>>
>> Perhaps in retrospect, APR would consider an even/odds approach as httpd
>> has for adding (even eliminating) interfaces during a development cycle.
>
> IMO the determination could be as simple as whether or not a release
> in the maj.min series has yet been declared GA.
Re: [RESULTS] [VOTE] Release httpd 2.3.4-alpha
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
Jeff Trawick wrote:
> On Thu, Dec 3, 2009 at 11:29 PM, William A. Rowe Jr.
>
>> As for broken versioning rules, please take that to APR.
>>
>> Perhaps in retrospect, APR would consider an even/odds approach as httpd
>> has for adding (even eliminating) interfaces during a development cycle.
>
> IMO the determination could be as simple as whether or not a release
> in the maj.min series has yet been declared GA.
Not sufficient, IMHO, unless we add the appropriate indicators to allow
feature tests in apr 2.0. E.g. the current test is VERSION_MAJOR >= 1
&& VERSION_MINOR >= 4 and the APR versioning contract says that test is
always sufficient.
This dialog reads like folks may assume the httpd MMN feature tests
work for APR functions, but there isn't such a feature test in APR.
Re: [RESULTS] [VOTE] Release httpd 2.3.4-alpha
Posted by Jeff Trawick <tr...@gmail.com>.
On Thu, Dec 3, 2009 at 11:29 PM, William A. Rowe Jr.
<wr...@rowe-clan.net> wrote:
> Jeff Trawick wrote:
>> On Thu, Dec 3, 2009 at 6:21 PM, William A. Rowe Jr. <wr...@rowe-clan.net> wrote:
>>
>>> Remember your -deps vote is to approve the release of apr 1.4.0-dev and the
>>> apr-util 1.4.0 dev, and the API versioning rules will bind from that release
>>> forwards.
>>
>> The APR versioning rules are hopelessly broken if a tarball snapshot
>> of the 1.4.x branch before a GA release casts the API in stone.
>>
>> Surely I misunderstood you.
>
> Is there a README indicating that the MAJOR/MINOR version tests for this
> particular tarball are not relevant/complete? No.
>
> This is not a snapshot. It is labeled httpd-2.3.4-alpha.tar.xx release.
> You surely don't misunderstand what I said.
Why is something with version x.y.z-dev a release and not a snapshot?
> As for broken versioning rules, please take that to APR.
>
> Perhaps in retrospect, APR would consider an even/odds approach as httpd
> has for adding (even eliminating) interfaces during a development cycle.
IMO the determination could be as simple as whether or not a release
in the maj.min series has yet been declared GA.
Re: [RESULTS] [VOTE] Release httpd 2.3.4-alpha
Posted by Jeff Trawick <tr...@gmail.com>.
On Thu, Dec 3, 2009 at 11:29 PM, William A. Rowe Jr.
<wr...@rowe-clan.net> wrote:
> Jeff Trawick wrote:
>> On Thu, Dec 3, 2009 at 6:21 PM, William A. Rowe Jr. <wr...@rowe-clan.net> wrote:
>>
>>> Remember your -deps vote is to approve the release of apr 1.4.0-dev and the
>>> apr-util 1.4.0 dev, and the API versioning rules will bind from that release
>>> forwards.
>>
>> The APR versioning rules are hopelessly broken if a tarball snapshot
>> of the 1.4.x branch before a GA release casts the API in stone.
>>
>> Surely I misunderstood you.
>
> Is there a README indicating that the MAJOR/MINOR version tests for this
> particular tarball are not relevant/complete? No.
>
> This is not a snapshot. It is labeled httpd-2.3.4-alpha.tar.xx release.
> You surely don't misunderstand what I said.
Why is something with version x.y.z-dev a release and not a snapshot?
> As for broken versioning rules, please take that to APR.
>
> Perhaps in retrospect, APR would consider an even/odds approach as httpd
> has for adding (even eliminating) interfaces during a development cycle.
IMO the determination could be as simple as whether or not a release
in the maj.min series has yet been declared GA.
Re: [RESULTS] [VOTE] Release httpd 2.3.4-alpha
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
Jeff Trawick wrote:
> On Thu, Dec 3, 2009 at 6:21 PM, William A. Rowe Jr. <wr...@rowe-clan.net> wrote:
>
>> Remember your -deps vote is to approve the release of apr 1.4.0-dev and the
>> apr-util 1.4.0 dev, and the API versioning rules will bind from that release
>> forwards.
>
> The APR versioning rules are hopelessly broken if a tarball snapshot
> of the 1.4.x branch before a GA release casts the API in stone.
>
> Surely I misunderstood you.
Is there a README indicating that the MAJOR/MINOR version tests for this
particular tarball are not relevant/complete? No.
This is not a snapshot. It is labeled httpd-2.3.4-alpha.tar.xx release.
You surely don't misunderstand what I said.
As for broken versioning rules, please take that to APR.
Perhaps in retrospect, APR would consider an even/odds approach as httpd
has for adding (even eliminating) interfaces during a development cycle.
Re: [RESULTS] [VOTE] Release httpd 2.3.4-alpha
Posted by Jeff Trawick <tr...@gmail.com>.
On Thu, Dec 3, 2009 at 6:21 PM, William A. Rowe Jr. <wr...@rowe-clan.net> wrote:
> Remember your -deps vote is to approve the release of apr 1.4.0-dev and the
> apr-util 1.4.0 dev, and the API versioning rules will bind from that release
> forwards.
The APR versioning rules are hopelessly broken if a tarball snapshot
of the 1.4.x branch before a GA release casts the API in stone.
Surely I misunderstood you.
Re: [RESULTS] [VOTE] Release httpd 2.3.4-alpha
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
Joe Orton wrote:
>
> This is all fine and good but I don't see any implication above that the
> APR project must enforce its versioning rules on anything other than
> releases *it voted on* - i.e. releases of APR, rather than releases of
> httpd.
I'm more than a bit confused. Does it matter if /usr/lib64/libapr-1.so.0.0
was installed by a release from apr, or from the httpd or svn projects? You
are one of the strongest advocates for consistency in shipped, released,
installed binary artifacts and have offered me no end of grief for single-
platform minor behavioral changes. And certainly I respect you, for your
convictions on this subject.
So let's measurably quantify if this is a molehill;
The httpd project has a feature-detection mechanism of AP_MODULE_MAGIC_AT_LEAST
from ap_mmn.h which reflects the current API, defined by MODULE_MAGIC_NUMBER_MAJOR
and MODULE_MAGIC_NUMBER_MINOR. The apr project uses only APR_VERSION_AT_LEAST
provided by apr_version.h, which reflects APR_MAJOR_VERSION, APR_MINOR_VERSION
and APR_PATCH_VERSION. The version contract declares all features are introduced
at APR_PATCH_VERSION 0 of a given series. Further, httpd would provide for other
projects to ship httpd's code, AP_SERVER_BASEVENDOR, AP_SERVER_BASEPROJECT and
AP_SERVER_BASEPRODUCT define who has provisioned the code. APR has no similar
constructs, by design.
Do you disagree with the paragraph above?
Anything that ships from /dist/ must be expected to be installed on some
users' machines, and the code has been released by the respective projects.
Infrastructure has set down ASF-wide policy that /dist/ contains only, and
all release artifacts. By convention, the ASF does not un-release code.
What exists in http://www.apache.org/dist/ persists forever in the
http://archive.apache.org/dist/. On the other hand, infrastructure has
defined http://svn.apache.org/snapshots/ as exactly that, and another
foundation-wide convention defines /dev/ as the developers' working
space, never release space. There's a clear definition, technically and
legally, between published product and work product.
Do you disagree with the paragraph above?
Then now there should expected to be local installs of a non-APR release
of an APR package by end users, as a published ASF release, without the
user being aware that they have introduced an incompatibility in other
software projects with the bundled flavor of APR. They believed they
were guinea pigs for an alpha of httpd. They should not be expected to
anticipate that their installed package may break third party applications
that are testing for APR 1.4 as a prerequisite to a new feature.
Do you disagree with the paragraph above?
Jeff called for apr (or httpd) to offer snapshots as proof-of-readiness
for the next API iteration. These could have resided at /dev/, or direct
from the /snapshots/ URL. That sounded like a good idea, and would have
been a reasonable course of action to resolve the previous logjam.
Instead, httpd had chosen to %$@jam APR. No, I don't really see this as
a technical molehill, but others are free to disagree, since this para
is purely opinion :)
> What and how the APR project chooses to apply API stability rules is
> something decided by the APR project, not the board or infra. Do you
> disagree with that?
Right. The versioning.html is APR's document, and its a shame when other
projects don't respect the advantages of respecting those guidelines.
Makes Sun's dictatorial supervision of java. seem rather wise. I'd hope
we can coexist without being dictatorial about it.
Since httpd has introduced a potential for inconsistency, APR project can
work around this by bumping version minor on any further '1.4' changes.
If they are called 1.5, there is no ambiguity.
There's obviously some opportunity at apr 2.0 to refine the versioning
contract at APR. I'd hope we take advantage of the opportunity to look
at how it's worked for us, and how it's impeded us from moving forwards.
Re: [RESULTS] [VOTE] Release httpd 2.3.4-alpha
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
Joe Orton wrote:
>
> This is all fine and good but I don't see any implication above that the
> APR project must enforce its versioning rules on anything other than
> releases *it voted on* - i.e. releases of APR, rather than releases of
> httpd.
I'm more than a bit confused. Does it matter if /usr/lib64/libapr-1.so.0.0
was installed by a release from apr, or from the httpd or svn projects? You
are one of the strongest advocates for consistency in shipped, released,
installed binary artifacts and have offered me no end of grief for single-
platform minor behavioral changes. And certainly I respect you, for your
convictions on this subject.
So let's measurably quantify if this is a molehill;
The httpd project has a feature-detection mechanism of AP_MODULE_MAGIC_AT_LEAST
from ap_mmn.h which reflects the current API, defined by MODULE_MAGIC_NUMBER_MAJOR
and MODULE_MAGIC_NUMBER_MINOR. The apr project uses only APR_VERSION_AT_LEAST
provided by apr_version.h, which reflects APR_MAJOR_VERSION, APR_MINOR_VERSION
and APR_PATCH_VERSION. The version contract declares all features are introduced
at APR_PATCH_VERSION 0 of a given series. Further, httpd would provide for other
projects to ship httpd's code, AP_SERVER_BASEVENDOR, AP_SERVER_BASEPROJECT and
AP_SERVER_BASEPRODUCT define who has provisioned the code. APR has no similar
constructs, by design.
Do you disagree with the paragraph above?
Anything that ships from /dist/ must be expected to be installed on some
users' machines, and the code has been released by the respective projects.
Infrastructure has set down ASF-wide policy that /dist/ contains only, and
all release artifacts. By convention, the ASF does not un-release code.
What exists in http://www.apache.org/dist/ persists forever in the
http://archive.apache.org/dist/. On the other hand, infrastructure has
defined http://svn.apache.org/snapshots/ as exactly that, and another
foundation-wide convention defines /dev/ as the developers' working
space, never release space. There's a clear definition, technically and
legally, between published product and work product.
Do you disagree with the paragraph above?
Then now there should expected to be local installs of a non-APR release
of an APR package by end users, as a published ASF release, without the
user being aware that they have introduced an incompatibility in other
software projects with the bundled flavor of APR. They believed they
were guinea pigs for an alpha of httpd. They should not be expected to
anticipate that their installed package may break third party applications
that are testing for APR 1.4 as a prerequisite to a new feature.
Do you disagree with the paragraph above?
Jeff called for apr (or httpd) to offer snapshots as proof-of-readiness
for the next API iteration. These could have resided at /dev/, or direct
from the /snapshots/ URL. That sounded like a good idea, and would have
been a reasonable course of action to resolve the previous logjam.
Instead, httpd had chosen to %$@jam APR. No, I don't really see this as
a technical molehill, but others are free to disagree, since this para
is purely opinion :)
> What and how the APR project chooses to apply API stability rules is
> something decided by the APR project, not the board or infra. Do you
> disagree with that?
Right. The versioning.html is APR's document, and its a shame when other
projects don't respect the advantages of respecting those guidelines.
Makes Sun's dictatorial supervision of java. seem rather wise. I'd hope
we can coexist without being dictatorial about it.
Since httpd has introduced a potential for inconsistency, APR project can
work around this by bumping version minor on any further '1.4' changes.
If they are called 1.5, there is no ambiguity.
There's obviously some opportunity at apr 2.0 to refine the versioning
contract at APR. I'd hope we take advantage of the opportunity to look
at how it's worked for us, and how it's impeded us from moving forwards.
Re: [RESULTS] [VOTE] Release httpd 2.3.4-alpha
Posted by Joe Orton <jo...@redhat.com>.
On Fri, Dec 04, 2009 at 07:48:02PM -0600, William Rowe wrote:
> Joe Orton wrote:
> > 1) the httpd project cannot force the APR project to commit to API
> > stability by distributing a snapshot of the APR 1.4 branch. Why on
> > earth would that be the case? The only time the APR project commits to
> > API stability is by making a new .0 release itself. What other projects
> > do is irrelevant to APR.
>
> Joe, as I pointed out in another thread, httpd *does* commit apr the moment
> the mislabeled artifact hits www.apache.org/dist/ - where does that package
> suggest it is nothing but a snapshot? The answer is, it doesn't.
>
> When we did this previously in httpd 2.0 (never 2.1 to the best of my
> recollection) we actually did commit to that particular apr API. The
> rules in 0.9 just weren't so draconian.
>
> If you don't like any of these rules;
>
> * what is on /dist/ is a release
> * what is released apr >= 1.0 follows absolute versioning rules
> * what is a snapshot doesn't appear on /dist/
>
> then take those issues to an infra/board level. We've had these discussions
> a thousand times on incubator lists, and this is a clear case of what is
> good for the goose...
This is all fine and good but I don't see any implication above that the
APR project must enforce its versioning rules on anything other than
releases *it voted on* - i.e. releases of APR, rather than releases of
httpd.
What and how the APR project chooses to apply API stability rules is
something decided by the APR project, not the board or infra. Do you
disagree with that?
If you think we need to amend apr/README to describe how the APR
versioning rules apply to the APR project, so be it, but I think you are
making an Everest-sized mountain out of a molehill here.
Regards, Joe
Re: [RESULTS] [VOTE] Release httpd 2.3.4-alpha
Posted by Joe Orton <jo...@redhat.com>.
On Fri, Dec 04, 2009 at 07:48:02PM -0600, William Rowe wrote:
> Joe Orton wrote:
> > 1) the httpd project cannot force the APR project to commit to API
> > stability by distributing a snapshot of the APR 1.4 branch. Why on
> > earth would that be the case? The only time the APR project commits to
> > API stability is by making a new .0 release itself. What other projects
> > do is irrelevant to APR.
>
> Joe, as I pointed out in another thread, httpd *does* commit apr the moment
> the mislabeled artifact hits www.apache.org/dist/ - where does that package
> suggest it is nothing but a snapshot? The answer is, it doesn't.
>
> When we did this previously in httpd 2.0 (never 2.1 to the best of my
> recollection) we actually did commit to that particular apr API. The
> rules in 0.9 just weren't so draconian.
>
> If you don't like any of these rules;
>
> * what is on /dist/ is a release
> * what is released apr >= 1.0 follows absolute versioning rules
> * what is a snapshot doesn't appear on /dist/
>
> then take those issues to an infra/board level. We've had these discussions
> a thousand times on incubator lists, and this is a clear case of what is
> good for the goose...
This is all fine and good but I don't see any implication above that the
APR project must enforce its versioning rules on anything other than
releases *it voted on* - i.e. releases of APR, rather than releases of
httpd.
What and how the APR project chooses to apply API stability rules is
something decided by the APR project, not the board or infra. Do you
disagree with that?
If you think we need to amend apr/README to describe how the APR
versioning rules apply to the APR project, so be it, but I think you are
making an Everest-sized mountain out of a molehill here.
Regards, Joe
Re: [RESULTS] [VOTE] Release httpd 2.3.4-alpha
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
Joe Orton wrote:
> On Thu, Dec 03, 2009 at 05:21:09PM -0600, William Rowe wrote:
>> Paul Querna wrote:
>>> Vote Results:
>>> +1 (binding): Sander Temme, Paul Querna, Joe Orton, Niklas Edmundsson,
>>> +1: Gregg Smith
>>> +/-0: Rainer Jung
>>> -1: William A. Rowe, Jr.
>>>
>>> Vote passes.
>> I'm sorry. I explicitly insisted on a vote on the -deps package seperately
>> from the 2.3.4 package, because it was entirely reasonable that Sander Temme,
>> Paul Querna, Joe Orton, Niklas Edmundsson, or Gregg Smith reviewed -only- the
>> httpd-2.3.4-alpha.tar.xx package alone.
>
> I've no issue at all with the -deps tarball containing a snapshot of
> APR:
>
> 1) the httpd project cannot force the APR project to commit to API
> stability by distributing a snapshot of the APR 1.4 branch. Why on
> earth would that be the case? The only time the APR project commits to
> API stability is by making a new .0 release itself. What other projects
> do is irrelevant to APR.
Joe, as I pointed out in another thread, httpd *does* commit apr the moment
the mislabeled artifact hits www.apache.org/dist/ - where does that package
suggest it is nothing but a snapshot? The answer is, it doesn't.
When we did this previously in httpd 2.0 (never 2.1 to the best of my
recollection) we actually did commit to that particular apr API. The
rules in 0.9 just weren't so draconian.
If you don't like any of these rules;
* what is on /dist/ is a release
* what is released apr >= 1.0 follows absolute versioning rules
* what is a snapshot doesn't appear on /dist/
then take those issues to an infra/board level. We've had these discussions
a thousand times on incubator lists, and this is a clear case of what is
good for the goose...
> 2) the httpd project isn't taking on any commitment to itself maintain
> API stability in the shipped APR snapshot because *this is an alpha*, so
> we're not guaranteeing API stability.
Nope, much like broken ldap and crypto interfaces, it simply inflicts them
upon apr and hopes for someone else to clean up the junk later, perhaps.
But the apr project would be remiss in not voiding 1.4.x and moving on to
1.5.x for API additions since users can now be reasonably expected to have
installed an apr 1.4.x major/minor with a specific feature set.
> Furthermore I don't think it's a good idea to set a precedent of
> requiring a separate vote on each file which makes up "the release". I
> certainly presumed that the vote Paul called was for all the files
> making up "the release".
Nonsense. I post up httpd win32 binaries all the time to /dev/dist/. Do
I really think everyone voting on the source code snapshot of httpd is paying
any attention to that artifact (or this new -deps artifact, when all the deps
are already provisioned on most voter's machines)?
Re: [RESULTS] [VOTE] Release httpd 2.3.4-alpha
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
Joe Orton wrote:
> On Thu, Dec 03, 2009 at 05:21:09PM -0600, William Rowe wrote:
>> Paul Querna wrote:
>>> Vote Results:
>>> +1 (binding): Sander Temme, Paul Querna, Joe Orton, Niklas Edmundsson,
>>> +1: Gregg Smith
>>> +/-0: Rainer Jung
>>> -1: William A. Rowe, Jr.
>>>
>>> Vote passes.
>> I'm sorry. I explicitly insisted on a vote on the -deps package seperately
>> from the 2.3.4 package, because it was entirely reasonable that Sander Temme,
>> Paul Querna, Joe Orton, Niklas Edmundsson, or Gregg Smith reviewed -only- the
>> httpd-2.3.4-alpha.tar.xx package alone.
>
> I've no issue at all with the -deps tarball containing a snapshot of
> APR:
>
> 1) the httpd project cannot force the APR project to commit to API
> stability by distributing a snapshot of the APR 1.4 branch. Why on
> earth would that be the case? The only time the APR project commits to
> API stability is by making a new .0 release itself. What other projects
> do is irrelevant to APR.
Joe, as I pointed out in another thread, httpd *does* commit apr the moment
the mislabeled artifact hits www.apache.org/dist/ - where does that package
suggest it is nothing but a snapshot? The answer is, it doesn't.
When we did this previously in httpd 2.0 (never 2.1 to the best of my
recollection) we actually did commit to that particular apr API. The
rules in 0.9 just weren't so draconian.
If you don't like any of these rules;
* what is on /dist/ is a release
* what is released apr >= 1.0 follows absolute versioning rules
* what is a snapshot doesn't appear on /dist/
then take those issues to an infra/board level. We've had these discussions
a thousand times on incubator lists, and this is a clear case of what is
good for the goose...
> 2) the httpd project isn't taking on any commitment to itself maintain
> API stability in the shipped APR snapshot because *this is an alpha*, so
> we're not guaranteeing API stability.
Nope, much like broken ldap and crypto interfaces, it simply inflicts them
upon apr and hopes for someone else to clean up the junk later, perhaps.
But the apr project would be remiss in not voiding 1.4.x and moving on to
1.5.x for API additions since users can now be reasonably expected to have
installed an apr 1.4.x major/minor with a specific feature set.
> Furthermore I don't think it's a good idea to set a precedent of
> requiring a separate vote on each file which makes up "the release". I
> certainly presumed that the vote Paul called was for all the files
> making up "the release".
Nonsense. I post up httpd win32 binaries all the time to /dev/dist/. Do
I really think everyone voting on the source code snapshot of httpd is paying
any attention to that artifact (or this new -deps artifact, when all the deps
are already provisioned on most voter's machines)?
Re: [RESULTS] [VOTE] Release httpd 2.3.4-alpha
Posted by Joe Orton <jo...@redhat.com>.
On Thu, Dec 03, 2009 at 05:21:09PM -0600, William Rowe wrote:
> Paul Querna wrote:
> > Vote Results:
> > +1 (binding): Sander Temme, Paul Querna, Joe Orton, Niklas Edmundsson,
> > +1: Gregg Smith
> > +/-0: Rainer Jung
> > -1: William A. Rowe, Jr.
> >
> > Vote passes.
>
> I'm sorry. I explicitly insisted on a vote on the -deps package seperately
> from the 2.3.4 package, because it was entirely reasonable that Sander Temme,
> Paul Querna, Joe Orton, Niklas Edmundsson, or Gregg Smith reviewed -only- the
> httpd-2.3.4-alpha.tar.xx package alone.
I've no issue at all with the -deps tarball containing a snapshot of
APR:
1) the httpd project cannot force the APR project to commit to API
stability by distributing a snapshot of the APR 1.4 branch. Why on
earth would that be the case? The only time the APR project commits to
API stability is by making a new .0 release itself. What other projects
do is irrelevant to APR.
2) the httpd project isn't taking on any commitment to itself maintain
API stability in the shipped APR snapshot because *this is an alpha*, so
we're not guaranteeing API stability.
Furthermore I don't think it's a good idea to set a precedent of
requiring a separate vote on each file which makes up "the release". I
certainly presumed that the vote Paul called was for all the files
making up "the release".
Regards, Joe
Re: [RESULTS] [VOTE] Release httpd 2.3.4-alpha
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
Paul Querna wrote:
> Vote Results:
> +1 (binding): Sander Temme, Paul Querna, Joe Orton, Niklas Edmundsson,
> +1: Gregg Smith
> +/-0: Rainer Jung
> -1: William A. Rowe, Jr.
>
> Vote passes.
I'm sorry. I explicitly insisted on a vote on the -deps package seperately
from the 2.3.4 package, because it was entirely reasonable that Sander Temme,
Paul Querna, Joe Orton, Niklas Edmundsson, or Gregg Smith reviewed -only- the
httpd-2.3.4-alpha.tar.xx package alone.
Gentlemen, if you could verify that your vote was for *both* the core package
and the -deps.tar.xx package, that might keep Paul on his schedule (or fall
against the proposed -deps.tar.xx package).
Remember your -deps vote is to approve the release of apr 1.4.0-dev and the
apr-util 1.4.0 dev, and the API versioning rules will bind from that release
forwards.
Re: [RESULTS] [VOTE] Release httpd 2.3.4-alpha
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
Paul Querna wrote:
> Vote Results:
> +1 (binding): Sander Temme, Paul Querna, Joe Orton, Niklas Edmundsson,
> +1: Gregg Smith
> +/-0: Rainer Jung
> -1: William A. Rowe, Jr.
>
> Vote passes.
>
> I'll push out the tarballs to start getting mirrors, and hack on an
> announcement email for tomorrow.
Oh - looking forward to the announce; the damage occured the moment
you had pushed to /dist/httpd/, we don't un-release software, and any
old arguments are over about the wisdom of releasing the -deps package.
Except of course, we need to finish the discussion of *adding* PCRE, but
that should never stop an alpha release.
In the meantime I'm pushing forwards on apr-1.4.1 since testing for
subversion 0 won't indicate if the APR_STATUS_IS_ENOTDIR had been fixed
(for anyone looking for min revlevel checks), and once that is done,
perhaps someone else wants to advocate for releasing apr-util-1.4.0.
But AFAIK apr-util 1.4.0 is not a prerequisite for httpd 2.3 alphas
just yet, it is an optional requirement for the scache module.
[RESULTS] [VOTE] Release httpd 2.3.4-alpha
Posted by Paul Querna <pa...@querna.org>.
Vote Results:
+1 (binding): Sander Temme, Paul Querna, Joe Orton, Niklas Edmundsson,
+1: Gregg Smith
+/-0: Rainer Jung
-1: William A. Rowe, Jr.
Vote passes.
I'll push out the tarballs to start getting mirrors, and hack on an
announcement email for tomorrow.
On Wed, Nov 25, 2009 at 2:43 PM, Paul Querna <pa...@querna.org> wrote:
> Test tarballs for Apache httpd 2.3.4-alpha are available at:
> <http://httpd.apache.org/dev/dist/>
>
> Your votes please;
>
> +/- 1
> [ ] Release httpd-2.3.4 as Alpha
>
> Vote closes at 18:00 UTC on Monday November 30 2009.
>
> May your Thanksgiving be filled with Turkey and httpd testing,
>
> Thanks,
>
> Paul
>
Re: [VOTE] Release httpd 2.3.4-alpha
Posted by Sander Temme <sc...@apache.org>.
On Nov 30, 2009, at 9:32 AM, Jeff Trawick wrote:
> On Wed, Nov 25, 2009 at 5:43 PM, Paul Querna <pa...@querna.org> wrote:
>> Test tarballs for Apache httpd 2.3.4-alpha are available at:
>> <http://httpd.apache.org/dev/dist/>
>>
>> Your votes please;
>>
>> +/- 1
>> [ ] Release httpd-2.3.4 as Alpha
>>
>> Vote closes at 18:00 UTC on Monday November 30 2009.
>
> I could use an extra couple of hours. Who else is still playing or
> about to start?
I've had my look and my say, but yes if others are willing to spend some time I'd encourage Paul to extend the vote.
S.
--
Sander Temme
sctemme@apache.org
PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF
Re: [VOTE] Release httpd 2.3.4-alpha
Posted by Rainer Jung <ra...@kippdata.de>.
I plan to have a look on Wednesday. I'll not be able earlier.
On 30.11.2009 18:32, Jeff Trawick wrote:
> On Wed, Nov 25, 2009 at 5:43 PM, Paul Querna <pa...@querna.org> wrote:
>> Test tarballs for Apache httpd 2.3.4-alpha are available at:
>> <http://httpd.apache.org/dev/dist/>
>>
>> Your votes please;
>>
>> +/- 1
>> [ ] Release httpd-2.3.4 as Alpha
>>
>> Vote closes at 18:00 UTC on Monday November 30 2009.
>
> I could use an extra couple of hours. Who else is still playing or
> about to start?
Re: [VOTE] Release httpd 2.3.4-alpha
Posted by Paul Querna <pa...@querna.org>.
On Mon, Nov 30, 2009 at 9:32 AM, Jeff Trawick <tr...@gmail.com> wrote:
> On Wed, Nov 25, 2009 at 5:43 PM, Paul Querna <pa...@querna.org> wrote:
>> Test tarballs for Apache httpd 2.3.4-alpha are available at:
>> <http://httpd.apache.org/dev/dist/>
>>
>> Your votes please;
>>
>> +/- 1
>> [ ] Release httpd-2.3.4 as Alpha
>>
>> Vote closes at 18:00 UTC on Monday November 30 2009.
>
> I could use an extra couple of hours. Who else is still playing or
> about to start?
>
Agree, very few people provided feedback, lets add 48 hours... so
closing at 18:00 UTC on Wednesday December 2nd.
Re: [VOTE] Release httpd 2.3.4-alpha
Posted by Jeff Trawick <tr...@gmail.com>.
On Wed, Nov 25, 2009 at 5:43 PM, Paul Querna <pa...@querna.org> wrote:
> Test tarballs for Apache httpd 2.3.4-alpha are available at:
> <http://httpd.apache.org/dev/dist/>
>
> Your votes please;
>
> +/- 1
> [ ] Release httpd-2.3.4 as Alpha
>
> Vote closes at 18:00 UTC on Monday November 30 2009.
I could use an extra couple of hours. Who else is still playing or
about to start?
Re: [VOTE] Release httpd 2.3.4-alpha
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
Sander Temme wrote:
> On Nov 30, 2009, at 1:12 PM, "William A. Rowe Jr." <wr...@rowe-clan.net>
>
>> Look, PCRE is a mandatory component. APR is a mandatory component.
>> Let's please start applying some rhyme to our reasoning again.
>
> Meaning? Put pcre in -deps? With libz? That's mandatory for deflate.
Mandatory 'for a feature' is not the same thing as mandatory to build
the damned thing ... zlib is no more 'required' than libiconv; you'll
lose a couple features but you'll keep on plugging away.
PCRE is a critical, don't pass go, don't collect $200 feature. And what
is passing for an excuse for a local PCRE install these days probably
doesn't look like 7.8 or later, with various fixes we are vulnerable to.
So until we support building sans-pcre, it would seem like a good idea
to bundle it with whatever 'extras' we ship.
Re: [VOTE] Release httpd 2.3.4-alpha
Posted by Sander Temme <sc...@apache.org>.
On Nov 30, 2009, at 1:12 PM, "William A. Rowe Jr." <wrowe@rowe-
clan.net> wrote:
> Paul Querna wrote:
>> Test tarballs for Apache httpd 2.3.4-alpha are available at:
>> <http://httpd.apache.org/dev/dist/>
>>
>> Your votes please;
>>
>> +/- 1
>> [-1] Release httpd-2.3.4 as Alpha
>
> for shipping the package httpd-2.3.4-deps; 1.4.0-dev is not released
> and I strongly feel the httpd project isn't in the business of doing
> so.
How big an overlap do we still have, community wise, with APR?
Obviously we should discuss that on the dev@apr list.
> Look, PCRE is a mandatory component. APR is a mandatory component.
> Let's please start applying some rhyme to our reasoning again.
Meaning? Put pcre in -deps? With libz? That's mandatory for deflate.
S.
Re: [VOTE] Release httpd 2.3.4-alpha
Posted by "Philip M. Gollucci" <pg...@p6m7g8.com>.
Niklas Edmundsson wrote:
> On Mon, 30 Nov 2009, William A. Rowe Jr. wrote:
>
>> Look, PCRE is a mandatory component. APR is a mandatory component.
>> Let's please start applying some rhyme to our reasoning again.
>
> +1
+1 a good write up.
--
------------------------------------------------------------------------
1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C
Philip M. Gollucci (pgollucci@p6m7g8.com) c: 703.336.9354
VP Apache Infrastructure; Member, Apache Software Foundation
Committer, FreeBSD Foundation
Consultant, P6M7G8 Inc.
Sr. System Admin, Ridecharge Inc.
Work like you don't need the money,
love like you'll never get hurt,
and dance like nobody's watching.
Re: [VOTE] Release httpd 2.3.4-alpha
Posted by Niklas Edmundsson <ni...@acc.umu.se>.
On Mon, 30 Nov 2009, William A. Rowe Jr. wrote:
> Look, PCRE is a mandatory component. APR is a mandatory component.
> Let's please start applying some rhyme to our reasoning again.
+1
/Nikke
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Niklas Edmundsson, Admin @ {acc,hpc2n}.umu.se | nikke@acc.umu.se
---------------------------------------------------------------------------
Never, ever use repetitive redundancies.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Re: [VOTE] Release httpd 2.3.4-alpha
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
Paul Querna wrote:
> Test tarballs for Apache httpd 2.3.4-alpha are available at:
> <http://httpd.apache.org/dev/dist/>
>
> Your votes please;
>
> +/- 1
> [-1] Release httpd-2.3.4 as Alpha
for shipping the package httpd-2.3.4-deps; 1.4.0-dev is not released
and I strongly feel the httpd project isn't in the business of doing
so.
Look, PCRE is a mandatory component. APR is a mandatory component.
Let's please start applying some rhyme to our reasoning again.
Re: [VOTE] Release httpd 2.3.4-alpha
Posted by "Gregg L. Smith" <li...@glewis.com>.
Guenter,
I looked at your commit
http://svn.apache.org/viewvc?view=revision&revision=885281
Yes, it allows VC++ to continue on building without error. It is exactly
what I had done to get passed the problem. Thank you.
Regards,
Gregg
Guenter Knauf wrote:
> Gregg,
> Gregg L. Smith schrieb:
>> > [+1] Release httpd-2.3.4 as Alpha
>>
>> Win32 Release build fails at mod_ldap
>> Windows XP
>> VC++ 6 SDK 2003 R2
>> PCRE 8.0
>> LUA 5.1.4
>>
>>
>> ---Configuration: mod_ldap - Win32 Release--------------------
>> Compiling resources...
>> Compiling...
>> util_ldap.c
>> E:\build\httpd-2.3.x-dev\modules\ldap\util_ldap.c(2660) : error C2065:
>> 'AP_LDAP_OPT_DEBUG' : undeclared identifier
> can you please test this fix I commited yesterday:
> http://svn.apache.org/viewvc?view=revision&revision=885281
>
> Gün.
>
>
>
>
Re: [VOTE] Release httpd 2.3.4-alpha
Posted by Guenter Knauf <fu...@apache.org>.
Gregg,
Gregg L. Smith schrieb:
> > [+1] Release httpd-2.3.4 as Alpha
>
> Win32 Release build fails at mod_ldap
> Windows XP
> VC++ 6 SDK 2003 R2
> PCRE 8.0
> LUA 5.1.4
>
>
> ---Configuration: mod_ldap - Win32 Release--------------------
> Compiling resources...
> Compiling...
> util_ldap.c
> E:\build\httpd-2.3.x-dev\modules\ldap\util_ldap.c(2660) : error C2065:
> 'AP_LDAP_OPT_DEBUG' : undeclared identifier
can you please test this fix I commited yesterday:
http://svn.apache.org/viewvc?view=revision&revision=885281
Gün.
Re: [VOTE] Release httpd 2.3.4-alpha
Posted by "Gregg L. Smith" <li...@glewis.com>.
> [+1] Release httpd-2.3.4 as Alpha
Win32 Release build fails at mod_ldap
Windows XP
VC++ 6 SDK 2003 R2
PCRE 8.0
LUA 5.1.4
---Configuration: mod_ldap - Win32 Release--------------------
Compiling resources...
Compiling...
util_ldap.c
E:\build\httpd-2.3.x-dev\modules\ldap\util_ldap.c(2660) : error C2065:
'AP_LDAP_OPT_DEBUG' : undeclared identifier
Regards
Gregg
Paul Querna wrote:
> Test tarballs for Apache httpd 2.3.4-alpha are available at:
> <http://httpd.apache.org/dev/dist/>
>
> Your votes please;
>
> +/- 1
> [ ] Release httpd-2.3.4 as Alpha
>
> Vote closes at 18:00 UTC on Monday November 30 2009.
>
> May your Thanksgiving be filled with Turkey and httpd testing,
>
> Thanks,
>
> Paul
>
Re: [VOTE] Release httpd 2.3.4-alpha
Posted by Paul Querna <pa...@querna.org>.
On Tue, Dec 1, 2009 at 1:30 AM, Joe Orton <jo...@redhat.com> wrote:
> On Wed, Nov 25, 2009 at 02:43:42PM -0800, Paul Querna wrote:
>> Test tarballs for Apache httpd 2.3.4-alpha are available at:
>> <http://httpd.apache.org/dev/dist/>
>>
>> Your votes please;
>>
>> +/- 1
>> [+1] Release httpd-2.3.4 as Alpha
>
> Sorry I'm late - thanks for RMing! +1 here for Alpha.
>
> * passes httpd-test
> * passes litmus
> * manual inspection looks good, though CHANGES thinks it is 2.3.3
Yes, I noticed the CHANGES issue after tagging/rollling/signing
everything. Not a big issue, and I've fixed up trunk so this should
be right for the 'next' alpha.
Re: [VOTE] Release httpd 2.3.4-alpha
Posted by Joe Orton <jo...@redhat.com>.
On Wed, Nov 25, 2009 at 02:43:42PM -0800, Paul Querna wrote:
> Test tarballs for Apache httpd 2.3.4-alpha are available at:
> <http://httpd.apache.org/dev/dist/>
>
> Your votes please;
>
> +/- 1
> [+1] Release httpd-2.3.4 as Alpha
Sorry I'm late - thanks for RMing! +1 here for Alpha.
* passes httpd-test
* passes litmus
* manual inspection looks good, though CHANGES thinks it is 2.3.3
Regards, Joe
Re: [VOTE] Release httpd 2.3.4-alpha
Posted by Jeff Trawick <tr...@gmail.com>.
On Wed, Nov 25, 2009 at 7:09 PM, Paul Querna <pa...@querna.org> wrote:
> On Wed, Nov 25, 2009 at 2:43 PM, Paul Querna <pa...@querna.org> wrote:
>> Test tarballs for Apache httpd 2.3.4-alpha are available at:
>> <http://httpd.apache.org/dev/dist/>
>>
>> Your votes please;
>>
>> +/- 1
>> [ ] Release httpd-2.3.4 as Alpha
>>
>> Vote closes at 18:00 UTC on Monday November 30 2009.
>>
>> May your Thanksgiving be filled with Turkey and httpd testing,
>
> Problems encountered when installing on aurora.apache.org (Solaris 10/SPARC):
> - Had to modify configure scripts to use /bin/bash instead of /bin/sh (ideas?)
> - Had to `ln -s apr_dbm_db.so apr_dbm_db-1.so`, otherwise all DBM
> functions fail.
Solaris 10 U5 x86:
no issues using just the httpd-2.3.4 tarball, building against
apr/apr-util 1.4.x HEAD
no httpd test failures with event MPM other than the info.t issue
I had some configure issues using the -deps tarball, but I haven't investigated.
Re: [VOTE] Release httpd 2.3.4-alpha
Posted by Paul Querna <pa...@querna.org>.
On Wed, Nov 25, 2009 at 2:43 PM, Paul Querna <pa...@querna.org> wrote:
> Test tarballs for Apache httpd 2.3.4-alpha are available at:
> <http://httpd.apache.org/dev/dist/>
>
> Your votes please;
>
> +/- 1
> [ ] Release httpd-2.3.4 as Alpha
>
> Vote closes at 18:00 UTC on Monday November 30 2009.
>
> May your Thanksgiving be filled with Turkey and httpd testing,
Problems encountered when installing on aurora.apache.org (Solaris 10/SPARC):
- Had to modify configure scripts to use /bin/bash instead of /bin/sh (ideas?)
- Had to `ln -s apr_dbm_db.so apr_dbm_db-1.so`, otherwise all DBM
functions fail.
Otherwise it seems to be running fine as www.apache.org w/ the Event MPM.
Re: [VOTE] Release httpd 2.3.4-alpha
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
Paul Querna wrote:
>
> I don't agree that we can't release a bundled unreleased version of
> APR, we did this for many versions of httpd 2.0.x and 2.1.x. It
> definitely isn't preferred, but that's the APR project's problem.
Look, your argument simply doesn't fly.
In httpd 2.0 timeframe we were only shipping apr-0.9.x - it did NOT
have the same API/ABI constraints (some of them, but not all). All
of those intermediary releases kept the ABI rules of APR.
Now that you have shipped immediately while ignoring my objection,
I'll treat all +1's as binding no matter if they approved both of
the pieces or not, and have tagged 1.4.0 of both apr and apr-util.
We have no alternative, or else all author's VERSION_MAJOR/MINOR
tests are invalid.
It becomes up to the APR project if this aught to be 1.4.0 or burn
a number and move on. For 1.4 initial release, I want to pick up
Branko's fix, so I plan to label this 1.4.1.
No intention of tagging apr-util yet till we decide if it can be
API frozen, so if we dislike the current includes/ tree, it will
end up being deprecated interfaces and version 1.5.0 already.
Re: [VOTE] Release httpd 2.3.4-alpha
Posted by Paul Querna <pa...@querna.org>.
On Mon, Nov 30, 2009 at 11:34 PM, William A. Rowe Jr.
<wr...@rowe-clan.net> wrote:
> Paul Querna wrote:
>>
>> I am trying to parse what you mean by this vote Bill.
>>
>> The vote is on all of the source release, including the -deps
>> tarballs. For the terms of the vote, I will interpret this as a -1 on
>> the entire release.
>
> That's fine. I interpret 'our release' as httpd. If httpd is ready,
> it should keep moving, and the -deps package, while nice for GA, really
> isn't necessary for alphas IMHO.
>
>> I agree, the root of the problem is the APR project, and they should
>> do a release when they see fit.
>
> Agreed. And that falls on you or I also, of course. Expecting that
> we can agree to a release this week, sorry that overwork and lack of
> vision contributed to my dropping the ball on releasing apr-1.4 (not
> apr-util-1.4 where many 'questionable additions' reside).
>
>> I don't agree that we can't release a bundled unreleased version of
>> APR, we did this for many versions of httpd 2.0.x and 2.1.x. It
>> definitely isn't preferred, but that's the APR project's problem.
>
> And we voted on that and released it. After about a year of that chaos
> it evolved to apr releasing their own releases. That's bootstrapping.
>
> It was part of the same package. You've split this into two packages,
> so I truly can't discern your argument that '-deps' is mandatory for
> httpd to even ship.
>
> Finally, I have yet to see any feedback on the pcre mandatory dependency
> issue. Comments?
On most platforms PCRE is a pretty common library these days. I
believe it is either in the standard install or easy to install on all
linux/osx/freebsd/etc versions. The common case is that people have
PCRE already somewhere on their system, unlike APR 1.4.x -- Most
people will not have that already installed.
I view libpcre as the same status as libz or libssl, both libraries
are widely distribtued, versioned and patched by OS Vendors, and
therefore should not be bundled, again in contrast to APR 1.4.x, which
no OS vendor bundles (yet).
Re: [VOTE] Release httpd 2.3.4-alpha
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
Paul Querna wrote:
>
> I am trying to parse what you mean by this vote Bill.
>
> The vote is on all of the source release, including the -deps
> tarballs. For the terms of the vote, I will interpret this as a -1 on
> the entire release.
That's fine. I interpret 'our release' as httpd. If httpd is ready,
it should keep moving, and the -deps package, while nice for GA, really
isn't necessary for alphas IMHO.
> I agree, the root of the problem is the APR project, and they should
> do a release when they see fit.
Agreed. And that falls on you or I also, of course. Expecting that
we can agree to a release this week, sorry that overwork and lack of
vision contributed to my dropping the ball on releasing apr-1.4 (not
apr-util-1.4 where many 'questionable additions' reside).
> I don't agree that we can't release a bundled unreleased version of
> APR, we did this for many versions of httpd 2.0.x and 2.1.x. It
> definitely isn't preferred, but that's the APR project's problem.
And we voted on that and released it. After about a year of that chaos
it evolved to apr releasing their own releases. That's bootstrapping.
It was part of the same package. You've split this into two packages,
so I truly can't discern your argument that '-deps' is mandatory for
httpd to even ship.
Finally, I have yet to see any feedback on the pcre mandatory dependency
issue. Comments?
Re: [VOTE] Release httpd 2.3.4-alpha
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
Paul Querna wrote:
>
> I don't agree that we can't release a bundled unreleased version of
> APR, we did this for many versions of httpd 2.0.x and 2.1.x. It
> definitely isn't preferred, but that's the APR project's problem.
Look, your argument simply doesn't fly.
In httpd 2.0 timeframe we were only shipping apr-0.9.x - it did NOT
have the same API/ABI constraints (some of them, but not all). All
of those intermediary releases kept the ABI rules of APR.
Now that you have shipped immediately while ignoring my objection,
I'll treat all +1's as binding no matter if they approved both of
the pieces or not, and have tagged 1.4.0 of both apr and apr-util.
We have no alternative, or else all author's VERSION_MAJOR/MINOR
tests are invalid.
It becomes up to the APR project if this aught to be 1.4.0 or burn
a number and move on. For 1.4 initial release, I want to pick up
Branko's fix, so I plan to label this 1.4.1.
No intention of tagging apr-util yet till we decide if it can be
API frozen, so if we dislike the current includes/ tree, it will
end up being deprecated interfaces and version 1.5.0 already.
Re: [VOTE] Release httpd 2.3.4-alpha
Posted by Paul Querna <pa...@querna.org>.
On Mon, Nov 30, 2009 at 4:48 PM, William A. Rowe Jr.
<wr...@rowe-clan.net> wrote:
> Paul Querna wrote:
>> Test tarballs for Apache httpd 2.3.4-alpha are available at:
>> <http://httpd.apache.org/dev/dist/>
>>
>> Your votes please;
>>
>> +/- 1
>> [ ] Release httpd-2.3.4 as Alpha
>
> +1 for httpd-2.3.4-alpha.tar.gz
>
> -1 for httpd-2.3.4-alpha-deps.tar.gz ...
>
> and since httpd-2.3.4-alpha-deps is not the same (and is in fact an
> entirely separate package of unreleased software), is not necessarily
> tested as part of registering this vote you called above, I must insist
> you hold a separate vote on that package to call it a release, or in any
> way park it on httpd://www.a.o/dist/. I personally might vote against,
> but it's the [explicit] decision of the httpd PMC folks to decide if this
> does or doesn't happen.
I am trying to parse what you mean by this vote Bill.
The vote is on all of the source release, including the -deps
tarballs. For the terms of the vote, I will interpret this as a -1 on
the entire release.
I agree, the root of the problem is the APR project, and they should
do a release when they see fit.
I don't agree that we can't release a bundled unreleased version of
APR, we did this for many versions of httpd 2.0.x and 2.1.x. It
definitely isn't preferred, but that's the APR project's problem.
Thanks,
Paul
Re: [VOTE] Release httpd 2.3.4-alpha
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
Paul Querna wrote:
> Test tarballs for Apache httpd 2.3.4-alpha are available at:
> <http://httpd.apache.org/dev/dist/>
>
> Your votes please;
>
> +/- 1
> [ ] Release httpd-2.3.4 as Alpha
+1 for httpd-2.3.4-alpha.tar.gz
-1 for httpd-2.3.4-alpha-deps.tar.gz ...
and since httpd-2.3.4-alpha-deps is not the same (and is in fact an
entirely separate package of unreleased software), is not necessarily
tested as part of registering this vote you called above, I must insist
you hold a separate vote on that package to call it a release, or in any
way park it on httpd://www.a.o/dist/. I personally might vote against,
but it's the [explicit] decision of the httpd PMC folks to decide if this
does or doesn't happen.
And thanks for your hard work on this, especially to the whole crew who
is helping out and keeping it caught up. I don't mind that 2.3.4 would
ship without support for this-or-that platform, that's the point of alpha,
to get something into somebody's hands. I'm regaining my vision fairly
quickly, and just as quickly discovered a couple things were out of whack
on my win32 build system. But after some quick provisioning, it looks
like a vc6 build works like a champ out of trunk, I will commit the add
of mod_proxy_scgi proposed by Gregg, and recheck it all with VC9.
Looking like progress :)