Stefano Stabellini writes ("Re: [OSSTEST PATCH] README.hardware-acquisition [and 1
more messages] [and 2 more messages]"):
Thank you for the detailed answer and the willingness to see osstest
changed in this respect.
Sure. It's not fixed in stone, and a variety of approachs will fit
into it I think.
Let me premise that as much as I would like this to be done, I had a
look at my schedule, and, realistically, I can only volunteer very
little time on this. In regards to the two Xilinx boards, it looks like
we'll just have to wait for Debian.
OK. That's perhaps less work overall at our end anyway. Let me know
if you think any aspect of this is getting stuck somehow; I have
contacts in Debian which I could use to enquire or whatever.
On Thu, 1 Nov 2018, Ian Jackson wrote:
The prerequisite is obviously an appropriate cross-compiler. Will the
Debian cross-compilers do ?
Probably it would work, but I don't know for sure. Most people use the
Linaro compiler and toolchain:
https://releases.linaro.org/components/toolchain/binaries/latest-7/aarch64-linux-gnu/
https://releases.linaro.org/components/toolchain/gcc-linaro/latest-7/
I guess that's probably tolerable. We'd have to think about whether
we should snapshot them, or install them directly from upstream. The
latter is less coding effort in osstest (just add an apt source and
run the install rune I guess) but it would imply tracking these in an
uncontrolled way, so we would want to be confident that they are
maintained to a high standard, since problems with the compiler would
break everything for us. Also I would ask: how reliable is their apt
repository hosting ? If it goes down, likewise, everything would
break for us.
Wei Liu writes ("Re: [OSSTEST PATCH] README.hardware-acquisition [and 1 more
messages] [and 2 more messages]"):
Debian's cross-compiler package conflicts with its native compiler,
Specifically it conflicts with the multilib style native compiler used
for Xen. This is a bug in Debian but it is intractable because of the
approach of the Debiabn GCC maintainer, so we will have to live with
it.
However, this is not a blocker because osstest could use a dedicated
x86 setup for the ARM cross builds. That's not ideal because it
shares resources less well, but it's certainly workable.
But maybe we just want to build on ThunderX. That leaves steps 4-6 of
my plan, which almost any approach (other than fixing the kernels in
Debian) require.
