[PATCHv9,1/4] graphene: import from meta-oe

Signed-off-by: Markus Volk <f_l_k@t-online.de>
---
 .../graphene/graphene_1.10.8.bb               | 22 +++++++++++++++++++
 1 file changed, 22 insertions(+)
 create mode 100644 meta/recipes-graphics/graphene/graphene_1.10.8.bb

I’m a big GNOME fan[1] but I wonder if moving pieces of the GTK4/GNOME4 stack into oe-core because we want to upgrade epiphany is the right thing to do.

It’s not the full GNOME stack as we’re just picking the build dependencies for Epiphany, so anyone who wants to use the GNOME stack will need meta-gnome. It’s not really a proper test of GTK4 because epiphany isn’t in any images, so will only get built in the few world builds on the autobuilder.  Because it is in no images there is no runtime QA for it, we could carry a GTK4 in oe-core that crashes on startup for a long time before anyone noticed.

WebKit supports both GTK3 and GTK4[2], so it’s easy enough for oe-core to either have one recipe with  PACKAGECONFIGs, or a well written flexible recipe that has a GTK3 variation in core and a GTK4 variation in meta-gnome.  I believe webkitgtk also ships a dumb-browser application that would be enough to verify that webkitgtk actually works, because in production use the choice of browser will be based on more than just what is in core: maybe a custom shell using webkit, maybe chromium, maybe something else entirely.

I’d even go as far as saying that maybe the meta-gnome maintainers should talk to the autobuilder maintainers and get meta-gnome added to the autobuilder test matrix.  GNOME has strong support for installed tests so we can execute the ptests on the autobuilder, and have some basic runtime tests to verify that GNOME starts.

Ross

[1] ex-gnome-games maintainer, wrote and maintained sound-juicer, attended several GUADECs, was active in the GNOME Mobile working group. Yes, this is historic, but working on GNOME 3 is what took me from proprietary software to working on open source full-time.

[2] https://github.com/WebKit/WebKit/blob/ab46c3ebb92d1134614f4f98918927d338062d74/Source/cmake/OptionsGTK.cmake#L184

How much longer before webkit, too, drops gtk3 support, or gtk3 itself
starts to bitrot in significant ways? If we want webkit in core, then
we better figure out how to build (and test) it with gtk4, and rather
now, than later.

I also don't like the idea that core should be using less-than-latest
options when latest options are 'complicated'.

Alex

On Thu, 1 Dec 2022 at 13:34, Ross Burton <ross.burton@arm.com> wrote:
>
> I’m a big GNOME fan[1] but I wonder if moving pieces of the GTK4/GNOME4 stack into oe-core because we want to upgrade epiphany is the right thing to do.
>
> It’s not the full GNOME stack as we’re just picking the build dependencies for Epiphany, so anyone who wants to use the GNOME stack will need meta-gnome. It’s not really a proper test of GTK4 because epiphany isn’t in any images, so will only get built in the few world builds on the autobuilder.  Because it is in no images there is no runtime QA for it, we could carry a GTK4 in oe-core that crashes on startup for a long time before anyone noticed.
>
> WebKit supports both GTK3 and GTK4[2], so it’s easy enough for oe-core to either have one recipe with  PACKAGECONFIGs, or a well written flexible recipe that has a GTK3 variation in core and a GTK4 variation in meta-gnome.  I believe webkitgtk also ships a dumb-browser application that would be enough to verify that webkitgtk actually works, because in production use the choice of browser will be based on more than just what is in core: maybe a custom shell using webkit, maybe chromium, maybe something else entirely.
>
> I’d even go as far as saying that maybe the meta-gnome maintainers should talk to the autobuilder maintainers and get meta-gnome added to the autobuilder test matrix.  GNOME has strong support for installed tests so we can execute the ptests on the autobuilder, and have some basic runtime tests to verify that GNOME starts.
>
> Ross
>
> [1] ex-gnome-games maintainer, wrote and maintained sound-juicer, attended several GUADECs, was active in the GNOME Mobile working group. Yes, this is historic, but working on GNOME 3 is what took me from proprietary software to working on open source full-time.
>
> [2] https://github.com/WebKit/WebKit/blob/ab46c3ebb92d1134614f4f98918927d338062d74/Source/cmake/OptionsGTK.cmake#L184
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#174054): https://lists.openembedded.org/g/openembedded-core/message/174054
> Mute This Topic: https://lists.openembedded.org/mt/95377611/1686489
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [alex.kanavin@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>

On 1 Dec 2022, at 12:45, Alexander Kanavin <alex.kanavin@gmail.com> wrote:
> 
> How much longer before webkit, too, drops gtk3 support, or gtk3 itself
> starts to bitrot in significant ways? If we want webkit in core, then
> we better figure out how to build (and test) it with gtk4, and rather
> now, than later.

I might be putting a different emphasis to you on that “if we want webkit in core”.

If webkit ditches gtk3 support *and* oe-core is still shipping a gtk3 based UI then I’ll repeat my suggestion that the autobuilder should exercise a GTK4 stack properly, and ephy/webkitgtk4 can live in meta-gnome.  Ephy is a GNOME project, meta-gnome is where it belongs.

> I also don't like the idea that core should be using less-than-latest
> options when latest options are ‘complicated’.

Adding recipes isn’t complicated, that’s not the problem.

Ross

On Thu, 1 Dec 2022 at 13:51, Ross Burton <Ross.Burton@arm.com> wrote:
> I might be putting a different emphasis to you on that “if we want webkit in core”.
>
> If webkit ditches gtk3 support *and* oe-core is still shipping a gtk3 based UI then I’ll repeat my suggestion that the autobuilder should exercise a GTK4 stack properly, and ephy/webkitgtk4 can live in meta-gnome.  Ephy is a GNOME project, meta-gnome is where it belongs.

Yes, I'd rather keep webkit/ephy in core. For one thing, we can add it
to core-image-weston, and instantly have a useful graphical UI that
way that also exercises a lot of things across the stack -
terminal+browser.

Alex

On Thu, 2022-12-01 at 12:34 +0000, Ross Burton wrote:
> I’m a big GNOME fan[1] but I wonder if moving pieces of the
> GTK4/GNOME4 stack into oe-core because we want to upgrade epiphany is
> the right thing to do.
> 
> It’s not the full GNOME stack as we’re just picking the build
> dependencies for Epiphany, so anyone who wants to use the GNOME stack
> will need meta-gnome. It’s not really a proper test of GTK4 because
> epiphany isn’t in any images, so will only get built in the few world
> builds on the autobuilder.  Because it is in no images there is no
> runtime QA for it, we could carry a GTK4 in oe-core that crashes on
> startup for a long time before anyone noticed.

There are a variety of pressures which say "lets move X or Y out of
core". It would be less work for me and for anyone else working on OE-
Core so there are advantages.

The downside to doing that is that we lose "real world" testing of
larger components and integration of them. webkit is a pain but in some
ways having large painful C++ code in core helps stress test that. By
real world I don't just mean someone using the end browser but even
just building it, enduring we don't have leakage of build paths into
C++ libraries, ensuring such things remain reproducible and so on. I've
said before that we do need a graphics stack somewhere in our tests
since in general graphics is important.

I think it partly depends on where we go with OE-Core. If sato stays on
gtk3+, we have a problem since that is a bit of a dead end. There is
still value there since it pulls together so many pieces of software
but as you say, gtk4 mixed with gtk3 like that isn't great.

If over time we see some pieces of sato using gtk4, that changes the
equation, this move could be a start of changes which put us in a
better position in the future.

Should we get rid of sato? I'm reluctant as we don't have a good
replacement plan. Ideas have been proposed but nobody is willing to
step up, propose and maintain something. We have a number of areas
where we could spend time and there are probably higher priority
issues. How much work is gtk4 in sato? No idea to be honest.

I do think OE-Core needs to have enough variety and represent enough of
the software ecosystem that it is useful in it's own right and is able
to test a good cross section of the software world people work with.

> WebKit supports both GTK3 and GTK4[2], so it’s easy enough for oe-
> core to either have one recipe with  PACKAGECONFIGs, or a well
> written flexible recipe that has a GTK3 variation in core and a GTK4
> variation in meta-gnome.  I believe webkitgtk also ships a dumb-
> browser application that would be enough to verify that webkitgtk
> actually works, because in production use the choice of browser will
> be based on more than just what is in core: maybe a custom shell
> using webkit, maybe chromium, maybe something else entirely.
> 
> I’d even go as far as saying that maybe the meta-gnome maintainers
> should talk to the autobuilder maintainers and get meta-gnome added
> to the autobuilder test matrix.  GNOME has strong support for
> installed tests so we can execute the ptests on the autobuilder, and
> have some basic runtime tests to verify that GNOME starts.

I would like to see more testing other layers on the autobuilder. There
are some potential points of contention:

a) OE-Core's test matrix often isn't what some other layer maintainer
wish to maintain (e.g. ppc or mips?).

b) the layers can influence the tests, for example would we need
reproducible builds tests with and without the layer?

c) What level of response can we expect to failures or issues?

d) Would those layers want to match the "quality" metrics we've been
aiming for in core (e.g. all recipes have MAINTAINER/HOMEPAGE etc.)?

We've had quite a bit of success putting a high quality bar on core and
we're trying to lead by example to other areas of the ecosystem but I
can see this creating tensions depending on how we set things up with
the autobuilder.

Cheers,

Richard

On Thu, 1 Dec 2022 at 14:15, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> Should we get rid of sato? I'm reluctant as we don't have a good
> replacement plan. Ideas have been proposed but nobody is willing to
> step up, propose and maintain something. We have a number of areas
> where we could spend time and there are probably higher priority
> issues. How much work is gtk4 in sato? No idea to be honest.

Here's mine. It may not be good, but I believe it's still ok. And good
may simply never show up, while gtk3/sato/x11 continue their slow but
steady slide into obsolescence.

- core-image-weston[-*] replaces core-image-sato[-*] as the
'workhorse' of the test matrix. The patchset for that is ready, with
additional provisions to ensure sato/x11 continues to get testing.
- epiphany is added to core-image-weston, and visible in its app launcher.
- as many tests for the browser and web engine are run at runtime as possible

Alex