Project:Chromium/How to bump Chromium
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. If in IRC, the CI bot that builds our release tarballs will join #gentoo-chromium (webchat) and provide a notification when it detects a new release for a given slot, and then another when the tarball is generated and uploaded.
A stable bump is typically as straightforward as:
- copying the existing ebuild to the new version
- If this build is the first in a new major version to be promoted to stable update the subslot to
0/stable. - ensuring the keywords are all reset to `~arch`
- running a build and test.
It is worth checking if there is a new PPC64 patchset available; don't be afraid to use an older patch version within the same major release if the patches apply cleanly.
While the build is progressing, log a Security bug to cover any CVEs (there are tons of examples on b.g.o already) - the details required will be on the Chrome Releases Blog.
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.
Security Bug
Ask in #gentoo-bugs (webchat) for permissions to assign bugs. Use the Project:Bug-wranglers userscript to easily assign bugs.
As Chromium is the base for many browsers, when the Chrome Releases Blog indicates that CVEs are fixed by this release an appropriate Security bug must be logged. Do this before merging www-client/chromium and reference the bug using the Bug: tag, e.g. Bug: https://bugs.gentoo.org/123456.
See bug #943403 and the related blog post for an example.
Step-by-step from https://bugs.gentoo.org:
- Click New-[Ex] then Gentoo Security
- Select the Component `Vulnerabilities`
- Copy the blog post content (noting the fixed version and CVEs in particular) into the Description
- Enter an appropriate Subject (for one CVE use the summary, for multiple "multiple vulnerabilities" is suitable. Mention each impacted product (i.e. each Chromium-based browser). Do not enter a version into this field until the fixed version is in-tree
- Enter each CVE into the Alias field, comma separated
- Click the CC checkbox for the Chromium Project email alias
- If the stablereq has already been logged, put the bug number in the Blocks field
- Click Submit Bug
Stable Request
Use app-portage/nattka to generate the list of packages required for stabilisation; it may be that media-video/ffmepg-chromium needs to be stabilised for the supported arches, too! See the docs for more information - It can even help with actioning stablereqs if configured correctly!
If CVEs are fixed by this release it is important to file a security stablereq so that the fixes can be distributed to users on stable as quickly as possible.
This section just provides a brief overview, see Stable_request and Bugzilla/Bug_report_guide for a detailed guide.
user $nattka make-package-list www-client/chromium-134.0.6998.35 -a arm64 -a amd64INFO:nattka:New packages: dev-build/gn-0.2217 media-video/ffmpeg-chromium-134
INFO:nattka:Iteration 1: verifying ...
INFO:nattka:Iteration 2: running pkgcheck ...
INFO:nattka:Time elapsed: 0:00:04.818253
INFO:nattka:Target CC: amd64@gentoo.org arm64@gentoo.org
WARNING:nattka:The package list contains newest versions visible.
WARNING:nattka:Please adjust the package list to desired versions.
INFO:nattka:Package list follows:
www-client/chromium-134.0.6998.35 arm64 amd64
dev-build/gn-0.2217 ^
Log a stablereq with the package list as output by nattka, ensuring that this bug blocks the security bug. See bug #948984 for an example. As you are working on behalf of the Chromium project, it is acceptable to immediately tag with CC-ARCHES.
It is possible (and even a good idea, while waiting for the package to build!) to log the stablereq and have it ready. Arch teams will only be CC'd (and workflows started) when the server-side nattka bot detects that this package has been merged into ::gentoo.
New Major Version
The process for non-trivial
dev bumps, and sometimes on promotion of dev to beta is this skipping the ffmpeg-chromium step.When a new major version has been released the process is slightly different.
- 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).
- 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/«channel». - While in the ebuild try and take care of a TODO.
- Generate a manifest for the ebuild (pkgdev manifest)
- start an ebuild chromium-${ver}.ebuild clean test 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.Tip
Try some variation on:
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!
- This will likely fail; it is completely expected.
- Once Chromium begins compiling it is time to watch out for weird failures halfway through the build:
- A file not found error is usually a missing directory which means updating
keeplibs. - On a fast machine (5950X), with LTO, Chromium takes about 4 hours. 2 With ccache (highly recommended).
- A file not found error is usually a missing directory which means updating
- 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:
- Check out the chromium-tools repo
- Run chrome-bump, edge-bump, and opera-bump to update the respective packages.
- 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.