emerge of vim-core results in * Applying 6.1.189... [ ok ] * Applying 6.1.190... * Failed Patch: 6.1.190! * * Include in your bugreport the contents of: * * /home/no_archive/portage/vim-core-6.1-r5/temp/6.1.190-13948.out !!! ERROR: app-editors/vim-core-6.1-r5 failed. !!! Function epatch, Line 321, Exitcode 0 !!! Failed Patch: 6.1.190! The specified file contains ***** 6.1.190 ***** =================== PATCH COMMAND: patch -p0 < /home/no_archive/portage/vim-core-6.1-r5/work/vimpatches/6.1.190 =================== patching file runtime/doc/os_vms.txt patching file src/gui_gtk_f.h patching file src/if_tcl.c patching file src/main.c patch: **** write error : No space left on device =================== PATCH COMMAND: patch -p1 < /home/no_archive/portage/vim-core-6.1-r5/work/vimpatches/6.1.190 =================== patch: **** write error : No space left on device cat: write error: Broken pipe =================== PATCH COMMAND: patch -p2 < /home/no_archive/portage/vim-core-6.1-r5/work/vimpatches/6.1.190 =================== patch: **** write error : No space left on device cat: write error: Broken pipe =================== PATCH COMMAND: patch -p3 < /home/no_archive/portage/vim-core-6.1-r5/work/vimpatches/6.1.190 =================== patch: **** write error : No space left on device cat: write error: Broken pipe =================== PATCH COMMAND: patch -p4 < /home/no_archive/portage/vim-core-6.1-r5/work/vimpatches/6.1.190 =================== patch: **** write error : No space left on device cat: write error: Broken pipe However, df command reveals there is plenty of space Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda8 256996 192784 64212 76% / tmpfs 2048 12 2036 1% /mnt/.init.d /dev/sda10 11132668 3491232 7641436 32% /home /dev/sda9 104380 94336 10044 91% /tmp /dev/sda5 4096408 2751312 1345096 68% /usr /dev/sda6 2048188 74352 1973836 4% /var tmpfs 63252 0 63252 0% /dev/shm ce: Reproducible: Always Steps to Reproduce: 1. 2. 3.
Hi, the ebuild wasn't lying, you really ran out of disk space temporarily. In the meantime stuff has been cleaned up and now there is space available. Due to the number of patches in vim you need about 30 MB free on the drive where /var/tmp/portage is mounted. There is a new vim.eclass as of this weekend that speeds up the patch application process, by the way. "emerge sync" to get it and try again. However if it runs out of space, it's the truth and you'll need to make room.
Sorry, I guess for you that would be /home/no_archive/portage instead of /var/tmp/portage. Also, patch requires space in /tmp for some of its work (see the patch man-page). If the problem is there, then you could try: export TMPDIR=/var/tmp emerge vim-core
Thinking this over further, I realized it would make more sense for patch to use the temporary space in the build area, rather than depending on /tmp (or the user's setting of TMPDIR). So I fixed the eclass to set TMPDIR correctly. It might take about a half-hour to become available on the rsync servers.
Marking FIXED instead of INVALID since hopefully the eclass now works around the problem.
Seems to me that Gentoo ebuilds are supposed to determine if there is enough disk space available to complete the ebuild before beginning. I cannot find the bug about this presently, but it sticks in my mind. Are we there with this ebuild?
There's no way for emerge to guarantee that the disk won't fill up at some point during the ebuild. You might be able to do something in DOS or some other inferior OS, but on Unix, any number of things can happen at any time to fill the disk up. That's just reality. If emerge does any kind of disk space checking at the beginning of the process, that's just a waste of time because it doesn't prove anything. It's much more efficient to check each disk write for success and bail out at the first failure.
