From: Adrian Bunk <bunk@stusta.de>
To: Khem Raj <raj.khem@gmail.com>
Cc: Patches and discussions about the oe-core layer
<openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH 01/13] python: update to 2.7.17
Date: Tue, 19 Nov 2019 00:55:00 +0200 [thread overview]
Message-ID: <20191118225500.GB7568@localhost> (raw)
In-Reply-To: <CAMKF1sq3hnUuM7rcCbEhfbTmUtGbpMVVZkq8mFo24FKGG=kFYA@mail.gmail.com>
On Mon, Nov 18, 2019 at 02:16:30PM -0800, Khem Raj wrote:
> On Mon, Nov 18, 2019 at 2:06 PM Adrian Bunk <bunk@stusta.de> wrote:
>
> > On Mon, Nov 18, 2019 at 01:39:48PM -0800, Khem Raj wrote:
> > > On Mon, Nov 18, 2019 at 1:05 PM Adrian Bunk <bunk@stusta.de> wrote:
> > > > On Mon, Nov 18, 2019 at 10:13:05AM -0800, Khem Raj wrote:
> > > > > On Mon, Nov 18, 2019 at 5:08 AM Alexander Kanavin
> > > > > <alex.kanavin@gmail.com> wrote:
> > > > > >
> > > > > > Drop backports, rebase a couple of patches.
> > > > > >
> > > > > > This is the second last release of py 2.x; upstream support ends on
> > > > > > 1 January 2020, there will be one final 2.x afterwards.
> > > > > >
> > > > > > Note that the only thing that still needs python 2.x in oe-core is
> > > > > > u-boot; when the next u-boot update arrives, we should find out
> > > > > > where the py3 migration is for that component before merging the
> > > > > > update.
> > > > >
> > > > > I guess u-boot need it during build, in that case defer it to user to
> > > > > have python2 on build host
> > > > > could be possible.
> > > > >...
> > > >
> > > > That's a non-option since it could mean
> > > > "Yocto 3.1 cannot be built on Ubuntu 20.04".
> > > >
> > > > Ubuntu 20.04 might end up still shipping Python2,[1]
> > > > but you cannot rely on future distributions shipping it.
> > >
> > > And why should OE ship something that’s dropped by its own upstream and
> > > other distributions
> >
> > All I am saying is that relying on the host Python2 is a non-option.
> >
> > If any layer needs a native Python2, this has to be shipped either in
> > this layer or in a layer it depends on.
>
>
> We should explore disabling python support in uboot if it does not move to
> py3 perhaps there is a way like that having a single recipe require py2 is
> a bit too much
In u-boot build scripts are using Python2.
But this is being fixed upstream, so realistically in Yocto 3.1
Python2 can move to meta-oe.
cu
Adrian
next prev parent reply other threads:[~2019-11-18 22:55 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-18 13:07 [PATCH 01/13] python: update to 2.7.17 Alexander Kanavin
2019-11-18 13:07 ` [PATCH 02/13] runqemu: add options that enable virgl with the SDL frontend Alexander Kanavin
2019-11-18 13:07 ` [PATCH 03/13] oe-selftest: extend virgl gtk test to also check the SDL option Alexander Kanavin
2019-11-18 13:07 ` [PATCH 04/13] tiff: update to 4.1.0 Alexander Kanavin
2019-11-18 13:07 ` [PATCH 05/13] librepo: upgrade 1.10.6 -> 1.11.0 Alexander Kanavin
2019-11-18 13:07 ` [PATCH 06/13] btrfs-tools: upgrade 5.3 -> 5.3.1 Alexander Kanavin
2019-11-18 13:07 ` [PATCH 07/13] psmisc: update to 23.3 Alexander Kanavin
2019-11-18 13:07 ` [PATCH 08/13] libxslt: update to 1.1.34 Alexander Kanavin
2019-11-18 13:07 ` [PATCH 09/13] Revert "devtool/standard.py: Not filtering devtool workspace for devtool finish" Alexander Kanavin
2019-11-18 13:07 ` [PATCH 10/13] mpg123: upgrade 1.25.12 -> 1.25.13 Alexander Kanavin
2019-11-18 13:07 ` [PATCH 11/13] vala: upgrade 0.46.3 -> 0.46.4 Alexander Kanavin
2019-11-18 13:08 ` [PATCH 12/13] systat: upstream version check is working again Alexander Kanavin
2019-11-18 13:47 ` Peter Kjellerstedt
2019-11-18 13:08 ` [PATCH 13/13] man-pages: correct the SRC_URI Alexander Kanavin
2019-11-18 13:31 ` ✗ patchtest: failure for "python: update to 2.7.17..." and 12 more Patchwork
2019-11-18 18:13 ` [PATCH 01/13] python: update to 2.7.17 Khem Raj
2019-11-18 21:05 ` Adrian Bunk
2019-11-18 21:39 ` Khem Raj
2019-11-18 22:06 ` Adrian Bunk
2019-11-18 22:16 ` Khem Raj
2019-11-18 22:34 ` Ross Burton
2019-11-18 22:55 ` Adrian Bunk [this message]
2019-11-18 23:26 ` Khem Raj
2019-11-19 7:57 ` Tim Orling
2019-11-19 11:30 ` Alexander Kanavin
2019-11-19 15:49 ` Khem Raj
2019-11-19 16:30 ` Adrian Bunk
2019-11-19 16:47 ` Khem Raj
2019-11-20 11:57 ` Ross Burton
2019-11-25 3:36 ` Adrian Bunk
2019-11-19 22:44 ` Andreas Müller
2019-11-30 9:49 ` Adrian Bunk
2019-11-19 11:24 ` Alexander Kanavin
2019-11-20 12:56 ` Tom Rini
2019-11-20 13:47 ` Alexander Kanavin
2019-11-20 13:50 ` Tom Rini
2019-11-20 15:06 ` Alexander Kanavin
2019-11-20 15:08 ` Tom Rini
-- strict thread matches above, loose matches on Subject: below --
2019-11-18 14:28 Alexander Kanavin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191118225500.GB7568@localhost \
--to=bunk@stusta.de \
--cc=openembedded-core@lists.openembedded.org \
--cc=raj.khem@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox