The spec file with the python compilation bits can be found here:

Gah, URL failed.

http://jgu.fedorapeople.org/emacs.spec

Thanks for filing this bug report, sorry I didn't check back sooner.

Notes to self:

I see build failures here:
http://koji.fedoraproject.org/koji/taskinfo?taskID=2053382
and:
http://koji.fedoraproject.org/koji/taskinfo?taskID=2053363
but these look like an earlier iteration where:
  + /usr/lib/rpm/brp-python-bytecompile /usr/bin/python 1
is called, and it fails on the python 3 due to language syntax changes.

Looks like the quoting may be wrong in /etc/rpm/macros.pybytecompile

See http://rpm.org/wiki/PackagerDocs/Macros ; do configuration macros actually support parameters?

(CCing Toshio: did this code used to work in the past, or did we mess up when we added this back in:
   * Mon Jan 25 2010 David Malcolm <dmalcolm> - 3.1.1-21
)

can you try using this instead::

  %py_byte_compile %{__python} %{buildroot}%{_datadir}/mypackage/foo
  %py_byte_compile %{__python3} %{buildroot}%{_datadir}/mypackage/bar

ie: leave off the {} in the %py_byte_compile macro.

If that works, I need to change the Guidelines to not have {} and write an admonition to leave them off.  The reason I think that form works is here::

  http://rpm.org/wiki/PackagerDocs/Macros#UsingaMacro

(In reply to comment #4)
> can you try using this instead::
> 
>   %py_byte_compile %{__python} %{buildroot}%{_datadir}/mypackage/foo
>   %py_byte_compile %{__python3} %{buildroot}%{_datadir}/mypackage/bar
> 
> ie: leave off the {} in the %py_byte_compile macro.

OK, that seems to work fine and the python files are byte compiled. However, the build still bails with 

+ /usr/bin/python 1
/usr/bin/python: can't open file '1': [Errno 2] No such file or directory
error: Bad exit status from /var/tmp/rpm-tmp.QAKZGo (%install)

Ugh.  We really messed up the recipes we included in the Guidelines.  Here's what's happening there::

  %global __os_install_post %(echo '%{__os_install_post}' | sed -e
's!/usr/lib[^[:space:]]*/brp-python-bytecompile!!g')

This is stripping out brp-python-bytecompile from __os_install_post.  However, it is leaving the arguments to brp-python-bytecompile in.  In F-13 and F-14 the arguments are "/usr/bin/python 1" which is leading to that error.

I think this will work::

  %global __os_install_post %(echo '%{__os_install_post}' | sed -e
's!/usr/lib[^[:space:]]*/brp-python-bytecompile[[:space:]].*$!!g')

but I want to see the build.log to confirm that we don't cut out commands after the bytecompile with that syntax.  If that fails we can do this instead:

  %global __os_install_post %(echo '%{__os_install_post}' | sed -e
's!/usr/lib[^[:space:]]*/brp-python-bytecompile!/bin/true!g')

which I know will work but is a bit hackish.

Just checked::

  %global __os_install_post %(echo '%{__os_install_post}' | sed -e
's!/usr/lib[^[:space:]]*/brp-python-bytecompile[[:space:]].*$!!g')

Looks good.  I'm updating the Guidelines; give it a try.

Yup, that works for me too - I was just waiting for a mock build to finish to confirm :) Thanks!

As an aside, would it not be nicer to hide this:

%global __os_install_post %(echo '%{__os_install_post}' | sed -e
's!/usr/lib[^[:space:]]*/brp-python-bytecompile[[:space:]].*$!!g')

behind a macro eg %py_auto_byte_compile_off or some such?

dmalcolm is looking into putting this into a macro.

This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

dmalcolm ping?  No preference from me as to whether a macro is created; just want to see the bug closed eventually :-)

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

bkbrda ping?

Closing this is an easyfix.  We just need to make a decision on the request here:

(In reply to Jonathan Underwood from comment #9)
> As an aside, would it not be nicer to hide this:
> 
> %global __os_install_post %(echo '%{__os_install_post}' | sed -e
> 's!/usr/lib[^[:space:]]*/brp-python-bytecompile[[:space:]].*$!!g')
> 
> behind a macro eg %py_auto_byte_compile_off or some such?

Sorry, I must have missed this. Macroing this seems fine to me, although I would probably prefer having something like

%{!?py_auto_byte_compile_off:<current bytecompilation stuff>}

in %__os_install_post, so that we could override default bytecompilation without sedding a specific string in python macros (if that would change in RPM, we would have to change ours, too).

Thoughts?

If it works, that sounds good to me.  I'd reverse the meaning of the switch though -- py_auto_byte_compile => when on (default), it enables byte compilation.  When set to %{nil} it disables auto byte compilation.  This would mirror what is done for debug packages:

"If you wish to disable generation of the useless debuginfo package [...] use %global debug_package %{nil} in the specfile, and be sure to add a comment next to it explaining why it was done." -- http://fedoraproject.org/wiki/Packaging:Debuginfo#Useless_or_incomplete_debuginfo_packages_due_to_other_reasons

(In reply to Toshio Ernie Kuratomi from comment #16)
> If it works, that sounds good to me.  I'd reverse the meaning of the switch
> though -- py_auto_byte_compile => when on (default), it enables byte
> compilation.  When set to %{nil} it disables auto byte compilation.  This
> would mirror what is done for debug packages:
> 
> "If you wish to disable generation of the useless debuginfo package [...]
> use %global debug_package %{nil} in the specfile, and be sure to add a
> comment next to it explaining why it was done." --
> http://fedoraproject.org/wiki/Packaging:
> Debuginfo#Useless_or_incomplete_debuginfo_packages_due_to_other_reasons

Good point, so this would mean adding


%py_auto_byte_compile 1

%__os_install_post \
<snip>
%{?py_auto_byte_compile:<current bytecompilation stuff>} \
<snip>


If this is what you mean then I think we're in agreement and I can propose the patch for macros file :)

Yep.  +1

See bug 976651 for the proposal to add this to redhat-rpm-config.

Not sure why this is showing as NEEDINFO from me. Clearing.

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Wow, is this really not fixed yet? :)

(In reply to Jonathan Underwood from comment #22)
> Wow, is this really not fixed yet? :)

Pinged bug 976651 :)

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

OK, I am going to close this (nearly 6 years old) bug, as it looks like the work has been done in 976651.