El mié, 31 dic 2025 a las 14:29, Pierre Gruet (<[email protected]>) escribió: > > Hi Juan, > > Le 30/12/2025 à 23:49, Juan Mendez a écrit : > > > 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. > > > > 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 <http://debian.vejeta.com> for anyone > > who wants to test in the > > meantime. > > > > Regards, > > Juan > > > > First, thanks for working on that package. It is nice to see there is > 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, > > -- > Pierre
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
