Python code not being byte-compiled when build on ARM ?

[Toshio Kuratomi]

On Mon, Aug 05, 2013 at 10:41:18PM +0200, Hans de Goede wrote:
> Hi all,
> 
> During the F-20 mass-rebuild a noarch package of mine
> ended up being build on arm (which by itself is fine),
> but it failed to build because the numerous .py files
> were not byte-compiled ?
> 
> See:
> http://koji.fedoraproject.org/koji/taskinfo?taskID=5753892
> 
> So is this a packaging bug in my package/ Maybe byte-compiled
> python files are not noarch?
> 
byte compiled python files are noarch

> Or is this a problem with the arm build config, which somehow
> causes the files to no be byte-compiled there?
> 
This could be.  I just took a look at some python packages that were built
on arm builders and they appear okay (I took a look at the pathname that
the .pyc and .pyo files refer to -- in the past, the pathnames would be
wrong if they weren't compiled with brp-python-compile but this might have
been fixed).

* python-paver -- instals into site_packages.  Uses setup.py to build
* gourmet -- installs into site_packages.  Uses setup.py to build

So I took a look at yun which uses a Makefile and installs a portion into
/usr/share.  This has .pyc files but not .pyo files in both the /usr/share
location and the site_packages location.

So it could be that brp-python-bytecompile isn't byte compiling correctly.  Whatever
files are created as part of the upstream package's build process are being
packaged but brp-python-bytecompile isn't compiling anything else like it's
supposed to.

I then took a look at rpm -ql yum on f17, f18, and f19.... it looks like
there are no .pyo files for yum in f19 either.  f18 and f17 do have .pyo
files.  So perhaps this is a problem that's come about in the time since
vegastrike-data was last compiled on F19 but we're only seeing it now?

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20130805/72581e1d/attachment.sig>