** Description changed:
+ [ Impact ]
+
+ * An explanation of the effects of the bug on users and justification
+ for backporting the fix to the stable release.
+
+ * In addition, it is helpful, but not required, to include an
+ explanation of how the upload fixes this bug.
+
+ [ Test Plan ]
+
+ * detailed instructions how to reproduce the bug
+
+ * these should allow someone who is not familiar with the affected
+ package to reproduce the bug and verify that the updated package
+ fixes the problem.
+
+ * if other testing is appropriate to perform before landing this
+ update, this should also be described here.
+
+ [ Where problems could occur ]
+
+ * Think about what the upload changes in the software. Imagine the
+ change is wrong or breaks something else: how would this show up?
+
+ * It is assumed that any SRU candidate patch is well-tested before
+ upload and has a low overall risk of regression, but it's important
+ to make the effort to think about what ''could'' happen in the event
+ of a regression.
+
+ * This must never be "None" or "Low", or entirely an argument as to why
+ your upload is low risk.
+
+ * This both shows the SRU team that the risks have been considered,
+ and provides guidance to testers in regression-testing the SRU.
+
+ [ Other Info ]
+
+ * Anything else you think is useful to include
+
+ * Make sure to explain any deviation from the norm, to save the SRU
+ reviewer from having to infer your reasoning, possibly incorrectly.
+ This should also help reduce review iterations, particularly when the
+ reason for the deviation is not obvious.
+
+ * Anticipate questions from users, SRU, +1 maintenance, security teams
+ and the Technical Board and address these questions in advance
+
+ [ Original Description ]
+
Ubuntu version: 24.04.1
Package version: 3.5.0.1-3build1
Python version: 3.12.3
I encountered this problem after upgrading from jammy -> nobel and
installing Trac 1.6. I do not believe this is a problem with Trac
however.
The trac.web.modpython_frontend handler supplied by Trac indirectly ends
up in platform._sys_version which requires sys.version to be of a
specific format: "X.Y.Z (buildno, builddate, buildtime) [compiler]", and
raises ValueError if it cannot be parsed.
However, setting the handler to mod_python.testhandler reveals that
sys.version is just "X.Y.X".
So the sys.version that is being set by mod_python is not compatible
with the standard python platform module.
The error that appears in the Apache log is:
...
File "/usr/lib/python3.12/platform.py", line 1108, in _sys_version ...
ValueError: failed to parse CPython sys.version: '3.12.3'
Adding this hack to the trac.web.modpython_frontend module resolves the
problem:
try:
- sys.version.index(" ")
+ sys.version.index(" ")
except ValueError:
- sys.version += ' (dummy, dummy, dummy) [dummy]'
+ sys.version += ' (dummy, dummy, dummy) [dummy]'
** Description changed:
[ Impact ]
- * An explanation of the effects of the bug on users and justification
- for backporting the fix to the stable release.
+ * An explanation of the effects of the bug on users and justification
+ for backporting the fix to the stable release.
- * In addition, it is helpful, but not required, to include an
- explanation of how the upload fixes this bug.
+ * In addition, it is helpful, but not required, to include an
+ explanation of how the upload fixes this bug.
[ Test Plan ]
- * detailed instructions how to reproduce the bug
+ # Create an ubuntu noble container or VM, and perform these steps in it:
- * these should allow someone who is not familiar with the affected
- package to reproduce the bug and verify that the updated package
- fixes the problem.
+ sudo apt install apache2 libapache2-mod-python lynx -y
- * if other testing is appropriate to perform before landing this
- update, this should also be described here.
+ wget https://bugs.launchpad.net/ubuntu/+source/libapache2-mod-
+ python/+bug/2078527/+attachment/5813129/+files/python_bug_2078527.tar.gz
+
+ sudo mkdir -p /opt/local/tmp
+
+ sudo tar -C /opt/local/tmp/ -xf python_bug_2078527.tar.gz
+
+ echo "Include /opt/local/tmp/python_bug_2078527/apache2.conf" | sudo tee
+ -a /etc/apache2/apache2.conf
+
+ sudo a2enmod python
+
+ sudo systemctl restart apache2
+
+ lynx -dump http://127.0.0.1/mod-python-bug-2078527
+
+ # When reproducing the error, the output will contain a ValueError:
+
+ Python sys.version 3.12.3
+ platform.python_version() ValueError: failed to parse CPython
+ sys.version: '3.12.3'
+
+ # With the fix, the output is:
+
+ Python sys.version 3.12.3 (main, Jun 18 2025, 17:59:45) [GCC 13.3.0]
+ platform.python_version() 3.12.3
+
[ Where problems could occur ]
- * Think about what the upload changes in the software. Imagine the
- change is wrong or breaks something else: how would this show up?
+ * Think about what the upload changes in the software. Imagine the
+ change is wrong or breaks something else: how would this show up?
- * It is assumed that any SRU candidate patch is well-tested before
- upload and has a low overall risk of regression, but it's important
- to make the effort to think about what ''could'' happen in the event
- of a regression.
+ * It is assumed that any SRU candidate patch is well-tested before
+ upload and has a low overall risk of regression, but it's important
+ to make the effort to think about what ''could'' happen in the event
+ of a regression.
- * This must never be "None" or "Low", or entirely an argument as to why
- your upload is low risk.
+ * This must never be "None" or "Low", or entirely an argument as to why
+ your upload is low risk.
- * This both shows the SRU team that the risks have been considered,
- and provides guidance to testers in regression-testing the SRU.
+ * This both shows the SRU team that the risks have been considered,
+ and provides guidance to testers in regression-testing the SRU.
[ Other Info ]
- * Anything else you think is useful to include
+ * Anything else you think is useful to include
- * Make sure to explain any deviation from the norm, to save the SRU
- reviewer from having to infer your reasoning, possibly incorrectly.
- This should also help reduce review iterations, particularly when the
- reason for the deviation is not obvious.
+ * Make sure to explain any deviation from the norm, to save the SRU
+ reviewer from having to infer your reasoning, possibly incorrectly.
+ This should also help reduce review iterations, particularly when the
+ reason for the deviation is not obvious.
- * Anticipate questions from users, SRU, +1 maintenance, security teams
- and the Technical Board and address these questions in advance
+ * Anticipate questions from users, SRU, +1 maintenance, security teams
+ and the Technical Board and address these questions in advance
[ Original Description ]
Ubuntu version: 24.04.1
Package version: 3.5.0.1-3build1
Python version: 3.12.3
I encountered this problem after upgrading from jammy -> nobel and
installing Trac 1.6. I do not believe this is a problem with Trac
however.
The trac.web.modpython_frontend handler supplied by Trac indirectly ends
up in platform._sys_version which requires sys.version to be of a
specific format: "X.Y.Z (buildno, builddate, buildtime) [compiler]", and
raises ValueError if it cannot be parsed.
However, setting the handler to mod_python.testhandler reveals that
sys.version is just "X.Y.X".
So the sys.version that is being set by mod_python is not compatible
with the standard python platform module.
The error that appears in the Apache log is:
...
File "/usr/lib/python3.12/platform.py", line 1108, in _sys_version ...
ValueError: failed to parse CPython sys.version: '3.12.3'
Adding this hack to the trac.web.modpython_frontend module resolves the
problem:
try:
sys.version.index(" ")
except ValueError:
sys.version += ' (dummy, dummy, dummy) [dummy]'
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2078527
Title:
sys.version from mod_python cannot be parsed by the python platform
module
To manage notifications about this bug go to:
https://bugs.launchpad.net/mod-python/+bug/2078527/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
