Bug#819278: llvm-toolchain-3.8: Build not reliable

[Santiago Vila]

Hello Sylvestre.

Packages llvm-toolchain-6.0 and llvm-toolchain-7 in buster show the
same behaviour in my building environment than llvm-toolchain-3.8, but
before reopening/cloning this bug it may be worth to comment here first.

Back in 2016, you said:

> I am building the LLVM toolchain twice a day on 2 architectures
> for 8 Debian/Ubuntu releases + maintain Debian packages. I think the
> process is reliable enough for Debian.

Well, I also do this kind of reasoning when I receive a bug which is
so weird which is almost impossible to believe that it could happen.

For example, if somebody reports that "ls" segfaults, one would
probably think that it's a problem in the user's machine, like
filesystem corruption, memory corruption, or something alike,
because otherwise a lot of people would notice.

However, continuous testing and jenkins only help to discover bugs
which happen in a similar environment. So, for example, if you always
build llvm in multi-cpu machines and it happens that it does not build
ok in single-cpu machines, the fact that you build llvm twice a day on
several differentr architectures will not help to discover such kind
of bug.

And that's precisely my theory here: I believe llvm build has never
been tested in a single-CPU system.

So: Would be possible for you to try building the package on a
single-cpu system at least once? (I can provide a virtual machine for
you if setting up such a system is a burden for you).

(If my suspicious is true, the subject ("build not reliable") would fit.
I would call a build "reliable" when its success or not does not
depend on things not in debian/control, i.e. when it builds ok in both
slow or fast computers, and regardless of vendor or number of CPU cores.
This is what I would expect from an Operating System which prides to
call itself Universal, and also this is the spirit of Debian Policy
when it says that "it must be possible to build the package when
build-essential and build-dependencies are installed". We don't have a
control field to require more than one CPU).

(Note: If you are wondering why I'm using single-CPU systems for my QA
work: They are usually cheaper and more efficient per €. In my experience,
multi-cpu is only "better" when you don't have to pay for it).

Sorry for the long email.

Thanks a lot.