Dear mentors,

I am looking for a sponsor for my package "chromium-embedded-framework":

 * Package name    : chromium-embedded-framework
   Version         : 138.0.1
   Upstream contact: Marshall Greenblatt <magreenblatt@gmail.com>
 * URL             : https://bitbucket.org/chromiumembedded/cef
 * License         : BSD-3-Clause
 * Vcs             :
https://salsa.debian.org/mendezr/chromium-embedded-framework
   Section         : libs

It builds these binary packages:

  libcef138      - Chromium Embedded Framework runtime library
  libcef-dev     - Chromium Embedded Framework development files
  cef-resources  - Chromium Embedded Framework resources

To access further information about this package, please visit:
https://mentors.debian.net/package/chromium-embedded-framework/

Or retrieve with dget:

  dget -x
https://mentors.debian.net/debian/pool/main/c/chromium-embedded-framework/chromium-embedded-framework_138.0.1.dsc

Changes for initial release:

chromium-embedded-framework (138.0.1) experimental; urgency=medium

  * Initial release (Closes: #915400)
  * 58 patches for network-isolated Debian builds
  * Tested with stremio-gtk (ITP #1119815)

chro

This is an interesting package (I am interested in all things related to
browser engines, particularly Chromium-based ones).  I don’t have time to
review this package right now.  I hope that someone else does.  But, if you
don’t get a response in a couple of months, please hit me up and I will take a
look at it if I have time then.

you
take a

Thanks Soren, I really appreciate the interest.

No rush - I'll follow up in a couple of months if needed. The packages
are available at debian.vejeta.com for anyone who wants to test in the
meantime.

Regards,
Juan

Hi,

Le 30/12/2025 à 23:49, Juan Mendez a écrit :

I am highly interested in this package, which will be needed by scilab
one day. I will try to review it shortly!

Best regards,

Hi Juan,

Le 30/12/2025 à 23:49, Juan Mendez a écrit :
some effort being done on it. As I wrote previously, I am interested in
scilab, of which upstream is relying more and more on JCEF, the Java
wrapper around cef.


Please let me start with some thoughts I have had for months about cef.

I wonder if we really need the whole source of chromium or if the
headers (plus the shared libs in chromium-common maybe) are enough, as
we would do if we build against the -dev package of a regular C++
library. Some months ago I issued a chromium-headers package from
src:chromium and tried to build against is.
I think we can build the package in a lighter way than the upstream's
one, by just calling some of the scripts to configure the package.
Please find attached the debian/ directory of my attempt to package cef,
using it I am able to build some things but curiously the target
libcef.so is not produced, I don't know why...

I would be really interested in your opinion about the headers being
enough or not. Once they are installed under /usr/include, I think they
can be included from the cef sources.


Back to your work now.

- The package is not native, as it is not Debian-specific and relies on
an upstream orig tarball. If you want to add other tarballs, use instead
a multiple upstream tarball package (look for ``MUT'' in the manpage of
uscan). I think it will also allow you to patch all the needed files at
once using the regular quilt mechanism.

- about the rust-toolchain tarball you need: is it packaged in Debian?

- certainly we can modify the build process (a bit like in my attached
attempt) to completely get rid of depot_tools. Anyway we cannot clone
anything nor access the Internet during a package build. (I see git
clone commands under override_dh_auto_build).

- there are multiple binary files (at least in depot_tools), including
Windows-related ones: simply remove them using the repacking mechanism
of Debian packages.

- There are lots of copyright holders to list in debian/copyright, I see
for instance Chris Moyer, Robert Mela, Mitch Garnaat, Amazon.com,
Eucalyptus Systems, Google, Nexenta Systems, Blue Pines Technology, ...
perhaps writing the final debian/copyright file is not the first thing
to do, still.

- When designing the MUT package, you will have to introduce a
debian/watch file.

- debian/rules: is it correct to say this file mimics the build
documentation on the cef website, plus some extra work for applying the
patches?



Summary

Thanks again for addressing this huge package. Maybe we should discuss a
bit things with the Chromium Team and the people implied in the
discussion in the bug report of #893448, to see what is the correct way
to go: if a new chromium-headers binary package is enough, we should go
for it. But maybe I am completely missing something.

I think designing a MUT package is a good way to go if it appears we
absolutely need the chromium sources. Have a look at my packaging
attempt to estimate if we can get rid of depot_tools, that would help a lot.

Additional feedback from more experienced people, e.g. from the Chromium
Team, would be very useful.

All the best,

El mié, 31 dic 2025 a las 14:29, Pierre Gruet (<pgt@debian.org>) escribió:
related to
time to
lot.
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.

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.

Let me address your points:

1. On chromium-headers vs full source

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.

Some examples:

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

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.

2. On package format (native vs 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.
```
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.

3. On the rust-toolchain tarball

For the Rust compiler, this package uses system rustc from Debian with
RUSTC_BOOTSTRAP=1 (following Debian Chromium's approach):
Build-Depends: rustc, bindgen, rust-src, librust-libc-dev

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 and 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) and were added to Rust's
std library after the version Debian packages.

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.

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+?)
c. Regenerate Chromium's rules/BUILD.gn - run gnrt against Rust 1.90.0 to
generate a compatible file (complex, may break other things)


4. On depot_tools and Internet access

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:
  cd chromium_src/cef && git init && git add . && git commit -m "..."

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.

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

6. On debian/copyright

Thanks for this, I need to update this to account for the number of
copyright holders across Chromium/CEF.

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)
Applies Debian Chromium patches manually (since chromium_src/ doesn't exist
until build time)
Works around the fact that Debian tarballs aren't git repositories.

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.

Finally,

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.
- And the base to get feedback as you invaluably have done!

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

Thanks a lot for this, happy new year!

Juan

Hi Pierre,

New update: I've addressed what you commented and uploaded a new version to
mentors, and this should be ready for a second round of review.

Changes made:

  1. MUT format implemented - Package now uses 3 component tarballs:
    - orig.tar.xz (CEF source)
    - orig-chromium.tar.xz (from Debian chromium)
    - orig-depot-tools.tar.xz (cleaned of binaries)
  2. Rust tarball removed - Debian's rust-src 1.91.1+ now includes the
files CEF needs (sync/nonpoison/condvar.rs, rwlock.rs). Build uses system
rust-src via Build-Depends.
  3. debian/copyright updated - All copyright holders listed, MUT
components documented, Files-Excluded for binary removal.
  4. debian/watch added - Version 4 format tracking CEF releases.
  5. Network isolation - Patch 0003 disables Google Cloud Storage
downloads. All source bundled in MUT tarballs.
  6. Binary repacking - depot-tools tarball is physically cleaned of .exe,
.dll, .bat files (not just Files-Excluded).
  7. Helper script - Added debian/scripts/get-orig-tarballs.sh for DDs to
recreate MUT tarballs from upstream sources.

Please, let me know if this is convenient to have, or any other thing can
be missing, once we have a clean package I should say we can bring this to
the chromium team notice.

Lintian status: 0 errors, and only informational messages remain in
pedantic due to chromium sources.

I had trouble uploading the new package with dput at:
https://mentors.debian.net/package/chromium-embedded-framework/
I am getting some  errors from the server.

File "/usr/lib/python3/dist-packages/dulwich/repo.py", line 1130, in
__init__
dulwich.errors.NotGitRepository: No git repository was found at
/var/lib/debexpo/git/chromium-embedded-framework

Could it be that in the meanwhile the package can be reviewed from the
salsa repo?
https://salsa.debian.org/mendezr/chromium-embedded-framework

Best regards,
Juan Manuel

Hi Juan,

Sorry about this importer failure on mentors but unfortunately, the
source package is hitting the maximum size that mentors can handle.

We had the same problem with the chromium source package.

I would suggest to ask reviewers to use the salsa repository directly
instead of uploading to mentors.

Best of luck,

Hi Juan,

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

You're welcome, thanks for all the explanations!

Understood. This seems to answer my concerns.

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.

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

OK!

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?

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!

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.

All the best,

Le ven. 9 janv. 2026 à 23:03, Pierre Gruet <pgt@debian.org> a écrit :

Nowadays we have watch 5 file format, which makes it more readable,
and also I'm used to MUT uses.
Do ask me on this.
  Files-Excluded: third_party/node/linux/node-linux-x64/bin/node
  (Build-)Depend: nodejs.
  You might need to patch the required path here.
Second, are there more binaries in third_party directory ?
Precompîled binaries in a debian package need to be fixed.

Hi Pierre, Jérémy,

Thank you both for your review and helpful suggestions!

Let me address the points you raised and let me know if they are answered
with this:

1. On the Node.js binary (third_party/node/linux/node-linux-x64/bin/node)

Good catch on this! This package already uses system Node.js from the
Debian nodejs
package instead of any bundled binary:

- nodejs is listed in Build-Depends
- debian/rules creates a symlink: ln -sf /usr/bin/node
.../third_party/node/.../node
- Patch 0013-skip-nodejs-version-check.chromium.patch bypasses the version
  check (system node v20.x vs expected v22.x)

However, I've added it explicitly to debian/copyright Files-Excluded for
documentation:

  chromium/third_party/node/linux/*

Is that what you meant?

2. On debian/watch format and component support (Jérémy)

Thank you for the suggestion! I've converted debian/watch to Version 5
format
(RFC822-style) which is indeed more readable. I have added comments in each
section to explain why we track what we track.
Note: We depend on DEBIAN's chromium package (not upstream Google), this is
until Chromium Team releases a source package, so the
chromium component tracks deb.debian.org/debian/pool/main/c/chromium/.

  Version: 5

  Mode: git
  Source: https://bitbucket.org/chromiumembedded/cef.git
  Matching-Pattern: refs/tags/(\d+\.\d+\.\d+)
  Pgp-Mode: none

  Component: chromium
  Source: https://deb.debian.org/debian/pool/main/c/chromium/
  Matching-Pattern: chromium_(@ANY_VERSION@)\.orig\.tar\.xz
  ...

  Component: depot-tools
  Mode: git
  Git-Mode: shallow
  Source: https://chromium.googlesource.com/chromium/tools/depot_tools.git
  ...

3. On other precompiled binaries in third_party (Jérémy)

I've investigated the tarballs thoroughly. The chromium component tarball is
derived from Debian's chromium source which already has extensive
Files-Excluded
applied. My analysis found:

- No .so binaries (only .so.c source files)
- No .jar, .wasm files
- No third_party/node/linux/ directory (already excluded by Debian chromium)
- No buildtools directory (already excluded by Debian chromium)

The "binary-looking" files that remain are actually:
- Shell/Python scripts (ninja, cipd, siso in depot-tools)
- Test data files (*.bin fuzzer seeds - not executables)

For system replacements beyond node, debian/rules also handles:
- Rollup: symlinks /usr/share/nodejs/rollup to replace bundled
@rollup/wasm-node

I'm happy to add more explicit exclusions to debian/copyright if you think
that would improve documentation clarity, even though the base tarball from
Debian chromium already excludes them.

4. On contacting the Chromium team

Understood - I'll reach out to the Debian Chromium maintainers before we
proceed with any upload to make them aware of this package.

Jérémy, please feel free to suggest any additional improvements to the watch
file format - I appreciate any feedback.

All these changes are now in salsa:
https://salsa.debian.org/mendezr/chromium-embedded-framework

Best regards,
Juan


PS: Currently working on being up to date with the latest debian chromium
released today.

Le sam. 10 janv. 2026 à 17:15, Juan Mendez <vejeta@gmail.com> a écrit :
yes

That's fine as it is

No other idea at the moment, but ok.

Hello,


The chromium-embedded-framework package has been updated to CEF 144 (branch
7559), now aligned with the current Debian Chromium version 144.0.7559.59.


Changes pushed again to:
https://salsa.debian.org/mendezr/chromium-embedded-framework
and new binary packages available in: https://debian.vejeta.com/


I have tested with my other package in the queue: stremio-gtk and it
continues working.

All the best,

Juan

Hello all,

Updated to CEF 144.0.6-2 with latest Debian Chromium  144.0.7559.96-1
 security fixes. Build and lintian pedantic pass cleanly.

Best wishes,

Juan

Hi Juan,

Le 25/01/2026 à 22:04, Juan Mendez a écrit :

Thanks for the news! I have not forgotten your email from the 16th and
will try to have a look shortly.

Best wishes,

Hi Pierre,

CEF package updated to track Chromium 145.0.7632.109-1~deb13u3 (security
release).

Build instructions unchanged:

./debian/scripts/get-orig-tarballs.sh 145.0.23 7632
145.0.7632.109-1~deb13u3
# Then build as usual:




dpkg-source -b .
cd .. && dpkg-source -x *.dsc build-dir
cd build-dir && dpkg-buildpackage -us -uc


Note: If you have old 145.0.7632.75 MUT tarballs, remove them first:
rm -f *_145.0.23.orig-chromium*.tar.xz

Salsa and debian.vejeta.com updated.

Best, Juan