rebuilding srpm fails to include new "ExclusiveArch"
by Dan Horák
Hi,
I am having troubles rebuilding Fedora packages that should use a
modified ExclusiveArch set via an updated macro that's redefined by a
package/build in my copr [1].
The reason for this exercise is that regular qt5-qtwebengine package
can't be built on ppc64le, because the qtwebengine projects contains
chromium under the covers and Google will unlikely ever merge the
ppc64le support into chromium, although the port exists and is
maintained out of the tree. To be able to provide packages that require
qtwebengine I am building an updated qt5-qtwebengine in my copr [1] and
would like to be able rebuild the other packages without further
modifications, just modifying the qt5_qtwebengine_arches macro and
rebuilding directly from dist-git branch.
The problem is that any(?) build in copr is first recreating the srpm
on a system that doesn't include the modified qt5 (qt5-srpm-macros)
package with the updated qt5_qtwebengine_arches macro and the build is
"skipped" (seems I have deleted the "skipped" builds, but can be
easily reproduced).
Is there a way to tell COPR to rebuild the srpm on the ppc64le builder
with my copr enabled (which is ppc64le-only)? Not only it fails when
building from dist-git, but even when a srpm built on host with the
macro updated is submitted.
Is there a way to "force" a rebuild even the copr backend thinks there
is no valid arch?
Shall I extend the copr to all arches so the modified macro exists on
eg. x86_64? Is there another option?
[1] https://copr.fedorainfracloud.org/coprs/sharkcz/talos/
Thanks,
Dan
4 weeks, 1 day
- 3
- 4
- ← Newer
- 1
- Older →