237667 2008-09-14 23:05 0000 epatch should skip -p0 for patchs with absolute paths in them - fix made multiple patches fail 2008-12-07 18:26:00 0000 1 1 1 Unclassified Gentoo Linux Eclasses and Profiles 2008.0 All Linux RESOLVED FIXED P2 normal --- 238346 238685 238713 1 art-gt@broomstick.com base-system@gentoo.org flameeyes@gentoo.org java@gentoo.org jer@gentoo.org art-gt@broomstick.com 2008-09-14 23:05:29 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". vapier@gentoo.org 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 vapier@gentoo.org 2008-09-20 19:00:36 0000 actually even better, skip -p0 for such patches ... no need for people to change their patches then vapier@gentoo.org 2008-09-20 19:03:30 0000 fixed here: http://sources.gentoo.org/eclass/eutils.eclass?r1=1.306&r2=1.307 gnu_andrew@member.fsf.org 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. caster@gentoo.org 2008-09-25 21:18:55 0000 Reopening. serkan@gentoo.org 2008-09-26 20:26:53 0000 Can we make this a QA warning or something for a while? vapier@gentoo.org 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. serkan@gentoo.org 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. vapier@gentoo.org 2008-11-20 16:17:16 0000 three whole bugs ? and they've been fixed ? i still see no grounds for revert. betelgeuse@gentoo.org 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. vapier@gentoo.org 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. art-gt@broomstick.com 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).