I've global umask 077 and this maybe is the source of the problem. The installed openoffice has ownership root.root with no read//execute for group and other for the paths below /usr/lib64/openoffice/share/uno_packages/cache. This is the location of some i18ne stuff. You'll get an well documented error like http://www.oooforum.org/forum/viewtopic.phtml?t=70331&highlight=determined+language This only applies at the first startup of the new version on a given .ooo3 directory. Reproducible: Always Steps to Reproduce: 1. remove ~/.ooo3 2. start oowriter Actual Results: Startup screen, and a dialog box with The application cannot be started. The user interface language cannot be determined Expected Results: openoffice window
sry, quick'n'dirty work-around is as root chmod -R a+r+X /usr/lib64/openoffice/share/uno_packages/cache
The problem is indeed umask 077, for some time i had umask 007 and several Programs/libraries installed without other read/execute.
I think that the portage tools and layman were a little ignorant towards the umask situation. Umask 022 in the root shell is a security hole and should be avoided. I would prefer some umask awareness in the gentoo scripts and ebuilds.
(In reply to comment #3) > I think that the portage tools and layman were a little ignorant towards the > umask situation. Umask 022 in the root shell is a security hole and should be > avoided. I would prefer some umask awareness in the gentoo scripts and ebuilds. > Wait, what? You mean that you want portage to detect the *users* environment setting for umask? That is not possible or smart. If anything it should be openoffice that is checking ~/.ooo/ permissions and adjusting as needed. Anyway, if you can define the problem or solution abit more we could gladly evaluate it some more. I'll leave this bug open but it will probably get closed within a week or less. thx for contributing.
Hi, no, I meant umask situation during installation. The ebuilds do not touch umask or the permissions of the installed files. So, if you install some software as root with umask 077, you'll create the installed files in /usr ... as root.root without read access for others. It would be nice to have a ebuild/emerge that set the proccess' umask explicit to 022 (python: os.umask), to reproduce the installation situation with gentoos default 022 umask. That would be much better than chmod -R a+rX ... in every ebuild. This is not a openoffice specific bug/feature, should I suggest this at the mailing list? Michael
portage should already be isolating the ebuild runtime from the user's umask settings. no matter what the user's or root's umask settings are, portage should be resetting this. it has been too for longer than this bug has been around. ebuild.sh has near its top: > # if no perms are specified, dirs/files will have decent defaults > # (not secretive, but not stupid) > umask 022 everyone involved in this report have prob moved on, and we don't seem to have any new reports since. would be nice to have a repro case before we investigate further.
*** Bug 884947 has been marked as a duplicate of this bug. ***
We seem to have had a case of this in bug 884947.
