Project:Chromium/How to bump Chromium

From Gentoo Wiki
Jump to:navigation Jump to:search

Chromium (and its binary "friends") have a relatively straightforward, if time-consuming ebuild update process.

Stable Bump

First, check the Chrome Releases Blog to see if a new Stable or Beta update has been released.

This is typically as straightforward as copying the existing ebuild to the new version, ensuring the keywords are all reset to `~arch` and running a test build. It is worth checking if there is a new PPC64 patchset available.

If this build is the first in a new major version to be promoted to stable update the subslot to 0/stable.

While the build is progressing, log a Security bug to cover any CVEs (there are _tons_ of examples on b.g.o already)

Once the build completes successfully, pkgdev commit as usual, referencing the bug logged earlier. In the _very rare_ event that there are no weekly CVEs no bug is required.

Open the new Chromium and run some Speedometer (etc) tests and do some light browsing to be sure that it isn't _horribly_ broken, then push the release.

New Major Version

When a new major version has been released the process is slightly different.

First, run the package-chromium-ffmpeg.py script to generate an appropriate media-video/chromium-ffmpeg package for the major release. This is a dependency of the RESTRICT=binpkg path, and is required for several other Chromium-based browsers as they rebase on newer versions of Chromium. The ffmpeg commit is pinned for the duration of a major version (however if a CVE in ffmpeg in Chromium is listed do update this major version's commit hash and backport as far as can reasonably be tested).

Next copy the latest ebuild version to the new version. Run the get-chromium-toolchain-strings.py script to extract the new Rust and Clang versions - these will serve as fallback compilers in case system Clang (or Rust) is unsuitable for some reason -system-toolchain.

These compiler versions appear to be pinned for the duration of a Major version and typically do not need to be changed.

Update these values, set the (sub)SLOT to 0/beta. While in the ebuild try and take care of a TODO.

Generate a manifest for the ebuild and start an ebuild chromium-${ver}.ebuild clean merge.

While unpacking, check /var/tmp/portage for a 'High water mark' and use that to update BASE_DISK.

This will likely fail; it is completely expected.

Typically we need to either add to, or remove from, the keeplibs variable in src_prepare.

Removing entries is easy; the ebuild will tell you which ones no longer exist. Adding new entries is harder, as Ninja can only tell us about them once we get to src_compile.

Try some variation on:

root #ebuild chromium-131.0.6753.0.ebuild clean merge | grep 'ninja: error:' | awk '{print $3}' | cut -c 8- | awk -F/ '{OFS="/"; NF--; print}'

Iterate over this a few times (this requires a clean; try a tmpfs if there is sufficient RAM available.) Once Ninja stops complaining about missing targets the package should compile successfully - it's rare that we need complex patches hours into a build.

Sometimes Chromium requires a new patch, an older patch to be rebased, or the compiler patches updated. It is usually obvious what needs to be done in the case of the Compiler patches, other patches will need case-by-case handling. Request access to the chromium-patches repo; it will likely be granted!

Once Chromium begins compiling it is time to watch out for weird failures halfway through the build or

On a fast machine (5950X), with LTO, Chromium takes about 4 hours. 2 With ccache (highly recommended).

Open the new Chromium and run some Speedometer (etc) tests and do some light browsing to be sure that it isn't _horribly_ broken, then commit and push the release.

Chromium-based binary packages

Packages such as Google Chrome, Microsoft Edge, and Opera are maintained by the project.

Strong automation exists to ensure that these packages are trivially updatable.

To update these packages:

  1. Check out the chromium-tools repo
  2. Run chrome-bump, edge-bump, and opera-bump to update the respective packages.
  3. Rebase the commits and reword the Chrome bump to reference the Chromium security bug.

Opera Developer (and to a lesser extent Beta and Stable) need to have the (major) version of Chromium that they use verified and updated in the ebuild in the appropriate variable as necessary. The corresponding media-video/ffmpeg-chromium should already be in the tree if Chromium is being kept up-to-date.

These packages are typically not runtime tested. We can assume that upstream did their job, and need to keep fast-moving web browser targets up-to-date.