Peter Robinson wrote:
> There will be a slight change that a failure in an arch won't cancel
> the other arches and each one will run to completion (pass/fail) but
> the overall primary task will still fail.
I don't see how wasting Koji resources on completing an already failed build
helps anybody.
> The data we have for build failures across all the arches show that
> not to be the case.
Having been plagued by obscure architecture-specific toolchain bugs several
times (see also my other mail in this thread), I don't think you are seeing
the whole picture there.
> All the pure noarch packages, which is over 50% of the distribution,
Noarch packages are by their very nature unaffected by the vast majority of
architecture-specific issues. (Also because they are typically interpreted
packages where the "build" process is trivial.) They are not a
representative sample in any way.
> currently can and are regularly built on ppc64/ppc64le builders now
> anyway due to them being in primary koji for EPEL so for a large
> percentage it's already dealing with a lot of the arches we're due to
> cover anyway and there's not been a single issue reported there in the
> 12 months that ppc64le has been present.
Are you sure that Fedora noarch packages are actually being built on ppc64
builders? They would need a ppc64 Fedora in the buildroot for that. I
remember that back when PPC was demoted to secondary, Fedora noarch builds
stopped happening on PPC builders for the releases where PPC was no longer
primary (while still happening for the updates of the last PPC-as-primary
release), because of that buildroot thing. It was similar the other way
round when ARM was added to the primary Koji instance, only the new release
was able to use ARM builders for noarch packages.
> And in response to the "slow built times" the builders in the non
> primary koji instance are of equivalent or faster than the x86
> builders. EG the ppc64 builders use to be a LOT slower than x86 back
> when we had Power6 builders, but that hasn't been the case for over 3
> years, and the current Power8 generation builders are actually faster
> than the x86 builders.
Does that also hold for build tasks that cannot be parallelized (e.g.:
custom specfile scripts, handwritten build scripts from upstream, Makefiles
that do not support %{_smp_mflags} due to race conditions, etc.)?
And is this really a strength of the new architectures? To me, it sounds
more like a sign that the x86 builders need to be renewed. Or is aarch64
really competitive at performance with x86 now?
> For ARMv7 (which is not part of this because it's already in primary) will
> actually get faster builders on aarch64 as part of this change.
And making ARMv7 primary was a big mistake that ought to be corrected now
that it is clear that Fedora will never (or at least not in the foreseeable
future) run on the ARM devices 99% of ARM users out there use (smartphones),
and that the remaining ARM niche is being obsoleted by aarch64. ARMv7 should
become secondary again (with the "old" definition of "secondary", not your
proposed one). Then you can also (instead of your proposed change) easily
put your fancy new builders on the ARM Koji instance and build both ARMv7
and aarch64 on them without bothering the x86 builds.
> In most cases the maintainers are still bothered by failures even from
> the secondary arches anyway, it will certainly be more up front to
> them but the core packages that historically have issues (toolchains
> etc) already have maintainers that actively test and support the non
> x86 architectures anyway.
Well, I care about the primary architectures mainly, and usually leave
issues on the secondary architectures to the secondary architecture
maintainer. And IMHO, that's how it should be. The people who care about
exotic niche architectures should be the ones doing the work for them.
> Yes, but how would you deal with a soname bump where if it's not fatal
> on an arch what happens when something is then rebuilt against one
> version on one arch and a different version on a different arch. You
> end up in a big mess really quickly. It ends up being a lot less work
> (even in the current situation with non x86 arches) if the issue is
> fixed from the outset.
The "big mess" you describe is how Debian does things, it works well for
them. The alternative approach is how koji-shadow does things: just hold all
builds that have the failed build in the buildroot. (And the easiest way to
implement that is to just keep using koji-shadow. I don't see why we have to
shoehorn everything into the main Koji instance.)
Kevin Kofler
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
