[fedora-arm] python packaging fedora arm (f14, f15) (newbie)

[Peter Robinson]

Hi,

On Wed, Aug 17, 2011 at 6:28 PM, letters.random13
<letters.random13 at gmail.com> wrote:
> Hello,
>
> [i assumed this is too specific for the arm mailing list, my apologies if it
> should have been directed there instead]

Nope, its not, added it to the CC:. Please send all messages to the list.

> as a newbie, i was studying the f14 arm packaging of python (v2.7) (i.e.,
> python.spec), and comparing it to, e.g., f15 ix86 version (v2.7.1), or even
> the meego 1.2 version (v2.6.4) (which must have been forked off fedora not
> too long ago, and is arch-independent (simply because there is no %check /
> make test)).  i have also started independently testing / packaging
> python2.7.2 for meego n900ce.

The Fedora arm package is the same as the F-14 mainline version, not
sure why you're comparing it to the F-15 version. The MeeGo version
forked off Fedora 12.

> there are some cosmetic bugs or inconsistences in the fedora spec file i was
> looking to fix in order to gain some packaging skills.

All fixes need to be committed upstream by the Fedora python
maintainers. The fedora bugzilla is your friend there.

> firstly, the mixing/overlap of CFLAGS and OPT is bizarre,
>
> in 2.7:
> export CFLAGS="$RPM_OPT_FLAGS -D_GNU_SOURCE -fPIC -fwrapv"
> export OPT="$RPM_OPT_FLAGS -D_GNU_SOURCE -fPIC -fwrapv"
> make OPT="$CFLAGS" %{?_smp_mflags}
>
> in 2.7.1 it is marginally less ugly via:
> make EXTRA_CFLAGS="$CFLAGS" %{?_smp_mflags}
>
> both of these basically result in a long string of duplicated args to gcc,
> and, i think, issues with differentiating the flags used between the
> optimized and debug (or safer?) builds.
>
> it naively seems to me that this should instead be something like:
>
> export CFLAGS="-D_GNU_SOURCE"
> #configure adds fpic
> #arm is likely sensitive to compiler optimizer bugs (unexpected test
> failures);
> # optflags defaults to ... -g -O2.
> %if %{debug_build}
> export OPT="%{optflags} -O0 -g"
> EXTRA_CONFIGARGS = "--with-pydebug"
> %else
> export OPT="%{optflags}"
> EXTRA_CONFIGARGS = ""
> %endif
>
> make OPT="$OPT" %{?_smp_mflags}
>
> (i think compiler / optimizer bugs may be causing some test failures, so it
> would be safer / preferred to use different OPT flags (if they solve the
> problem) rather than EXCLUDE the complaining tests?)
> #test_float test failed similar to http://bugs.python.org/issue8265
>
> is it of more use to the fedora arm project to do some of this stuff on f14
> & arm-koji, or would it be better to start working on f15 (python2.7.1)?
> i see that last month python made it into arm.git:
> stage3/python/python-2.7.1-8.fc15.src.rpm

Your actually better off looking at rawhide (which will become F-17)
or F-16 and get the fixes in there. By the F-17 time frame we're
looking to be basically in parallel to mainline Fedora.

> i don't have fedora-ready arm hardware, but the meego (osc) build system has
> fedora15 i586 repository in addition to meego i586/armv7el, so at least i
> can sanity-test my package changes there while i wait for f15 to show up on
> arm-koji.
>
> minor related note:
> out of the ~1220 broken pkgs listed in the recent email:
> [fedora-arm] ARM F-14 Branched report: 20110816 changes
>
> about 200 pkgs have this issue:
> django-addons-0.6.3-1.fc13.noarch requires python(abi) = 0:2.6
>
> while 86 pkgs have this issue:
> mod_python-3.3.1-11.armv5tel requires libpython2.6.so.1.0
>
> since f14 default is python(abi) = 2.7, is this issue present because
> (1) no motivated packager (or automatic repackaging script) has hacked thru
> ~100 pkgs to change
> Requires: python-abi = 2.6
> to
> Requires: python-abi = 2.7
> and confirmed the package rebuilds ok.
> or
> (2) no motivated packager (or automatic repackaging script) has hacked the
> pkgs to contain a (temporary?) ExcludeArch / F-ExcludeArch-arm (or
> ARMTracker) bug, until (1) is completed.

There's an auto rebuild happening, most of those will be fixed once
that has finished. Its not as fast as I would like.

Peter