When running an emerge gcc(after doing an emerge sync), it downloads gcc 3.2.3-r3 and starts to apply a patch with the following error: * Failed Patch: gcc-3.2.3-tls-update.patch.bz2! * * Include in your bugreport the contents of: * * /var/tmp/portage/gcc-3.2.3-r3/temp/gcc-3.2.3-tls-update.patch.bz2-4113.out URL above points to that file. Current version of gcc is 3.2.3-r2 Reproducible: Always Steps to Reproduce: 1.emerge sync 2.emerge -u gcc 3. Actual Results: * Applying gcc-3.2.3-tls-update.patch.bz2... * Failed Patch: gcc-3.2.3-tls-update.patch.bz2! * * Include in your bugreport the contents of: * * /var/tmp/portage/gcc-3.2.3-r3/temp/gcc-3.2.3-tls-update.patch.bz2-20585.out !!! ERROR: sys-devel/gcc-3.2.3-r3 failed. !!! Function epatch, Line 322, Exitcode 0 !!! Failed Patch: gcc-3.2.3-tls-update.patch.bz2! Expected Results: Uhmm - less errormessages :)
FWIW, I had this problem, with the same error messages. I deleted the work directories as well as all of the source files in distfiles, then re-emerged, and it worked.
the patch that may have failed was apparently not the tls update this is because the logic always displays the last applied patch as being the failed one. two possible problems play into this: 1) the abort shows only the last patch that failed, which must not necessarily be the patch that actually led into the failure. 2) when emerging gcc, interrupting it, restarting it and in the meantime not removing the involved directory in /var/tmp/portage, it may not be removed and recreated (call this a portage bug or what) on given heuristics. recent versions recognize the timestamp on the patches and source packages involved and can recreate the working directory. however, it may still happen that patching in gcc breaks when (as the last comment also noticed) the "old" directory is still around. thanks, Alex
is this this an issue ?
should be all set on this
