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
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1162): https://lists.openembedded.org/g/openembedded-architecture/message/1162 Mute This Topic: https://lists.openembedded.org/mt/76689895/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
