Yocto support for Centos-7 (RHEL-7): drop in early 2020?


Randy MacLeod
 

In the YP technical meeting today, Richard suggested that we stop
support for CentOS-7. Is there any objection to doing so
before 3.1-M2?

CentOS-7 is just too old and there is significant work to support it.
Richard said that many if not most of the package upgrades that he
deals with fail for CentOS-7 and he has to either fix them himself
or get the person who submitted the work to do so. Newer distributions
are not nearly so problematic.

While the CentOS-7 distro is still a supported by it's provider,
the toolchain is very old:
- gcc-4.8
- glibc-2.17
- binutils-2.27

One could add a newer toolchain to the buildtools tarball to address
some of the CentOS-7 support problems. So far, we have only use
the host's toolchain and it seems best to continue to do so.

Release and support dates for CentOS-6,7,8 are here:
https://wiki.centos.org/About/Product
Note that 'Full Updates' or new hardware support for
CentOS-7 stops in Q3 2020.

--
# Randy MacLeod
# Wind River Linux


Nicholas Krause
 

On 12/10/19 12:22 PM, Randy MacLeod wrote:

In the YP technical meeting today, Richard suggested that we stop
support for CentOS-7. Is there any objection to doing so
before 3.1-M2?

CentOS-7 is just too old and there is significant work to support it.
Richard said that many if not most of the package upgrades that he
deals with fail for CentOS-7 and he has to either fix them himself
or get the person who submitted the work to do so. Newer distributions
are not nearly so problematic.

While the CentOS-7 distro is still a supported by it's provider,
the toolchain is very old:
 - gcc-4.8
 - glibc-2.17
 - binutils-2.27

One could add a newer toolchain to the buildtools tarball to address
some of the CentOS-7 support problems. So far, we have only use
the host's toolchain and it seems best to continue to do so.

Release and support dates for CentOS-6,7,8 are here:
  https://wiki.centos.org/About/Product
Note that 'Full Updates' or new hardware support for
CentOS-7 stops in Q3 2020.
When we talking about moving to C++11 on the toolchain side for gcc, generally
the problem was older in support vendor distributions. If CentOS 7 is going out
of support soon its a good idea. Otherwise for now just add a tarball until then
would be my idea.

Cheers,
Nick


Armin Kuster
 

On 12/10/19 9:22 AM, Randy MacLeod wrote:

In the YP technical meeting today, Richard suggested that we stop
support for CentOS-7. Is there any objection to doing so
before 3.1-M2?
Sounds good to me.

- Armin

CentOS-7 is just too old and there is significant work to support it.
Richard said that many if not most of the package upgrades that he
deals with fail for CentOS-7 and he has to either fix them himself
or get the person who submitted the work to do so. Newer distributions
are not nearly so problematic.

While the CentOS-7 distro is still a supported by it's provider,
the toolchain is very old:
 - gcc-4.8
 - glibc-2.17
 - binutils-2.27

One could add a newer toolchain to the buildtools tarball to address
some of the CentOS-7 support problems. So far, we have only use
the host's toolchain and it seems best to continue to do so.

Release and support dates for CentOS-6,7,8 are here:
  https://wiki.centos.org/About/Product
Note that 'Full Updates' or new hardware support for
CentOS-7 stops in Q3 2020.


Khem Raj
 

On Tue, Dec 10, 2019 at 9:23 AM Randy MacLeod
<randy.macleod@...> wrote:


In the YP technical meeting today, Richard suggested that we stop
support for CentOS-7. Is there any objection to doing so
before 3.1-M2?

CentOS-7 is just too old and there is significant work to support it.
I am in support of it, but then I also fear that many corporate
policies might still
be using it until 2024 when security updates end so perhaps would like to hear
centos7 users here. if no one speaks up then we can safely retire it before 3.1

Richard said that many if not most of the package upgrades that he
deals with fail for CentOS-7 and he has to either fix them himself
or get the person who submitted the work to do so. Newer distributions
are not nearly so problematic.

While the CentOS-7 distro is still a supported by it's provider,
the toolchain is very old:
- gcc-4.8
- glibc-2.17
- binutils-2.27

One could add a newer toolchain to the buildtools tarball to address
some of the CentOS-7 support problems. So far, we have only use
the host's toolchain and it seems best to continue to do so.

Release and support dates for CentOS-6,7,8 are here:
https://wiki.centos.org/About/Product
Note that 'Full Updates' or new hardware support for
CentOS-7 stops in Q3 2020.

--
# Randy MacLeod
# Wind River Linux
_______________________________________________
Openembedded-architecture mailing list
Openembedded-architecture@...
http://lists.openembedded.org/mailman/listinfo/openembedded-architecture


Diego Santa Cruz
 

-----Original Message-----
From: openembedded-architecture-bounces@...
<openembedded-architecture-bounces@...> On Behalf Of
Khem Raj
Sent: 10 December 2019 20:35
To: Randy MacLeod <randy.macleod@...>
Cc: openembedded-architecture <openembedded-
architecture@...>
Subject: Re: [Openembedded-architecture] Yocto support for Centos-7 (RHEL-7):
drop in early 2020?

On Tue, Dec 10, 2019 at 9:23 AM Randy MacLeod
<randy.macleod@...> wrote:


In the YP technical meeting today, Richard suggested that we stop
support for CentOS-7. Is there any objection to doing so before
3.1-M2?

CentOS-7 is just too old and there is significant work to support it.
I am in support of it, but then I also fear that many corporate policies might still
be using it until 2024 when security updates end so perhaps would like to hear
centos7 users here. if no one speaks up then we can safely retire it before 3.1
While I see what the motivation to remove CentOS-7 is, dropping it will probably create issues for people. CentOS 8 was released not so long ago. In our case we have older products (among which Yocto based ones) which do not necessarily work on CentOS 8. CentOS 8 is relatively recent, so we have not had time to test how old products work on it.

Isn't it possible to require things like devtoolset-8 (gcc 8.3, binutils-2.30) on CentOS 7 to keep it going?

In our case we are using devtoolset-8 with Yocto thud on CentOS 7 with success, as some layers require a recent host gcc to build.

Richard said that many if not most of the package upgrades that he
deals with fail for CentOS-7 and he has to either fix them himself or
get the person who submitted the work to do so. Newer distributions
are not nearly so problematic.

While the CentOS-7 distro is still a supported by it's provider, the
toolchain is very old:
- gcc-4.8
- glibc-2.17
- binutils-2.27

One could add a newer toolchain to the buildtools tarball to address
some of the CentOS-7 support problems. So far, we have only use the
host's toolchain and it seems best to continue to do so.

Release and support dates for CentOS-6,7,8 are here:
https://wiki.centos.org/About/Product
Note that 'Full Updates' or new hardware support for
CentOS-7 stops in Q3 2020.

--
# Randy MacLeod
# Wind River Linux
_______________________________________________
Openembedded-architecture mailing list
Openembedded-architecture@...
http://lists.openembedded.org/mailman/listinfo/openembedded-architectu
re
_______________________________________________
Openembedded-architecture mailing list
Openembedded-architecture@...
http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
--
Diego Santa Cruz, PhD
Technology Architect
spinetix.com


Andreas Müller
 

On Wed, Dec 11, 2019 at 8:15 AM Diego Santa Cruz via
Openembedded-architecture
<openembedded-architecture@...> wrote:

-----Original Message-----
From: openembedded-architecture-bounces@...
<openembedded-architecture-bounces@...> On Behalf Of
Khem Raj
Sent: 10 December 2019 20:35
To: Randy MacLeod <randy.macleod@...>
Cc: openembedded-architecture <openembedded-
architecture@...>
Subject: Re: [Openembedded-architecture] Yocto support for Centos-7 (RHEL-7):
drop in early 2020?

On Tue, Dec 10, 2019 at 9:23 AM Randy MacLeod
<randy.macleod@...> wrote:


In the YP technical meeting today, Richard suggested that we stop
support for CentOS-7. Is there any objection to doing so before
3.1-M2?

CentOS-7 is just too old and there is significant work to support it.
I am in support of it, but then I also fear that many corporate policies might still
be using it until 2024 when security updates end so perhaps would like to hear
centos7 users here. if no one speaks up then we can safely retire it before 3.1
While I see what the motivation to remove CentOS-7 is, dropping it will probably create issues for people. CentOS 8 was released not so long ago. In our case we have older products (among which Yocto based ones) which do not necessarily work on CentOS 8. CentOS 8 is relatively recent, so we have not had time to test how old products work on it.

Isn't it possible to require things like devtoolset-8 (gcc 8.3, binutils-2.30) on CentOS 7 to keep it going?

In our case we are using devtoolset-8 with Yocto thud on CentOS 7 with success, as some layers require a recent host gcc to build.
How about extending uninative with more gcc bits?

Andreas


Richard Purdie
 

On Wed, 2019-12-11 at 11:18 +0100, Andreas Müller wrote:
On Wed, Dec 11, 2019 at 8:15 AM Diego Santa Cruz via
Openembedded-architecture
<openembedded-architecture@...> wrote:
-----Original Message-----
From: openembedded-architecture-bounces@...
<openembedded-architecture-bounces@...> On
Behalf Of
Khem Raj
Sent: 10 December 2019 20:35
To: Randy MacLeod <randy.macleod@...>
Cc: openembedded-architecture <openembedded-
architecture@...>
Subject: Re: [Openembedded-architecture] Yocto support for
Centos-7 (RHEL-7):
drop in early 2020?

On Tue, Dec 10, 2019 at 9:23 AM Randy MacLeod
<randy.macleod@...> wrote:

In the YP technical meeting today, Richard suggested that we
stop
support for CentOS-7. Is there any objection to doing so before
3.1-M2?

CentOS-7 is just too old and there is significant work to
support it.
I am in support of it, but then I also fear that many corporate
policies might still
be using it until 2024 when security updates end so perhaps would
like to hear
centos7 users here. if no one speaks up then we can safely retire
it before 3.1
While I see what the motivation to remove CentOS-7 is, dropping it
will probably create issues for people. CentOS 8 was released not
so long ago. In our case we have older products (among which Yocto
based ones) which do not necessarily work on CentOS 8. CentOS 8 is
relatively recent, so we have not had time to test how old products
work on it.

Isn't it possible to require things like devtoolset-8 (gcc 8.3,
binutils-2.30) on CentOS 7 to keep it going?

In our case we are using devtoolset-8 with Yocto thud on CentOS 7
with success, as some layers require a recent host gcc to build.
How about extending uninative with more gcc bits?
uninative isn't the right place. What we'd need is a nativesdk-gcc
recipe and then to add nativesdk-gcc to buildtools-tarball.

We could then add some mechanism to auto-install buildtools tarball up
front on systems that need it, in a similar way to what uninative does.

Definitely possible and would solve certain problems, we'd just need
someone to implement it...

Cheers,

Richard


Adrian Bunk
 

On Wed, Dec 11, 2019 at 10:29:27AM +0000, Richard Purdie wrote:
On Wed, 2019-12-11 at 11:18 +0100, Andreas Müller wrote:
On Wed, Dec 11, 2019 at 8:15 AM Diego Santa Cruz via
Openembedded-architecture
<openembedded-architecture@...> wrote:
While I see what the motivation to remove CentOS-7 is, dropping it
will probably create issues for people. CentOS 8 was released not
so long ago. In our case we have older products (among which Yocto
based ones) which do not necessarily work on CentOS 8. CentOS 8 is
relatively recent, so we have not had time to test how old products
work on it.

Isn't it possible to require things like devtoolset-8 (gcc 8.3,
binutils-2.30) on CentOS 7 to keep it going?

In our case we are using devtoolset-8 with Yocto thud on CentOS 7
with success, as some layers require a recent host gcc to build.
How about extending uninative with more gcc bits?
uninative isn't the right place. What we'd need is a nativesdk-gcc
recipe and then to add nativesdk-gcc to buildtools-tarball.

We could then add some mechanism to auto-install buildtools tarball up
front on systems that need it, in a similar way to what uninative does.

Definitely possible and would solve certain problems, we'd just need
someone to implement it...
What you describe sounds like a manual and painful way to create some
kind of container - once you have toolchain/chrpath/tar/... of the host
replaced there is not much left that is actually used from the host.

The simple and sane solution would be to provide or require a container
with a supported distribution instead.

Cheers,

Richard
cu
Adrian


Richard Purdie
 

On Wed, 2019-12-11 at 14:13 +0200, Adrian Bunk wrote:
On Wed, Dec 11, 2019 at 10:29:27AM +0000, Richard Purdie wrote:
On Wed, 2019-12-11 at 11:18 +0100, Andreas Müller wrote:
On Wed, Dec 11, 2019 at 8:15 AM Diego Santa Cruz via
Openembedded-architecture
<openembedded-architecture@...> wrote:
While I see what the motivation to remove CentOS-7 is, dropping
it
will probably create issues for people. CentOS 8 was released
not
so long ago. In our case we have older products (among which
Yocto
based ones) which do not necessarily work on CentOS 8. CentOS 8
is
relatively recent, so we have not had time to test how old
products
work on it.

Isn't it possible to require things like devtoolset-8 (gcc 8.3,
binutils-2.30) on CentOS 7 to keep it going?

In our case we are using devtoolset-8 with Yocto thud on CentOS
7
with success, as some layers require a recent host gcc to
build.
How about extending uninative with more gcc bits?
uninative isn't the right place. What we'd need is a nativesdk-gcc
recipe and then to add nativesdk-gcc to buildtools-tarball.

We could then add some mechanism to auto-install buildtools tarball
up
front on systems that need it, in a similar way to what uninative
does.

Definitely possible and would solve certain problems, we'd just
need
someone to implement it...
What you describe sounds like a manual and painful way to create
some kind of container - once you have toolchain/chrpath/tar/... of
the host replaced there is not much left that is actually used from
the host.

The simple and sane solution would be to provide or require a
container with a supported distribution instead.
We already have the technology for most of it and its tried and tested.

Creating containers, whilst easier than it ever used to be, does
usually require elevated permissions and can cause problems with things
like qemu acceleration and networking. If you've already dealt with
that, fine but some setups wouldn't have.

So for some use cases containers are simpler, for some they are harder,
and this would help.

Thinking about it, it may well be the easiest way of supporting LTS on
older distros on the autobuilder workers too. I know Tim is looking at
the container angle there but this one is much easier to do from a
permissions standpoint.

Yes, its old fashioned, totally agree on that.

Cheers,

Richard


Adrian Bunk
 

On Wed, Dec 11, 2019 at 12:33:45PM +0000, Richard Purdie wrote:
...
Creating containers, whilst easier than it ever used to be, does
usually require elevated permissions and can cause problems with things
like qemu acceleration and networking. If you've already dealt with
that, fine but some setups wouldn't have.
...
Status quo is that qemu might be broken when the host has a more recent
libdrm than the Yocto release to be built.

Like the qemu virgl issues with warrior on Fedora 30.

Cheers,

Richard
cu
Adrian


Alexander Kanavin
 

On Wed, 11 Dec 2019 at 13:58, Adrian Bunk <bunk@...> wrote:
>...
> Creating containers, whilst easier than it ever used to be, does
> usually require elevated permissions and can cause problems with things
> like qemu acceleration and networking. If you've already dealt with
> that, fine but some setups wouldn't have.
>...

Status quo is that qemu might be broken when the host has a more recent
libdrm than the Yocto release to be built.

Like the qemu virgl issues with warrior on Fedora 30.

I wouldn't say that qemu is broken when virgl isn't working. Virgl support is entirely optional, and you have to explicitly request it by passing an option to runqemu. It's also not working on some very old distros like centos 7, but rather than take them off the supported distro list, we simply skip the automated test there, as there is no hope to make it work.

Ideas on how to better decouple virgl support from the host GL stack including libdrm (without drastically increasing build times) are welcome.

Alex


Philip Balister
 

On 12/11/19 5:29 AM, Richard Purdie wrote:
On Wed, 2019-12-11 at 11:18 +0100, Andreas Müller wrote:
On Wed, Dec 11, 2019 at 8:15 AM Diego Santa Cruz via
Openembedded-architecture
<openembedded-architecture@...> wrote:
-----Original Message-----
From: openembedded-architecture-bounces@...
<openembedded-architecture-bounces@...> On
Behalf Of
Khem Raj
Sent: 10 December 2019 20:35
To: Randy MacLeod <randy.macleod@...>
Cc: openembedded-architecture <openembedded-
architecture@...>
Subject: Re: [Openembedded-architecture] Yocto support for
Centos-7 (RHEL-7):
drop in early 2020?

On Tue, Dec 10, 2019 at 9:23 AM Randy MacLeod
<randy.macleod@...> wrote:

In the YP technical meeting today, Richard suggested that we
stop
support for CentOS-7. Is there any objection to doing so before
3.1-M2?

CentOS-7 is just too old and there is significant work to
support it.
I am in support of it, but then I also fear that many corporate
policies might still
be using it until 2024 when security updates end so perhaps would
like to hear
centos7 users here. if no one speaks up then we can safely retire
it before 3.1
While I see what the motivation to remove CentOS-7 is, dropping it
will probably create issues for people. CentOS 8 was released not
so long ago. In our case we have older products (among which Yocto
based ones) which do not necessarily work on CentOS 8. CentOS 8 is
relatively recent, so we have not had time to test how old products
work on it.

Isn't it possible to require things like devtoolset-8 (gcc 8.3,
binutils-2.30) on CentOS 7 to keep it going?

In our case we are using devtoolset-8 with Yocto thud on CentOS 7
with success, as some layers require a recent host gcc to build.
How about extending uninative with more gcc bits?
uninative isn't the right place. What we'd need is a nativesdk-gcc
recipe and then to add nativesdk-gcc to buildtools-tarball.

We could then add some mechanism to auto-install buildtools tarball up
front on systems that need it, in a similar way to what uninative does.

Definitely possible and would solve certain problems, we'd just need
someone to implement it...
From my point of view, the people that need CentOS 7 support need to
step up and do the work. The project can't allocate critical development
resources to support older distros.

Philip


Cheers,

Richard


_______________________________________________
Openembedded-architecture mailing list
Openembedded-architecture@...
http://lists.openembedded.org/mailman/listinfo/openembedded-architecture


Andreas Müller
 

On Wed, Dec 11, 2019 at 11:29 AM Richard Purdie
<richard.purdie@...> wrote:
How about extending uninative with more gcc bits?
uninative isn't the right place. What we'd need is a nativesdk-gcc
recipe and then to add nativesdk-gcc to buildtools-tarball.
Maybe - but from user's perspective it is perfect: Enter a line in
local.conf and let it happen. No manual download/install / container
setup.

Did that to make our very old build server work with zeus images. We
have to keep it old because there are products sitting on VERY old
releases (I think it was daisy). And yes I know that this completely
irresponsible but we are a 'team' of two for the whole stack
(applications inclusive) - but that is another story...

Andreas

We could then add some mechanism to auto-install buildtools tarball up
front on systems that need it, in a similar way to what uninative does.

Definitely possible and would solve certain problems, we'd just need
someone to implement it...

Cheers,

Richard


Andre McCurdy
 

On Wed, Dec 11, 2019 at 4:14 AM Adrian Bunk <bunk@...> wrote:
On Wed, Dec 11, 2019 at 10:29:27AM +0000, Richard Purdie wrote:
On Wed, 2019-12-11 at 11:18 +0100, Andreas Müller wrote:
On Wed, Dec 11, 2019 at 8:15 AM Diego Santa Cruz via
Openembedded-architecture
<openembedded-architecture@...> wrote:
While I see what the motivation to remove CentOS-7 is, dropping it
will probably create issues for people. CentOS 8 was released not
so long ago. In our case we have older products (among which Yocto
based ones) which do not necessarily work on CentOS 8. CentOS 8 is
relatively recent, so we have not had time to test how old products
work on it.

Isn't it possible to require things like devtoolset-8 (gcc 8.3,
binutils-2.30) on CentOS 7 to keep it going?

In our case we are using devtoolset-8 with Yocto thud on CentOS 7
with success, as some layers require a recent host gcc to build.
How about extending uninative with more gcc bits?
uninative isn't the right place. What we'd need is a nativesdk-gcc
recipe and then to add nativesdk-gcc to buildtools-tarball.

We could then add some mechanism to auto-install buildtools tarball up
front on systems that need it, in a similar way to what uninative does.

Definitely possible and would solve certain problems, we'd just need
someone to implement it...
What you describe sounds like a manual and painful way to create some
kind of container - once you have toolchain/chrpath/tar/... of the host
replaced there is not much left that is actually used from the host.

The simple and sane solution would be to provide or require a container
with a supported distribution instead.
The downside of that is that it causes problems for anyone who is
already building in a container, e.g. anyone using a Docker image to
run Jenkins, etc.

https://hub.docker.com/r/jenkins/jenkins/


Denys Dmytriyenko
 

On Wed, Dec 11, 2019 at 01:30:30PM -0500, Philip Balister wrote:
On 12/11/19 5:29 AM, Richard Purdie wrote:
On Wed, 2019-12-11 at 11:18 +0100, Andreas Müller wrote:
On Wed, Dec 11, 2019 at 8:15 AM Diego Santa Cruz via
Openembedded-architecture
<openembedded-architecture@...> wrote:
-----Original Message-----
From: openembedded-architecture-bounces@...
<openembedded-architecture-bounces@...> On
Behalf Of
Khem Raj
Sent: 10 December 2019 20:35
To: Randy MacLeod <randy.macleod@...>
Cc: openembedded-architecture <openembedded-
architecture@...>
Subject: Re: [Openembedded-architecture] Yocto support for
Centos-7 (RHEL-7):
drop in early 2020?

On Tue, Dec 10, 2019 at 9:23 AM Randy MacLeod
<randy.macleod@...> wrote:

In the YP technical meeting today, Richard suggested that we
stop
support for CentOS-7. Is there any objection to doing so before
3.1-M2?

CentOS-7 is just too old and there is significant work to
support it.
I am in support of it, but then I also fear that many corporate
policies might still
be using it until 2024 when security updates end so perhaps would
like to hear
centos7 users here. if no one speaks up then we can safely retire
it before 3.1
While I see what the motivation to remove CentOS-7 is, dropping it
will probably create issues for people. CentOS 8 was released not
so long ago. In our case we have older products (among which Yocto
based ones) which do not necessarily work on CentOS 8. CentOS 8 is
relatively recent, so we have not had time to test how old products
work on it.

Isn't it possible to require things like devtoolset-8 (gcc 8.3,
binutils-2.30) on CentOS 7 to keep it going?

In our case we are using devtoolset-8 with Yocto thud on CentOS 7
with success, as some layers require a recent host gcc to build.
How about extending uninative with more gcc bits?
uninative isn't the right place. What we'd need is a nativesdk-gcc
recipe and then to add nativesdk-gcc to buildtools-tarball.

We could then add some mechanism to auto-install buildtools tarball up
front on systems that need it, in a similar way to what uninative does.

Definitely possible and would solve certain problems, we'd just need
someone to implement it...
From my point of view, the people that need CentOS 7 support need to
step up and do the work. The project can't allocate critical development
resources to support older distros.
I agree with Philip here - we should not be spending already scarce
engineering resources trying to shoehorn CentOS 7 support in.

I realize this is mostly about OE-Core, but on a related note, I very
recently had to install a more modern gcc8 compiler on Ubuntu 16.04 on some
of our build servers, as 16.04 was lacking recent C++ standards support
in its default 5.4 compiler. The point is that we cannot keep on patching
out every use of newer API to make it work with old OSes...

--
Denys


Andre McCurdy
 

On Wed, Dec 11, 2019 at 5:13 PM Denys Dmytriyenko <denis@...> wrote:
On Wed, Dec 11, 2019 at 01:30:30PM -0500, Philip Balister wrote:
On 12/11/19 5:29 AM, Richard Purdie wrote:
On Wed, 2019-12-11 at 11:18 +0100, Andreas Müller wrote:
On Wed, Dec 11, 2019 at 8:15 AM Diego Santa Cruz via
Openembedded-architecture
<openembedded-architecture@...> wrote:
-----Original Message-----
From: openembedded-architecture-bounces@...
<openembedded-architecture-bounces@...> On
Behalf Of
Khem Raj
Sent: 10 December 2019 20:35
To: Randy MacLeod <randy.macleod@...>
Cc: openembedded-architecture <openembedded-
architecture@...>
Subject: Re: [Openembedded-architecture] Yocto support for
Centos-7 (RHEL-7):
drop in early 2020?

On Tue, Dec 10, 2019 at 9:23 AM Randy MacLeod
<randy.macleod@...> wrote:

In the YP technical meeting today, Richard suggested that we
stop
support for CentOS-7. Is there any objection to doing so before
3.1-M2?

CentOS-7 is just too old and there is significant work to
support it.
I am in support of it, but then I also fear that many corporate
policies might still
be using it until 2024 when security updates end so perhaps would
like to hear
centos7 users here. if no one speaks up then we can safely retire
it before 3.1
While I see what the motivation to remove CentOS-7 is, dropping it
will probably create issues for people. CentOS 8 was released not
so long ago. In our case we have older products (among which Yocto
based ones) which do not necessarily work on CentOS 8. CentOS 8 is
relatively recent, so we have not had time to test how old products
work on it.

Isn't it possible to require things like devtoolset-8 (gcc 8.3,
binutils-2.30) on CentOS 7 to keep it going?

In our case we are using devtoolset-8 with Yocto thud on CentOS 7
with success, as some layers require a recent host gcc to build.
How about extending uninative with more gcc bits?
uninative isn't the right place. What we'd need is a nativesdk-gcc
recipe and then to add nativesdk-gcc to buildtools-tarball.

We could then add some mechanism to auto-install buildtools tarball up
front on systems that need it, in a similar way to what uninative does.

Definitely possible and would solve certain problems, we'd just need
someone to implement it...
From my point of view, the people that need CentOS 7 support need to
step up and do the work. The project can't allocate critical development
resources to support older distros.
I agree with Philip here - we should not be spending already scarce
engineering resources trying to shoehorn CentOS 7 support in.
We already spend scarce engineering resources on stuff like (just as
an example) gcc for the target, which is a far more "niche" use case
than CentOS 7 support.

You could also ask the question why do we have scarce engineering
resources? One factor is that OE is not user friendly and putting up
more barriers (ie stricter requirements on the host OS) isn't going to
help with that. Effort spent to increase the chances that OE "just
works" by automatically providing more of its dependencies and relying
less on the host may be a good investment in terms of alienating less
users, who may then persevere long enough to eventually become
contributors.

I realize this is mostly about OE-Core, but on a related note, I very
recently had to install a more modern gcc8 compiler on Ubuntu 16.04 on some
of our build servers, as 16.04 was lacking recent C++ standards support
in its default 5.4 compiler. The point is that we cannot keep on patching
out every use of newer API to make it work with old OSes...

--
Denys
_______________________________________________
Openembedded-architecture mailing list
Openembedded-architecture@...
http://lists.openembedded.org/mailman/listinfo/openembedded-architecture


Adrian Bunk
 

On Wed, Dec 11, 2019 at 06:31:30PM -0800, Andre McCurdy wrote:
On Wed, Dec 11, 2019 at 5:13 PM Denys Dmytriyenko <denis@...> wrote:
On Wed, Dec 11, 2019 at 01:30:30PM -0500, Philip Balister wrote:

From my point of view, the people that need CentOS 7 support need to
step up and do the work. The project can't allocate critical development
resources to support older distros.
I agree with Philip here - we should not be spending already scarce
engineering resources trying to shoehorn CentOS 7 support in.
We already spend scarce engineering resources on stuff like (just as
an example) gcc for the target, which is a far more "niche" use case
than CentOS 7 support.
It does matter a lot how the resulting work is distributed.

There is no need to question whether niche features like gcc or GNOME
for the target is a useful way of spending resources since the work is
done by the people interested in the feature.

Niche features like CentOS 7 support or musl place a burden on everyone
contributing to OE, since these are common cases where completely
unrelated contributions require extra work.

In some cases this even creates new bugs for everyone else,
like the breakage caused by an incorrect CentOS 7 workaround in nettle
that needed a last-minute fixup before the release of Yocto 2.7.

You could also ask the question why do we have scarce engineering
resources? One factor is that OE is not user friendly and putting up
more barriers (ie stricter requirements on the host OS) isn't going to
help with that. Effort spent to increase the chances that OE "just
works" by automatically providing more of its dependencies and relying
less on the host may be a good investment in terms of alienating less
users, who may then persevere long enough to eventually become
contributors.
The problem is not lack of users, the problem is converting existing
users into upstream contributors.

Effort spent on getting more users is wasted effort if the goal is to
improve the scarce engineering resources.

And existing contributors might stop contributing when a large part of
the contributing effort ends up having to be spent on niche features
without interest to the contributor.

cu
Adrian


Andre McCurdy
 

On Wed, Dec 11, 2019 at 7:38 PM Adrian Bunk <bunk@...> wrote:
On Wed, Dec 11, 2019 at 06:31:30PM -0800, Andre McCurdy wrote:
On Wed, Dec 11, 2019 at 5:13 PM Denys Dmytriyenko <denis@...> wrote:
On Wed, Dec 11, 2019 at 01:30:30PM -0500, Philip Balister wrote:

From my point of view, the people that need CentOS 7 support need to
step up and do the work. The project can't allocate critical development
resources to support older distros.
I agree with Philip here - we should not be spending already scarce
engineering resources trying to shoehorn CentOS 7 support in.
We already spend scarce engineering resources on stuff like (just as
an example) gcc for the target, which is a far more "niche" use case
than CentOS 7 support.
It does matter a lot how the resulting work is distributed.

There is no need to question whether niche features like gcc or GNOME
for the target is a useful way of spending resources since the work is
done by the people interested in the feature.
Yes, that's probably expected. Developers work on stuff which
interests them. That's precisely why there's a danger that effort and
resources don't always get spent on the work which would benefit the
widest range of users.

Niche features like CentOS 7 support or musl place a burden on everyone
contributing to OE, since these are common cases where completely
unrelated contributions require extra work.
True. Continually updating all packages in oe-core and supporting
multiple CPU architecture places a burden on everyone contributing to
OE too. There's always a trade off between burdening developers and
making the project interesting / useful / usable for users.

In some cases this even creates new bugs for everyone else,
like the breakage caused by an incorrect CentOS 7 workaround in nettle
that needed a last-minute fixup before the release of Yocto 2.7.
That was an embarrassing mistake, which you've brought up before. It
happens sometimes. Dropping support for CentOS 7 or musl isn't going
to stop embarrassing mistakes happening again. The good news though is
that if mistakes are fixed relatively quickly most users are either
completely unaware that anything happened or they just update and move
on. ie I don't think mistakes like that cause any real damage at all.

You could also ask the question why do we have scarce engineering
resources? One factor is that OE is not user friendly and putting up
more barriers (ie stricter requirements on the host OS) isn't going to
help with that. Effort spent to increase the chances that OE "just
works" by automatically providing more of its dependencies and relying
less on the host may be a good investment in terms of alienating less
users, who may then persevere long enough to eventually become
contributors.
The problem is not lack of users, the problem is converting existing
users into upstream contributors.

Effort spent on getting more users is wasted effort if the goal is to
improve the scarce engineering resources.
If the goal is to increase the amount of engineering resource then
attracting / retaining users and converting them to contributors are
both important.

And existing contributors might stop contributing when a large part of
the contributing effort ends up having to be spent on niche features
without interest to the contributor.
That's true. It also works the other way around though - I've largely
given up contributing because the particular niche features which
interest me don't fit well upstream. Kicking niche features out of the
project can reduce contributions too.


Adrian Bunk
 

On Wed, Dec 11, 2019 at 08:48:04PM -0800, Andre McCurdy wrote:
On Wed, Dec 11, 2019 at 7:38 PM Adrian Bunk <bunk@...> wrote:

There is no need to question whether niche features like gcc or GNOME
for the target is a useful way of spending resources since the work is
done by the people interested in the feature.
Yes, that's probably expected. Developers work on stuff which
interests them. That's precisely why there's a danger that effort and
resources don't always get spent on the work which would benefit the
widest range of users.
This is not a danger, this is how open source projects work.

Yocto is not a company where all developers are paid resources that can
be told what to spend their time on.

Developers spend effort on what is useful for their local paid work,
or what is fun to do as a hobby.

...
In some cases this even creates new bugs for everyone else,
like the breakage caused by an incorrect CentOS 7 workaround in nettle
that needed a last-minute fixup before the release of Yocto 2.7.
That was an embarrassing mistake, which you've brought up before.
Not exactly embarrassing, the problem is obvious only in hindsight.

It happens sometimes. Dropping support for CentOS 7 or musl isn't going
to stop embarrassing mistakes happening again.
...
It avoids bugs being introduced by workarounds.

Trying to build and run 2020 software on a 2013 distribution is
problematic, and will generate more and more problems noone else
has seen or is interested in fixing.

Bumping the baseline by 3 years to Ubuntu 16.04 would make both existing
and future OE-specific workarounds for ancient hosts unnecessary.

cu
Adrian


Andre McCurdy
 

On Wed, Dec 11, 2019 at 9:55 PM Adrian Bunk <bunk@...> wrote:
On Wed, Dec 11, 2019 at 08:48:04PM -0800, Andre McCurdy wrote:
On Wed, Dec 11, 2019 at 7:38 PM Adrian Bunk <bunk@...> wrote:

There is no need to question whether niche features like gcc or GNOME
for the target is a useful way of spending resources since the work is
done by the people interested in the feature.
Yes, that's probably expected. Developers work on stuff which
interests them. That's precisely why there's a danger that effort and
resources don't always get spent on the work which would benefit the
widest range of users.
This is not a danger, this is how open source projects work.
Yes, it's how open source projects work. It's also a model where
there's a risk that the best interests of the wider user base don't
get much consideration. There's no conflict between those two
statements.

Yocto is not a company where all developers are paid resources that can
be told what to spend their time on.

Developers spend effort on what is useful for their local paid work,
or what is fun to do as a hobby.

...
In some cases this even creates new bugs for everyone else,
like the breakage caused by an incorrect CentOS 7 workaround in nettle
that needed a last-minute fixup before the release of Yocto 2.7.
That was an embarrassing mistake, which you've brought up before.
Not exactly embarrassing, the problem is obvious only in hindsight.

It happens sometimes. Dropping support for CentOS 7 or musl isn't going
to stop embarrassing mistakes happening again.
...
It avoids bugs being introduced by workarounds.

Trying to build and run 2020 software on a 2013 distribution is
problematic, and will generate more and more problems noone else
has seen or is interested in fixing.
In general yes, but build environments are somewhat of a special in
that one of their key functions is to isolate the code being built
from any specific details of the host. OE already does a very good job
of doing that (by building -native versions of many of the tools
traditionally provided by the host in legacy build environment, etc)
but if there are ways to improve that isolation even further then I
don't think we should dismiss efforts to work on them just because key
developers are happy with the level of isolation we have already.

Bumping the baseline by 3 years to Ubuntu 16.04 would make both existing
and future OE-specific workarounds for ancient hosts unnecessary.

cu
Adrian