Le ven. 9 janv. 2026 à 23:03, Pierre Gruet <[email protected]> a écrit :
> 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! > > > > > 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 <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) > > > > 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. > > 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. > 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. > > > > 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 <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. > > > > 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) > > > > Ok, I read your other email where you say the package in Debian is now > enough, great! > > > > > 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. > > 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? > This is a concern. First, somewhat easy to fix: 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. > > > > > 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. > > 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, > > > > 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 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. > > > > > I will start working on the MUT packaging, updating watch, copyright > > while receiving more feedback. > > > > Thanks a lot for this, happy new year! > > > > Juan > > All the best, > > -- > Pierre >
