Re: Possible end of Ubuntu LTS 18.04 as a build target in 7.1 ?

[Thomas Huth]

On 15/02/2022 15.08, Daniel P. Berrangé wrote:
> Per our platform support policy
>
>    https://www.qemu.org/docs/master/about/build-platforms.html
>
>    "The project aims to support the most recent major version at all
>     times. Support for the previous major version will be dropped 2
>     years after the new major version is released or when the vendor
>     itself drops support, whichever comes first."
>
> In April this year, Ubuntu LTS 22.04 will arrive, which means the
> "previous" release will then be considered to be "LTS 20.04" and
> thus "18.04" will no longer be in scope for what we aim to support.
>
> It is possible that this might enable us to assume newer versions
> of some software we depend on, but I've not analysed the situation
> yet. This would apply from start of 7.1 development cycle if any
> min version bumps do appear relevant.

What I really would like to see: Could we get rid of some of the git 
submodules, since they keep being a pain from time to time. Could we get rid 
of the capstone submodule? libslirp? dtc? ... but this needs some careful 
checking first, of course.

> When we previously had 16.04 fall out of scope for support, we had
> a roadblock in bumping min versions. IIRC this was due to various
> machines in the compile farm Peter used for merge testing not
> supporting anything newer.
>
> I don't have a good understanding of what machines are used for
> testing now, so I'm wondering if we're going to hit any kind of
> similar issue if we try to drop 18.04 support ?  If so we might
> want to start thinking about our options now.

I think the most difficult part are maybe the custom runners in 
.gitlab-ci.d/custom-runners/ubuntu-18.04-s390x.yml ... who has access to 
that system and could try to get these updated?

We've got some more few occurances, e.g. in .gitlab-ci.d/opensbi/Dockerfile 
and in .gitlab-ci.d/containers.yml ... but that can be done by anybody who 
knows how to use the gitlab-CI.

And there are still some jobs on bionic in .travis.yml - but I can take care 
of those.

 Thomas