Bug report for APR [2009/07/19]
+---+ | Bugzilla Bug ID | | +-+ | | Status: UNC=Unconfirmed NEW=New ASS=Assigned| | | OPN=ReopenedVER=Verified(Skipped Closed/Resolved) | | | +-+ | | | Severity: BLK=Blocker CRI=Critical REG=Regression MAJ=Major | | | | MIN=Minor NOR=NormalENH=Enhancement TRV=Trivial | | | | +-+ | | | | Date Posted | | | | | +--+ | | | | | Description | | | | | | | |16056|Inf|Enh|2003-01-14|Shared memory mutex ownership not correctly esta| |20382|New|Nor|2003-05-31|Poor performance on W2000 AS | |28453|New|Enh|2004-04-18|apr_uri should parse relative to a base URI | |33188|Inf|Nor|2005-01-21|libtool linking failure on Suse | |33490|Inf|Nor|2005-02-10|APR does not compile with Borland C++ | |38410|New|Nor|2006-01-27|apr/win32 misinterpreted the meaning of WAIT_ABAND| |39289|New|Enh|2006-04-12|test suite additions for trylock functions| |39853|Inf|Nor|2006-06-21|apr_strtoi64 does not build on WinCE due to lack o| |39895|New|Enh|2006-06-23|apr_os_strerror on WinCE needs to xlate unicode-u| |39896|New|Enh|2006-06-23|Output test status to OutputDebugString in additio| |40020|New|Enh|2006-07-11|Add support for apr_uint8_t and apr_int8_t types | |40193|Inf|Nor|2006-08-06|Patches to support different compiler than EMX on | |40622|New|Enh|2006-09-27|enhance apr temp files on NT to be more secure| |40758|Ver|Maj|2006-10-15|WIN64, apr_vformatter(..) cannot handle 64bit poin| |40939|New|Enh|2006-11-09|pool minimal allocation size should be configurabl| |41192|Inf|Trv|2006-12-17|Add the expat libtool file to the LT_LDFLAGS varia| |41254|New|Enh|2006-12-28|apr_queue_t enhancements | |41351|New|Enh|2007-01-11|Tivoli LDAP SDK support in aprutil| |41352|New|Min|2007-01-11|openldap and per-connection client certificates in| |41916|Inf|Nor|2007-03-21|MinGW support | |42365|New|Enh|2007-05-09|Suppress console for apr_proc_create() created pro| |42728|New|Nor|2007-06-23|mod_ssl thread detaching not releasing handles| |42848|New|Enh|2007-07-10|add IP TOS support to apr_socket_opt_set()| |43035|New|Enh|2007-08-04|Add ability to wrap ssl around pre-existing socket| |43066|New|Nor|2007-08-08|get_password on Windows is kludgy | |43152|Inf|Nor|2007-08-16|apr_socket_opt_get doesn't work with APR_SO_SNDBUF| |43172|Ass|Nor|2007-08-20|apr-util don't want to find mozldap-6.x | |43217|New|Min|2007-08-26|All-ones IPv6 subnet mask not accepted| |43244|New|Enh|2007-08-29|apr_socket_t missing dup, dup2 and setaside | |43302|New|Nor|2007-09-04|apr_bucket_socket doesn't work with non-connected | |43309|New|Enh|2007-09-05|add apr_socket_sendtov support| |43375|Ass|Nor|2007-09-13|Pool integrity check fails for apr threads| |43499|New|Nor|2007-09-27|apr_global_mutex_create returns error Access deni| |43507|New|Enh|2007-09-28|configure flag for SHELL_PATH | |43508|New|Enh|2007-09-28|Please be available whether atomics use thread mut| |43793|New|Enh|2007-11-04|builtin atomics on Windows| |44127|New|Enh|2007-12-21|File Extended Attributes Support | |44128|New|Enh|2007-12-21|apr_os_file_put() does not register a cleanup hand| |44129|New|Enh|2007-12-21|apr_os_dir_put() does not allocate an entry buffer| |44186|New|Nor|2008-01-08|[PATCH] Add memcached 1.2.4 features to apr_memcac| |44230|New|Enh|2008-01-14|Add Ark Linux support to config.layout| |44432|New|Enh|2008-02-15|patch - proposal for application function hooks | |44550|Inf|Maj|2008-03-06|Solaris sendfilev() handling - EINTR appears to ha| |44684|Inf|Nor|2008-03-26|32 libexpat used instead of 64 bit| |45232|New|Nor|2008-06-18|Empty APU_MODULES makes sh syntax error | |45256|New|Maj|2008-06-23|lack of object check for null value cause expectio| |45276|Opn|Nor|2008-06-25|Little issue with srclib/apr-util/Makefile| |45291|New|Nor|2008-06-26|apr_thread_t is leaking | |45298|New|Nor|2008-06-27|apr_os_thread_get() differs between windows and un| |45321|New|Nor|2008-07-01|Handling IPV6_V6ONLY on NT 5.x| |45389|New|Nor|2008-07-13|testrand fails 5 tests (55%) - line 62: randomnes|
Re: svn commit: r794485 - /apr/apr/trunk/configure.in
]] Bojan Smojver | However, there one could have an option to configure that forces new | functions (i.e. use AC_CHECK_FUNCS instead of the new elaborate tests), | because Fedora packages are targeted for a particular release. Not sure | if that is something Debian package do or not. You could force it on using apr_cv_epoll=yes ./configure and such, but ugh and eww. Debian does have a minimum kernel version that's supported, and for Etch (the previous release), that was «anything 2.6». I don't know if there is a tighter supported version for the current and next release, and even if it is, it doesn't change the principle we're discussing here. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: svn commit: r794485 - /apr/apr/trunk/configure.in
On Mon, 2009-07-20 at 08:13 +0200, Tollef Fog Heen wrote: You could force it on using apr_cv_epoll=yes ./configure and such, but ugh and eww. Ah, yes. There is always that too (note to self: edit Rawhide spec file when APR 1.3.7 gets released). Debian does have a minimum kernel version that's supported, and for Etch (the previous release), that was «anything 2.6». I don't know if there is a tighter supported version for the current and next release, and even if it is, it doesn't change the principle we're discussing here. I'll lay off this discussion and leave it up to other folks to decide what's appropriate. -- Bojan
Re: Intent to TR 2.2.12
On Jul 20, 2009, at 7:47 AM, Plüm, Rüdiger, VF-Group wrote: -Original Message- From: Jim Jagielski Sent: Montag, 20. Juli 2009 13:29 To: d...@httpd.apache.org Subject: Re: Intent to TR 2.2.12 HEAD on httpd-2.2 passes the perl framework tests and looks good. Planning on tagging/rolling later on today assuming nothing pops up, so please test beforehand :) What about the dup3 / accept4 and so on detection issue in APR? Do we want to see a fixed APR release before or do we live with this issue in 2.2.12? I get the impression that we won't be seeing a new APR release anytime soon, due to the concern on whether this is an APR issue or an OS related one. However, instead of waiting for a full APR release, it would be nice to maybe tag an interim version of APR and bundle *that* with 2.2.12... CCing d...@apr
Re: apr-1.3.6 on linux kernel 2.6.26
Looking over all this, I would like to suggest we do a quick 1.3.7 for APR, mostly so we can have httpd 2.2.12 ship with it. Comments? On Jul 16, 2009, at 6:30 PM, Bojan Smojver wrote: On Thu, 2009-07-16 at 20:42 +0200, Ruediger Pluem wrote: Does fixing this issue warrant yet another apr release? My vote would be yes. Version numbers are cheap. -- Bojan
Re: apr-1.3.6 on linux kernel 2.6.26
2009-07-20 15:28:25 Jim Jagielski napisał(a): On Jul 16, 2009, at 6:30 PM, Bojan Smojver wrote: On Thu, 2009-07-16 at 20:42 +0200, Ruediger Pluem wrote: Does fixing this issue warrant yet another apr release? My vote would be yes. Version numbers are cheap. Looking over all this, I would like to suggest we do a quick 1.3.7 for APR, mostly so we can have httpd 2.2.12 ship with it. Comments? +1. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: apr-1.3.6 on linux kernel 2.6.26
Jim Jagielski wrote: Looking over all this, I would like to suggest we do a quick 1.3.7 for APR, mostly so we can have httpd 2.2.12 ship with it. Comments? +1. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: apr-1.3.6 on linux kernel 2.6.26
We're looking at mainly the configure.in detection patch and a bunch of Netware updates, which look safe... So my pref will be to tag from HEAD. On Jul 20, 2009, at 9:45 AM, Graham Leggett wrote: Jim Jagielski wrote: Looking over all this, I would like to suggest we do a quick 1.3.7 for APR, mostly so we can have httpd 2.2.12 ship with it. Comments? +1. Regards, Graham --
Tagging APR-1.3.7 (Was: Re: apr-1.3.6 on linux kernel 2.6.26)
Later on today or tomorrow (to give people enough time to complain :) ) I will be tagging 1.3.7 from HEAD. We can choose to formal release or not (my pref is to release); I am mainly doing this so what we have is best version available as well as for the httpd 2.2.12 release... On Jul 20, 2009, at 10:10 AM, Jim Jagielski wrote: We're looking at mainly the configure.in detection patch and a bunch of Netware updates, which look safe... So my pref will be to tag from HEAD. On Jul 20, 2009, at 9:45 AM, Graham Leggett wrote: Jim Jagielski wrote: Looking over all this, I would like to suggest we do a quick 1.3.7 for APR, mostly so we can have httpd 2.2.12 ship with it. Comments? +1. Regards, Graham --
Re: Tagging APR-1.3.7 (Was: Re: apr-1.3.6 on linux kernel 2.6.26)
Jim Jagielski wrote: Later on today or tomorrow (to give people enough time to complain :) ) I will be tagging 1.3.7 from HEAD. We can choose to formal release or not (my pref is to release); I am mainly doing this so what we have is best version available as well as for the httpd 2.2.12 release... Is HEAD not currently v1.4.0? Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Tagging APR-1.3.7 (Was: Re: apr-1.3.6 on linux kernel 2.6.26)
HEAD of the 1.3 branch :) On Jul 20, 2009, at 11:21 AM, Graham Leggett wrote: Jim Jagielski wrote: Later on today or tomorrow (to give people enough time to complain :) ) I will be tagging 1.3.7 from HEAD. We can choose to formal release or not (my pref is to release); I am mainly doing this so what we have is best version available as well as for the httpd 2.2.12 release... Is HEAD not currently v1.4.0? Regards, Graham --
Re: Tagging APR-1.3.7 (Was: Re: apr-1.3.6 on linux kernel 2.6.26)
Jim Jagielski wrote: HEAD of the 1.3 branch :) Ack :) Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Tagging APR-1.3.7 (Was: Re: apr-1.3.6 on linux kernel 2.6.26)
2009/7/20 Jim Jagielski j...@jagunet.com: Later on today or tomorrow (to give people enough time to complain :) ) I will be tagging 1.3.7 from HEAD. We can choose to formal release or not (my pref is to release); I am mainly doing this so what we have is best version available as well as for the httpd 2.2.12 release... formal release. Do not release httpd with anon-formal release of apr, Thanks, Paul On Jul 20, 2009, at 10:10 AM, Jim Jagielski wrote: We're looking at mainly the configure.in detection patch and a bunch of Netware updates, which look safe... So my pref will be to tag from HEAD. On Jul 20, 2009, at 9:45 AM, Graham Leggett wrote: Jim Jagielski wrote: Looking over all this, I would like to suggest we do a quick 1.3.7 for APR, mostly so we can have httpd 2.2.12 ship with it. Comments? +1. Regards, Graham --
Re: Tagging APR-1.3.7 (Was: Re: apr-1.3.6 on linux kernel 2.6.26)
On 07/20/2009 05:18 PM, Jim Jagielski wrote: Later on today or tomorrow (to give people enough time to complain :) ) I will be tagging 1.3.7 from HEAD. We can choose to formal release or not (my pref is to release); I am mainly doing this so what we have is best version available as well as for the httpd 2.2.12 release... +1 on tagging and formal release. Regards Rüdiger
Re: Tagging APR-1.3.7 (Was: Re: apr-1.3.6 on linux kernel 2.6.26)
Jim Jagielski schrieb: Later on today or tomorrow (to give people enough time to complain :) ) I will be tagging 1.3.7 from HEAD. We can choose to formal release or not (my pref is to release); I am mainly doing this so what we have is best version available as well as for the httpd 2.2.12 release... +1 on tagging and formal release. Günter.
Re: Tagging APR-1.3.7 (Was: Re: apr-1.3.6 on linux kernel 2.6.26)
On Mon, Jul 20, 2009 at 8:18 AM, Jim Jagielskij...@jagunet.com wrote: Later on today or tomorrow (to give people enough time to complain :) ) I will be tagging 1.3.7 from HEAD. We can choose to formal release or not (my pref is to release); I am mainly doing this so what we have is best version available as well as for the httpd 2.2.12 release... I don't really see using a non-formal release for httpd as an option. I'd rather stay far away from going back down the bundling of unreleased versions path. In short, if we have a releasable APR, by all means tag :) Cheers, Sander On Jul 20, 2009, at 10:10 AM, Jim Jagielski wrote: We're looking at mainly the configure.in detection patch and a bunch of Netware updates, which look safe... So my pref will be to tag from HEAD. On Jul 20, 2009, at 9:45 AM, Graham Leggett wrote: Jim Jagielski wrote: Looking over all this, I would like to suggest we do a quick 1.3.7 for APR, mostly so we can have httpd 2.2.12 ship with it. Comments? +1. Regards, Graham --
Re: Tagging APR-1.3.7 (Was: Re: apr-1.3.6 on linux kernel 2.6.26)
Hi, Graham Leggett schrieb: Is HEAD not currently v1.4.0? I thought that HEAD is un-branched trunk = v2.0.0; and we have a branch-1.4.x trunk, a branch-1.3.x trunk, a branch-1.2.x trunk, ., and a branch-0.9.x trunk :) Günter.
Re: Tagging APR-1.3.7 (Was: Re: apr-1.3.6 on linux kernel 2.6.26)
OK... Before I tag and roll, I should likely downgrade from libtool2 to libtool1.5, right? Our distros should make that assumption, I think. On Jul 20, 2009, at 3:03 PM, Guenter Knauf wrote: Hi, Graham Leggett schrieb: Is HEAD not currently v1.4.0? I thought that HEAD is un-branched trunk = v2.0.0; and we have a branch-1.4.x trunk, a branch-1.3.x trunk, a branch-1.2.x trunk, ., and a branch-0.9.x trunk :) Günter.
Re: Intent to TR 2.2.12
Jim Jagielski wrote: However, instead of waiting for a full APR release, it would be nice to maybe tag an interim version of APR and bundle *that* with 2.2.12... No, it would not, httpd will not become responsible for APR's releases unless the APR project is folded and httpd project votes to accept the responsibility for this code. So... -1 on any APR fork in an httpd release (and my feelings are similar on PCRE or expat forks, and for very similar reasons).
Re: [VOTE] Release APR 1.3.7
Jim Jagielski wrote: Release candidate tarballs in usual location (http://apr.apache.org/dev/dist/) [not for distribution]. Vote starts as we speak and will run for 48 hours. OpenSolaris/x86: configure gets me gcc in preference to Sun CC which is the system default. All tests pass. If I explicitly select SunStudio CC, I can build with that, and again all tests pass. So all is basically well, but it would be good to compile by default with the same compiler as `which cc` on the host system! -- Nick Kew
Re: [VOTE] Release APR 1.3.7
Nick Kew wrote: Jim Jagielski wrote: Release candidate tarballs in usual location (http://apr.apache.org/dev/dist/) [not for distribution]. Vote starts as we speak and will run for 48 hours. OpenSolaris/x86: configure gets me gcc in preference to Sun CC which is the system default. All tests pass. If I explicitly select SunStudio CC, I can build with that, and again all tests pass. So all is basically well, but it would be good to compile by default with the same compiler as `which cc` on the host system! Agreed, but this is a regression?
Re: [VOTE] Release APR 1.3.7
2009/7/20 William A. Rowe, Jr. wr...@rowe-clan.net: Nick Kew wrote: Jim Jagielski wrote: Release candidate tarballs in usual location (http://apr.apache.org/dev/dist/) [not for distribution]. Vote starts as we speak and will run for 48 hours. OpenSolaris/x86: configure gets me gcc in preference to Sun CC which is the system default. All tests pass. If I explicitly select SunStudio CC, I can build with that, and again all tests pass. So all is basically well, but it would be good to compile by default with the same compiler as `which cc` on the host system! Agreed, but this is a regression? No, I do nott believe so.
Re: [VOTE] Release APR 1.3.7
William A. Rowe, Jr. wrote: So all is basically well, but it would be good to compile by default with the same compiler as `which cc` on the host system! Agreed, but this is a regression? No. Just something that didn't affect me when my platforms were Linux/BSD/Mac, and that I've hitherto silently worked around on Solaris. Having had it hit me when I was composing a post to dev@ seemed like a good occasion to raise the issue! -- Nick Kew
Re: [VOTE] Release APR 1.3.7
Nick Kew wrote: William A. Rowe, Jr. wrote: So all is basically well, but it would be good to compile by default with the same compiler as `which cc` on the host system! Agreed, but this is a regression? No. Just something that didn't affect me when my platforms were Linux/BSD/Mac, and that I've hitherto silently worked around on Solaris. Having had it hit me when I was composing a post to dev@ seemed like a good occasion to raise the issue! Yup - but is your default really cc? E.g. what does CC=cc as a global do for you? I agree it is strange that 'default' CC is gcc, but then again, we are using a gnu toolchain, so did we expect any different? Many offbeat platforms do have cc as a default, even Solaris, which is not their modern compiler. Instead it's often a pre C89 or otherwise less reliable/less feature-rich compiler. So the system default of CC=gcc actually makes a fair amount of sense. Bill
