Bug#1124290: RFS: chromium-embedded-framework/138.0.1 [ITP] -- Chromium Embedded Framework library

[Pierre Gruet]

Hi Juan,

Le 01/01/2026 à 20:58, Juan Mendez a écrit :

[...]

Hi Pierre,

Thank you for your quick and insightful response and for sharing your packaging attempt. It's great to know there's interest from the Scilab side - having a concrete use case like JCEF makes this work even more meaningful.

You're welcome, thanks for all the explanations!

Let me address your points:

1. On chromium-headers vs full source



Some examples:

I decided to continue pursing CEF packaging attempt, not only because it is a dependency for my other package, stremio-gtk, but because it was a learning opportunity as there are more and more packages that are using CEF. This is the critical question. In my investigation of CEF's source code, here is part of what I found: CEF uses internal Chromium APIs, not only public ones. CEF includes 43+ headers from content/browser/ (internal implementation headers), as opposed to content/public/browser/ (stable public API). For example, libcef/browser/browser_host_base.cc includes content/browser/ renderer_host/render_frame_host_impl.h. See https://bitbucket.org/chromiumembedded/cef/src/master/libcef/ browser/browser_host_base.cc <https://bitbucket.org/chromiumembedded/ cef/src/master/libcef/browser/browser_host_base.cc>

Also CEF's off-screen rendering (osr/render_widget_host_view_osr.h) extends content::RenderWidgetHostViewBase from content/browser/ renderer_host/render_widget_host_view_base.h. These internal classes don't have stable ABIs presumably and their implementation I infer could change between Chromium versions. CEF hooks into Chromium's internal browser infrastructure. This could explain why the attempt with chromium-headers didn't produce libcef.so: the ninja build targets I gather that depends on compiled Chromium object files (not just headers). This means CEF requires source-level integration with a matching Chromium version, I have been updating the last 3 Debian Chromium sources with CEF, and the approach seems to work.

Understood. This seems to answer my concerns.

2. On package format (native vs MUT)


```
chromium-embedded-framework_X.orig.tar.xz        (CEF sources)
chromium-embedded-framework_X.orig-chromium.tar.xz (Chromium sources)
debian.tar.xz                                     (with quilt patches)
```

I'll also add a proper `debian/watch` file for MUT.

I am learning, so this feedback I appreciate it a lot too. The native format was my first attempt, so I will start working just now on moving it to the MUT format and see if I find any caveat.

No worry, yes you're learning, and this is fine :)

I think we should try to get the components downloaded by debian/watch. Honestly that's maybe not the priority, but we could try adding something like opts=component=chromium,compression=xz,searchmode=plain,downloadurlmangle=s/"version":\s*"@ANY_VERSION@"/https:\/\/gsdview.appspot.com\/chromium-browser-official\/chromium-$1-lite.tar.xz/,filenamemangle=s/"version":\s*"@ANY_VERSION@"/chromium-$1-lite.tar.xz/ \ https://chromiumdash.appspot.com/fetch_releases?channel=Stable&platform=Linux \

    "version":\s*"@ANY_VERSION@" \
 ignore

opts="component=depot-tools, mode=git, pgpmode=none" \
 https://chromium.googlesource.com/chromium/tools/depot_tools.git HEAD \
 ignore

at the end of debian/watch.

Alternatively I will use your debian/scripts/get-orig-tarballs.sh file.

3. On the rust-toolchain tarball


Build-Depends: rustc, bindgen, rust-src, librust-libc-dev

For the Rust compiler, this package uses system rustc from Debian with RUSTC_BOOTSTRAP=1 (following Debian Chromium's approach): However, we require rust-toolchain.tar.xz tarball as a bundled dependency (for now). This is because Debian's rust-src package (currently 1.90.0) is missing newer std library source files that Chromium requires, such as sync/nonpoison/condvar.rs <http://condvar.rs> and rwlock.rs <http://rwlock.rs>. The tarball provides the complete Rust std library sources at the version Chromium expects. These are part of the unstable sync_nonpoison feature (Related: https:// github.com/rust-lang/rust/issues/134645 <https://github.com/rust-lang/ rust/issues/134645>) and were added to Rust's std library after the version Debian packages.

Options:
a. Keep using rust-toolchain.tar.xz (current approach) - bundled dependency
b. Wait for Debian - these files will appear in a future rust-src (1.91+?)

This is NOT currently packaged in Debian. When Debian's rust-src catches up to Chromium's requirements in the future, this tarball can probably be eliminated, these files will appear in a future rust-src (1.91+?)   The real issue: Chromium's rust-toolchain.tar.xz (commit 15283f6fe95e5b604273d13a428bab5fc0788f5a) is built from a newer Rust version than 1.90.0 - likely a recent nightly or development build. Their build/rust/std/rules/BUILD.gn was generated against this newer toolchain. c. Regenerate Chromium's rules/BUILD.gn - run gnrt against Rust 1.90.0 to generate a compatible file (complex, may break other things)

Ok, I read your other email where you say the package in Debian is now enough, great!

4. On depot_tools and Internet access






   cd chromium_src/cef && git init && git add . && git commit -m "..."

To clarify: this package debian/rules does not access the internet during build. The git clone commands you saw are only in error messages telling users to pre-download depot_tools if missing - they don't execute during the build itself. Network isolation is enforced by patch 0003-network-isolation-disable- google-storage-downloads.chromium.patch which makes download_from_google_storage.py a no-op, plus the --no-depot-tools- update flag which prevents depot_tools from pulling upstream changes. Then , Why I had to do this: I create local git repositories to satisfy CEF's build system expectations. CEF's automate-git.py expects git repositories for its source directories. I satisfy this requirement with local git init && git commit: This is completely network-free but admittedly unusual for Debian packaging. A cleaner approach would be to patch automate-git.py to remove git repository requirements entirely, though I found the necessary patching would be quite complex for limited benefit.

OK!

5. On binary files

  I'll add Files-Excluded to debian/copyright for repacking:
   Files-Excluded:
    depot_tools/*.exe
    depot_tools/win_tools*
    depot_tools/*.bat
    depot_tools/.cipd_bin/*.exe

Great!
I have not made a review yet, but I see other binary files such as
  third_party/node/linux/node-linux-x64/bin/node

and I wonder if it is useful / if this could be excluded and instead /usr/bin/node provided by the Debian package nodejs could be used?

6. On debian/copyright



7. On debian/rules

Your assessment is correct. The file:

Follows CEF's automate-git.py approach for the build structure
Adds Debian-specific patches (system libc++, unbundling attempts)

Works around the fact that Debian tarballs aren't git repositories.

Thanks for this, I need to update this to account for the number of copyright holders across Chromium/CEF. Applies Debian Chromium patches manually (since chromium_src/ doesn't exist until build time) Again, many many builds led me to have this, it has been a trial/error approach until getting to this point, although trying to match Debian Chromium as closely as possible. I will appreciate any feedback if there are things to improve.

I suggest yoou see if it is possible to address the remaining binaries (node for instance) and if you wish to work on debian/watch as I said above, then I will try to build locally and to analyze things further. Tell me!

Finally,


- And the base to get feedback as you invaluably have done!

Why the current strategy: Get something that builds first, then iterate toward policy compliance. When reading the original RFP, my targets where: - Having a working (if imperfect) package that can lives in experimental for all the other packages that wants to try it. - Prove it can be done, and have something concrete to discuss with the Chromium Team.

I am fine with this way. Maybe you should get in touch with the Chromium team explicitly before we upload anything, so that they know there will be a copy of chromium in the archive.

Thanks a lot for this, happy new year!

Juan

I will start working on the MUT packaging, updating watch, copyright while receiving more feedback.

All the best,

--
Pierre

OpenPGP_signature.asc
Description: OpenPGP digital signature