[PATCH 1/2] gsettings-desktop-schemas: upgrade 3.28.1 -> 3.32.0

[PATCH 1/2] gsettings-desktop-schemas: upgrade 3.28.1 -> 3.32.0

[Andreas Müller]

* build with meson
* dependency intltool-native can go - they moved gettext only translation
* put gnome inherits together

Signed-off-by: Andreas Müller <schnitzeltony@gmail.com>
---
 ...gir-installation-for-cross-compiling.patch | 33 +++++++++++++++++++
 ...bb => gsettings-desktop-schemas_3.32.0.bb} | 11 ++++---
 2 files changed, 40 insertions(+), 4 deletions(-)
 create mode 100644 meta/recipes-gnome/gsettings-desktop-schemas/gsettings-desktop-schemas/0001-Do-not-skip-gir-installation-for-cross-compiling.patch
 rename meta/recipes-gnome/gsettings-desktop-schemas/{gsettings-desktop-schemas_3.28.1.bb => gsettings-desktop-schemas_3.32.0.bb} (43%)

diff --git a/meta/recipes-gnome/gsettings-desktop-schemas/gsettings-desktop-schemas/0001-Do-not-skip-gir-installation-for-cross-compiling.patch b/meta/recipes-gnome/gsettings-desktop-schemas/gsettings-desktop-schemas/0001-Do-not-skip-gir-installation-for-cross-compiling.patch
new file mode 100644
index 0000000000..c481b18f1c
--- /dev/null
+++ b/meta/recipes-gnome/gsettings-desktop-schemas/gsettings-desktop-schemas/0001-Do-not-skip-gir-installation-for-cross-compiling.patch
@@ -0,0 +1,33 @@
+From 42e58c4c3e95a4a78ee8294f9b3901726bbbabe4 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Andreas=20M=C3=BCller?= <schnitzeltony@gmail.com>
+Date: Sat, 11 May 2019 00:21:11 +0200
+Subject: [PATCH] Do not skip gir installation for cross compiling
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+We are cool and can handle cross gobject-introspection.
+
+Upstream-Status: Inappropriate [OE specific]
+
+Signed-off-by: Andreas Müller <schnitzeltony@gmail.com>
+---
+ headers/meson.build | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/headers/meson.build b/headers/meson.build
+index 3ce8b61..1132695 100644
+--- a/headers/meson.build
++++ b/headers/meson.build
+@@ -19,7 +19,7 @@ enums_xml = custom_target(
+   install: true,
+   install_dir: schemasdir)
+ 
+-if not meson.is_cross_build() and get_option('introspection')
++if get_option('introspection')
+   noinst_lib = shared_library('noinst',
+                               headers,
+                               install: false)
+-- 
+2.20.1
+
diff --git a/meta/recipes-gnome/gsettings-desktop-schemas/gsettings-desktop-schemas_3.28.1.bb b/meta/recipes-gnome/gsettings-desktop-schemas/gsettings-desktop-schemas_3.32.0.bb
similarity index 43%
rename from meta/recipes-gnome/gsettings-desktop-schemas/gsettings-desktop-schemas_3.28.1.bb
rename to meta/recipes-gnome/gsettings-desktop-schemas/gsettings-desktop-schemas_3.32.0.bb
index 693c109d83..859f70466b 100644
--- a/meta/recipes-gnome/gsettings-desktop-schemas/gsettings-desktop-schemas_3.28.1.bb
+++ b/meta/recipes-gnome/gsettings-desktop-schemas/gsettings-desktop-schemas_3.32.0.bb
@@ -5,9 +5,12 @@ BUGTRACKER = "https://bugzilla.gnome.org/"
 LICENSE = "LGPLv2.1"
 LIC_FILES_CHKSUM = "file://COPYING;md5=4fbd65380cdd255951079008b364516c"
 
-DEPENDS = "glib-2.0 intltool-native"
+DEPENDS = "glib-2.0"
 
-inherit gnomebase gsettings gettext gobject-introspection upstream-version-is-even
+GNOMEBASEBUILDCLASS = "meson"
 
-SRC_URI[archive.md5sum] = "83bb19d025f126fae495ab43a2f26f40"
-SRC_URI[archive.sha256sum] = "f88ea6849ffe897c51cfeca5e45c3890010c82c58be2aee18b01349648e5502f"
+inherit gnomebase gsettings gobject-introspection gettext upstream-version-is-even
+
+SRC_URI[archive.md5sum] = "0c2d468a482c12594757442c983aa8ea"
+SRC_URI[archive.sha256sum] = "2d59b4b3a548859dfae46314ee4666787a00d5c82db382e97df7aa9d0e310a35"
+SRC_URI += "file://0001-Do-not-skip-gir-installation-for-cross-compiling.patch"
-- 
2.20.1

[PATCH 2/2] python-six: put python2/3 variant together

[Andreas Müller]

Upcoming 60.2.3 mozjs (meta-oe) requires python(2)-six-native for its
configuration. Currently python(2)-six lives in meta-python and it could be
moved to mozjs's home meta-oe but that would be just further clutter.

Once applied here patch to meta-python will be send.

Signed-off-by: Andreas Müller <schnitzeltony@gmail.com>
---
 meta/recipes-devtools/python/python-six_1.12.0.bb | 2 ++
 1 file changed, 2 insertions(+)
 create mode 100644 meta/recipes-devtools/python/python-six_1.12.0.bb

diff --git a/meta/recipes-devtools/python/python-six_1.12.0.bb b/meta/recipes-devtools/python/python-six_1.12.0.bb
new file mode 100644
index 0000000000..9075745d74
--- /dev/null
+++ b/meta/recipes-devtools/python/python-six_1.12.0.bb
@@ -0,0 +1,2 @@
+inherit pypi setuptools
+require python-six.inc
-- 
2.20.1

Re: [PATCH 2/2] python-six: put python2/3 variant together

[Richard Purdie]

On Tue, 2019-05-21 at 11:00 +0200, Andreas Müller wrote:
> Upcoming 60.2.3 mozjs (meta-oe) requires python(2)-six-native for its
> configuration. Currently python(2)-six lives in meta-python and it
> could be
> moved to mozjs's home meta-oe but that would be just further clutter.
> 
> Once applied here patch to meta-python will be send.
> 
> Signed-off-by: Andreas Müller <schnitzeltony@gmail.com>
> ---
>  meta/recipes-devtools/python/python-six_1.12.0.bb | 2 ++
>  1 file changed, 2 insertions(+)
>  create mode 100644 meta/recipes-devtools/python/python-six_1.12.0.bb
> 
> diff --git a/meta/recipes-devtools/python/python-six_1.12.0.bb
> b/meta/recipes-devtools/python/python-six_1.12.0.bb
> new file mode 100644
> index 0000000000..9075745d74
> --- /dev/null
> +++ b/meta/recipes-devtools/python/python-six_1.12.0.bb
> @@ -0,0 +1,2 @@
> +inherit pypi setuptools
> +require python-six.inc

Can it not use python3? Python2 is rapidly running out of time at this
point and I'd not expect new dependencies on python2 to be appearing...

Cheers,

Richard

Re: [PATCH 2/2] python-six: put python2/3 variant together

[Andreas Müller]

On Tue, May 21, 2019 at 6:41 PM Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
>
> On Tue, 2019-05-21 at 11:00 +0200, Andreas Müller wrote:
> > Upcoming 60.2.3 mozjs (meta-oe) requires python(2)-six-native for its
> > configuration. Currently python(2)-six lives in meta-python and it
> > could be
> > moved to mozjs's home meta-oe but that would be just further clutter.
> >
> > Once applied here patch to meta-python will be send.
> >
> > Signed-off-by: Andreas Müller <schnitzeltony@gmail.com>
> > ---
> >  meta/recipes-devtools/python/python-six_1.12.0.bb | 2 ++
> >  1 file changed, 2 insertions(+)
> >  create mode 100644 meta/recipes-devtools/python/python-six_1.12.0.bb
> >
> > diff --git a/meta/recipes-devtools/python/python-six_1.12.0.bb
> > b/meta/recipes-devtools/python/python-six_1.12.0.bb
> > new file mode 100644
> > index 0000000000..9075745d74
> > --- /dev/null
> > +++ b/meta/recipes-devtools/python/python-six_1.12.0.bb
> > @@ -0,0 +1,2 @@
> > +inherit pypi setuptools
> > +require python-six.inc
>
> Can it not use python3? Python2 is rapidly running out of time at this
> point and I'd not expect new dependencies on python2 to be appearing...
>
> Cheers,
>
No sorry mozjs uses old crap in their configurations scripts nobody
else does (python which) and ask for python2 explicitly.

Andreas

Re: [PATCH 2/2] python-six: put python2/3 variant together

[richard.purdie]

On Tue, 2019-05-21 at 20:00 +0200, Andreas Müller wrote:
> On Tue, May 21, 2019 at 6:41 PM Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> > On Tue, 2019-05-21 at 11:00 +0200, Andreas Müller wrote:
> > > Upcoming 60.2.3 mozjs (meta-oe) requires python(2)-six-native for
> > > its
> > > configuration. Currently python(2)-six lives in meta-python and
> > > it
> > > could be
> > > moved to mozjs's home meta-oe but that would be just further
> > > clutter.
> > > 
> > > Once applied here patch to meta-python will be send.
> > > 
> > > Signed-off-by: Andreas Müller <schnitzeltony@gmail.com>
> > > ---
> > >  meta/recipes-devtools/python/python-six_1.12.0.bb | 2 ++
> > >  1 file changed, 2 insertions(+)
> > >  create mode 100644 meta/recipes-devtools/python/python-
> > > six_1.12.0.bb
> > > 
> > > diff --git a/meta/recipes-devtools/python/python-six_1.12.0.bb
> > > b/meta/recipes-devtools/python/python-six_1.12.0.bb
> > > new file mode 100644
> > > index 0000000000..9075745d74
> > > --- /dev/null
> > > +++ b/meta/recipes-devtools/python/python-six_1.12.0.bb
> > > @@ -0,0 +1,2 @@
> > > +inherit pypi setuptools
> > > +require python-six.inc
> > 
> > Can it not use python3? Python2 is rapidly running out of time at
> > this
> > point and I'd not expect new dependencies on python2 to be
> > appearing...
> > 
> > Cheers,
> > 
> No sorry mozjs uses old crap in their configurations scripts nobody
> else does (python which) and ask for python2 explicitly.

I've been giving this a bit more thought and its our intent to try and
remove python2 from OE-Core entirely so adding py2 modules back seems
like a backwards step.

I think this will therefore need to go to one of the other layers,
painful as that might be from an include perspective.

Upstream are only going to keep py2 compatibility to the end of the
year, if that so the recipes will have to fork sooner or later anyway.

Cheers,

Richard

Re: [PATCH 2/2] python-six: put python2/3 variant together

[Andreas Müller]

On Tue, May 21, 2019 at 8:38 PM <richard.purdie@linuxfoundation.org> wrote:
> > No sorry mozjs uses old crap in their configurations scripts nobody
> > else does (python which) and ask for python2 explicitly.
>
> I've been giving this a bit more thought and its our intent to try and
> remove python2 from OE-Core entirely so adding py2 modules back seems
> like a backwards step.
>
> I think this will therefore need to go to one of the other layers,
> painful as that might be from an include perspective.
Yeah a new burden out of thin air is born. You know what I do: Create
my own layers and am happy as I am with my other layers.

Bye

Andreas
>
> Upstream are only going to keep py2 compatibility to the end of the
> year, if that so the recipes will have to fork sooner or later anyway.
>
> Cheers,
>
> Richard
>
>
>

Re: [PATCH 2/2] python-six: put python2/3 variant together

[richard.purdie]

On Tue, 2019-05-21 at 22:59 +0200, Andreas Müller wrote:
> On Tue, May 21, 2019 at 8:38 PM <richard.purdie@linuxfoundation.org>
> wrote:
> > > No sorry mozjs uses old crap in their configurations scripts
> > > nobody
> > > else does (python which) and ask for python2 explicitly.
> > 
> > I've been giving this a bit more thought and its our intent to try
> > and
> > remove python2 from OE-Core entirely so adding py2 modules back
> > seems
> > like a backwards step.
> > 
> > I think this will therefore need to go to one of the other layers,
> > painful as that might be from an include perspective.
> Yeah a new burden out of thin air is born. You know what I do: Create
> my own layers and am happy as I am with my other layers.
> 
> Bye

Its not "out of thin air". It was discussed over two years ago when we
started a plan of trying to remove python2 dependencies:

http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=1fc2c9315faf65ea05fecf81450dd40b9a330435

This was in line with what upstream python recommended. Upstream python
has made a clear statement on this too:

https://python3statement.org/

For a release that will ship 3 months before that deadline, it seems
unreasonable to add this back to oe-core, no?

Cheers,

Richard

Re: [PATCH 2/2] python-six: put python2/3 variant together

[Khem Raj]

On Tue, May 21, 2019 at 2:44 PM <richard.purdie@linuxfoundation.org> wrote:
>
> On Tue, 2019-05-21 at 22:59 +0200, Andreas Müller wrote:
> > On Tue, May 21, 2019 at 8:38 PM <richard.purdie@linuxfoundation.org>
> > wrote:
> > > > No sorry mozjs uses old crap in their configurations scripts
> > > > nobody
> > > > else does (python which) and ask for python2 explicitly.
> > >
> > > I've been giving this a bit more thought and its our intent to try
> > > and
> > > remove python2 from OE-Core entirely so adding py2 modules back
> > > seems
> > > like a backwards step.
> > >
> > > I think this will therefore need to go to one of the other layers,
> > > painful as that might be from an include perspective.
> > Yeah a new burden out of thin air is born. You know what I do: Create
> > my own layers and am happy as I am with my other layers.
> >
> > Bye
>
> Its not "out of thin air". It was discussed over two years ago when we
> started a plan of trying to remove python2 dependencies:
>
> http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=1fc2c9315faf65ea05fecf81450dd40b9a330435
>
> This was in line with what upstream python recommended. Upstream python
> has made a clear statement on this too:
>
> https://python3statement.org/
>
> For a release that will ship 3 months before that deadline, it seems
> unreasonable to add this back to oe-core, no?
>

the EOL is expected to be Jan 2020, lets see what happens but I think
it would be good for us
to first switch default python to be python3 and then remove python2
completely IMO, I do not
see any major distro planning to drop py2 at the stroke of it going
EOL as of now, situation might
change in coming months but many of them haven't even switched defaults.

Its good that project is taking lead here but we might leave many users behind.

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

Re: [PATCH 2/2] python-six: put python2/3 variant together

[richard.purdie]

On Tue, 2019-05-21 at 18:49 -0700, Khem Raj wrote:
> On Tue, May 21, 2019 at 2:44 PM <richard.purdie@linuxfoundation.org>
> wrote:
> > On Tue, 2019-05-21 at 22:59 +0200, Andreas Müller wrote:
> > > On Tue, May 21, 2019 at 8:38 PM <
> > > richard.purdie@linuxfoundation.org>
> > > wrote:
> > > > > No sorry mozjs uses old crap in their configurations scripts
> > > > > nobody
> > > > > else does (python which) and ask for python2 explicitly.
> > > > 
> > > > I've been giving this a bit more thought and its our intent to
> > > > try
> > > > and
> > > > remove python2 from OE-Core entirely so adding py2 modules back
> > > > seems
> > > > like a backwards step.
> > > > 
> > > > I think this will therefore need to go to one of the other
> > > > layers,
> > > > painful as that might be from an include perspective.
> > > Yeah a new burden out of thin air is born. You know what I do:
> > > Create
> > > my own layers and am happy as I am with my other layers.
> > > 
> > > Bye
> > 
> > Its not "out of thin air". It was discussed over two years ago when
> > we
> > started a plan of trying to remove python2 dependencies:
> > 
> > http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=1fc2c9315faf65ea05fecf81450dd40b9a330435
> > 
> > This was in line with what upstream python recommended. Upstream
> > python
> > has made a clear statement on this too:
> > 
> > https://python3statement.org/
> > 
> > For a release that will ship 3 months before that deadline, it
> > seems
> > unreasonable to add this back to oe-core, no?
> > 
> 
> the EOL is expected to be Jan 2020, lets see what happens but I think
> it would be good for us
> to first switch default python to be python3 and then remove python2
> completely IMO, I do not
> see any major distro planning to drop py2 at the stroke of it going
> EOL as of now, situation might
> change in coming months but many of them haven't even switched
> defaults.

I don't think we need to switch our default, just be able to build say
oe-core without python/python2 in HOSTTOOLS and without needing python
2.7 in OE-Core either. 

> Its good that project is taking lead here but we might leave many
> users behind.

I suspect python2 will end up in a layer of its down which I'm fine
with, dependencies can then be clearly seen.

Cheers,

Richard

Re: [PATCH 2/2] python-six: put python2/3 variant together

[Alexander Kanavin]

On Wed, 22 May 2019 at 13:05, <richard.purdie@linuxfoundation.org> wrote:

> I don't think we need to switch our default, just be able to build say
> oe-core without python/python2 in HOSTTOOLS and without needing python
> 2.7 in OE-Core either.
>
> > Its good that project is taking lead here but we might leave many
> > users behind.
>
> I suspect python2 will end up in a layer of its down which I'm fine
> with, dependencies can then be clearly seen.

For what it's worth, Fedora is getting serious about Python 2 removal,
and they have a plan for it:
https://fedoraproject.org/wiki/Changes/RetirePython2

"All packages in Fedora that need Python 2 to run will be removed from
Fedora 32 regardless of their dependencies. All packages in Fedora
that need Python 2 to build will be removed from Fedora 32 regardless
of their dependencies. "

Alex

Re: [PATCH 2/2] python-six: put python2/3 variant together

[Tim Orling]

[-- Attachment #1: Type: text/plain, Size: 1841 bytes --]

On Wed, May 22, 2019 at 4:27 AM Alexander Kanavin <alex.kanavin@gmail.com>
wrote:

> On Wed, 22 May 2019 at 13:05, <richard.purdie@linuxfoundation.org> wrote:
>
> > I don't think we need to switch our default, just be able to build say
> > oe-core without python/python2 in HOSTTOOLS and without needing python
> > 2.7 in OE-Core either.
> >
> > > Its good that project is taking lead here but we might leave many
> > > users behind.
> >
> > I suspect python2 will end up in a layer of its down which I'm fine
> > with, dependencies can then be clearly seen.
>
> For what it's worth, Fedora is getting serious about Python 2 removal,
> and they have a plan for it:
> https://fedoraproject.org/wiki/Changes/RetirePython2
>
> "All packages in Fedora that need Python 2 to run will be removed from
> Fedora 32 regardless of their dependencies. All packages in Fedora
> that need Python 2 to build will be removed from Fedora 32 regardless
> of their dependencies. "
>


We have discussed moving meta-python to its own repository (not under
meta-openembedded). As part of that move, I am proposing the existing
python2 recipes move to a separate (deprecated) layer, as RP mentioned
earlier. Then meta-python will become python3 only. We will also move
recipetool/devtool to provide python3 (only) support. People that need
python2 will very soon have to live with older stable branches. This should
not be a surprise.

We also need to do whatever we can with upstream projects that are not
feeling an urgency to move to python3. They should likewise not be
surprised at the need to switch.


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

[-- Attachment #2: Type: text/html, Size: 2828 bytes --]

Re: [PATCH 2/2] python-six: put python2/3 variant together

[Alejandro Hernandez]

[-- Attachment #1: Type: text/plain, Size: 2247 bytes --]


On 5/22/2019 7:01 AM, Tim Orling wrote:
>
>
> On Wed, May 22, 2019 at 4:27 AM Alexander Kanavin 
> <alex.kanavin@gmail.com <mailto:alex.kanavin@gmail.com>> wrote:
>
>     On Wed, 22 May 2019 at 13:05, <richard.purdie@linuxfoundation.org
>     <mailto:richard.purdie@linuxfoundation.org>> wrote:
>
>     > I don't think we need to switch our default, just be able to
>     build say
>     > oe-core without python/python2 in HOSTTOOLS and without needing
>     python
>     > 2.7 in OE-Core either.
>     >
>     > > Its good that project is taking lead here but we might leave many
>     > > users behind.
>     >
>     > I suspect python2 will end up in a layer of its down which I'm fine
>     > with, dependencies can then be clearly seen.
>
>     For what it's worth, Fedora is getting serious about Python 2 removal,
>     and they have a plan for it:
>     https://fedoraproject.org/wiki/Changes/RetirePython2
>
>     "All packages in Fedora that need Python 2 to run will be removed from
>     Fedora 32 regardless of their dependencies. All packages in Fedora
>     that need Python 2 to build will be removed from Fedora 32 regardless
>     of their dependencies. "
>
>
>
> We have discussed moving meta-python to its own repository (not under 
> meta-openembedded). As part of that move, I am proposing the existing 
> python2 recipes move to a separate (deprecated) layer, as RP mentioned 
> earlier. Then meta-python will become python3 only. We will also move 
> recipetool/devtool to provide python3 (only) support. People that need 
> python2 will very soon have to live with older stable branches. This 
> should not be a surprise.
>
> We also need to do whatever we can with upstream projects that are not 
> feeling an urgency to move to python3. They should likewise not be 
> surprised at the need to switch.


I would agree with this as well.


Cheers,

Alejandro


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

[-- Attachment #2: Type: text/html, Size: 4829 bytes --]

Re: [PATCH 2/2] python-six: put python2/3 variant together

[Philip Balister]

On 05/21/2019 12:41 PM, Richard Purdie wrote:
> On Tue, 2019-05-21 at 11:00 +0200, Andreas Müller wrote:
>> Upcoming 60.2.3 mozjs (meta-oe) requires python(2)-six-native for its
>> configuration. Currently python(2)-six lives in meta-python and it
>> could be
>> moved to mozjs's home meta-oe but that would be just further clutter.
>>
>> Once applied here patch to meta-python will be send.
>>
>> Signed-off-by: Andreas Müller <schnitzeltony@gmail.com>
>> ---
>>  meta/recipes-devtools/python/python-six_1.12.0.bb | 2 ++
>>  1 file changed, 2 insertions(+)
>>  create mode 100644 meta/recipes-devtools/python/python-six_1.12.0.bb
>>
>> diff --git a/meta/recipes-devtools/python/python-six_1.12.0.bb
>> b/meta/recipes-devtools/python/python-six_1.12.0.bb
>> new file mode 100644
>> index 0000000000..9075745d74
>> --- /dev/null
>> +++ b/meta/recipes-devtools/python/python-six_1.12.0.bb
>> @@ -0,0 +1,2 @@
>> +inherit pypi setuptools
>> +require python-six.inc
> 
> Can it not use python3? Python2 is rapidly running out of time at this
> point and I'd not expect new dependencies on python2 to be appearing...

Also, I suspect plenty of other things use python-six and expect to get
it from meta-python, not meta-oe.

We need to be driving everything we can to python3.

Philip

> 
> Cheers,
> 
> Richard
>