Package Details: chromium-ozone-wayland-git 74.0.3703.0+24+5c0e21aca5-2

Git Clone URL: https://aur.archlinux.org/chromium-ozone-wayland-git.git (read-only)
Package Base: chromium-ozone-wayland-git
Description: Chromium built from the Igalia fork with experimental Wayland support via Ozone
Upstream URL: https://www.chromium.org/Home
Licenses: BSD
Conflicts: chromium
Provides: chromium
Submitter: hedgepigdaniel
Maintainer: hedgepigdaniel
Last Packager: hedgepigdaniel
Votes: 3
Popularity: 0.226627
First Submitted: 2019-02-06 08:40
Last Updated: 2019-02-14 22:03

Dependencies (47)

Required by (47)

Sources (6)

Pinned Comments

hedgepigdaniel commented on 2019-02-11 01:53

If you think changes should be made to the build script, please open a pull request: https://github.com/hedgepigdaniel/chromium-ozone-wayland-wayland-git-pkgbuild

Some information/recommendations:

  1. AFAICT, https://aur.archlinux.org/packages/depot-tools-git/ requires file create permission for /opt/depot_tools/ for the scripts to work correctly. So for this build to succeed you will need to run $ chmod a+w /opt/depot_tools/.

  2. Checking out the repository requires downloading ~800MB. You can avoid this in subsequent builds by checking out https://github.com/Igalia/chromium once, and then when you build, pulling the latest changes and editing the PKGBUILD to clone the repo from file:///path/to/your/checkout instead of $_gitrepo. Using the --depth 1000 argument to git clone brings the download size down from ~10GB to ~800MB. The build script also downloads a large amount of dependent projects.

  3. The build will take a long time (about 4 hours for me). If you find that you run out of memory during the build, you can sacrifice speed for memory usage by disabling the use_jumbo_build flag. To speed up subsequent builds, you should set up ccache with a large cache size - at least 10GB.

  4. There are still many large bugs. Since this is more likely a curiosity than a daily driver, I've set the default options to (debug !strip). This sacrifices performance and binary size (4GB) for good stack traces. If you experience a crash and would like to report the issue to the maintainers, you should be able to get a good stack trace out of coredumpctl+gdb: https://wiki.archlinux.org/index.php/Core_dump

  5. I have patched some things in a very hacky way to make the build work.

Latest Comments

1 2 Next › Last »

hedgepigdaniel commented on 2019-02-20 22:49

FYI, I've made another package at https://aur.archlinux.org/packages/chromium-ozone/

It is different because:

  • It compiles a recent stable version of chromium, not the development version here
  • It fetches the source tarballs instead of using gclient and co, so should be simpler to build

vially commented on 2019-02-16 00:23

Great. I'll experiment with some stuff and I'll submit a pull-request to your repository if I find a better approach.

hedgepigdaniel commented on 2019-02-15 23:54

Damn, maybe I'll try some more stuff.

Actually I did also start with the official chromium PKGBUILD. The reason I went with the git + gclient option was that I wasn't aware at the time how close the Igalia fork was to the upstream chromium version, so it seemed like the only option.

Since then I've found this repo, where the patches from upstream seem to be maintained: https://github.com/OSSystems/meta-browser/tree/master/recipes-browser/chromium/chromium-ozone-wayland

If you're interested in refactoring this so that it uses the source tarball and applies patches to it to account for the Igalia work that is not yet merged upstream, then please make a pull request: https://github.com/hedgepigdaniel/chromium-ozone-wayland-wayland-git-pkgbuild - I agree that would be a better strategy.

vially commented on 2019-02-15 20:48

I still get the error with the latest PKGBUILD. Thanks for the prompt reply though.

I did manage to successfully build (and run) chromium on wayland by updating the official chromium PKGBUILD (https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/chromium) with the Ozone instructions from https://chromium.googlesource.com/chromium/src/+/HEAD/docs/ozone_overview.md (and a couple of extra patches).

One of the main differences I notice from your approach is that the official chromium PKGBUILD downloads an archive of the source code and uses that directly instead of using depot-tools to grab the sources from git. As as a result the official chromium PGKBUILD seems to build slightly faster (or more precisely it's faster because it skips some steps).

Is there any particular reason why you decided to go this way? Maybe we can combine these two approaches to get the best of both worlds.

hedgepigdaniel commented on 2019-02-14 22:06

@vially I've updated it again, it now removes the -Qunused-arguments flag in BUILD.gn, which I assume will fix the -fvar-tracking-assignments error as per @TwainDee's comment.

The only reason is that I can't reproduce the error so I incorrectly thought it might have been fixed in the latest rebase.

Please let me know if its not fixed now.

vially commented on 2019-02-14 21:13

I'm still getting the -fvar-tracking-assignments errors. Were they supposed to be fixed upstream, or what was the reason for removing them in the latest commit (a9841652bac3) to the PKGBUILD?

hedgepigdaniel commented on 2019-02-11 01:53

If you think changes should be made to the build script, please open a pull request: https://github.com/hedgepigdaniel/chromium-ozone-wayland-wayland-git-pkgbuild

Some information/recommendations:

  1. AFAICT, https://aur.archlinux.org/packages/depot-tools-git/ requires file create permission for /opt/depot_tools/ for the scripts to work correctly. So for this build to succeed you will need to run $ chmod a+w /opt/depot_tools/.

  2. Checking out the repository requires downloading ~800MB. You can avoid this in subsequent builds by checking out https://github.com/Igalia/chromium once, and then when you build, pulling the latest changes and editing the PKGBUILD to clone the repo from file:///path/to/your/checkout instead of $_gitrepo. Using the --depth 1000 argument to git clone brings the download size down from ~10GB to ~800MB. The build script also downloads a large amount of dependent projects.

  3. The build will take a long time (about 4 hours for me). If you find that you run out of memory during the build, you can sacrifice speed for memory usage by disabling the use_jumbo_build flag. To speed up subsequent builds, you should set up ccache with a large cache size - at least 10GB.

  4. There are still many large bugs. Since this is more likely a curiosity than a daily driver, I've set the default options to (debug !strip). This sacrifices performance and binary size (4GB) for good stack traces. If you experience a crash and would like to report the issue to the maintainers, you should be able to get a good stack trace out of coredumpctl+gdb: https://wiki.archlinux.org/index.php/Core_dump

  5. I have patched some things in a very hacky way to make the build work.

hedgepigdaniel commented on 2019-02-11 01:25

I've added another line to remove the offending -fvar-tracking-assignments flags from BUILD.gn

Hopefully that resolves that issue

TwainDee commented on 2019-02-08 13:21

I'm getting these errors at runtime (chromium does open, but it crashes easily):

[25234:25234:0208/131625.166265:ERROR:gles2_cmd_decoder.cc(16290)] Context lost because SwapBuffers failed.
[25234:25234:0208/131625.186114:ERROR:gles2_cmd_decoder.cc(4746)]   GLES2DecoderImpl: Trying to make lost context current. 
[25234:25234:0208/131625.233285:ERROR:gles2_cmd_decoder.cc(16290)] Context lost because SwapBuffers failed. 
[25234:25234:0208/131625.237274:ERROR:gles2_cmd_decoder.cc(4746)]   GLES2DecoderImpl: Trying to make lost context current.

And the UI seems to be scaled 4x instead of 2x on a 4k screen, but not sure if that's issue with sway or chromium.

I tried exporting EGL_PLATFORM=wayland and GDK_BACKEND=wayland. And I tried setting the --ozone-platform=wayland and --enable-native-gpu-buffers. But nothing worked.

P.S. I have an Intel GPU on the laptop with Mesa installed.

TwainDee commented on 2019-02-08 10:29

That said, it seems to be very unstable and keeps crashing when I run the browser with --ozone-platform=wayland. Are there any other options I need to enable for it to run properly?