[LEDE-DEV] Toolchain/Buildroot requirements, testing and common lowest denominator?

[Florian Fainelli]

On 05/19/2017 02:10 AM, Daniel Engberg wrote:
> Long story short:
> * Updated tools/sparse
> * Compiles fine on my side (Debian 8)
> * Blows up on buildbot (slave-lede-local) because it runs GCC 4.7 (lacks
> bswap, 4.8+ works according to
> https://sourceware.org/bugzilla/show_bug.cgi?id=20530)
> 
> Having a look at the buildbots, it shows that tictex-02 uses GCC 4.9
> (probably Debian 8) while slave-lede-local runs Debian 7 (LTS).
> I have on idea what the phase2 buildbots uses however as the web
> interface doesn't say.
> 
> However this bring my question about what we are targeting and what's
> the view on supported versions and common lowest denominator?
> 
> Version of base GCC on common distros, haven't looked at external packages:
> Debian 7 (LTS): 4.7
> Debian 8: 4.9
> RHEL/CentOS 7.3: 4.8
> Ubuntu 16.04.2 (LTS): 5.3.0
> Ubuntu 17.04: 6.3.0
> Arch Linux: 6.3.1
> Linux Mint 17.3: 4.8.4
> FreeBSD 10.3/11.0: 5.4.0 (default via ports)
> 
> We already have requirements for a few utils and libs so I don't think
> it's a huge deal in the end.
> https://github.com/lede-project/source/blob/master/include/prereq-build.mk#L17
> 
> This should probably be adjusted as it tests for really old versions of
> GCC etc.
> 
> While hacking in bswap in this case isn't an issue it however raises the
> question of what we want to support and for how long. Also, do we want
> unified buildbots? It's been mentioned on Github that some build bots
> doesn't support all download protocols or at least have issues with a
> few such as svn, I don't if that's the case anymore but do we have any
> guidelines for such setups? Bots also have different software installed
> meaning that some packages fails depending on bot, however I'm not sure
> if that applies to any of the current packages but it occurred in the
> past. Jo-Philipp Wich also pointed out on irc that using different
> versions also irons out bugs, while this is true it also adds a lot more
> of complexity to debugging. Perhaps we should try to have a unified
> setup first and have "experimental" bots later on if there's capacity?

Having experimental buildbots would be interesting if they were
representative, of e.g: next LTS Debian/Ubuntu release, if they are not,
then we should standardize so we have a larger unified compute power
that we can leverage for daily builds.

Regarding reproducing build bug reports reported by users, we can always
fire up containers/virtual machines to reproduce what users have and
over time, the number of distribution specific build issues should be
much much lower to the point where having experimental buildbots just
for that should not be worth it.

My 2 cents.
-- 
Florian