Re: [oe] [meta-browser][PATCH] conf/layer.conf: Add meta-python2 to LAYERDEPENDS

[Khem Raj]

Can you post this series via a github pull request please ?

On Thu, Sep 24, 2020 at 7:49 AM Stacy Gaikovaia  wrote:
>
> From: Robert Yang 
>
> The recipes-browser/chromium/chromium.inc requires pythonnative which is in 
> meta-python2.
>
> Signed-off-by: Robert Yang 
> Signed-off-by: Stacy Gaikovaia 
> ---
>  conf/layer.conf | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/conf/layer.conf b/conf/layer.conf
> index 2572211..5fb9beb 100644
> --- a/conf/layer.conf
> +++ b/conf/layer.conf
> @@ -112,4 +112,4 @@ BBFILE_PRIORITY_browser-layer = "7"
>  LAYERVERSION_browser-layer = "1"
>  LAYERSERIES_COMPAT_browser-layer = "warrior zeus dunfell gatesgarth"
>
> -LAYERDEPENDS_browser-layer = "clang-layer core openembedded-layer"
> +LAYERDEPENDS_browser-layer = "clang-layer core openembedded-layer 
> meta-python2"
> --
> 2.27.0
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#87248): 
https://lists.openembedded.org/g/openembedded-devel/message/87248
Mute This Topic: https://lists.openembedded.org/mt/77061530/21656
Group Owner: openembedded-devel+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [oe] [meta-browser] [PATCH] chromium: change to python3

[Martin Jansa]

https://bugs.chromium.org/p/chromium/issues/detail?id=942720

is still far from finished.

Using python from host and assuming it's python2 is much worse than
pythonnative inherit and using meta-python2.

On Wed, Sep 23, 2020 at 8:11 PM Ming Liu  wrote:

> From: Ming Liu 
>
> python support has been dropped from OE since dunfell, let's change to
> python3.
>
> Signed-off-by: Ming Liu 
> ---
>  recipes-browser/chromium/chromium.inc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/recipes-browser/chromium/chromium.inc
> b/recipes-browser/chromium/chromium.inc
> index b351114..0d1a761 100644
> --- a/recipes-browser/chromium/chromium.inc
> +++ b/recipes-browser/chromium/chromium.inc
> @@ -18,7 +18,7 @@ TOOLCHAIN = "clang"
>  # to build the native recipes (e.g. GN) with clang too.
>  TOOLCHAIN_class-native = "clang"
>
> -inherit pythonnative setuptools
> +inherit python3native setuptools3
>
>  # Chromium itself is licensed under the 3-clause BSD license. However, it
>  # depends upon several other projects whose copyright files are listed in
> --
> 2.28.0
>
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#87220): 
https://lists.openembedded.org/g/openembedded-devel/message/87220
Mute This Topic: https://lists.openembedded.org/mt/77041135/21656
Group Owner: openembedded-devel+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [oe] [meta-browser][PATCH] chromium-ozone-wayland: add build dependency to at-spi2-atk

[Mikko Rapeli]

Hi,

On Fri, Jun 26, 2020 at 10:36:09AM +0300, Maksim Sisov wrote:
> Hi!
> 
> Thank you for your contribution! But would you please make a pull
> request to the meta-browser github repo that is the source of the
> meta-browser recipe? Thanks!
> 
> https://github.com/OSSystems/meta-browser

Ok, I can do this too. README in meta-browser says that contributions
through mailing list also work. Maybe you want to update that.

Cheers,

-Mikko

> On 26.06.2020 10:19, Mikko Rapeli wrote:
> > Fixes configure error with poky master branch:
> > 
> > ERROR at //build/config/linux/pkg_config.gni:103:17: Script returned
> > non-zero exit code.
> > pkgresult = exec_script(pkg_config_script, args, "value")
> > ^--
> > Current dir:
> > /home/builder/src/yocto/poky/build/tmp/work/cortexa57-poky-linux/chromium-ozone-wayland/83.0.4103.116-r0/chromium-83.0.4103.116/out/Release/
> > Command: python
> > /home/builder/src/yocto/poky/build/tmp/work/cortexa57-poky-linux/chromium-ozone-wayland/83.0.4103.116-r0/chromium-83.0.4103.116/build/config/linux/pkg-config.py
> > atk atk-bridge-2.0
> > Returned 1.
> > stderr:
> > 
> > Package atk-bridge-2.0 was not found in the pkg-config search path.
> > Perhaps you should add the directory containing `atk-bridge-2.0.pc'
> > to the PKG_CONFIG_PATH environment variable
> > No package 'atk-bridge-2.0' found
> > Could not run pkg-config.
> > 
> > See //build/config/linux/atk/BUILD.gn:19:1: whence it was called.
> > pkg_config("atk_base") {
> > ^---
> > See //ui/views/BUILD.gn:821:22: which caused the file to be included.
> > configs += [ "//build/config/linux/atk" ]
> >  ^-
> > WARNING: exit code 1 from a shell command.
> > ERROR: Execution of
> > '/home/builder/src/yocto/poky/build/tmp/work/cortexa57-poky-linux/chromium-ozone-wayland/83.0.4103.116-r0/temp/run.do_configure.35368'
> > failed with exit code 1:
> > ERROR at //build/config/linux/pkg_config.gni:103:17: Script returned
> > non-zero exit code.
> > pkgresult = exec_script(pkg_config_script, args, "value")
> > ^--
> > 
> > Signed-off-by: Mikko Rapeli 
> > ---
> >  recipes-browser/chromium/chromium-ozone-wayland_83.0.4103.116.bb | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git
> > a/recipes-browser/chromium/chromium-ozone-wayland_83.0.4103.116.bb
> > b/recipes-browser/chromium/chromium-ozone-wayland_83.0.4103.116.bb
> > index de9274d..58fa0fb 100644
> > --- a/recipes-browser/chromium/chromium-ozone-wayland_83.0.4103.116.bb
> > +++ b/recipes-browser/chromium/chromium-ozone-wayland_83.0.4103.116.bb
> > @@ -3,6 +3,7 @@ require chromium-gn.inc
> >  REQUIRED_DISTRO_FEATURES = "wayland"
> >  
> >  DEPENDS += "\
> > +at-spi2-atk \
> >  libxkbcommon \
> >  virtual/egl \
> >  wayland \
> 
> -- 
> Best Regards,
> Maksim Sisov-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#85366): 
https://lists.openembedded.org/g/openembedded-devel/message/85366
Mute This Topic: https://lists.openembedded.org/mt/75119976/21656
Group Owner: openembedded-devel+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [oe] [meta-browser][PATCH] chromium.inc: Use setuptools3 instead of setuptools bbclass

[Chandana kalluri]

> -Original Message-
> From: Khem Raj 
> Sent: Monday, June 22, 2020 4:55 PM
> To: Chandana Kalluri ; openembedded-
> de...@lists.openembedded.org
> Cc: Chandana Kalluri 
> Subject: Re: [oe] [meta-browser][PATCH] chromium.inc: Use setuptools3
> instead of setuptools bbclass
> 
> 
> 
> On 6/22/20 3:11 PM, Chandana kalluri wrote:
> >  From dunfell onwards, python2 recipes and classes are not supported.
> > Inherit setuptools3.bbclass for chromium instead of setuptools.bbclass
> >
> > Signed-off-by: Sai Hari Chandana Kalluri 
> > ---
> >   recipes-browser/chromium/chromium.inc | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/recipes-browser/chromium/chromium.inc
> > b/recipes-browser/chromium/chromium.inc
> > index a483ec4..49947be 100644
> > --- a/recipes-browser/chromium/chromium.inc
> > +++ b/recipes-browser/chromium/chromium.inc
> > @@ -18,7 +18,7 @@ TOOLCHAIN = "clang"
> >   # to build the native recipes (e.g. GN) with clang too.
> >   TOOLCHAIN_class-native = "clang"
> >
> > -inherit python3native setuptools
> > +inherit python3native setuptools3
> 
> it still needs python2, better patch is to add meta-python2 to meta-browser
> layer dependencies
> 
> e.g in conf/layer.conf
> LAYERDEPENDS_browser-layer = "clang-layer core openembedded-layer"
> 
> 
Will try this out. 

Thanks,
Chandana
> >
> >   # Chromium itself is licensed under the 3-clause BSD license. However, it
> >   # depends upon several other projects whose copyright files are
> > listed in
> >
> >
> > 
> >
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#85281): 
https://lists.openembedded.org/g/openembedded-devel/message/85281
Mute This Topic: https://lists.openembedded.org/mt/75049315/21656
Group Owner: openembedded-devel+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [oe] [meta-browser][PATCH] chromium.inc: Use python3native.bbclass instead of pythonnative.bbclass

[Chandana kalluri]

> -Original Message-
> From: Denys Dmytriyenko 
> Sent: Monday, June 22, 2020 4:18 PM
> To: Chandana Kalluri 
> Cc: Alejandro Hernandez Samaniego ; Alexander
> Kanavin ; OpenEmbedded Devel List
> 
> Subject: Re: [oe] [meta-browser][PATCH] chromium.inc: Use
> python3native.bbclass instead of pythonnative.bbclass
> 
> On Mon, Jun 22, 2020 at 10:53:09PM +, Chandana kalluri wrote:
> > I am building the meta-browser layer against poky/master and currently
> > I am seeing parse errors as pythonnative and setuptools classes are no
> > longer supported. Hence the patch.
> 
> So, have you had any successful builds of chromium after your patches?
> 
I'm afraid I haven't gotten that far in building chromium recipes.
 I just started to upgrade our layers for dunfell and gatesgarth where I have 
been running into parse errors for this recipe due to invalid pythonnative 
class inheritance. 

> 
> > How are everyone else building python2 chromium against poky/master
> > which doesn’t have support for python2 recipes/classes anymore?
> 
> You need meta-python2 layer to enable Python2 support.
> 
I will try this out.
 
Thanks,
Chandana
> 
> > Thanks,
> > Chandana
> >
> >
> > From: Alejandro Hernandez Samaniego 
> > Sent: Monday, June 22, 2020 3:42 PM
> > To: Denys Dmytriyenko ; Alexander Kanavin
> > 
> > Cc: Chandana Kalluri ; OpenEmbedded Devel List
> > ; Chandana Kalluri
> > 
> > Subject: Re: [oe] [meta-browser][PATCH] chromium.inc: Use
> > python3native.bbclass instead of pythonnative.bbclass
> >
> >
> > Some of it is already ported, but it doesn't look like it will be fixed 
> > soon, its
> easier to depend on python-native but that creates a dependency on meta-
> python as well as it uses EOL code.
> >
> > If you do that you have to manually patch lots of stuff on the v8 engine
> (and other components) which try calling /usr/bin/python specifically, but it
> will work.
> >
> > Alejandro
> > On 6/22/20 3:32 PM, Denys Dmytriyenko wrote:
> >
> > Yeah, not gonna work - many people are waiting for this to happen, but
> alas:
> >
> >
> >
> > https://bugs.chromium.org/p/chromium/issues/detail?id=942720
> >
> >
> >
> >
> >
> > On Tue, Jun 23, 2020 at 12:16:51AM +0200, Alexander Kanavin wrote:
> >
> > Wait, did you actually test this? Chromium is not yet ready for
> > python3,
> >
> > and builds will fail.
> >
> >
> >
> > Alex
> >
> >
> >
> > On Tue, 23 Jun 2020 at 00:09, Chandana kalluri
> <mailto:ckall...@xilinx.com> wrote:
> >
> >
> >
> > From dunfell onwards, python2 recipes and classes are not supported.
> >
> > Inherit
> >
> > python3native.bbclass for chromium instead of pythonnative.bbclass
> >
> >
> >
> > Signed-off-by: Sai Hari Chandana Kalluri
> > <mailto:chandana.kall...@xilinx.com>
> >
> > ---
> >
> >  recipes-browser/chromium/chromium.inc | 2 +-
> >
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> >
> >
> > diff --git a/recipes-browser/chromium/chromium.inc
> >
> > b/recipes-browser/chromium/chromium.inc
> >
> > index 14d762f..a483ec4 100644
> >
> > --- a/recipes-browser/chromium/chromium.inc
> >
> > +++ b/recipes-browser/chromium/chromium.inc
> >
> > @@ -18,7 +18,7 @@ TOOLCHAIN = "clang"
> >
> >  # to build the native recipes (e.g. GN) with clang too.
> >
> >  TOOLCHAIN_class-native = "clang"
> >
> >
> >
> > -inherit pythonnative setuptools
> >
> > +inherit python3native setuptools
> >
> >
> >
> >  # Chromium itself is licensed under the 3-clause BSD license.
> > However, it
> >
> >  # depends upon several other projects whose copyright files are
> > listed in
> >
> > --
> >
> > 2.7.4
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> 
> > 

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#85280): 
https://lists.openembedded.org/g/openembedded-devel/message/85280
Mute This Topic: https://lists.openembedded.org/mt/75049276/21656
Group Owner: openembedded-devel+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [oe] [meta-browser][PATCH] chromium.inc: Use setuptools3 instead of setuptools bbclass

[Khem Raj]

On 6/22/20 3:11 PM, Chandana kalluri wrote:

 From dunfell onwards, python2 recipes and classes are not supported. Inherit
setuptools3.bbclass for chromium instead of setuptools.bbclass

Signed-off-by: Sai Hari Chandana Kalluri 
---
  recipes-browser/chromium/chromium.inc | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-browser/chromium/chromium.inc 
b/recipes-browser/chromium/chromium.inc
index a483ec4..49947be 100644
--- a/recipes-browser/chromium/chromium.inc
+++ b/recipes-browser/chromium/chromium.inc
@@ -18,7 +18,7 @@ TOOLCHAIN = "clang"
  # to build the native recipes (e.g. GN) with clang too.
  TOOLCHAIN_class-native = "clang"
  
-inherit python3native setuptools

+inherit python3native setuptools3


it still needs python2, better patch is to add meta-python2 to 
meta-browser layer dependencies


e.g in conf/layer.conf
LAYERDEPENDS_browser-layer = "clang-layer core openembedded-layer"


  
  # Chromium itself is licensed under the 3-clause BSD license. However, it

  # depends upon several other projects whose copyright files are listed in




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#85279): 
https://lists.openembedded.org/g/openembedded-devel/message/85279
Mute This Topic: https://lists.openembedded.org/mt/75049315/21656
Group Owner: openembedded-devel+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [oe] [meta-browser][PATCH] chromium.inc: Use python3native.bbclass instead of pythonnative.bbclass

[Denys Dmytriyenko]

On Mon, Jun 22, 2020 at 10:53:09PM +, Chandana kalluri wrote:
> I am building the meta-browser layer against poky/master and currently I am 
> seeing parse errors as pythonnative and setuptools classes are no longer 
> supported. Hence the patch.

So, have you had any successful builds of chromium after your patches?


> How are everyone else building python2 chromium against poky/master which 
> doesn’t have support for python2 recipes/classes anymore?

You need meta-python2 layer to enable Python2 support.


> Thanks,
> Chandana
> 
> 
> From: Alejandro Hernandez Samaniego 
> Sent: Monday, June 22, 2020 3:42 PM
> To: Denys Dmytriyenko ; Alexander Kanavin 
> 
> Cc: Chandana Kalluri ; OpenEmbedded Devel List 
> ; Chandana Kalluri 
> 
> Subject: Re: [oe] [meta-browser][PATCH] chromium.inc: Use 
> python3native.bbclass instead of pythonnative.bbclass
> 
> 
> Some of it is already ported, but it doesn't look like it will be fixed soon, 
> its easier to depend on python-native but that creates a dependency on 
> meta-python as well as it uses EOL code.
> 
> If you do that you have to manually patch lots of stuff on the v8 engine (and 
> other components) which try calling /usr/bin/python specifically, but it will 
> work.
> 
> Alejandro
> On 6/22/20 3:32 PM, Denys Dmytriyenko wrote:
> 
> Yeah, not gonna work - many people are waiting for this to happen, but alas:
> 
> 
> 
> https://bugs.chromium.org/p/chromium/issues/detail?id=942720
> 
> 
> 
> 
> 
> On Tue, Jun 23, 2020 at 12:16:51AM +0200, Alexander Kanavin wrote:
> 
> Wait, did you actually test this? Chromium is not yet ready for python3,
> 
> and builds will fail.
> 
> 
> 
> Alex
> 
> 
> 
> On Tue, 23 Jun 2020 at 00:09, Chandana kalluri 
> <mailto:ckall...@xilinx.com> wrote:
> 
> 
> 
> From dunfell onwards, python2 recipes and classes are not supported.
> 
> Inherit
> 
> python3native.bbclass for chromium instead of pythonnative.bbclass
> 
> 
> 
> Signed-off-by: Sai Hari Chandana Kalluri 
> <mailto:chandana.kall...@xilinx.com>
> 
> ---
> 
>  recipes-browser/chromium/chromium.inc | 2 +-
> 
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> 
> 
> diff --git a/recipes-browser/chromium/chromium.inc
> 
> b/recipes-browser/chromium/chromium.inc
> 
> index 14d762f..a483ec4 100644
> 
> --- a/recipes-browser/chromium/chromium.inc
> 
> +++ b/recipes-browser/chromium/chromium.inc
> 
> @@ -18,7 +18,7 @@ TOOLCHAIN = "clang"
> 
>  # to build the native recipes (e.g. GN) with clang too.
> 
>  TOOLCHAIN_class-native = "clang"
> 
> 
> 
> -inherit pythonnative setuptools
> 
> +inherit python3native setuptools
> 
> 
> 
>  # Chromium itself is licensed under the 3-clause BSD license. However, it
> 
>  # depends upon several other projects whose copyright files are listed in
> 
> --
> 
> 2.7.4
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 

> 

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#85278): 
https://lists.openembedded.org/g/openembedded-devel/message/85278
Mute This Topic: https://lists.openembedded.org/mt/75049276/21656
Group Owner: openembedded-devel+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [oe] [meta-browser][PATCH] chromium.inc: Use python3native.bbclass instead of pythonnative.bbclass

[Chandana kalluri]

I am building the meta-browser layer against poky/master and currently I am 
seeing parse errors as pythonnative and setuptools classes are no longer 
supported. Hence the patch.
How are everyone else building python2 chromium against poky/master which 
doesn’t have support for python2 recipes/classes anymore?

Thanks,
Chandana


From: Alejandro Hernandez Samaniego 
Sent: Monday, June 22, 2020 3:42 PM
To: Denys Dmytriyenko ; Alexander Kanavin 

Cc: Chandana Kalluri ; OpenEmbedded Devel List 
; Chandana Kalluri 

Subject: Re: [oe] [meta-browser][PATCH] chromium.inc: Use python3native.bbclass 
instead of pythonnative.bbclass


Some of it is already ported, but it doesn't look like it will be fixed soon, 
its easier to depend on python-native but that creates a dependency on 
meta-python as well as it uses EOL code.

If you do that you have to manually patch lots of stuff on the v8 engine (and 
other components) which try calling /usr/bin/python specifically, but it will 
work.

Alejandro
On 6/22/20 3:32 PM, Denys Dmytriyenko wrote:

Yeah, not gonna work - many people are waiting for this to happen, but alas:



https://bugs.chromium.org/p/chromium/issues/detail?id=942720





On Tue, Jun 23, 2020 at 12:16:51AM +0200, Alexander Kanavin wrote:

Wait, did you actually test this? Chromium is not yet ready for python3,

and builds will fail.



Alex



On Tue, 23 Jun 2020 at 00:09, Chandana kalluri 
<mailto:ckall...@xilinx.com> wrote:



From dunfell onwards, python2 recipes and classes are not supported.

Inherit

python3native.bbclass for chromium instead of pythonnative.bbclass



Signed-off-by: Sai Hari Chandana Kalluri 
<mailto:chandana.kall...@xilinx.com>

---

 recipes-browser/chromium/chromium.inc | 2 +-

 1 file changed, 1 insertion(+), 1 deletion(-)



diff --git a/recipes-browser/chromium/chromium.inc

b/recipes-browser/chromium/chromium.inc

index 14d762f..a483ec4 100644

--- a/recipes-browser/chromium/chromium.inc

+++ b/recipes-browser/chromium/chromium.inc

@@ -18,7 +18,7 @@ TOOLCHAIN = "clang"

 # to build the native recipes (e.g. GN) with clang too.

 TOOLCHAIN_class-native = "clang"



-inherit pythonnative setuptools

+inherit python3native setuptools



 # Chromium itself is licensed under the 3-clause BSD license. However, it

 # depends upon several other projects whose copyright files are listed in

--

2.7.4
















-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#85277): 
https://lists.openembedded.org/g/openembedded-devel/message/85277
Mute This Topic: https://lists.openembedded.org/mt/75049276/21656
Group Owner: openembedded-devel+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [oe] [meta-browser][PATCH] chromium.inc: Use python3native.bbclass instead of pythonnative.bbclass

[Alejandro Hernandez]

Some of it is already ported, but it doesn't look like it will be fixed 
soon, its easier to depend on python-native but that creates a 
dependency on meta-python as well as it uses EOL code.


If you do that you have to manually patch lots of stuff on the v8 engine 
(and other components) which try calling /usr/bin/python specifically, 
but it will work.


Alejandro

On 6/22/20 3:32 PM, Denys Dmytriyenko wrote:

Yeah, not gonna work - many people are waiting for this to happen, but alas:

https://bugs.chromium.org/p/chromium/issues/detail?id=942720


On Tue, Jun 23, 2020 at 12:16:51AM +0200, Alexander Kanavin wrote:

Wait, did you actually test this? Chromium is not yet ready for python3,
and builds will fail.

Alex

On Tue, 23 Jun 2020 at 00:09, Chandana kalluri  wrote:


 From dunfell onwards, python2 recipes and classes are not supported.
Inherit
python3native.bbclass for chromium instead of pythonnative.bbclass

Signed-off-by: Sai Hari Chandana Kalluri 
---
  recipes-browser/chromium/chromium.inc | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-browser/chromium/chromium.inc
b/recipes-browser/chromium/chromium.inc
index 14d762f..a483ec4 100644
--- a/recipes-browser/chromium/chromium.inc
+++ b/recipes-browser/chromium/chromium.inc
@@ -18,7 +18,7 @@ TOOLCHAIN = "clang"
  # to build the native recipes (e.g. GN) with clang too.
  TOOLCHAIN_class-native = "clang"

-inherit pythonnative setuptools
+inherit python3native setuptools

  # Chromium itself is licensed under the 3-clause BSD license. However, it
  # depends upon several other projects whose copyright files are listed in
--
2.7.4






-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#85276): 
https://lists.openembedded.org/g/openembedded-devel/message/85276
Mute This Topic: https://lists.openembedded.org/mt/75049276/21656
Group Owner: openembedded-devel+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [oe] [meta-browser][PATCH] chromium.inc: Use python3native.bbclass instead of pythonnative.bbclass

[Denys Dmytriyenko]

Yeah, not gonna work - many people are waiting for this to happen, but alas:

https://bugs.chromium.org/p/chromium/issues/detail?id=942720


On Tue, Jun 23, 2020 at 12:16:51AM +0200, Alexander Kanavin wrote:
> Wait, did you actually test this? Chromium is not yet ready for python3,
> and builds will fail.
> 
> Alex
> 
> On Tue, 23 Jun 2020 at 00:09, Chandana kalluri  wrote:
> 
> > From dunfell onwards, python2 recipes and classes are not supported.
> > Inherit
> > python3native.bbclass for chromium instead of pythonnative.bbclass
> >
> > Signed-off-by: Sai Hari Chandana Kalluri 
> > ---
> >  recipes-browser/chromium/chromium.inc | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/recipes-browser/chromium/chromium.inc
> > b/recipes-browser/chromium/chromium.inc
> > index 14d762f..a483ec4 100644
> > --- a/recipes-browser/chromium/chromium.inc
> > +++ b/recipes-browser/chromium/chromium.inc
> > @@ -18,7 +18,7 @@ TOOLCHAIN = "clang"
> >  # to build the native recipes (e.g. GN) with clang too.
> >  TOOLCHAIN_class-native = "clang"
> >
> > -inherit pythonnative setuptools
> > +inherit python3native setuptools
> >
> >  # Chromium itself is licensed under the 3-clause BSD license. However, it
> >  # depends upon several other projects whose copyright files are listed in
> > --
> > 2.7.4
> >
> > 
> >

> 

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#85275): 
https://lists.openembedded.org/g/openembedded-devel/message/85275
Mute This Topic: https://lists.openembedded.org/mt/75049276/21656
Group Owner: openembedded-devel+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [oe] [meta-browser][PATCH] chromium.inc: Use python3native.bbclass instead of pythonnative.bbclass

[Alexander Kanavin]

Wait, did you actually test this? Chromium is not yet ready for python3,
and builds will fail.

Alex

On Tue, 23 Jun 2020 at 00:09, Chandana kalluri  wrote:

> From dunfell onwards, python2 recipes and classes are not supported.
> Inherit
> python3native.bbclass for chromium instead of pythonnative.bbclass
>
> Signed-off-by: Sai Hari Chandana Kalluri 
> ---
>  recipes-browser/chromium/chromium.inc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/recipes-browser/chromium/chromium.inc
> b/recipes-browser/chromium/chromium.inc
> index 14d762f..a483ec4 100644
> --- a/recipes-browser/chromium/chromium.inc
> +++ b/recipes-browser/chromium/chromium.inc
> @@ -18,7 +18,7 @@ TOOLCHAIN = "clang"
>  # to build the native recipes (e.g. GN) with clang too.
>  TOOLCHAIN_class-native = "clang"
>
> -inherit pythonnative setuptools
> +inherit python3native setuptools
>
>  # Chromium itself is licensed under the 3-clause BSD license. However, it
>  # depends upon several other projects whose copyright files are listed in
> --
> 2.7.4
>
> 
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#85274): 
https://lists.openembedded.org/g/openembedded-devel/message/85274
Mute This Topic: https://lists.openembedded.org/mt/75049276/21656
Group Owner: openembedded-devel+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [oe] [meta-browser][PATCH 1/2] chromium: don't pass is_official_build=true when doing a component-build

[Otavio Salvador]

On Fri, Aug 9, 2019 at 6:20 AM Rasmus Villemoes
 wrote:
>
> When setting the PACKAGECONFIG component-build, the build breaks
> immediately due to this from the toplevel BUILD.gn:
>
> if (is_official_build) {
>   # An official (maximally optimized!) component (optimized for build times)
>   # build doesn't make sense and usually doesn't work.
>   assert(!is_component_build)
> }
>
> So we must make is_official_build the negative of component-build.
>
> Signed-off-by: Rasmus Villemoes 

Good, please open a PR on GitHub so we can merge it :-)

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854  Mobile: +1 (347) 903-9750
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-browser][PATCH 1/2] chromium: don't pass is_official_build=true when doing a component-build

[Khem Raj]

On Fri, Aug 9, 2019 at 2:20 AM Rasmus Villemoes
 wrote:
>
> When setting the PACKAGECONFIG component-build, the build breaks
> immediately due to this from the toplevel BUILD.gn:
>
> if (is_official_build) {
>   # An official (maximally optimized!) component (optimized for build times)
>   # build doesn't make sense and usually doesn't work.
>   assert(!is_component_build)
> }
>
> So we must make is_official_build the negative of component-build.
>
> Signed-off-by: Rasmus Villemoes 
> ---
>  recipes-browser/chromium/chromium-gn.inc | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/recipes-browser/chromium/chromium-gn.inc 
> b/recipes-browser/chromium/chromium-gn.inc
> index d5258c0..d9735ab 100644
> --- a/recipes-browser/chromium/chromium-gn.inc
> +++ b/recipes-browser/chromium/chromium-gn.inc
> @@ -138,7 +138,8 @@ GN_ARGS += 'host_pkg_config="pkg-config-native"'
>  # (debug, release, official) but for historical reasons there are two
>  # separate flags.
>  # See also: 
> https://groups.google.com/a/chromium.org/d/msg/chromium-dev/hkcb6AOX5gE/PPT1ukWoBwAJ
> -GN_ARGS += "is_debug=false is_official_build=true"
> +GN_ARGS += "is_debug=false"
> +GN_ARGS += "is_official_build=${@bb.utils.contains('PACKAGECONFIG', 
> 'component-build', 'false', 'true', d)}"
>

this looks good.

>  # Starting with M61, Chromium defaults to building with its own copy of 
> libc++
>  # instead of the system's libstdc++. Explicitly disable this behavior.
> --
> 2.20.1
>
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-browser][PATCH] README: update list of maintainers

[Ulrich Ölmann]

Hi there,

to ease the development flow I created a pull request on GitHub for this
subthread's patch as well :)

  https://github.com/OSSystems/meta-browser/pull/279

Best regards
Ulrich


On Thu, Jun 27 2019 at 01:23 +0200, Ulrich Ölmann  
wrote:
> Signed-off-by: Ulrich Ölmann 
> ---
>  README | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/README b/README
> index 0a005a8b5ea6..31d361d2ab41 100644
> --- a/README
> +++ b/README
> @@ -23,13 +23,15 @@ revision: HEAD
>  Contributing
>  
>
> -To contribute to this layer you should the patches for review to the
> +To contribute to this layer you should send the patches for review to the
>  OpenEmbedded dev mailing list openembedded-devel@lists.openembedded.org
>  and please cc the maintainers.
>
> -Maintainers: Eric Bénard 
> - Denis Carikli 
> +Maintainers: Fabio Berton 
> + Raphael Kubo da Costa 
> + Khem Raj 
>   Otavio Salvador 
> + Maksim Sisov 
>
>  When sending single patches, please use something like :
>  git send-email -1 -s --to openembedded-devel@lists.openembedded.org 
> --subject-prefix='meta-browser][PATCH'
-- 
Pengutronix e.K.   | Ulrich Ölmann   |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-browser][PATCH] chromium-ozone-wayland: Stop depending on the system's wayland-scanner binary

[Ulrich Ölmann]

Hi maintainers of meta-browser,

looking back in the mailing-list archives I got the impression that
meta-browser's development does not really take place here anymore these
days, but is pushed on on GitHub. Hence I prepared a pull request of
this thread's patch and would like to ask for review:

  https://github.com/OSSystems/meta-browser/pull/278

Best regards
Ulrich

On Thu, Jun 27 2019 at 15:38 +0200, Ulrich Ölmann  
wrote:
> This commit re-applies the changes of the commit given below to the current
> chromium-ozone-wayland recipe as they got lost in the meantime.
>
> | commit cd88d7be61bc39726b8ecf7ddc19e6942bcf8cb4
> | Author: Raphael Kubo da Costa 
> | Date:   Thu May 2 12:08:54 2019 +0200
> |
> | chromium-ozone-wayland: Stop depending on the system's wayland-scanner
> | binary
> |
> | So far, we were using Chromium's default GN path for the system
> | wayland-scanner binary, "/usr/bin/wayland-scanner", which may not be 
> present
> | at all and which should never be used anyway. Instead, we now point to 
> the
> | version built by the wayland-native recipe.
> |
> | Doing so of course requires depending on wayland-native in the first 
> place,
> | and that requires adding back REQUIRED_DISTRO_FEATURES and a DEPENDS 
> block
> | that got removed with no explanation when the recipe was updated to
> | M72 (commit 97876fab, "chromium: Update to 72.0.3626.81").
> |
> | Fixes #241
> |
> | Signed-off-by: Raphael Kubo da Costa 
>
> Fixes: 1f363e25cb7d ("chromium: Update to 74.0.3729.131")
> Signed-off-by: Ulrich Ölmann 
> ---
>  .../chromium/chromium-ozone-wayland_75.0.3770.100.bb   | 10 ++
>  1 file changed, 10 insertions(+)
>
> diff --git a/recipes-browser/chromium/chromium-ozone-wayland_75.0.3770.100.bb 
> b/recipes-browser/chromium/chromium-ozone-wayland_75.0.3770.100.bb
> index 22afa52aec20..1e4ed2958d2d 100644
> --- a/recipes-browser/chromium/chromium-ozone-wayland_75.0.3770.100.bb
> +++ b/recipes-browser/chromium/chromium-ozone-wayland_75.0.3770.100.bb
> @@ -31,6 +31,15 @@ SRC_URI += " \
>  file://0001-ozone-wayland-Fix-method-prototype-match.patch \
>  "
>
> +REQUIRED_DISTRO_FEATURES = "wayland"
> +
> +DEPENDS += "\
> +libxkbcommon \
> +virtual/egl \
> +wayland \
> +wayland-native \
> +"
> +
>  # Chromium can use v4l2 device for hardware accelerated video decoding. Make 
> sure that
>  # /dev/video-dec exists.
>  PACKAGECONFIG[use-linux-v4l2] = "use_v4l2_codec=true use_v4lplugin=true 
> use_linux_v4l2_only=true"
> @@ -42,6 +51,7 @@ GN_ARGS += "\
>  ozone_platform_headless=true \
>  ozone_platform_wayland=true \
>  ozone_platform_x11=false \
> +
> system_wayland_scanner_path="${STAGING_BINDIR_NATIVE}/wayland-scanner" \
>  use_xkbcommon=true \
>  use_system_libwayland=true \
>  use_system_minigbm=true \
-- 
Pengutronix e.K.   | Ulrich Ölmann   |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-browser] host leaking wayland-scanner?

[Otavio Salvador]

Hello Ulrich,

On Wed, Jun 26, 2019 at 10:29 AM Ulrich Ölmann  wrote:
> Again it's me with another small question regarding meta-browser's
> maintainership - I got the following back from our mail delivery system:
...
> Are Denis Carikli and Eric Bénard still actively maintaining meta-
> browser? (Their last commits are from 2012-07-12 and 2013-03-08
> respectively).

They are not.

> As both are listed as maintainers in [6] I would like to
> ask if a patch to update the README file is welcome? Are there other
> maintainers that shall be listed there instead?

Absolutely, please prepare it.

Raphael, Maksim, Khem, Fabio and I are the active people.

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854  Mobile: +1 (347) 903-9750
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-browser] host leaking wayland-scanner?

[Ulrich Ölmann]

Again it's me with another small question regarding meta-browser's
maintainership - I got the following back from our mail delivery system:

From: Mail Delivery System 
To: u...@pengutronix.de
Subject: Mail delivery failed: returning message to sender
Date: Wed 26.06.2019
Flags: seen
Maildir: /
Message-Id: e1hg7dm-00010m...@metis.ext.pengutronix.de
Attachments: [1]Re- [meta-browser] host leaking wayland-scanner?.eml

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  de...@eukrea.com
host mx1.ovh.net [188.165.47.122]
SMTP error from remote mail server after RCPT TO::
554 5.7.1 : Relay access denied
  e...@eukrea.com
host mx1.ovh.net [188.165.47.122]
SMTP error from remote mail server after RCPT TO::
554 5.7.1 : Relay access denied

Are Denis Carikli and Eric Bénard still actively maintaining meta-
browser? (Their last commits are from 2012-07-12 and 2013-03-08
respectively). As both are listed as maintainers in [6] I would like to
ask if a patch to update the README file is welcome? Are there other
maintainers that shall be listed there instead?

Best regards
Ulrich


[6] https://github.com/OSSystems/meta-browser/blob/master/README

On Wed, Jun 26 2019 at 14:29 +0200, Ulrich Ölmann  
wrote:
> Hi developers of meta-browser,
>
> while building meta-browser's latest chromium-ozone-wayland recipe (my
> meta-browser's current state is [1], integrated into a customer's thud
> based Yocto-BSP) I faced the following problem (excerpt from log.do_com-
> pile)
>
>   [9109/37430] python ../../third_party/wayland/wayland_scanner_wrapper.py 
> third_party/wayland-protocols/src/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml
>  --src-root ../../ --root-gen-dir gen --cmd /usr/bin/wayland-scanner
>   FAILED: 
> gen/third_party/wayland-protocols/src/unstable/linux-dmabuf/linux-dmabuf-unstable-v1-protocol.c
>  
> gen/third_party/wayland-protocols/src/unstable/linux-dmabuf/linux-dmabuf-unstable-v1-client-protocol.h
>  
> gen/third_party/wayland-protocols/src/unstable/linux-dmabuf/linux-dmabuf-unstable-v1-server-protocol.h
>   python ../../third_party/wayland/wayland_scanner_wrapper.py 
> third_party/wayland-protocols/src/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml
>  --src-root ../../ --root-gen-dir gen --cmd /usr/bin/wayland-scanner
>   Traceback (most recent call last):
> File "../../third_party/wayland/wayland_scanner_wrapper.py", line 48, in 
> 
>   main(sys.argv)
> File "../../third_party/wayland/wayland_scanner_wrapper.py", line 40, in 
> main
>   generate_code(cmd, "code", protocol_path, out_base_name + "-protocol.c")
> File "../../third_party/wayland/wayland_scanner_wrapper.py", line 18, in 
> generate_code
>   ret = subprocess.call([wayland_scanner_cmd, code_type, path_in, 
> path_out])
> File 
> "/build/YOCTO.BSP/tmp/work/cortexa9hf-neon-pmc-linux-gnueabi/chromium-ozone-wayland/75.0.3770.100-r0/recipe-sysroot-native/usr/lib/python2.7/subprocess.py",
>  line 172, in call
>   return Popen(*popenargs, **kwargs).wait()
> File 
> "/build/YOCTO.BSP/tmp/work/cortexa9hf-neon-pmc-linux-gnueabi/chromium-ozone-wayland/75.0.3770.100-r0/recipe-sysroot-native/usr/lib/python2.7/subprocess.py",
>  line 394, in __init__
>   errread, errwrite)
> File 
> "/build/YOCTO.BSP/tmp/work/cortexa9hf-neon-pmc-linux-gnueabi/chromium-ozone-wayland/75.0.3770.100-r0/recipe-sysroot-native/usr/lib/python2.7/subprocess.py",
>  line 1047, in _execute_child
>   raise child_exception
>   OSError: [Errno 2] No such file or directory
>
> which seems to come from my build host not providing '/usr/bin/wayland-
> scanner' and which suggests that we have a host tool leakage here. This
> all originally results from Chromium's commit [2], particularly [3].
>
> Unfortunately up to now I am not familiar with Google's build tool 'GN'
> (see [4]), so I can't present a solution straightaway. But I would like
> to start working on a patch now, hence my questions are:
>
>   - did anyone notice the same issue?
>   - is my analysis correct that [3] has to be patched somehow and the
> recipe [5] lacks a dependency on wayland-native?
>
> Best regards
> Ulrich
>
>
> P.S.: Sending this message a second time as I have not been subscribed
> to the oe-devel list before so that the original mail got rejected.
>
>
> [1] e0d1e299d691 ("chromium: fix "pure virtual method called" problem.")
> [2] 
> https://chromium.googlesource.com/chromium/src/+/a64f758399d26a1c80ab0d3dfecee3abf0714305
> a64f758399d2 ("Run wayland-scanner as part of build")
> [3] 
> https://chromium.googlesource.com/chromium/src/+/a64f758399d26a1c80ab0d3dfecee3abf0714305/third_party/wayland/features.gni#12
> [4] https://gn.googlesource.com/gn/
> [5] 
> 

Re: [oe] [meta-browser] host leaking wayland-scanner?

[Ulrich Ölmann]

Hi Maksim,

On Wed, Jun 26 2019 at 14:39 +0200, Maksim Sisov  wrote:
> The wayland-scanner issue must have been fixed by
> https://github.com/OSSystems/meta-browser/commit/cd88d7be61bc39726b8ecf7ddc19e6942bcf8cb4

ah, okay - that's right. But unfortunately it was re-introduced by
commit [6] later. At least that shows how to fix it again - I will
prepare a patch.

Thanks & best regards
Ulrich


[6] 1f363e25cb7d ("chromium: Update to 74.0.3729.131")

> On 26.06.2019 15:29, Ulrich Ölmann wrote:
>> Hi developers of meta-browser,
>>
>> while building meta-browser's latest chromium-ozone-wayland recipe (my
>> meta-browser's current state is [1], integrated into a customer's thud
>> based Yocto-BSP) I faced the following problem (excerpt from log.do_com-
>> pile)
>>
>>   [9109/37430] python
>> ../../third_party/wayland/wayland_scanner_wrapper.py
>> third_party/wayland-protocols/src/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml
>> --src-root ../../ --root-gen-dir gen --cmd /usr/bin/wayland-scanner
>>   FAILED:
>> gen/third_party/wayland-protocols/src/unstable/linux-dmabuf/linux-dmabuf-unstable-v1-protocol.c
>> gen/third_party/wayland-protocols/src/unstable/linux-dmabuf/linux-dmabuf-unstable-v1-client-protocol.h
>> gen/third_party/wayland-protocols/src/unstable/linux-dmabuf/linux-dmabuf-unstable-v1-server-protocol.h
>>   python ../../third_party/wayland/wayland_scanner_wrapper.py
>> third_party/wayland-protocols/src/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml
>> --src-root ../../ --root-gen-dir gen --cmd /usr/bin/wayland-scanner
>>   Traceback (most recent call last):
>> File "../../third_party/wayland/wayland_scanner_wrapper.py", line
>> 48, in 
>>   main(sys.argv)
>> File "../../third_party/wayland/wayland_scanner_wrapper.py", line
>> 40, in main
>>   generate_code(cmd, "code", protocol_path, out_base_name + 
>> "-protocol.c")
>> File "../../third_party/wayland/wayland_scanner_wrapper.py", line
>> 18, in generate_code
>>   ret = subprocess.call([wayland_scanner_cmd, code_type, path_in, 
>> path_out])
>> File
>> "/build/YOCTO.BSP/tmp/work/cortexa9hf-neon-pmc-linux-gnueabi/chromium-ozone-wayland/75.0.3770.100-r0/recipe-sysroot-native/usr/lib/python2.7/subprocess.py",
>> line 172, in call
>>   return Popen(*popenargs, **kwargs).wait()
>> File
>> "/build/YOCTO.BSP/tmp/work/cortexa9hf-neon-pmc-linux-gnueabi/chromium-ozone-wayland/75.0.3770.100-r0/recipe-sysroot-native/usr/lib/python2.7/subprocess.py",
>> line 394, in __init__
>>   errread, errwrite)
>> File
>> "/build/YOCTO.BSP/tmp/work/cortexa9hf-neon-pmc-linux-gnueabi/chromium-ozone-wayland/75.0.3770.100-r0/recipe-sysroot-native/usr/lib/python2.7/subprocess.py",
>> line 1047, in _execute_child
>>   raise child_exception
>>   OSError: [Errno 2] No such file or directory
>>
>> which seems to come from my build host not providing '/usr/bin/wayland-
>> scanner' and which suggests that we have a host tool leakage here. This
>> all originally results from Chromium's commit [2], particularly [3].
>>
>> Unfortunately up to now I am not familiar with Google's build tool 'GN'
>> (see [4]), so I can't present a solution straightaway. But I would like
>> to start working on a patch now, hence my questions are:
>>
>>   - did anyone notice the same issue?
>>   - is my analysis correct that [3] has to be patched somehow and the
>> recipe [5] lacks a dependency on wayland-native?
>>
>> Best regards
>> Ulrich
>>
>>
>> P.S.: Sending this message a second time as I have not been subscribed
>> to the oe-devel list before so that the original mail got rejected.
>>
>>
>> [1] e0d1e299d691 ("chromium: fix "pure virtual method called" problem.")
>> [2]
>> https://chromium.googlesource.com/chromium/src/+/a64f758399d26a1c80ab0d3dfecee3abf0714305
>> a64f758399d2 ("Run wayland-scanner as part of build")
>> [3]
>> https://chromium.googlesource.com/chromium/src/+/a64f758399d26a1c80ab0d3dfecee3abf0714305/third_party/wayland/features.gni#12
>> [4] https://gn.googlesource.com/gn/
>> [5]
>> https://github.com/OSSystems/meta-browser/blob/master/recipes-browser/chromium/chromium-ozone-wayland_75.0.3770.100.bb


--
Pengutronix e.K.   | Ulrich Ölmann   |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-browser][PATCH] chromium: add 2 fixes for v4l2 VDA support

[Otavio Salvador]

Hello Peter,

On Fri, Mar 15, 2019 at 8:25 PM Peter Griffin  wrote:
>
> The first patch allows GpuVideoDecoder to actually get created.
> Without it chrome://gpu report hardware video acceleration is
> enabled, but actually ffmpegVideoDecoder is used for the decode.
>
> The second adds NV12 & YVU420 formats for all ARM platforms,
> otherwise V4L2 VDA on dragonboard will error with NV12 buffers.
>
> Signed-off-by: Peter Griffin 

Thank you for working on this; please open a PR on github as we have
been using it for the layer as a way to get more people to contribute
to it.

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854  Mobile: +1 (347) 903-9750
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-browser] Chromium missing DEPENDS

[Garren, Chris D.]

That looks like it's fixed the issue. I guess I'll submit a patch for it.

Thanks,

Chris Garren


-Original Message-
From: Khem Raj [mailto:raj.k...@gmail.com] 
Sent: Friday, November 9, 2018 9:31 AM
To: Garren, Chris D. 
Cc: openembeded-devel 
Subject: Re: [oe] [meta-browser] Chromium missing DEPENDS

On Fri, Nov 9, 2018 at 4:59 AM Garren, Chris D.
 wrote:
>
> I'm working on building an image with chromium for a Variscite 
> VAR-SOM-MX6-SOLO. I previously was able to build an image for the DART-6UL 
> successfully with chromium included. When I changed machines, I started 
> getting an error during the do_configure step of chromium-x11:
>
> ERROR: chromium-x11-69.0.3497.100-r0 do_configure: Function failed: 
> do_configure (log file is located at 
> /home/cdgarren/yocto/build/tmp/work/cortexa9hf-neon-mx6qdl-poky-linux-
> gnueabi/chromiu
> m-x11/69.0.3497.100-r0/temp/log.do_configure.79809)
> ERROR: Logfile of failure stored in: 
> /home/cdgarren/yocto/build/tmp/work/cortexa9hf-neon-mx6qdl-poky-linux-
> gnueabi/chromium-x11/69.0.3497.100-r0/temp/log.do_configure.79809
> Log data follows:
> | DEBUG: Executing shell function do_configure ERROR at 
> | //build/config/linux/pkg_config.gni:103:17: Script returned non-zero exit 
> code.
> | pkgresult = exec_script(pkg_config_script, args, "value")
> | ^--
> | Current dir: 
> | /home/cdgarren/yocto/build/tmp/work/cortexa9hf-neon-mx6qdl-poky-linu
> | x-gnueabi/chromium-x11/69.0.3497.100-r0/chromium-69.0.3497.100/out/R
> | elease/
> | Command: python 
> | 
> /home/cdgarren/yocto/build/tmp/work/cortexa9hf-neon-mx6qdl-poky-linux-gnueabi/chromium-x11/69.0.3497.100-r0/chromium-69.0.3497.100/build/config/linux/pkg-config.py
>  atk atk-bridge-2.0 Returned 1.
> | stderr:
> |
> | Package atk-bridge-2.0 was not found in the pkg-config search path.
> | Perhaps you should add the directory containing `atk-bridge-2.0.pc'
> | to the PKG_CONFIG_PATH environment variable No package 
> | 'atk-bridge-2.0' found Could not run pkg-config.
> |
> | See //build/config/linux/atk/BUILD.gn:20:1: whence it was called.
> | pkg_config("atk_base") {
> | ^---
> | See //ui/views/BUILD.gn:686:24: which caused the file to be included.
> |   configs += [ "//build/config/linux/atk" ]
> |^-
> | WARNING: exit code 1 from a shell command.
> | ERROR: Function failed: do_configure (log file is located at 
> | /home/cdgarren/yocto/build/tmp/work/cortexa9hf-neon-mx6qdl-poky-linu
> | x-gnueabi/chromium-x11/69.0.3497.100-r0/temp/log.do_configure.79809)
> ERROR: Task 
> (/home/cdgarren/yocto/sources/meta-browser/recipes-browser/chromium/chromium-x11_69.0.3497.100.bb:do_configure)
>  failed with exit code '1'
>
> Any ideas what might be causing this?
>

try adding  at-spi2-atk to DEPENDS


> Thanks,
>
> Chris Garren
>
> --
> ___
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-browser] Chromium missing DEPENDS

[Khem Raj]

On Fri, Nov 9, 2018 at 4:59 AM Garren, Chris D.
 wrote:
>
> I'm working on building an image with chromium for a Variscite 
> VAR-SOM-MX6-SOLO. I previously was able to build an image for the DART-6UL 
> successfully with chromium included. When I changed machines, I started 
> getting an error during the do_configure step of chromium-x11:
>
> ERROR: chromium-x11-69.0.3497.100-r0 do_configure: Function failed: 
> do_configure (log file is located at 
> /home/cdgarren/yocto/build/tmp/work/cortexa9hf-neon-mx6qdl-poky-linux-gnueabi/chromiu
> m-x11/69.0.3497.100-r0/temp/log.do_configure.79809)
> ERROR: Logfile of failure stored in: 
> /home/cdgarren/yocto/build/tmp/work/cortexa9hf-neon-mx6qdl-poky-linux-gnueabi/chromium-x11/69.0.3497.100-r0/temp/log.do_configure.79809
> Log data follows:
> | DEBUG: Executing shell function do_configure
> | ERROR at //build/config/linux/pkg_config.gni:103:17: Script returned 
> non-zero exit code.
> | pkgresult = exec_script(pkg_config_script, args, "value")
> | ^--
> | Current dir: 
> /home/cdgarren/yocto/build/tmp/work/cortexa9hf-neon-mx6qdl-poky-linux-gnueabi/chromium-x11/69.0.3497.100-r0/chromium-69.0.3497.100/out/Release/
> | Command: python 
> /home/cdgarren/yocto/build/tmp/work/cortexa9hf-neon-mx6qdl-poky-linux-gnueabi/chromium-x11/69.0.3497.100-r0/chromium-69.0.3497.100/build/config/linux/pkg-config.py
>  atk atk-bridge-2.0
> | Returned 1.
> | stderr:
> |
> | Package atk-bridge-2.0 was not found in the pkg-config search path.
> | Perhaps you should add the directory containing `atk-bridge-2.0.pc'
> | to the PKG_CONFIG_PATH environment variable
> | No package 'atk-bridge-2.0' found
> | Could not run pkg-config.
> |
> | See //build/config/linux/atk/BUILD.gn:20:1: whence it was called.
> | pkg_config("atk_base") {
> | ^---
> | See //ui/views/BUILD.gn:686:24: which caused the file to be included.
> |   configs += [ "//build/config/linux/atk" ]
> |^-
> | WARNING: exit code 1 from a shell command.
> | ERROR: Function failed: do_configure (log file is located at 
> /home/cdgarren/yocto/build/tmp/work/cortexa9hf-neon-mx6qdl-poky-linux-gnueabi/chromium-x11/69.0.3497.100-r0/temp/log.do_configure.79809)
> ERROR: Task 
> (/home/cdgarren/yocto/sources/meta-browser/recipes-browser/chromium/chromium-x11_69.0.3497.100.bb:do_configure)
>  failed with exit code '1'
>
> Any ideas what might be causing this?
>

try adding  at-spi2-atk to DEPENDS


> Thanks,
>
> Chris Garren
>
> --
> ___
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-browser][PATCH] layer.conf: add LAYERSERIES_COMPAT

[Martin Jansa]

You can ignore this one, different version got merged through github PR:
https://github.com/OSSystems/meta-browser/pull/107

On Fri, Apr 6, 2018 at 2:34 PM, Martin Jansa  wrote:

> Signed-off-by: Martin Jansa 
> ---
>  conf/layer.conf | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/conf/layer.conf b/conf/layer.conf
> index 5275778..37c4160 100644
> --- a/conf/layer.conf
> +++ b/conf/layer.conf
> @@ -9,3 +9,5 @@ BBFILE_PATTERN_browser-layer := "^${LAYERDIR}/"
>  BBFILE_PRIORITY_browser-layer = "7"
>
>  LAYERVERSION_browser-layer = "1"
> +
> +LAYERSERIES_COMPAT_browser-layer = "sumo"
> --
> 2.15.1
>
>
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-browser] RFC: updating chromium-ozone-wayland to 65.0.xxxx.0.rxxxxxx.igalia.1

[Khem Raj]

On Mon, Jan 22, 2018 at 1:54 PM, Andrey Konovalov
 wrote:
> Hello,
>
> chromium-ozone-wayland_64.0.3274.0.r517731.igalia.1.bb from current
> meta-browser [1] didn't
> quite worked for me: e.g. I was getting the "Aw Snap" after filling in the
> search text box and pressing 
> at youtube.com; sometimes when moving the mouse pointer over the screen the
> mouse cursor became the arrow
> and was not changing for quite a while when moving over the chromium window
> (looks similar to the issue [2]
> though it should have been fixed in r517731 if I got it correct).
>
> But when I tried updating chromium-ozone-wayland to version 65 using [3] as
> the basis,
> those two issues were gone, and chromium became much more usable for me.
> Then I did the following:
>   * from [3] took only the changes relevant to the version update,
>   * rebased on the current OSSystems/meta-browser,
>   * replaced the patches added to SRC_URI with the upstream versions where
> applicable,
>   * updated to the latest tarball at [4] (though I don't see a difference in
> how 65.0.3298.0.r524623
> and 65.0.3315.0.r527534 behave, any of these are OK for me)
> - thus ending up with [5] (the 3 topmost commits).
> (If we go with r524623, the topmost commit is to be dropped. Or if we go
> with r527534, the two topmost commits
> are to be squashed into one.)
> Basically this is still the subset of Maxim's work [3] with minor changes.
>
> Does it make sense to update chromium-ozone-wayland to version 65 now?
> One of my concerns is that it was only tested on an aarch64 target
> (dragonboard-410c) in rocko, and build-only-tested
> for an armv7 machine (am57xx-evm, rocko as well).

65 is dev channel, so I think if you keep updating it until 65 hits
release it should be ok
Can you check it on x86 arch too ? may be qemux86-64

>
>
> Thanks,
> Andrey
>
>
> [1]
> https://github.com/OSSystems/meta-browser/tree/master/recipes-browser/chromium
> [2] https://github.com/Igalia/chromium/issues/317
> [3]
> https://github.com/Igalia/meta-browser/commits/ozone/wayland/65.0.3298.0.r524623
> [4] https://tmp.igalia.com/chromium-tarballs/
> [5] https://github.com/andrey-konovalov/meta-browser/commits/my.master
> --
> ___
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-browser] RFC: updating chromium-ozone-wayland to 65.0.xxxx.0.rxxxxxx.igalia.1

[Andrey Konovalov]

Hello Maksim,

On 23.01.2018 15:52, Maksim Sisov wrote:

Hello Andrey,

Yes, it makes sense to update the recipe, which I'm going to do in the
end of this or in the beginning of the next week,


That's great news!

Thanks,
Andrey


as long as the work is
based on chromium ToT, and the code base is always changing.

On 22.01.2018 21:54, Andrey Konovalov wrote:

Hello,

chromium-ozone-wayland_64.0.3274.0.r517731.igalia.1.bb from current
meta-browser [1] didn't
quite worked for me: e.g. I was getting the "Aw Snap" after filling in
the search text box and pressing 
at youtube.com; sometimes when moving the mouse pointer over the
screen the mouse cursor became the arrow
and was not changing for quite a while when moving over the chromium
window (looks similar to the issue [2]
though it should have been fixed in r517731 if I got it correct).

But when I tried updating chromium-ozone-wayland to version 65 using
[3] as the basis,
those two issues were gone, and chromium became much more usable for
me. Then I did the following:
   * from [3] took only the changes relevant to the version update,
   * rebased on the current OSSystems/meta-browser,
   * replaced the patches added to SRC_URI with the upstream versions
where applicable,
   * updated to the latest tarball at [4] (though I don't see a
difference in how 65.0.3298.0.r524623
 and 65.0.3315.0.r527534 behave, any of these are OK for me)
- thus ending up with [5] (the 3 topmost commits).
(If we go with r524623, the topmost commit is to be dropped. Or if we
go with r527534, the two topmost commits
are to be squashed into one.)
Basically this is still the subset of Maxim's work [3] with minor changes.

Does it make sense to update chromium-ozone-wayland to version 65 now?
One of my concerns is that it was only tested on an aarch64 target
(dragonboard-410c) in rocko, and build-only-tested
for an armv7 machine (am57xx-evm, rocko as well).


Thanks,
Andrey


[1]
https://github.com/OSSystems/meta-browser/tree/master/recipes-browser/chromium
[2] https://github.com/Igalia/chromium/issues/317
[3]
https://github.com/Igalia/meta-browser/commits/ozone/wayland/65.0.3298.0.r524623
[4] https://tmp.igalia.com/chromium-tarballs/
[5] https://github.com/andrey-konovalov/meta-browser/commits/my.master


-Maksim



--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-browser] Running chromium as root

[Bhargava Sreekantappa Gayathri]

Thanks Jacob, I will try that out.

Thanks,
Bhargav

> -Original Message-
> From: openembedded-devel-boun...@lists.openembedded.org
> [mailto:openembedded-devel-boun...@lists.openembedded.org] On Behalf Of
> Jacobo Aragunde Pérez
> Sent: Tuesday, January 16, 2018 4:22 AM
> To: openembedded-devel@lists.openembedded.org
> Subject: Re: [oe] [meta-browser] Running chromium as root
> 
> Hi!
> 
> On 15/01/18 23:14, Bhargava Sreekantappa Gayathri wrote:
> > Hello,
> >
> > Has anyone has been able to run chromium-x11 as root user? Is there a flag 
> > or
> config I can tweak before building chromium?
> >
> 
> You should be able to run chromium as root with the runtime flag `--no-
> sandbox`. No changes in the build process are needed.
> 
> Take into account such a setup is discouraged for security reasons!
> 
> Best,
> --
> Jacobo Aragunde
> Software Engineer at Igalia
> --
> ___
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-browser] Running chromium as root

[Jacobo Aragunde Pérez]

Hi!

On 15/01/18 23:14, Bhargava Sreekantappa Gayathri wrote:
> Hello,
> 
> Has anyone has been able to run chromium-x11 as root user? Is there a flag or 
> config I can tweak before building chromium?
> 

You should be able to run chromium as root with the runtime flag
`--no-sandbox`. No changes in the build process are needed.

Take into account such a setup is discouraged for security reasons!

Best,
-- 
Jacobo Aragunde
Software Engineer at Igalia
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-browser] CFT: Chromium 62 in meta-browser

[Raphael Kubo da Costa]

Ayoub Zaki  writes:

> Hello all,
>
> I'm trying to build from the latest commit meta-browser:
> a8bb1e779bc3565beacceadc4414816670f33475 with an imx6 using yocto pyro
> branch with meta-freescale, however the build fails :

FWIW, the errors reported below seem to be coming from Node. I guess the
node.js version in your pyro branch is too old and does not support all
the JS features present in the Chromium code.
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-browser] CFT: Chromium 62 in meta-browser

[Ayoub Zaki]

Hi Raphael,

Yes you are right, it  built better with using rocko branch, now Chromium
is up and running.
Thanks  again for the amazing work :-)

best regards,

On Mon, Dec 11, 2017 at 12:30 PM, Raphael Kubo da Costa <
raphael.kubo.da.co...@intel.com> wrote:

> Ayoub Zaki  writes:
>
> > Hello all,
> >
> > I'm trying to build from the latest commit meta-browser:
> > a8bb1e779bc3565beacceadc4414816670f33475 with an imx6 using yocto pyro
> > branch with meta-freescale, however the build fails :
>
> FWIW, the errors reported below seem to be coming from Node. I guess the
> node.js version in your pyro branch is too old and does not support all
> the JS features present in the Chromium code.
>
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-browser] CFT: Chromium 62 in meta-browser

[Ian Coolidge]

The chromium-imx patches don't apply cleanly since chromium52. Also
patching chromium52 properly to compile and use chromium-imx on Rocko also
has it's issues, I've got a build for that currently but SSL handshaking is
broken somehow. I need to debug it more but its a large task.

On Tue, Nov 28, 2017 at 5:05 AM, Otavio Salvador <
otavio.salva...@ossystems.com.br> wrote:

> On Tue, Nov 28, 2017 at 10:47 AM, Ayoub Zaki 
> wrote:
> > Hi Otavio,
> >
> > that's a shame :-( thanks for the information.
> > are they other browsers that are well supported with GPU acceleration on
> > iMX6 ?
> > what about Firefox ?
>
> GPU works, VPU does not. You need to pass some params to ignore
> gpu-blacklist and like.
>
> --
> Otavio Salvador O.S. Systems
> http://www.ossystems.com.brhttp://code.ossystems.com.br
> Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
> --
> ___
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
>
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-browser] CFT: Chromium 62 in meta-browser

[Otavio Salvador]

On Tue, Nov 28, 2017 at 10:47 AM, Ayoub Zaki  wrote:
> Hi Otavio,
>
> that's a shame :-( thanks for the information.
> are they other browsers that are well supported with GPU acceleration on
> iMX6 ?
> what about Firefox ?

GPU works, VPU does not. You need to pass some params to ignore
gpu-blacklist and like.

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-browser] CFT: Chromium 62 in meta-browser

[Ayoub Zaki]

Hi Otavio,

that's a shame :-( thanks for the information.
are they other browsers that are well supported with GPU acceleration on
iMX6 ?
what about Firefox ?
Thank you!

On Tue, Nov 28, 2017 at 12:58 PM, Otavio Salvador <
otavio.salva...@ossystems.com.br> wrote:

> On Tue, Nov 28, 2017 at 6:13 AM, Ayoub Zaki 
> wrote:
> > Thank you, indeed I used rocko branches and it seems to build and also
> run
> > on an iMX6!
> > I use a mainline kernel 4.14  and with iMX6 Etnaviv GPU acceleration
> > support.
> > It's not clear for me how to enable GPU acceleration with chromium +
> > Etnaviv :
> > I tried the switch --use-gl=any,  it starts up but when running WebGL
> demo
> > Chromium/Etnaviv is crashing...
> > For normal browsing it works just fine however I noticed that CPU
> > consumption is very high > 50%
> > Anyone having better experience with Chromium + HW accleration support on
> > iMX6 ?
>
> The i.MX6 support requires a number of patches to properly support its
> hardware. Currently not well supported ...
>
> --
> Otavio Salvador O.S. Systems
> http://www.ossystems.com.brhttp://code.ossystems.com.br
> Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
>
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-browser] CFT: Chromium 62 in meta-browser

[Otavio Salvador]

On Tue, Nov 28, 2017 at 6:13 AM, Ayoub Zaki  wrote:
> Thank you, indeed I used rocko branches and it seems to build and also run
> on an iMX6!
> I use a mainline kernel 4.14  and with iMX6 Etnaviv GPU acceleration
> support.
> It's not clear for me how to enable GPU acceleration with chromium +
> Etnaviv :
> I tried the switch --use-gl=any,  it starts up but when running WebGL demo
> Chromium/Etnaviv is crashing...
> For normal browsing it works just fine however I noticed that CPU
> consumption is very high > 50%
> Anyone having better experience with Chromium + HW accleration support on
> iMX6 ?

The i.MX6 support requires a number of patches to properly support its
hardware. Currently not well supported ...

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-browser] CFT: Chromium 62 in meta-browser

[Ayoub Zaki]

Hi Ian,

Thank you, indeed I used rocko branches and it seems to build and also run
on an iMX6!
I use a mainline kernel 4.14  and with iMX6 Etnaviv GPU acceleration
support.
It's not clear for me how to enable GPU acceleration with chromium +
Etnaviv :
I tried the switch --use-gl=any,  it starts up but when running WebGL demo
Chromium/Etnaviv is crashing...
For normal browsing it works just fine however I noticed that CPU
consumption is very high > 50%
Anyone having better experience with Chromium + HW accleration support on
iMX6 ?

Best regards,

On Tue, Nov 28, 2017 at 1:52 AM, Ian Coolidge 
wrote:

> I'm not sure this build has been tested on Pyro. I'd use Rocko or master
> when building this chromium.
>
> I've built this on Rocko on the imx6 just fine. Granted it doesn't work
> properly right now for me, but it built fine.
>
> On Thu, Nov 23, 2017 at 2:22 AM, Ayoub Zaki 
> wrote:
>
>> Hello all,
>>
>> I'm trying to build from the latest commit meta-browser:
>> a8bb1e779bc3565beacceadc4414816670f33475 with an imx6 using yocto pyro
>> branch with meta-freescale, however the build fails :
>>
>>  [460/30779] touch obj/chrome/browser/search/loca
>> l_ntp_code_generate.stamp
>> | [461/30779] touch obj/chrome/browser/search/generated.stamp
>> | [462/30779] python
>> ../../mojo/public/tools/bindings/generate_type_mappings.py --output
>> gen/chrome/browser/ui/webui/omnibox/mojo_bindings__type_mappings
>> | [463/30779] touch
>> obj/chrome/browser/ui/webui/omnibox/mojo_bindings__type_mappings.stamp
>> | [464/30779] touch obj/chrome/browser/chrome_inte
>> rnal_resources_gen.stamp
>> | [465/30779] touch obj/chrome/browser/theme_properties.stamp
>> | [466/30779] python ../../chrome/browser/resources/vulcanize_gn.py
>> --host
>> bookmarks --input ../../chrome/browser/resources/md_bookmarks
>> --out_folder
>> gen/chrome/browser/resources/md_bookmarks --depfile
>> gen/chrome/browser/resources/md_bookmarks/build.d --html_in_files
>> bookmarks.html --html_out_files vulcanized.html --js_out_files crisper.js
>> | FAILED: gen/chrome/browser/resources/md_bookmarks/vulcanized.html
>> gen/chrome/browser/resources/md_bookmarks/crisper.js
>> | python ../../chrome/browser/resources/vulcanize_gn.py --host bookmarks
>> --input ../../chrome/browser/resources/md_bookmarks --out_folder
>> gen/chrome/browser/resources/md_bookmarks --depfile
>> gen/chrome/browser/resources/md_bookmarks/build.d --html_in_files
>> bookmarks.html --html_out_files vulcanized.html --js_out_files crisper.js
>> | ../../third_party/node/linux/node-linux-x64/bin/node
>> ../../third_party/node/node_modules/polymer-bundler/lib/bin/
>> polymer-bundler
>> --exclude chrome://resources/html/polymer.html --exclude
>> chrome://resources/polymer/v1_0/polymer/polymer.html --exclude
>> chrome://resources/polymer/v1_0/polymer/polymer-micro.html --exclude
>> chrome://resources/polymer/v1_0/polymer/polymer-mini.html --exclude
>> chrome://resources/polymer/v1_0/web-animations-js/web-animat
>> ions-next-lite.min.js
>> --exclude chrome://resources/css/roboto.css --exclude
>> chrome://resources/css/text_defaults.css --exclude
>> chrome://resources/css/text_defaults_md.css --exclude
>> chrome://resources/js/load_time_data.js --inline-css --inline-scripts
>> --rewrite-urls-in-templates --strip-comments --redirect
>> "chrome://resources/cr_components/|../../ui/webui/resources/
>> cr_components"
>> --redirect
>> "chrome://resources/cr_elements/|../../ui/webui/resources/cr_elements"
>> --redirect "chrome://resources/css/|../../ui/webui/resources/css"
>> --redirect "chrome://resources/html/|../../ui/webui/resources/html"
>> --redirect "chrome://resources/js/|../../ui/webui/resources/js"
>> --redirect
>> "chrome://resources/polymer/v1_0/|../../third_party/polymer/
>> v1_0/components-chromium"
>> --exclude strings.js --exclude chrome://bookmarks/strings.js
>> --manifest-out
>> /opt/yocto/pyro/build/tmp/work/armv7ahf-neon-imx-beld-linux-
>> gnueabi/chromium/62.0.3202.94-r0/chromium-62.0.3202.94/out/
>> Release/gen/chrome/browser/resources/md_bookmarks/
>> bookmarks_requestlist.txt
>> --root
>> /opt/yocto/pyro/build/tmp/work/armv7ahf-neon-imx-beld-linux-
>> gnueabi/chromium/62.0.3202.94-r0/chromium-62.0.3202.94/
>> chrome/browser/resources/md_bookmarks
>> --redirect
>> "chrome://bookmarks/|/opt/yocto/pyro/build/tmp/work/armv7ahf
>> -neon-imx-beld-linux-gnueabi/chromium/62.0.3202.94-r0/
>> chromium-62.0.3202.94/chrome/browser/resources/md_bookmarks"
>> --out-dir gen/chrome/browser/resources/md_bookmarks/bundled --shell
>> bookmarks.html --in-html bookmarks.html failed:
>> /opt/yocto/pyro/build/tmp/work/armv7ahf-neon-imx-beld-linux-
>> gnueabi/chromium/62.0.3202.94-r0/chromium-62.0.3202.94/
>> third_party/node/node_modules/polymer-bundler/lib/bin/
>> polymer-bundler.js:178
>> | const [prefix, path] = redirect.split('|');
>> |   ^
>> |
>> | SyntaxError: Unexpected token [
>> | at exports.runInThisContext 

Re: [oe] [meta-browser] CFT: Chromium 62 in meta-browser

[Ian Coolidge]

I'm not sure this build has been tested on Pyro. I'd use Rocko or master
when building this chromium.

I've built this on Rocko on the imx6 just fine. Granted it doesn't work
properly right now for me, but it built fine.

On Thu, Nov 23, 2017 at 2:22 AM, Ayoub Zaki 
wrote:

> Hello all,
>
> I'm trying to build from the latest commit meta-browser:
> a8bb1e779bc3565beacceadc4414816670f33475 with an imx6 using yocto pyro
> branch with meta-freescale, however the build fails :
>
>  [460/30779] touch obj/chrome/browser/search/local_ntp_code_generate.stamp
> | [461/30779] touch obj/chrome/browser/search/generated.stamp
> | [462/30779] python
> ../../mojo/public/tools/bindings/generate_type_mappings.py --output
> gen/chrome/browser/ui/webui/omnibox/mojo_bindings__type_mappings
> | [463/30779] touch
> obj/chrome/browser/ui/webui/omnibox/mojo_bindings__type_mappings.stamp
> | [464/30779] touch obj/chrome/browser/chrome_internal_resources_gen.stamp
> | [465/30779] touch obj/chrome/browser/theme_properties.stamp
> | [466/30779] python ../../chrome/browser/resources/vulcanize_gn.py --host
> bookmarks --input ../../chrome/browser/resources/md_bookmarks --out_folder
> gen/chrome/browser/resources/md_bookmarks --depfile
> gen/chrome/browser/resources/md_bookmarks/build.d --html_in_files
> bookmarks.html --html_out_files vulcanized.html --js_out_files crisper.js
> | FAILED: gen/chrome/browser/resources/md_bookmarks/vulcanized.html
> gen/chrome/browser/resources/md_bookmarks/crisper.js
> | python ../../chrome/browser/resources/vulcanize_gn.py --host bookmarks
> --input ../../chrome/browser/resources/md_bookmarks --out_folder
> gen/chrome/browser/resources/md_bookmarks --depfile
> gen/chrome/browser/resources/md_bookmarks/build.d --html_in_files
> bookmarks.html --html_out_files vulcanized.html --js_out_files crisper.js
> | ../../third_party/node/linux/node-linux-x64/bin/node
> ../../third_party/node/node_modules/polymer-bundler/lib/
> bin/polymer-bundler
> --exclude chrome://resources/html/polymer.html --exclude
> chrome://resources/polymer/v1_0/polymer/polymer.html --exclude
> chrome://resources/polymer/v1_0/polymer/polymer-micro.html --exclude
> chrome://resources/polymer/v1_0/polymer/polymer-mini.html --exclude
> chrome://resources/polymer/v1_0/web-animations-js/web-
> animations-next-lite.min.js
> --exclude chrome://resources/css/roboto.css --exclude
> chrome://resources/css/text_defaults.css --exclude
> chrome://resources/css/text_defaults_md.css --exclude
> chrome://resources/js/load_time_data.js --inline-css --inline-scripts
> --rewrite-urls-in-templates --strip-comments --redirect
> "chrome://resources/cr_components/|../../ui/webui/resources/cr_components"
> --redirect
> "chrome://resources/cr_elements/|../../ui/webui/resources/cr_elements"
> --redirect "chrome://resources/css/|../../ui/webui/resources/css"
> --redirect "chrome://resources/html/|../../ui/webui/resources/html"
> --redirect "chrome://resources/js/|../../ui/webui/resources/js" --redirect
> "chrome://resources/polymer/v1_0/|../../third_party/
> polymer/v1_0/components-chromium"
> --exclude strings.js --exclude chrome://bookmarks/strings.js --manifest-out
> /opt/yocto/pyro/build/tmp/work/armv7ahf-neon-imx-beld-
> linux-gnueabi/chromium/62.0.3202.94-r0/chromium-62.0.3202.
> 94/out/Release/gen/chrome/browser/resources/md_bookmarks/bookmarks_
> requestlist.txt
> --root
> /opt/yocto/pyro/build/tmp/work/armv7ahf-neon-imx-beld-
> linux-gnueabi/chromium/62.0.3202.94-r0/chromium-62.0.3202.
> 94/chrome/browser/resources/md_bookmarks
> --redirect
> "chrome://bookmarks/|/opt/yocto/pyro/build/tmp/work/
> armv7ahf-neon-imx-beld-linux-gnueabi/chromium/62.0.3202.94-
> r0/chromium-62.0.3202.94/chrome/browser/resources/md_bookmarks"
> --out-dir gen/chrome/browser/resources/md_bookmarks/bundled --shell
> bookmarks.html --in-html bookmarks.html failed:
> /opt/yocto/pyro/build/tmp/work/armv7ahf-neon-imx-beld-
> linux-gnueabi/chromium/62.0.3202.94-r0/chromium-62.0.3202.
> 94/third_party/node/node_modules/polymer-bundler/lib/
> bin/polymer-bundler.js:178
> | const [prefix, path] = redirect.split('|');
> |   ^
> |
> | SyntaxError: Unexpected token [
> | at exports.runInThisContext (vm.js:53:16)
> | at Module._compile (module.js:373:25)
> | at Object.Module._extensions..js (module.js:416:10)
> | at Module.load (module.js:343:32)
> | at Function.Module._load (module.js:300:12)
> | at Function.Module.runMain (module.js:441:10)
> | at startup (node.js:140:18)
> | at node.js:1043:3
> |
> | Traceback (most recent call last):
> |   File "../../chrome/browser/resources/vulcanize_gn.py", line 252, in
> 
> | main(sys.argv[1:])
> |   File "../../chrome/browser/resources/vulcanize_gn.py", line 235, in
> main
> | manifest_out_path = _vulcanize(args.input, args)
> |   File "../../chrome/browser/resources/vulcanize_gn.py", line 159, in
> _vulcanize
> | ] + in_html_args)
> |   File 

Re: [oe] [meta-browser] CFT: Chromium 62 in meta-browser

[Ayoub Zaki]

Hello all,

I'm trying to build from the latest commit meta-browser:
a8bb1e779bc3565beacceadc4414816670f33475 with an imx6 using yocto pyro
branch with meta-freescale, however the build fails :

 [460/30779] touch obj/chrome/browser/search/local_ntp_code_generate.stamp
| [461/30779] touch obj/chrome/browser/search/generated.stamp
| [462/30779] python
../../mojo/public/tools/bindings/generate_type_mappings.py --output
gen/chrome/browser/ui/webui/omnibox/mojo_bindings__type_mappings
| [463/30779] touch
obj/chrome/browser/ui/webui/omnibox/mojo_bindings__type_mappings.stamp
| [464/30779] touch obj/chrome/browser/chrome_internal_resources_gen.stamp
| [465/30779] touch obj/chrome/browser/theme_properties.stamp
| [466/30779] python ../../chrome/browser/resources/vulcanize_gn.py --host
bookmarks --input ../../chrome/browser/resources/md_bookmarks --out_folder
gen/chrome/browser/resources/md_bookmarks --depfile
gen/chrome/browser/resources/md_bookmarks/build.d --html_in_files
bookmarks.html --html_out_files vulcanized.html --js_out_files crisper.js
| FAILED: gen/chrome/browser/resources/md_bookmarks/vulcanized.html
gen/chrome/browser/resources/md_bookmarks/crisper.js
| python ../../chrome/browser/resources/vulcanize_gn.py --host bookmarks
--input ../../chrome/browser/resources/md_bookmarks --out_folder
gen/chrome/browser/resources/md_bookmarks --depfile
gen/chrome/browser/resources/md_bookmarks/build.d --html_in_files
bookmarks.html --html_out_files vulcanized.html --js_out_files crisper.js
| ../../third_party/node/linux/node-linux-x64/bin/node
../../third_party/node/node_modules/polymer-bundler/lib/bin/polymer-bundler
--exclude chrome://resources/html/polymer.html --exclude
chrome://resources/polymer/v1_0/polymer/polymer.html --exclude
chrome://resources/polymer/v1_0/polymer/polymer-micro.html --exclude
chrome://resources/polymer/v1_0/polymer/polymer-mini.html --exclude
chrome://resources/polymer/v1_0/web-animations-js/web-animations-next-lite.min.js
--exclude chrome://resources/css/roboto.css --exclude
chrome://resources/css/text_defaults.css --exclude
chrome://resources/css/text_defaults_md.css --exclude
chrome://resources/js/load_time_data.js --inline-css --inline-scripts
--rewrite-urls-in-templates --strip-comments --redirect
"chrome://resources/cr_components/|../../ui/webui/resources/cr_components"
--redirect
"chrome://resources/cr_elements/|../../ui/webui/resources/cr_elements"
--redirect "chrome://resources/css/|../../ui/webui/resources/css"
--redirect "chrome://resources/html/|../../ui/webui/resources/html"
--redirect "chrome://resources/js/|../../ui/webui/resources/js" --redirect
"chrome://resources/polymer/v1_0/|../../third_party/polymer/v1_0/components-chromium"
--exclude strings.js --exclude chrome://bookmarks/strings.js --manifest-out
/opt/yocto/pyro/build/tmp/work/armv7ahf-neon-imx-beld-linux-gnueabi/chromium/62.0.3202.94-r0/chromium-62.0.3202.94/out/Release/gen/chrome/browser/resources/md_bookmarks/bookmarks_requestlist.txt
--root
/opt/yocto/pyro/build/tmp/work/armv7ahf-neon-imx-beld-linux-gnueabi/chromium/62.0.3202.94-r0/chromium-62.0.3202.94/chrome/browser/resources/md_bookmarks
--redirect
"chrome://bookmarks/|/opt/yocto/pyro/build/tmp/work/armv7ahf-neon-imx-beld-linux-gnueabi/chromium/62.0.3202.94-r0/chromium-62.0.3202.94/chrome/browser/resources/md_bookmarks"
--out-dir gen/chrome/browser/resources/md_bookmarks/bundled --shell
bookmarks.html --in-html bookmarks.html failed:
/opt/yocto/pyro/build/tmp/work/armv7ahf-neon-imx-beld-linux-gnueabi/chromium/62.0.3202.94-r0/chromium-62.0.3202.94/third_party/node/node_modules/polymer-bundler/lib/bin/polymer-bundler.js:178
| const [prefix, path] = redirect.split('|');
|   ^
|
| SyntaxError: Unexpected token [
| at exports.runInThisContext (vm.js:53:16)
| at Module._compile (module.js:373:25)
| at Object.Module._extensions..js (module.js:416:10)
| at Module.load (module.js:343:32)
| at Function.Module._load (module.js:300:12)
| at Function.Module.runMain (module.js:441:10)
| at startup (node.js:140:18)
| at node.js:1043:3
|
| Traceback (most recent call last):
|   File "../../chrome/browser/resources/vulcanize_gn.py", line 252, in

| main(sys.argv[1:])
|   File "../../chrome/browser/resources/vulcanize_gn.py", line 235, in main
| manifest_out_path = _vulcanize(args.input, args)
|   File "../../chrome/browser/resources/vulcanize_gn.py", line 159, in
_vulcanize
| ] + in_html_args)
|   File "../../third_party/node/node.py", line 28, in RunNode
| raise
| TypeError: exceptions must be old-style classes or derived from
BaseException, not NoneType
| [467/30779] python ../../chrome/browser/resources/vulcanize_gn.py --host
downloads --input ../../chrome/browser/resources/md_downloads --out_folder
gen/chrome/browser/resources/md_downloads --depfile
gen/chrome/browser/resources/md_downloads/build.d --html_in_files
downloads.html --html_out_files vulcanized.html --js_out_files crisper.js

Re: [oe] [meta-browser] CFT: Chromium 62 in meta-browser

[Khem Raj]

>> As for musl: like I said in my original email and on GitHub, the musl
>> build is currently broken. Carrying tons of patches in the recipe is an
>> uphill battle, so unless someone takes the time to work with upstream I
>> don't think it makes much sense to try to keep the build working.
>

musl is relatively newer and support for various components may not be upstream
but it is getting there. There is no alternative than to carry patches
as of now.
and keep forward porting them as the versions advance. We may never get all
of them upstreamed as is the case with many other large packages.

> OK, fair enough, maybe Khem will again chime in and fix it for musl (in
> the meantime we might blacklist it for musl that people don't wait for
> the build to fail).

The patches needs to be redone mostly. Its ok to blacklist it from now.
I wish someone besides me would have cared too.
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-browser] CFT: Chromium 62 in meta-browser

[Kubo Da Costa, Raphael]

On Wed, 2017-11-15 at 18:41 +0100, Martin Jansa wrote:
> On Wed, Nov 15, 2017 at 06:08:49PM +0100, Raphael Kubo da Costa
> wrote:
> > Thanks for testing!
> > 
> > Martin Jansa  writes:
> > > Thanks for very good changes.
> > > 
> > > Yesterday I've tried to build this on "bitbake world" servers and
> > > the build
> > > for qemuarm64 failed with:
> > 
> > [...]
> > > longer log in http://errors.yoctoproject.org/Errors/Details/15889
> > > 8/
> > 
> > [...]
> > > I know what linking needs *a lot* of memory, but this server has
> > > 219GB
> > > available and "only" 128GB from it can be taken by tmpfs, so
> > > there should
> > > be still plenty RAM for successful linkage.
> > 
> > It had been a while since I'd last done an aarch64 build. I
> > launched one
> > here and linking failed with relocation errors. I've pushed 4e5abf8
> > ("chromium: Apply -g -> -g1 workaround for aarch64 as well"), which
> > is
> > the same workaround I've been applying for other architectures, and
> > everything went fine.
> 
> With the latest version from you (62.0.3202.94) I also got relocation
> errors instead of the out-of-memory one, see:
> 
> http://errors.yoctoproject.org/Errors/Build/48426/
> 
> I'm trying now with g1 as you suggested.

.94 is still under review on GitHub, but it's what I tested
nonetheless. The relocation error shouldn't happen anymore, please make
sure that commit I mentioned is included in your tests.

> (in the meantime we might blacklist it for musl that people don't
> wait for the build to fail).

Sounds like a plan to me, just let me know if you'd like to do that
yourself, otherwise I'll get around to it tomorrow.
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-browser] CFT: Chromium 62 in meta-browser

[Martin Jansa]

On Wed, Nov 15, 2017 at 06:08:49PM +0100, Raphael Kubo da Costa wrote:
> Thanks for testing!
> 
> Martin Jansa  writes:
> > Thanks for very good changes.
> >
> > Yesterday I've tried to build this on "bitbake world" servers and the build
> > for qemuarm64 failed with:
> [...]
> > longer log in http://errors.yoctoproject.org/Errors/Details/158898/
> [...]
> > I know what linking needs *a lot* of memory, but this server has 219GB
> > available and "only" 128GB from it can be taken by tmpfs, so there should
> > be still plenty RAM for successful linkage.
> 
> It had been a while since I'd last done an aarch64 build. I launched one
> here and linking failed with relocation errors. I've pushed 4e5abf8
> ("chromium: Apply -g -> -g1 workaround for aarch64 as well"), which is
> the same workaround I've been applying for other architectures, and
> everything went fine.

With the latest version from you (62.0.3202.94) I also got relocation
errors instead of the out-of-memory one, see:

http://errors.yoctoproject.org/Errors/Build/48426/

I'm trying now with g1 as you suggested.

> 
> > Build for x86_64 (on similar server) was successful.
> >
> > Build for x86 + musl failed even before start, because there is missing
> > space in the append:
> > recipes-browser/chromium/chromium_62.0.3202.89.bb:DEPENDS_append_x86 =
> > "yasm-native"
> > recipes-browser/chromium/chromium_62.0.3202.89.bb:DEPENDS_append_x86-64 =
> > "yasm-native"
> >
> > and unlike x86_64 it doesn't have trailing space in previous DEPENDS,
> > because of:
> > recipes-browser/chromium/chromium_62.0.3202.89.bb:DEPENDS_append_libc-musl
> > = " libexecinfo"
> >
> > Causing:
> > ERROR: Nothing PROVIDES 'libexecinfoyasm-native' (but
> > /home/jenkins/oe/world/shr-core/meta-browser/recipes-browser/chromium/
> > chromium_62.0.3202.89.bb DEPENDS on or otherwise requires it). Close
> > matches:
> >   libxinerama-native
> >   texinfo-native
> >   libyaml-native
> 
> Thanks for fixing the yasm bit.
> 
> As for musl: like I said in my original email and on GitHub, the musl
> build is currently broken. Carrying tons of patches in the recipe is an
> uphill battle, so unless someone takes the time to work with upstream I
> don't think it makes much sense to try to keep the build working.

OK, fair enough, maybe Khem will again chime in and fix it for musl (in
the meantime we might blacklist it for musl that people don't wait for
the build to fail).

-- 
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com


signature.asc
Description: Digital signature
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-browser] CFT: Chromium 62 in meta-browser

[Raphael Kubo da Costa]

Thanks for testing!

Martin Jansa  writes:
> Thanks for very good changes.
>
> Yesterday I've tried to build this on "bitbake world" servers and the build
> for qemuarm64 failed with:
[...]
> longer log in http://errors.yoctoproject.org/Errors/Details/158898/
[...]
> I know what linking needs *a lot* of memory, but this server has 219GB
> available and "only" 128GB from it can be taken by tmpfs, so there should
> be still plenty RAM for successful linkage.

It had been a while since I'd last done an aarch64 build. I launched one
here and linking failed with relocation errors. I've pushed 4e5abf8
("chromium: Apply -g -> -g1 workaround for aarch64 as well"), which is
the same workaround I've been applying for other architectures, and
everything went fine.

> Build for x86_64 (on similar server) was successful.
>
> Build for x86 + musl failed even before start, because there is missing
> space in the append:
> recipes-browser/chromium/chromium_62.0.3202.89.bb:DEPENDS_append_x86 =
> "yasm-native"
> recipes-browser/chromium/chromium_62.0.3202.89.bb:DEPENDS_append_x86-64 =
> "yasm-native"
>
> and unlike x86_64 it doesn't have trailing space in previous DEPENDS,
> because of:
> recipes-browser/chromium/chromium_62.0.3202.89.bb:DEPENDS_append_libc-musl
> = " libexecinfo"
>
> Causing:
> ERROR: Nothing PROVIDES 'libexecinfoyasm-native' (but
> /home/jenkins/oe/world/shr-core/meta-browser/recipes-browser/chromium/
> chromium_62.0.3202.89.bb DEPENDS on or otherwise requires it). Close
> matches:
>   libxinerama-native
>   texinfo-native
>   libyaml-native

Thanks for fixing the yasm bit.

As for musl: like I said in my original email and on GitHub, the musl
build is currently broken. Carrying tons of patches in the recipe is an
uphill battle, so unless someone takes the time to work with upstream I
don't think it makes much sense to try to keep the build working.
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-browser] CFT: Chromium 62 in meta-browser

[Martin Jansa]

With the DEPENDS fix applied it still fails to build with musl:

http://errors.yoctoproject.org/Errors/Build/48408/
| In file included from ../../third_party/ffmpeg/libavutil/autorename_
libavutil_cpu.c:2:0:
| ../../third_party/ffmpeg/libavutil/cpu.c:42:10: fatal error:
sys/sysctl.h: No such file or directory
|  #include 
|   ^~
| compilation terminated.

I'm doing local qemuarm64 build now to see what happens before that out of
memory crash.


On Wed, Nov 15, 2017 at 1:38 PM, Martin Jansa 
wrote:

> Thanks for very good changes.
>
> Yesterday I've tried to build this on "bitbake world" servers and the
> build for qemuarm64 failed with:
>
> | [30609/30609] python "../../build/toolchain/gcc_link_wrapper.py"
> --output="./chrome" -- aarch64-oe-linux-g++  -fstack-protector-strong
> -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security
> --sysroot=/home/jenkins/oe/world/shr-core/tmp-glibc/work/
> aarch64-oe-linux/chromium/62.0.3202.89-r0/recipe-sysroot -pie
> -Wl,--fatal-warnings -Wl,--build-id=sha1 -fPIC -Wl,-z,noexecstack
> -Wl,-z,now -Wl,-z,relro -Wl,-z,defs -Wl,--no-as-needed -lpthread
> -Wl,--as-needed -fuse-ld=gold -B -Wl,--icf=all -Wl,-O1 -Wl,--gc-sections
> -Wl,-rpath-link=. -Wl,--disable-new-dtags -Wl,--export-dynamic -Wl,-O1
> -Wl,--hash-style=gnu -Wl,--as-needed -fstack-protector-strong
> -Wl,-z,relro,-z,now -o "./chrome" -Wl,--start-group @"./chrome.rsp"
> -Wl,--end-group   -ldl -lpthread -lrt -lpangocairo-1.0 -lpango-1.0
> -lgobject-2.0 -lglib-2.0 -lcairo -lX11 -lX11-xcb -lxcb -lXcomposite
> -lXcursor -lXdamage -lXext -lXfixes -lXi -lXrender -lXtst -lgmodule-2.0
> -lgthread-2.0 -lsmime3 -lnss3 -lsoftokn3 -lnssutil3 -lplds4 -lplc4 -lnspr4
> -lxml2 -lexpat -lfontconfig -ldbus-1 -latomic -lXss -lfreetype -ljpeg
> -lwebp -lwebpdemux -lwebpmux -lXrandr -lresolv -lgio-2.0 -lpci -lasound -lm
> -lz -latk-1.0 -lFLAC -lgtk-3 -lgdk-3 -lcairo-gobject -lgdk_pixbuf-2.0 -lxslt
> | FAILED: chrome
> | python "../../build/toolchain/gcc_link_wrapper.py" --output="./chrome"
> -- aarch64-oe-linux-g++  -fstack-protector-strong  -D_FORTIFY_SOURCE=2
> -Wformat -Wformat-security -Werror=format-security
> --sysroot=/home/jenkins/oe/world/shr-core/tmp-glibc/work/
> aarch64-oe-linux/chromium/62.0.3202.89-r0/recipe-sysroot -pie
> -Wl,--fatal-warnings -Wl,--build-id=sha1 -fPIC -Wl,-z,noexecstack
> -Wl,-z,now -Wl,-z,relro -Wl,-z,defs -Wl,--no-as-needed -lpthread
> -Wl,--as-needed -fuse-ld=gold -B -Wl,--icf=all -Wl,-O1 -Wl,--gc-sections
> -Wl,-rpath-link=. -Wl,--disable-new-dtags -Wl,--export-dynamic -Wl,-O1
> -Wl,--hash-style=gnu -Wl,--as-needed -fstack-protector-strong
> -Wl,-z,relro,-z,now -o "./chrome" -Wl,--start-group @"./chrome.rsp"
> -Wl,--end-group   -ldl -lpthread -lrt -lpangocairo-1.0 -lpango-1.0
> -lgobject-2.0 -lglib-2.0 -lcairo -lX11 -lX11-xcb -lxcb -lXcomposite
> -lXcursor -lXdamage -lXext -lXfixes -lXi -lXrender -lXtst -lgmodule-2.0
> -lgthread-2.0 -lsmime3 -lnss3 -lsoftokn3 -lnssutil3 -lplds4 -lplc4 -lnspr4
> -lxml2 -lexpat -lfontconfig -ldbus-1 -latomic -lXss -lfreetype -ljpeg
> -lwebp -lwebpdemux -lwebpmux -lXrandr -lresolv -lgio-2.0 -lpci -lasound -lm
> -lz -latk-1.0 -lFLAC -lgtk-3 -lgdk-3 -lcairo-gobject -lgdk_pixbuf-2.0 -lxslt
> | /home/jenkins/oe/world/shr-core/tmp-glibc/work/aarch64-
> oe-linux/chromium/62.0.3202.89-r0/recipe-sysroot-native/
> usr/bin/aarch64-oe-linux/../../libexec/aarch64-oe-linux/gcc/
> aarch64-oe-linux/7.2.0/ld.gold: out of memory
> | collect2: error: ld returned 1 exit status
> | ninja: build stopped: subcommand failed.
>
> longer log in http://errors.yoctoproject.org/Errors/Details/158898/
>
> I know what linking needs *a lot* of memory, but this server has 219GB
> available and "only" 128GB from it can be taken by tmpfs, so there should
> be still plenty RAM for successful linkage.
>
> Build for x86_64 (on similar server) was successful.
>
> Build for x86 + musl failed even before start, because there is missing
> space in the append:
> recipes-browser/chromium/chromium_62.0.3202.89.bb:DEPENDS_append_x86 =
> "yasm-native"
> recipes-browser/chromium/chromium_62.0.3202.89.bb:DEPENDS_append_x86-64 =
> "yasm-native"
>
> and unlike x86_64 it doesn't have trailing space in previous DEPENDS,
> because of:
> recipes-browser/chromium/chromium_62.0.3202.89.bb:DEPENDS_append_libc-musl
> = " libexecinfo"
>
> Causing:
> ERROR: Nothing PROVIDES 'libexecinfoyasm-native' (but
> /home/jenkins/oe/world/shr-core/meta-browser/recipes-browser/chromium/
> chromium_62.0.3202.89.bb DEPENDS on or otherwise requires it). Close
> matches:
>   libxinerama-native
>   texinfo-native
>   libyaml-native
>
> I'll fix that missing space, but any other ideas why it might fail with
> out of memory? Are you building for aarch64 as well?
>
> Regards,
>
>
>
> On Wed, Nov 15, 2017 at 1:04 PM, Raphael Kubo da Costa <
> raphael.kubo.da.co...@intel.com> wrote:
>
>> Raphael Kubo da Costa  writes:
>> > I believe this has finally 

Re: [oe] [meta-browser] CFT: Chromium 62 in meta-browser

[Martin Jansa]

Thanks for very good changes.

Yesterday I've tried to build this on "bitbake world" servers and the build
for qemuarm64 failed with:

| [30609/30609] python "../../build/toolchain/gcc_link_wrapper.py"
--output="./chrome" -- aarch64-oe-linux-g++  -fstack-protector-strong
-D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security
--sysroot=/home/jenkins/oe/world/shr-core/tmp-glibc/work/aarch64-oe-linux/chromium/62.0.3202.89-r0/recipe-sysroot
-pie -Wl,--fatal-warnings -Wl,--build-id=sha1 -fPIC -Wl,-z,noexecstack
-Wl,-z,now -Wl,-z,relro -Wl,-z,defs -Wl,--no-as-needed -lpthread
-Wl,--as-needed -fuse-ld=gold -B -Wl,--icf=all -Wl,-O1 -Wl,--gc-sections
-Wl,-rpath-link=. -Wl,--disable-new-dtags -Wl,--export-dynamic -Wl,-O1
-Wl,--hash-style=gnu -Wl,--as-needed -fstack-protector-strong
-Wl,-z,relro,-z,now -o "./chrome" -Wl,--start-group @"./chrome.rsp"
-Wl,--end-group   -ldl -lpthread -lrt -lpangocairo-1.0 -lpango-1.0
-lgobject-2.0 -lglib-2.0 -lcairo -lX11 -lX11-xcb -lxcb -lXcomposite
-lXcursor -lXdamage -lXext -lXfixes -lXi -lXrender -lXtst -lgmodule-2.0
-lgthread-2.0 -lsmime3 -lnss3 -lsoftokn3 -lnssutil3 -lplds4 -lplc4 -lnspr4
-lxml2 -lexpat -lfontconfig -ldbus-1 -latomic -lXss -lfreetype -ljpeg
-lwebp -lwebpdemux -lwebpmux -lXrandr -lresolv -lgio-2.0 -lpci -lasound -lm
-lz -latk-1.0 -lFLAC -lgtk-3 -lgdk-3 -lcairo-gobject -lgdk_pixbuf-2.0 -lxslt
| FAILED: chrome
| python "../../build/toolchain/gcc_link_wrapper.py" --output="./chrome" --
aarch64-oe-linux-g++  -fstack-protector-strong  -D_FORTIFY_SOURCE=2
-Wformat -Wformat-security -Werror=format-security
--sysroot=/home/jenkins/oe/world/shr-core/tmp-glibc/work/aarch64-oe-linux/chromium/62.0.3202.89-r0/recipe-sysroot
-pie -Wl,--fatal-warnings -Wl,--build-id=sha1 -fPIC -Wl,-z,noexecstack
-Wl,-z,now -Wl,-z,relro -Wl,-z,defs -Wl,--no-as-needed -lpthread
-Wl,--as-needed -fuse-ld=gold -B -Wl,--icf=all -Wl,-O1 -Wl,--gc-sections
-Wl,-rpath-link=. -Wl,--disable-new-dtags -Wl,--export-dynamic -Wl,-O1
-Wl,--hash-style=gnu -Wl,--as-needed -fstack-protector-strong
-Wl,-z,relro,-z,now -o "./chrome" -Wl,--start-group @"./chrome.rsp"
-Wl,--end-group   -ldl -lpthread -lrt -lpangocairo-1.0 -lpango-1.0
-lgobject-2.0 -lglib-2.0 -lcairo -lX11 -lX11-xcb -lxcb -lXcomposite
-lXcursor -lXdamage -lXext -lXfixes -lXi -lXrender -lXtst -lgmodule-2.0
-lgthread-2.0 -lsmime3 -lnss3 -lsoftokn3 -lnssutil3 -lplds4 -lplc4 -lnspr4
-lxml2 -lexpat -lfontconfig -ldbus-1 -latomic -lXss -lfreetype -ljpeg
-lwebp -lwebpdemux -lwebpmux -lXrandr -lresolv -lgio-2.0 -lpci -lasound -lm
-lz -latk-1.0 -lFLAC -lgtk-3 -lgdk-3 -lcairo-gobject -lgdk_pixbuf-2.0 -lxslt
|
/home/jenkins/oe/world/shr-core/tmp-glibc/work/aarch64-oe-linux/chromium/62.0.3202.89-r0/recipe-sysroot-native/usr/bin/aarch64-oe-linux/../../libexec/aarch64-oe-linux/gcc/aarch64-oe-linux/7.2.0/ld.gold:
out of memory
| collect2: error: ld returned 1 exit status
| ninja: build stopped: subcommand failed.

longer log in http://errors.yoctoproject.org/Errors/Details/158898/

I know what linking needs *a lot* of memory, but this server has 219GB
available and "only" 128GB from it can be taken by tmpfs, so there should
be still plenty RAM for successful linkage.

Build for x86_64 (on similar server) was successful.

Build for x86 + musl failed even before start, because there is missing
space in the append:
recipes-browser/chromium/chromium_62.0.3202.89.bb:DEPENDS_append_x86 =
"yasm-native"
recipes-browser/chromium/chromium_62.0.3202.89.bb:DEPENDS_append_x86-64 =
"yasm-native"

and unlike x86_64 it doesn't have trailing space in previous DEPENDS,
because of:
recipes-browser/chromium/chromium_62.0.3202.89.bb:DEPENDS_append_libc-musl
= " libexecinfo"

Causing:
ERROR: Nothing PROVIDES 'libexecinfoyasm-native' (but
/home/jenkins/oe/world/shr-core/meta-browser/recipes-browser/chromium/
chromium_62.0.3202.89.bb DEPENDS on or otherwise requires it). Close
matches:
  libxinerama-native
  texinfo-native
  libyaml-native

I'll fix that missing space, but any other ideas why it might fail with out
of memory? Are you building for aarch64 as well?

Regards,



On Wed, Nov 15, 2017 at 1:04 PM, Raphael Kubo da Costa <
raphael.kubo.da.co...@intel.com> wrote:

> Raphael Kubo da Costa  writes:
> > I believe this has finally reached a stage where it's ready for public
> > consumption, hence the CFT:
> >
> > https://github.com/rakuco/meta-browser/tree/chromium62
> >
> > I'd like people to look at my commits and let me know if there's any big
> > issue that would prevent those changes from landing into meta-browser.
> > If everything's OK, I'd then start sending the patches to the list (or
> > pull requests on GitHub, whichever is preferred).
>
> Thanks to everyone who chimed in on GitHub and Otavio for merging my
> pull requests.
>
> We now have Chromium 62 in meta-browser, and I intend to keep the recipe
> up-to-date from now on.
> --
> ___
> Openembedded-devel mailing list
> 

Re: [oe] [meta-browser] CFT: Chromium 62 in meta-browser

[Raphael Kubo da Costa]

Raphael Kubo da Costa  writes:
> I believe this has finally reached a stage where it's ready for public
> consumption, hence the CFT:
>
> https://github.com/rakuco/meta-browser/tree/chromium62
>
> I'd like people to look at my commits and let me know if there's any big
> issue that would prevent those changes from landing into meta-browser.
> If everything's OK, I'd then start sending the patches to the list (or
> pull requests on GitHub, whichever is preferred).

Thanks to everyone who chimed in on GitHub and Otavio for merging my
pull requests.

We now have Chromium 62 in meta-browser, and I intend to keep the recipe
up-to-date from now on.
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-browser] CFT: Chromium 62 in meta-browser

[Ian Coolidge]

Nevermind, found it. I'll test that.

On Mon, Nov 13, 2017 at 1:51 PM, Ian Coolidge 
wrote:

> Where is this commit? I don't see 568227133be3f9f015679df3525f6c4f86304fd0
> in meta-browser?
>
> On Sat, Nov 11, 2017 at 9:25 AM, Otavio Salvador <
> otavio.salva...@ossystems.com.br> wrote:
>
>> On Fri, Nov 10, 2017 at 10:10 PM, Ian Coolidge 
>> wrote:
>> ...
>> > Are there any obvious flags or compile options I'm missing here? I
>> haven't
>> > tied debugging into this yet, which is my next step here. Just wanted to
>> > know if I was missing something obvious.
>>
>> Maybe this fixes it?
>>
>> commit 568227133be3f9f015679df3525f6c4f86304fd0
>> Author: Khem Raj 
>> Date:   Tue Nov 7 15:26:52 2017 -0800
>>
>> gcc7/gcc6: Fix unaligned STRD issue on ARM
>>
>> Backport
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82445
>>
>> Fixes [YOCTO 12297]
>>
>> Signed-off-by: Khem Raj 
>> Signed-off-by: Ross Burton 
>>
>> Please check if it helps you, otherwise please open a github issue so
>> we can keep track of it.
>>
>> --
>> Otavio Salvador O.S. Systems
>> http://www.ossystems.com.brhttp://code.ossystems.com.br
>> Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
>>
>
>
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-browser] CFT: Chromium 62 in meta-browser

[Ian Coolidge]

Where is this commit? I don't see 568227133be3f9f015679df3525f6c4f86304fd0
in meta-browser?

On Sat, Nov 11, 2017 at 9:25 AM, Otavio Salvador <
otavio.salva...@ossystems.com.br> wrote:

> On Fri, Nov 10, 2017 at 10:10 PM, Ian Coolidge 
> wrote:
> ...
> > Are there any obvious flags or compile options I'm missing here? I
> haven't
> > tied debugging into this yet, which is my next step here. Just wanted to
> > know if I was missing something obvious.
>
> Maybe this fixes it?
>
> commit 568227133be3f9f015679df3525f6c4f86304fd0
> Author: Khem Raj 
> Date:   Tue Nov 7 15:26:52 2017 -0800
>
> gcc7/gcc6: Fix unaligned STRD issue on ARM
>
> Backport
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82445
>
> Fixes [YOCTO 12297]
>
> Signed-off-by: Khem Raj 
> Signed-off-by: Ross Burton 
>
> Please check if it helps you, otherwise please open a github issue so
> we can keep track of it.
>
> --
> Otavio Salvador O.S. Systems
> http://www.ossystems.com.brhttp://code.ossystems.com.br
> Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
>
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-browser] CFT: Chromium 62 in meta-browser

[Otavio Salvador]

On Fri, Nov 10, 2017 at 10:10 PM, Ian Coolidge  wrote:
...
> Are there any obvious flags or compile options I'm missing here? I haven't
> tied debugging into this yet, which is my next step here. Just wanted to
> know if I was missing something obvious.

Maybe this fixes it?

commit 568227133be3f9f015679df3525f6c4f86304fd0
Author: Khem Raj 
Date:   Tue Nov 7 15:26:52 2017 -0800

gcc7/gcc6: Fix unaligned STRD issue on ARM

Backport
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82445

Fixes [YOCTO 12297]

Signed-off-by: Khem Raj 
Signed-off-by: Ross Burton 

Please check if it helps you, otherwise please open a github issue so
we can keep track of it.

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-browser] CFT: Chromium 62 in meta-browser

[Ian Coolidge]

Hi All,

For what it's worth, I built this chromium62 for the nitrogen6x and I'm
getting Alignment traps when loading webpages.

Are there any obvious flags or compile options I'm missing here? I haven't
tied debugging into this yet, which is my next step here. Just wanted to
know if I was missing something obvious.

Thanks!
-Ian Coolidge

On Fri, Nov 10, 2017 at 11:49 AM, Trevor Woerner  wrote:

> Raphael,
>
> On Thu, Nov 9, 2017 at 11:28 AM, Raphael Kubo da Costa
>  wrote:
> > There are 60 new commits in my "chromium62" branch
>
> This work is utterly *brilliant*! BRAVO! Thanks so much for sticking with
> it.
>
> > Possibly controversial issues:
> > - The ozone-wayland recipe has been removed (this is actually commit
> >   #1). The ozone-wayland project Intel used to maintain has not been
> >   maintained in a very long time, and it is impossible to just get it to
> >   work with Chromium 62. I'd also rather not keep Chromium 53 around
> >   just because of it due to A) increased maintenance costs 2) we'd be
> >   shipping an ancient Chromium release with tons of security issues.
>
> No issues from me. Originally there was only one recipe that included
> both wayland and x11 support together. I had proposed, then done the
> work, to separate them out into two recipes because keeping them in
> sync wasn't working. If nobody is keeping ozone-wayland working, it
> doesn't work, and/or it's not being worked on upstream, then I have no
> issues with it being removed. Just to be clear: if somebody finds it
> useful and wants to support it, I'd be happy to see it come back. But
> at this point it appears to be dead and I don't think it's worth
> blacklisting.
>
> > - musl support is currently broken. I've sent a few patches upstream
> >   lately and added a few musl-related changes to the Chromium 62 recipe,
> >   but getting the code to build requires a lot of time and
> >   determination, and if we don't have someone actively working with
> >   upstream it's just going to be an uphill battle that I am not willing
> >   to take upon myself.
>
> I'll have to defer to Khem on this one. As I've said before, I
> strongly don't believe meta-browser (or any other layer other than
> meta-musl) is the right place for musl support. Musl support should be
> in meta-musl and not spread throughout the ecosystem for everyone else
> to worry about. But I don't get the feeling that I "won" this
> discussion in the past... ;-)
>
> > - The 'ignore-lost-context' PACKAGECONFIG knob was removed. The patch
> >   it required no longer applies cleanly, its context refers a 5-year-old
> >   discussion and it is not clear if it is still necessary at all.
>
> This seems fine to me. If anyone still wants to use the
> --gpu-no-context-lost cmdline argument (or any other cmdline argument,
> for that matter) without the patch, they can simply add it to the
> chromium-wrapper.
>
> > - In the future, I'd like to revisit the other PACKAGECONFIG knobs as
> >   well. In particular, it is not clear to me if 'impl-side-painting' and
> >   'use-egl' are still needed at all,
>
> Sounds good.
>
> > and I'd like to drop
> >   'component-build' to simplify the recipe and prevent anyone from using
> >   this option in production.
>
> Yes! And if you wanted to remove DEBUG_BUILD too, I'd be okay with
> that as well. I'm confused as to the status of DEBUG_BUILD, it seems
> to be removed, but you're setting debug flags?
> --
> ___
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
>
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-browser] CFT: Chromium 62 in meta-browser

[Trevor Woerner]

Raphael,

On Thu, Nov 9, 2017 at 11:28 AM, Raphael Kubo da Costa
 wrote:
> There are 60 new commits in my "chromium62" branch

This work is utterly *brilliant*! BRAVO! Thanks so much for sticking with it.

> Possibly controversial issues:
> - The ozone-wayland recipe has been removed (this is actually commit
>   #1). The ozone-wayland project Intel used to maintain has not been
>   maintained in a very long time, and it is impossible to just get it to
>   work with Chromium 62. I'd also rather not keep Chromium 53 around
>   just because of it due to A) increased maintenance costs 2) we'd be
>   shipping an ancient Chromium release with tons of security issues.

No issues from me. Originally there was only one recipe that included
both wayland and x11 support together. I had proposed, then done the
work, to separate them out into two recipes because keeping them in
sync wasn't working. If nobody is keeping ozone-wayland working, it
doesn't work, and/or it's not being worked on upstream, then I have no
issues with it being removed. Just to be clear: if somebody finds it
useful and wants to support it, I'd be happy to see it come back. But
at this point it appears to be dead and I don't think it's worth
blacklisting.

> - musl support is currently broken. I've sent a few patches upstream
>   lately and added a few musl-related changes to the Chromium 62 recipe,
>   but getting the code to build requires a lot of time and
>   determination, and if we don't have someone actively working with
>   upstream it's just going to be an uphill battle that I am not willing
>   to take upon myself.

I'll have to defer to Khem on this one. As I've said before, I
strongly don't believe meta-browser (or any other layer other than
meta-musl) is the right place for musl support. Musl support should be
in meta-musl and not spread throughout the ecosystem for everyone else
to worry about. But I don't get the feeling that I "won" this
discussion in the past... ;-)

> - The 'ignore-lost-context' PACKAGECONFIG knob was removed. The patch
>   it required no longer applies cleanly, its context refers a 5-year-old
>   discussion and it is not clear if it is still necessary at all.

This seems fine to me. If anyone still wants to use the
--gpu-no-context-lost cmdline argument (or any other cmdline argument,
for that matter) without the patch, they can simply add it to the
chromium-wrapper.

> - In the future, I'd like to revisit the other PACKAGECONFIG knobs as
>   well. In particular, it is not clear to me if 'impl-side-painting' and
>   'use-egl' are still needed at all,

Sounds good.

> and I'd like to drop
>   'component-build' to simplify the recipe and prevent anyone from using
>   this option in production.

Yes! And if you wanted to remove DEBUG_BUILD too, I'd be okay with
that as well. I'm confused as to the status of DEBUG_BUILD, it seems
to be removed, but you're setting debug flags?
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-browser] CFT: Chromium 62 in meta-browser

[Raphael Kubo da Costa]

Hey Otavio, thanks for the quick response!

Otavio Salvador  writes:
> Hello Raphael,
>
>> I'd like people to look at my commits and let me know if there's any big
>> issue that would prevent those changes from landing into meta-browser.
>> If everything's OK, I'd then start sending the patches to the list (or
>> pull requests on GitHub, whichever is preferred).
>
> I went through all the commits, one by one. There are few that might
> need minor adjustments (as for example the removal of cups support
> which should be moved to a PACKAGECONFIG) but in general, they are all
> good. You did a great job making it very granular and well documented
> :-)
>
> I think this is huge enough that using a pull request so we can track
> comments and progress makes sense. Do you mind creating one?
>
> I think we will end picking individual commits on the beginning to
> reduce the delta and keep going until we have the bump done. Do you
> think it is a good way to handle this?

I think that works, and it matches what I originally had in mind:
* Get people to look at the existing commits and raise any objections to
  any major "architectural" issues with the changes.
* Once everyone's on the same page, start sending patches in chunks
  (e.g. all dependency changes in one pull request).
* Once the clean-ups and bug fixes are in, send the big PRs (move to GN
  and update to M62).

I'll start splitting that branch into smaller ones for PRs, but I'll
also wait a little bit for others (such as Jacobo, Trevor and Khem) to
chime in as well.

The only bummer is that I'll be on holidays from 17th November to 8th
December so it may take a little longer than usual for me to get all the
changes landed.
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-browser] CFT: Chromium 62 in meta-browser

[Otavio Salvador]

Hello Raphael,

On Thu, Nov 9, 2017 at 2:28 PM, Raphael Kubo da Costa
 wrote:
> Like I said back in September, I'd like to merge the Chromium recipe
> I've been maintaining independently [1] since last year into the
> meta-browser layer so that more people can both benefit from it as well
> as help maintain it. Currently, the meta-browser recipe is still
> tracking Chromium 54 and ozone-wayland with Chromium 53, whereas my
> recipe tracks the latest stable releases (it's currently at
> 62.0.3202.89).

First, I'd like to thank you for all this amazing work. Chromium is
indeed a giant project and its proper integration has some specific
challenges by itself...

...
> I'd like people to look at my commits and let me know if there's any big
> issue that would prevent those changes from landing into meta-browser.
> If everything's OK, I'd then start sending the patches to the list (or
> pull requests on GitHub, whichever is preferred).

I went through all the commits, one by one. There are few that might
need minor adjustments (as for example the removal of cups support
which should be moved to a PACKAGECONFIG) but in general, they are all
good. You did a great job making it very granular and well documented
:-)

I think this is huge enough that using a pull request so we can track
comments and progress makes sense. Do you mind creating one?

I think we will end picking individual commits on the beginning to
reduce the delta and keep going until we have the bump done. Do you
think it is a good way to handle this?

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-browser] Modern Chromium with GN

[Raphael Kubo da Costa]

Trevor Woerner  writes:

> I was able to successfully build for the minnow board (x86_64), but
> when I tried building for the 32-bit variant for raspberrypi3 I got:
>
> | install: cannot stat 'swiftshader/libEGL.so': No such file or directory
>
> during the do_install step for chromium itself. Odd, I thought egl
> came from mesa? (but then again I thought OE built its own
> gcc-native... :-S

Thanks for spotting that, I've fixed it in commit de21170 ("chromium:
Install SwiftShader only when building for Intel architectures"). I've
now checked the M62 build on pyro with GCC 5.4.0 and
MACHINE="raspberrypi3".

As for the EGL question: as far as I know, the SwiftShader stuff [1] is
a CPU-based OpenGL implementation that's used when hardware acceleration
is not available.

[1] https://github.com/google/swiftshader
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-browser] Modern Chromium with GN

[Jacobo Aragunde Pérez]

On 27/10/17 17:44, Trevor Woerner wrote:
> ...
> I was able to successfully build for the minnow board (x86_64), but
> when I tried building for the 32-bit variant for raspberrypi3 I got:
> 
> | install: cannot stat 'swiftshader/libEGL.so': No such file or directory
> 
> during the do_install step for chromium itself. Odd, I thought egl
> came from mesa? (but then again I thought OE built its own
> gcc-native... :-S
> 

Raphael added the swiftshader libs in this commit, which explains nicely
what they are for:

https://github.com/rakuco/meta-crosswalk/commit/924103037857e6b9e8348d67381ea09cfbf975e3

I was able to build arm32 images for the Pi3 before this commit. I guess
swiftshader is not built on arm?

Best,
-- 
Jacobo Aragunde
Software Engineer at Igalia
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-browser] Modern Chromium with GN

[Daniel Mack]

On Friday, October 27, 2017 11:19 AM, Jacobo Aragunde Pérez wrote:
> On 27/10/17 10:49, Daniel Mack wrote:
>>
>> I'd like to give Chromium 62 a shot on arm64, but the recipes currently
>> only support x11, is that correct? My platform is based on wayland, any
>> plans on supporting that?
>>
> 
> The problem is that upstream Chromium does not support Wayland natively
> yet. There is a fork under development to implement this support, which
> is quite advanced now: https://github.com/Igalia/chromium
> 
> Patches from the fork will start pouring into upstream Chromium shortly.
> 

I see, thanks for explaining. I'll wait for these upstream patches and
your recipes to land then!


Thanks,
Daniel
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-browser] Modern Chromium with GN

[Trevor Woerner]

On Mon, Oct 23, 2017 at 9:33 AM, Raphael Kubo da Costa
 wrote:
> Otavio Salvador  writes:
   | g++ -MMD -MF base/base_paths.o.d
   | 
 -I/z/chromium/crosswalk/build/tmp-glibc/work/x86_64-linux/gn-native/62.0.3202.62-r0/chromium-62.0.3202.62/out_bootstrap/gen
   | 
 -I/z/chromium/crosswalk/build/tmp-glibc/work/x86_64-linux/gn-native/62.0.3202.62-r0/chromium-62.0.3202.62
   | 
 -isystem/z/chromium/crosswalk/build/tmp-glibc/work/x86_64-linux/gn-native/62.0.3202.62-r0/recipe-sysroot-native/usr/include
   | -O2 -pipe -DNO_TCMALLOC -D__STDC_FORMAT_MACROS -O2 -g0
   | -D_FILE_OFFSET_BITS=64 -D__STDC_CONSTANT_MACROS
   | -D__STDC_FORMAT_MACROS -pthread -pipe -fno-exceptions
   | 
 -isystem/z/chromium/crosswalk/build/tmp-glibc/work/x86_64-linux/gn-native/62.0.3202.62-r0/recipe-sysroot-native/usr/include
   | -O2 -pipe -std=c++14 -Wno-c++11-narrowing -c
   | 
 /z/chromium/crosswalk/build/tmp-glibc/work/x86_64-linux/gn-native/62.0.3202.62-r0/chromium-62.0.3202.62/base/base_paths.cc
   | -o base/base_paths.o
   | g++: error: unrecognized command line option ‘-std=c++14’
>>>
>>> Ouch :( That's a new kind of issue I was not expecting.
>>
>> It needs to check if c++14 is really needed for GN to work. Better
>> would it depends on gn-native and it to be handled elsewhere.
>
> While this specific issue is in GN, I expect it to happen during the
> Chromium build as well, as some tools are built and run on the host
> machine.
>
> Even if GN specifically does not depend on C++14 now, working around
> that is an uphill battle, as the Chromium project requires a C++14
> compiler and multiple parts of the code base will start using C++14
> features (or already are).

Ouch for sure! For some strange reason I was under the impression OE
builds created a native gcc for things like this! Oh well, I was able
to sort out the native compiler issue on my openSUSE 42.2 system; the
default gcc is 4.8, but there are packages for gcc5 and gcc6 so I just
installed the gcc6 one and used update-alternatives. It works, but it
will lead to some interesting questions wrt support and basic OE
support for openSUSE (however, that'll be a different discussion for
another day and probably for another mailing list).

I was able to successfully build for the minnow board (x86_64), but
when I tried building for the 32-bit variant for raspberrypi3 I got:

| install: cannot stat 'swiftshader/libEGL.so': No such file or directory

during the do_install step for chromium itself. Odd, I thought egl
came from mesa? (but then again I thought OE built its own
gcc-native... :-S
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-browser] Modern Chromium with GN

[Jacobo Aragunde Pérez]

On 27/10/17 10:49, Daniel Mack wrote:
> 
> I'd like to give Chromium 62 a shot on arm64, but the recipes currently
> only support x11, is that correct? My platform is based on wayland, any
> plans on supporting that?
> 

The problem is that upstream Chromium does not support Wayland natively
yet. There is a fork under development to implement this support, which
is quite advanced now: https://github.com/Igalia/chromium

Patches from the fork will start pouring into upstream Chromium shortly.

-- 
Jacobo Aragunde
Software Engineer at Igalia
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-browser] Modern Chromium with GN

[Daniel Mack]

Hi,

On Wednesday, October 11, 2017 05:00 PM, Raphael Kubo da Costa wrote:
> Trevor Woerner  writes:
>> Hi Raphael,
>>
>> On Tue, Oct 10, 2017 at 3:10 PM, Kubo Da Costa, Raphael
>>  wrote:
>>> On Tue, 2017-10-10 at 14:28 -0400, Trevor Woerner wrote:
>>> I've pushed commit a0db280 to my chromium61 branch; that one allowed me
>>> to get to the end of the build without any other issues. Let me know if
>>> that's enough to get master working for you.
>>
>> Excellent! Yes, this update works for me against master :-)
>>
>> Has anyone started trying to integrate this with meta-browser?
> 
> That's the next part of my plan, I hope to get around to it this week.

I'd like to give Chromium 62 a shot on arm64, but the recipes currently
only support x11, is that correct? My platform is based on wayland, any
plans on supporting that?


Thanks,
Daniel
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-browser] Modern Chromium with GN

[Raphael Kubo da Costa]

Otavio Salvador  writes:
>>>   | g++ -MMD -MF base/base_paths.o.d
>>>   | 
>>> -I/z/chromium/crosswalk/build/tmp-glibc/work/x86_64-linux/gn-native/62.0.3202.62-r0/chromium-62.0.3202.62/out_bootstrap/gen
>>>   | 
>>> -I/z/chromium/crosswalk/build/tmp-glibc/work/x86_64-linux/gn-native/62.0.3202.62-r0/chromium-62.0.3202.62
>>>   | 
>>> -isystem/z/chromium/crosswalk/build/tmp-glibc/work/x86_64-linux/gn-native/62.0.3202.62-r0/recipe-sysroot-native/usr/include
>>>   | -O2 -pipe -DNO_TCMALLOC -D__STDC_FORMAT_MACROS -O2 -g0
>>>   | -D_FILE_OFFSET_BITS=64 -D__STDC_CONSTANT_MACROS
>>>   | -D__STDC_FORMAT_MACROS -pthread -pipe -fno-exceptions
>>>   | 
>>> -isystem/z/chromium/crosswalk/build/tmp-glibc/work/x86_64-linux/gn-native/62.0.3202.62-r0/recipe-sysroot-native/usr/include
>>>   | -O2 -pipe -std=c++14 -Wno-c++11-narrowing -c
>>>   | 
>>> /z/chromium/crosswalk/build/tmp-glibc/work/x86_64-linux/gn-native/62.0.3202.62-r0/chromium-62.0.3202.62/base/base_paths.cc
>>>   | -o base/base_paths.o
>>>   | g++: error: unrecognized command line option ‘-std=c++14’
>>
>> Ouch :( That's a new kind of issue I was not expecting.
>
> It needs to check if c++14 is really needed for GN to work. Better
> would it depends on gn-native and it to be handled elsewhere.

While this specific issue is in GN, I expect it to happen during the
Chromium build as well, as some tools are built and run on the host
machine.

Even if GN specifically does not depend on C++14 now, working around
that is an uphill battle, as the Chromium project requires a C++14
compiler and multiple parts of the code base will start using C++14
features (or already are).

>>> [...]
>>
>>> Is there any way to intercept these calls and have it call OE's gcc-native
>>> instead?
>>
>> Do you have an example of that being done in another recipe?
>
> Hard. We don't build a native compiler.
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-browser] Modern Chromium with GN

[Otavio Salvador]

On Mon, Oct 23, 2017 at 9:06 AM, Raphael Kubo da Costa
 wrote:
> Trevor Woerner  writes:
>
>> On Thu 2017-10-19 @ 06:24:11 PM, Raphael Kubo da Costa wrote:
>>> Raphael Kubo da Costa  writes:
>>> > Work on Chromium 62 has started, but updating is a bit slower now that
>>> > I'm trying to test GCC 5, 7, pyro and rocko.
>>>
>>> I've pushed a new branch called "chromium62". It's been test-built
>>> against Yocto's pyro (with GCC 5) and rocko (with GCC 7) for x86 and
>>> x86-64.
>>>
>>> Additional testing is appreciated!
>>
>> It looks like something in the chromium62 build is calling my native g++ and
>> expecting that this native g++ will be recent enough to support c++14:
>>
>>
>>   | g++ -MMD -MF base/base_paths.o.d
>>   | 
>> -I/z/chromium/crosswalk/build/tmp-glibc/work/x86_64-linux/gn-native/62.0.3202.62-r0/chromium-62.0.3202.62/out_bootstrap/gen
>>   | 
>> -I/z/chromium/crosswalk/build/tmp-glibc/work/x86_64-linux/gn-native/62.0.3202.62-r0/chromium-62.0.3202.62
>>   | 
>> -isystem/z/chromium/crosswalk/build/tmp-glibc/work/x86_64-linux/gn-native/62.0.3202.62-r0/recipe-sysroot-native/usr/include
>>   | -O2 -pipe -DNO_TCMALLOC -D__STDC_FORMAT_MACROS -O2 -g0
>>   | -D_FILE_OFFSET_BITS=64 -D__STDC_CONSTANT_MACROS
>>   | -D__STDC_FORMAT_MACROS -pthread -pipe -fno-exceptions
>>   | 
>> -isystem/z/chromium/crosswalk/build/tmp-glibc/work/x86_64-linux/gn-native/62.0.3202.62-r0/recipe-sysroot-native/usr/include
>>   | -O2 -pipe -std=c++14 -Wno-c++11-narrowing -c
>>   | 
>> /z/chromium/crosswalk/build/tmp-glibc/work/x86_64-linux/gn-native/62.0.3202.62-r0/chromium-62.0.3202.62/base/base_paths.cc
>>   | -o base/base_paths.o
>>   | g++: error: unrecognized command line option ‘-std=c++14’
>
> Ouch :( That's a new kind of issue I was not expecting.

It needs to check if c++14 is really needed for GN to work. Better
would it depends on gn-native and it to be handled elsewhere.

>> [...]
>
>> Is there any way to intercept these calls and have it call OE's gcc-native
>> instead?
>
> Do you have an example of that being done in another recipe?

Hard. We don't build a native compiler.

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-browser] Modern Chromium with GN

[Raphael Kubo da Costa]

Trevor Woerner  writes:

> On Thu 2017-10-19 @ 06:24:11 PM, Raphael Kubo da Costa wrote:
>> Raphael Kubo da Costa  writes:
>> > Work on Chromium 62 has started, but updating is a bit slower now that
>> > I'm trying to test GCC 5, 7, pyro and rocko.
>>
>> I've pushed a new branch called "chromium62". It's been test-built
>> against Yocto's pyro (with GCC 5) and rocko (with GCC 7) for x86 and
>> x86-64.
>>
>> Additional testing is appreciated!
>
> It looks like something in the chromium62 build is calling my native g++ and
> expecting that this native g++ will be recent enough to support c++14:
>
>
>   | g++ -MMD -MF base/base_paths.o.d
>   | 
> -I/z/chromium/crosswalk/build/tmp-glibc/work/x86_64-linux/gn-native/62.0.3202.62-r0/chromium-62.0.3202.62/out_bootstrap/gen
>   | 
> -I/z/chromium/crosswalk/build/tmp-glibc/work/x86_64-linux/gn-native/62.0.3202.62-r0/chromium-62.0.3202.62
>   | 
> -isystem/z/chromium/crosswalk/build/tmp-glibc/work/x86_64-linux/gn-native/62.0.3202.62-r0/recipe-sysroot-native/usr/include
>   | -O2 -pipe -DNO_TCMALLOC -D__STDC_FORMAT_MACROS -O2 -g0
>   | -D_FILE_OFFSET_BITS=64 -D__STDC_CONSTANT_MACROS
>   | -D__STDC_FORMAT_MACROS -pthread -pipe -fno-exceptions
>   | 
> -isystem/z/chromium/crosswalk/build/tmp-glibc/work/x86_64-linux/gn-native/62.0.3202.62-r0/recipe-sysroot-native/usr/include
>   | -O2 -pipe -std=c++14 -Wno-c++11-narrowing -c
>   | 
> /z/chromium/crosswalk/build/tmp-glibc/work/x86_64-linux/gn-native/62.0.3202.62-r0/chromium-62.0.3202.62/base/base_paths.cc
>   | -o base/base_paths.o
>   | g++: error: unrecognized command line option ‘-std=c++14’

Ouch :( That's a new kind of issue I was not expecting.

> [...]

> Is there any way to intercept these calls and have it call OE's gcc-native
> instead?

Do you have an example of that being done in another recipe?
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-browser] Modern Chromium with GN

[Trevor Woerner]

On Thu 2017-10-19 @ 06:24:11 PM, Raphael Kubo da Costa wrote:
> Raphael Kubo da Costa  writes:
> > Work on Chromium 62 has started, but updating is a bit slower now that
> > I'm trying to test GCC 5, 7, pyro and rocko.
> 
> I've pushed a new branch called "chromium62". It's been test-built
> against Yocto's pyro (with GCC 5) and rocko (with GCC 7) for x86 and
> x86-64.
> 
> Additional testing is appreciated!

It looks like something in the chromium62 build is calling my native g++ and
expecting that this native g++ will be recent enough to support c++14:


| g++  -MMD -MF base/base_paths.o.d  
-I/z/chromium/crosswalk/build/tmp-glibc/work/x86_64-linux/gn-native/62.0.3202.62-r0/chromium-62.0.3202.62/out_bootstrap/gen
 
-I/z/chromium/crosswalk/build/tmp-glibc/work/x86_64-linux/gn-native/62.0.3202.62-r0/chromium-62.0.3202.62
 
-isystem/z/chromium/crosswalk/build/tmp-glibc/work/x86_64-linux/gn-native/62.0.3202.62-r0/recipe-sysroot-native/usr/include
 -O2 -pipe -DNO_TCMALLOC -D__STDC_FORMAT_MACROS -O2 -g0 -D_FILE_OFFSET_BITS=64 
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -pthread -pipe -fno-exceptions 
-isystem/z/chromium/crosswalk/build/tmp-glibc/work/x86_64-linux/gn-native/62.0.3202.62-r0/recipe-sysroot-native/usr/include
 -O2 -pipe -std=c++14 -Wno-c++11-narrowing -c 
/z/chromium/crosswalk/build/tmp-glibc/work/x86_64-linux/gn-native/62.0.3202.62-r0/chromium-62.0.3202.62/base/base_paths.cc
 -o base/base_paths.o
| g++: error: unrecognized command line option ‘-std=c++14’


Unfortunately on my openSUSE 42.2 host this isn't the case:

$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/4.8/lto-wrapper
Target: x86_64-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info 
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 
--enable-languages=c,c++,objc,fortran,obj-c++,java,ada 
--enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.8 
--enable-ssp --disable-libssp --disable-plugin 
--with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux' 
--disable-libgcj --disable-libmudflap --with-slibdir=/lib64 --with-system-zlib 
--enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch 
--enable-version-specific-runtime-libs --enable-linker-build-id 
--enable-linux-futex --program-suffix=-4.8 --without-system-libunwind 
--with-arch-32=i586 --with-tune=generic --build=x86_64-suse-linux 
--host=x86_64-suse-linux
Thread model: posix
gcc version 4.8.5 (SUSE Linux)


Is there any way to intercept these calls and have it call OE's gcc-native
instead?
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-browser] Modern Chromium with GN

[Raphael Kubo da Costa]

Raphael Kubo da Costa  writes:
> Work on Chromium 62 has started, but updating is a bit slower now that
> I'm trying to test GCC 5, 7, pyro and rocko.

I've pushed a new branch called "chromium62". It's been test-built
against Yocto's pyro (with GCC 5) and rocko (with GCC 7) for x86 and
x86-64.

Additional testing is appreciated!
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-browser] Modern Chromium with GN

[Raphael Kubo da Costa]

Raphael Kubo da Costa  writes:

> Raphael Kubo da Costa  writes:
>> Can you check if the attached patch also solves the WebRTC build issue
>> for you? I've tried it here with Yocto's morty branch and GCC 5.4.0.
>>
>> If so, I'll send it upstream, as the original approach
>> (https://webrtc-review.googlesource.com/c/src/+/8641) was not accepted
>> by the WebRTC maintainers.
>
> Sorry, I'm attaching patch v2, the original version had an extra,
> unwanted chunk.

I've upstreamed the patch and integrated it into the chromium61 branch.

Work on Chromium 62 has started, but updating is a bit slower now that
I'm trying to test GCC 5, 7, pyro and rocko.
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-browser] Modern Chromium with GN

[Raphael Kubo da Costa]

Raphael Kubo da Costa  writes:
> Can you check if the attached patch also solves the WebRTC build issue
> for you? I've tried it here with Yocto's morty branch and GCC 5.4.0.
>
> If so, I'll send it upstream, as the original approach
> (https://webrtc-review.googlesource.com/c/src/+/8641) was not accepted
> by the WebRTC maintainers.

Sorry, I'm attaching patch v2, the original version had an extra,
unwanted chunk.

--- a/third_party/webrtc/modules/audio_processing/aec3/aec_state.cc	2017-10-16 16:31:47.636478663 +0200
+++ b/third_party/webrtc/modules/audio_processing/aec3/aec_state.cc	2017-10-16 16:31:45.329471819 +0200
@@ -271,9 +271,9 @@
   auto result_x = std::minmax_element(x.begin(), x.end());
   auto result_s = std::minmax_element(s.begin(), s.end());
   const float x_abs =
-  std::max(std::abs(*result_x.first), std::abs(*result_x.second));
+  std::max(fabsf(*result_x.first), fabsf(*result_x.second));
   const float s_abs =
-  std::max(std::abs(*result_s.first), std::abs(*result_s.second));
+  std::max(fabsf(*result_s.first), fabsf(*result_s.second));
 
   if (x_abs < 5.f) {
 ++low_farend_counter_;
@@ -294,7 +294,7 @@
 void AecState::EchoAudibility::UpdateWithOutput(rtc::ArrayView e) {
   const float e_max = *std::max_element(e.begin(), e.end());
   const float e_min = *std::min_element(e.begin(), e.end());
-  const float e_abs = std::max(std::abs(e_max), std::abs(e_min));
+  const float e_abs = std::max(fabsf(e_max), fabsf(e_min));
 
   if (max_nearend_ < e_abs) {
 max_nearend_ = e_abs;
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-browser] Modern Chromium with GN

[Raphael Kubo da Costa]

+oe-devel again

Jacobo Aragunde Pérez  writes:
> On 05/10/17 17:26, Jacobo Aragunde Pérez wrote:
>> Hi everyone,
>>
>> I have several potential patches for Rafael's layer after having tried
>> several builds for different hardware. I'm sending individual mails to
>> discuss each of them.
>>
>
> The second patch is a fix that I needed with a GCC 5.4.0 toolchain. The
> fix looks harmless enough so I sent it upstream (to the webrtc project),
> but I don't know if it will be merged.
>
> I have another couple patches to fix problems that only happen when
> compiling with linaro-5.3, one of them is a backport for the compiler
> itself. I don't think they belong in this layer so I'm finally not
> sending them. Anyway, ask me if you are interested!
>
> All in all, I have created images with Rafael's layer for Raspberry Pi 3
> and R-Car gen 3 with different toolchains: GCC 5.4.0 and 6.3.0 for the
> former, and linaro-5.3 for the latter. Let me know if you want me to do
> any other tests.

Hey Jacobo,

Thanks for all the testing so far!

Can you check if the attached patch also solves the WebRTC build issue
for you? I've tried it here with Yocto's morty branch and GCC 5.4.0.

If so, I'll send it upstream, as the original approach
(https://webrtc-review.googlesource.com/c/src/+/8641) was not accepted
by the WebRTC maintainers.

--- a/third_party/webrtc/modules/audio_processing/aec3/aec_state.cc	2017-10-16 16:31:47.636478663 +0200
+++ b/third_party/webrtc/modules/audio_processing/aec3/aec_state.cc	2017-10-16 16:31:45.329471819 +0200
@@ -157,7 +157,7 @@
   // TODO(peah): Add the delay in this computation to ensure that the render and
   // capture signals are properly aligned.
   RTC_DCHECK_LT(0, x.size());
-  const float max_sample = fabs(*std::max_element(
+  const float max_sample = fabsf(*std::max_element(
   x.begin(), x.end(), [](float a, float b) { return a * a < b * b; }));
   const bool saturated_echo =
   previous_max_sample_ * 100 > 1600 && SaturatedCapture();
@@ -271,9 +271,9 @@
   auto result_x = std::minmax_element(x.begin(), x.end());
   auto result_s = std::minmax_element(s.begin(), s.end());
   const float x_abs =
-  std::max(std::abs(*result_x.first), std::abs(*result_x.second));
+  std::max(fabsf(*result_x.first), fabsf(*result_x.second));
   const float s_abs =
-  std::max(std::abs(*result_s.first), std::abs(*result_s.second));
+  std::max(fabsf(*result_s.first), fabsf(*result_s.second));
 
   if (x_abs < 5.f) {
 ++low_farend_counter_;
@@ -294,7 +294,7 @@
 void AecState::EchoAudibility::UpdateWithOutput(rtc::ArrayView e) {
   const float e_max = *std::max_element(e.begin(), e.end());
   const float e_min = *std::min_element(e.begin(), e.end());
-  const float e_abs = std::max(std::abs(e_max), std::abs(e_min));
+  const float e_abs = std::max(fabsf(e_max), fabsf(e_min));
 
   if (max_nearend_ < e_abs) {
 max_nearend_ = e_abs;
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-browser] Modern Chromium with GN

[Raphael Kubo da Costa]

Trevor Woerner  writes:

> Hi Raphael,
>
> On Tue, Oct 10, 2017 at 3:10 PM, Kubo Da Costa, Raphael
>  wrote:
>> On Tue, 2017-10-10 at 14:28 -0400, Trevor Woerner wrote:
>> I've pushed commit a0db280 to my chromium61 branch; that one allowed me
>> to get to the end of the build without any other issues. Let me know if
>> that's enough to get master working for you.
>
> Excellent! Yes, this update works for me against master :-)
>
> Has anyone started trying to integrate this with meta-browser?

That's the next part of my plan, I hope to get around to it this week.
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-browser] Modern Chromium with GN

[Trevor Woerner]

Hi Raphael,

On Tue, Oct 10, 2017 at 3:10 PM, Kubo Da Costa, Raphael
 wrote:
> On Tue, 2017-10-10 at 14:28 -0400, Trevor Woerner wrote:
> I've pushed commit a0db280 to my chromium61 branch; that one allowed me
> to get to the end of the build without any other issues. Let me know if
> that's enough to get master working for you.

Excellent! Yes, this update works for me against master :-)

Has anyone started trying to integrate this with meta-browser?
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-browser] Modern Chromium with GN

[Kubo Da Costa, Raphael]

On Tue, 2017-10-10 at 14:28 -0400, Trevor Woerner wrote:
> Are either of you working off of (and building against) master?
> 
> My builds against pyro build fine, but I can't build successfully
> against master.
> 
> This is a problem because, by convention, layers accept patches
> against master first, then allow those patches to be backported to
> prior releases. Until this works against master, it'll have a hard
> time landing in meta-browser.

Hey Trevor,

I decided to try out Yocto's rocko branch today, and found the same
problem you described with GCC 7.

I've pushed commit a0db280 to my chromium61 branch; that one allowed me
to get to the end of the build without any other issues. Let me know if
that's enough to get master working for you.
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-browser] Modern Chromium with GN

[Trevor Woerner]

Are either of you working off of (and building against) master?

My builds against pyro build fine, but I can't build successfully
against master.

This is a problem because, by convention, layers accept patches
against master first, then allow those patches to be backported to
prior releases. Until this works against master, it'll have a hard
time landing in meta-browser.


log.do_compile2__qemux86-64__chromium61_master_wtf_swapanchor
Description: Binary data
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-browser] Modern Chromium with GN

[Raphael Kubo da Costa]

Jacobo Aragunde Pérez  writes:
> Hi everyone,
>
> I have several potential patches for Rafael's layer after having tried
> several builds for different hardware. I'm sending individual mails to
> discuss each of them.
>
> The first one is pretty straightforward. It is just a backport of an
> existing upstream chromium patch to fix a compilation error on some GCC
> versions. I've reproduced the error with gcc-linaro-5.3 and gcc-5.4.0
> toolchains, and the patch fixes it. GCC 6 seems not to have any problem
> with the original code but I still think it makes no harm to include the
> patch.
>
> Find the patch attached.

Hey Jacobo,

Sorry for the delay, it took me a couple of days to catch up with
everything after returning from the Hackfest :-)

I've just added some context to the patch and adjusted its name. It's
now in my chromium61 branch as commit 13cdc60.

Thanks!

(P.S.: I haven't given up on the idea of merging my recipe into
meta-browser, I just need to get around to doing it :-)
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-browser] Modern Chromium with GN

[Jacobo Aragunde Pérez]

Hi everyone,

I have several potential patches for Rafael's layer after having tried
several builds for different hardware. I'm sending individual mails to
discuss each of them.

The first one is pretty straightforward. It is just a backport of an
existing upstream chromium patch to fix a compilation error on some GCC
versions. I've reproduced the error with gcc-linaro-5.3 and gcc-5.4.0
toolchains, and the patch fixes it. GCC 6 seems not to have any problem
with the original code but I still think it makes no harm to include the
patch.

Find the patch attached.

Best,
-- 
Jacobo
>From 88a4375bbc5e9bfb81a0573f1f2ec902b8ce23e2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jacobo=20Aragunde=20P=C3=A9rez?= 
Date: Wed, 4 Oct 2017 13:17:40 +0200
Subject: [PATCH] chromium: Backport patch to fix gcc build error

This is a compilation error that doesn't seem to manifest on gcc6 or
clang toolchains, but it affects gcc5 which is used, for example, by
R-Car gen 3 devices.

Patch: https://chromium-review.googlesource.com/645549
---
 recipes-browser/chromium/chromium_61.0.3163.100.bb |  1 +
 ...rename-ArrayBufferContents-AllocationKind.patch | 35 ++
 2 files changed, 36 insertions(+)
 create mode 100644 recipes-browser/chromium/files/rename-ArrayBufferContents-AllocationKind.patch

diff --git a/recipes-browser/chromium/chromium_61.0.3163.100.bb b/recipes-browser/chromium/chromium_61.0.3163.100.bb
index 87f6fdb..4bf1b0d 100644
--- a/recipes-browser/chromium/chromium_61.0.3163.100.bb
+++ b/recipes-browser/chromium/chromium_61.0.3163.100.bb
@@ -13,6 +13,7 @@ SRC_URI += " \
 file://0001-Make-base-numerics-build-with-GCC.patch \
 file://0001-Fix-compilation-for-ATK-accessibility.patch \
 file://0001-Replace-remaining-references-to-struct-ucontext-with.patch \
+file://rename-ArrayBufferContents-AllocationKind.patch \
 ${@bb.utils.contains('PACKAGECONFIG', 'root-profile', 'file://root-user-profile.patch', '', d)} \
 "
 
diff --git a/recipes-browser/chromium/files/rename-ArrayBufferContents-AllocationKind.patch b/recipes-browser/chromium/files/rename-ArrayBufferContents-AllocationKind.patch
new file mode 100644
index 000..f47b54e
--- /dev/null
+++ b/recipes-browser/chromium/files/rename-ArrayBufferContents-AllocationKind.patch
@@ -0,0 +1,35 @@
+From ec0d7abe5c1520464ff0ea2405b2c59d51b0b775 Mon Sep 17 00:00:00 2001
+From: Piotr Tworek 
+Date: Fri, 1 Sep 2017 12:20:03 +
+Subject: [PATCH] Rename ArrayBufferContents::AllocationKind to
+ GetAllocationKind.
+
+Current name clashes with the name of the enum class the function is
+supposed to return. Clang does not care, but gcc fails to compile the
+code.
+
+Bug: 760070
+Change-Id: I935d91493a3fc7b289d03f776c14b6ec4f3f622a
+Reviewed-on: https://chromium-review.googlesource.com/645549
+Reviewed-by: Yuta Kitamura 
+Commit-Queue: Yuta Kitamura 
+Cr-Commit-Position: refs/heads/master@{#499171}
+---
+ .../WebKit/Source/platform/wtf/typed_arrays/ArrayBufferContents.h | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+diff --git a/third_party/WebKit/Source/platform/wtf/typed_arrays/ArrayBufferContents.h b/third_party/WebKit/Source/platform/wtf/typed_arrays/ArrayBufferContents.h
+index 94bb9161ec85..0671c471cbe0 100644
+--- a/third_party/WebKit/Source/platform/wtf/typed_arrays/ArrayBufferContents.h
 b/third_party/WebKit/Source/platform/wtf/typed_arrays/ArrayBufferContents.h
+@@ -122,7 +122,9 @@ class WTF_EXPORT ArrayBufferContents {
+ void* Data() const { return data_; }
+ size_t DataLength() const { return data_length_; }
+ 
+-ArrayBufferContents::AllocationKind AllocationKind() const { return kind_; }
++ArrayBufferContents::AllocationKind GetAllocationKind() const {
++  return kind_;
++}
+ 
+ operator bool() const { return allocation_base_; }
+ 
-- 
2.11.0

-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-browser] Modern Chromium with GN

[Jacobo Aragunde Pérez]

Hi all,

On 05/10/17 02:43, Trevor Woerner wrote:
> Hi Jocobo,
> 
> Please have a look at
> https://github.com/rakuco/meta-crosswalk/tree/chromium61/recipes-browser/chromium
> from Raphael (CCed). It is an interesting and promising approach.
> 

Indeed, I've been in touch with Raphael who has also attended the
hackfest. We have decided to go on with his approach, I will test those
recipes in different hardware and add some missing bits there were
before in meta-browser.

> I have built against minnow (x86-64) and rpi3-32 (armv7ve)
> successfully with pyro. I haven't had time to runtime test anything
> yet. I'm still seeing a build issue with both MACHINEs against master.
> 

I've tested a rpi3-32 image and I've successfully built an armv8 image
for R-Car gen3, which I still have to test. So far I had to add a couple
of backports related with the toolchain they use in Renesas BSPs.

I'll keep you informed of the progress :)

Best,
-- 
Jacobo Aragunde
Software Engineer at Igalia
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-browser] Modern Chromium with GN

[Trevor Woerner]

Hi Jocobo,

Please have a look at
https://github.com/rakuco/meta-crosswalk/tree/chromium61/recipes-browser/chromium
from Raphael (CCed). It is an interesting and promising approach.

I have built against minnow (x86-64) and rpi3-32 (armv7ve)
successfully with pyro. I haven't had time to runtime test anything
yet. I'm still seeing a build issue with both MACHINEs against master.

It's been about two weeks since I've had time to tinker with it.

Best regards,
Trevor
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-browser] Modern Chromium with GN

[Otavio Salvador]

On Mon, Oct 2, 2017 at 12:35 PM, Jacobo Aragunde Pérez
 wrote:
...
> I will send patches as soon as I have something!
...

+1 :-)


-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-browser][PATCH] chromium: Do not enforce gold as default linker

[Martin Jansa]

USEGOLD
or
USE_GOLD
?

On Mon, Jul 10, 2017 at 11:33 PM, Khem Raj  wrote:

> Provide a knob USEGOLD however to enable it if desired
>
> Signed-off-by: Khem Raj 
> Cc: Denys Dmytriyenko 
> ---
>  recipes-browser/chromium/chromium-browser.inc | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/recipes-browser/chromium/chromium-browser.inc
> b/recipes-browser/chromium/chromium-browser.inc
> index 094a3d3..1e4fb1e 100644
> --- a/recipes-browser/chromium/chromium-browser.inc
> +++ b/recipes-browser/chromium/chromium-browser.inc
> @@ -200,7 +200,12 @@ python add_ozone_wayland_patches() {
>  d.appendVar('SRC_URI', ' ' + d.getVar('OZONE_WAYLAND_EXTRA_PATCHES',
> False))
>  }
>
> -USEGOLD ?= "-Dlinux_use_gold_flags=1"
> +# uncomment below or set it in a bbappend if you want to use gold linker
> +# to link chromium irrespective of system linker, gold speeds up linking
> +# chromium ( 8mins to < 2mins on a decent xeon system)
> +#
> +#USEGOLD = "-Dlinux_use_gold_flags=1"
> +USE_GOLD ??= ""
>
>  EXTRA_OEGYP = " \
> -Dangle_use_commit_id=0 \
> --
> 2.13.2
>
> --
> ___
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
>
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-browser] Chromium and gold linker

[Khem Raj]

On 7/10/17 2:09 PM, Denys Dmytriyenko wrote:
> On Mon, Jul 10, 2017 at 02:00:35PM -0700, Khem Raj wrote:
>> On 7/10/17 1:47 PM, Denys Dmytriyenko wrote:
>>> On Mon, Jul 10, 2017 at 04:36:42PM -0400, Denys Dmytriyenko wrote:
 Khem, et al,

 I couldn't find below patch being discussed on this mailing list before it 
 got 
 merged:

 https://github.com/OSSystems/meta-browser/commit/62e323848f569c4cdea5567b1917ce006d7705af
>>>
>>> https://github.com/OSSystems/meta-browser/commit/55a74501bc65c90c86e3236b51ec2dc2fc0145fb
>>>
>>> "ld-is-gold just means that my default linker is gold, however we build
>>> both linkers, so one should be able to enable gold just for linking
>>> chromium even if default ld is bfd linker."
>>>
>>> I strongly disagree with such interpretation - this would mean there's NO 
>>> way 
>>> to disable gold linker completely, e.g. for when external toolchain doesn't 
>>> support it.
> 
> Copying OE architecture list for further discussion of "ld-is-gold" meaning.
> 
> 
>> it is not just interpretation but how it is designed if you look closely
>> to code in oe-core and as a matter of fact, there are certain packages
>> where we enforce one linker or other.
> 
> So far I only seen forcing bfd, as a legacy linker, not the other way around.
> 
> 
>> mere presence or absence of
>> ld-is-gold in distro features does not mean that other linker will not
>> be available. If your distro is making that assumption please correct that.
>>
>> I however agree, that using gold as default linker should have a knob
>> and it so does which is USEGOLD, if a distro or toolchain layer does not
>> want to use gold then they could set this variable to be off.
>>
>> USEGOLD = "" or USEGOLD = "-Dlinux_use_gold_flags=0"
> 
> Yes, I saw this variable and already added it to my bbappend. But the issue 
> is 
> that it's per-recipe, not global. Do we need a separate distro-level flag to 
> avoid any and all gold linker references?

Leave aside the meaning for a moment, I think its convenient to use it
this way, I am not too hell bent for enforcing gold as default, so I
will send a patch to not default to gold. The flag is useful only when
bfd linker is system default and one just want to link chromium with
gold for various
reasons, they can set it explicitly in their own setups. We however will
have the mechanism to do so without making gold the system linker.

> 
> 
>> I think its better to use gold linker for linking chromium since it
>> reduced the link time for chrome quite significantly (8 mins to 2min) on
>> my experiments. But I am fine if other users think that we should not
>> make gold as default.  I can send a patch to toggle the USEGOLD switch
>>
>>>
 According to the layer README, openembedded-devel is the official mailing 
 list 
 to submit patches. I understand that github pull request is a nice 
 shortcut, 
 but it prevents others from seeing and commenting on the patches...


 My issue with this change is that it makes an assumption of using OE-built 
 toolchain. It now breaks external toolchains like this:
>>
>> No it does not make assumption. See above.
>>

 | [17/20569] LINK genmacro
 | FAILED: genmacro
 | gcc  -L/opt/linaro-2016.11/arm-linux-gnueabihf/lib 
 -Wl,-rpath-link,/opt/linaro-2016.11/arm-linux-gnueabihf/lib -Wl,-O1 
 -Wl,--hash-style=gnu -Wl,-z,now -Wl,-z,relro -Wl,-z,defs -pthread 
 -Wl,-z,noexecstack -fPIC -fuse-ld=gold -Wl,--disable-new-dtags -Wl,-O1 
 -Wl,--as-needed -Wl,--gc-sections -Wl,--no-as-needed -lpthread 
 -Wl,--as-needed -o genmacro -Wl,--start-group 
 obj.host/third_party/yasm/source/patched-yasm/tools/genmacro/genmacro.genmacro.o
  -Wl,--end-group
 | /usr/bin/ld.gold: fatal error: 
 /opt/linaro-2016.11/arm-linux-gnueabihf/lib/libgcc_s.so.1: unsupported ELF 
 machine number 40
 | collect2: error: ld returned 1 exit status
 | [18/20569] LINK genstring
 | FAILED: genstring
 | gcc  -L/opt/linaro-2016.11/arm-linux-gnueabihf/lib 
 -Wl,-rpath-link,/opt/linaro-2016.11/arm-linux-gnueabihf/lib -Wl,-O1 
 -Wl,--hash-style=gnu -Wl,-z,now -Wl,-z,relro -Wl,-z,defs -pthread 
 -Wl,-z,noexecstack -fPIC -fuse-ld=gold -Wl,--disable-new-dtags -Wl,-O1 
 -Wl,--as-needed -Wl,--gc-sections -Wl,--no-as-needed -lpthread 
 -Wl,--as-needed -o genstring -Wl,--start-group 
 obj.host/third_party/yasm/source/patched-yasm/genstring.genstring.o 
 -Wl,--end-group
 | /usr/bin/ld.gold: fatal error: 
 /opt/linaro-2016.11/arm-linux-gnueabihf/lib/libgcc_s.so.1: unsupported ELF 
 machine number 40
 | collect2: error: ld returned 1 exit status

 -- 
 Denys
 -- 
 ___
 Openembedded-devel mailing list
 Openembedded-devel@lists.openembedded.org
 http://lists.openembedded.org/mailman/listinfo/openembedded-devel
>>
>>
> 
> 
> 




signature.asc
Description: OpenPGP 

Re: [oe] [meta-browser] Chromium and gold linker

[Denys Dmytriyenko]

On Mon, Jul 10, 2017 at 02:00:35PM -0700, Khem Raj wrote:
> On 7/10/17 1:47 PM, Denys Dmytriyenko wrote:
> > On Mon, Jul 10, 2017 at 04:36:42PM -0400, Denys Dmytriyenko wrote:
> >> Khem, et al,
> >>
> >> I couldn't find below patch being discussed on this mailing list before it 
> >> got 
> >> merged:
> >>
> >> https://github.com/OSSystems/meta-browser/commit/62e323848f569c4cdea5567b1917ce006d7705af
> > 
> > https://github.com/OSSystems/meta-browser/commit/55a74501bc65c90c86e3236b51ec2dc2fc0145fb
> > 
> > "ld-is-gold just means that my default linker is gold, however we build
> > both linkers, so one should be able to enable gold just for linking
> > chromium even if default ld is bfd linker."
> > 
> > I strongly disagree with such interpretation - this would mean there's NO 
> > way 
> > to disable gold linker completely, e.g. for when external toolchain doesn't 
> > support it.

Copying OE architecture list for further discussion of "ld-is-gold" meaning.


> it is not just interpretation but how it is designed if you look closely
> to code in oe-core and as a matter of fact, there are certain packages
> where we enforce one linker or other.

So far I only seen forcing bfd, as a legacy linker, not the other way around.


> mere presence or absence of
> ld-is-gold in distro features does not mean that other linker will not
> be available. If your distro is making that assumption please correct that.
> 
> I however agree, that using gold as default linker should have a knob
> and it so does which is USEGOLD, if a distro or toolchain layer does not
> want to use gold then they could set this variable to be off.
> 
> USEGOLD = "" or USEGOLD = "-Dlinux_use_gold_flags=0"

Yes, I saw this variable and already added it to my bbappend. But the issue is 
that it's per-recipe, not global. Do we need a separate distro-level flag to 
avoid any and all gold linker references?


> I think its better to use gold linker for linking chromium since it
> reduced the link time for chrome quite significantly (8 mins to 2min) on
> my experiments. But I am fine if other users think that we should not
> make gold as default.  I can send a patch to toggle the USEGOLD switch
> 
> > 
> >> According to the layer README, openembedded-devel is the official mailing 
> >> list 
> >> to submit patches. I understand that github pull request is a nice 
> >> shortcut, 
> >> but it prevents others from seeing and commenting on the patches...
> >>
> >>
> >> My issue with this change is that it makes an assumption of using OE-built 
> >> toolchain. It now breaks external toolchains like this:
> 
> No it does not make assumption. See above.
> 
> >>
> >> | [17/20569] LINK genmacro
> >> | FAILED: genmacro
> >> | gcc  -L/opt/linaro-2016.11/arm-linux-gnueabihf/lib 
> >> -Wl,-rpath-link,/opt/linaro-2016.11/arm-linux-gnueabihf/lib -Wl,-O1 
> >> -Wl,--hash-style=gnu -Wl,-z,now -Wl,-z,relro -Wl,-z,defs -pthread 
> >> -Wl,-z,noexecstack -fPIC -fuse-ld=gold -Wl,--disable-new-dtags -Wl,-O1 
> >> -Wl,--as-needed -Wl,--gc-sections -Wl,--no-as-needed -lpthread 
> >> -Wl,--as-needed -o genmacro -Wl,--start-group 
> >> obj.host/third_party/yasm/source/patched-yasm/tools/genmacro/genmacro.genmacro.o
> >>  -Wl,--end-group
> >> | /usr/bin/ld.gold: fatal error: 
> >> /opt/linaro-2016.11/arm-linux-gnueabihf/lib/libgcc_s.so.1: unsupported ELF 
> >> machine number 40
> >> | collect2: error: ld returned 1 exit status
> >> | [18/20569] LINK genstring
> >> | FAILED: genstring
> >> | gcc  -L/opt/linaro-2016.11/arm-linux-gnueabihf/lib 
> >> -Wl,-rpath-link,/opt/linaro-2016.11/arm-linux-gnueabihf/lib -Wl,-O1 
> >> -Wl,--hash-style=gnu -Wl,-z,now -Wl,-z,relro -Wl,-z,defs -pthread 
> >> -Wl,-z,noexecstack -fPIC -fuse-ld=gold -Wl,--disable-new-dtags -Wl,-O1 
> >> -Wl,--as-needed -Wl,--gc-sections -Wl,--no-as-needed -lpthread 
> >> -Wl,--as-needed -o genstring -Wl,--start-group 
> >> obj.host/third_party/yasm/source/patched-yasm/genstring.genstring.o 
> >> -Wl,--end-group
> >> | /usr/bin/ld.gold: fatal error: 
> >> /opt/linaro-2016.11/arm-linux-gnueabihf/lib/libgcc_s.so.1: unsupported ELF 
> >> machine number 40
> >> | collect2: error: ld returned 1 exit status
> >>
> >> -- 
> >> Denys
> >> -- 
> >> ___
> >> Openembedded-devel mailing list
> >> Openembedded-devel@lists.openembedded.org
> >> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
> 
> 



-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-browser] Chromium and gold linker

[Khem Raj]

On 7/10/17 1:47 PM, Denys Dmytriyenko wrote:
> On Mon, Jul 10, 2017 at 04:36:42PM -0400, Denys Dmytriyenko wrote:
>> Khem, et al,
>>
>> I couldn't find below patch being discussed on this mailing list before it 
>> got 
>> merged:
>>
>> https://github.com/OSSystems/meta-browser/commit/62e323848f569c4cdea5567b1917ce006d7705af
> 
> https://github.com/OSSystems/meta-browser/commit/55a74501bc65c90c86e3236b51ec2dc2fc0145fb
> 
> "ld-is-gold just means that my default linker is gold, however we build
> both linkers, so one should be able to enable gold just for linking
> chromium even if default ld is bfd linker."
> 
> I strongly disagree with such interpretation - this would mean there's NO way 
> to disable gold linker completely, e.g. for when external toolchain doesn't 
> support it.
> 

it is not just interpretation but how it is designed if you look closely
to code in oe-core and as a matter of fact, there are certain packages
where we enforce one linker or other. mere presence or absence of
ld-is-gold in distro features does not mean that other linker will not
be available. If your distro is making that assumption please correct that.

I however agree, that using gold as default linker should have a knob
and it so does which is USEGOLD, if a distro or toolchain layer does not
want to use gold then they could set this variable to be off.

USEGOLD = "" or USEGOLD = "-Dlinux_use_gold_flags=0"


I think its better to use gold linker for linking chromium since it
reduced the link time for chrome quite significantly (8 mins to 2min) on
my experiments. But I am fine if other users think that we should not
make gold as default.  I can send a patch to toggle the USEGOLD switch

> 
>> According to the layer README, openembedded-devel is the official mailing 
>> list 
>> to submit patches. I understand that github pull request is a nice shortcut, 
>> but it prevents others from seeing and commenting on the patches...
>>
>>
>> My issue with this change is that it makes an assumption of using OE-built 
>> toolchain. It now breaks external toolchains like this:

No it does not make assumption. See above.

>>
>> | [17/20569] LINK genmacro
>> | FAILED: genmacro
>> | gcc  -L/opt/linaro-2016.11/arm-linux-gnueabihf/lib 
>> -Wl,-rpath-link,/opt/linaro-2016.11/arm-linux-gnueabihf/lib -Wl,-O1 
>> -Wl,--hash-style=gnu -Wl,-z,now -Wl,-z,relro -Wl,-z,defs -pthread 
>> -Wl,-z,noexecstack -fPIC -fuse-ld=gold -Wl,--disable-new-dtags -Wl,-O1 
>> -Wl,--as-needed -Wl,--gc-sections -Wl,--no-as-needed -lpthread 
>> -Wl,--as-needed -o genmacro -Wl,--start-group 
>> obj.host/third_party/yasm/source/patched-yasm/tools/genmacro/genmacro.genmacro.o
>>  -Wl,--end-group
>> | /usr/bin/ld.gold: fatal error: 
>> /opt/linaro-2016.11/arm-linux-gnueabihf/lib/libgcc_s.so.1: unsupported ELF 
>> machine number 40
>> | collect2: error: ld returned 1 exit status
>> | [18/20569] LINK genstring
>> | FAILED: genstring
>> | gcc  -L/opt/linaro-2016.11/arm-linux-gnueabihf/lib 
>> -Wl,-rpath-link,/opt/linaro-2016.11/arm-linux-gnueabihf/lib -Wl,-O1 
>> -Wl,--hash-style=gnu -Wl,-z,now -Wl,-z,relro -Wl,-z,defs -pthread 
>> -Wl,-z,noexecstack -fPIC -fuse-ld=gold -Wl,--disable-new-dtags -Wl,-O1 
>> -Wl,--as-needed -Wl,--gc-sections -Wl,--no-as-needed -lpthread 
>> -Wl,--as-needed -o genstring -Wl,--start-group 
>> obj.host/third_party/yasm/source/patched-yasm/genstring.genstring.o 
>> -Wl,--end-group
>> | /usr/bin/ld.gold: fatal error: 
>> /opt/linaro-2016.11/arm-linux-gnueabihf/lib/libgcc_s.so.1: unsupported ELF 
>> machine number 40
>> | collect2: error: ld returned 1 exit status
>>
>> -- 
>> Denys
>> -- 
>> ___
>> Openembedded-devel mailing list
>> Openembedded-devel@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-devel




signature.asc
Description: OpenPGP digital signature
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-browser] Chromium and gold linker

[Denys Dmytriyenko]

On Mon, Jul 10, 2017 at 04:36:42PM -0400, Denys Dmytriyenko wrote:
> Khem, et al,
> 
> I couldn't find below patch being discussed on this mailing list before it 
> got 
> merged:
> 
> https://github.com/OSSystems/meta-browser/commit/62e323848f569c4cdea5567b1917ce006d7705af

https://github.com/OSSystems/meta-browser/commit/55a74501bc65c90c86e3236b51ec2dc2fc0145fb

"ld-is-gold just means that my default linker is gold, however we build
both linkers, so one should be able to enable gold just for linking
chromium even if default ld is bfd linker."

I strongly disagree with such interpretation - this would mean there's NO way 
to disable gold linker completely, e.g. for when external toolchain doesn't 
support it.


> According to the layer README, openembedded-devel is the official mailing 
> list 
> to submit patches. I understand that github pull request is a nice shortcut, 
> but it prevents others from seeing and commenting on the patches...
> 
> 
> My issue with this change is that it makes an assumption of using OE-built 
> toolchain. It now breaks external toolchains like this:
> 
> | [17/20569] LINK genmacro
> | FAILED: genmacro
> | gcc  -L/opt/linaro-2016.11/arm-linux-gnueabihf/lib 
> -Wl,-rpath-link,/opt/linaro-2016.11/arm-linux-gnueabihf/lib -Wl,-O1 
> -Wl,--hash-style=gnu -Wl,-z,now -Wl,-z,relro -Wl,-z,defs -pthread 
> -Wl,-z,noexecstack -fPIC -fuse-ld=gold -Wl,--disable-new-dtags -Wl,-O1 
> -Wl,--as-needed -Wl,--gc-sections -Wl,--no-as-needed -lpthread 
> -Wl,--as-needed -o genmacro -Wl,--start-group 
> obj.host/third_party/yasm/source/patched-yasm/tools/genmacro/genmacro.genmacro.o
>  -Wl,--end-group
> | /usr/bin/ld.gold: fatal error: 
> /opt/linaro-2016.11/arm-linux-gnueabihf/lib/libgcc_s.so.1: unsupported ELF 
> machine number 40
> | collect2: error: ld returned 1 exit status
> | [18/20569] LINK genstring
> | FAILED: genstring
> | gcc  -L/opt/linaro-2016.11/arm-linux-gnueabihf/lib 
> -Wl,-rpath-link,/opt/linaro-2016.11/arm-linux-gnueabihf/lib -Wl,-O1 
> -Wl,--hash-style=gnu -Wl,-z,now -Wl,-z,relro -Wl,-z,defs -pthread 
> -Wl,-z,noexecstack -fPIC -fuse-ld=gold -Wl,--disable-new-dtags -Wl,-O1 
> -Wl,--as-needed -Wl,--gc-sections -Wl,--no-as-needed -lpthread 
> -Wl,--as-needed -o genstring -Wl,--start-group 
> obj.host/third_party/yasm/source/patched-yasm/genstring.genstring.o 
> -Wl,--end-group
> | /usr/bin/ld.gold: fatal error: 
> /opt/linaro-2016.11/arm-linux-gnueabihf/lib/libgcc_s.so.1: unsupported ELF 
> machine number 40
> | collect2: error: ld returned 1 exit status
> 
> -- 
> Denys
> -- 
> ___
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-browser][PATCHv3 1/2] chromium(-wayland): Fix build with gcc7

[Trevor Woerner]

Awesome!! I've build- and run- -tested this with x11 on:
- minnow (x86-64)
- qemux86
- rpi3 (32-bit)
- dragonboard-410c

nice find
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-browser][WIP][PATCH] chromium(-wayland): Fix build with gcc7

[Khem Raj]

On Fri, Jun 16, 2017 at 7:06 AM, Martin Jansa  wrote:
> * add 2 patches to fix issues detected by gcc7
>

both patches look ok to me

> Signed-off-by: Martin Jansa 
> ---
>  recipes-browser/chromium/chromium-browser.inc  |  2 ++
>  .../files/0001-v8-fix-build-with-gcc7.patch| 20 ++
>  .../files/0002-WebKit-fix-build-with-gcc7.patch| 31 
> ++
>  3 files changed, 53 insertions(+)
>  create mode 100644 
> recipes-browser/chromium/files/0001-v8-fix-build-with-gcc7.patch
>  create mode 100644 
> recipes-browser/chromium/files/0002-WebKit-fix-build-with-gcc7.patch
>
> diff --git a/recipes-browser/chromium/chromium-browser.inc 
> b/recipes-browser/chromium/chromium-browser.inc
> index ad8e497..08853b1 100644
> --- a/recipes-browser/chromium/chromium-browser.inc
> +++ b/recipes-browser/chromium/chromium-browser.inc
> @@ -26,6 +26,8 @@ SRC_URI = "\
>  ${@bb.utils.contains('PACKAGECONFIG', 'disable-api-keys-info-bar', 
> 'file://api-keys.patch;patchdir=${WORKDIR}', '', d)} \
>  file://google-chrome.desktop \
>  file://unset-madv-free.patch \
> +file://0001-v8-fix-build-with-gcc7.patch \
> +file://0002-WebKit-fix-build-with-gcc7.patch \
>  "
>
>  S = "${WORKDIR}/chromium-${PV}"
> diff --git a/recipes-browser/chromium/files/0001-v8-fix-build-with-gcc7.patch 
> b/recipes-browser/chromium/files/0001-v8-fix-build-with-gcc7.patch
> new file mode 100644
> index 000..0fc5bfb
> --- /dev/null
> +++ b/recipes-browser/chromium/files/0001-v8-fix-build-with-gcc7.patch
> @@ -0,0 +1,20 @@
> +Use the fix from nodejs:
> +https://github.com/nodejs/node/commit/2a2a5565c298639b823250b571101f51210c50e8
> +
> +* fixes:
> +| ../../git/src/v8/src/objects-body-descriptors.h: In static member function 
> 'static void v8::internal::FixedBodyDescriptor size>::IterateBody(v8::internal::HeapObject*, int)':
> +| ../../git/src/v8/src/objects-body-descriptors.h:102:20: error: no matching 
> function for call to 'v8::internal::FixedBodyDescriptor end_offset, size>::IterateBody(v8::internal::HeapObject*&)'
> +|  IterateBody(obj);
> +| ^
> +
> +--- chromium-54.0.2810.2.orig/v8/src/objects-body-descriptors.h
> 2016-07-28 12:17:37.0 -1000
>  chromium-54.0.2810.2/v8/src/objects-body-descriptors.h 2017-06-16 
> 01:20:50.026665439 -1000
> +@@ -99,7 +99,7 @@
> +
> +   template 
> +   static inline void IterateBody(HeapObject* obj, int object_size) {
> +-IterateBody(obj);
> ++IterateBody(obj);
> +   }
> + };
> +
> diff --git 
> a/recipes-browser/chromium/files/0002-WebKit-fix-build-with-gcc7.patch 
> b/recipes-browser/chromium/files/0002-WebKit-fix-build-with-gcc7.patch
> new file mode 100644
> index 000..284a83c
> --- /dev/null
> +++ b/recipes-browser/chromium/files/0002-WebKit-fix-build-with-gcc7.patch
> @@ -0,0 +1,31 @@
> +Based on qtwebengine-opensource-src-5.8.0-wtf-gcc7.patch from
> +http://git.net/ml/scm-fedora-commits/2017-03/msg15697.html
> +
> +* Fixes:
> +In file included from 
> ../../git/src/third_party/WebKit/Source/platform/heap/ThreadingTraits.h:14:0,
> + from 
> ../../git/src/third_party/WebKit/Source/platform/heap/ThreadState.h:37,
> + from 
> ../../git/src/third_party/WebKit/Source/platform/heap/GarbageCollected.h:8,
> + from 
> ../../git/src/third_party/WebKit/Source/platform/heap/Visitor.h:35,
> + from 
> ../../git/src/third_party/WebKit/Source/platform/heap/GCInfo.h:8,
> + from 
> ../../git/src/third_party/WebKit/Source/platform/heap/Heap.h:35,
> + from 
> ../../git/src/third_party/WebKit/Source/platform/heap/Handle.h:34,
> + from 
> ../../git/src/third_party/WebKit/public/platform/WebPrivatePtr.h:38,
> + from 
> ../../git/src/third_party/WebKit/public/platform/WebString.h:35,
> + from 
> ../../git/src/third_party/WebKit/Source/platform/exported/FilePathConversion.cpp:8:
> +../../git/src/third_party/WebKit/Source/wtf/LinkedHashSet.h: In member 
> function 'void WTF::LinkedHashSet Allocator>::swap(WTF::LinkedHashSet Allocator>&)':
> +../../git/src/third_party/WebKit/Source/wtf/LinkedHashSet.h:549:5: error: 
> there are no arguments to 'swapAnchor' that depend on a template parameter, 
> so a declaration of 'swapAnchor' must be available [-fpermissive]
> + swapAnchor(m_anchor, other.m_anchor);
> + ^~
> +../../git/src/third_party/WebKit/Source/wtf/LinkedHashSet.h:549:5: note: (if 
> you use '-fpermissive', G++ will accept your code, but allowing the use of an 
> undeclared name is deprecated)
> +
> +--- chromium-54.0.2810.2.orig/third_party/WebKit/Source/wtf/LinkedHashSet.h  
>   2016-07-28 12:16:12.0 -1000
>  

Re: [oe] [meta-browser][WIP][PATCH] chromium(-wayland): Fix build with gcc7

[Martin Jansa]

I've tested this with chromium, but for chromium-wayland few more changes
are needed from that v8 change.

On Fri, Jun 16, 2017 at 4:06 PM, Martin Jansa 
wrote:

> * add 2 patches to fix issues detected by gcc7
>
> Signed-off-by: Martin Jansa 
> ---
>  recipes-browser/chromium/chromium-browser.inc  |  2 ++
>  .../files/0001-v8-fix-build-with-gcc7.patch| 20 ++
>  .../files/0002-WebKit-fix-build-with-gcc7.patch| 31
> ++
>  3 files changed, 53 insertions(+)
>  create mode 100644 recipes-browser/chromium/files/0001-v8-fix-build-with-
> gcc7.patch
>  create mode 100644 recipes-browser/chromium/files/0002-WebKit-fix-build-
> with-gcc7.patch
>
> diff --git a/recipes-browser/chromium/chromium-browser.inc
> b/recipes-browser/chromium/chromium-browser.inc
> index ad8e497..08853b1 100644
> --- a/recipes-browser/chromium/chromium-browser.inc
> +++ b/recipes-browser/chromium/chromium-browser.inc
> @@ -26,6 +26,8 @@ SRC_URI = "\
>  ${@bb.utils.contains('PACKAGECONFIG',
> 'disable-api-keys-info-bar', 'file://api-keys.patch;patchdir=${WORKDIR}',
> '', d)} \
>  file://google-chrome.desktop \
>  file://unset-madv-free.patch \
> +file://0001-v8-fix-build-with-gcc7.patch \
> +file://0002-WebKit-fix-build-with-gcc7.patch \
>  "
>
>  S = "${WORKDIR}/chromium-${PV}"
> diff --git a/recipes-browser/chromium/files/0001-v8-fix-build-with-gcc7.patch
> b/recipes-browser/chromium/files/0001-v8-fix-build-with-gcc7.patch
> new file mode 100644
> index 000..0fc5bfb
> --- /dev/null
> +++ b/recipes-browser/chromium/files/0001-v8-fix-build-with-gcc7.patch
> @@ -0,0 +1,20 @@
> +Use the fix from nodejs:
> +https://github.com/nodejs/node/commit/2a2a5565c298639b823250b571101f
> 51210c50e8
> +
> +* fixes:
> +| ../../git/src/v8/src/objects-body-descriptors.h: In static member
> function 'static void v8::internal::FixedBodyDescriptor end_offset, size>::IterateBody(v8::internal::HeapObject*, int)':
> +| ../../git/src/v8/src/objects-body-descriptors.h:102:20: error: no
> matching function for call to 'v8::internal::FixedBodyDescriptor end_offset, size>::IterateBody(v8::internal::HeapObject*&)'
> +|  IterateBody(obj);
> +| ^
> +
> +--- chromium-54.0.2810.2.orig/v8/src/objects-body-descriptors.h
> 2016-07-28 12:17:37.0 -1000
>  chromium-54.0.2810.2/v8/src/objects-body-descriptors.h
>  2017-06-16 01:20:50.026665439 -1000
> +@@ -99,7 +99,7 @@
> +
> +   template 
> +   static inline void IterateBody(HeapObject* obj, int object_size) {
> +-IterateBody(obj);
> ++IterateBody(obj);
> +   }
> + };
> +
> diff --git 
> a/recipes-browser/chromium/files/0002-WebKit-fix-build-with-gcc7.patch
> b/recipes-browser/chromium/files/0002-WebKit-fix-build-with-gcc7.patch
> new file mode 100644
> index 000..284a83c
> --- /dev/null
> +++ b/recipes-browser/chromium/files/0002-WebKit-fix-build-with-gcc7.patch
> @@ -0,0 +1,31 @@
> +Based on qtwebengine-opensource-src-5.8.0-wtf-gcc7.patch from
> +http://git.net/ml/scm-fedora-commits/2017-03/msg15697.html
> +
> +* Fixes:
> +In file included from ../../git/src/third_party/
> WebKit/Source/platform/heap/ThreadingTraits.h:14:0,
> + from ../../git/src/third_party/
> WebKit/Source/platform/heap/ThreadState.h:37,
> + from ../../git/src/third_party/
> WebKit/Source/platform/heap/GarbageCollected.h:8,
> + from ../../git/src/third_party/
> WebKit/Source/platform/heap/Visitor.h:35,
> + from ../../git/src/third_party/
> WebKit/Source/platform/heap/GCInfo.h:8,
> + from ../../git/src/third_party/
> WebKit/Source/platform/heap/Heap.h:35,
> + from ../../git/src/third_party/
> WebKit/Source/platform/heap/Handle.h:34,
> + from ../../git/src/third_party/WebKit/public/platform/
> WebPrivatePtr.h:38,
> + from ../../git/src/third_party/WebKit/public/platform/
> WebString.h:35,
> + from ../../git/src/third_party/WebKit/Source/platform/
> exported/FilePathConversion.cpp:8:
> +../../git/src/third_party/WebKit/Source/wtf/LinkedHashSet.h: In member
> function 'void WTF::LinkedHashSet Allocator>::swap(WTF::LinkedHashSet Allocator>&)':
> +../../git/src/third_party/WebKit/Source/wtf/LinkedHashSet.h:549:5:
> error: there are no arguments to 'swapAnchor' that depend on a template
> parameter, so a declaration of 'swapAnchor' must be available [-fpermissive]
> + swapAnchor(m_anchor, other.m_anchor);
> + ^~
> +../../git/src/third_party/WebKit/Source/wtf/LinkedHashSet.h:549:5: note:
> (if you use '-fpermissive', G++ will accept your code, but allowing the use
> of an undeclared name is deprecated)
> +
> +--- chromium-54.0.2810.2.orig/third_party/WebKit/Source/wtf/LinkedHashSet.h
>   2016-07-28 12:16:12.0 -1000

Re: [oe] [meta-browser][PATCH] chromium: show progress for do_compile

[Andreas Müller]

On Sun, Apr 23, 2017 at 4:33 AM, Trevor Woerner  wrote:
> Otavio is quick to apply patches provided as github pull requests :-)
Pull request is out

Andreas
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-browser][PATCH] chromium: show progress for do_compile

[Trevor Woerner]

Sweet!
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-browser] [PATCH] chromium: fix null pointer dereference in V8 with gcc-6

[Andrey Konovalov]

On 04/11/2017 09:51 PM, Andre McCurdy wrote:

On Tue, Apr 11, 2017 at 6:02 AM, Andrey Konovalov
 wrote:

On 04/11/2017 03:40 AM, Andre McCurdy wrote:


On Fri, Apr 7, 2017 at 11:40 AM, Andrey Konovalov
 wrote:



-GYP_DEFINES += "${ARMFPABI}
release_extra_cflags='-Wno-error=unused-local-typedefs' sysroot=''"
+GYP_DEFINES += " ${ARMFPABI}
release_extra_cflags='-Wno-error=unused-local-typedefs' sysroot='' \
+   ${@bb.utils.contains("AVAILTUNES", "mips", "",
"release_extra_cflags='-fno-delete-null-pointer-checks'", d)}"



What's the significance of skipping the workaround if AVAILTUNES
contains "mips" ?



This change (to add '-fno-delete-null-pointer-checks' to gcc flags) was
initially merged into chromium directly,
but soon reverted as it broke mips somehow:
https://bugs.chromium.org/p/v8/issues/detail?id=3782#c10


OK, thanks. Note that building for MIPS isn't currently supported at
all according to the COMPATIBLE_MACHINE definitions at the top of the
recipe.


Indeed.
So my check for "mips" in AVAILTUNES is a NOP until someone enables building 
for MIPS.
Thanks for pointing that out!
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-browser] [PATCH] chromium: fix null pointer dereference in V8 with gcc-6

[Andre McCurdy]

On Tue, Apr 11, 2017 at 6:02 AM, Andrey Konovalov
 wrote:
> On 04/11/2017 03:40 AM, Andre McCurdy wrote:
>>
>> On Fri, Apr 7, 2017 at 11:40 AM, Andrey Konovalov
>>  wrote:
>>>
>>> This patch prevents "Aw Snap" error when loading a page with JavaScript.
>>>
>>> Tested by running:
>>> - chromium-wayland on Beagle X15
>>> - chromium-wayland on HiKey (with a separate patch to enable aarch64
>>> build)
>>> - cromium on dragonboard-410c (with a separate patch to enable aarch64
>>> build)
>>>
>>> Based on the fix for Gentoo's bug 588596:
>>> https://bugs.gentoo.org/show_bug.cgi?id=588596#c10
>>>
>>> Signed-off-by: Andrey Konovalov 
>>> ---
>>>   recipes-browser/chromium/chromium.inc | 3 ++-
>>>   1 file changed, 2 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/recipes-browser/chromium/chromium.inc
>>> b/recipes-browser/chromium/chromium.inc
>>> index 60edccb..7e057ec 100644
>>> --- a/recipes-browser/chromium/chromium.inc
>>> +++ b/recipes-browser/chromium/chromium.inc
>>> @@ -15,7 +15,8 @@ CHROMIUM_BUILD_TYPE ??= "Release"
>>>   inherit gettext pythonnative
>>>
>>>   ARMFPABI_armv7a = "${@bb.utils.contains('TUNE_FEATURES',
>>> 'callconvention-hard', 'arm_float_abi=hard', 'arm_float_abi=softfp', d)}"
>>
>>
>> Not related to the patch, but this over-ride should be duplicated for
>> _armv7ve
>>
>>> -GYP_DEFINES += "${ARMFPABI}
>>> release_extra_cflags='-Wno-error=unused-local-typedefs' sysroot=''"
>>> +GYP_DEFINES += " ${ARMFPABI}
>>> release_extra_cflags='-Wno-error=unused-local-typedefs' sysroot='' \
>>> +   ${@bb.utils.contains("AVAILTUNES", "mips", "",
>>> "release_extra_cflags='-fno-delete-null-pointer-checks'", d)}"
>>
>>
>> What's the significance of skipping the workaround if AVAILTUNES
>> contains "mips" ?
>
>
> This change (to add '-fno-delete-null-pointer-checks' to gcc flags) was
> initially merged into chromium directly,
> but soon reverted as it broke mips somehow:
> https://bugs.chromium.org/p/v8/issues/detail?id=3782#c10

OK, thanks. Note that building for MIPS isn't currently supported at
all according to the COMPATIBLE_MACHINE definitions at the top of the
recipe.

>>>   GYP_DEFINES_append_x86 = " generate_character_data=0"
>>>
>>>   do_configure() {
>>> --
>>> 2.1.4
>>>
>>> --
>>> ___
>>> Openembedded-devel mailing list
>>> Openembedded-devel@lists.openembedded.org
>>> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
>
>
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-browser] [PATCH] chromium: fix null pointer dereference in V8 with gcc-6

[Andrey Konovalov]

On 04/11/2017 03:40 AM, Andre McCurdy wrote:

On Fri, Apr 7, 2017 at 11:40 AM, Andrey Konovalov
 wrote:

This patch prevents "Aw Snap" error when loading a page with JavaScript.

Tested by running:
- chromium-wayland on Beagle X15
- chromium-wayland on HiKey (with a separate patch to enable aarch64 build)
- cromium on dragonboard-410c (with a separate patch to enable aarch64 build)

Based on the fix for Gentoo's bug 588596:
https://bugs.gentoo.org/show_bug.cgi?id=588596#c10

Signed-off-by: Andrey Konovalov 
---
  recipes-browser/chromium/chromium.inc | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/recipes-browser/chromium/chromium.inc 
b/recipes-browser/chromium/chromium.inc
index 60edccb..7e057ec 100644
--- a/recipes-browser/chromium/chromium.inc
+++ b/recipes-browser/chromium/chromium.inc
@@ -15,7 +15,8 @@ CHROMIUM_BUILD_TYPE ??= "Release"
  inherit gettext pythonnative

  ARMFPABI_armv7a = "${@bb.utils.contains('TUNE_FEATURES', 'callconvention-hard', 
'arm_float_abi=hard', 'arm_float_abi=softfp', d)}"


Not related to the patch, but this over-ride should be duplicated for _armv7ve


-GYP_DEFINES += "${ARMFPABI} release_extra_cflags='-Wno-error=unused-local-typedefs' 
sysroot=''"
+GYP_DEFINES += " ${ARMFPABI} 
release_extra_cflags='-Wno-error=unused-local-typedefs' sysroot='' \
+   ${@bb.utils.contains("AVAILTUNES", "mips", "", 
"release_extra_cflags='-fno-delete-null-pointer-checks'", d)}"


What's the significance of skipping the workaround if AVAILTUNES
contains "mips" ?


This change (to add '-fno-delete-null-pointer-checks' to gcc flags) was 
initially merged into chromium directly,
but soon reverted as it broke mips somehow:
https://bugs.chromium.org/p/v8/issues/detail?id=3782#c10


  GYP_DEFINES_append_x86 = " generate_character_data=0"

  do_configure() {
--
2.1.4

--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel


--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-browser] [PATCH] chromium: fix null pointer dereference in V8 with gcc-6

[Andre McCurdy]

On Fri, Apr 7, 2017 at 11:40 AM, Andrey Konovalov
 wrote:
> This patch prevents "Aw Snap" error when loading a page with JavaScript.
>
> Tested by running:
> - chromium-wayland on Beagle X15
> - chromium-wayland on HiKey (with a separate patch to enable aarch64 build)
> - cromium on dragonboard-410c (with a separate patch to enable aarch64 build)
>
> Based on the fix for Gentoo's bug 588596:
> https://bugs.gentoo.org/show_bug.cgi?id=588596#c10
>
> Signed-off-by: Andrey Konovalov 
> ---
>  recipes-browser/chromium/chromium.inc | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/recipes-browser/chromium/chromium.inc 
> b/recipes-browser/chromium/chromium.inc
> index 60edccb..7e057ec 100644
> --- a/recipes-browser/chromium/chromium.inc
> +++ b/recipes-browser/chromium/chromium.inc
> @@ -15,7 +15,8 @@ CHROMIUM_BUILD_TYPE ??= "Release"
>  inherit gettext pythonnative
>
>  ARMFPABI_armv7a = "${@bb.utils.contains('TUNE_FEATURES', 
> 'callconvention-hard', 'arm_float_abi=hard', 'arm_float_abi=softfp', d)}"

Not related to the patch, but this over-ride should be duplicated for _armv7ve

> -GYP_DEFINES += "${ARMFPABI} 
> release_extra_cflags='-Wno-error=unused-local-typedefs' sysroot=''"
> +GYP_DEFINES += " ${ARMFPABI} 
> release_extra_cflags='-Wno-error=unused-local-typedefs' sysroot='' \
> +   ${@bb.utils.contains("AVAILTUNES", "mips", "", 
> "release_extra_cflags='-fno-delete-null-pointer-checks'", d)}"

What's the significance of skipping the workaround if AVAILTUNES
contains "mips" ?

>  GYP_DEFINES_append_x86 = " generate_character_data=0"
>
>  do_configure() {
> --
> 2.1.4
>
> --
> ___
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-browser] [PATCH] chromium: fix null pointer dereference in V8 with gcc-6

[Andrey Konovalov]

On 04/07/2017 09:40 PM, Andrey Konovalov wrote:

This patch prevents "Aw Snap" error when loading a page with JavaScript.

Tested by running:
- chromium-wayland on Beagle X15
- chromium-wayland on HiKey (with a separate patch to enable aarch64 build)
- cromium on dragonboard-410c (with a separate patch to enable aarch64 build)

Based on the fix for Gentoo's bug 588596:
https://bugs.gentoo.org/show_bug.cgi?id=588596#c10

Signed-off-by: Andrey Konovalov 
---
  recipes-browser/chromium/chromium.inc | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/recipes-browser/chromium/chromium.inc 
b/recipes-browser/chromium/chromium.inc
index 60edccb..7e057ec 100644
--- a/recipes-browser/chromium/chromium.inc
+++ b/recipes-browser/chromium/chromium.inc
@@ -15,7 +15,8 @@ CHROMIUM_BUILD_TYPE ??= "Release"
  inherit gettext pythonnative

  ARMFPABI_armv7a = "${@bb.utils.contains('TUNE_FEATURES', 'callconvention-hard', 
'arm_float_abi=hard', 'arm_float_abi=softfp', d)}"
-GYP_DEFINES += "${ARMFPABI} release_extra_cflags='-Wno-error=unused-local-typedefs' 
sysroot=''"
+GYP_DEFINES += " ${ARMFPABI} 
release_extra_cflags='-Wno-error=unused-local-typedefs' sysroot='' \


Oops, by occasion I've added an extra space before ${ARMFPABI}. I updated the 
pull request in github, and
can send an updated patch to the list if needed.

Thanks,
Andrey


+   ${@bb.utils.contains("AVAILTUNES", "mips", "", 
"release_extra_cflags='-fno-delete-null-pointer-checks'", d)}"
  GYP_DEFINES_append_x86 = " generate_character_data=0"

  do_configure() {



--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-browser][PATCH] chromium: 52.0.2743.76 -> 54.0.2810.2

[Andrey Konovalov]

Hi,

On 04/07/2017 11:08 AM, Fathi Boudra wrote:

Hi Trevor,

On 6 April 2017 at 23:37, Trevor Woerner  wrote:

On Thu, Apr 6, 2017 at 3:31 AM, Martin Jansa  wrote:

In my world build it (surprisingly) didn't fail, good job Trevor!


Sadly, it does fail with one specific PACKAGECONFIG: ignore-lost-context

I have a fix which I've build-tested both for x11 and wayland with a
bunch of different targets, which is just waiting for run-testing:
https://github.com/twoerner/meta-browser/tree/contrib/twoerner/chromium_54_pkgconfig_fix


Are you willing to check 2 QA issues which might be there in older version
as well?

chromium-54.0.2810.2: ELF binary
'/tmp/work/i586-oe-linux/chromium/54.0.2810.2-r0/packages-split/chromium/usr/bin/chromium/chrome'
has relocations in .text [textrel]
chromium-wayland-53.0.2785.143: ELF binary
'/tmp/work/i586-oe-linux/chromium-wayland/53.0.2785.143-r0/packages-split/chromium-wayland/usr/bin/chromium/chrome'
has relocations in .text [textrel]


Yes, I'll have a look.

Currently I'm trying to figure out how to move past this version.
After 53.0.2810.2 the current method OE uses to build chromium starts
to fail because (as is my understanding) it was around this point that
the chromium build switched from gyp+ninja (what we're using in OE) to
gn+ninja (ninja is like "make" and gyp/gn are like the autotools)
Therefore the gyp support starts to break down due to lack of upstream
maintainership. I'm starting to be able to do successful chromium
builds from tarballs on the cmdline (outside of OE) up to
57.0.2987.133 but I need to figure out how to translate that into a
recipe.


I think Zoltan looked into it at some point but I can't remember what
was the outcome...


Oh, and it'd be nice to have an aarch64 build too.


Andrey in CC is looking at submitting the changes needed to get Aarch64 added.


To my surprise just enabling aarch64 in the current chromium recipes was enough
to get the browser running (tried playing some videos from youtube and the horse
example from threejs.org [1]).
After checking the chromium sources, it looks like at least some of the aarch64
fixes mentioned in [2] are present in the 53 and 54 versions used in 
meta-browser.

I'll post my aarch64 patch to the list shortly.

Thanks,
Andrey

[1] http://threejs.org/examples/#webgl_morphtargets_horse
[2] https://bugs.chromium.org/p/chromium/issues/detail?id=613452

--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-browser][PATCH] chromium: 52.0.2743.76 -> 54.0.2810.2

[Jacobo Aragunde Pérez]

Hi Trevor,

On 06/04/17 22:37, Trevor Woerner wrote:
> ...
> Currently I'm trying to figure out how to move past this version.
> After 53.0.2810.2 the current method OE uses to build chromium starts
> to fail because (as is my understanding) it was around this point that
> the chromium build switched from gyp+ninja (what we're using in OE) to
> gn+ninja (ninja is like "make" and gyp/gn are like the autotools)
> Therefore the gyp support starts to break down due to lack of upstream
> maintainership. I'm starting to be able to do successful chromium
> builds from tarballs on the cmdline (outside of OE) up to
> 57.0.2987.133 but I need to figure out how to translate that into a
> recipe.
> 

Some colleagues here have modified the recipe to build Chromium up to
version 57 using the new GN build system, targeting R-Car Gen.3 boards.
Unfortunately, the solution would still need a lot of cleanup before
being able to submit it.

Still, if you want to take a look and use it as an example, even reuse
parts of it in your own patch, feel free to do it.

Layer is here: https://github.com/Igalia/meta-browser

Best,
-- 
Jacobo Aragunde
Software Engineer at Igalia
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-browser][PATCH] chromium: 52.0.2743.76 -> 54.0.2810.2

[Fathi Boudra]

Hi Trevor,

On 6 April 2017 at 23:37, Trevor Woerner  wrote:
> On Thu, Apr 6, 2017 at 3:31 AM, Martin Jansa  wrote:
>> In my world build it (surprisingly) didn't fail, good job Trevor!
>
> Sadly, it does fail with one specific PACKAGECONFIG: ignore-lost-context
>
> I have a fix which I've build-tested both for x11 and wayland with a
> bunch of different targets, which is just waiting for run-testing:
> https://github.com/twoerner/meta-browser/tree/contrib/twoerner/chromium_54_pkgconfig_fix
>
>> Are you willing to check 2 QA issues which might be there in older version
>> as well?
>>
>> chromium-54.0.2810.2: ELF binary
>> '/tmp/work/i586-oe-linux/chromium/54.0.2810.2-r0/packages-split/chromium/usr/bin/chromium/chrome'
>> has relocations in .text [textrel]
>> chromium-wayland-53.0.2785.143: ELF binary
>> '/tmp/work/i586-oe-linux/chromium-wayland/53.0.2785.143-r0/packages-split/chromium-wayland/usr/bin/chromium/chrome'
>> has relocations in .text [textrel]
>
> Yes, I'll have a look.
>
> Currently I'm trying to figure out how to move past this version.
> After 53.0.2810.2 the current method OE uses to build chromium starts
> to fail because (as is my understanding) it was around this point that
> the chromium build switched from gyp+ninja (what we're using in OE) to
> gn+ninja (ninja is like "make" and gyp/gn are like the autotools)
> Therefore the gyp support starts to break down due to lack of upstream
> maintainership. I'm starting to be able to do successful chromium
> builds from tarballs on the cmdline (outside of OE) up to
> 57.0.2987.133 but I need to figure out how to translate that into a
> recipe.

I think Zoltan looked into it at some point but I can't remember what
was the outcome...

> Oh, and it'd be nice to have an aarch64 build too.

Andrey in CC is looking at submitting the changes needed to get Aarch64 added.

Cheers,
Fathi
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-browser][PATCH] chromium: 52.0.2743.76 -> 54.0.2810.2

[Trevor Woerner]

On Thu, Apr 6, 2017 at 3:31 AM, Martin Jansa  wrote:
> In my world build it (surprisingly) didn't fail, good job Trevor!

Sadly, it does fail with one specific PACKAGECONFIG: ignore-lost-context

I have a fix which I've build-tested both for x11 and wayland with a
bunch of different targets, which is just waiting for run-testing:
https://github.com/twoerner/meta-browser/tree/contrib/twoerner/chromium_54_pkgconfig_fix

> Are you willing to check 2 QA issues which might be there in older version
> as well?
>
> chromium-54.0.2810.2: ELF binary
> '/tmp/work/i586-oe-linux/chromium/54.0.2810.2-r0/packages-split/chromium/usr/bin/chromium/chrome'
> has relocations in .text [textrel]
> chromium-wayland-53.0.2785.143: ELF binary
> '/tmp/work/i586-oe-linux/chromium-wayland/53.0.2785.143-r0/packages-split/chromium-wayland/usr/bin/chromium/chrome'
> has relocations in .text [textrel]

Yes, I'll have a look.

Currently I'm trying to figure out how to move past this version.
After 53.0.2810.2 the current method OE uses to build chromium starts
to fail because (as is my understanding) it was around this point that
the chromium build switched from gyp+ninja (what we're using in OE) to
gn+ninja (ninja is like "make" and gyp/gn are like the autotools)
Therefore the gyp support starts to break down due to lack of upstream
maintainership. I'm starting to be able to do successful chromium
builds from tarballs on the cmdline (outside of OE) up to
57.0.2987.133 but I need to figure out how to translate that into a
recipe.

Oh, and it'd be nice to have an aarch64 build too.
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-browser][PATCH] chromium: 52.0.2743.76 -> 54.0.2810.2

[Martin Jansa]

In my world build it (surprisingly) didn't fail, good job Trevor!

Are you willing to check 2 QA issues which might be there in older version
as well?

chromium-54.0.2810.2: ELF binary
'/tmp/work/i586-oe-linux/chromium/54.0.2810.2-r0/packages-split/chromium/usr/bin/chromium/chrome'
has relocations in .text [textrel]
chromium-wayland-53.0.2785.143: ELF binary
'/tmp/work/i586-oe-linux/chromium-wayland/53.0.2785.143-r0/packages-split/chromium-wayland/usr/bin/chromium/chrome'
has relocations in .text [textrel]



On Mon, Apr 3, 2017 at 8:38 PM, Trevor Woerner  wrote:

> Tested by building for and running on:
> - minnow
> - raspi3 (32-bit)
> - qemux86
> - bbb
>
> On-target testing includes:
> - playing a video from youtube[1]
> - running (and passing) the octane tests (js)[2]
>
> Verified chromium-wayland still builds.
>
> [1] http://youtube.com
> [2] http://chromium.github.io/octane
>
> Signed-off-by: Trevor Woerner 
> ---
>  .../chromium/chromium-wayland_53.0.2785.143.bb |  2 +-
>  .../Remove-hard-coded-values-for-CC-and-CXX.patch  | 42 ---
>  .../chromium/chromium/chromium/m32.patch   | 87
> ++
>  ...ium_52.0.2743.76.bb => chromium_54.0.2810.2.bb} |  7 +-
>  ...3-Remove-hard-coded-values-for-CC-and-CXX.patch | 11 ++-
>  recipes-browser/chromium/files/i586/x86-m32.patch  | 42 ---
>  6 files changed, 96 insertions(+), 95 deletions(-)
>  delete mode 100644 recipes-browser/chromium/chromium/chromium-wayland/
> Remove-hard-coded-values-for-CC-and-CXX.patch
>  create mode 100644 recipes-browser/chromium/chromium/chromium/m32.patch
>  rename recipes-browser/chromium/{chromium_52.0.2743.76.bb =>
> chromium_54.0.2810.2.bb} (85%)
>  delete mode 100644 recipes-browser/chromium/files/i586/x86-m32.patch
>
> diff --git a/recipes-browser/chromium/chromium-wayland_53.0.2785.143.bb
> b/recipes-browser/chromium/chromium-wayland_53.0.2785.143.bb
> index ef913a7..ab52bc2 100644
> --- a/recipes-browser/chromium/chromium-wayland_53.0.2785.143.bb
> +++ b/recipes-browser/chromium/chromium-wayland_53.0.2785.143.bb
> @@ -6,9 +6,9 @@ DEPENDS += "wayland libxkbcommon"
>
>  SRC_URI += "\
>  file://chromium-wayland/add_missing_stat_h_include.patch \
> +file://0003-Remove-hard-coded-values-for-CC-and-CXX.patch \
>  
> file://0004-Create-empty-i18n_process_css_test.html-file-to-avoi.patch
> \
>  file://0005-Override-root-filesystem-access-restriction.patch \
> -file://chromium-wayland/Remove-hard-coded-values-for-CC-and-CXX.patch
> \
> 
> file://chromium-wayland/0007-Workaround-for-glib-related-build-error-with-ozone-w.patch
> \
>  file://chromium-wayland/0011-Replace-readdir_r-with-readdir.patch
> \
>  file://chromium-wayland/remove-Werror.patch \
> diff --git a/recipes-browser/chromium/chromium/chromium-wayland/
> Remove-hard-coded-values-for-CC-and-CXX.patch b/recipes-browser/chromium/
> chromium/chromium-wayland/Remove-hard-coded-values-for-CC-and-CXX.patch
> deleted file mode 100644
> index 63de68a..000
> --- a/recipes-browser/chromium/chromium/chromium-wayland/
> Remove-hard-coded-values-for-CC-and-CXX.patch
> +++ /dev/null
> @@ -1,42 +0,0 @@
> -From 518135b0cd6878e91e5fcf489f3185740ec307c0 Mon Sep 17 00:00:00 2001
> -From: Carlos Rafael Giani 
> -Date: Sun, 12 Oct 2014 19:31:47 +0200
> -Subject: [PATCH] Remove hard coded values for CC and CXX
> -
> -In spite of what the comment says, the environment variables do *not*
> -override the variables; "which which arm-linux-gnueabihf-gcc" etc. are
> -always called. To undo this, remove the change.
> -
> -Upstream-Status: Pending
> -
> -The default values cannot be overriden without the patch; upstream
> -might be interested in this.
> -
> -Signed-off-by: Carlos Rafael Giani 
> 
> - build/common.gypi | 10 --
> - 1 file changed, 10 deletions(-)
> -
> -diff --git a/build/common.gypi b/build/common.gypi
> -index 7ec5ae2..11e8d1d 100644
>  a/build/common.gypi
> -+++ b/build/common.gypi
> -@@ -6027,16 +6027,6 @@
> - ['CXX.host', '<(host_cxx)'],
> -   ],
> - }],
> --['OS=="linux" and target_arch=="arm" and host_arch!="arm" and
> chromeos==0 and clang==0', {
> --  # Set default ARM cross tools on linux.  These can be overridden
> --  # using CC,CXX,CC.host and CXX.host environment variables.
> --  'make_global_settings': [
> --['CC', ' --['CXX', ' --['CC.host', '<(host_cc)'],
> --['CXX.host', '<(host_cxx)'],
> --  ],
> --}],
> - ['use_goma==1', {
> -   'make_global_settings': [
> -['CC_wrapper', '<(gomadir)/gomacc'],
> ---
> -2.1.4
> diff --git a/recipes-browser/chromium/chromium/chromium/m32.patch
> b/recipes-browser/chromium/chromium/chromium/m32.patch
> new file mode 100644
> index 000..2911cfa
> --- /dev/null
> +++ b/recipes-browser/chromium/chromium/chromium/m32.patch
> @@ -0,0 +1,87 

Re: [oe] [meta-browser] calling all chromium recipe users

[Ian Coolidge]

Chromium and Chromium-Wayland on IMX platform

Chromium is working great, although chromium-imx hasn't been updated yet
for the later 53.x versions as the patches for graphics need to be updated.

Chromium-Wayland hasn't worked in any of it's versions, or on wayland on
IMX in general for some time. Unless i'm doing something wrong... I've been
trying to get this working on the 48x version for a while now, I just get a
segfault on startup that looks like this

root@nitrogen6x-lite:~# google-chrome www.google.com
>
> [1:1:0327/214358:ERROR:image_metadata_extractor.cc(112)] Couldn't load
>> libexif. libexif.so.12: cannot open shared object file: No such file or
>> directory
>
> error: XDG_RUNTIME_DIR not set in the environment.
>
> error: XDG_RUNTIME_DIR not set in the environment.
>
> [512:512:0327/214400:ERROR:display.cc(148)] WaylandDisplay failed to
>> initialize hardware
>
> [512:512:0327/214400:FATAL:ozone_platform_wayland.cc(115)] failed to
>> initialize display hardware
>
> #0 0x5524860a 
>
> #1 0x55257dd0 
>
> #2 0x558a506e 
>
> #3 0x55989104 
>
> #4 0x55989a54 
>
> #5 0x55989b26 
>
> #6 0x578ca552 
>
> #7 0x5521a1d4 
>
> #8 0x5521900a 
>
> #9 0x54f3e4f8 ChromeMain
>
> #10 0x766e246a __libc_start_main
>
>
>> Received signal 6
>
> #0 0x5524860a 
>
> #1 0x552488cc 
>
> #2 0x766f1020 
>
> #3 0x766e26b6 
>
> #4 0x766f040c gsignal
>
> #5 0x766f10fa abort
>
> #6 0x5524842a 
>
> #7 0x55257e98 
>
> #8 0x558a506e 
>
> #9 0x55989104 
>
> #10 0x55989a54 
>
> #11 0x55989b26 
>
> #12 0x578ca552 
>
> #13 0x5521a1d4 
>
> #14 0x5521900a 
>
> #15 0x54f3e4f8 ChromeMain
>
> #16 0x766e246a __libc_start_main
>
> [end of stack trace]
>
> Segmentation fault
>
>
>
On Wed, Mar 29, 2017 at 3:04 PM, Denys Dmytriyenko  wrote:

> On Wed, Mar 29, 2017 at 03:35:22PM -0400, Trevor Woerner wrote:
> > When testing changes to the chromium[-wayland] recipes, it would be
> > great to know the layers, configurations, and MACHINEs with which
> > people are building.
> >
> > For example I care about chromium running on X11 for minnow
> > (meta-intel) and raspberry pi (meta-raspberrypi). How are other people
> > running chromium?
>
> chromium-wayland on TI platforms from meta-ti.
>
>
> > Also, are you able to run with accelerated graphics? If so, what
> > configuration are you using?
>
> Full acceleration is still in the works for our platforms.
> Very basic "hacky" way was to patch wayland.gyp to bypass the configure
> check
> for Mesa version:
> http://arago-project.org/git/?p=meta-arago.git;a=blob;f=
> meta-arago-distro/recipes-browser/chromium/chromium-
> wayland/0001-wayland.gyp-adjust-Mesa-version-to-work-
> with-TI-SGX-.patch;hb=HEAD
>
> --
> Denys
>
>
> > Specifically, I assume the trick is the correct configuration of various
> >
> > PREFERRED_PROVIDER_virtual/X = Y
> >
> > where X is one of {mesa|gl|egl|gles1|gles2} and Y is probably
> > something BSP-specific. Is anything else needed to get accelerated
> > graphics working with chromium?
> > --
> > ___
> > Openembedded-devel mailing list
> > Openembedded-devel@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-devel
> --
> ___
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
>
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-browser] calling all chromium recipe users

[Denys Dmytriyenko]

On Wed, Mar 29, 2017 at 03:35:22PM -0400, Trevor Woerner wrote:
> When testing changes to the chromium[-wayland] recipes, it would be
> great to know the layers, configurations, and MACHINEs with which
> people are building.
> 
> For example I care about chromium running on X11 for minnow
> (meta-intel) and raspberry pi (meta-raspberrypi). How are other people
> running chromium?

chromium-wayland on TI platforms from meta-ti.


> Also, are you able to run with accelerated graphics? If so, what
> configuration are you using?

Full acceleration is still in the works for our platforms.
Very basic "hacky" way was to patch wayland.gyp to bypass the configure check 
for Mesa version:
http://arago-project.org/git/?p=meta-arago.git;a=blob;f=meta-arago-distro/recipes-browser/chromium/chromium-wayland/0001-wayland.gyp-adjust-Mesa-version-to-work-with-TI-SGX-.patch;hb=HEAD

-- 
Denys


> Specifically, I assume the trick is the correct configuration of various
> 
> PREFERRED_PROVIDER_virtual/X = Y
> 
> where X is one of {mesa|gl|egl|gles1|gles2} and Y is probably
> something BSP-specific. Is anything else needed to get accelerated
> graphics working with chromium?
> -- 
> ___
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-browser][PATCH] chromium: disable generate_character_data for qemux86

[Jacobo Aragunde Pérez]

On 23/02/17 01:41, Otavio Salvador wrote:
> On Wed, Feb 22, 2017 at 9:53 AM, Jacobo Aragunde Pérez
>  wrote:
>> Chromium-wayland fails with:
>>   http://errors.yoctoproject.org/Errors/Build/32356/
>>
>> Root cause seems to be ICU mixing host and target architectures,
>> same as in: https://bugreports.qt.io/browse/QTBUG-57705
>> ...
> Any x86 will need this.
> 

You are totally right, I've reproduced build issues in third_party/icu
with qemux86 and intel-core2-32 machines.

I'm sending an amended patch that covers both cases. Thanks for the review.

Best,
-- 
Jacobo Aragunde
Software Engineer at Igalia
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-browser][PATCH] chromium: disable generate_character_data for qemux86

[Otavio Salvador]

On Wed, Feb 22, 2017 at 9:53 AM, Jacobo Aragunde Pérez
 wrote:
> Chromium-wayland fails with:
>   http://errors.yoctoproject.org/Errors/Build/32356/
>
> Root cause seems to be ICU mixing host and target architectures,
> same as in: https://bugreports.qt.io/browse/QTBUG-57705
>
> Signed-off-by: Jacobo Aragunde Pérez 
> ---
>  recipes-browser/chromium/chromium.inc | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/recipes-browser/chromium/chromium.inc 
> b/recipes-browser/chromium/chromium.inc
> index 0e7250e..0076f3a 100644
> --- a/recipes-browser/chromium/chromium.inc
> +++ b/recipes-browser/chromium/chromium.inc
> @@ -15,6 +15,7 @@ inherit gettext pythonnative
>
>  ARMFPABI_armv7a = "${@bb.utils.contains('TUNE_FEATURES', 
> 'callconvention-hard', 'arm_float_abi=hard', 'arm_float_abi=softfp', d)}"
>  GYP_DEFINES += "${ARMFPABI} 
> release_extra_cflags='-Wno-error=unused-local-typedefs' sysroot=''"
> +GYP_DEFINES_append_qemux86 = " generate_character_data=0"

Any x86 will need this.


-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-browser][PATCH] chromium-wayland: fix compilation problem on non-X11 builds

[Jacobo Aragunde Pérez]

Hi Martin,

On 15/02/17 19:39, Martin Jansa wrote:
> It still fails for qemux86 as reported in:
> http://lists.openembedded.org/pipermail/openembedded-devel/2017-February/111221.html
> 
> can someone please look into it?

Let me take a look along this week. Thanks for the heads-up.

Best,
-- 
Jacobo Aragunde
Software Engineer at Igalia


> On Wed, Feb 15, 2017 at 7:17 PM, Jacobo Aragunde Pérez > wrote:
> 
>> Hi everyone!
>>
>> The patch in this thread has been recently merged. Thanks for your review!
>>
>> On 02/02/17 16:33, Herve Jourdain wrote:
>>> Hi Jacobo,
>>>
>>> OK, I will send those extra patched to the meta-raspberry list tomorrow
>> then.
>>>
>>
>> Sorry to ping you again on this, Herve O:-) I haven't found your patches
>> around in yocto ML and I would like to try them. May I be following the
>> wrong ML?
>>
>> Thanks in advance,
>> --
>> Jacobo Aragunde
>> Software Engineer at Igalia
>>
>>
 On 2 Feb 2017, at 21:28, Jacobo Aragunde Pérez 
>> wrote:

> On 02/02/17 13:46, Herve Jourdain wrote:
> Hi Jacobo,
>
> I'm using "master", and I do have patches for enabling armv7ve. But
>> since
> they're needed only for raspberrypi, I planned to submit them only for
> meta-raspberrypi.
> If you think it could be useful in meta-browser, though, I can submit
>> them there.
>

 Oh, I think sending them to meta-rpi would be good enough, thank you!
 I'll keep an eye on it.

 Best regards,
 --
 Jacobo Aragunde
 Software Engineer at Igalia


> -Original Message-
> From: Jacobo Aragunde Pérez [mailto:jaragu...@igalia.com]
> Sent: jeudi 2 février 2017 13:30
> To: openembedded-devel@lists.openembedded.org
> Cc: ota...@ossystems.com.br; Herve Jourdain 
> Subject: Re: [meta-browser][PATCH] chromium-wayland: fix compilation
>> problem on non-X11 builds
>
> Thank you all for your reviews. This should be the last patch, it
>> addresses Herve's problem when building on a Raspberry Pi.
>
> Unfortunately, I haven't been able to reproduce his problem myself,
>> but this patch is actually a backport of an upstream patch, so it makes no
>> harm in my opinion.
>
> Another question, are you using krogoth in you rpi build? I found
>> problems with the declared architecture in releases newer than jethro, it
>> is called "armv7ve" and chromium doesn't build because it expects "armv7a".
>> We could use a patch if you have worked around this problem :)
>
> Thanks again,
> --
> Jacobo Aragunde
> Software Engineer at Igalia
>
>
>> On 02/02/17 13:17, Jacobo Aragunde Pérez wrote:
>> Certain build configurations enable a code path that includes
>> keyboard_code_conversion_xkb.cc, but it eventually fails in non-X11
>> environments because of a missing patch that is present upstream.
>>
>> This commit adds the missing patch from
>> https://codereview.chromium.org/2239833003
>>
>> There are two versions of the patch in the code review URL above.
>> The first version fixes the problem both under the gyp and GN build
>> systems. That patch was rejected because gyp is considered deprecated
>> upstream. The second version fixes the problem only on GN and it was
>> merged upstream. We are picking the first version because our recipes
>> still use gyp to build.
>>
>> Signed-off-by: Jacobo Aragunde Pérez 
>> ---
>> .../chromium/chromium-wayland_53.0.2785.143.bb |  1 +
>> .../fix-non-x11-build-when-use_xkbcommon-1.patch   | 51
>> ++
>> 2 files changed, 52 insertions(+)
>> create mode 100644 recipes-browser/chromium/
>> chromium/chromium-wayland/fix-non-x11-build-when-use_xkbcommon-1.patch
>>
>> diff --git a/recipes-browser/chromium/chr
>> omium-wayland_53.0.2785.143.bb b/recipes-browser/chromium/chr
>> omium-wayland_53.0.2785.143.bb
>> index a75918b..ef913a7 100644
>> --- a/recipes-browser/chromium/chromium-wayland_53.0.2785.143.bb
>> +++ b/recipes-browser/chromium/chromium-wayland_53.0.2785.143.bb
>> @@ -13,6 +13,7 @@ SRC_URI += "\
>> file://chromium-wayland/0011-Replace-readdir_r-with-readdir.patch
>> \
>> file://chromium-wayland/remove-Werror.patch \
>> file://chromium-wayland/guard-x11_desktop_handler-inclusion.patch
>> \
>> +
>> file://chromium-wayland/fix-non-x11-build-when-use_xkbcommon-1.patch
>> \
>> ${@bb.utils.contains('PACKAGECONFIG', 'component-build',
>> 'file://component-build.gypi', '', d)} \
>> ${@bb.utils.contains('PACKAGECONFIG', 'ignore-lost-context',
>> 'file://0001-Remove-accelerated-Canvas-support-from-blacklist.patch', '',
>> d)} \
>> "
>> diff --git a/recipes-browser/chromium/chromium/chromium-wayland/fix-
>> non-x11-build-when-use_xkbcommon-1.patch 

Re: [oe] [meta-browser][PATCH] chromium-wayland: fix compilation problem on non-X11 builds

[Martin Jansa]

It still fails for qemux86 as reported in:
http://lists.openembedded.org/pipermail/openembedded-devel/2017-February/111221.html

can someone please look into it?

On Wed, Feb 15, 2017 at 7:17 PM, Jacobo Aragunde Pérez  wrote:

> Hi everyone!
>
> The patch in this thread has been recently merged. Thanks for your review!
>
> On 02/02/17 16:33, Herve Jourdain wrote:
> > Hi Jacobo,
> >
> > OK, I will send those extra patched to the meta-raspberry list tomorrow
> then.
> >
>
> Sorry to ping you again on this, Herve O:-) I haven't found your patches
> around in yocto ML and I would like to try them. May I be following the
> wrong ML?
>
> Thanks in advance,
> --
> Jacobo Aragunde
> Software Engineer at Igalia
>
>
> >> On 2 Feb 2017, at 21:28, Jacobo Aragunde Pérez 
> wrote:
> >>
> >>> On 02/02/17 13:46, Herve Jourdain wrote:
> >>> Hi Jacobo,
> >>>
> >>> I'm using "master", and I do have patches for enabling armv7ve. But
> since
> >>> they're needed only for raspberrypi, I planned to submit them only for
> >>> meta-raspberrypi.
> >>> If you think it could be useful in meta-browser, though, I can submit
> them there.
> >>>
> >>
> >> Oh, I think sending them to meta-rpi would be good enough, thank you!
> >> I'll keep an eye on it.
> >>
> >> Best regards,
> >> --
> >> Jacobo Aragunde
> >> Software Engineer at Igalia
> >>
> >>
> >>> -Original Message-
> >>> From: Jacobo Aragunde Pérez [mailto:jaragu...@igalia.com]
> >>> Sent: jeudi 2 février 2017 13:30
> >>> To: openembedded-devel@lists.openembedded.org
> >>> Cc: ota...@ossystems.com.br; Herve Jourdain 
> >>> Subject: Re: [meta-browser][PATCH] chromium-wayland: fix compilation
> problem on non-X11 builds
> >>>
> >>> Thank you all for your reviews. This should be the last patch, it
> addresses Herve's problem when building on a Raspberry Pi.
> >>>
> >>> Unfortunately, I haven't been able to reproduce his problem myself,
> but this patch is actually a backport of an upstream patch, so it makes no
> harm in my opinion.
> >>>
> >>> Another question, are you using krogoth in you rpi build? I found
> problems with the declared architecture in releases newer than jethro, it
> is called "armv7ve" and chromium doesn't build because it expects "armv7a".
> We could use a patch if you have worked around this problem :)
> >>>
> >>> Thanks again,
> >>> --
> >>> Jacobo Aragunde
> >>> Software Engineer at Igalia
> >>>
> >>>
>  On 02/02/17 13:17, Jacobo Aragunde Pérez wrote:
>  Certain build configurations enable a code path that includes
>  keyboard_code_conversion_xkb.cc, but it eventually fails in non-X11
>  environments because of a missing patch that is present upstream.
> 
>  This commit adds the missing patch from
>  https://codereview.chromium.org/2239833003
> 
>  There are two versions of the patch in the code review URL above.
>  The first version fixes the problem both under the gyp and GN build
>  systems. That patch was rejected because gyp is considered deprecated
>  upstream. The second version fixes the problem only on GN and it was
>  merged upstream. We are picking the first version because our recipes
>  still use gyp to build.
> 
>  Signed-off-by: Jacobo Aragunde Pérez 
>  ---
>  .../chromium/chromium-wayland_53.0.2785.143.bb |  1 +
>  .../fix-non-x11-build-when-use_xkbcommon-1.patch   | 51
> ++
>  2 files changed, 52 insertions(+)
>  create mode 100644 recipes-browser/chromium/
> chromium/chromium-wayland/fix-non-x11-build-when-use_xkbcommon-1.patch
> 
>  diff --git a/recipes-browser/chromium/chr
> omium-wayland_53.0.2785.143.bb b/recipes-browser/chromium/chr
> omium-wayland_53.0.2785.143.bb
>  index a75918b..ef913a7 100644
>  --- a/recipes-browser/chromium/chromium-wayland_53.0.2785.143.bb
>  +++ b/recipes-browser/chromium/chromium-wayland_53.0.2785.143.bb
>  @@ -13,6 +13,7 @@ SRC_URI += "\
>  file://chromium-wayland/0011-Replace-readdir_r-with-readdir.patch
> \
>  file://chromium-wayland/remove-Werror.patch \
>  file://chromium-wayland/guard-x11_desktop_handler-inclusion.patch
> \
>  +
>  file://chromium-wayland/fix-non-x11-build-when-use_xkbcommon-1.patch
> \
>  ${@bb.utils.contains('PACKAGECONFIG', 'component-build',
> 'file://component-build.gypi', '', d)} \
>  ${@bb.utils.contains('PACKAGECONFIG', 'ignore-lost-context',
> 'file://0001-Remove-accelerated-Canvas-support-from-blacklist.patch', '',
> d)} \
>  "
>  diff --git a/recipes-browser/chromium/chromium/chromium-wayland/fix-
> non-x11-build-when-use_xkbcommon-1.patch b/recipes-browser/chromium/
> chromium/chromium-wayland/fix-non-x11-build-when-use_xkbcommon-1.patch
>  new file mode 100644
>  index 000..976ece9
>  --- /dev/null
>  +++ 

Re: [oe] [meta-browser][PATCH] chromium-wayland: fix compilation problem on non-X11 builds

[Jacobo Aragunde Pérez]

Hi everyone!

The patch in this thread has been recently merged. Thanks for your review!

On 02/02/17 16:33, Herve Jourdain wrote:
> Hi Jacobo,
> 
> OK, I will send those extra patched to the meta-raspberry list tomorrow then.
> 

Sorry to ping you again on this, Herve O:-) I haven't found your patches
around in yocto ML and I would like to try them. May I be following the
wrong ML?

Thanks in advance,
-- 
Jacobo Aragunde
Software Engineer at Igalia


>> On 2 Feb 2017, at 21:28, Jacobo Aragunde Pérez  wrote:
>>
>>> On 02/02/17 13:46, Herve Jourdain wrote:
>>> Hi Jacobo,
>>>
>>> I'm using "master", and I do have patches for enabling armv7ve. But since
>>> they're needed only for raspberrypi, I planned to submit them only for
>>> meta-raspberrypi.
>>> If you think it could be useful in meta-browser, though, I can submit them 
>>> there.
>>>
>>
>> Oh, I think sending them to meta-rpi would be good enough, thank you!
>> I'll keep an eye on it.
>>
>> Best regards,
>> -- 
>> Jacobo Aragunde
>> Software Engineer at Igalia
>>
>>
>>> -Original Message-
>>> From: Jacobo Aragunde Pérez [mailto:jaragu...@igalia.com] 
>>> Sent: jeudi 2 février 2017 13:30
>>> To: openembedded-devel@lists.openembedded.org
>>> Cc: ota...@ossystems.com.br; Herve Jourdain 
>>> Subject: Re: [meta-browser][PATCH] chromium-wayland: fix compilation 
>>> problem on non-X11 builds
>>>
>>> Thank you all for your reviews. This should be the last patch, it addresses 
>>> Herve's problem when building on a Raspberry Pi.
>>>
>>> Unfortunately, I haven't been able to reproduce his problem myself, but 
>>> this patch is actually a backport of an upstream patch, so it makes no harm 
>>> in my opinion.
>>>
>>> Another question, are you using krogoth in you rpi build? I found problems 
>>> with the declared architecture in releases newer than jethro, it is called 
>>> "armv7ve" and chromium doesn't build because it expects "armv7a". We could 
>>> use a patch if you have worked around this problem :)
>>>
>>> Thanks again,
>>> --
>>> Jacobo Aragunde
>>> Software Engineer at Igalia
>>>
>>>
 On 02/02/17 13:17, Jacobo Aragunde Pérez wrote:
 Certain build configurations enable a code path that includes
 keyboard_code_conversion_xkb.cc, but it eventually fails in non-X11
 environments because of a missing patch that is present upstream.

 This commit adds the missing patch from
 https://codereview.chromium.org/2239833003

 There are two versions of the patch in the code review URL above.
 The first version fixes the problem both under the gyp and GN build
 systems. That patch was rejected because gyp is considered deprecated
 upstream. The second version fixes the problem only on GN and it was
 merged upstream. We are picking the first version because our recipes
 still use gyp to build.

 Signed-off-by: Jacobo Aragunde Pérez 
 ---
 .../chromium/chromium-wayland_53.0.2785.143.bb |  1 +
 .../fix-non-x11-build-when-use_xkbcommon-1.patch   | 51 
 ++
 2 files changed, 52 insertions(+)
 create mode 100644 
 recipes-browser/chromium/chromium/chromium-wayland/fix-non-x11-build-when-use_xkbcommon-1.patch

 diff --git a/recipes-browser/chromium/chromium-wayland_53.0.2785.143.bb 
 b/recipes-browser/chromium/chromium-wayland_53.0.2785.143.bb
 index a75918b..ef913a7 100644
 --- a/recipes-browser/chromium/chromium-wayland_53.0.2785.143.bb
 +++ b/recipes-browser/chromium/chromium-wayland_53.0.2785.143.bb
 @@ -13,6 +13,7 @@ SRC_URI += "\
 file://chromium-wayland/0011-Replace-readdir_r-with-readdir.patch \
 file://chromium-wayland/remove-Werror.patch \
 file://chromium-wayland/guard-x11_desktop_handler-inclusion.patch \
 +
 file://chromium-wayland/fix-non-x11-build-when-use_xkbcommon-1.patch \
 ${@bb.utils.contains('PACKAGECONFIG', 'component-build', 
 'file://component-build.gypi', '', d)} \
 ${@bb.utils.contains('PACKAGECONFIG', 'ignore-lost-context', 
 'file://0001-Remove-accelerated-Canvas-support-from-blacklist.patch', '', 
 d)} \
 "
 diff --git 
 a/recipes-browser/chromium/chromium/chromium-wayland/fix-non-x11-build-when-use_xkbcommon-1.patch
  
 b/recipes-browser/chromium/chromium/chromium-wayland/fix-non-x11-build-when-use_xkbcommon-1.patch
 new file mode 100644
 index 000..976ece9
 --- /dev/null
 +++ 
 b/recipes-browser/chromium/chromium/chromium-wayland/fix-non-x11-build-when-use_xkbcommon-1.patch
 @@ -0,0 +1,51 @@
 +From: jbriance 
 +Subject: keycodes: Fix non-X11 build when use_xkbcommon=1
 +
 +Since M51, ui/events/keycodes/xkb_keysym.h follows X11 path, even if
 +use_xkbcommon=1 is set because USE_XKBCOMMON is not defined, leading
 +to the following compilation error in 

Re: [oe] [meta-browser][PATCH] chromium-wayland: fix compilation problem on non-X11 builds

[Jacobo Aragunde Pérez]

Hi again!

I've finally been able to reproduce the problem and acknowledge the
patch fixes it.

It should affect any build that doesn't contain X11 libs, in my case it
was the GENIVI platform for a Minnowboard. I don't even know how I
didn't trigger it before.

Best,
-- 
Jacobo Aragunde
Software Engineer at Igalia


On 02/02/17 13:17, Jacobo Aragunde Pérez wrote:
> Certain build configurations enable a code path that includes
> keyboard_code_conversion_xkb.cc, but it eventually fails in non-X11
> environments because of a missing patch that is present upstream.
> 
> This commit adds the missing patch from
> https://codereview.chromium.org/2239833003
> 
> There are two versions of the patch in the code review URL above.
> The first version fixes the problem both under the gyp and GN build
> systems. That patch was rejected because gyp is considered deprecated
> upstream. The second version fixes the problem only on GN and it was
> merged upstream. We are picking the first version because our recipes
> still use gyp to build.
> 
> Signed-off-by: Jacobo Aragunde Pérez 
> ---
>  .../chromium/chromium-wayland_53.0.2785.143.bb |  1 +
>  .../fix-non-x11-build-when-use_xkbcommon-1.patch   | 51 
> ++
>  2 files changed, 52 insertions(+)
>  create mode 100644 
> recipes-browser/chromium/chromium/chromium-wayland/fix-non-x11-build-when-use_xkbcommon-1.patch
> 
> diff --git a/recipes-browser/chromium/chromium-wayland_53.0.2785.143.bb 
> b/recipes-browser/chromium/chromium-wayland_53.0.2785.143.bb
> index a75918b..ef913a7 100644
> --- a/recipes-browser/chromium/chromium-wayland_53.0.2785.143.bb
> +++ b/recipes-browser/chromium/chromium-wayland_53.0.2785.143.bb
> @@ -13,6 +13,7 @@ SRC_URI += "\
>  file://chromium-wayland/0011-Replace-readdir_r-with-readdir.patch \
>  file://chromium-wayland/remove-Werror.patch \
>  file://chromium-wayland/guard-x11_desktop_handler-inclusion.patch \
> +file://chromium-wayland/fix-non-x11-build-when-use_xkbcommon-1.patch 
> \
>  ${@bb.utils.contains('PACKAGECONFIG', 'component-build', 
> 'file://component-build.gypi', '', d)} \
>  ${@bb.utils.contains('PACKAGECONFIG', 'ignore-lost-context', 
> 'file://0001-Remove-accelerated-Canvas-support-from-blacklist.patch', '', d)} 
> \
>  "
> diff --git 
> a/recipes-browser/chromium/chromium/chromium-wayland/fix-non-x11-build-when-use_xkbcommon-1.patch
>  
> b/recipes-browser/chromium/chromium/chromium-wayland/fix-non-x11-build-when-use_xkbcommon-1.patch
> new file mode 100644
> index 000..976ece9
> --- /dev/null
> +++ 
> b/recipes-browser/chromium/chromium/chromium-wayland/fix-non-x11-build-when-use_xkbcommon-1.patch
> @@ -0,0 +1,51 @@
> +From: jbriance 
> +Subject: keycodes: Fix non-X11 build when use_xkbcommon=1
> +
> +Since M51, ui/events/keycodes/xkb_keysym.h follows X11 path, even if
> +use_xkbcommon=1 is set because USE_XKBCOMMON is not defined, leading
> +to the following compilation error in this case:
> +
> +  In file included from 
> ../../ui/events/keycodes/keyboard_code_conversion_xkb.h:12:0,
> +   from 
> ../../ui/events/keycodes/keyboard_code_conversion_xkb.cc:5:
> +  ../../ui/events/keycodes/xkb_keysym.h:19:19: fatal error: X11/X.h: No such 
> file or directory
> +
> +BUG=none
> +
> +Review-Url: https://codereview.chromium.org/2239833003
> +--
> +
> +Index: ui/events/keycodes/BUILD.gn
> +diff --git a/ui/events/keycodes/BUILD.gn b/ui/events/keycodes/BUILD.gn
> +index 
> 4f2d47c2497d321332c79d0dd4e9007b50c319c7..716c7ed17cc8049ea65b95a5062e7c6e0adc6e48
>  100644
> +--- a/ui/events/keycodes/BUILD.gn
>  b/ui/events/keycodes/BUILD.gn
> +@@ -17,6 +17,10 @@ source_set("xkb") {
> + "//base",
> + "//ui/events:dom_keycode_converter",
> +   ]
> ++
> ++  if (use_xkbcommon) {
> ++defines = [ "USE_XKBCOMMON" ]
> ++  }
> + }
> + 
> + if (use_x11 || ozone_platform_x11) {
> +Index: ui/events/keycodes/events_keycodes.gyp
> +diff --git a/ui/events/keycodes/events_keycodes.gyp 
> b/ui/events/keycodes/events_keycodes.gyp
> +index 
> b0796b4e2ead8bffe88fb01ed136814be505d967..248e961bad2ad3996ca99624b6c489c7835f6241
>  100644
> +--- a/ui/events/keycodes/events_keycodes.gyp
>  b/ui/events/keycodes/events_keycodes.gyp
> +@@ -21,6 +21,13 @@
> + 'scoped_xkb.h',
> + 'xkb_keysym.h',
> +   ],
> ++  'conditions': [
> ++['use_xkbcommon==1', {
> ++  'defines': [
> ++'USE_XKBCOMMON',
> ++  ],
> ++}],
> ++  ],
> + },
> +   ],
> +   'conditions': [
> 

-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel