Page MenuHomeSolus

Initial inclusion of chromium

Authored by joebonrichie on Sep 12 2017, 10:45 AM.
Referenced Files
F10832137: D985.id2664.diff
Mon, Jun 5, 9:25 PM
F10829561: D985.id2434'nvOpzp; AND 1=1 OR (<'">iKO)),.diff
Sun, Jun 4, 1:00 PM
F10829560: D985.id2434.diff
Sun, Jun 4, 1:00 PM
F10829504:'nvOpzp; AND 1=1 OR (<'">iKO)),.diff
Sun, Jun 4, 12:41 PM
F10829283: D985.id2313.diff
Sun, Jun 4, 11:41 AM
F10828623: D985.id6546.diff
Sun, Jun 4, 9:54 AM
F10828538: D985.id6546.diff
Sun, Jun 4, 9:41 AM
F10828435: D985.id9681.diff
Sun, Jun 4, 9:24 AM
"Like" token, awarded by pappfer."Like" token, awarded by Botanium."Love" token, awarded by gnumdk."Love" token, awarded by Nikki1993."Like" token, awarded by fagoatse."Cup of Joe" token, awarded by kyrios123.


Group Reviewers
Triage Team
Maniphest Tasks
T6348: chromedriver
T233: Chromium

Chromium is the open-source version of Google Chrome. Fixes T233.

Notes of interest:

  • Widevine support is enabled but not shipped due to distribution restrictions, you can copy from google-chrome to enable it.
  • Headless shell support is enabled.
  • chromedriver is provided. Fixes T6348.
  • Expects PPAPI Pepper flash to be installed to /usr/lib64/PepperFlash for automatic support.
  • In the future a remoting desktop subpackage is planned (T1912).
Test Plan

Several months using as a daily driver.

Diff Detail

No Lint Coverage
No Test Coverage

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

At minimum I need a newer version of harfbuzz and API keys sorted to put this in the repo. The Remote Web and Headless subpackages can be finished at a later time (they actually add a lot of complexity to the build process)

Update to 64.0.3282.167
Switch to ChromeOS ffmpeg branding for testing

joebonrichie edited the summary of this revision. (Show Details)

Comment items to be completed at a later date

Drop unnecessary patch
Use personal API keys

joebonrichie edited the summary of this revision. (Show Details)

Clean up commit message ready for inclusion

Update to 64.0.3282.186 latest stable

Move api keys to a seperate file

Update to 65.0.3325.146 stable

  • Add new build fix patches and remove old ones
  • Remove pstables.h build hack (fixed upstream)

Remove unneeded build patch from v64
Remove harfbuzz-ng from third party keepers (circular dependancy issue fixed upstream)

Update to 65.0.3325.162 stable

Update to 65.0.3325.181
Remove obsolete build flag

Rebuild against libicu 60.2
Enable system libvpx

Is there something missing for this task? Chromium is the only software missing for me in Solus (and Google Chrome is not an alternative).

@gnumdk we need to obtain api keys from google with permission to distribute. We also need to update our tooling to hide the api keys from the public repo and public build log.

@gnumdk we need to obtain api keys from google with permission to distribute. We also need to update our tooling to hide the api keys from the public repo and public build log.

The second part is not necessary if we get the permission from google.

Enable is_offical_build

  • You no longer need to be a googler to enable this flag, this enables all buildflags used for offical chrome releases.
  • Enables thin lto
  • Enables Control Flow Integrity learn more
  • Enables a bunch of other shite I can't remember
  • Clean up build flags as offical build auto enables most things.
  • No longer disable unsupported buildflags
  • Add sed hack from arch to support using system libs with offical build enabled

Requires clang 6.0.0

Update to 66.0.3359.139 latest stable
Rebuild against LLVM 6
Enable system libpng
Enable system openjpeg
Rebase patches and update as required (thanks debian and Arch)

Disable is_component_ffmpeg and -ffmpeg subpackage for now as we have ffmpeg-chromium and package conflicts are annoying
Re-enable VAAPI hw video decoding for testing (off by default, enable via chrome://flags)

Update to 66.0.3359.170 latest stable release

Update to 67.0.3396.62
Rebase and update patches as required
Build with system flags
Adjust for upstream widevine changes

Disable use of systemflags simply because i can't get ccache to work with this questionable build system

Update to 67.0.3396.79 latest stable
Re-enable experiantal optional VAAPI HW decoding

Any news on when this will be merged?

No movement on the api key situation which is the blocker. Potentially could ask them myself for keys which are allowed to distribute so we wouldn't have to put in new infrastructure to hide them but I'm only an half-official member of the team so it doesn't seem right that I should.

IIRC, we need keys specially given to us which don't have:-

  • Query limits for using Google services
  • Which are allowed to distribute (if we don't put in new infrastructure to hide them)

We are also well within ours rights to patch away the annoying 'you don't have api keys to use google servies' comment and ship it without keys which would severely hamper the using of Google services but users could obtain their own keys. For obvious reasons that's not really a viable solution.

Let’s hope this gets sorted some time soon then and thanks for the answer ?

joebonrichie edited the summary of this revision. (Show Details)

Update to 67.0.3396.87
Initial support for headless chromium, see here
Small cleanups

joebonrichie edited the summary of this revision. (Show Details)

Rebuild against libicu 61.1
Initial support for chromium-launcher wrapper which automatically enables flash support if PPAPI flash is installed to an expected location, as well as support for passing a flags.conf file.

Just wondering how you are doing the ( step on Solus where you pull the required dependencies to chromium? Tried building chromium myself but failed at that step sadly... @joebonrichie

Why are we building Chromium from source? Aren’t there binaries available?

Have you asked about the API key situation yet?

In D985#52301, @Snuggle wrote:

Why are we building Chromium from source? Aren’t there binaries available?

Have you asked about the API key situation yet?

binaries are evil, you can't control how they have been build and that the source haven't been altered.

joebonrichie edited the test plan for this revision. (Show Details)

Update to 67.0.3396.99
Fix xml pages with system libxml

joebonrichie edited the summary of this revision. (Show Details)
joebonrichie edited the test plan for this revision. (Show Details)

Update summary and test plan

Update to 69.0.3497.92
Refresh patches as normal
Use bundled vpx (development is done in-tree)
Build against libicu 62.1

Update to 69.0.3497.100
Use bundled zlib as their exists several x86 optimizations which will not be in upstream for a long time.

Update to 70.0.3538.67
Rebuild against system icu
Usual new patches and rebasing to fix compile errors
Requires a newer harfbuzz

Update to 71.0.3578.98
Refresh patches

Requires harfbuzz 2.0.0 or later

It is my opinion that this patch should be closed in light of recent news of Google's planned removal of "access from Chromium and Chromium OS derivatives that used google_default_client_id and google_default_client_secret on their build configuration to Google-exclusive APIs" in March. The primary blocker to landing this in the first place was actually the acquisition of these keys precisely for the functionality I elaborate on below, and without it I see zero reason to include Chromium.

These "Google-exclusive" APIs center around Google Sync, synchronization functionality in Chromium and Google Chrome that enable the user to log in with their Google account and synchronize their bookmarks, history, passwords, settings, extensions, and more. This functionality helps users transition from Google Chrome to Chromium, without it they are not able to keep this data in sync between multiple clients, whether that be desktop or mobile clients.

There will be no impact to users, as this software has never landed. The chromium-ffmpeg package will be unaffected. We will continue to provide Google Chrome via Third Party and browsers such as Vivaldi use their own synchronization platform (I can't speak for Brave on that).

  • A discussion by Arch Linux maintainers indicate that it should be dropped rather than putting themselves in legal jeopardy by instead using Google Chrome's keys.
  • Fedora may drop it as well, with Flathub possibly shipping Chromium without the sync functionality
  • Slackware maintainer's words on the matter: "I honestly see no reason to continue compiling and packaging Chromium for Slackware if the Google developers present in this group confirm this policy change by Google."

We would have likely needed an increased quota allowance regardless from google but that's a moot point now.
There are still some users who may want this package:-

  • Users wanting better performance than firefox
  • Users who minimally use google services and don't sign in (ungoogled-chromium?)
  • Potential that some website only work in chrome/chromium and not firefox (do these websites work with chromium derivatives like vivaldi and opera?)

We should also probably get the chromium flatpak at least working as the performance of snaps is literally dreadful and not everybody wants to use the chrome binary.

I believe this or ungoogled-chromium could still land if there is enough interest in it with the main blocker from this package gone. The blocker for ungoogled-chromium was them not keeping up with new releases quick enough (and thus leaving open CVEs) with the other being some functionality was missing. However, a new maintainer will need to be found (keeping this maintained was a burden and I relied heavily on Arch and Debian patches)

With that being said I'm still open to closing this for now. Any users who still want this would need to speak up and a new maintainer would need to be found. Might be worth reaching out to forum to gauge opinions.

If we're going to be shipping Chromium in the repository, it should be Chromium proper rather than ungoogled-chromium. We're not a privacy centric operating system and I wouldn't want us to have to rely on someone updating their patchset of an entire browser just to roll out updates, including potentially security fixes.

The argument around performance is valid, however that can already be satisfied with Google Chrome proper, as well as Chromium-based browsers already in the repository. I have no strong preference on the matter, but unless the person that is going to maintain it will do so borderline religiously, it isn't something I'd want to land in the first place, as the responsibility would just end up falling on Global Maintainers and Core Team, which have enough responsibility as is.

As long as (1) someone wants to maintain it and (2) people are willing to deal with the limitations, I don't really see the harm in including it. I still see there being benefits to be compiled on Solus for Solus. ungoogled-chromium has already been addressed several times and at least once by me personally. Sacrificing security for privacy is short-sighted.

Yea at this stage it's more just someone stepping up that wants to use Chromium and actively maintain this. I really appreciate all the work Joe has done on this patch and will be closing it per his earlier O.K. on the matter. Should someone step up, they are certainly welcome to use this patch as a reference point, though the build instructions, dependencies, and patches required are likely to be significantly different.

I'll be marking the Chromium task as Needs Maintainer.