On pondělí 30. října 2023 18:33:27 CET Miro Hrončok wrote:
On 30. 10. 23 12:12, Dan Horák wrote:
> 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 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).
That is because the SRPMs are always rebuilt on the builder which sues Fedora
38. Even when building from uploaded SRPMs.
> 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.
I don't think that's possible. See also
https://github.com/fedora-copr/copr/issues/2900#issuecomment-1710260138 and
further.
> 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?
I am afraid this won't help.
I agree with the points Miro made; he knows this problem best. Koji is
in a comfortable situation here because each buildSRPMFromTask is done
to build for a single distribution version (Fedora N). It's easy to
decide which chroots to skip "in advance". In Copr, we do a similar
thing, but the SRPM build serves as the base for builds in multiple
distribution versions and even families (EPEL, Fedora, ...).
The design of the Exclu*Arch macros doesn't seem to account for this.
These macros are distro-specific and baked into the shipped packages,
potentially having different values in every distro version. It would be
beneficial if we had access to these macros in the repository metadata.
This way, we could read them and account for their cross-distro
differences without the need to install every single distro tree we
potentially want to build against, or skip builds as needed. Ideally,
having all these macros baked into some kind of registry (Git?)
would make them easy to download. Should we consider experimenting with
a solution like this?
Another approach is to take a step back and initiate the build in every
chroot, which means allocating builder resources for all the chroots.
Then, we can decide "later" whether to skip the build or not. However,
this approach can be very uneconomical, especially for s390x chroots
this might cause slowdown because of the limited builder resources.
Pavel
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
buildsys mailing list -- buildsys(a)lists.fedoraproject.org
To unsubscribe send an email to buildsys-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/buildsys@lists.fedoraprojec...
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue