Bugzilla Bug 172573

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.