Hi,
On Wed, Aug 17, 2011 at 6:28 PM, letters.random13
<letters.random13(a)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