Ungoogled-chromium: Update to version 66

[Eloston]

This issue tracks the upgrade progress to Chromium 66, subsequent revisions, and related discussion.

Here are the steps necessary towards the first release in the upgrade process:

• [x] Update common and other abstract base bundles
• [ ] Update other base bundles and associated packaging types:
  
  
  
  • [ ] Arch Linux
  
  
  • [x] Debian and Ubuntu
  
  
  • [x] macOS
  
  
  • [ ] openSUSE
  
  
  • [x] Portable Linux
  
  
  • [ ] Windows
  
  

NOTE: A base bundle is considered "updated" once its current configuration has been added/removed/changed to produce working builds (i.e. runs without severe regressions) on the new version. It does not always consider new Chromium features.

After the initial release is published, this issue will remain open for status updates and discussions relating to new revisions or the version as a whole. It will be closed once a new Specific problems should still be posted in a separate issue.

[Eloston]

Status update: The common base bundle has been updated. As such, I will begin work on Debian shortly. Feel free to submit PRs for other base bundles.

Due to 5c192485e446e90fde5df7c79ff428ffa7997012, linux_rooted is currently broken. The mentioned patch should be included soon.

[irlcatgirl]

@Eloston My knowledge of C++ is minimal. Is there any way I could help with the macOS patches.

[Eloston]

@nsuchy You don't need to know a lot of C++-specific knowledge; most problems depend more on knowledge of Chromium code and its structure rather than anything else. The way I learned is just by blindly diving in and reading the code or design docs as I need to. Granted, this is not a fast process.

If you're looking to contribute patches in the future, I'd suggest having a look at the current macOS patches and seeing how they work in the actual code. The kinds of problems we run into in new versions is pretty consistent from release to release. In addition, you can consider updating the patches yourself to see what the process is like and to see the kinds of errors you'll run into.

[tectiv3]

Built macOS using #401, so far so good.

[Eloston]

Status update: I've updated the statuses for macOS, Windows, and openSUSE. I've also started work on Debian/Ubuntu.

[squalus]

I've been using portable Linux for a while and I've had no problems. No changes were needed to get it to build

[Eloston]

Status update: I've incorporated changes from Debian, and ended up changing a few things in the process. Please re-test and let me know if anything broke.

Ubuntu and Debian buster support has been updated but not tested. Updated instructions are in BUILDING.md.

[Eloston]

My binaries of 66.0.3359.139-1 for Debian stretch and Linux portable are available for testing here.

[Eloston]

Status update: I've released 66.0.3359.139-1 and removed the updated status for platforms I don't have a working status confirmation.

[macandchief]

Those .deb files seem to be unavailable at the moment.

[squalus]

Windows looks fine to me: https://github.com/ungoogled-software/ungoogled-chromium-binaries/pull/16

[Eloston]

@macandchief I made a typo. The links are fixed.

[LeFroid]

@Eloston I'm not sure if this is related to the recent build configuration changes, but when I attempted to build version 66.0.3359.170 I ran into the following compilation error with the OpenSUSE config and LLVM/clang version 6.0.0: https://pastebin.com/PC74QWmq

Commenting out the troublesome call to base::Bind(..) allowed the build to complete, and I'm seeing if there is a more appropriate way to fix the issue.

[Eloston]

@LeFroid I just remembered that I changed openSUSE GN config to use the linux unbundle toolchain, so the exported compiler environment variable flags are now used to specify the compiler. Do the default flags there correctly use LLVM 6?

[Eloston]

I've been able to build and run 66.0.3359.170 on Debian without needing any changes on develop.

[LeFroid]

LLVM 6 was being used to compile the last version. I looked through the linux unbundle toolchain files and couldn't find anything apparent. I hadn't thought of it before, but maybe it's caused by the compiler flags that are set in the RPM spec file, as I'm seeing both '-std=gnu++14' and '-std=c++17' in the build output. For the next release I'll remove the compiler flag settings from the spec file to see if that was the cause.

[Tacolizard]

ubuntu 18.04 build has been working fine for me for around a week.

[Eloston]

Moving onto 67: #414