The rpm-4.6.0-python-validate.patch introduced in rpm-4.6.0-6 and described by the following commit is one of the reasons for the problems in trying to build anjuta [1] in Rawhide.
* Fri Feb 20 2009 Panu Matilainen pmatilai@redhat.com - 4.6.0-6 - error out on uncompilable python code (Tim Waugh)
What happens is that Anjuta installs some code templates in %{_datadir}/anjuta which get converted into proper C, C++ or Python files once a project is created and some parameters like license, author, etc. are specified by the user. So these templates are not really valid Python files by themselves even though they have .py as a suffix. So for obvious reasons, running brp-python-bytecompile causes the build to fail.
Can any one suggest a solution? Should I just redefine %__os_install_post to %{nil}?
Thanks, Debarshi
[1] http://koji.fedoraproject.org/koji/taskinfo?taskID=1158121
2009/2/24 Debarshi Ray debarshi.ray@gmail.com:
What happens is that Anjuta installs some code templates in %{_datadir}/anjuta which get converted into proper C, C++ or Python files once a project is created and some parameters like license, author, etc. are specified by the user. So these templates are not really valid Python files by themselves even though they have .py as a suffix. So for obvious reasons, running brp-python-bytecompile causes the build to fail.
So maybe the long-term solution would be upstream renames them to *.py.tmpl, *.py.in or similar?
On Tue, 24 Feb 2009, Debarshi Ray wrote:
The rpm-4.6.0-python-validate.patch introduced in rpm-4.6.0-6 and described by the following commit is one of the reasons for the problems in trying to build anjuta [1] in Rawhide.
- Fri Feb 20 2009 Panu Matilainen pmatilai@redhat.com - 4.6.0-6
- error out on uncompilable python code (Tim Waugh)
What happens is that Anjuta installs some code templates in %{_datadir}/anjuta which get converted into proper C, C++ or Python files once a project is created and some parameters like license, author, etc. are specified by the user. So these templates are not really valid Python files by themselves even though they have .py as a suffix. So for obvious reasons, running brp-python-bytecompile causes the build to fail.
Ok, so we need to figure out a reasonable way to disable the extra checking. I suspected that'll be the case but hoping otherwise :)
Can any one suggest a solution? Should I just redefine %__os_install_post to %{nil}?
Right now: redefining %__os_install_post will work, but is a tad large hammer for the task. Other possibilities involve avoiding python in the buildroot (obviously not always possible) and renaming .py to something else like Thomas suggested (but might not be possible either for various reasons)
Even if this particular case could be worked around by something, doesn't mean everything can be worked around reasonably... so we'll need to parametrize the thing so that you can turn the syntax check off or into a warning-only from spec.
- Panu -
So for the time-being I will redefine %__os_install_post and ask upstream if they are comfortable with renaming the extensions of the templates.
In case we decide to parametrize it, how would the knob be turned from a .spec file? Something like '%{nocompile} %{_datadir}/%{name}/.../.../main.py' in the %files list?
Cheers, Debarshi
On Wed, 25 Feb 2009, Debarshi Ray wrote:
So for the time-being I will redefine %__os_install_post and ask upstream if they are comfortable with renaming the extensions of the templates.
In case we decide to parametrize it, how would the knob be turned from a .spec file? Something like '%{nocompile} %{_datadir}/%{name}/.../.../main.py' in the %files list?
For the time being, I pulled out the syntax checking patch (currently building as rpm-4.6.0-9.fc11). It's not important enough to cause holdups in the mass rebuild, once that's over can then rethink how to best handle the cases that do misfire - I was just told all jython packages trip over the check too.
- Panu -