On Tue, 31 Oct 2023 08:58:52 +0100 Pavel Raiskup <prais...@redhat.com> wrote:
> 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, ...). thanks for replies, it makes sense > 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? this sounds pretty complex, I was more thinking about being able to specify which of my chroots to use to (re)build the srpm for my build. Would this be possible to implement? > 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. What I am trying to avoid is to have to fork every package, modify its spec, push and rebuild. It works, but doesn't scale. Dan _______________________________________________ buildsys mailing list -- buildsys@lists.fedoraproject.org To unsubscribe send an email to buildsys-le...@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.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
