| Summary: | dev-ruby/i18n-0.3.2 setting homedir permissions doesn't work for custom TMPDIR | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Martin Jansa <Martin.Jansa> |
| Component: | [OLD] Development | Assignee: | Gentoo Ruby Team <ruby> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | bugs_gentoo_org.korobkov, ec5983, levertond, uzytkownik2 |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
Fixes paludis installation
dev-ruby-HOME-fix.patch |
||
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. 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 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. |
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