Date   

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

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


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

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


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

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


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

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


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

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


Re: Yocto support for Centos-7 (RHEL-7): drop in early 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


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

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.


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

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


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


Re: [OE-core] OE-Core python minimum version requirement

Nicolas Dechesne
 

On Thu, Dec 5, 2019 at 3:38 PM Khem Raj <raj.khem@...> wrote:

On Thu, Dec 5, 2019 at 2:19 AM Paul Eggleton
<paul.eggleton@...> wrote:

On Thursday, 5 December 2019 7:48:11 PM NZDT Nicolas Dechesne wrote:
On Thu, Dec 5, 2019 at 3:08 AM Paul Eggleton
<paul.eggleton@...> wrote:
FYI I came across repology.org which tells you the version of various
packages in each distro, though it's not ideal:

https://repology.org/project/python/versions
Nice! How do we get OE plugged into that? Have you looked at that?
No, I haven't - only discovered it today. I agree we should look into it
though.

you need to have binary feeds somewhere.
I don't think so. I believe it could work straight from the layerindex
JSON API. in fact the 'source' could be:
http://layers.openembedded.org/layerindex/api/recipes/?filter=layerbranch__branch__name:master

and then we need a simple JSON parser that converts 'our' data into
'their' format, such as:
https://github.com/repology/repology-updater/blob/master/repology/parsers/parsers/ravenports.py

If you check their debian config for example, they use debian 'source'
packages for input:
https://github.com/repology/repology-updater/blob/master/repos.d/deb/debian.yaml


Cheers
Paul

--

Paul Eggleton
Intel System Software Products


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


Re: [OE-core] OE-Core python minimum version requirement

Khem Raj
 

On Thu, Dec 5, 2019 at 2:19 AM Paul Eggleton
<paul.eggleton@...> wrote:

On Thursday, 5 December 2019 7:48:11 PM NZDT Nicolas Dechesne wrote:
On Thu, Dec 5, 2019 at 3:08 AM Paul Eggleton
<paul.eggleton@...> wrote:
FYI I came across repology.org which tells you the version of various
packages in each distro, though it's not ideal:

https://repology.org/project/python/versions
Nice! How do we get OE plugged into that? Have you looked at that?
No, I haven't - only discovered it today. I agree we should look into it
though.

you need to have binary feeds somewhere.

Cheers
Paul

--

Paul Eggleton
Intel System Software Products


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


Re: OE-Core python minimum version requirement

Paul Eggleton <paul.eggleton@...>
 

On Thursday, 5 December 2019 7:48:11 PM NZDT Nicolas Dechesne wrote:
On Thu, Dec 5, 2019 at 3:08 AM Paul Eggleton
<paul.eggleton@...> wrote:
FYI I came across repology.org which tells you the version of various
packages in each distro, though it's not ideal:

https://repology.org/project/python/versions
Nice! How do we get OE plugged into that? Have you looked at that?
No, I haven't - only discovered it today. I agree we should look into it
though.

Cheers
Paul

--

Paul Eggleton
Intel System Software Products


Re: OE-Core python minimum version requirement

Nicolas Dechesne
 

On Thu, Dec 5, 2019 at 3:08 AM Paul Eggleton
<paul.eggleton@...> wrote:

On Thursday, 5 December 2019 6:45:03 AM NZDT Richard Purdie wrote:
I just enabled hashequiv's server in local mode by default in poky.

This causes an unintended side effect of requiring python 3.5 as the
minimum version.

We had thought that the servers would be 'rare' and a 3.5 version
requirement for that was fine. It turns out a local server is also
extremely useful.

The code needed the python 3.5 async support and trying to write it any
other way is a nightmare, we need that performance for the server.

At this point I think we just give in and require python 3.5 as a
minimum. Any objections?
Seems reasonable to me. Theoretically this should allow us to complete the
subprocess cleanups as well (time permitting of course).

FYI I came across repology.org which tells you the version of various packages
in each distro, though it's not ideal:

https://repology.org/project/python/versions
Nice! How do we get OE plugged into that? Have you looked at that?


That seems to be missing a few distros, here's another entry:

https://repology.org/project/python3-defaults/versions

For Ubuntu you have to go back to 14.04 to have 3.4; any others other than
CentOS 7 that are as old we don't really support.

There is also pkgs.org that I could have sworn used to support comparing
package versions across distros but it doesn't seem to want to do it anymore.
Distrowatch also tracks this per distro but only allows side-by-side
comparisons across versions within a distro or only between two distros. I
think in this instance we have the information we need though.

Cheers,
Paul


--

Paul Eggleton
Intel System Software Products


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


Re: OE-Core python minimum version requirement

Khem Raj
 

On Wed, Dec 4, 2019 at 6:08 PM Paul Eggleton
<paul.eggleton@...> wrote:

On Thursday, 5 December 2019 6:45:03 AM NZDT Richard Purdie wrote:
I just enabled hashequiv's server in local mode by default in poky.

This causes an unintended side effect of requiring python 3.5 as the
minimum version.

We had thought that the servers would be 'rare' and a 3.5 version
requirement for that was fine. It turns out a local server is also
extremely useful.

The code needed the python 3.5 async support and trying to write it any
other way is a nightmare, we need that performance for the server.

At this point I think we just give in and require python 3.5 as a
minimum. Any objections?
Seems reasonable to me. Theoretically this should allow us to complete the
subprocess cleanups as well (time permitting of course).

FYI I came across repology.org which tells you the version of various packages
in each distro, though it's not ideal:

https://repology.org/project/python/versions

That seems to be missing a few distros, here's another entry:

https://repology.org/project/python3-defaults/versions

For Ubuntu you have to go back to 14.04 to have 3.4; any others other than
CentOS 7 that are as old we don't really support.
yeah and we bandaid centos7 anyway. So probably all is fine.

There is also pkgs.org that I could have sworn used to support comparing
package versions across distros but it doesn't seem to want to do it anymore.
Distrowatch also tracks this per distro but only allows side-by-side
comparisons across versions within a distro or only between two distros. I
think in this instance we have the information we need though.

Cheers,
Paul


--

Paul Eggleton
Intel System Software Products


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


Re: OE-Core python minimum version requirement

Paul Eggleton <paul.eggleton@...>
 

On Thursday, 5 December 2019 6:45:03 AM NZDT Richard Purdie wrote:
I just enabled hashequiv's server in local mode by default in poky.

This causes an unintended side effect of requiring python 3.5 as the
minimum version.

We had thought that the servers would be 'rare' and a 3.5 version
requirement for that was fine. It turns out a local server is also
extremely useful.

The code needed the python 3.5 async support and trying to write it any
other way is a nightmare, we need that performance for the server.

At this point I think we just give in and require python 3.5 as a
minimum. Any objections?
Seems reasonable to me. Theoretically this should allow us to complete the
subprocess cleanups as well (time permitting of course).

FYI I came across repology.org which tells you the version of various packages
in each distro, though it's not ideal:

https://repology.org/project/python/versions

That seems to be missing a few distros, here's another entry:

https://repology.org/project/python3-defaults/versions

For Ubuntu you have to go back to 14.04 to have 3.4; any others other than
CentOS 7 that are as old we don't really support.

There is also pkgs.org that I could have sworn used to support comparing
package versions across distros but it doesn't seem to want to do it anymore.
Distrowatch also tracks this per distro but only allows side-by-side
comparisons across versions within a distro or only between two distros. I
think in this instance we have the information we need though.

Cheers,
Paul


--

Paul Eggleton
Intel System Software Products


Re: [OE-core] OE-Core python minimum version requirement

Tom Rini
 

On Thu, Dec 05, 2019 at 01:23:24AM +0200, Adrian Bunk wrote:
On Wed, Dec 04, 2019 at 06:02:37PM -0500, Tom Rini wrote:
On Wed, Dec 04, 2019 at 05:45:03PM +0000, Richard Purdie wrote:

I just enabled hashequiv's server in local mode by default in poky.

This causes an unintended side effect of requiring python 3.5 as the
minimum version.

We had thought that the servers would be 'rare' and a 3.5 version
requirement for that was fine. It turns out a local server is also
extremely useful.

The code needed the python 3.5 async support and trying to write it any
other way is a nightmare, we need that performance for the server.

At this point I think we just give in and require python 3.5 as a
minimum. Any objections?
In having to pick a minimum Python 3 for U-Boot, it was noted that
Debian/Stretch is 3.4 and gets end of long term support in 2022. 3.5
was otherwise fine I believe in the end.
Debian 9 (stretch) has 3.5
Debian 8 (jessie) has 3.4
Ah, ok, thanks.

--
Tom


Re: [OE-core] OE-Core python minimum version requirement

Adrian Bunk
 

On Wed, Dec 04, 2019 at 06:02:37PM -0500, Tom Rini wrote:
On Wed, Dec 04, 2019 at 05:45:03PM +0000, Richard Purdie wrote:

I just enabled hashequiv's server in local mode by default in poky.

This causes an unintended side effect of requiring python 3.5 as the
minimum version.

We had thought that the servers would be 'rare' and a 3.5 version
requirement for that was fine. It turns out a local server is also
extremely useful.

The code needed the python 3.5 async support and trying to write it any
other way is a nightmare, we need that performance for the server.

At this point I think we just give in and require python 3.5 as a
minimum. Any objections?
In having to pick a minimum Python 3 for U-Boot, it was noted that
Debian/Stretch is 3.4 and gets end of long term support in 2022. 3.5
was otherwise fine I believe in the end.
Debian 9 (stretch) has 3.5
Debian 8 (jessie) has 3.4

Tom
cu
Adrian


Re: [OE-core] OE-Core python minimum version requirement

Tom Rini
 

On Wed, Dec 04, 2019 at 05:45:03PM +0000, Richard Purdie wrote:

I just enabled hashequiv's server in local mode by default in poky.

This causes an unintended side effect of requiring python 3.5 as the
minimum version.

We had thought that the servers would be 'rare' and a 3.5 version
requirement for that was fine. It turns out a local server is also
extremely useful.

The code needed the python 3.5 async support and trying to write it any
other way is a nightmare, we need that performance for the server.

At this point I think we just give in and require python 3.5 as a
minimum. Any objections?
In having to pick a minimum Python 3 for U-Boot, it was noted that
Debian/Stretch is 3.4 and gets end of long term support in 2022. 3.5
was otherwise fine I believe in the end.

--
Tom


Re: OE-Core python minimum version requirement

Richard Purdie
 

On Wed, 2019-12-04 at 10:52 -0800, Khem Raj wrote:
On Wed, Dec 4, 2019 at 9:51 AM Ross Burton <ross.burton@...>
wrote:
On 04/12/2019 17:45, Richard Purdie wrote:
I just enabled hashequiv's server in local mode by default in
poky.

This causes an unintended side effect of requiring python 3.5 as
the
minimum version.

We had thought that the servers would be 'rare' and a 3.5 version
requirement for that was fine. It turns out a local server is
also
extremely useful.

The code needed the python 3.5 async support and trying to write
it any
other way is a nightmare, we need that performance for the
server.

At this point I think we just give in and require python 3.5 as a
minimum. Any objections?
None here.

For reference, 3.5.0 was released in September 2015 and is in
security-fixes only mode.
so how many supported distros have older python3 ?
We have to install python3 separately on Centos7 already so we're ok
there. I think its only debian8 with python 3.4.

Cheers,

Richard


Re: [OE-core] OE-Core python minimum version requirement

Josef Holzmayr <holzmayr@...>
 

On Wed, Dec 04, 2019 at 05:45:03PM +0000, Richard Purdie wrote:
I just enabled hashequiv's server in local mode by default in poky.

This causes an unintended side effect of requiring python 3.5 as the
minimum version.

We had thought that the servers would be 'rare' and a 3.5 version
requirement for that was fine. It turns out a local server is also
extremely useful.

The code needed the python 3.5 async support and trying to write it any
other way is a nightmare, we need that performance for the server.

At this point I think we just give in and require python 3.5 as a
minimum. Any objections?
A quick check on packages.ubuntu.com says 16.04 is on python 3.5.1,
18.04 is on 3.6.something.

Hence, looks good to me.

Greetz


Cheers,

Richard

--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@...
http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
———————————————
Josef Holzmayr
Software Developer Embedded Systems

Tel: +49 8444 9204-48
Fax: +49 8444 9204-50

R-S-I Elektrotechnik GmbH & Co. KG
Woelkestrasse 11
D-85301 Schweitenkirchen
www.rsi-elektrotechnik.de
———————————————
Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393
Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
Ust-IdNr: DE 128592548

_____________________________________________________________
Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363
Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
USt-IdNr.: DE 128592548

721 - 740 of 1685