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)

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.

In D985#42185, @joebonrichie wrote:

@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.

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 ?

Just wondering how you are doing the (https://chromium.googlesource.com/chromium/src/+/lkcr/docs/linux_build_instructions.md#notes) 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.

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.