Emerge has been spitting this out for a while: ... * 30_all_gcc33-sparc-default-v8.patch.bz2... [ ok ] * 31_all_gcc33-s390-biarch.patch.bz2... [ ok ] * 32_all_gcc33-ggc_page-speedup.patch.bz2... [ ok ] * Done with patching * Applying various patches (bugfixes/updates)... * 01_all_gcc33-sparc-uninitialized-warning-fix.patch.bz2... * Failed Patch: 01_all_gcc33-sparc-uninitialized-warning-fix.patch.bz2! * * Include in your bugreport the contents of: * * /var/tmp/portage/gcc-3.3/temp/01_all_gcc33-sparc-uninitialized-warning-fix.patch.bz2-11192.out !!! ERROR: sys-devel/gcc-3.3 failed. !!! Function epatch, Line 321, Exitcode 0 !!! Failed Patch: 01_all_gcc33-sparc-uninitialized-warning-fix.patch.bz2! Reproducible: Always Steps to Reproduce: 1. 'emerge gcc' (portage tree is NFS-mounted from another machine). 2. count sheep. 3. scratch head at error. Actual Results: emerge failed Expected Results: new version of GCC to emerge Snipped from /etc/make.conf (note that I changed the location of some portage folders to accomodate the NFS-shared tree and to simplify my life): USE="acpi alsa cdr dga dvd ggi -gnome pda pnp samba tiff usb wmf" CHOST="i686-pc-linux-gnu" CFLAGS="-march=athlon-tbird -O3 -pipe" CXXFLAGS="${CFLAGS}" #ACCEPT_KEYWORDS="~x86" PORTAGE_TMPDIR=/var/tmp PORTDIR=/usr/portage DISTDIR=/usr/portage-distfiles PKGDIR=/usr/packages-darkfuture PORT_LOGDIR=/var/log/portage PORTDIR_OVERLAY=/usr/portage-overlay SYNC="rsync://rsync.namerica.gentoo.org/gentoo-portage" MAKEOPTS="-j2" PORTAGE_NICENESS=19 AUTOCLEAN="yes"
I encountered this bug recently myself when copying the gcc-3.3.ebuild to gcc-3.3-r1.ebuild for making small editing changes. This problem is solved by editing the ebuild to comment out the lines where it does an epatch on the patch directory. The problem is that it is applying all patches from this directory and THEN hitting the location in the ebuild where the epatch command is. when it hits the epatch command it tries to apply these patches yet again. in my local revision i was conditionally deleting patches right before running the epatch command in the ebuild, within the if statement that checks for PATCH_VER, and i noticed even when i used rm -fv nothing was getting deleted before the patch was run and then it would delete files and run that epatch. so it would apply the sed patches and the like, then patch everything in the patch directory, and then run the epatch command which would patch everything in that directory (i had commented out the athlon patch as well as other things). oddly enough, for me the gcc-3.3.ebuild file did not produce this error. to make things even more odd, later on i made yet another gcc-3.3-r1.ebuild and it also did not produce this error... the epatch runs as expected without another epatch being run beforehand. i am thinking this is an error in either elibtoolize or epatch but at this moment i cant figure it out as i cant reproduce this error. since the eclasses are part of the portage tree, i would suggest running an emerge sync and trying again and then giving more detailed output. i'm specifically interested to know if the athlon hammer update patches before the first patch.
Created attachment 13921 [details] this ebuild causes the error to happen YES! I got it to reproduce this bug. I still have no freaking clue as to why it happens but at least now somebody else who happens to see this bug can reproduce it and try to figure out what's wrong.
Well, I missed that. But it basically means that you had some files (patches) in $FILESDIR missing for epatch to revert to the default path (which is $WORKDIR/patch) ....
Reopen with more info if its a problem with stock ebuilds, thanks.
