Bug#932795: How to handle FTBFS bugs in release architectures
On Thu, 25 Jul 2019 at 16:39:38 +0300, Adrian Bunk wrote:
> On Thu, Jul 25, 2019 at 01:22:42PM +0200, Santiago Vila wrote:
> > The only thing it did not have was more than one CPU, but AFAIK that's
> > not something that may be considered as a misconfiguration.
>
> For CPU-bound tasks like package building I would consider this build
> environment a misconfiguration.
I can see your point, but some cloud-based automated build environments
that I've used at work only provide one vCPU per build. I believe this
is done because builds typically don't parallelize perfectly (a build
that takes 10 minutes on one core will usually take more than 5 minutes
on two cores, because there are single-threaded bottlenecks like the
linker or documentation toolchains), so if you have a lot of packages
to build, it's a more efficient use of limited resources to build two
packages with parallel=1 on one core each than to build a single package
with parallel=2 on two cores. This seems like it would apply equally well
whether your limited resource is the money you pay for cloud VM instances,
or the number of physical CPUs available in your own non-cloudy VM host.
(Of course, if you're optimizing for latency rather than throughput, to
get each new version deployed and tested as quickly as possible, then the
opposite is true and it's better to sprint through each package as fast as
possible on as many cores as you can get - it's a question of priorities.)
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=924325 does look like
something I've encountered in my day job, although we worked around it
by disabling Ada to bypass the problematic part of the build (we don't
actually have any need for Ada in that environment, so speeding up the
build was welcome) rather than by adding more cores.
smcv
Reply to: