Bug 497148 – www-client/seamonkey-2.22.1 disk space check - needs more than 4 GiB

• Product: Gentoo Linux
• Status: RESOLVED OBSOLETE

[Description kavol 2014-01-05 16:18:46 UTC]

I've just tried to emerge seamonkey and it failed due to insufficient disk space, despite the ebuild check passed - I had 4.5 GB free.
So it seems the limit should be increased ...

Reproducible: Always

Steps to Reproduce:
1. df -h
2. emerge seamonkey

Actual Results:  
...
/dev/sda1            688G  652G  4.5G 100% /
...

 * Checking for at least 4 gigabytes disk space at "/var/tmp/portage/www-client/seamonkey-2.22.1/temp" ...                                                                                                                            [ ok ]
...

build fails with messages like:

Cannot write file - not enough space on device.

Expected Results:  
 * Checking for at least 4 gigabytes disk space at "/var/tmp/portage/www-client/seamonkey-2.22.1/temp" ...                                                                                                                            [fail]

build doesn't continue

my use in effect:

[ebuild     U  ] www-client/seamonkey-2.22.1 [2.21] USE="alsa crypt dbus gstreamer ipc jit libnotify startup-notification -chatzilla -custom-cflags -custom-optimization -debug -minimal -pulseaudio -roaming (-selinux) -system-cairo -system-icu -system-jpeg -system-sqlite -wifi" LINGUAS="cs sk -be -ca -de -en_GB -es_AR -es_ES -fi -fr -gl -hu -it -ja -lt -nb_NO -nl -pl -pt_PT -ru -sv_SE -tr -uk -zh_CN -zh_TW" 0 kB


... the space requirements may differ, the ebuild should warn about the maximum and don't let to continue even if the minimum is not met

[Comment 1 Jeff (JD) Horelick (RETIRED) 2014-01-05 17:05:38 UTC]

I can not confirm this on x86. My /var/tmp/portage is a 4.0GB tmpfs and seamonkey-2.22.1 compiles fine inside it.

Perhaps the amd64 compile uses significantly more disk space, but it doesn't seem likely.

Also, are you using -pipe in your CFLAGS? If you don't, GCC writes the tempfiles to disk making the compile slower and causes it to use more disk.

[Comment 2 kavol 2014-01-05 17:34:01 UTC]

(In reply to Jeff (JD) Horelick from comment #1)
> Also, are you using -pipe in your CFLAGS? If you don't, GCC writes the
> tempfiles to disk making the compile slower and causes it to use more disk.

yes, I do have -pipe in CFLAGS, but speaking about them ... it reminds me I have also -ggdb (and -splitdebug in FEATURES), so maybe this could be the culprit?

... recently, I've seen webkit-gtk ebuild complaining about that

p.s. even 5.7 GB doesn't seem to be enough

[Comment 3 Lars Wendler (Polynomial-C) (RETIRED) 2014-01-05 18:17:06 UTC]

I'm afraid I cannot reproduce this. I don't get the whole package consuming more than 2GB of diskspace during compilation here.
Nevertheless if you can provide some rasonable numbers I'm willing to adjust the diskspace check accordingly.

[Comment 4 Jeff (JD) Horelick (RETIRED) 2014-01-05 20:36:34 UTC]

(In reply to kavol from comment #2)
> yes, I do have -pipe in CFLAGS, but speaking about them ... it reminds me I
> have also -ggdb (and -splitdebug in FEATURES), so maybe this could be the
> culprit?

-ggdb might cause this (Unless Polynomial-C can confirm that it doesn't).

[Comment 5 kavol 2014-01-05 22:36:38 UTC]

Created attachment 367132 [details]
file sizes with -ggdb

[Comment 6 kavol 2014-01-05 22:37:07 UTC]

Created attachment 367134 [details]
file sizes without -ggdb

[Comment 7 kavol 2014-01-05 22:46:04 UTC]

(In reply to Jeff (JD) Horelick from comment #4)
> -ggdb might cause this (Unless Polynomial-C can confirm that it doesn't).

well, yes, it does - see the attachments

I've tried to do 'ebuild seamonkey-2.22.1.ebuild install' and then check the file sizes in /var/tmp/portage/...

so, probably, this flag should be taken into account in the check (as mentioned above, there may be some inspiration within the webkit-gtk ebuild)

but as this flag is recommended to provide useful backtraces, see e.g.
http://wiki.gentoo.org/wiki/Project:Quality_Assurance/Backtraces
maybe it'd be better to try to handle it at the system level and not in individual ebuilds ... just a thought ...

[Comment 8 Jory A. Pratt 2017-08-26 17:55:31 UTC]

If you feel I have closed your bug and it is still a current issue, please reopen and update it completely. We will not work bugs that have no ebuild in tree any longer or can not be reproduced with a current system.

Thank You for your support and understanding
The Mozilla Team