<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<!DOCTYPE bugzilla SYSTEM "http://bugs.gentoo.org/bugzilla.dtd">

<bugzilla version="2.22.7"
          urlbase="http://bugs.gentoo.org/"
          maintainer="bugzilla@gentoo.org"
>

    <bug>
          <bug_id>172573</bug_id>
          
          <creation_ts>2007-03-28 16:40 0000</creation_ts>
          <short_desc>games-util/biounzip 64bit patch fails when PORTAGE_TMPDIR not set to default</short_desc>
          <delta_ts>2007-03-29 15:38:21 0000</delta_ts>
          <reporter_accessible>1</reporter_accessible>
          <cclist_accessible>1</cclist_accessible>
          <classification_id>1</classification_id>
          <classification>Unclassified</classification>
          <product>Gentoo Linux</product>
          <component>Games</component>
          <version>unspecified</version>
          <rep_platform>All</rep_platform>
          <op_sys>Linux</op_sys>
          <bug_status>RESOLVED</bug_status>
          <resolution>FIXED</resolution>
          
          
          
          <priority>P2</priority>
          <bug_severity>normal</bug_severity>
          <target_milestone>---</target_milestone>
          
          
          
          <everconfirmed>1</everconfirmed>
          <reporter>curiousgeorge_banana@yahoo.com</reporter>
          <assigned_to>games@gentoo.org</assigned_to>
          

      

      
          <long_desc isprivate="0">
            <who>curiousgeorge_banana@yahoo.com</who>
            <bug_when>2007-03-28 16:40:09 0000</bug_when>
            <thetext>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&apos;s tmpdir is not /var/tmp/. (In my case it is /dev/shm.) I don&apos;t know if that&apos;s the clean way to do relative paths but it Works For Me (tm).

On a related note, shouldn&apos;t epatch apply patches only when they are architecturally necessary? I&apos;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&apos;t find anything to patch.

Expected Results:  
biounzip should have emerged.

Just for clarity&apos;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&apos;m no software developer and I really have no idea what I&apos;m doing.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>wolf31o2@gentoo.org</who>
            <bug_when>2007-03-29 15:38:21 0000</bug_when>
            <thetext>(In reply to comment #0)
&gt; On a related note, shouldn&apos;t epatch apply patches only when they are
&gt; architecturally necessary? I&apos;m on 32-bit x86. Why is an amd64 patch being
&gt; 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&apos;ve fixed this now.</thetext>
          </long_desc>
      
    </bug>

</bugzilla>