All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ian Coolidge <ian@boundarydevices.com>
To: Trevor Woerner <twoerner@gmail.com>
Cc: Otavio Salvador <otavio.salvador@ossystems.com.br>,
	openembedded-devel <openembedded-devel@lists.openembedded.org>
Subject: Re: [meta-browser] CFT: Chromium 62 in meta-browser
Date: Fri, 10 Nov 2017 16:10:16 -0800	[thread overview]
Message-ID: <CADseiP=dhrkCrqBnO+g-HZQZaGgf1ywZwFcd-0bpE9K-qhALPQ@mail.gmail.com> (raw)
In-Reply-To: <CAHUNapRKjZZ=yCYpfrm3CDVZez0JbLeaKHaZg2J3WhjBvRR6jg@mail.gmail.com>

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 <twoerner@gmail.com> wrote:

> Raphael,
>
> On Thu, Nov 9, 2017 at 11:28 AM, Raphael Kubo da Costa
> <raphael.kubo.da.costa@intel.com> 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
>


  reply	other threads:[~2017-11-11  0:10 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-09 16:28 [meta-browser] CFT: Chromium 62 in meta-browser Raphael Kubo da Costa
2017-11-09 16:54 ` Otavio Salvador
2017-11-09 17:08   ` Raphael Kubo da Costa
2017-11-10 19:49 ` Trevor Woerner
2017-11-11  0:10   ` Ian Coolidge [this message]
2017-11-11 17:25     ` Otavio Salvador
2017-11-13 21:51       ` Ian Coolidge
2017-11-13 21:56         ` Ian Coolidge
2017-11-15 12:04 ` Raphael Kubo da Costa
2017-11-15 12:38   ` Martin Jansa
2017-11-15 14:20     ` Martin Jansa
2017-11-15 17:08     ` Raphael Kubo da Costa
2017-11-15 17:41       ` Martin Jansa
2017-11-15 17:49         ` Kubo Da Costa, Raphael
2017-11-15 19:34         ` Khem Raj
2017-11-23 10:22           ` Ayoub Zaki
2017-11-28  0:52             ` Ian Coolidge
2017-11-28  8:13               ` Ayoub Zaki
2017-11-28 11:58                 ` Otavio Salvador
2017-11-28 12:47                   ` Ayoub Zaki
2017-11-28 13:05                     ` Otavio Salvador
2017-11-28 21:44                       ` Ian Coolidge
2017-12-11 11:30             ` Raphael Kubo da Costa
2017-12-11 11:35               ` Ayoub Zaki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CADseiP=dhrkCrqBnO+g-HZQZaGgf1ywZwFcd-0bpE9K-qhALPQ@mail.gmail.com' \
    --to=ian@boundarydevices.com \
    --cc=openembedded-devel@lists.openembedded.org \
    --cc=otavio.salvador@ossystems.com.br \
    --cc=twoerner@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.