On Sun, Aug 07, 2016 at 12:59:06AM +0200, Kevin Kofler wrote:
> 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.
I think this was already mentioned in this thread, but anyway, the goal
is to be able to distinguish the case where just one architecture x fails to
build from the case where two or more architectures fail to build, and
architecture x was just the fastest.
> > 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.
Bug #1342095 is hardly earth-shattering. Simply reverting to distribution
default CFLAGS seems to work around the problem.
And please note that the plan is that by removing the need to play catch
up with koji-shadow for secondary architectures, the maintainers for those
architectures will have more time to handle actual bugs, so it's likely
that #1342095 might be handled faster in the future.
> > 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.)?
Probably not. But how many packages do we have that A) are big, B) have broken
parallel build, C) are active and rebuild regularly? It'd get that A ∩ B ∩ C
isn't that big.
Zbyszek
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
