Merge branch 'release/4.5.11'

Author: GrahamDumpleton

README.rst

@@ -83,6 +83,7 @@ If you are using the Software Collections Library (SCL) packages with
 RHEL, CentOS or Fedora, you would need:
 
 * httpd24
+* httpd24-httpd-devel
 
 If you are running MacOS X, you will need to have the Xcode command line
 tools installed. These can be installed by running ``xcode-select --install``.

docs/configuration-directives/WSGIDaemonProcess.rst

@@ -381,7 +381,7 @@ Options which can be supplied to the ``WSGIDaemonProcess`` directive are:
     and not simply cause the daemon process to become even more backlogged.
     When this occurs the user will recieve a 504 Gateway Time Out response.
 
-**listen-backlog**
+**listen-backlog=nnn**
     Defines the depth of the daemon process socket listener queue. By
     default the limit is 100, although this is actually a hint, as
     different operating systems can have different limits on the maximum

docs/configuration-directives/WSGIPythonOptimize.rst

@@ -37,7 +37,7 @@ This directive will have no affect if mod_python is being loaded into Apache
 at the same time as mod_wsgi as mod_python will in that case be responsible
 for initialising Python.
 
-Overall, if you do not understand what the normal 'python' executable '-O'
+Overall, if you do not understand what the normal 'python' executable ``-O``
 option does, how the Python runtime changes it behaviour as a result, and
 you don't know exactly how your application would be affected by enabling
 this option, then do not use this option. In other words, stop trying to

docs/installation.rst

@@ -2,19 +2,19 @@
 Installation
 ============
 
-The mod_wsgi package can be installed form source code or may also be
+The mod_wsgi package can be installed from source code or may also be
 available as a pre built binary package as part of your Linux distribution.
 
 Do be aware though that Linux distributions generally ship out of date
 versions of mod_wsgi and for long term support (LTS) versions of Linux can
 be anything up to about 5 years old. Those older versions are not supported
-in any way even though part of a so called LTS version of Linux.
+in any way even though they are part of a so called LTS version of Linux.
 
 If you want support and want to ensure you have the most up to date and
 bug free version of mod_wsgi, you should consider building and installing
-mod_wsgi from source code.
+mod_wsgi from the source code.
 
-For instructions on how to compile mod_wsgi from source code for UNIX like
+For instructions on how to compile mod_wsgi from the source code for UNIX like
 operating systems such as Linux and MacOS X see:
 
   * :doc:`user-guides/quick-installation-guide`

docs/release-notes.rst

@@ -5,6 +5,7 @@ Release Notes
 .. toctree::
    :maxdepth: 2
 
+   release-notes/version-4.5.11
    release-notes/version-4.5.10
    release-notes/version-4.5.9
    release-notes/version-4.5.8

docs/release-notes/version-4.5.11.rst

@@ -0,0 +1,13 @@
+==============
+Version 4.5.11
+==============
+
+Version 4.5.11 of mod_wsgi can be obtained from:
+
+  https://codeload.github.com/GrahamDumpleton/mod_wsgi/tar.gz/4.5.11
+
+Bugs Fixed
+----------
+
+* The ``runmodwsgi`` option when using Django application integration would
+  fail on older Django versions up to Django 1.7.

docs/user-guides/application-issues.rst

@@ -338,8 +338,8 @@ If Apache is started automatically as 'root' when a machine is first booted
 it would inherit the user 'HOME' environment variable setting of the 'root'
 user. If however, Apache is started by a non privileged user via the 'sudo'
 command, it would inherit the 'HOME' environment variable of the user who
-started it, unless the '-H' option had been supplied to 'sudo'. In the case
-of the '-H' option being supplied, the 'HOME' environment variable of the
+started it, unless the ``-H`` option had been supplied to 'sudo'. In the case
+of the ``-H`` option being supplied, the 'HOME' environment variable of the
 'root' user would again be used.
 
 Because the value of the 'HOME' environment variable can vary based on how
@@ -736,7 +736,7 @@ module is not generally compiled and so the following error will occur::
     ImportError: No module named _md5
 
 To resolve this problem it would be necessary to rebuild Apache and use the
-'--with-ssl' option to 'configure' to specify the location of the distinct
+``--with-ssl`` option to 'configure' to specify the location of the distinct
 SSL library that is being used by the Python modules.
 
 Note that it has also been suggested that the !ImportError above can also
@@ -866,7 +866,7 @@ directive should be used and the group set to '%{GLOBAL}'::
     WSGIApplicationGroup %{GLOBAL}
 
 Extension modules for which this is known to be necessary are any which
-have been developed using SWIG and for which the '-threads' option was
+have been developed using SWIG and for which the ``-threads`` option was
 supplied to 'swig' when the bindings were generated. One example of this is
 the 'dbxml' module, a Python wrapper for the Berkeley Database, previously
 developed by !SleepyCat Software, but now managed by Oracle. Another package
@@ -876,15 +876,15 @@ There is also a bit of a question mark over the Python Subversion bindings.
 This package also uses SWIG, however it is only some versions that appear
 to require that the very first sub interpreter created when Python is
 initialised be used. It is currently believed that this may be more to do
-with coding problems than with the '-threads' option being passed to the
+with coding problems than with the ``-threads`` option being passed to the
 'swig' command when the bindings were generated.
 
 For all the affected packages, as described above it is believed though
 that they will work when application group is set to force the application
 to run in the first interpreter created by Python as described above.
 
 Another option for packages which use SWIG generated bindings is not to use
-the '-threads' option when 'swig' is used to generate the bindings. This
+the ``-threads`` option when 'swig' is used to generate the bindings. This
 will avoid any problems and allow the package to be used in any sub
 interpreter. Do be aware though that by disabling thread support in SWIG
 bindings, that the GIL isn't released when C code is entered. The

docs/user-guides/checking-your-installation.rst

@@ -25,7 +25,7 @@ Apache Build Information
 Information related to what version of Apache is being used and how it is
 built is obtained in a number of ways. The primary means is from the
 Apache 'httpd' executable itself using command line options. The main such
-option is the '-V' option.
+option is the ``-V`` option.
 
 On most systems the standard Apache executable supplied with the operating
 system is located at '/usr/sbin/httpd'. On MacOS X, for the operating system
@@ -101,7 +101,7 @@ On MacOS X, for the operating system supplied Apache this file is located at
     "$@"
 
 Not only does this indicate what features of Apache have been compiled in,
-it also indicates by way of the '--enable-layout' option what custom Apache
+it also indicates by way of the ``--enable-layout`` option what custom Apache
 installation layout has been used.
 
 Apache Modules Loaded
@@ -112,11 +112,11 @@ at run time based on Apache configuration files.
 
 If modules have been statically compiled into Apache, usually it would be
 evident by what 'configure' arguments have been used when Apache was built.
-To verify what exactly what is compiled in statically, you can use the '-l'
+To verify what exactly what is compiled in statically, you can use the ``-l``
 option to the Apache executable.
 
 On MacOS X, for the operating system supplied Apache the output from
-running '-l' option is::
+running ``-l`` option is::
 
     $ /usr/sbin/httpd -l
     Compiled in modules:
@@ -130,10 +130,10 @@ This is actually the Apache module that handles the task of dynamically
 loading other Apache modules.
 
 For a specific Apache configuration, you can determine what Apache modules
-will be loaded dynamically by using the '-M' option for the Apache executable.
+will be loaded dynamically by using the ``-M`` option for the Apache executable.
 
 On MacOS X, for the operating system supplied Apache the output from
-running '-M' option, where the only additional module added is mod_wsgi,
+running ``-M`` option, where the only additional module added is mod_wsgi,
 is::
 
     $ /usr/sbin/httpd -M
@@ -249,7 +249,7 @@ checks about what is the prefered mechanism for a particular operating
 system.
 
 Which mechanism is used by default can be determined from the build
-information displayed by the '-V' option to the Apache executable described
+information displayed by the ``-V`` option to the Apache executable described
 previously. The particular entries of interest are those with 'SERIALIZE'
 in the name of the macro.
 
@@ -321,7 +321,7 @@ and::
 
     WSGIAcceptMutex xxx
 
-For each run the '-t' option on the Apache program executable.
+For each run the ``-t`` option on the Apache program executable.
 
 On MacOS X, with the operating system supplied APR library, this yields::
 
@@ -443,7 +443,7 @@ was used and what MacOS X operating system version. In this case, if
 multiple installations of same version of Python in different locations,
 may find the system installation rather than your custom installation.
 
-In that situation you may need to use the '--disable-framework' option to
+In that situation you may need to use the ``--disable-framework`` option to
 'configure' script for mod_wsgi. This doesn't actually disable use of the
 framework, but does change how it links to use a more traditional library
 style linking rather than framework linking. This seems to resolve the

docs/user-guides/debugging-techniques.rst

@@ -747,7 +747,7 @@ interpreter created when Python is initialised.
 In this latter issue, the sub interpreter problems can often be solved by
 forcing the WSGI application using the Python Subversion modules to run in
 the '%{GLOBAL}' application group. This solution often also resolves issues
-with SWIG generated bindings, especially where the '-thread' option was
+with SWIG generated bindings, especially where the ``-thread`` option was
 supplied to 'swig' when the bindings were generated.
 
 Whatever the reason, in some cases the only way to determine why Apache or

docs/user-guides/installation-issues.rst

@@ -38,7 +38,7 @@ To remedy the problem, install the developer package for Python
 corresponding to the Python runtime package you have installed. What the
 name of the developer package is can vary from one Linux distribution to
 another. Normally it has the same name as the Python runtime package with
-'-dev' appended to the package name. You will need to lookup up list of
+``-dev`` appended to the package name. You will need to lookup up list of
 available packages in your packaging system to determine actual name of
 package to install.
 
@@ -90,7 +90,7 @@ this is not present then mod_wsgi is using a static Python library.
 Although mod_wsgi will still work when compiled against a version of Python
 which only provides a static library, you are highly encouraged to ensure
 that your Python installation has been configured and compiled with the
-'--enable-shared' option to enable the production and use of a shared
+``--enable-shared`` option to enable the production and use of a shared
 library for Python.
 
 If rebuilding Python to generate a shared library, do make sure that the
@@ -143,7 +143,7 @@ Multiple Python Versions
 ------------------------
 
 Where there are multiple versions of Python installed on a system and it is
-necessary to ensure that a specific version is used, the '--with-python'
+necessary to ensure that a specific version is used, the ``--with-python``
 option can be supplied to 'configure' when installing mod_wsgi::
 
     ./configure --with-python=/usr/local/bin/python2.5
@@ -202,7 +202,7 @@ used, is located. This can be done using the WSGIPythonHome directive::
 
 The value given to the WSGIPythonHome directive should be a normalised
 path corresponding to that defined by the Python {{{sys.prefix}}} variable
-for the version of Python being used and passed to the '--with-python'
+for the version of Python being used and passed to the ``--with-python``
 option when configuring mod_wsgi::
 
     >>> import sys
@@ -258,12 +258,12 @@ The warning is indicating that a newer version of Python is now being
 used than what mod_wsgi was originally compiled for.
 
 This would generally not be a problem provided that both versions of Python
-were originally installed with the '--enable-shared' option supplied to
+were originally installed with the ``--enable-shared`` option supplied to
 'configure'. If this option is used then the Python library will be linked
 in dynamically at runtime and so an upgrade to the Python version will be
 automatically used.
 
-If '--enable-shared' was however not used and the Python library is
+If ``--enable-shared`` was however not used and the Python library is
 therefore embedded into the actual mod_wsgi Apache module, then there is a
 risk of undefined behaviour. This is because the version of the Python
 library embedded into the mod_wsgi Apache module will be older than the
@@ -304,7 +304,7 @@ bit static library in all cases.
 
 If the first issue, the only solution to this problem is to recompile
 Python for the X86 64 bit architecture. When doing this, it is preferable,
-and may actually be necessary, to ensure that the '--enable-shared' option
+and may actually be necessary, to ensure that the ``--enable-shared`` option
 is provided to the 'configure' script for Python when it is being compiled
 and installed.
 
@@ -406,9 +406,9 @@ The error encountered would be similar to::
      load /etc/httpd/modules/mod_wsgi.so into server: \
      /etc/httpd/modules/mod_wsgi.so: undefined symbol: forkpty 
 
-This problem can be fixed by adding '-lutil' to the list of libraries to
+This problem can be fixed by adding ``-lutil`` to the list of libraries to
 link mod_wsgi against when it is being built. This can be done by adding
-'-lutil' to the 'LDLIBS' variable in the mod_wsgi 'Makefile' after having
+``-lutil`` to the 'LDLIBS' variable in the mod_wsgi 'Makefile' after having
 run 'configure'.
 
 An alternative method which may work is to edit the 'envvars' file, if it
@@ -440,7 +440,7 @@ are::
     apxs:Error: Command failed with rc=65536 
 
 To avoid this problem, when configuring mod_wsgi, it is necessary to use
-the "--with-apxs" option to designate that either "apxs2-worker" or
+the ``--with-apxs`` option to designate that either "apxs2-worker" or
 "apxs2-prefork" should be used. Thus::
 
     ./configure --with-apxs=/usr/sbin/apxs2-worker
@@ -468,9 +468,9 @@ configured for maintainer mode::
     qualifiers from pointer target type
 
 Specifically, whoever built the version of Apache being used supplied the
-option '--enable-maintainer-mode' when configuring Apache prior to
+option ``--enable-maintainer-mode`` when configuring Apache prior to
 installation. You would be able to tell at the time of compiling mod_wsgi
-if this has been done as the option '-DAP_DEBUG' would be supplied to the
+if this has been done as the option ``-DAP_DEBUG`` would be supplied to the
 compiler when mod_wsgi source code is compiled.
 
 These warnings can be ignored, but in general you shouldn't run Apache in