bootstrap: Minimal Changes

[EliasTheGrandMasterOfMistakes]

Enable FFMPEG Sumo. Enable MiniGBM. Use System libdrm. No more necessary define system libwayland as false

A need a opinion, if will be enabled V4l2 will be necessary to just be enabled in arm system.

What is the better way?

1: Split Bootstrap.sh and just use it in arm64? 2: Define a env var to arm64 and just use it in arm64?

How this can be used? have some software using a thing like this to be used as reference?

[Erick555]

You should explain why those are changed.

[EliasTheGrandMasterOfMistakes]

You should explain why those are changed.

Yes minigbm is a graphic buffer alocator used in chromeos system, but according to this blog

"Building a functional minigbm

Ozone-GBM uses the GBM API to create buffers. However, it doesn’t use Mesa’s GBM implementation, but ships its own in the form of the minigbm library. The Chromium source code contains a copy of the library under third_party, but uses it only for building and testing purposes without enabling any of the minigbm hardware drivers." source: https://www.collabora.com/news-and-blog/blog/2017/11/27/running-chromium-with-ozone-gbm-on-gnu-linux/.

use_system_libwayland=false is no more necessary, you can build without this flags and build will works great in wayland, system libwayland is not break in sdk.

use_system_libdrm according to build.gn "

Controls whether the build should use the version of libdrm

library shipped with the system. In release builds of Chrome OS we

use the system version, but when building on dev workstations we

bundle it because Ubuntu doesn't ship a usable version.".

Libdrm used for build chromium in sdk is not break.

About the ffmpeg sumo i will remove it, looks is deprecated more used and is just ignored as parameter, search in chromium appears this is removed. Sorry for this mistake.

[Erick555]

Yes minigbm is a graphic buffer alocator used in chromeos system, but according to this blog

The blog's author said in the comment section there is no reason to use it for normal cases:

Hi Jay. This is vanilla Chromium, too, just running directly in a Linux virtual terminal instead of running using X11 (or Wayland). This is mostly useful for development purposes, especially since Chromebooks run this way, too (i.e., they use Ozone-GBM). From an end user perspective there is not much to be gained from this for normal use cases, although there are some production use cases for which this could be useful (e.g., kiosks).

Ubuntu libdrm also isn't broken as it has millions of users yet for some reason chromium devs prefer their own. Flatpak chromium prefers bundled libs due to better compatibility and hardening

[flathubbot]

Started test build 105911

[flathubbot]

Build 105911 successful To test this build, install it from the testing repository:

flatpak install --user https://dl.flathub.org/build-repo/88718/org.chromium.Chromium.flatpakref

[EliasTheGrandMasterOfMistakes]

Yes minigbm is a graphic buffer alocator used in chromeos system, but according to this blog

The blog's author said in the comment section there is no reason to use it for normal cases:

Hi Jay. This is vanilla Chromium, too, just running directly in a Linux virtual terminal instead of running using X11 (or Wayland). This is mostly useful for development purposes, especially since Chromebooks run this way, too (i.e., they use Ozone-GBM). From an end user perspective there is not much to be gained from this for normal use cases, although there are some production use cases for which this could be useful (e.g., kiosks).

Ubuntu libdrm also isn't broken as it has millions of users yet for some reason chromium devs prefer their own. Flatpak chromium prefers bundled libs due to better compatibility and hardening

In this case i can remove this commit?

[refi64]

Yeah I'm not sure about the minigbm/libdrm changes, if there's no specific known thing that they fix I'd rather leave them as-is.

I'm fine with removing use_system_libwayland though; it seems to be completely gone from upstream altogether.