We are working on adding more flexible scheduling in koji, but it is not here yet.

Currently, you could probably work around this with channels as you suggest. Such workarounds can be cumbersome because of interaction with other channel rules. That said, it looks like most of these builds are currently in the default channel, so maybe it will be ok.

The channel policy could be used to route your noarch buildArch tasks as described. E.g. a stanza like:

method buildArch && match arch noarch :: use noarch-build

You'll want to be careful about where you place this in your existing channel policy. It will need to come before the is_child_task :: parent line.

Note that this will overrule any channel overrides and there's not a good way to check for such overrides in the policy at this point (since buildArch is a subtask).

@kevin Can we do what @mikem suggested?

So if we do that it would mean that noarch builds would never be built on builders with i386, so thats about 1/3 of all builders that wouldn't be available. That might cause issues during mass rebuilds?

I suppose we could drop the number of x86_64 builders that do i386... but then I worry about a bunch of builds there that need more resources (since a lot of big core packages still build for i386).

There are a lot of packages that only need to keep i386 support due to dependent noarch packages. I’m not saying that enough of these would go ExcludeArch: %{ix86} in the near future to make up for the change, but there would be some effect.

We are working on adding more flexible scheduling in koji, but it is not here yet.

Is that https://pagure.io/koji/pull-request/3921#_4__96-118 or does the next stage still need to be implemented to get this in?

I’m not saying that enough of these would go ExcludeArch: %{ix86} in the near future to make up for the change, but there would be some effect.

TL;DR: pandas dropping 32-bit support will put some pressure on this issue.

Just a heads up that we will need to drop 32-bit support for pandas for the next major release (3.x). That's still in the future, but it may tilt the playing field for noarch packages since a lot of packages depending on pandas are Python noarch packages. Of the 75 packages directly depending on pandas, 46 are noarch packages. There will be more further down in the dependency tree.

More info in the bug: https://bugzilla.redhat.com/show_bug.cgi?id=2263999

Can we please put in a place some (possibly hacky) solution? When pandas and a few other packages drop support for i386, we'll end up with needing to patch a few hundred packages. This will be an ongoing waste of maintainer time.

The mass rebuild is freshly past, so we have another five months where we'll be fine with slightly slower builds. And anyway, even a slightly slower mass rebuild is better than so many FTBFS packages.

A patch which does something like if builder.arch in x86_arches and build.type == 'noarch': continue; should be easy enough, even as a downstream patch.

semi-hack solution here -- https://pagure.io/koji/pull-request/4013

I was considering upgrading to 1.34.0 next week, could add this in... I guess we set it to 'aarch64 ppc64le x86_64 s390x' ? (or perhaps leave s390x off. ;)

I was considering upgrading to 1.34.0 next week, could add this in... I guess we set it to 'aarch64 ppc64le x86_64 s390x' ? (or perhaps leave s390x off. ;)

I kind of like having noarch packages that actually only work on little-endian platforms randomly FTBFS when they hit s390x builders. These problems are still easy to miss or ignore, but having s390x in the rotation increases the chances that someone will notice the problem eventually.

This is now enabled in fedora's koji. I set:

"aarch64 x86_64 ppc64le s390x" for f41-build

Awesome. I suppose we shouldn't start cutting the dep tree right now, in case this turns out to be broken, right?

Commit 65758fe fixes this issue