I wanted to write down my findings on trying to getting and keeping
stable branch builds working on the autobuilder. I also have a proposal
in mind for moving this forward.

Jeremy did good work in getting thud nearly building, building upon
work I'd done in getting buildtools-extended-tarball working for older
releases. Its not as simpler a problem as it would first appear.

We have two versions of buildtools tarball. In simple terms, one has
the basic utils needed to run builds without gcc and the other includes
gcc.

Our current policy was to install a buildtools tarball on certain
problematic autobuilders but this doesn't work since a given release
usually has a set of tools its known to work with and it won't work
without tools outside that. We therefore suffer "bitrot" as new workers
are added and older ones replaced with new distro installs.

In particular:
* gcc 10 doesn't work with older releases
* gcc 4.8 and 4.9 don't work with newer releases
* we no longer install makeinfo onto new autobuilder workers
* we no longer install python2 onto new autobuilder workers
* some older autobuilder workers have old versions of python3
* newer autobuilder workers need newer uninative versions
* some things changed like crypt() being moved out of glibc

This means that for a given release we want to use the standard
buildtools tarball on "old" systems and the extended buildtools tarball
on "new" systems that didn't exist at the time the release was made.

My thoughts are that we should:

a) Remove all the current buildtools installs from the autobuilder

b) teach autobuilder-helper to install buildtools tarballs in all the
older release branches

c) backport most of the autobuilder-helper changes to older releases so
its easier to maintain things

d) backport buildtools-extended-tarball to older releases

e) backport the necessary fixes to older releases to allow them to
build on the current infrastructure with buildtools.

Dunfell is in a good state and ok.

Zeus needs poky:zeus-next yocto-autobuilder-helper:contrib/rpurdie/zeus

Thud has branches available that need to update against the zeus
changes I've figured out which should get that working too.

Pyro has example code at poky-contrib:rpurdie/pyro to allow a
buildtools tarball that old to be built.

As things stand the branches are all just going to bitrot so if we can
get these branches to build cleanly, it would seem to make sense to me
to merge this approximate set of changes in the hope that stable
maintenance in case of any major security fix (for example) becomes
much more possible.

Any thoughts from anyone on this?

Cheers,

Richard