Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 669082 - dev-qt/qtwebengine-bin package
Summary: dev-qt/qtwebengine-bin package
Status: UNCONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: Normal normal with 10 votes (vote)
Assignee: Default Assignee for New Packages
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-10-20 16:19 UTC by Pavel Kozlov
Modified: 2020-06-03 17:58 UTC (History)
13 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Pavel Kozlov 2018-10-20 16:19:07 UTC
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

...
Comment 1 jms 2019-04-23 18:19:50 UTC
oh yes please a bin package.
this is becoming a pain .
It will rise earth temperature by another 1°c by itself.
Comment 2 Till Schäfer 2019-10-30 01:53:52 UTC
+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.
Comment 3 Bodo Graumann 2019-11-03 10:11:01 UTC
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?
Comment 4 Andreas Sturmlechner gentoo-dev 2019-11-12 17:40:18 UTC
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.
Comment 5 Chiitoo gentoo-dev 2019-11-12 18:05:48 UTC
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.
Comment 6 jeff.lemos.a 2019-12-07 02:51:49 UTC
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
Comment 7 Erik Solomon 2020-01-20 08:21:39 UTC
Till Schäfer

It's still over 4:30 hours with my nice 8 core and 16GB.  Never touches swap, though.
Comment 8 Simon 2020-05-22 19:41:15 UTC
+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?
Comment 9 Paul Gover 2020-05-23 11:37:42 UTC
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.
Comment 10 jms 2020-05-23 11:45:16 UTC
what I ve got
(alsa bindist jumbo-build pulseaudio system-ffmpeg system-icu widgets -debug -designer -geolocation -kerberos -test)
Comment 11 Vasilis Lourdas 2020-05-23 11:51:10 UTC
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.
Comment 12 jms 2020-05-23 12:21:27 UTC
(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
Comment 13 Vasilis Lourdas 2020-05-23 12:25:06 UTC
(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.
Comment 14 jms 2020-05-23 12:38:11 UTC
(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
Comment 15 Chiitoo gentoo-dev 2020-05-24 18:30:26 UTC
(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.
Comment 16 Simon 2020-06-03 17:58:18 UTC
(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?