Emerging biounzip fails because the 64bit patch is hard-set to something like /var/tmp/portage/etc/etc/brainfart/ Changing the first two lines of the patch to start at /work/ allows epatch to function in cases when portage's tmpdir is not /var/tmp/. (In my case it is /dev/shm.) I don't know if that's the clean way to do relative paths but it Works For Me (tm). On a related note, shouldn't epatch apply patches only when they are architecturally necessary? I'm on 32-bit x86. Why is an amd64 patch being applied to an x86 system? Reproducible: Always Steps to Reproduce: 1. Set PORTAGE_TMPDIR in make.conf to /dev/shm 2. Emerge biounzip. 3. Cry. Actual Results: Emerge fails at patching with a big red Failed Patch error. Additional log reports indicate epatch finds the patch file, which in turn can't find anything to patch. Expected Results: biounzip should have emerged. Just for clarity's sake, my fix is to change this: --- /var/tmp/portage/games-util/biounzip-1.1a/work/biounzip-1.1-old/biounzip.c 2007-03-08 02:06:16.000000000 +0200 +++ /var/tmp/portage/games-util/biounzip-1.1a/work/biounzip-1.1/biounzip.c 2007-03-08 02:06:50.000000000 +0200 to this: --- /work/biounzip-1.1-old/biounzip.c 2007-03-08 02:06:16.000000000 +0200 +++ /work/biounzip-1.1/biounzip.c 2007-03-08 02:06:50.000000000 +0200 Caveat is that I'm no software developer and I really have no idea what I'm doing.
(In reply to comment #0) > On a related note, shouldn't epatch apply patches only when they are > architecturally necessary? I'm on 32-bit x86. Why is an amd64 patch being > applied to an x86 system? Nope. Policy states we apply them unilaterally except in cases where they can break other arches. Anyway, I think I've fixed this now.
