Re: [VOTE] 1.3.42 release candidate
Hi Colm, On 08.01.2010 21:53, Colm MacCárthaigh wrote: On Fri, Jan 8, 2010 at 6:58 PM, Rainer Jungrainer.j...@kippdata.de wrote: File htdocs/manual/misc/FAQ.html was previously 150KB and now is only 5KB. I didn't yet load it from the web server itself, but it seems some generation step was missing. The file installed by make install has the same problem. links -src now returns the gzipped body, as we have mod_deflate enabled these days. I've fixed up the other nits and rerolled, tarballs with new checksums/signatures in the same place now. I'll fix up the Announce language too, waiting for PRC input on that too. md5, sha1, sigs good, tar.Z and tar.gz same contents. FAQ fine, expand.pl gone, Configuration present, no other changes to previous 1.3.42 tarball. There's one other manual related thing I wasn't thinking enough about before writing my last mail: the 1.3.42 manual contains SSI #include virtual statements, the 1.3.41 version not. I (wildly) guess the script expand.pl is usually used during releasing to fix the manual, so that the pages caqn also be read without running them though the web server. At least the contents of expand.pl look like it recursively goes through a directory and resolves all #include virtual in the files. Regards, Rainer
Re: [VOTE] 1.3.42 release candidate
On Sat, Jan 9, 2010 at 11:48 AM, Rainer Jung rainer.j...@kippdata.de wrote: There's one other manual related thing I wasn't thinking enough about before writing my last mail: the 1.3.42 manual contains SSI #include virtual statements, the 1.3.41 version not. I (wildly) guess the script expand.pl is usually used during releasing to fix the manual, so that the pages caqn also be read without running them though the web server. At least the contents of expand.pl look like it recursively goes through a directory and resolves all #include virtual in the files. I ran expand.pl, I'll look into what the hell it's doing :-) -- Colm
Re: [VOTE] 1.3.42 release candidate
On 09.01.2010 12:58, Colm MacCárthaigh wrote: On Sat, Jan 9, 2010 at 11:48 AM, Rainer Jungrainer.j...@kippdata.de wrote: There's one other manual related thing I wasn't thinking enough about before writing my last mail: the 1.3.42 manual contains SSI #include virtual statements, the 1.3.41 version not. I (wildly) guess the script expand.pl is usually used during releasing to fix the manual, so that the pages caqn also be read without running them though the web server. At least the contents of expand.pl look like it recursively goes through a directory and resolves all #include virtual in the files. I ran expand.pl, I'll look into what the hell it's doing :-) Ah, I see. I just tried to run it on top of the manual contained in the tarball, and on my system (Solaris) the result looks fine. It is identical to the manual contained in the 41 tarball. Had to use the system perl, because the hash bang line #!/usr/local/bin/perl5 doesn't fit my local system. Regards, Rainer
Re: [VOTE] 1.3.42 release candidate
Hi, On Fri, 8 Jan 2010, Colm MacCárthaigh wrote: On Fri, Jan 8, 2010 at 7:50 PM, Brian Havard brian.hav...@gmail.com wrote: Colm MacCárthaigh wrote: There is a 1.3.42 release candidate for testing, and voting, at; http://people.apache.org/~colm/1.3.42/ I just tried building on a fairly stock Ubuntu Karmic system and ran into this compile error: gcc -c -I../os/unix -I../include -DLINUX=22 -DHAVE_SET_DUMPABLE -DUSE_HSREGEX -DNO_DL_NEEDED `../apaci` htpasswd.c htpasswd.c:101: error: conflicting types for ?getline? /usr/include/stdio.h:651: note: previous declaration of ?getline? was here So getline() is a system provided function here. I used the top level configure with /bin/sh changed to /bin/bash as mentioned elsewhere, no options. On fixing this I found that htdigest.c and logrotate.c have the same problem. The obvious fix would be to namespace protect these getline implementations, Thanks for the report - disinclined to fix anything that isn't a regression from 1.3.41 though. This is a security release, for upgraders only - so presumably people who've managed to work around these problems. Making life easy for new users is a deliberate non-goal :-) 2.2 is much much better for new users. Just for information: Only out of curiosity (we use 2.2) I tried to compile 1.3.42 on a current OpenSUSE 11.2 system and found also the above described compile problem (but on OpenSUSE 11.1 compiling is ok). The orign seems to lie in the used newer glibc-library respectively the changed file stdio.h. In the glibc-ChangeLog I found 2009-02-26 Ulrich Drepper drep...@redhat.com * libio/stdio.h: dprintf, fmemopen, getdelim, getline, open_memstream, and vdprintf are in POSIX 2008. The above patch would be better but for clarification I added in the Linux block of src/include/ap_config.h the following lines /* glibc 2.10 and later define getline in stdio.h if __USE_XOPEN2K8 * is defined but that conflicts with getline definitions in * support/htpasswd.c, support/htdigest.c and support/logresolve.c. */ #if (__GLIBC__ == 2 __GLIBC_MINOR__ 9) #undef __USE_XOPEN2K8 #endif and it works also (but I am not a C expert). But I accept the arguments of Colm and deleted the apache_1.3.42 directory but I expect some according bug reports after releasing 1.3.42 :-( Regards, Jens
Re: Should ap_get_server_name() behave like get_server_name_for_url() for literal IPv6 addresses?
On Fri, 8 Jan 2010, Colm MacCárthaigh wrote: mod_proxy_http: via header (should have brackets) ssl_engine_kernel.c: error message url (should have brackets) mod_rewrite: redirects (should have brackets) logging (doesn't matter) SERVER_NAME variable Redirects should have brackets yes ... but I don't think that it's the job of the SERVER_NAME variable to anticipate potential use in a url, it's just a representation of an IPv6 address. Introducing braces would break reverse DNS lookups, for one thing. DNS lookups are a valid point. Unless somebody disagrees, I will leave ap_get_server_name()/SERVER_NAME alone but create a public ap_get_server_name_for_url() function and use that where appropriate.
Thundering herd patch for mod_cache
I've just been attempting to review Graham's proposed backport. Looks interesting, but just a few points: Trivial: needs r809335. Trivial: indentation doesn't quite fit code style guidelines. - In ap_cache_try_lock - do we really need the hashed directories hardwired? I thought most modern filesystems had abandoned linear search, so that kind of thing is redundant! At least make it optional - perhaps an additional arg to the Cachelock directive. - Why is ap_cache_remove_lock called from so many places rather than just use a pool cleanup, and maybe in cache_save_filter as the earliest possible point in the normal processing path? - Do we need to use lock files like this? Not I think in every case: with mod_disk_cache we already have files we could lock (and create if they don't already exist). - Your ELSE clause (cache_util, line 623) for requests for a stale object that is being refreshed by another request serves the stale object and adds a warning. Is this the best thing to do? What about waiting for the file to be fetched? Should still be quicker than going to the backend in parallel with the other request. -- Nick Kew
