chromium: Update to a new version

[rakuco]

Additional context in this oe-devel thread.

We're currently still packaging Chromium M54 and Chromium M53 + ozone-wayland, both of which are ancient releases by Chromium's standards.

I've done the work to move the existing recipe to M62 (the current stable milestone upstream) based on my own recipe, we now need to break up the ~60 commits in my branch into logical chunks and start merging them.

Depending on how long it takes to get everything merged, we might need to move to M63 directly.

This is a meta issue to track everything we need to do in terms of splitting up the existing commits in my chromium62 branch:

• [x] Drop the ozone-wayland recipe. oz-wl has been unmaintained upstream for years and there is no point in trying to get it to work with M62 or later. Doing so allows us to greatly simplify the rest of the recipe.
• [x] Actual recipe bug fixes that also apply to M54.
• [x] Remove unnecessary patches, as well as patches that can be replaced by gyp options.
• [x] Recipe simplification: drop a few checks for things we build unconditionally, stop setting a few variables here and there, adjust installation directory layout.
• [x] Adjust recipe dependencies: add implicit ones, remove unnecessary ones.
• [x] Move to GN, still on M54. Also requires some additional recipe simplification.
• [x] Move to M62 (should be easy once everything else is done).

[rakuco]

@jaragunde @twoerner @kraj

[twoerner]

I've don't use wayland, so I'm not interested in ozone-wayland. But if the wayland stuff still works then I'm not opposed to keeping it as its own recipe, stuck at version 53. If it doesn't work then we should get rid of it in master and provide a check in the new chromium6x recipe to make sure the user isn't trying to build against wayland.

[rakuco]

I think it currently works in the sense that right now master builds with it, but I've never tried it myself and am not a big fan of the idea of shipping a dangerously old and insecure Chromium version.

All the other changes I've made depend on getting rid of the existing oz-wl recipe to simplify the main recipe and allow us to move to a newer release, so if anything I'd rather have a completely separate recipe (i.e. recipes-browser/chromium-ozone-wayland) with a copy of what we have at the moment than having to deal with it in recipes-browser/chromium.

[twoerner]

I'd be in favour of moving the ozone-wayland stuff to a different directory. We could even provide a warning in the top-level README and that's printed during build-time to let people know this is old, unsupported, and insecure?

[rakuco]

Works for me as long as I don't have to deal with it later :-) @otavio: any strong opinions here?

[twoerner]

I'm not sure it's worth the work to move so slowly from 54 to 6x. At this point I'm thinking more along the lines of a whole-sale replacement of the existing stuff with the new stuff. From my point of view (and maybe I'm not fully informed) the only things to consider keeping from the current build are:

• the build progress (do_compile[progress])
• how to migrate the current package configuration options (PACKAGECONFIG). Some of these options are already in the new build, some don't make sense anymore, some are most likely not used anymore
• musl support (there's a can of worms... if musl support is going to be easy then it's a win, if it's going to hold us up for weeks and be a constant source of pain then my previously-expressed feelings for musl support outside meta-musl become more valid)

[rakuco]

I'm not sure it's worth the work to move so slowly from 54 to 6x. At this point I'm thinking more along the lines of a whole-sale replacement of the existing stuff with the new stuff.

It's all done, see my message to openembedded-devel. I've even split my commits into separate chunks corresponding to the items I listed above.

• how to migrate the current package configuration options (PACKAGECONFIG). Some of these options are already in the new build, some don't make sense anymore, some are most likely not used anymore

I've removed "ignore-lost-context" and mentioned considering removing a few others in the future in my mailing list message.

• musl support (there's a can of worms... if musl support is going to be easy then it's a win, if it's going to hold us up for weeks and be a constant source of pain then my previously-expressed feelings for musl support outside meta-musl become more valid)

I also commented on that in my original email. musl + M62 is currently broken. I didn't remove the musl bits from the recipe (in fact I even added a few patches and configuration lines to help), but I believe the amount of work required to get it to build (let alone run properly) is quite big, especially if there's nobody working on proper musl support upstream.

[otavio]

Honestly, @twoerner, the Wayland is old and mostly untested. Also, keeping an untested recipe is bad.

The meta-freescale patches don't apply anymore and anything using it must be upgraded. I prefer to drop it and if someone wishes to use it, well ... Git is your friend!

I think if we can keep the layer clean, it helps, as we can start moving faster with the releases. Also, it removes a lot of code and complexity.

[twoerner]

Ah, sorry. I hadn't seen the posting to oe-devel. @rakuco , I've looked through much of your work and I think this work is utterly brilliant!!

I have some small questions:

• should the contents of the README in recipes-browser/chromium simply be merged with the top-level README?
• there should be a note in somewhere explaining that a "large" machine is required to build chromium (lots of memory) and that currently the build can only be performed on a 64-bit x86_64 machine

[otavio]

• should the contents of the README in recipes-browser/chromium simply be merged with the top-level README?

My vote is yes; or a Wiki page.

• there should be a note in somewhere explaining that a "large" machine is required to build chromium (lots of memory) and that currently the build can only be performed on a 64-bit x86_64 machine

This also should be part of root README, in my point of view.

[twoerner]

One other very small nit, that maybe isn't necessarily part of this effort, but maybe it is. I've long been annoyed by the directory name "recipes-browser". We should probably rename the recipes-browser directory to something less confusing? Maybe recipes-google or recipes-chromium? Then the gn stuff in recipes-browser/chromium could be moved to, say, recipes-chromium/tools?

[otavio]

When I did this, my idea was to have multiple browsers there. I am not against moving it and having a recipes-chromium and recipes-mozilla ... but if it was up to me, I'd put it under recipes-core or recipes-browser.

[twoerner]

Oh, and we probably also need to note that the host system's native gcc (g++?) needs to support.... ? What did it need to support again? IOW you need at least gcc5 or gcc6 installed natively.

[r1mikey]

I have a strong preference for keeping the Ozone Wayland recipe around, but I do understand if the community does not see value in it, and would for the existing recipe until such time as enough of the Igalia work is available in upstream Chromium.

[r1mikey]

@twoerner In my experience, at least native g++5.x is needed for the -std=c++11 functionality.

[rakuco]

I have a strong preference for keeping the Ozone Wayland recipe around, but I do understand if the community does not see value in it, and would for the existing recipe until such time as enough of the Igalia work is available in upstream Chromium.

I'm not the best person to comment on Igalia's work, but they've been publishing their own recipe for Chromium + Wayland upstream snapshots at https://github.com/Igalia/chromium, and we all hope they're able to simplify their recipe and base it on the work done here.

+@tonikitoo, @jdapena

[otavio]

Independently, maintaining an old recipe consumes time and effort also it requires test. The recipe will be kept in Git history so if someone wishes to use it, it is possible. For now, leverage the Chromium recipe and boost the recipe quality, reducing duplicated work and making future upgrades easier seems to be the way to go.

So I am in agreement in dropping Wayland support for now and also try to get Igalia guys involved to get Wayland merged here, in the new base.

[otavio]

@rakuco please keep the good work. @twoerner talked to me privately and we are on the same page.

Please send the next pull request ;-)

[tonikitoo]

from our side (igalia), we still have interest in the old wayland recipe, while upstream isn't wayland capable, but, it should be easily recoverable from the git history.

/cc @jdapena @msisov

[otavio]

@tonikitoo agreed; but using the Git history for that makes sense, don't you think? It allows for a cleaner baseline and also reduces boilerplate and duplication.

@tonikitoo how far is to get something we can use? even if it is a set of patches.

[otavio]

@rakuco thanks for all those changes. Up to now, it has been an easy work as you did a very good job at splitting it in logical patchsets :-) :+1:

[rakuco]

Thanks. It definitely took a lot longer than I anticipated back in September, but I'm glad the effort's paying off now :-)

[tonikitoo]

@otavio : we have Chromium/Wayland from https://github.com/Igalia/chromium/ pretty usable on gnome-wayland Desktop, with a baseline chromium of yesterday (Nov/12) - tested on fedora 25-27, Debing testing and Ubuntu 17.04/10.

On meta-browser land, our primarily target is ARM64, and we've reworked/forked the meta-browser from Dec/2016, to get our build going: https://github.com/Igalia/meta-browser . This includes arm64, GN and our new Chromium/Wayland baseline.

That all being said, now that meta-browser upstream has moved forward (and deleted the support for the old Ozone/Wayland work), we plan to contribute Chromium/Wayland (and eliminate our fork altogether) in Q4/2017.

[otavio]

@tonikitoo that's our goal. We should work together to avoid the fork need and easy people to get going with the outstanding work you guys been doing.

[otavio]

I think we are done. I will close this issue so we can track any rework as new issues.

[rakuco]

Thanks, everyone!