Bug 237667 - epatch should skip -p0 for patchs with absolute paths in them - fix made multiple patches fail
Bug#: 237667 Product:  Gentoo Linux Version: 2008.0 Platform: All
OS/Version: Linux Status: RESOLVED Severity: normal Priority: P2
Resolution: FIXED Assigned To: base-system@gentoo.org Reported By: art-gt@broomstick.com
Component: Eclasses and Profiles
URL: 
Summary: epatch should skip -p0 for patchs with absolute paths in them - fix made multiple patches fail
Keywords:  
Status Whiteboard: 
Opened: 2008-09-14 23:05 0000
Description:   Opened: 2008-09-14 23:05 0000
The patch 42_all_012_check_ldrunpath_length.patch for
sys-devel/binutils-2.18-r3 (and probably some other versions) references a user
home directory on lines 27 and 28:

@DPATCH@
diff -urNad
/home/james/debian/packages/binutils/new/binutils-2.15/ld/emultempl/elf32.em
binutils-2.15/ld/emultempl/elf32.em
---
/home/james/debian/packages/binutils/new/binutils-2.15/ld/emultempl/elf32.em2004-05-21
23:12:58.000000000 +0100
+++ binutils-2.15/ld/emultempl/elf32.em 2004-05-21 23:12:59.000000000 +0100

On systems with /home being on autofs, building binutils then causes a mount
request and a system error log entry unless one by sheer luck happens to have a
user named "james".

------- Comment #1 From SpanKY 2008-09-20 18:55:13 0000 -------
this isnt only a problem with binutils, so ive implemented a check in epatch:
http://sources.gentoo.org/eclass/eutils.eclass?r1=1.304&r2=1.305

------- Comment #2 From SpanKY 2008-09-20 19:00:36 0000 -------
actually even better, skip -p0 for such patches ... no need for people to
change their patches then

------- Comment #3 From SpanKY 2008-09-20 19:03:30 0000 -------
fixed here:
http://sources.gentoo.org/eclass/eutils.eclass?r1=1.306&r2=1.307

------- Comment #4 From Andrew John Hughes 2008-09-25 20:35:45 0000 -------
This fix seems to have broken a number of working patches where both paths
aren't absolute.  I saw this happen in the kde ebuilds and it also made
icedtea6-1.2 fail, taking me ages to figure out why.

Please fix.

------- Comment #5 From Vlastimil Babka (Caster) 2008-09-25 21:18:55 0000 -------
Reopening.

------- Comment #6 From Serkan Kaba 2008-09-26 20:26:53 0000 -------
Can we make this a QA warning or something for a while?

------- Comment #7 From SpanKY 2008-10-26 06:04:27 0000 -------
post real information rather than vague "this breaks things".  i have yet to
see this change break any real code.

------- Comment #8 From Serkan Kaba 2008-10-26 06:44:05 0000 -------
(In reply to comment #7)
> post real information rather than vague "this breaks things".  i have yet to
> see this change break any real code.
> 

I provided enough information in -dev post. Please see
http://archives.gentoo.org/gentoo-dev/msg_777d416bb082a45b0e4848d8db5bfec8.xml
And there are a few more that I fixed that I can't track right now.

------- Comment #9 From SpanKY 2008-11-20 16:17:16 0000 -------
three whole bugs ?  and they've been fixed ?  i still see no grounds for
revert.

------- Comment #10 From Petteri Räty 2008-11-21 12:29:24 0000 -------
(In reply to comment #9)
> three whole bugs ?  and they've been fixed ?  i still see no grounds for
> revert.
> 

Yeah not any more as Flameeyes fixed the broken patches in the tree. 

betelgeuse@aria ~/irclogs/freenode $ tail -n 10000 \#gentoo-commits.log | grep
flameeyes -A 3 | grep "Fix patch with absolute paths" | wc -l
94

I think this should have easily qualified as something to revert before the
patches were fixed.

------- Comment #11 From SpanKY 2008-12-07 08:58:14 0000 -------
yes, that number indicates the change should have been temporary.  such info
should have been posted with the original request rather than what was.  but
the real thanks goes to the guy who did the real work: Diego.

------- Comment #12 From Arthur Hagen 2008-12-07 18:26:00 0000 -------
Indeed, thanks to both flameeyes and vapier.

However, one minor niggle:  The description says it's only a problem if sandbox
is disabled.  That's not strictly true.  The original report in this bug occurs
with sandbox enabled -- autofs knows nothing about the sandbox, and will
happily mount (and hopefully fail).