Using a standard installation of apache-2.2.27 and trying to access the manual by pointing the browser to https://apacheserver/manual/ does not display the expected manual pages but rather returns a not found error message in the browser. The apache log file logs the error as follws: "File does not exist: /usr/share/doc/apache-2.2.27/manual/index.html.de" (NB: my default browser language is German and thus the file ends with .de. The same same message appears however for English with ".en" instead of ".de" at the end). Investigating further, it turned out that the log was right - the requested file does indeed not exist as all files under /usr/share/doc/apache-2.2.27/manual are actually compressed and therefore have a .bz2 extension as standard (that is unless the command to compress was overriden in /etc/portage/make.conf by setting PORTAGE_COMPRESS to a different value). The standard value of PORTAGE_COMPRESS_EXCLUDE_SUFFIXES doesn't help here either as the manual files don't end with .htn[l]? but rather with .html.lang (wiht lang being a minimum two character language indicator) and are therefore compressed. In a nutshell: The problem basically is the compression applied to html-docs in the ebuild which (if I understood the EAPI documentation correctly) is done automatically as part of the src_install function. I have tried to understand the EAPI functions and think that adding something similar to the following line in src_install() should fix the problem: docompress -x /usr/share/doc/"${PF}"/manual As a temporary workaround, I have added PORTAGE_COMPRESS="" to my /etc/portage/make.conf and re-emerged apache. After that the manual pages worked flawlessly as the files were no longer compressed.
This bug has already been fixed a while ago. Please re-emerge your apache so the fix can come into effect. *** This bug has been marked as a duplicate of bug 503640 ***
Hi Lars, thanks for your comment. (In reply to Lars Wendler (Polynomial-C) from comment #1) > This bug has already been fixed a while ago. Please re-emerge your apache so > the fix can come into effect. I have one question though and would appreciate if you could enligthen me: I am currently running the latest stable version of apache2 on amd64 - which as of today is 2.2.27. According to my elog file, I have originally emerged that same version on 4 May shortly after 2.2.27 became stable. This very version I emerged back then (2.2.27) did have the bug and to me it seems that the version number since then has not changed: The current stable version, as I have said above, is till 2.2.27. I always thought it was safe to assume that version numbers (or at least revision numbers) changed if there was a change in a package. Does this assumption of mine not hold? Or in other words: The version 2.2.27 that I emerged back in May is different from version 2.2.27 that is available today? If that is really the case, how would one be able to figure out when an update is required in order to fix a bug? (In reply to Lars Wendler (Polynomial-C) from comment #1) > *** This bug has been marked as a duplicate of bug 503640 *** Or were you thinking about a fix for the currently _unstable_ apache 2.4 branch to which you refer when you consider this to be a duplicate of bug 503640? Many thanks KK
Hi Klaus, The change affected all apache versions being in the tree. As it was only a minor fix I didn't want to rollout a fully new apache and make a stabilization request for. The change didn't happen in apache ebuilds but in apache-2.eclass on May 22nd and was part of a preparation for better apache-2.4 support: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/apache-2.eclass?r1=1.35&r2=1.36 So your assumption still is correct, the pache package itself didn't change but the eclass it is primarily using. The fact that it was first reported for apache-2.4 doesn't count. The important part was the report itself :) To be honest, yes, it is hard to figure out what to do to get this problem solved. Searching in bugzilla does not always give the results one is expecting. Please understand that rolling out a new apache version/revision is not as simple as giving an apache ebuild file a new version-/revision-number. There need new patchsets to be rolled out which need testing as well. When a new version needs stabilization the whole process gets even more complicated. But to make you feel a bit better, there's apache-2.2.27-r4 about to be stabilized to fix a couple of security bugs (see bug #517298) which of course also comes with the uncompressed HTML manual pages. Cheers Lars
Hi Lars, many thanks for your thorough explanation. Now all makes sense to me. It also indicates that, in case of problems or issues being found, it sometimes might make sense to simply re-emerge a package to rule out any bugs being resolved in the meantime. Thanks again KK
