Created attachment 716133 [details] output from rpmbuild <mock-chroot>[root@bluebill ~]# wget http://kojipkgs.fedoraproject.org/packages/anaconda/19.13/1.fc19/src/anaconda-19.13-1.fc19.src.rpm <mock-chroot>[root@bluebill ~]# yum-builddep anaconda-19.13-1.fc19.src.rpm <mock-chroot>[root@bluebill ~]# rpm -i anaconda-19.13-1.fc19.src.rpm <mock-chroot>[root@bluebill ~]# (cd ~/build/; rpmbuild -ba SPECS/anaconda.spec 2>&1 | tee errors.anaconda) ... In file included from /usr/include/python2.7/Python.h:126:0, from isys.c:20: /usr/include/python2.7/modsupport.h:28:1: error: 'PyArg_ParseTuple' is an unrecognized format function type [-Werror=format=] PyAPI_FUNC(int) PyArg_ParseTuple(PyObject *, const char *, ...) Py_FORMAT_PARSETUPLE(PyArg_ParseTuple, 2, 3); ^ ... > Hey David, > > I am seeing: > > In file included from /usr/include/python2.7/Python.h:126:0, > from isys.c:20: > /usr/include/python2.7/modsupport.h:28:1: error: 'PyArg_ParseTuple' is > an unrecognized format function type [-Werror=format=] > PyAPI_FUNC(int) PyArg_ParseTuple(PyObject *, const char *, ...) > Py_FORMAT_PARSETUPLE(PyArg_ParseTuple, 2, 3); It looks like Py_FORMAT_PARSETUPLE somehow became non-empty. pyport.h has: /* * Add PyArg_ParseTuple format where available. */ #ifdef HAVE_ATTRIBUTE_FORMAT_PARSETUPLE #define Py_FORMAT_PARSETUPLE(func,p1,p2) __attribute__((format(func,p1,p2))) #else #define Py_FORMAT_PARSETUPLE(func,p1,p2) #endif and pyconfig-{32|64}.h has: /* Define if GCC supports __attribute__((format(PyArg_ParseTuple, 2, 3))) */ /* #undef HAVE_ATTRIBUTE_FORMAT_PARSETUPLE */ I wouldn't have expected gcc to start supporting that attribute; AFAIK the "PyArg_ParseTuple" code for the "format" attribute only ever existed in an unofficial branch of gcc, so I normally expect all of that preprocessor stuff to collapse away. > when I try to rpmbuild anaconda. This is inside of a Fedora 19 > chroot. Specifically > http://ppc.koji.fedoraproject.org/mash/branched-20130322/19-ppc/ppc64/os/ pyconfig-{32|64}.h are in the python-libs package, Looking at that header in python-libs-2.7.3-34.fc19.ppc and python-libs-2.7.3-34.fc19.ppc64 from the link above ^^^ I see this: /* Define if GCC supports __attribute__((format(PyArg_ParseTuple, 2, 3))) */ /* #undef HAVE_ATTRIBUTE_FORMAT_PARSETUPLE */ as expected. However, looking in python-libs-2.7.3-34.fc19.ppc64p7, I see that /usr/include/python2.7/pyconfig-64.h has this: /* Define if GCC supports __attribute__((format(PyArg_ParseTuple, 2, 3))) */ #define HAVE_ATTRIBUTE_FORMAT_PARSETUPLE 1 This looks erroneous: it looks like when that python package was built on that arch, pyconfig somehow thought that the gcc understood that format, hence the problem you're running into. Do you have the build logs for the underlying python build?
Created attachment 716134 [details] isys.i
python-2.7.3-34.fc19 was built for the ppc architecture at: http://ppc.koji.fedoraproject.org/koji/buildinfo?buildID=145790 The build log for ppc64p7 is at: http://ppc.koji.fedoraproject.org/kojifiles/packages/python/2.7.3/34.fc19/data/logs/ppc64p7/build.log
(In reply to comment #0) > Do you have the build logs for the underlying python build? I was asking for the build logs for python-2.7.3-34.fc19.ppc64p7 This would appear to be: http://ppc.koji.fedoraproject.org/koji/buildinfo?buildID=145790 which appeared to work as expected on ppc and ppc64, but give this bug on ppc64p7. The relevant configure.in fragment is: # Check whether GCC supports PyArg_ParseTuple format if test "$GCC" = "yes" then AC_MSG_CHECKING(whether gcc supports ParseTuple __format__) save_CFLAGS=$CFLAGS CFLAGS="$CFLAGS -Werror" AC_COMPILE_IFELSE([ AC_LANG_PROGRAM([[void f(char*,...)__attribute((format(PyArg_ParseTuple, 1, 2)));]], [[]]) ],[ AC_DEFINE(HAVE_ATTRIBUTE_FORMAT_PARSETUPLE, 1, [Define if GCC supports __attribute__((format(PyArg_ParseTuple, 2, 3)))]) AC_MSG_RESULT(yes) ],[ AC_MSG_RESULT(no) ]) CFLAGS=$save_CFLAGS fi Looking at: http://ppc.koji.fedoraproject.org/kojifiles/packages/python/2.7.3/34.fc19/data/logs/ppc64p7/build.log I do indeed see: checking whether gcc supports ParseTuple __format__... yes for both debug and optimized configurations, whereas in reality our gcc doesn't.
The issue appears to be that -Wformat is no longer included by default in gcc 4.8 The underlying test code (from configure) is: void f(char*,...)__attribute((format(PyArg_ParseTuple, 1, 2))); int main () { ; return 0; } With gcc 4.7: $ gcc -Werror /tmp/foo.c /tmp/foo.c:1:1: error: ‘PyArg_ParseTuple’ is an unrecognized format function type [-Werror=format] cc1: all warnings being treated as errors $ echo $? 1 With gcc 4.8: $ ~/coding/gcc-python/gcc-svn-trunk/install/bin/gcc -Werror /tmp/foo.c $ echo $? 0 but on adding -Wall: $ ~/coding/gcc-python/gcc-svn-trunk/install/bin/gcc -Werror -Wall /tmp/foo.c /tmp/foo.c:1:1: error: ‘PyArg_ParseTuple’ is an unrecognized format function type [-Werror=format=] void f(char*,...)__attribute((format(PyArg_ParseTuple, 1, 2))); ^ cc1: all warnings being treated as errors $ echo $? 1 or indeed just -Wformat: $ ~/coding/gcc-python/gcc-svn-trunk/install/bin/gcc -Werror -Wformat /tmp/foo.c /tmp/foo.c:1:1: error: ‘PyArg_ParseTuple’ is an unrecognized format function type [-Werror=format=] void f(char*,...)__attribute((format(PyArg_ParseTuple, 1, 2))); ^ cc1: all warnings being treated as errors $ echo $? 1
Underlying warning comes from gcc/c-family/c-format.c: 282 warning (OPT_Wformat_, "%qE is an unrecognized format function type", 283 format_type_id);
Upstream gcc commit r193304 changed: c.opt: Wformat -C ObjC C++ ObjC++ Warning +C ObjC C++ ObjC++ Warning Alias(Wformat=, 1, 0) Warn about printf/scanf/strftime/strfmon format string anomalies [...snip...] Wformat= -C ObjC C++ ObjC++ Joined Warning +C ObjC C++ ObjC++ Joined RejectNegative UInteger Var(warn_format) Warning LangEnabledBy(C ObjC C++ ObjC++,Wall, 1, 0) +Warn about printf/scanf/strftime/strfmon format string anomalies If I'm reading this right, this commit made it so that -Wformat only warn when -Wall is set, or when enabled explicitly, whereas before it appears to have been on by default. See http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=193304 for full commit.
Filed upstream as http://bugs.python.org/issue17547
Candidate fix pushed to git as: http://pkgs.fedoraproject.org/cgit/python.git/commit/?id=bc9fa6b8687f901c2aa5436596d3134938f7a3c1 to master and f19 Building python-2.7.3-35.fc20 for rawhide Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=5170856 Building python-2.7.3-35.fc19 for f19-candidate Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=5170885
Awesome, thanks! Will test it out tomorrow...
Candidate fix also pushed to "python3" git as: http://pkgs.fedoraproject.org/cgit/python3.git/commit/?id=b4d586e1005658bde584c457ea1c34790a298c3a to master and f19 Building python3-3.3.0-10.fc20 for rawhide Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=5171026 Building python3-3.3.0-10.fc19 for f19-candidate Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=5171068
This works for me.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. 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. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 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, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. 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.
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.