Hello! dev-qt/qtwebengine takes really huge time to compile - and it became worse after every next version. Last time it took more than 8 hours to build on my laptop! Of course it is not new, but still core-i5 with 6 gigabytes of memory... Sat Oct 20 15:05:28 2018 >>> dev-qt/qtwebengine-5.11.1 merge time: 8 hours, 9 minutes and 46 seconds. I know that gentoo has some bin versions of packages which were created in intention to reduce compile-time which doesn't make really much sense - like firefox-bin or libreoffice-bin. In fact, firefox takes just about 1.5 hour to compile in my laptop, which is acceptable, I don't use firefox-bin, I use firefox package - it is OK for me. But why qtwebengine takes so long? Can it be improved? I am OK to use -bin version for it, is this possible? emerge --info (first part with processor and memory) Portage 2.3.49 (python 3.6.5-final-0, default/linux/amd64/17.1/desktop/plasma, gcc-7.3.0, glibc-2.26-r7, 4.18.9-gentoo x86_64) ================================================================= System uname: Linux-4.18.9-gentoo-x86_64-Intel-R-_Core-TM-_i5-3230M_CPU_@_2.60GHz-with-gentoo-2.4.1 KiB Mem: 5909444 total, 1578476 free KiB Swap: 1048572 total, 851256 free ...
oh yes please a bin package. this is becoming a pain . It will rise earth temperature by another 1°c by itself.
+1 compilation times are skyrocketing here on my laptop with core 2 duo / 4GiB RAM: 2019-01-07T21:53:17 >>> dev-qt/qtwebengine-5.11.1: 7 hours, 29 minutes, 17 seconds 2019-06-05T07:06:21 >>> dev-qt/qtwebengine-5.12.3: 16 hours, 34 minutes, 2 seconds current merge (5.12.5) is running for 18 hours now and is not finished yet.
Yes please provide a binary package! I have masked this package on my system because of the ridiculous long build time. This project includes a large part of the chromium code base. I need to install nextcloud-client, but am not able because of this package. :-( Maybe as a quick fix somebody can point me to a public binhost?
For everyone with such long build times, please look at USE=jumbo-build, build will be much, much faster. Make sure your MAKEOPTS value is not unreasonable though taking into account available RAM. Demand can go up to 2GB per process.
We'd already have a binary package if it was a simple thing to provide while also doing it right. With regards to the build time, I'll add that it might be worth checking if swapping and/or thermal throttling is happening. Either will very likely slow down the build considerably. I'll also add that it looks like jumbo-build will be going away at around Chromium 80 or some time after, but only time will really tell.
I have found this flag: --no-keep-memory; in case the system runs out of memory when processing ld at the end, when using jumbo-build. Putting it on /portage/env could be a good idea in such case
Till Schäfer It's still over 4:30 hours with my nice 8 core and 16GB. Never touches swap, though.
+1 for this request, this package is a pain. (In reply to Chiitoo from comment #5) > We'd already have a binary package if it was a simple thing to provide while > also doing it right. > > With regards to the build time, I'll add that it might be worth checking if > swapping and/or thermal throttling is happening. Either will very likely > slow down the build considerably. > > I'll also add that it looks like jumbo-build will be going away at around > Chromium 80 or some time after, but only time will really tell. What are the challenges/what needs to be done to make a binary package for this possible?
My guess is the choice of USE flags. I'd go for: alsa bindist -designer geolocation -kerberos pulseaudio +system-ffmpeg +system-icu widgets which is pretty much the defaults apart from removing designer.
what I ve got (alsa bindist jumbo-build pulseaudio system-ffmpeg system-icu widgets -debug -designer -geolocation -kerberos -test)
Having +system-icu and +system-ffmpeg would cause a rebuild in case either of these libraries changed their ABI. In my opinion, it might be best if these flags were off for the *binary* package of qtwebengine to reduce any external dependencies. Just like when both icu and libreoffice-bin get bumped together, because the former depends on the latter.
(In reply to Vasilis Lourdas from comment #11) > Having +system-icu and +system-ffmpeg would cause a rebuild in case either > of these libraries changed their ABI. In my opinion, it might be best if > these flags were off for the *binary* package of qtwebengine to reduce any > external dependencies. Just like when both icu and libreoffice-bin get > bumped together, because the former depends on the latter. Agreed. -system-icu -system-ffmpeg This makes sense to me for a binary package and -debug -test +alsa +bindist what about theses? +pulseaudio (I am for it I use it) -designer (don't think many people use it) -geolocation -kerberos
(In reply to jms from comment #12) > Agreed. > -system-icu -system-ffmpeg > This makes sense to me for a binary package > and > -debug -test > +alsa +bindist > what about theses? > +pulseaudio (I am for it I use it) > -designer (don't think many people use it) > -geolocation > -kerberos Yes, these make sense, but I also think +widgets is needed too.
(In reply to Vasilis Lourdas from comment #13) > (In reply to jms from comment #12) > > Agreed. > > -system-icu -system-ffmpeg > > This makes sense to me for a binary package > > and > > -debug -test > > +alsa +bindist > > what about theses? > > +pulseaudio (I am for it I use it) > > -designer (don't think many people use it) > > -geolocation > > -kerberos > > Yes, these make sense, but I also think +widgets is needed too. yes I forgot
(In reply to Simon from comment #8) > What are the challenges/what needs to be done to make a binary package for > this possible? Mainly probably reverse dependencies, and bundling the most annoying ones while also keeping them up-to-date especially with regards to security updates and such.
(In reply to Chiitoo from comment #15) > (In reply to Simon from comment #8) > > What are the challenges/what needs to be done to make a binary package for > > this possible? > > Mainly probably reverse dependencies, and bundling the most annoying ones > while also keeping them up-to-date especially with regards to security > updates and such. OK, thanks for the clarification. That seems doable. Is there already something in place within gentoo's infrastructure to build and distribute binary packages? Or would this need to be done by a dev on his/her own account? I assume we could use a binpkg for this?
definitely +1...this package has become a huge deal when updating my laptop. Though it's really old (11-years old, dual core, 4GB RAM), updating everything else every now and then is fine...but this one: > 14 hours
+1 for the bin package. This would relieve my aging laptops a bit.
Newer qtwebengine package. Still hours to build, especially when you maintain 4 Gentoo installations. Is there hope to finally see a binary version of this package?
Vasilis, if your 4 installations share a common CPU architecture, you should be able to build a binary package on just one (the most powerful), and install that on the other 3. For added value, you might be able to use DISTCC to spread the compilation across all the machines. See the wiki for details of both. That said, I'd still like to see a qtwebengine-bin package!
Ok, this is ridiculous. Today I got a libjpeg-turbo update which causes a qtwebengine rebuild. In my (relatively strong) PC, it takes an hour to compile. In my 2-core laptop, it took more than 3 hours to compile (even with the jumbo-build USE flag). And just because libjpeg-turbo was updated, another rebuild is needed. Today marks exactly 2 years after this bug was opened. Is someone willing to provide a binary package for this time-consuming package?
+1 for a much needed qtwebengine-bin There are some packages I don't emerge and some USE flags I don't use so that they don't trigger the qtwebengine monster.
Another day, another qtwebengine rebuild. And as I thought Zoom needed it (and in fact it did at first, but not now), the latest digikam-7.0 requires it. Today dev-libs/re2 causes a rebuild of this freaking package...
+1 for the bin package. It takes 3 hours on my 8cores/16G computer.
(In reply to email200202 from comment #24) > +1 for the bin package. > > It takes 3 hours on my 8cores/16G computer. You should enable the jumbo-build USE flag for this package, for your system, it shouldn't take more than an hour.
(In reply to Vasilis Lourdas from comment #25) > (In reply to email200202 from comment #24) > > +1 for the bin package. > > > > It takes 3 hours on my 8cores/16G computer. > > You should enable the jumbo-build USE flag for this package, for your > system, it shouldn't take more than an hour. It takes 3 hours with jumbo-build USE flag enabled. In the latest version dev-qt/qtwebengine-5.15.2, jumbo-build USE flag was removed! # cat /usr/portage/dev-qt/qtwebengine/qtwebengine-5.15.2.ebuild .... IUSE="alsa bindist designer geolocation kerberos pulseaudio +system-ffmpeg +system-icu widgets" .... src_prepare() { if use ppc64; then eapply "${WORKDIR}/${PN}-ppc64" fi # QTBUG-88657 - jumbo-build is broken #if ! use jumbo-build; then sed -i -e 's|use_jumbo_build=true|use_jumbo_build=false|' \ src/buildtools/config/common.pri || die #fi
dev-qt/qtwebengine-5.15.2 merge took 6 hours 43 minutes! # genlop -t dev-qt/qtwebengine Wed May 20 20:30:20 2020 >>> dev-qt/qtwebengine-5.14.2 merge time: 2 hours, 50 minutes and 28 seconds. Wed May 27 18:48:10 2020 >>> dev-qt/qtwebengine-5.15.0 merge time: 3 hours, 9 minutes and 3 seconds. Wed Jul 15 17:01:58 2020 >>> dev-qt/qtwebengine-5.15.0 merge time: 3 hours, 1 minute and 21 seconds. Fri Sep 11 18:40:38 2020 >>> dev-qt/qtwebengine-5.15.1 merge time: 3 hours, 9 minutes. Mon Oct 19 15:41:27 2020 >>> dev-qt/qtwebengine-5.15.1 merge time: 2 hours, 59 minutes and 23 seconds. Thu Nov 5 03:37:44 2020 >>> dev-qt/qtwebengine-5.15.1 merge time: 2 hours, 59 minutes and 29 seconds. Fri Nov 27 05:03:23 2020 >>> dev-qt/qtwebengine-5.15.2 merge time: 6 hours, 43 minutes and 28 seconds.
*** Bug 758341 has been marked as a duplicate of this bug. ***
This really needs to be addressed; I'm on a decently new/good specced laptop and even after I started using the -jumbo-build flag in October or so you can see from genlop output how much that has NOT helped: Sat Jan 11 21:32:07 2020 >>> dev-qt/qtwebengine-5.14.0 merge time: 5 hours, 14 minutes and 48 seconds. Mon Feb 3 01:53:42 2020 >>> dev-qt/qtwebengine-5.14.1 merge time: 9 hours, 9 minutes and 53 seconds. Sun Feb 16 05:14:32 2020 >>> dev-qt/qtwebengine-5.14.1 merge time: 9 hours, 46 minutes and 27 seconds. Sun Mar 22 01:07:15 2020 >>> dev-qt/qtwebengine-5.14.1 merge time: 7 hours, 36 minutes and 29 seconds. Sun Apr 5 08:53:14 2020 >>> dev-qt/qtwebengine-5.14.1 merge time: 8 hours, 41 minutes and 20 seconds. Sun Apr 12 02:44:46 2020 >>> dev-qt/qtwebengine-5.14.2 merge time: 8 hours, 34 minutes and 8 seconds. Fri May 1 19:35:51 2020 >>> dev-qt/qtwebengine-5.14.2 merge time: 6 hours, 6 minutes and 27 seconds. Sun May 10 09:02:10 2020 >>> dev-qt/qtwebengine-5.14.2 merge time: 8 hours and 18 seconds. Sun May 31 02:55:19 2020 >>> dev-qt/qtwebengine-5.15.0 merge time: 9 hours, 57 minutes and 12 seconds. Wed Jul 15 15:20:16 2020 >>> dev-qt/qtwebengine-5.15.0 merge time: 6 hours, 59 minutes and 19 seconds. Fri Sep 11 16:15:06 2020 >>> dev-qt/qtwebengine-5.15.1 merge time: 5 hours, 31 minutes and 28 seconds. Sat Oct 31 16:44:17 2020 >>> dev-qt/qtwebengine-5.15.1 merge time: 4 hours, 12 minutes and 21 seconds. Wed Nov 4 16:13:45 2020 >>> dev-qt/qtwebengine-5.15.1 merge time: 4 hours, 26 minutes and 38 seconds. Fri Nov 27 23:15:26 2020 >>> dev-qt/qtwebengine-5.15.2 merge time: 9 hours, 33 minutes and 18 seconds. Tue Dec 8 22:32:36 2020 >>> dev-qt/qtwebengine-5.15.2 merge time: 11 hours, 45 minutes and 28 seconds.
CPU : Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz RAM : 4Gb dev-qt/qtwebengine-5.15.2: 19 hours, 58 minutes, 22 seconds average for 1 merge dev-qt/qtwebengine-5.14.1: 15 hours, 20 minutes, 50 seconds average for 1 merge USE flags : dev-qt/qtwebengine-5.15.2 -alsa -bindist -debug -designer -geolocation -kerberos -pulseaudio -system-ffmpeg -system-icu -test widgets Shrug... Worst of this : it is required only for KmyMoney (which I will simply download the AppImage in the future) ... Previous "jumbo-build" USE flag looks to have saved like 4 hours...
(In reply to Tiger from comment #30) > CPU : Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz > RAM : 4Gb > > dev-qt/qtwebengine-5.15.2: 19 hours, 58 minutes, 22 seconds average for 1 > merge > dev-qt/qtwebengine-5.14.1: 15 hours, 20 minutes, 50 seconds average for 1 > merge > > USE flags : > dev-qt/qtwebengine-5.15.2 -alsa -bindist -debug -designer -geolocation > -kerberos -pulseaudio -system-ffmpeg -system-icu -test widgets > > Shrug... > > Worst of this : it is required only for KmyMoney (which I will simply > download the AppImage in the future) ... > > Previous "jumbo-build" USE flag looks to have saved like 4 hours... Today I synced and I also got the stable 5.15.2 ebuild without the jumbo-build flag. I copied the ebuild to my local overlay, re-enabled the jumbo-build flag since I don't use GCC 10 and I will compile it. Let's hope that in 2021 the developers will decide to provide a binary package.
another +1 this gets troubling to build on my haswell i7-4810MQ system 2020-11-20T02:53:17 >>> dev-qt/qtwebengine-5.15.1: 2 hours, 18 minutes, 14 seconds 2020-11-26T15:58:09 >>> dev-qt/qtwebengine-5.15.2: 5 hours, 6 minutes, 46 seconds
There won't be any progress here if all that people do is posting additional +1 comments. Someone has to step up and write an ebuild, and be prepared to maintain the package (e.g., rebuild it against new versions of dev-libs/icu).
I'm sorry for yet another +1, but this package is a potential death sentence on Gentoo on many of my desktop machines.
Ulrich, is it possible to release a binpkg binary as an ebuild? The discussions earlier seem to imply a binary package along the lines of say firefox, which can optionally contain specific versions of dependencies; I understand why that can make sense for such packages, but the need here is simply (for certain values of "simple") avoiding the mega-compilation. IIUC, two things need to be developed: something in catalyst to build and package qtwebengine for various platforms, and an ebuild that installs the result. I do something different on my home setup - I compile it on my ryzen-9 desktop machine (in less than an hour), and install the binpkg on my laptop (where it would probably take a day). But AFAIK ebuilds don't do that. Or can they?
