www-client/chromium-72.0.3595.2 FAILED: gen/mojo/public/js/mojo_bindings_lite.js /bin/sh: java: command not found Reproducible: Always Steps to Reproduce: emerge chromium Actual Results: build system cannot find java Expected Results: chromium should not need java installed
Created attachment 557358 [details] emergeinfo.txt
Created attachment 557360 [details] nojava-chromium-buildlog.xz
Created attachment 557362 [details] fakejava-chromium-buildlog.xz When I pretended to have java installed, the build went quite a bit further before failing. ln -s /bin/true /usr/bin/java
Interesting. Pulling in a JRE would suck...
Installing dev-java/icedtea-bin does allow chromium to build, but it would be nice to have a java-free option that either omits the java parts like app-office/libreoffice does, or pre-generates the java parts like media-tv/kodi does.
wow, so it's come to this... starting to miss firefox (not really :P) I wonder how long before this trickles down to qt-webkit and the like :)
Getting this with 72.0.3626.28 also. Indeed, requiring java sucks. I wonder what the other distros and ungoogled-chromium (I believe that's the name... I found an ebuild for it in an overlay when I was first trying to build 72 using a modified 71 ebuild for, investigated it a bit but haven't yet installed that overlay or tried the ebuild) are doing/going-to-do. Hopefully it's not core and someone develops a workaround patch. ... So I guess it's still 71-stable for now. When I saw 72 in-tree I was hoping the problems I had run into on my own were fixed now, but it doesn't appear so... yet.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f6dfd1e5a3e33b9e63e37a9e32963ef06db4c3f0 commit f6dfd1e5a3e33b9e63e37a9e32963ef06db4c3f0 Author: Mike Gilbert <floppym@gentoo.org> AuthorDate: 2018-12-26 19:20:33 +0000 Commit: Mike Gilbert <floppym@gentoo.org> CommitDate: 2018-12-26 19:20:33 +0000 www-client/chromium: depend on virtual/jre Closes: https://bugs.gentoo.org/672778 Package-Manager: Portage-2.3.52_p8, Repoman-2.3.12_p20 Signed-off-by: Mike Gilbert <floppym@gentoo.org> www-client/chromium/chromium-72.0.3626.28.ebuild | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
coming up soon: adobe flash chromium BDEPEND :P
I think I've found the culprit, but I haven't tested yet. Looking the source responsible for generating "mojo_bindings_lite.js" [1], which requires [2], I came to conclusion that "closure_compile=false" is the way to go if you don't want Java as dep. 1: https://chromium.googlesource.com/chromium/src/+/72.0.3626.28/mojo/public/js/BUILD.gn 2: https://chromium.googlesource.com/chromium/src/+/72.0.3626.28/ui/webui/webui_features.gni
(In reply to Ian Moone from comment #10) > "closure_compile=false" is the way to go if you > don't want Java as dep. Thanks for the tip, and I can verify that this works :) Next step: try this on chromium-73 --- /mnt/repos/gentoo/www-client/chromium/chromium-72.0.3626.28.ebuild 2018-12-26 19:33:10.935730000 -0500 +++ /mnt/repos/fixes/www-client/chromium/chromium-72.0.3626.28.ebuild 2018-12-27 18:53:33.046523000 -0500 @@ -105,7 +105,6 @@ sys-apps/hwids[usb(+)] >=sys-devel/bison-2.4.3 sys-devel/flex - virtual/jre virtual/pkgconfig " @@ -430,6 +429,9 @@ # Disable nacl, we can't build without pnacl (http://crbug.com/269560). myconf_gn+=" enable_nacl=false" + # Nobody wants java in the build system. Get rid of it BGO 672778 + myconf_gn+=" closure_compile=false" + # Use system-provided libraries. # TODO: freetype -- remove sources (https://bugs.chromium.org/p/pdfium/issues/detail?id=733). # TODO: use_system_hunspell (upstream changes needed).
Reopening this, because indeed nobody wants jre in their build system who doesn't want jre in their build system. myconf_gn+=" closure_compile=false" seems like a good solution, but, I suspect we ought to put this behind a USE flag called "optimize-mojo-javascript", since closure compiler is used as an optimizer of sorts. Alternatively, if somebody knows what that JS is doing and has an argument about why nobody actually wants to optimize it, pipe up?
(In reply to Jason A. Donenfeld from comment #12) > closure compiler is used as an optimizer of sorts I imagine this is simply an upstream brainfart, because I can think of a couple of better approaches. Perform the optimization step prior to commiting the source code. That way, no build-time optimization would be needed. or Write the optimizer in a less reflux-inducing language. Python would be a good choice because the build system already uses this. In any case, disabling this optimization is a good enough solution for me.
argh! extra points if you spot my spelling mistakes
(In reply to cyrillic from comment #13) > > In any case, disabling this optimization is a good enough solution for me. If you want to go further and want to drop net-libs/nodejs as dep, just disable "optimize_webui". You can see in this chromium spin-off [1], that there's an USE=optimize-webui for it. 1: https://gitlab.com/chaoslab/chaoslab-overlay/blob/64a3279dd18e06eb0c76fae186287500e4f3e9d0/www-client/ungoogled-chromium/ungoogled-chromium-71.0.3578.98_p2.ebuild Sorry for the off-topic, guys. But I thought it was worth mentioning. Adding a similar USE flag will make everyone happy.
(In reply to cyrillic from comment #13) > (In reply to Jason A. Donenfeld from comment #12) > > closure compiler is used as an optimizer of sorts > > I imagine this is simply an upstream brainfart, because I can think of a > couple of better approaches. > > Perform the optimization step prior to commiting the source code. That way, > no build-time optimization would be needed. > > or > > Write the optimizer in a less reflux-inducing language. Python would be a > good choice because the build system already uses this. > > In any case, disabling this optimization is a good enough solution for me. I agree that this seems like a large oversight upstream, so patching it here within Gentoo might not be the best approach. Looking at the comment in the source that calls for Java: https://chromium.googlesource.com/chromium/src/+/72.0.3626.28/ui/webui/webui_features.gni and seeing as this functionality is explained in greater detail here: https://developers.google.com/closure/compiler/ it looks like it is being used within Chromium to optimise the JS-based components of the UI. If that's the case, I agree that it should be handled before shipping the source code for building. That way, the optimisations to the JavaScript portions are already in place before the end-user attempts to build. Requiring a JRE for this type of optimisation should, at worst, be the obligation of the Chromium developers and *NOT* the end-users.
(In reply to Nathan Zachary from comment #16) > (In reply to cyrillic from comment #13) > > (In reply to Jason A. Donenfeld from comment #12) > > > closure compiler is used as an optimizer of sorts > > > > I imagine this is simply an upstream brainfart, because I can think of a > > couple of better approaches. > > > > Perform the optimization step prior to commiting the source code. That way, > > no build-time optimization would be needed. FWIW that's no good. See below. > > > > or > > > > Write the optimizer in a less reflux-inducing language. Python would be a > > good choice because the build system already uses this. Agreed in general (and yes, IMO "reflux-inducing" seems appropriate for Java), but as the FLOSS-world saying goes, he who codes, decides. The folks doing the work found it most convenient to use Java, and the folks using that work in an open-core commercial product (Google, Chrome) seem to have accepted it, so... I guess it's up to someone from the community with the skill and the care to reimplement it in Python or whatever and demonstrate why that's better... Until then, reflux inducing tho it may be... well, at least it's easy enough to turn off... > > In any case, disabling this optimization is a good enough solution for me. > > I agree that this seems like a large oversight upstream, so patching it here > within Gentoo might not be the best approach. Looking at the comment in the > source that calls for Java: > https://chromium.googlesource.com/chromium/src/+/72.0.3626.28/ui/webui/ > webui_features.gni > > and seeing as this functionality is explained in greater detail here: > https://developers.google.com/closure/compiler/ > > it looks like it is being used within Chromium to optimise the JS-based > components of the UI. If that's the case, I agree that it should be handled > before shipping the source code for building. That way, the optimisations > to the JavaScript portions are already in place before the end-user attempts > to build. Requiring a JRE for this type of optimisation should, at worst, > be the obligation of the Chromium developers and *NOT* the end-users. [Catching the punt from above...] The problem with that is pre-ship-optimizing like that arguably wouldn't be proper open source... chromium isn't GPL but the FSF in a FAQ describing what's required for the GPL, for instance, says, effectively, that the source must be in the customary form for human editing, and pre-optimizing rather defeats that, just as minified javascript (which without looking I suspect is more or less the optimization done here) on a web page does. OK, so chrome can ship it optimized, but the whole point of building chromium from sources is to have and be able to modify if desired the actual source, and minified/optimized/whatever isn't the proper sources. If you're going to be satisfied with no-longer-source-as-authored pre-optimized code, you might as well run the pre-built chrome binary and call it good, because you would /not/ be getting the proper sources in that case. ... Meanwhile, change of topic, FWIW (if it's too long feel free to skip)... Given that the browser is almost certainly the most security-exposed piece of code I run on my main computers (arguably the routers have similar security exposure, but this isn't about them), I tend to be rather sensitized to the security implications of running old and likely exploit-code-available-due-to-patch-fixing-it-availability versions. It therefore bothers me to have upstream releases out for days without corresponding packages. Now I'm not criticizing the hard work the gentoo devs put in making the things actually work -- I know it's often significantly more work than simply renaming the existing ebuild to the new version so it fetches the new code, and hoping it builds, because often I do that myself, and often it does *NOT* build, and I have to fix what I can and often enough wait for someone else to come up with fixes for what I can't, or simply don't have time to figure out just yet. But, that *is* a large part of why I switched from firefox for my default browser -- when new versions are out upstream, with fixes for vulnerabilities X and Y that may very quickly have exploits available based on the fixes, and weeks later gentoo still doesn't have a working ebuild for it, I get worried! After all, among other things I do online banking with my default browser! For some time I worked around the problem by running upstream's binary-build (firefox-bin), but upstream firefox broke that solution when they quit supporting alsa-audio and required pulse-audio in ordered to get sound. Actually, I do still keep firefox-bin installed, but it's not default, because it won't play audio, and I spend enough time browsing youtube (in the browser, in addition to using minitube a lot of the rest of the time) that I don't consider a broken-audio browser a satisfactory default. Thus my reluctant switch to chromium. And actually, I must say, I've had less problems building it than I have firefox, and credit where it's due, the gentoo/chromium maintainers seem to keep a lot more current than the gentoo/firefox maintainers... unfortunately for firefox users. But I don't have a Java installed, and I'm not going to have one installed just for this if I can help it, so I was *very* happy to have someone post that patch! =:^) But, then along comes the next 72 version, and something else broke. And it /stayed/ broken even after a newer chromium-72 went stable! OK, so the point is, thanks for mentioning ungoogled-chromium. =:^) I had been thinking about trying it every since I saw that mention, and with the delay in getting an upstream-stabilized gentoo/chromium-72 out, I checked, and sure enough, it happens to be the googlized-stuff that was giving me difficulties trying to use the older 72 ebuild with the newer 72-upstream-stabilized version, and the ungoogled-chromium in the chaoslab overlay was already bumped, and it actually built for me! =:^) So definitely, thanks for that mention of ungoogled-chromium in chaoslab! I'm running it now. I still have to setup a script to update the extensions I have installed since ungoogled-chromium no longer does that automatically, but the upstream ungoogled-chromium site already has a FAQ entry with solutions I can adapt for that (and for that matter now that I think of it I've not actually checked whether the chaoslab overlay already has such an update-script package available, it might...), and they were current when I switched so they're good for now and I've a bit of time to work that out, but again, thanks for that mention because now I'm using it, and I'm already quite happy with it! =:^) Of course it'd be nice to have ungoogled-chromium in the gentoo mainline repo, but unless/until that happens the chaoslab overlay's a reasonable substitute. =:^)
Please do not post long, largely irrelevant comments on bug reports.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=dff605f2030ec8e60a47070de8d05bd7a3fc1470 commit dff605f2030ec8e60a47070de8d05bd7a3fc1470 Author: Mike Gilbert <floppym@gentoo.org> AuthorDate: 2019-02-12 21:45:54 +0000 Commit: Mike Gilbert <floppym@gentoo.org> CommitDate: 2019-02-12 21:46:28 +0000 www-client/chromium: add closure-compile USE flag This makes java an optional dependency. Closes: https://bugs.gentoo.org/672778 Package-Manager: Portage-2.3.59_p2, Repoman-2.3.12_p67 Signed-off-by: Mike Gilbert <floppym@gentoo.org> www-client/chromium/chromium-72.0.3626.96.ebuild | 5 +++-- www-client/chromium/metadata.xml | 1 + 2 files changed, 4 insertions(+), 2 deletions(-)
