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.
"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.
> 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
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.
That should not happen. Let me try to rebuild xen in mock.
$ 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/
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.
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
Changing severity to urgent because this is in critpath (according to PDC) and we'd like to proceed with 3.8 rebuilds next week.
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
Created attachment 1575805 [details] Python 3.8 failures
This should work in xen-4.12.0-3.fc31
Thanks.
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.
I see, there is -std=gnu99, but also -Wdeclaration-after-statement.
$ 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
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.
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.
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.
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?
No idea.
https://src.fedoraproject.org/rpms/xen/pull-request/1
I merged my PR, but didn't rebuild. Nevertheless, this should be solved.
The push triggered a build in copr, it is now pending.
thanks