Bug 1704807 - xen FTBFS with Python 3.8
Summary: xen FTBFS with Python 3.8
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: xen
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
urgent
Target Milestone: ---
Assignee: Michael Young
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On: 1720868
Blocks: PYTHON38
TreeView+ depends on / blocked
 
Reported: 2019-04-30 14:37 UTC by Miro Hrončok
Modified: 2019-06-19 09:56 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-06-19 09:56:05 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
Full log from Copr (2.51 MB, text/plain)
2019-04-30 14:37 UTC, Miro Hrončok
no flags Details
Python 3.8 failures (33.78 KB, application/gzip)
2019-05-31 17:49 UTC, Charalampos Stratakis
no flags Details

Description Miro Hrončok 2019-04-30 14:37:14 UTC
Created attachment 1560325 [details]
Full log from Copr

xen 4.12.0-2.fc31 FTBFS with Python 3.8:


building 'xc' extension
creating build/temp.linux-x86_64-3.8
creating build/temp.linux-x86_64-3.8/xen
creating build/temp.linux-x86_64-3.8/xen/lowlevel
creating build/temp.linux-x86_64-3.8/xen/lowlevel/xc
gcc -Wno-unused-result -Wsign-compare -DDYNAMIC_ANNOTATIONS_ENABLED=1 -DNDEBUG -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -D_GNU_SOURCE -fPIC -fwrapv -m64 -DBUILD_ID -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs -O2 -fomit-frame-pointer -D__XEN_INTERFACE_VERSION__=__XEN_LATEST_INTERFACE_VERSION__ -MMD -MF .install.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -O1 -fPIC -I../../tools/include -I../../tools/libs/toollog/include -I../../tools/libs/evtchn/include -I../../tools/libxc/include -Ixen/lowlevel/xc -I/usr/include/python3.8m -c xen/lowlevel/xc/xc.c -o build/temp.linux-x86_64-3.8/xen/lowlevel/xc/xc.o -fno-strict-aliasing -Werror
BUILDSTDERR: xen/lowlevel/xc/xc.c: In function ‘pyxc_domain_create’:
BUILDSTDERR: xen/lowlevel/xc/xc.c:148:24: error: comparison of integer expressions of different signedness: ‘int’ and ‘long unsigned int’ [-Werror=sign-compare]
BUILDSTDERR:   148 |         for ( i = 0; i < sizeof(xen_domain_handle_t); i++ )
BUILDSTDERR:       |                        ^
BUILDSTDERR: xen/lowlevel/xc/xc.c: In function ‘pyxc_domain_sethandle’:
BUILDSTDERR: xen/lowlevel/xc/xc.c:313:20: error: comparison of integer expressions of different signedness: ‘int’ and ‘long unsigned int’ [-Werror=sign-compare]
BUILDSTDERR:   313 |     for ( i = 0; i < sizeof(xen_domain_handle_t); i++ )
BUILDSTDERR:       |                    ^
BUILDSTDERR: xen/lowlevel/xc/xc.c: In function ‘pyxc_domain_getinfo’:
BUILDSTDERR: xen/lowlevel/xc/xc.c:392:24: error: comparison of integer expressions of different signedness: ‘int’ and ‘long unsigned int’ [-Werror=sign-compare]
BUILDSTDERR:   392 |         for ( j = 0; j < sizeof(xen_domain_handle_t); j++ )
BUILDSTDERR:       |                        ^
BUILDSTDERR: xen/lowlevel/xc/xc.c: In function ‘pyxc_get_device_group’:
BUILDSTDERR: xen/lowlevel/xc/xc.c:678:20: error: comparison of integer expressions of different signedness: ‘int’ and ‘uint32_t’ {aka ‘unsigned int’} [-Werror=sign-compare]
BUILDSTDERR:   678 |     for ( i = 0; i < num_sdevs; i++ )
BUILDSTDERR:       |                    ^
BUILDSTDERR: xen/lowlevel/xc/xc.c: In function ‘pyxc_physinfo’:
BUILDSTDERR: xen/lowlevel/xc/xc.c:983:20: error: comparison of integer expressions of different signedness: ‘int’ and ‘long unsigned int’ [-Werror=sign-compare]
BUILDSTDERR:   983 |     for ( i = 0; i < sizeof(pinfo.hw_cap)/4; i++ )
BUILDSTDERR:       |                    ^
BUILDSTDERR: cc1: all warnings being treated as errors
BUILDSTDERR: error: command 'gcc' failed with exit status 1
BUILDSTDERR: make[4]: *** [Makefile:18: install] Error 1
make[4]: Leaving directory '/builddir/build/BUILD/xen-4.12.0/tools/python'
make[3]: Leaving directory '/builddir/build/BUILD/xen-4.12.0/tools'
BUILDSTDERR: make[3]: *** [/builddir/build/BUILD/xen-4.12.0/tools/../tools/Rules.mk:251: subdir-install-python] Error 2
BUILDSTDERR: make[2]: *** [/builddir/build/BUILD/xen-4.12.0/tools/../tools/Rules.mk:246: subdirs-install] Error 2
make[2]: Leaving directory '/builddir/build/BUILD/xen-4.12.0/tools'
BUILDSTDERR: make[1]: *** [Makefile:74: install] Error 2
make[1]: Leaving directory '/builddir/build/BUILD/xen-4.12.0/tools'
BUILDSTDERR: make: *** [Makefile:127: install-tools] Error 2
BUILDSTDERR: error: Bad exit status from /var/tmp/rpm-tmp.XSTpev (%build)
RPM build errors:
BUILDSTDERR:     Bad exit status from /var/tmp/rpm-tmp.XSTpev (%build)
Child return code was: 1

Not sure if "all warnings being treated as errors" is the cause here, but maybe we shouldn't do that?

Full logs attached.

Comment 1 Michael Young 2019-04-30 14:55:42 UTC
"all warnings being treated as errors" is standard for Fedora builds. The xen code seems fairly sensitive to gcc changes and I suspect there have been extra checks added since it was last built. The failure doesn't look to be Python 3.8 related.

Comment 2 Miro Hrončok 2019-04-30 15:04:36 UTC
> failure doesn't look to be Python 3.8 related

No they don't seem o be, but the build runs fine in Koji with Python 3.7.

https://koji.fedoraproject.org/koji/taskinfo?taskID=34547775

Comment 3 Michael Young 2019-04-30 15:19:49 UTC
If you compare the gcc options you will see that the copr one has the extra options -Wno-unused-result -Wsign-compare at the start, so the difference is that copr has some extra compile checks that flag issues with the xen code.

Comment 4 Miro Hrončok 2019-04-30 15:29:31 UTC
That should not happen. Let me try to rebuild xen in mock.

Comment 5 Miro Hrončok 2019-04-30 15:47:03 UTC
$ mock -r ~/.config/mock/fedora-rawhide-x86_64-python3.8.cfg --no-clean --no-cleanup-after ./xen-4.12.0-1.fc31.src.rpm
...
building 'xc' extension
creating build/temp.linux-x86_64-3.8
creating build/temp.linux-x86_64-3.8/xen
creating build/temp.linux-x86_64-3.8/xen/lowlevel
creating build/temp.linux-x86_64-3.8/xen/lowlevel/xc
gcc -Wno-unused-result -Wsign-compare -DDYNAMIC_ANNOTATIONS_ENABLED=1 -DNDEBUG -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -D_GNU_SOURCE -fPIC -fwrapv -m64 -DBUILD_ID -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs -O2 -fomit-frame-pointer -D__XEN_INTERFACE_VERSION__=__XEN_LATEST_INTERFACE_VERSION__ -MMD -MF .install.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -O1 -fPIC -I../../tools/include -I../../tools/libs/toollog/include -I../../tools/libs/evtchn/include -I../../tools/libxc/include -Ixen/lowlevel/xc -I/usr/include/python3.8m -c xen/lowlevel/xc/xc.c -o build/temp.linux-x86_64-3.8/xen/lowlevel/xc/xc.o -fno-strict-aliasing -Werror
xen/lowlevel/xc/xc.c: In function ‘pyxc_domain_create’:
xen/lowlevel/xc/xc.c:148:24: error: comparison of integer expressions of different signedness: ‘int’ and ‘long unsigned int’ [-Werror=sign-compare]
  148 |         for ( i = 0; i < sizeof(xen_domain_handle_t); i++ )
      |                        ^
xen/lowlevel/xc/xc.c: In function ‘pyxc_domain_sethandle’:
xen/lowlevel/xc/xc.c:313:20: error: comparison of integer expressions of different signedness: ‘int’ and ‘long unsigned int’ [-Werror=sign-compare]
  313 |     for ( i = 0; i < sizeof(xen_domain_handle_t); i++ )
      |                    ^
xen/lowlevel/xc/xc.c: In function ‘pyxc_domain_getinfo’:
xen/lowlevel/xc/xc.c:392:24: error: comparison of integer expressions of different signedness: ‘int’ and ‘long unsigned int’ [-Werror=sign-compare]
  392 |         for ( j = 0; j < sizeof(xen_domain_handle_t); j++ )
      |                        ^
xen/lowlevel/xc/xc.c: In function ‘pyxc_get_device_group’:
xen/lowlevel/xc/xc.c:678:20: error: comparison of integer expressions of different signedness: ‘int’ and ‘uint32_t’ {aka ‘unsigned int’} [-Werror=sign-compare]
  678 |     for ( i = 0; i < num_sdevs; i++ )
      |                    ^
xen/lowlevel/xc/xc.c: In function ‘pyxc_physinfo’:
xen/lowlevel/xc/xc.c:983:20: error: comparison of integer expressions of different signedness: ‘int’ and ‘long unsigned int’ [-Werror=sign-compare]
  983 |     for ( i = 0; i < sizeof(pinfo.hw_cap)/4; i++ )
      |                    ^
cc1: all warnings being treated as errors
error: command 'gcc' failed with exit status 1



To reproduce, get the mock config at https://copr.fedorainfracloud.org/coprs/g/python/python3.8/

Comment 6 Miro Hrončok 2019-05-01 08:57:35 UTC
Building xen in another Copr repository (with Python 3.7) works.

I'm not ruling out that "something" in my copr changes the flags, however I wouldn't know what that could be. But this is definitively not a "Copr vs. Koji" thing.

Comment 7 Miro Hrončok 2019-05-01 09:00:08 UTC
This is on my Fedora 30:


$ python3.6-config --cflags | grep -o -- '-Wno-unused-result -Wsign-compare'
-Wno-unused-result -Wsign-compare


$ python3.7-config --cflags | grep -o -- '-Wno-unused-result -Wsign-compare'
-Wno-unused-result -Wsign-compare


$ python3.8-config --cflags | grep -o -- '-Wno-unused-result -Wsign-compare'
-Wno-unused-result -Wsign-compare

Comment 8 Miro Hrončok 2019-05-30 19:38:19 UTC
Changing severity to urgent because this is in critpath (according to PDC) and we'd like to proceed with 3.8 rebuilds next week.

Comment 9 Charalampos Stratakis 2019-05-31 17:48:33 UTC
It seems there is indeed a problem now due to C extensions being no longer linked to libpython. [0]

Also from [1] which seems related:

To embed Python into an application, a new --embed option must be passed to python3-config --libs --embed to get -lpython3.8 (link the application to libpython). To support both 3.8 and older, try python3-config --libs --embed first and fallback to python3-config --libs (without --embed) if the previous command fails.

python3-config --libs is used within configure and it should modified accordingly for Python 3.8.

By adding the --embed flag (which will fail for Python 3.7, hence configure needs to have a fallback as well), I get back to the initially reported gcc errors.

[0] https://bugs.python.org/issue21536
[1] https://docs.python.org/3.8/whatsnew/3.8.html#debug-build-uses-the-same-abi-as-release-build

Comment 10 Charalampos Stratakis 2019-05-31 17:49:14 UTC
Created attachment 1575805 [details]
Python 3.8 failures

Comment 11 Michael Young 2019-06-03 18:48:33 UTC
This should work in xen-4.12.0-3.fc31

Comment 12 Miro Hrončok 2019-06-03 20:12:19 UTC
Thanks.

Comment 13 Miro Hrončok 2019-06-06 23:24:28 UTC
New build failure with xen 4.12.0-3.fc30, Python 3.8.0b1:

Full logs at 
https://copr.fedorainfracloud.org/coprs/g/python/python3.8/package/xen/

gcc -Wno-unused-result -Wsign-compare -DDYNAMIC_ANNOTATIONS_ENABLED=1 -DNDEBUG -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -D_GNU_SOURCE -fPIC -fwrapv -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -D_GNU_SOURCE -fPIC -fwrapv -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -D_GNU_SOURCE -fPIC -fwrapv -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -D_GNU_SOURCE -fPIC -fwrapv -m64 -DBUILD_ID -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs -O2 -fomit-frame-pointer -D__XEN_INTERFACE_VERSION__=__XEN_LATEST_INTERFACE_VERSION__ -MMD -MF .install.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -O1 -fPIC -I../../tools/include -I../../tools/libs/toollog/include -I../../tools/libs/evtchn/include -I../../tools/libxc/include -Ixen/lowlevel/xc -I/usr/include/python3.8 -c xen/lowlevel/xc/xc.c -o build/temp.linux-x86_64-3.8/xen/lowlevel/xc/xc.o -fno-strict-aliasing -Werror
In file included from /usr/include/python3.8/abstract.h:837,
                 from /usr/include/python3.8/Python.h:147,
                 from xen/lowlevel/xc/xc.c:7:
/usr/include/python3.8/cpython/abstract.h: In function ‘_PyVectorcall_Function’:
/usr/include/python3.8/cpython/abstract.h:88:5: error: ISO C90 forbids mixed declarations and code [-Werror=declaration-after-statement]
   88 |     Py_ssize_t offset = tp->tp_vectorcall_offset;
      |     ^~~~~~~~~~
/usr/include/python3.8/cpython/abstract.h:90:5: error: ISO C90 forbids mixed declarations and code [-Werror=declaration-after-statement]
   90 |     vectorcallfunc *ptr = (vectorcallfunc *)(((char *)callable) + offset);
      |     ^~~~~~~~~~~~~~
/usr/include/python3.8/cpython/abstract.h: In function ‘_PyObject_Vectorcall’:
/usr/include/python3.8/cpython/abstract.h:119:5: error: ISO C90 forbids mixed declarations and code [-Werror=declaration-after-statement]
  119 |     vectorcallfunc func = _PyVectorcall_Function(callable);
      |     ^~~~~~~~~~~~~~
/usr/include/python3.8/cpython/abstract.h:124:5: error: ISO C90 forbids mixed declarations and code [-Werror=declaration-after-statement]
  124 |     PyObject *res = func(callable, args, nargsf, kwnames);
      |     ^~~~~~~~
cc1: all warnings being treated as errors
error: command 'gcc' failed with exit status 1
make[4]: *** [Makefile:18: install] Error 1
make[4]: Leaving directory '/builddir/build/BUILD/xen-4.12.0/tools/python'
make[3]: *** [/builddir/build/BUILD/xen-4.12.0/tools/../tools/Rules.mk:251: subdir-install-python] Error 2
make[3]: Leaving directory '/builddir/build/BUILD/xen-4.12.0/tools'
make[2]: *** [/builddir/build/BUILD/xen-4.12.0/tools/../tools/Rules.mk:246: subdirs-install] Error 2
make[2]: Leaving directory '/builddir/build/BUILD/xen-4.12.0/tools'
make[1]: *** [Makefile:74: install] Error 2
make[1]: Leaving directory '/builddir/build/BUILD/xen-4.12.0/tools'
make: *** [Makefile:127: install-tools] Error 2
error: Bad exit status from /var/tmp/rpm-tmp.iMx4Ht (%build)


Python uses several C99 features since 3.6 including intermingled declarations.

I don't really understand compiler flags, but I see -std=gnu99 in there, not sure why it has C90 warning (turned into errors with -Werror).

----

This issue is blocking the Python 3.8 rebuilds. If this package won't build with 3.8, it won't be installable, along with all its dependent packages, after the side tag is merged.
Furthermore, as it fails to install, its dependent packages will fail to install and/or build as well. The fix should be pushed on the master branch and no release bump is required.

Testing and mass rebuild of packages is happening in copr. You can follow these instructions to test in locally mock if your package builds with Python 3.8: https://copr.fedorainfracloud.org/coprs/g/python/python3.8/

This issue needs to be resolved by next week, if other rebuilds of Python 3.8 beta 1 go well. If this is unrealistic for you, let us know how much time you need.

If you don't have free cycles to dedicate fixing your package, notify us and we'll try to provide some pointers. Let us know if we can push a fix directly without a pull request, in the case we happen to have one before you do.

Comment 14 Miro Hrončok 2019-06-06 23:29:32 UTC
I see, there is -std=gnu99, but also -Wdeclaration-after-statement.

Comment 15 Miro Hrončok 2019-06-06 23:30:54 UTC
$ rg declaration-after xen-4.12.0
xen-4.12.0/Config.mk
222:$(call cc-option-add,HOSTCFLAGS,HOSTCC,-Wdeclaration-after-statement)
223:$(call cc-option-add,CFLAGS,CC,-Wdeclaration-after-statement)

xen-4.12.0/stubdom/Makefile
235:	cd $@/build; CC=${CC} $(CMAKE) .. -DCMAKE_C_FLAGS:STRING="-std=c99 -DTPM_NO_EXTERN $(TARGET_CPPFLAGS) $(TARGET_CFLAGS) -Wno-declaration-after-statement"

xen-4.12.0/stubdom/vtpmmgr/Makefile
20:CFLAGS+=-Wno-declaration-after-statement -Wno-unused-label

xen-4.12.0/tools/xl/Makefile
9:	-Wno-declaration-after-statement -Wformat-nonliteral

xen-4.12.0/tools/libxl/Makefile
15:	-Wno-declaration-after-statement -Wformat-nonliteral

xen-4.12.0/tools/tests/depriv/Makefile
4:CFLAGS += -Werror -Wno-declaration-after-statement

xen-4.12.0/tools/qemu-xen-traditional/xen-hooks.mak
17:CFLAGS += -Wno-unused -Wno-declaration-after-statement

xen-4.12.0/tools/ocaml/libs/xl/Makefile
6:CFLAGS += -Wno-unused -Wno-declaration-after-statement

xen-4.12.0/tools/ocaml/libs/xentoollog/Makefile
6:CFLAGS += -Wno-declaration-after-statement

Comment 16 Miro Hrončok 2019-06-10 16:44:05 UTC
This issue is blocking the Python 3.8 rebuilds. If this package won't build with 3.8, it won't be installable, along with all its dependent packages, after the side tag is merged.
Furthermore, as it fails to install, its dependent packages will fail to install and/or build as well. The fix should be pushed on the master branch and no release bump is required.

Testing and mass rebuild of packages is happening in copr. You can follow these instructions to test locally in mock if your package builds with Python 3.8: https://copr.fedorainfracloud.org/coprs/g/python/python3.8/

This issue needs to be resolved by next week, if other rebuilds of Python 3.8 beta 1 go well. If this is unrealistic for you, let us know how much time you need.

If you don't have free cycles to dedicate fixing your package, notify us and we'll try to provide some pointers. Let us know if we can push a fix directly without a pull request, in the case we happen to have one before you do.

We recommend always consulting with upstream, chances are this is already fixed there.

Comment 17 Zbigniew Jędrzejewski-Szmek 2019-06-18 13:08:39 UTC
I'd say that Python is in the wrong here. Libraries should require only really old C standards in widely
used public headers. Internally, they should use something recent. The motivation is that we have many
very old packages, and upgrading the C standard they conform to can be a lot of work. In general
public headers should not expose complex state, and certainly not any complex code, and any old
C standard should be enough.

That said, using -Werror is actively asking for trouble. This is the easiest method to get
gratuitous breakage after every gcc upgrade. 

> "all warnings being treated as errors" is standard for Fedora builds.

Certainly not. -Werror is useful for developers, but not for packaging.

I added -Wno-declaration-after-statement to flags, but I'm blocking on another bug. I'll push
the fix if I get the package to build.

Comment 18 Miro Hrončok 2019-06-18 13:21:09 UTC
IIRC Petr wants to (or even did) revert this header change, however only for 3.8, so this will bite again in 3.9. If you think that there is proper and good reason to only have C89 headers in Python, I suggest to file a cpython issue about that, but I tend to disagree.

See also PEP 7's C dialect section: https://www.python.org/dev/peps/pep-0007/#c-dialect

Either way, using -Werror in Fedora packages is IMHO a terrible idea actively wasting other maintainers' time.

Comment 19 Zbigniew Jędrzejewski-Szmek 2019-06-18 13:44:34 UTC
Duh, it now fails with:
Error: Transaction check error:
  file /usr/lib/debug/usr/bin/xenstore-4.12.0-4.fc31.x86_64.debug conflicts between attempted installs of xen-runtime-debuginfo-4.12.0-4.fc31.x86_64 and xen-runtime-4.12.0-4.fc31.x86_64
  file /usr/lib/debug/usr/bin/xenstore-chmod-4.12.0-4.fc31.x86_64.debug conflicts between attempted installs of xen-runtime-debuginfo-4.12.0-4.fc31.x86_64 and xen-runtime-4.12.0-4.fc31.x86_64
  file /usr/lib/debug/usr/bin/xenstore-control-4.12.0-4.fc31.x86_64.debug conflicts between attempted installs of xen-runtime-debuginfo-4.12.0-4.fc31.x86_64 and xen-runtime-4.12.0-4.fc31.x86_64
  file /usr/lib/debug/usr/bin/xenstore-exists-4.12.0-4.fc31.x86_64.debug conflicts between attempted installs of xen-runtime-debuginfo-4.12.0-4.fc31.x86_64 and xen-runtime-4.12.0-4.fc31.x86_64
  file /usr/lib/debug/usr/bin/xenstore-list-4.12.0-4.fc31.x86_64.debug conflicts between attempted installs of xen-runtime-debuginfo-4.12.0-4.fc31.x86_64 and xen-runtime-4.12.0-4.fc31.x86_64
  file /usr/lib/debug/usr/bin/xenstore-ls-4.12.0-4.fc31.x86_64.debug conflicts between attempted installs of xen-runtime-debuginfo-4.12.0-4.fc31.x86_64 and xen-runtime-4.12.0-4.fc31.x86_64
  file /usr/lib/debug/usr/bin/xenstore-read-4.12.0-4.fc31.x86_64.debug conflicts between attempted installs of xen-runtime-debuginfo-4.12.0-4.fc31.x86_64 and xen-runtime-4.12.0-4.fc31.x86_64
  file /usr/lib/debug/usr/bin/xenstore-rm-4.12.0-4.fc31.x86_64.debug conflicts between attempted installs of xen-runtime-debuginfo-4.12.0-4.fc31.x86_64 and xen-runtime-4.12.0-4.fc31.x86_64
  file /usr/lib/debug/usr/bin/xenstore-watch-4.12.0-4.fc31.x86_64.debug conflicts between attempted installs of xen-runtime-debuginfo-4.12.0-4.fc31.x86_64 and xen-runtime-4.12.0-4.fc31.x86_64
  file /usr/lib/debug/usr/bin/xenstore-write-4.12.0-4.fc31.x86_64.debug conflicts between attempted installs of xen-runtime-debuginfo-4.12.0-4.fc31.x86_64 and xen-runtime-4.12.0-4.fc31.x86_64

Any hints?

Comment 20 Miro Hrončok 2019-06-18 13:47:36 UTC
No idea.

Comment 21 Zbigniew Jędrzejewski-Szmek 2019-06-18 13:50:29 UTC
https://src.fedoraproject.org/rpms/xen/pull-request/1

Comment 22 Zbigniew Jędrzejewski-Szmek 2019-06-18 14:02:51 UTC
I merged my PR, but didn't rebuild. Nevertheless, this should be solved.

Comment 23 Miro Hrončok 2019-06-18 14:17:33 UTC
The push triggered a build in copr, it is now pending.

Comment 24 Miro Hrončok 2019-06-19 09:56:05 UTC
thanks


Note You need to log in before you can comment on or make changes to this bug.