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?
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.
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?
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
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.
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?
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).
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
such huge usage from USE=nsplugin seems very suspect...
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?
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.
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...
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)
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
