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.
