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".
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
actually even better, skip -p0 for such patches ... no need for people to change their patches then
fixed here: http://sources.gentoo.org/eclass/eutils.eclass?r1=1.306&r2=1.307
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.
Reopening.
Can we make this a QA warning or something for a while?
post real information rather than vague "this breaks things". i have yet to see this change break any real code.
(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.
three whole bugs ? and they've been fixed ? i still see no grounds for revert.
(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.
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.
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).
