Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 646034 - net-libs/webkit-gtk-2.18.6 needs CHECKREQS_DISK_BUILD increasing beyond 20G
Summary: net-libs/webkit-gtk-2.18.6 needs CHECKREQS_DISK_BUILD increasing beyond 20G
Status: CONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Linux Gnome Desktop Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-01-29 09:27 UTC by Mike Auty
Modified: 2019-12-31 13:40 UTC (History)
0 users

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 Mike Auty gentoo-dev 2018-01-29 09:27:35 UTC
Hiya,

I've got -ggdb in my CFLAGS.  Currently webkit-gtk's CHECKREQS_DISK_BUILD is set to 18G but ended up failing to build on my 20G tmpfs for /var/tmp/portage due to disk space (no other package was using space there).  Could we up the requirement please?

It fails in the install phase, so my guess is 20G isn't far off, but we need to add the space required for a complete image to that value as well.  Hopefully 21G would solve it, but if there's an easy way to determine the exact minimum requirement I'd be happy to run a test to figure it out?
Comment 1 Mart Raudsepp gentoo-dev 2018-01-29 09:37:21 UTC
Maybe temporary FEATURES="keeptemp keepwork" or something? Not sure if the image part gets left over, which might take some space too. I'm not very excited about fiddling with these values, but if you do the work and give me the numbers, sure I guess.
Looks like we only do this for -g values, ignoring non-debug builds also quite big requirements (but those should fit below 3G). Which of course also means the requirement is probably different for -g1, -ggdb3, etc.
Comment 2 Mike Auty gentoo-dev 2018-01-29 19:52:04 UTC
I'm not sure what work you're after?  I can change the:

CHECKREQS_DISK_BUILD="18G" # and even this might not be enough, bug #417307

line to read:

CHECKREQS_DISK_BUILD="21G" # Correct for -ggdb as of 2018-01-29

(since quickpkg creates a tarball that unpacks to 66Mb, and with 20G you can get to the install phase, so I suspect that 21G will sort it), but that seems like a trivial change.  Have I missed other work that would need to be done?

FEATURES="keeptemp keepwork" doesn't seem like it'll help except if the build bombs out after several hours of compilation.  I'd thought the whole point of CHECKREQS_DISK_BUILD was to save people from trying to complete a build on a drive that has too little space?  What's the downside to upping it to 21G (only for "-g" flag users), if the package requires that much to build successfully?

I'm not keen on tinkering such a complex ebuild, but it seems the check isn't actually doing its job at the moment?  If you believe 18G is a suitable value across the other -g flags then I'm happy for it to stay that way, but it will likely irritate users with 20G tmpfs drives who use -ggdb.

Lemme know how you'd like to leave this?
Comment 3 Mart Raudsepp gentoo-dev 2018-01-29 20:30:09 UTC
keeptemp/keepwork was just to help find out what the requirement is. To du -hs it after a successful build. It was a response to "but if there's an easy way to determine the exact minimum requirement I'd be happy to run a test to figure it out".

Make the proposed change then yourself (but maybe state the current version or both, not just date),

Acked-by: Mart Raudsepp <leio@gentoo.org>
Closes: https://bugs.gentoo.org/646034
Comment 4 Gilles Dartiguelongue gentoo-dev 2018-01-30 17:07:02 UTC
portage should print various disk stats after each successful install. Maybe that would help getting a more precise idea of how much is actually needed. Rounding that up is ok of course, you just don't want to set a random value just to find out it does not work in all cases.
Comment 5 Mike Auty gentoo-dev 2018-02-02 10:07:44 UTC
Hmmmm, I think I tracked down the issue.  It seems that USE="nsplugin" has a significant impact.  5:S  Without I get the following:

 * Final size of build directory: 13186872 KiB (12.5 GiB)
 * Final size of installed tree:   4082692 KiB ( 3.8 GiB)

With it enabled I get:

 * Final size of build directory: 15688068 KiB (14.9 GiB)
 * Final size of installed tree:   6537144 KiB ( 6.2 GiB)

I'm not sure if it's worth making per-USE-flag values, or whether we just leave it at 18?  We should probably include an additional warning if -g and nsplugin but if we're going that far, why not just change the build requirement size?  What does everyone think is the best way of handling this?
Comment 6 Mart Raudsepp gentoo-dev 2018-02-02 13:14:26 UTC
I would start by wondering how does the final size of installed tree differ so much. It's supposedly just adding a gtk2 plugin process thing to support gtk2 based nsplugins... (nsplugin is supported without USE=nsplugin, that just adds gtk2 support to be able to use e.g. adobe-flash, which still links to gtk2).
Comment 7 Mike Auty gentoo-dev 2018-02-04 12:20:59 UTC
It appears most of the extra weight is in WebKitPluginProcess2 which comes out as a 2.5Gb file (and does not exist in USE="-nsplugin" builds).  Everything else seems small fry to that.  The libwebkit2gtk-4.0.so.37{,24.9} are both 2.9Gb but that's the same size under USE="-nsplugin".  Otherwise there's a couple extra directories taking up 12Mb and 32Mb respectively.

So that extra 2.5Gb would explain both the build and install image sizes (since the file will get installed).  Unfortunately it seems necessary for the feature being requested, but it should really be adding 5G to the necessary CHECKREQS value in that case (which would be around 16G, but might be just over)...  5:S
Comment 8 Mart Raudsepp gentoo-dev 2018-02-23 06:04:26 UTC
such huge usage from USE=nsplugin seems very suspect...
Comment 9 Mike Auty gentoo-dev 2018-02-23 09:43:05 UTC
It is a little confusing why gkt2 support requires a whole second executable but the libraries don't seem to change much in size?  Does WebKitPluginProcess still get used if WebKitPluginProcess2 exists?
Comment 10 Mart Raudsepp gentoo-dev 2018-02-23 11:34:45 UTC
webkit-gtk:4 itself is linking against gtk+:3. adobe-flash links against gtk+:2. gtk+:2 and gtk+:3 can't co-exist in the same process, so the extra thing installed by USE=nsplugin is for gtk+:2 using nsplugins.
It should be just a small thing (think like the old nspluginwrapper), not something that makes the build take gigabytes of more space.
Comment 11 Mike Auty gentoo-dev 2018-02-25 20:41:43 UTC
Ok, it seems the webkit developers just rebuilt the main process for running plugins with Gtk2 rather than Gtk3, so we end up with a complete duplicate of the WebKitPluginProcess, which itself is several Gb.   Not sure how you want to deal with it, but that's what seems to be happening...
Comment 12 Mart Raudsepp gentoo-dev 2019-12-29 14:06:46 UTC
Is this still a concern?
Note that gtk2 plugin process goes away with webkit-gtk-2.26 (support for adobe-flash is essentially dropped), so shouldn't be increasing the requirements oddly like this (and 2.26 is going stable ASAP for security)
Comment 13 Ulenrich 2019-12-31 13:40:13 UTC
With USE -coverage and -webgl 
I never had more than:
  build max	813276 kb  net-libs/webkit-gtk: 12294s average for 7 merges

This my minutely running du script had written into a log for webkit-gtk