Re: [vote] 2.2.0 tarballs
On Wed, Nov 30, 2005 at 07:10:37PM -0600, William Rowe wrote: Colm MacCarthaigh wrote: If apr 1.0 or 1.1 happen to be installed, I don't see why it's not reasonable to fail to configure. The administrator may intend to link against the system version, they may not want httpd having its own libapr. And they're the only people capable of making that decision and hence resolving the conflict. They can decide to install over their existing apr, or to install a new one just for httpd. I brought this exact issue up weeks ago, and it didn't go very far. I was originally -1, for the very same reasons you are, but having thought about it decided that yes, while the present system introduces some inconvienence for a small fraction of users, it doesn't try to second guess them either, and unbundling apr/apr-util would represent a huge inconvienence to a large fraction of users. I read this a bit backwards of your interpretation; * admins who install 1.1 for some specific reason are responsible to ensure they deal with the new package correctly (e.g., we give them a message upon configure Found old APR 1.1.0, installing APR 1.2.2 for you and let them decide what to do. 99% of the time, they must follow our advise and install 1.2.2 in the same prefix/ as httpd.) * the vast majority of users, who only have apr 1.0/1.1 due to svn or other intrapackage dependencies, get a free apr 1.2 without having to think about it. Make this whole headache a noop for them. If some random user has APR 1.1 installed in /usr/local/apr, and builds httpd 2.2 with --prefix=/usr/local/httpd-2.2, it would be a Bad Thing (and certainly, very surprising behaviour) if that httpd install went ahead and silently upgraded that APR install. (what if the APR configure options were wrong/different? what if the APR 1.1 build had been custom-patched? etc) Therefore I maintain that the current behaviour having configure fail if the system APR/apr-util is not of sufficient version is the right thing to do. The user can always force the use of the bundled copies (to be installed in the same $prefix as httpd) as had been said many times. And I for one don't want the headaches of the users@ trouble reports. I'd really prefer to see those who help out on users@ answering this objection, as opposed to the hackers who are detached from the user community pushing this out +1 over those user-supporters objections. Any users who run httpd are unlikely to have installed APR 1.[01] given that APR 1.x has never been supported by an httpd release to date. It's really only httpd/APR developers who are likely to get into this situation. (APR 1.x has never been shipped in a Subversion tarball) joe
Re: [vote] 2.2.0 tarballs
Roy T. Fielding wrote: On Nov 30, 2005, at 10:12 PM, William A. Rowe, Jr. wrote: So we've been compiling and improving the code, but the build/ install status is -worse- than httpd-2.0, ergo this is not the best version of apache now available and is -not- ready for GA. I just built from scratch using the tarball and the same options that any typical user would set: i.e., ./configure --prefix=/dist/test22 --enable-modules=all Zero problems. Ok, but did you try installing into a tree that has, say, a fink port of svn based on apr 1.0 or 1.1? We are (mostly) talking about where httpd is finding stale APR versions related to non-httpd packages. (Non-httpd, because httpd never has shipped anything but alphas based on 1.0 or 1.1.) I don't understand what you are talking about -- developers don't run ./buildconf on the source package. Only we do that. Ack, as I suggested, let's kill it in the source distro. again I have zero problems. The included versions of apr and apr-util are used in all of my tests. I've never installed apr-1.x in the OS system libraries. Why would anyone outside this list do that? That's my -main- worry, those that didn't intend/deliberately install apr at all, but picked up 1.0/1.1 from another package such as subversion. Bill
Re: [vote] 2.2.0 tarballs
Any users who run httpd are unlikely to have installed APR 1.[01] given that APR 1.x has never been supported by an httpd release to date. It's really only httpd/APR developers who are likely to get into this situation. (APR 1.x has never been shipped in a Subversion tarball) As far as i know APR 1.0 (1.1 perhaps) is the only APR that is available as a standalone APR with FreeBSD systems, and if i remember correctly that APR gets installed as a prereq for Subversion if you use ports to build it. Yes, this is probably not a very big problem as Subversion is most likely used only by developers or other knowledgeable people... however, i do not know how many other ports installations that are using this APR. (Worst case, some really common port uses it and all of a sudden this is a really big problem.) Just to lift the two issues i know of atm and make sure they are at least being documented, here they are. First off, configure does not like it when you give the httpd configure the source trees to use (without running any other configures first), and... as the configure clearly states that this should work, how many users do you think is gonna do the configure in both apr and apr-util first and then run the httpd configure? (Really?!) Not that many i think, and if this is really how its released, then there should be a clear statement somewhere in the install docs or in configure itself that this is not working, do it this way instead. Secondly, there was a huge buzz over mod_authn_dbd not working or being built... but i dont see any buzz over mod_authnz_ldap not working with newer versions of OpenSSL and OpenLDAP and mod_authnz_ldap is actually included in the build, this is an issue that also is a few weeks old, but has this even been documented somewhere? Actually, wrowe, is this still true? Havent heard anything so im kinda assuming that its still broken. And as OpenLDAP is commonly used for system wide authentication i can definitely see people screaming when they try to get their new Apache 2.2.0 to auth against it as well, using SSL that is. This seems like an issue that should be documented (if its still an issue) or i can see users@ beeing flooded here too. / Andreas
Re: [vote] 2.2.0 tarballs
On Thu, Dec 01, 2005 at 04:06:37AM -0600, William A. Rowe, Jr. wrote: Ok, but did you try installing into a tree that has, say, a fink port of svn based on apr 1.0 or 1.1? We are (mostly) talking about where httpd is finding stale APR versions related to non-httpd packages. (Non-httpd, because httpd never has shipped anything but alphas based on 1.0 or 1.1.) But are there any of these that we know of? fink's apr is 0.9 ; http://pdb.finkproject.org/pdb/package.php/apr and its svn depends on that too. This has got to affect a vanishly small user base of people who know what they're doing :) -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: [vote] 2.2.0 tarballs
On Thu, Dec 01, 2005 at 04:06:37AM -0600, William A. Rowe, Jr. wrote: Ok, but did you try installing into a tree that has, say, a fink port of svn based on apr 1.0 or 1.1? We are (mostly) talking about where httpd Subversion has never officially supported anything other than APR 0.9.x - i.e. what comes with httpd 2.0.x. Now, Subversion actually will work with APR 1.0 and higher mainly because I make it do so. I personally don't run much with APR 0.9.x any more, but I'm probably the only semi-active full committer on Subversion who does so. No one on the Subversion lists will discuss using SVN and APR 1.0+ until, and at least, httpd 2.2 goes GA. Chicken and egg in its finest. So, claiming that there may be Subversion clients based on APR 1.0 or 1.1 would be against everything that the Subversion team recommends. -- justin
Re: [vote] 2.2.0 tarballs
On Thu, Dec 01, 2005 at 11:11:26AM +0100, Andreas Lindström wrote: Any users who run httpd are unlikely to have installed APR 1.[01] given that APR 1.x has never been supported by an httpd release to date. It's really only httpd/APR developers who are likely to get into this situation. (APR 1.x has never been shipped in a Subversion tarball) As far as i know APR 1.0 (1.1 perhaps) is the only APR that is available as a standalone APR with FreeBSD systems Hmmm, The following list of ports; mod_webapp, flood, subversion, c_c++_reference-2.0.2_3, chora-2.0, cvs2svn-1.2.0, esvn-0.6.8, kdesdk-3.4.0, kdevelop-3.2.0, p5-Log-Accounting-SVK-0.03,, p5-SVN-Mirror-0.56, p5-SVN-Simple-0.27, p5-SVN-Web-0.38, p5-VCP-Dest-svk-0.28_1, psvn-10727, rapidsvn-0.7.0, subversion-1.1.3, subversion-perl-1.1.3, subversion-python-1.1.3, svk-0.30, instant-workstation-1.0_8, kdewebdev-3.4.0,2, p5-Kwiki-Archive-SVK-0.11, trac-0.8, kde-3.4.0 is the full list apr-1 in some form as a B-dep or an R-dep. instant-workstation and kde are a bit worrying it has to be said. Though I think the workaround is still acceptable. Just to lift the two issues i know of atm and make sure they are at least being documented, here they are. First off, configure does not like it when you give the httpd configure the source trees to use (without running any other configures first), and... as the configure clearly states that this should work, how many users do you think is gonna do the configure in both apr and apr-util first and then run the httpd configure? (Really?!) Not that many i think, and if this is really how its released, then there should be a clear statement somewhere in the install docs or in configure itself that this is not working, do it this way instead. That's what release notes are for :) -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: [vote] 2.2.0 tarballs
Joe Orton wrote: If some random user has APR 1.1 installed in /usr/local/apr, and builds httpd 2.2 with --prefix=/usr/local/httpd-2.2, it would be a Bad Thing (and certainly, very surprising behaviour) if that httpd install went ahead and silently upgraded that APR install. AGREED! Never silent - in fact if there is a conflict, present the user two command line options to choose between. (APR 1.x has never been shipped in a Subversion tarball) light bulb Seriously? No applications? That significantly weakens my initial objection, although still, this should be fixed soonish. Bill
Re: [vote] 2.2.0 tarballs
torsdagen den 1 december 2005 07.54 skrev Roy T. Fielding: On Nov 30, 2005, at 10:12 PM, William A. Rowe, Jr. wrote: I'm 100% conviced next to nobody on this list has been developing and testing httpd-2.2/apr-1.2 without their own in-tree tweaks. I'm as guilty as anyone. So we've been compiling and improving the code, but the build/ install status is -worse- than httpd-2.0, ergo this is not the best version of apache now available and is -not- ready for GA. I just built from scratch using the tarball and the same options that any typical user would set: i.e., ./configure --prefix=/dist/test22 --enable-modules=all Zero problems. I don't understand what you are talking about -- developers don't run ./buildconf on the source package. Only we do that. Even after I do a I added mysql support in apr-util-1.2.2 as per INSTALL.MySQL as a conditional build switch in our rpm package, that was only possible after doing a lot of hacks. -- Regards // Oden Eriksson Mandriva: http://www.mandriva.com NUX: http://li.nux.se
Re: [vote] 2.2.0 tarballs
On Thursday 01 December 2005 14:47, Oden Eriksson wrote: I added mysql support in apr-util-1.2.2 as per INSTALL.MySQL as a conditional build switch in our rpm package, that was only possible after doing a lot of hacks. Are those hacks anything we/I should know about and fix, or are they specific to your packaging? -- Nick Kew
Re: [vote] 2.2.0 tarballs
torsdagen den 1 december 2005 16.01 skrev Nick Kew: On Thursday 01 December 2005 14:47, Oden Eriksson wrote: I added mysql support in apr-util-1.2.2 as per INSTALL.MySQL as a conditional build switch in our rpm package, that was only possible after doing a lot of hacks. Are those hacks anything we/I should know about and fix, or are they specific to your packaging? Well if you want to fix it it would be great. basically what I had to do was to install these in the apr installbuilddir (in our apr-1.2.2 binary rpm): apr_common.m4 apr_hints.m4 apr_network.m4 apr_threads.m4 find_apr.m4 gen-build.py (I'm not sure all those *.m4 files was required) After that mimic buildconf by copying them to the apr-util-1.2.2/build/ directory, followed by libtoolize --copy --force; aclocal; autoconf --force; python build/gen-build.py make. After that apr-util-1.2.2 recognized the added apr_dbd_mysql.c source. Of course this was done at rpm build time for apr-util-1.2.2. Cheers. -- Regards // Oden Eriksson Mandriva: http://www.mandriva.com NUX: http://li.nux.se
Re: [vote] 2.2.0 tarballs
On 12/01/2005 08:15 AM, Sander Temme wrote: On Nov 30, 2005, at 10:53 PM, William A. Rowe, Jr. wrote: [..cut..] Is buildconf present? If the user runs it, does it corrupt the unpacked tree? If this is so, and it's broken, then perhaps remove buildconf throughout the tree, and the autoconf source files, resulting in a vanilla ./ configure for the resulting distribution package? Hm... you kinda need it if you drop in a custom module with its config5.m4 foo. Or if you want to build with a different libtool than httpd came with. I agree that's kinda deep though. BTW: buildconf is also used by the rpm spec file that is delivered with the tar ball. I wouldn't hold up the release for it. +1 Regards Rüdiger
Re: [vote] 2.2.0 tarballs
Ruediger Pluem wrote: BTW: buildconf is also used by the rpm spec file that is delivered with the tar ball. To be honest I don't think the rpm build script needs to run buildconf, it seems to be a hangup from when the spec file was the Redhat one, and they needed to do custom stuff, all of which has been removed. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: [vote] 2.2.0 tarballs
On 12/01/2005 10:01 PM, Graham Leggett wrote: Ruediger Pluem wrote: BTW: buildconf is also used by the rpm spec file that is delivered with the tar ball. To be honest I don't think the rpm build script needs to run buildconf, it seems to be a hangup from when the spec file was the Redhat one, and they needed to do custom stuff, all of which has been removed. I was also asking myself why it was in there. Seems to be pretty needless. So it's only a reminder that if it is decided to take it out of the tar ball then (at latest) the rpm spec file should be fixed. Regards Rüdiger
Re: [vote] 2.2.0 tarballs
Joe Orton wrote: It's pretty silly for anybody to suddenly wake up and declare some random bug as a showstopper for 2.2. Nobody has cared enough about the problem to fix it in the six months and four(?) 2.1.x alpha/beta releases that mod_dbd has been in the tree. So it clearly isn't really very critical to anybody, and isn't showstopper material. Exactly. I've stopped testing httpd-2.1.x because there was nobody interested in testing apr-iconv 1.1.1, a prereq to httpd-2.1/2.2. Without any community interest, httpd on Win32 is clearly my toy, not a project port. I have no intention of rolling any 2.2, voting on any 2.2, until httpd will either correctly build on unix against apr 1.2, or emit a sensible failure. REGARDLESS of whether apr 1.0/1.1 is installed in the system path. I'm voting -1 until the issue of packaging apr/apr-util/apr-iconv in the httpd tarball is resolved. The last I heard, there were folks voting AGAINST this, yet I saw these trees in httpd-2.1.10 tarball. Why? And the suggestion to have an httpd-2.x.x-bundle.tar.gz was raised, that we include apr/apr-util/kitchen sink. That never saw a resolution, with several of those against apr being rolled into httpd, also being against this proposal. No legitimate counterproposals were offered. There's no way that this list has agreement/concluded vote on if srclib/ should include apr/apr-util/expat, and when it's present ./configure is doing the wrong things. So we perpetuate (nay - it's made worse) the 2.0 just to push this out the door. Roy's point of how f'ed up many fink distributions are is rather funny, it's the reason my Mac isn't building httpd-2.2 from svn, and the reason I'm building new toolchains on Win32. The last thing I want is for httpd to be as much of a mess as most of the packages out there, today :-) Bill
Re: [vote] 2.2.0 tarballs
Jim Jagielski wrote: Joe Orton wrote: Win32 is not special. It's a second-class citizen if anything because it gets so little developer attention. Now *that's* a statement for the Release Notes :) Absolutely, add to this list AIX, OS2, Netware, BeOS, HPUX and many others. Not to mention OS/390, BS2000 and several others I don't think we can build on since 1.3. Perhaps the Apache HTTP Server for Linux 2.6/Solaris 10/BSD 4 would be a more appropriate name for this project, based on the current community participation, as long as we are going for Truth in Advertising. Of course there are maintainers for each of those 'others', but since active development has become nothing but Linux/Solaris/BSD we should specify supported platforms, not bother to list the dozens of platforms that are not as closely maintained. Bill
Re: [vote] 2.2.0 tarballs
Joost de Heer wrote: Win32 is not special. It's a second-class citizen if anything because it gets so little developer attention. And how many people compile the thing on Windows anyway, except the msi builder? My guess is that I need about 2 hands to count them Au contrare, I get feedback personally from about 25 people a year, that ping me personally about something, and about 5 folks who maintain their own bin distributions that include 'other things'. I count 10 people on this list alone who build for win32 when they have a reason to. And there are several posts a month to users@ or entries in the bugzilla from folks having problems. The question isn't how many you know are building, the question is how many we don't know. Success == silence :) Bill
Re: [vote] 2.2.0 tarballs
Once 2.2 is released we'll be working to use it -- and distribute it with our products -- on Windows, Solaris, and AIX. I throw in patches relevant to these platforms when possible, but I don't have the time or interest in native (non-Java) code anymore to help out more. -- Jess Holle William A. Rowe, Jr. wrote: Jim Jagielski wrote: Joe Orton wrote: Win32 is not special. It's a second-class citizen if anything because it gets so little developer attention. Now *that's* a statement for the Release Notes :) Absolutely, add to this list AIX, OS2, Netware, BeOS, HPUX and many others. Not to mention OS/390, BS2000 and several others I don't think we can build on since 1.3. Perhaps the Apache HTTP Server for Linux 2.6/Solaris 10/BSD 4 would be a more appropriate name for this project, based on the current community participation, as long as we are going for Truth in Advertising. Of course there are maintainers for each of those 'others', but since active development has become nothing but Linux/Solaris/BSD we should specify supported platforms, not bother to list the dozens of platforms that are not as closely maintained. Bill
Re: [vote] 2.2.0 tarballs
On Wed, Nov 30, 2005 at 09:22:58PM +, Nick Kew wrote: Can someone clarify: what happens *by default* if APR 1.0/1.1 is found on a target machine? If it tries to build against that, I'd support a -1. If it does something sensible - which could be emitting an error message and refusing to build - I'd not worry. It refuses to configure, you need to go build apr/apu 1.2 somewhere and reconfig with the --with-apr(-util) options. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: [vote] 2.2.0 tarballs
Nick Kew wrote: I diskile bundling APR, and dislike even more bundling third-party libs like expat and pcre. But I thought I/we had just lost that argument with louder voices. We lost the argument over pcre; our requirement is apparently just a little to particular to have the user obtain any distro of pcre, since it would not work out of the box. Not true, apparently, of expat, zlib, openssl, openldap, apr or apr-util.
Re: [vote] 2.2.0 tarballs
On Wed, Nov 30, 2005 at 02:43:24PM -0600, William A. Rowe, Jr. wrote: Exactly. I've stopped testing httpd-2.1.x because there was nobody interested in testing apr-iconv 1.1.1, a prereq to httpd-2.1/2.2. Without any community interest, httpd on Win32 is clearly my toy, not a project port. It was hardly nobody, I may be shoddily inexperienced with the win32 port, but I did go to the trouble of testing apr-iconv on win32 and have been regularly building 2.1/2.2 on win32 to make sure it builds/works for me. And we've heard from others doing the same. dbd slipped through because it wasn't included in the build environment, and hence did not affect the process. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: [vote] 2.2.0 tarballs
Build the php5apache2.dll ( php 5.1.1 apache2handler) with 2.2.0 on Win32. No issues. Steffen
Re: [vote] 2.2.0 tarballs
Colm MacCarthaigh wrote: On Wed, Nov 30, 2005 at 02:43:24PM -0600, William A. Rowe, Jr. wrote: It was hardly nobody, I may be shoddily inexperienced with the win32 port, but I did go to the trouble of testing apr-iconv on win32 and have been regularly building 2.1/2.2 on win32 to make sure it builds/works for me. And we've heard from others doing the same. It was close to nobody, the only reason it is released is that yourself, and Garrett both stepped up. But I posted far more pings than I received in testers, and it took two months :) Thank you two for the review, no slight intended. Bill
Re: [vote] 2.2.0 tarballs
On 11/30/05, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Colm MacCarthaigh wrote: On Wed, Nov 30, 2005 at 02:43:24PM -0600, William A. Rowe, Jr. wrote: It was hardly nobody, I may be shoddily inexperienced with the win32 port, but I did go to the trouble of testing apr-iconv on win32 and have been regularly building 2.1/2.2 on win32 to make sure it builds/works for me. And we've heard from others doing the same. It was close to nobody, the only reason it is released is that yourself, and Garrett both stepped up. But I posted far more pings than I received in testers, and it took two months :) Thank you two for the review, no slight intended. Wouldn't it help if (beta) binaries are posted to http://httpd.apache.org/download.cgi?
Re: [vote] 2.2.0 tarballs
Olaf van der Spek wrote: Wouldn't it help if (beta) binaries are posted to http://httpd.apache.org/download.cgi? In general yes. In the case I mentioned, NO - you cannot post a candidate which hasn't received 3 +1's, and you certainly cannot push it out to the mirrors. But our alphas/betas have been pushed out to download.cgi ... Apache HTTP Server 2.1.9-beta is also available although the apr-iconv-1.x component hadn't been released in time for any beta binaries from Win32. Bill
Re: [vote] 2.2.0 tarballs
Colm MacCarthaigh wrote: On Wed, Nov 30, 2005 at 09:22:58PM +, Nick Kew wrote: Can someone clarify: what happens *by default* if APR 1.0/1.1 is found on a target machine? If it tries to build against that, I'd support a -1. If it does something sensible - which could be emitting an error message and refusing to build - I'd not worry. It refuses to configure, you need to go build apr/apu 1.2 somewhere and reconfig with the --with-apr(-util) options. Ok, so explain to me why we wasted a MB or two distributing srclib/apr/ and srclib/apr-util/ when the result is; [EMAIL PROTECTED] httpd-2.2]$ ./configure checking for chosen layout... Apache checking for working mkdir -p... yes checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu Configuring Apache Portable Runtime library ... checking for APR... yes setting CC to gcc setting CPP to gcc -E setting CFLAGS to -g -O2 -pthread setting CPPFLAGS to -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE setting LDFLAGS to Configuring Apache Portable Runtime Utility library... checking for APR-util... yes checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking how to run the C preprocessor... gcc -E configure: Configuring PCRE regular expression library configuring package in srclib/pcre now checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking how to run the C preprocessor... gcc -E checking for egrep... grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking limits.h usability... yes checking limits.h presence... yes checking for limits.h... yes checking for an ANSI C-conforming const... yes checking for size_t... yes checking for bcopy... yes checking for memmove... yes checking for strerror... yes configure: creating ./config.status config.status: creating Makefile config.status: creating pcre.h config.status: creating pcre-config config.status: creating config.h config.status: executing default commands srclib/pcre configured properly setting AP_LIBS to /local0/asf/httpd-2.2/srclib/pcre/libpcre.la setting INCLUDES to -I$(top_builddir)/srclib/pcre Configuring Apache httpd ... adding -I. to INCLUDES adding -I$(top_srcdir)/os/$(OS_DIR) to INCLUDES adding -I$(top_srcdir)/server/mpm/$(MPM_SUBDIR_NAME) to INCLUDES adding -I$(top_srcdir)/modules/http to INCLUDES adding -I$(top_srcdir)/modules/filters to INCLUDES adding -I$(top_srcdir)/modules/proxy to INCLUDES adding -I$(top_srcdir)/include to INCLUDES adding -I$(top_srcdir)/modules/generators to INCLUDES adding -I$(top_srcdir)/modules/mappers to INCLUDES adding -I$(top_srcdir)/modules/database to INCLUDES adding -I/usr/local/include/apr-1 to INCLUDES Applying OS-specific hints for httpd ... forcing SINGLE_LISTEN_UNSERIALIZED_ACCEPT to 1 forcing AP_NONBLOCK_WHEN_MULTI_LISTEN to 1 checking for rm... /bin/rm checking for pkg-config... /usr/bin/pkg-config checking for rsync... /usr/bin/rsync checking for gawk... gawk checking whether ln -s works... yes checking for ranlib... ranlib checking for lynx... lynx checking for egrep... grep -E checking for AIX... no checking for library containing strerror... none required checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking minix/config.h usability... no checking minix/config.h presence... no checking for minix/config.h... no checking for APR version 1.2.0 or later... no configure: error: APR version 1.2.0 or later is required This appears to be the worst of both worlds. -1 for release of the proposed tarball in this state. Drop the srclib's or make the srclib's work, it doesn't that much matter to me. But the above is sillyness at it's worst. Bill
Re: [vote] 2.2.0 tarballs
Colm MacCarthaigh wrote: On Wed, Nov 30, 2005 at 09:22:58PM +, Nick Kew wrote: Can someone clarify: what happens *by default* if APR 1.0/1.1 is found on a target machine? If it tries to build against that, I'd support a -1. If it does something sensible - which could be emitting an error message and refusing to build - I'd not worry. It refuses to configure, you need to go build apr/apu 1.2 somewhere and reconfig with the --with-apr(-util) options. Ok, now what the heck? [EMAIL PROTECTED] httpd-2.2]$ configure: error: APR-util version 1.2.0 or later is required ./configure --prefix=/usr/local --with-apr=srclib/apr --with-apr-util=srclib/apr-util checking for chosen layout... Apache [...] checking for APR version 1.2.0 or later... yes checking for APR-util version 1.2.0 or later... no configure: error: APR-util version 1.2.0 or later is required [EMAIL PROTECTED] httpd-2.2]$ ls -al srclib total 48 drwxrwxr-x 4 wrowe wrowe 4096 Nov 30 18:32 . drwxrwxr-x 12 wrowe wrowe 4096 Nov 30 18:34 .. lrwxrwxrwx 1 wrowe wrowe 19 Nov 30 18:32 apr - /local0/asf/apr-1.2 lrwxrwxrwx 1 wrowe wrowe 24 Nov 30 18:32 apr-util - /local0/asf/apr-util-1.2 [...] [EMAIL PROTECTED] httpd-2.2]$ grep VERSION srclib/apr-util/apu-1-config APRUTIL_MAJOR_VERSION=1 APRUTIL_DOTTED_VERSION=1.2.3 Explanations?
Re: [vote] 2.2.0 tarballs
On Wed, Nov 30, 2005 at 06:33:51PM -0600, William A. Rowe, Jr. wrote: Ok, so explain to me why we wasted a MB or two distributing srclib/apr/ and srclib/apr-util/ when the result is; That's not the result when you don't have apr/apu 1.x [x:2] installed. apr and apr-util 1.2 are bundled for reasons of pragmatic convienence, recognising that the vast majority of people don't have these already. If apr 1.0 or 1.1 happen to be installed, I don't see why it's not reasonable to fail to configure. The administrator may intend to link against the system version, they may not want httpd having its own libapr. And they're the only people capable of making that decision and hence resolving the conflict. They can decide to install over their existing apr, or to install a new one just for httpd. I brought this exact issue up weeks ago, and it didn't go very far. I was originally -1, for the very same reasons you are, but having thought about it decided that yes, while the present system introduces some inconvienence for a small fraction of users, it doesn't try to second guess them either, and unbundling apr/apr-util would represent a huge inconvienence to a large fraction of users. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: [vote] 2.2.0 tarballs
On Wed, Nov 30, 2005 at 06:39:30PM -0600, William A. Rowe, Jr. wrote: Ok, now what the heck? Looks like you've pointed the --with-apr options at trees which have been built, but arn't installed targets. find_apr.m4 tests for bin/apr-1-config -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: [vote] 2.2.0 tarballs
On Thu, Dec 01, 2005 at 12:59:12AM +, Colm MacCarthaigh wrote: On Wed, Nov 30, 2005 at 06:39:30PM -0600, William A. Rowe, Jr. wrote: Ok, now what the heck? Looks like you've pointed the --with-apr options at trees which have been built, but arn't installed targets. find_apr.m4 tests for bin/apr-1-config Actually no, sorry, it should test for both. configuring the bundled apr, apr-util and then using the --with-apr and --with-apr-util options works for me. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: [vote] 2.2.0 tarballs
Colm MacCarthaigh wrote: If apr 1.0 or 1.1 happen to be installed, I don't see why it's not reasonable to fail to configure. The administrator may intend to link against the system version, they may not want httpd having its own libapr. And they're the only people capable of making that decision and hence resolving the conflict. They can decide to install over their existing apr, or to install a new one just for httpd. I brought this exact issue up weeks ago, and it didn't go very far. I was originally -1, for the very same reasons you are, but having thought about it decided that yes, while the present system introduces some inconvienence for a small fraction of users, it doesn't try to second guess them either, and unbundling apr/apr-util would represent a huge inconvienence to a large fraction of users. I read this a bit backwards of your interpretation; * admins who install 1.1 for some specific reason are responsible to ensure they deal with the new package correctly (e.g., we give them a message upon configure Found old APR 1.1.0, installing APR 1.2.2 for you and let them decide what to do. 99% of the time, they must follow our advise and install 1.2.2 in the same prefix/ as httpd.) * the vast majority of users, who only have apr 1.0/1.1 due to svn or other intrapackage dependencies, get a free apr 1.2 without having to think about it. Make this whole headache a noop for them. And I for one don't want the headaches of the users@ trouble reports. I'd really prefer to see those who help out on users@ answering this objection, as opposed to the hackers who are detached from the user community pushing this out +1 over those user-supporters objections. Bill
Re: [vote] 2.2.0 tarballs
On Wed, Nov 30, 2005 at 07:10:37PM -0600, William A. Rowe, Jr. wrote: * admins who install 1.1 for some specific reason are responsible to ensure they deal with the new package correctly (e.g., we give them a message upon configure Found old APR 1.1.0, installing APR 1.2.2 for you and let them decide what to do. 99% of the time, they must follow our advise and install 1.2.2 in the same prefix/ as httpd.) * the vast majority of users, who only have apr 1.0/1.1 due to svn or other intrapackage dependencies, get a free apr 1.2 without having to think about it. Make this whole headache a noop for them. And I for one don't want the headaches of the users@ trouble reports. I'd really prefer to see those who help out on users@ answering this objection, as opposed to the hackers who are detached from the user community pushing this out +1 over those user-supporters objections. User trouble reports can be easily mitigated by including the instructions; If you are installing on a system with apr/apr-util 1.0 or 1.1 installed, you must provide apr 1.2 manually. You can decide to upgrade your existing apr/apr-util installation(s) to 1.2, or may use the bundled versions like so; cd srclib/apr ; ./configure cd srclib/apr-util ; ./configure --with-apr=../apr ./configure --with-apr=srclib/apr --with-apr-util=srclib/apr-util in the release notes. There's no reason why this can't be fixed during 2.2, but with a months old issue, and no sign of a patch, should it hold up a GA? -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: [vote] 2.2.0 tarballs
On Nov 30, 2005, at 4:39 PM, William A. Rowe, Jr. wrote: ./configure --prefix=/usr/local --with-apr=srclib/apr --with-apr- util=srclib/apr-util checking for chosen layout... Apache [...] checking for APR version 1.2.0 or later... yes checking for APR-util version 1.2.0 or later... no configure: error: APR-util version 1.2.0 or later is required Heh. apr-util checks for apr in ../apr, which is broken behaviour. S. -- [EMAIL PROTECTED] http://www.temme.net/sander/ PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF
Re: [vote] 2.2.0 tarballs
On Thu, Dec 01, 2005 at 01:25:38AM +, Colm MacCarthaigh wrote: There's no reason why this can't be fixed during 2.2, but with a months old issue, and no sign of a patch, should it hold up a GA? No way. -- justin
Re: [vote] 2.2.0 tarballs
Sander Temme wrote: On Nov 30, 2005, at 4:39 PM, William A. Rowe, Jr. wrote: ./configure --prefix=/usr/local --with-apr=srclib/apr --with-apr- util=srclib/apr-util checking for chosen layout... Apache [...] checking for APR version 1.2.0 or later... yes checking for APR-util version 1.2.0 or later... no configure: error: APR-util version 1.2.0 or later is required Heh. apr-util checks for apr in ../apr, which is broken behaviour. I'm seeing this too... ./buildconf --with-apr=srclib/apr --with-apr-util=srclib/apr-util found apr source: srclib/apr found apr-util source: srclib/apr-util rebuilding srclib/apr/configure buildconf: checking installation... buildconf: python version 2.3.4 (ok) buildconf: autoconf version 2.59 (ok) buildconf: libtool version 1.5.20 (ok) Copying libtool helper files ... buildconf: Using libtool.m4 at /usr/local/share/aclocal/libtool.m4. Creating include/arch/unix/apr_private.h.in ... Creating configure ... Generating 'make' outputs ... rebuilding rpm spec file rebuilding srclib/apr-util/configure Problem finding apr source in ../apr. Use: --with-apr=[directory] ./buildconf failed for apr-util
Re: [vote] 2.2.0 tarballs
Colm MacCarthaigh wrote: There's no reason why this can't be fixed during 2.2, but with a months old issue, and no sign of a patch, should it hold up a GA? I'm 100% conviced next to nobody on this list has been developing and testing httpd-2.2/apr-1.2 without their own in-tree tweaks. I'm as guilty as anyone. So we've been compiling and improving the code, but the build/install status is -worse- than httpd-2.0, ergo this is not the best version of apache now available and is -not- ready for GA. Those hyper to release, why not make it usable by Joe anybody instead of only httpd-dev hacker who's used to 'fudging the build'? Bill
Re: [vote] 2.2.0 tarballs
On Nov 30, 2005, at 10:10 PM, William A. Rowe, Jr. wrote: Sander Temme wrote: On Nov 30, 2005, at 4:39 PM, William A. Rowe, Jr. wrote: ./configure --prefix=/usr/local --with-apr=srclib/apr --with-apr- util=srclib/apr-util checking for chosen layout... Apache [...] checking for APR version 1.2.0 or later... yes checking for APR-util version 1.2.0 or later... no configure: error: APR-util version 1.2.0 or later is required Heh. apr-util checks for apr in ../apr, which is broken behaviour. I'm seeing this too... ./buildconf --with-apr=srclib/apr --with-apr-util=srclib/apr-util found apr source: srclib/apr found apr-util source: srclib/apr-util rebuilding srclib/apr/configure buildconf: checking installation... buildconf: python version 2.3.4 (ok) buildconf: autoconf version 2.59 (ok) buildconf: libtool version 1.5.20 (ok) Copying libtool helper files ... buildconf: Using libtool.m4 at /usr/local/share/aclocal/libtool.m4. Creating include/arch/unix/apr_private.h.in ... Creating configure ... Generating 'make' outputs ... rebuilding rpm spec file rebuilding srclib/apr-util/configure Problem finding apr source in ../apr. Use: --with-apr=[directory] ./buildconf failed for apr-util I'm looking at this. If you give that apu buildconf the right --with- apr parameter, buildconf completes. The problem is, if the apr_src_dir is relative, when we call buildconf we have already descended into srclib/apr-util so the relative reference is broken. I'm trying to wrap my common cold-addled brain around this and hope to have a patch by the time this episode of Law Order is over. S. -- [EMAIL PROTECTED] http://www.temme.net/sander/ PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF
Re: [vote] 2.2.0 tarballs
On Nov 30, 2005, at 10:12 PM, William A. Rowe, Jr. wrote: I'm 100% conviced next to nobody on this list has been developing and testing httpd-2.2/apr-1.2 without their own in-tree tweaks. I'm as guilty as anyone. So we've been compiling and improving the code, but the build/ install status is -worse- than httpd-2.0, ergo this is not the best version of apache now available and is -not- ready for GA. I just built from scratch using the tarball and the same options that any typical user would set: i.e., ./configure --prefix=/dist/test22 --enable-modules=all Zero problems. I don't understand what you are talking about -- developers don't run ./buildconf on the source package. Only we do that. Even after I do a make extraclean ./buildconf ./configure --prefix=/dist/test22 --enable-modules=most again I have zero problems. The included versions of apr and apr-util are used in all of my tests. I've never installed apr-1.x in the OS system libraries. Why would anyone outside this list do that? Those hyper to release, why not make it usable by Joe anybody instead of only httpd-dev hacker who's used to 'fudging the build'? Whatever problem you are encountering, please fix it on trunk. I see no evidence that it will cause people outside the APR core development group any grief for httpd-2.2, and even then a workaround can be described on the website. Roy
Re: [vote] 2.2.0 tarballs
Justin Erenkrantz wrote: On Wed, Nov 30, 2005 at 10:35:07PM -0800, Sander Temme wrote: I'm looking at this. If you give that apu buildconf the right --with- apr parameter, buildconf completes. The problem is, if the Just to reiterate - buildconf is not necessary for users to run. Therefore, if it's broken for 2.2.0, it's not a showstopper. -- justin Is buildconf present? If the user runs it, does it corrupt the unpacked tree? If this is so, and it's broken, then perhaps remove buildconf throughout the tree, and the autoconf source files, resulting in a vanilla ./configure for the resulting distribution package?
Re: [vote] 2.2.0 tarballs
On Nov 30, 2005, at 10:53 PM, William A. Rowe, Jr. wrote: Justin Erenkrantz wrote: On Wed, Nov 30, 2005 at 10:35:07PM -0800, Sander Temme wrote: I'm looking at this. If you give that apu buildconf the right -- with- apr parameter, buildconf completes. The problem is, if the Just to reiterate - buildconf is not necessary for users to run. Therefore, if it's broken for 2.2.0, it's not a showstopper. -- justin Is buildconf present? If the user runs it, does it corrupt the unpacked tree? If this is so, and it's broken, then perhaps remove buildconf throughout the tree, and the autoconf source files, resulting in a vanilla ./ configure for the resulting distribution package? Hm... you kinda need it if you drop in a custom module with its config5.m4 foo. Or if you want to build with a different libtool than httpd came with. I agree that's kinda deep though. I wouldn't hold up the release for it. S. -- [EMAIL PROTECTED] http://www.temme.net/sander/ PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF
Re: [vote] 2.2.0 tarballs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Nov 28, 2005, at 11:55 PM, Paul Querna wrote: Available from: http://people.apache.org/~pquerna/dev/httpd-2.2.0/ Please vote on releasing as GA/Stable. +1 for release as 2.2.0. I have verified the signatures, compared the contents, diffed versus the post-tarball httpd-2.2 changes, and tested on OS X 10.4.3 using Xcode 2.2. You can add the following signatures to the asc files if you like, minus the indent, assuming you can verify them afterward). httpd-2.2.0.tar.bz2.asc: -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (Darwin) iD8DBQBDjqBqW5aAEOBPmokRAmt6AJ0VpGAZAeSw6sDKp/NftIVFFeaF4ACeL+CB Ljif/NCrZXEpktnVTt3uCPs= =mtfD -END PGP SIGNATURE- httpd-2.2.0.tar.gz.asc: -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (Darwin) iD8DBQBDjqBXW5aAEOBPmokRAlXHAKCUE/dZdsXikx11CuYkBoCr28WYqgCfYuTv +qPQnF9uCcmV+n/ZUFW8jTo= =HJ0S -END PGP SIGNATURE- Cheers, Roy T. Fieldinghttp://roy.gbiv.com/ Chief Scientist, Day Software http://www.day.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (Darwin) iD8DBQFDjqMxW5aAEOBPmokRAiouAKCH5He8ly1ngnyUcM+CB2F6tTjpHgCdHfzy +XMSmJzDWHeA4GI9K09w+Fs= =SNvw -END PGP SIGNATURE-
Re: [vote] 2.2.0 tarballs
On Thu, Dec 01, 2005 at 12:53:22AM -0600, William A. Rowe, Jr. wrote: Is buildconf present? If the user runs it, does it corrupt the unpacked tree? Um. Have you even *tried* to run './buildconf' in an extracted httpd 2.2.0 tarball? I have - guess what? It works just fine. Therefore, there is no corruption. The default case with no arguments works exactly as expected. It only goes wonky if you give it bad arguments. It might not be as robust as we might like (the fact that it switches directories means passing --with-apr doesn't work as expected - yawn - don't specify the args!). The case remains that the default arguments (i.e. none) to buildconf work. If this particular corner case bugs you so much, you can go and commit a fix yourself - I'll even vote for it to be backported for 2.2.1. Still, I've yet to see a single issue - including this one - raised that would cause to me to even consider changing my +1 vote for GA. -- justin
Re: [vote] 2.2.0 tarballs
Paul Querna wrote: These tarballs are Identical to 2.1.10 except for two changes: * include/ap_release.h Updated to be 2.2.0-release * The root directory was changed from httpd-2.1.10 to httpd-2.2.0 Okay, I lied, slightly: * svn r348009: Added AP_DECLARE to mod_dbd exported functions. No functional changes for most operating systems. * svn r348055 and 348029: Netware specific fixes for a missing SSL CGI variable, and for linking to the correct sockets library. * Several Documentation only commits. (Including updating URLs in the README, UPDATING, etc..) -Paul
Re: [vote] 2.2.0 tarballs
On Mon, Nov 28, 2005 at 11:55:48PM -0800, Paul Querna wrote: These tarballs are Identical to 2.1.10 except for two changes: * include/ap_release.h Updated to be 2.2.0-release * The root directory was changed from httpd-2.1.10 to httpd-2.2.0 Available from: http://people.apache.org/~pquerna/dev/httpd-2.2.0/ Please vote on releasing as GA/Stable. +1 for GA based on my previous tests with 2.1.10 and a visual inspection of the recursive diff between the 2.1.10 and 2.2.0 tarballs (which is only 314 lines long anyway). I don't believe the mod_dbd change has any chance for negative impact and I don't run NetWare. Thanks. -- justin
Re: [vote] 2.2.0 tarballs
Justin Erenkrantz wrote: On Mon, Nov 28, 2005 at 11:55:48PM -0800, Paul Querna wrote: These tarballs are Identical to 2.1.10 except for two changes: * include/ap_release.h Updated to be 2.2.0-release * The root directory was changed from httpd-2.1.10 to httpd-2.2.0 Available from: http://people.apache.org/~pquerna/dev/httpd-2.2.0/ Please vote on releasing as GA/Stable. +1 for GA based on my previous tests with 2.1.10 and a visual inspection of the recursive diff between the 2.1.10 and 2.2.0 tarballs (which is only 314 lines long anyway). Easy way to see the diff: svn diff https://svn.apache.org/repos/asf/httpd/httpd/tags/2.1.10 https://svn.apache.org/repos/asf/httpd/httpd/tags/2.2.0 -Paul
Re: [vote] 2.2.0 tarballs
Available from: http://people.apache.org/~pquerna/dev/httpd-2.2.0/ FWIW, the MIME types for the .md5 files seem to be wrong. The .bz2.md5 is served as application/x-tar and .gz.md5 is application/x-gzip. Luc
Re: [vote] 2.2.0 tarballs
On Tuesday 29 November 2005 08:32, Paul Querna wrote: Paul Querna wrote: These tarballs are Identical to 2.1.10 except for two changes: * include/ap_release.h Updated to be 2.2.0-release * The root directory was changed from httpd-2.1.10 to httpd-2.2.0 Okay, I lied, slightly: * svn r348009: Added AP_DECLARE to mod_dbd exported functions. No functional changes for most operating systems. Yow! That reminds me: that was in response to someone complaining of a build failure on Windows, and he said it *still* failed with AP_DECLARE. Can someone with Windows *please* look at this? -1 for GA while this is outstanding! http://marc.theaimsgroup.com/?l=apache-httpd-devm=113266737311013w=2 -- Nick Kew
Re: [vote] 2.2.0 tarballs
On Mon, Nov 28, 2005 at 11:55:48PM -0800, Paul Querna wrote: These tarballs are Identical to 2.1.10 except for two changes: * include/ap_release.h Updated to be 2.2.0-release * The root directory was changed from httpd-2.1.10 to httpd-2.2.0 Available from: http://people.apache.org/~pquerna/dev/httpd-2.2.0/ Please vote on releasing as GA/Stable. A quick httpd-test pass on RHEL4/i686 FC3/i686 RHEL3/i686 RHEL3/ppc, plus manual testing, plus diff vs 2.1.10 inspection, +1 for GA. joe
Re: [vote] 2.2.0 tarballs
On 11/29/05, Paul Querna [EMAIL PROTECTED] wrote: Paul Querna wrote: These tarballs are Identical to 2.1.10 except for two changes: * include/ap_release.h Updated to be 2.2.0-release * The root directory was changed from httpd-2.1.10 to httpd-2.2.0 Okay, I lied, slightly: Shouldn't the final always be equal except version number to the last rc?
Re: [vote] 2.2.0 tarballs
I'm no commiter but must concur -- until the build runs cleanly on Windows 2.2.0 should not go out the door. Not everyone may like it, but Windows is a major Apache usage platform these days. -- Jess Holle Nick Kew wrote: On Tuesday 29 November 2005 08:32, Paul Querna wrote: Paul Querna wrote: These tarballs are Identical to 2.1.10 except for two changes: * include/ap_release.h Updated to be 2.2.0-release * The root directory was changed from httpd-2.1.10 to httpd-2.2.0 Okay, I lied, slightly: * svn r348009: Added AP_DECLARE to mod_dbd exported functions. No functional changes for most operating systems. Yow! That reminds me: that was in response to someone complaining of a build failure on Windows, and he said it *still* failed with AP_DECLARE. Can someone with Windows *please* look at this? -1 for GA while this is outstanding! http://marc.theaimsgroup.com/?l=apache-httpd-devm=113266737311013w=2
Re: [vote] 2.2.0 tarballs
On Tue, Nov 29, 2005 at 05:53:52AM -0600, Jess Holle wrote: I'm no commiter but must concur -- until the build runs cleanly on Windows 2.2.0 should not go out the door. Not everyone may like it, but Windows is a major Apache usage platform these days. mod_dbd isn't included in the win32 build environment yet, so it has no effect on a standard build. mod_dbd may or may not become available within the win32 build environment during the life of 2.2, but I don't think this should hold up GA. It's often the case that some modules or support utilities lag behind on win32. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: [vote] 2.2.0 tarballs
Colm MacCarthaigh wrote: On Tue, Nov 29, 2005 at 05:53:52AM -0600, Jess Holle wrote: I'm no commiter but must concur -- until the build runs cleanly on Windows 2.2.0 should not go out the door. Not everyone may like it, but Windows is a major Apache usage platform these days. mod_dbd isn't included in the win32 build environment yet, so it has no effect on a standard build. mod_dbd may or may not become available within the win32 build environment during the life of 2.2, but I don't think this should hold up GA. It's often the case that some modules or support utilities lag behind on win32. Ah... Sorry to jump the gun. I'm anxious to start the move to 2.2 on various platforms (Windows, Solaris, and AIX). -- Jess Holle
Re: [vote] 2.2.0 tarballs
Build with no issue here on Windows, except mod_authn_db and dmod_dbd. In the change log: *) Add mod_authn_dbd (SQL-based authentication) [Nick Kew] I agree with Jesse: 2.2.0 should not go out the door until we can build mod_authn_db and mod_dbd on windows. Steffen - Original Message - From: Colm MacCarthaigh [EMAIL PROTECTED] To: dev@httpd.apache.org Sent: Tuesday, November 29, 2005 1:24 PM Subject: Re: [vote] 2.2.0 tarballs On Tue, Nov 29, 2005 at 05:53:52AM -0600, Jess Holle wrote: I'm no commiter but must concur -- until the build runs cleanly on Windows 2.2.0 should not go out the door. Not everyone may like it, but Windows is a major Apache usage platform these days. mod_dbd isn't included in the win32 build environment yet, so it has no effect on a standard build. mod_dbd may or may not become available within the win32 build environment during the life of 2.2, but I don't think this should hold up GA. It's often the case that some modules or support utilities lag behind on win32. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: [vote] 2.2.0 tarballs
Steffen wrote: Build with no issue here on Windows, except mod_authn_db and dmod_dbd. In the change log: *) Add mod_authn_dbd (SQL-based authentication) [Nick Kew] I agree with Jesse: 2.2.0 should not go out the door until we can build mod_authn_db and mod_dbd on windows. +1 -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ If you can dodge a wrench, you can dodge a ball.
Re: [vote] 2.2.0 tarballs
On Tue, Nov 29, 2005 at 02:03:59PM +0100, Steffen wrote: Build with no issue here on Windows, except mod_authn_db and dmod_dbd. How are you building these? there's no .dsp file for either, nor are they in Makefile.win. The distributed source tree not building is one thing, but modules people are manually adding is another. In the change log: *) Add mod_authn_dbd (SQL-based authentication) [Nick Kew] I agree with Jesse: 2.2.0 should not go out the door until we can build mod_authn_db and mod_dbd on windows. Why? -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: [vote] 2.2.0 tarballs
On Tuesday 29 November 2005 12:24, Colm MacCarthaigh wrote: On Tue, Nov 29, 2005 at 05:53:52AM -0600, Jess Holle wrote: I'm no commiter but must concur -- until the build runs cleanly on Windows 2.2.0 should not go out the door. Not everyone may like it, but Windows is a major Apache usage platform these days. mod_dbd isn't included in the win32 build environment yet, so it has no effect on a standard build. That's another oversight. I can (reluctantly) live with that - though it should go into the release notes, or at least errata. The problem is when someone builds it themselves, and the build dies on them. What signal is that sending? That build, in the hands of someone who knows what he's doing, should NOT fail. Or, if it does, the fact MUST be clearly documented. It's a full week since I noted the issue in http://marc.theaimsgroup.com/?l=apache-httpd-devm=113266737311013w=2 That references the first, and so far only, report I've seen of anyone trying to build it on windows (for values of it encompassing ANY of 2.1.x). For the time being I'll be content with either a definite worksforme or a fails because that can be properly documented. But not with an undocumented situation that apparently leaves users just dangling. -- Nick Kew
Re: [vote] 2.2.0 tarballs
When I see this list then I get the feeling that 2.1/2.2 is not a lot tested on Win32 yet. I build 2.2 on Win32 (without mod_dbd). If you want to test it, you can get the win32 binary from me, please contact me off-list. Also I build some popular modules (mod_security, mod_view, mod_watch, mod_fcgid and mod_log_rotate), see www.apachelounge.com. Steffen - Original Message - From: Nick Kew [EMAIL PROTECTED] To: dev@httpd.apache.org Sent: Tuesday, November 29, 2005 2:25 PM Subject: Re: [vote] 2.2.0 tarballs On Tuesday 29 November 2005 12:24, Colm MacCarthaigh wrote: On Tue, Nov 29, 2005 at 05:53:52AM -0600, Jess Holle wrote: I'm no commiter but must concur -- until the build runs cleanly on Windows 2.2.0 should not go out the door. Not everyone may like it, but Windows is a major Apache usage platform these days. mod_dbd isn't included in the win32 build environment yet, so it has no effect on a standard build. That's another oversight. I can (reluctantly) live with that - though it should go into the release notes, or at least errata. The problem is when someone builds it themselves, and the build dies on them. What signal is that sending? That build, in the hands of someone who knows what he's doing, should NOT fail. Or, if it does, the fact MUST be clearly documented. It's a full week since I noted the issue in http://marc.theaimsgroup.com/?l=apache-httpd-devm=113266737311013w=2 That references the first, and so far only, report I've seen of anyone trying to build it on windows (for values of it encompassing ANY of 2.1.x). For the time being I'll be content with either a definite worksforme or a fails because that can be properly documented. But not with an undocumented situation that apparently leaves users just dangling. -- Nick Kew
Re: [vote] 2.2.0 tarballs
On Tue, Nov 29, 2005 at 02:03:59PM +0100, Steffen wrote: Build with no issue here on Windows, except mod_authn_db and dmod_dbd. In the change log: *) Add mod_authn_dbd (SQL-based authentication) [Nick Kew] I agree with Jesse: 2.2.0 should not go out the door until we can build mod_authn_db and mod_dbd on windows. It's pretty silly for anybody to suddenly wake up and declare some random bug as a showstopper for 2.2. Nobody has cared enough about the problem to fix it in the six months and four(?) 2.1.x alpha/beta releases that mod_dbd has been in the tree. So it clearly isn't really very critical to anybody, and isn't showstopper material. joe
Re: [vote] 2.2.0 tarballs
Joe Orton wrote: On Tue, Nov 29, 2005 at 02:03:59PM +0100, Steffen wrote: Build with no issue here on Windows, except mod_authn_db and dmod_dbd. In the change log: *) Add mod_authn_dbd (SQL-based authentication) [Nick Kew] I agree with Jesse: 2.2.0 should not go out the door until we can build mod_authn_db and mod_dbd on windows. It's pretty silly for anybody to suddenly wake up and declare some random bug as a showstopper for 2.2. Nobody has cared enough about the problem to fix it in the six months and four(?) 2.1.x alpha/beta releases that mod_dbd has been in the tree. So it clearly isn't really very critical to anybody, and isn't showstopper material. According to: http://httpd.apache.org/docs/2.1/new_features_2_2.html mod_dbd is explicitly mentioned as a new feature of 2.2 and, therefore, a compelling reason to upgrade. Either we stop refering to mod_dbd as something special enough to warrant special attention as a core enhancement or we fix it so it *is* one. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ If you can dodge a wrench, you can dodge a ball.
Re: [vote] 2.2.0 tarballs
Joe Orton wrote: On Tue, Nov 29, 2005 at 02:03:59PM +0100, Steffen wrote: Build with no issue here on Windows, except mod_authn_db and dmod_dbd. In the change log: *) Add mod_authn_dbd (SQL-based authentication) [Nick Kew] I agree with Jesse: 2.2.0 should not go out the door until we can build mod_authn_db and mod_dbd on windows. It's pretty silly for anybody to suddenly wake up and declare some random bug as a showstopper for 2.2. Nobody has cared enough about the problem to fix it in the six months and four(?) 2.1.x alpha/beta releases that mod_dbd has been in the tree. So it clearly isn't really very critical to anybody, and isn't showstopper material. As I noted in my previous e-mail, I was over-reacting as I did not understand this module was simply not part of the build on Windows yet. Steffan's thoughts may be quite different than mine on this matter, but I'd say go ahead and go for 2.2.0 if this is the biggest issue out there. [I'm much more concerned about authentication against multiple LDAPs than anything else in the authentication arena.] -- Jess Holle
Re: [vote] 2.2.0 tarballs
Jim Jagielski wrote: Joe Orton wrote: On Tue, Nov 29, 2005 at 02:03:59PM +0100, Steffen wrote: Build with no issue here on Windows, except mod_authn_db and dmod_dbd. In the change log: *) Add mod_authn_dbd (SQL-based authentication) [Nick Kew] I agree with Jesse: 2.2.0 should not go out the door until we can build mod_authn_db and mod_dbd on windows. It's pretty silly for anybody to suddenly wake up and declare some random bug as a showstopper for 2.2. Nobody has cared enough about the problem to fix it in the six months and four(?) 2.1.x alpha/beta releases that mod_dbd has been in the tree. So it clearly isn't really very critical to anybody, and isn't showstopper material. According to: http://httpd.apache.org/docs/2.1/new_features_2_2.html mod_dbd is explicitly mentioned as a new feature of 2.2 and, therefore, a compelling reason to upgrade. Either we stop refering to mod_dbd as something special enough to warrant special attention as a core enhancement or we fix it so it *is* one. That is a good point. Truth in advertising (as best as can be managed) will only help -- and lack thereof only hurt... -- Jess Holle
Re: [vote] 2.2.0 tarballs
On Tuesday 29 November 2005 15:03, Joe Orton wrote: On Tue, Nov 29, 2005 at 02:03:59PM +0100, Steffen wrote: Build with no issue here on Windows, except mod_authn_db and dmod_dbd. In the change log: *) Add mod_authn_dbd (SQL-based authentication) [Nick Kew] I agree with Jesse: 2.2.0 should not go out the door until we can build mod_authn_db and mod_dbd on windows. It's pretty silly for anybody to suddenly wake up and declare some random bug as a showstopper for 2.2. Nobody has cared enough about the problem to fix it in the six months and four(?) 2.1.x alpha/beta releases that mod_dbd has been in the tree. It works nicely on platforms I use. But last week was the first report of anyone building it on windows. Or rather, trying and failing to build it. I'd guess that's precisely because it's now stable for us as devs, a slightly wider circle of testers are looking at it. That's a Good Thing. When it goes GA, we can expect a *much* wider range of users, and they'll be less tolerant of things not working. I don't even know if it's a bug or a user error. If it is a bug, it would obviously be best to fix it, but an acceptable second-best is to document it. As for suddenly waking up, please note the date on http://marc.theaimsgroup.com/?l=apache-httpd-devm=113266737311013w=2 -- Nick Kew
Re: [vote] 2.2.0 tarballs
On Tue, Nov 29, 2005 at 10:16:04AM -0500, Jim Jagielski wrote: mod_dbd is explicitly mentioned as a new feature of 2.2 and, therefore, a compelling reason to upgrade. Either we stop refering to mod_dbd as something special enough to warrant special attention as a core enhancement or we fix it so it *is* one. The fact that no one has ever cared to make mod_dbd work on Windows until the precise instance that we're to go to GA is complete evidence that this is not a showstopper. It's not even in the default build! It can wait until the next release of 2.2. We can note it in the release notes and move along. -- justin
Re: [vote] 2.2.0 tarballs
Justin Erenkrantz wrote: On Tue, Nov 29, 2005 at 10:16:04AM -0500, Jim Jagielski wrote: mod_dbd is explicitly mentioned as a new feature of 2.2 and, therefore, a compelling reason to upgrade. Either we stop refering to mod_dbd as something special enough to warrant special attention as a core enhancement or we fix it so it *is* one. The fact that no one has ever cared to make mod_dbd work on Windows until the precise instance that we're to go to GA is complete evidence that this is not a showstopper. It's not even in the default build! It can wait until the next release of 2.2. We can note it in the release notes and move along. -- justin I would agree, as long as we remove it for the What's New pages until it actually works and builds. My point, obviously, was that we can't have it both ways and say mod_dbd is great and a new core enhancement if it doesn't even build under Win32. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ If you can dodge a wrench, you can dodge a ball.
Re: [vote] 2.2.0 tarballs
On Tue, Nov 29, 2005 at 10:28:43AM -0500, Jim Jagielski wrote: I would agree, as long as we remove it for the What's New pages until it actually works and builds. My point, obviously, was that we can't have it both ways and say mod_dbd is great and a new core enhancement if it doesn't even build under Win32. Win32 is one platform among many that we support. Additionally, we have very few developers who care to maintain Win32. mod_dbd apparently works just fine on every other platform. Therefore, I don't think removing it from the feature list is warranted. If no one cared about it until now, I don't care about it either. If mod_dbd didn't work on Darwin, I wouldn't ask that we remove it from the features list if it works on Linux, Solaris, and Win32. I'd ask that it be noted and move along. I don't know why we would or should grant special consideration to Win32 here. -- justin
Re: [vote] 2.2.0 tarballs
On 11/29/05, Justin Erenkrantz [EMAIL PROTECTED] wrote: On Tue, Nov 29, 2005 at 10:28:43AM -0500, Jim Jagielski wrote: I would agree, as long as we remove it for the What's New pages until it actually works and builds. My point, obviously, was that we can't have it both ways and say mod_dbd is great and a new core enhancement if it doesn't even build under Win32. Win32 is one platform among many that we support. Additionally, we have very few developers who care to maintain Win32. mod_dbd apparently works just fine on every other platform. Therefore, I don't think removing it from the feature list is warranted. If no one cared about it until now, I don't care about it either. If mod_dbd didn't work on Darwin, I wouldn't ask that we remove it from the features list if it works on Linux, Solaris, and Win32. I'd ask that it be noted and move along. I don't know why we would or should grant special consideration to Win32 here. -- justin Why not add a special 'except on Windows' clause to that page?
Re: [vote] 2.2.0 tarballs
On Nov 29, 2005, at 2:55 AM, Paul Querna wrote: These tarballs are Identical to 2.1.10 except for two changes: * include/ap_release.h Updated to be 2.2.0-release * The root directory was changed from httpd-2.1.10 to httpd-2.2.0 Available from: http://people.apache.org/~pquerna/dev/httpd-2.2.0/ Please vote on releasing as GA/Stable. Passes tests: +1 for GA.
Re: [vote] 2.2.0 tarballs
On Tue, Nov 29, 2005 at 10:28:43AM -0500, Jim Jagielski wrote: Justin Erenkrantz wrote: On Tue, Nov 29, 2005 at 10:16:04AM -0500, Jim Jagielski wrote: mod_dbd is explicitly mentioned as a new feature of 2.2 and, therefore, a compelling reason to upgrade. Either we stop refering to mod_dbd as something special enough to warrant special attention as a core enhancement or we fix it so it *is* one. The fact that no one has ever cared to make mod_dbd work on Windows until the precise instance that we're to go to GA is complete evidence that this is not a showstopper. It's not even in the default build! It can wait until the next release of 2.2. We can note it in the release notes and move along. -- justin I would agree, as long as we remove it for the What's New pages until it actually works and builds. My point, obviously, was that we can't have it both ways and say mod_dbd is great and a new core enhancement if it doesn't even build under Win32. Win32 is not special. It's a second-class citizen if anything because it gets so little developer attention. joe
Re: [vote] 2.2.0 tarballs
On Tue, Nov 29, 2005 at 04:38:01PM +0100, Olaf van der Spek wrote: Why not add a special 'except on Windows' clause to that page? It's not like it'll never work. Someone will get around to fixing it. IMHO, this is exactly what release notes are for. -- justin
Re: [vote] 2.2.0 tarballs
On Tuesday 29 November 2005 15:22, Justin Erenkrantz wrote: We can note it in the release notes and move along. -- justin Indeed, that's fine by me. I've just committed a documentation update to Trunk. If we backport that to branch-2.2, I'll withdraw my objections. -- Nick Kew
Re: [vote] 2.2.0 tarballs
The fact that no one has ever cared to make mod_dbd work on Windows until the precise instance that we're to go to GA is complete evidence that this is not a showstopper. It's not even in the default build! I cared, when I recall mod_dbd was compiling with a former apr (pity I do not know which version) For me is a reason to upgrade is mod_authn_db (which relies on mod_dbd) . When you guys go on with 2.2 then add also a note to mod_authn_db docu that it is not available on win32. Steffen - Original Message - From: Justin Erenkrantz [EMAIL PROTECTED] To: dev@httpd.apache.org; [EMAIL PROTECTED] Sent: Tuesday, November 29, 2005 4:22 PM Subject: Re: [vote] 2.2.0 tarballs On Tue, Nov 29, 2005 at 10:16:04AM -0500, Jim Jagielski wrote: mod_dbd is explicitly mentioned as a new feature of 2.2 and, therefore, a compelling reason to upgrade. Either we stop refering to mod_dbd as something special enough to warrant special attention as a core enhancement or we fix it so it *is* one. The fact that no one has ever cared to make mod_dbd work on Windows until the precise instance that we're to go to GA is complete evidence that this is not a showstopper. It's not even in the default build! It can wait until the next release of 2.2. We can note it in the release notes and move along. -- justin
Re: [vote] 2.2.0 tarballs
On Nov 29, 2005, at 10:36 AM, Justin Erenkrantz wrote: On Tue, Nov 29, 2005 at 10:28:43AM -0500, Jim Jagielski wrote: I would agree, as long as we remove it for the What's New pages until it actually works and builds. My point, obviously, was that we can't have it both ways and say mod_dbd is great and a new core enhancement if it doesn't even build under Win32. Win32 is one platform among many that we support. Additionally, we have very few developers who care to maintain Win32. mod_dbd apparently works just fine on every other platform. Therefore, I don't think removing it from the feature list is warranted. If no one cared about it until now, I don't care about it either. If mod_dbd didn't work on Darwin, I wouldn't ask that we remove it from the features list if it works on Linux, Solaris, and Win32. I'd ask that it be noted and move along. I don't know why we would or should grant special consideration to Win32 here. -- justin Either we: 1. Remove it from the feature list 2. Keep it in there, but document that it doesn't build under Win32 3. Someone who knows Win32 adds whatever magic is required to have it build. I don't care which one is done, but doing none is just plain sloppy, and we're better than that (or, at least, we *should* be).
Re: [vote] 2.2.0 tarballs
Joe Orton wrote: On Tue, Nov 29, 2005 at 10:28:43AM -0500, Jim Jagielski wrote: Justin Erenkrantz wrote: On Tue, Nov 29, 2005 at 10:16:04AM -0500, Jim Jagielski wrote: mod_dbd is explicitly mentioned as a new feature of 2.2 and, therefore, a compelling reason to upgrade. Either we stop refering to mod_dbd as something special enough to warrant special attention as a core enhancement or we fix it so it *is* one. The fact that no one has ever cared to make mod_dbd work on Windows until the precise instance that we're to go to GA is complete evidence that this is not a showstopper. It's not even in the default build! It can wait until the next release of 2.2. We can note it in the release notes and move along. -- justin I would agree, as long as we remove it for the What's New pages until it actually works and builds. My point, obviously, was that we can't have it both ways and say mod_dbd is great and a new core enhancement if it doesn't even build under Win32. Win32 is not special. It's a second-class citizen if anything because it gets so little developer attention. Now *that's* a statement for the Release Notes :) -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ If you can dodge a wrench, you can dodge a ball.
Re: [vote] 2.2.0 tarballs
On Tue, Nov 29, 2005 at 10:46:55AM -0500, Jim Jagielski wrote: Either we: 1. Remove it from the feature list 2. Keep it in there, but document that it doesn't build under Win32 3. Someone who knows Win32 adds whatever magic is required to have it build. #2 would be in the release notes. I don't think anyone has said we wouldn't note it. If someone figures out the necessary bits to twiddle by the time we make an announcement, we can stick it in the 'patches_to_apply' directory too. But, removing it from the feature list because it doesn't work on one platform out of many doesn't sit well with me. (And, it's not even in the default build for that platform anyway!) -- justin
Re: [vote] 2.2.0 tarballs
Justin Erenkrantz wrote: On Tue, Nov 29, 2005 at 10:46:55AM -0500, Jim Jagielski wrote: Either we: 1. Remove it from the feature list 2. Keep it in there, but document that it doesn't build under Win32 3. Someone who knows Win32 adds whatever magic is required to have it build. #2 would be in the release notes. I don't think anyone has said we wouldn't note it. That wasn't clear at the start of this thread. There was a tone of I don't care, that's no reason to stop the release and the impression that nothing would be done to address it. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ If you can dodge a wrench, you can dodge a ball.
Re: [vote] 2.2.0 tarballs
On Tue, Nov 29, 2005 at 10:56:56AM -0500, Jim Jagielski wrote: #2 would be in the release notes. I don't think anyone has said we wouldn't note it. That wasn't clear at the start of this thread. There was a tone of I don't care, that's no reason to stop the release and the impression that nothing would be done to address it. Well, that's just silly. If you read my replies about this, in almost every one, I said something about including it in the release notes and moving on. I'm sure no one really meant that we wouldn't make some mention of it in the appropriate places given that we now know about it. -- justin
Re: [vote] 2.2.0 tarballs
On Tue, Nov 29, 2005 at 03:20:50PM +, Nick Kew wrote: As for suddenly waking up, please note the date on http://marc.theaimsgroup.com/?l=apache-httpd-devm=113266737311013w=2 mod_dbd compiles fine for me when I remove the AP_DECLARE wrappers actually. But that might break the symbol export on Windows, I don't know. Doing a mod_cache/ldap-like workaround where a BDB_DECLARE maps to an _EXPORT macro is probably something that would make it work too. How do can I test mod_dbd to find out if my changes are commitable? -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: [vote] 2.2.0 tarballs
Win32 is not special. It's a second-class citizen if anything because it gets so little developer attention. And how many people compile the thing on Windows anyway, except the msi builder? My guess is that I need about 2 hands to count them Joost
Re: [vote] 2.2.0 tarballs
I didn't expect the NetWare fixes to go in until 2.2.1. Thanks for including them. +1 GA (NetWare) Brad On 11/29/2005 at 1:32:32 am, in message [EMAIL PROTECTED], [EMAIL PROTECTED] wrote: Paul Querna wrote: These tarballs are Identical to 2.1.10 except for two changes: * include/ap_release.h Updated to be 2.2.0-release * The root directory was changed from httpd-2.1.10 to httpd-2.2.0 Okay, I lied, slightly: * svn r348009: Added AP_DECLARE to mod_dbd exported functions. No functional changes for most operating systems. * svn r348055 and 348029: Netware specific fixes for a missing SSL CGI variable, and for linking to the correct sockets library. * Several Documentation only commits. (Including updating URLs in the README, UPDATING, etc..) -Paul
Re: [vote] 2.2.0 tarballs
We don't until the first GA release, but from there on out we compile just about every release ourselves as we often end up applying our own patches when we find issues (submitting them back, of course) and we do our own cross-platform installation packaging, automated configuration, etc, of Apache for our customers (so the raw build result is more useful). -- Jess Holle Joost de Heer wrote: Win32 is not special. It's a second-class citizen if anything because it gets so little developer attention. And how many people compile the thing on Windows anyway, except the msi builder? My guess is that I need about 2 hands to count them Joost
Re: [vote] 2.2.0 tarballs
Paul Querna wrote: Paul Querna wrote: These tarballs are Identical to 2.1.10 except for two changes: * include/ap_release.h Updated to be 2.2.0-release * The root directory was changed from httpd-2.1.10 to httpd-2.2.0 Okay, I lied, slightly: * svn r348009: Added AP_DECLARE to mod_dbd exported functions. No functional changes for most operating systems. * svn r348055 and 348029: Netware specific fixes for a missing SSL CGI variable, and for linking to the correct sockets library. * Several Documentation only commits. (Including updating URLs in the README, UPDATING, etc..) My vote, +1 for GA, tested lightly on FreeBSD 5.4/x86, and OSX 10.4.3/ppc. Also based on diff of the 2.1.10 and 2.2.0 tarballs. -Pau
Re: [vote] 2.2.0 tarballs
On Tue, Nov 29, 2005 at 09:30:30AM -0800, Paul Querna wrote: My vote, +1 for GA, tested lightly on FreeBSD 5.4/x86, and OSX 10.4.3/ppc. Also based on diff of the 2.1.10 and 2.2.0 tarballs. +1 here too, tested on ubuntu. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: [vote] 2.2.0 tarballs
On Tue, Nov 29, 2005 at 05:53:52AM -0600, Jess Holle wrote: I'm no commiter but must concur -- until the build runs cleanly on Windows 2.2.0 should not go out the door. Not everyone may like it, but Windows is a major Apache usage platform these days. O.k., can any win32 users please test the mod_dbd and mod_authn_dbd build environments that are now in trunk? -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: [vote] 2.2.0 tarballs
+1 on Mac OS. -wsv On Nov 28, 2005, at 11:55 PM, Paul Querna wrote: These tarballs are Identical to 2.1.10 except for two changes: * include/ap_release.h Updated to be 2.2.0-release * The root directory was changed from httpd-2.1.10 to httpd-2.2.0 Available from: http://people.apache.org/~pquerna/dev/httpd-2.2.0/ Please vote on releasing as GA/Stable. I am sorry for the confusion on whole move of 2.1.10 to 2.2.0. This entire situation is completely undefined in our VERSIONING file, and hasn't ever happened before with these versioning rules. I believe the best way to move forward for everyone is to vote on these 2.2.0 tarballs. Hopefully we can all learn from this, and come up with a better VERSIONING policy by the time we do 2.4. Thanks, Paul.
Re: [vote] 2.2.0 tarballs
tisdagen den 29 november 2005 08.55 skrev Paul Querna: These tarballs are Identical to 2.1.10 except for two changes: * include/ap_release.h Updated to be 2.2.0-release * The root directory was changed from httpd-2.1.10 to httpd-2.2.0 Available from: http://people.apache.org/~pquerna/dev/httpd-2.2.0/ Please vote on releasing as GA/Stable. I am sorry for the confusion on whole move of 2.1.10 to 2.2.0. This entire situation is completely undefined in our VERSIONING file, and hasn't ever happened before with these versioning rules. I believe the best way to move forward for everyone is to vote on these 2.2.0 tarballs. Hopefully we can all learn from this, and come up with a better VERSIONING policy by the time we do 2.4. Thanks, Paul. Seems to work great on Mandriva Linux (Cooker) x86 and x86_64, all tests passes (with php-4.4.1 and php-5.1.1) using the perl-framework r344476. -- Regards // Oden Eriksson Mandriva: http://www.mandriva.com NUX: http://li.nux.se
[vote] 2.2.0 tarballs
These tarballs are Identical to 2.1.10 except for two changes: * include/ap_release.h Updated to be 2.2.0-release * The root directory was changed from httpd-2.1.10 to httpd-2.2.0 Available from: http://people.apache.org/~pquerna/dev/httpd-2.2.0/ Please vote on releasing as GA/Stable. I am sorry for the confusion on whole move of 2.1.10 to 2.2.0. This entire situation is completely undefined in our VERSIONING file, and hasn't ever happened before with these versioning rules. I believe the best way to move forward for everyone is to vote on these 2.2.0 tarballs. Hopefully we can all learn from this, and come up with a better VERSIONING policy by the time we do 2.4. Thanks, Paul.
