I have own TMPDIR setting because I share it with ie bitbake work dir for building. Its set for portage to PORTAGE_TMPDIR=/tmp/tmpwork then WORKDIR looks like WORKDIR: /tmp/tmpwork/portage/dev-ruby/i18n-0.3.2/work old expresion for homedir ${WORKDIR/work/homedir} * old: /tmp/tmphomedir/portage/dev-ruby/i18n-0.3.2/work new expresion for homedir ${WORKDIR/\/work//homedir} works for me: * new: /tmp/tmpwork/portage/dev-ruby/i18n-0.3.2/homedir To make it a bit more safer (bash replace seems to not support $ for checking end of string) I used HOMEDIR=`echo ${WORKDIR} | sed 's#/work$#/homedir#g'` in both src_prepare and src_test, because I got QA notice if it is defined in global section: jama ~ # ebuild /usr/portage/dev-ruby/i18n/i18n-0.3.2.ebuild digest * QA Notice: 'sed' called in global scope: dev-ruby/i18n-0.3.2 If having word "work" in PORTAGE_TMPDIR is considered unsupported then please ignore&close this bug :). Thanks Reproducible: Always
this also causes paludis the fail: * Running source copy phase for ruby18 ... chmod: cannot access `/var/tmp/paludis/dev-ruby-i18n-0.3.2/homedir': No such file or directory !!! ERROR in dev-ruby/i18n-0.3.2::gentoo: !!! In src_prepare at line 4114 !!! Failed to fix permissions on home
Actually the permission mangling is just temporary so it should go away soonish.
I confirm that brokes compilation with paludis completely. And as this is pulled by activesupport, you cant really install rails from gentoo-86 on system you use paludis...
*** Bug 308547 has been marked as a duplicate of this bug. ***
Is there any reason why this doesn't just use "${HOME}" (with the quotes)?
Also confirm failing with paludis. Is it difficult to fix? Does it depend on ebuild or on source code?
Created attachment 239793 [details, diff] Fixes paludis installation Originally I thought I shouldn't publish this ugly patch, which isn't even tested but in one environment that runs Redmine. And I don't know how it behaves with portage, it is written for Paludis.
Created attachment 239869 [details, diff] dev-ruby-HOME-fix.patch Patch to apply comment #6 suggestion to all dev-ruby ebuilds that use this pattern
Comment on attachment 239869 [details, diff] dev-ruby-HOME-fix.patch If userpriv is not set ${HOME} might touch outside the sandbox.
(In reply to comment #10) > (From update of attachment 239869 [details, diff]) > If userpriv is not set ${HOME} might touch outside the sandbox. HOME is an environment variable set by your package manager to the desired value in a directory in the sandbox. The actual home directories of the portage or root users are irrelevant. Hence so is userpriv.
Also confirm this with dev-ruby/i18n-0.3.7 Thanks for the patches, Samu, but why are they obsoletted?
Comment on attachment 239869 [details, diff] dev-ruby-HOME-fix.patch As Bo said - the stated behaviour is required by PMS, and zmedico confirms that Portage does indeed do it. And if that weren't the case, RubyInline would itself cause a violation when it tried to put its own files in $HOME
(In reply to comment #12) > Also confirm this with dev-ruby/i18n-0.3.7 > > Thanks for the patches, Samu, but why are they obsoletted? > If this fix (and problem) doesn't affect Portage, please say so and I'll put it to Paludis, or as another bug if it still is ebuild problem...
Fixed.
