I'm using the new cascading profiles: # ls -l /etc/make.profile lrwxrwxrwx 1 root root 48 Apr 6 03:31 /etc/make.profile -> ../usr/portage/profiles/default-linux/x86/2004.0 euse's search for package descriptions needs to be massaged to work with cascading profiles. Here's the error: # euse -i lcms EUSE exiting with following errors: requires read permissions for /etc/make.profile/../use.desc. requires read permissions for /etc/make.profile/../use.local.desc. Reproducible: Always Steps to Reproduce: 1. Symlink /etc/make.profile to a cascading profile 2. Execute euse (-i, -c, -d, or -e) Actual Results: EUSE exiting with following errors: requires read permissions for /etc/make.profile/../use.desc. requires read permissions for /etc/make.profile/../use.local.desc. Expected Results: euse should locate the use.desc and use.local.desc files and succeed.
Oops..BTW, I'm using app-portage/gentoolkit-0.2.0_pre8. Should have included that info. Sorry. *blush*
I also have this problem, it is caused by two line in the euse perlscript our $FUse_desc = "/etc/make.profile/../use.desc"; our $FUse_local = "/etc/make.profile/../use.local.desc"; For a normal profile, this simply looks in /usr/prortage/profile/ for use description files, but if you use a cascaded profile, the path /etc/make.profile links to, can be unexpectedly deep and euse won't find the file by simply going one step back in the directory tree. I do not know if there are plan to give every cascaded profile own use.desc files to stack them, too. If not the solution is imho very simple, because in the past, with flat profiles, euse always got its files from /usr/portage/profile/, just get it from there, without traversal or any fancy stuff, just the get_portdir function from ufed schould be built into euse, in case someone changes it in /etc/make.conf
I just encountered this when I changed to the new cascading profile for hardened. where it points to: ln -s ../usr/portage/profiles/hardened/x86 make.profile And recieve these errors: ignite root # euse -i tcpd EUSE exiting with following errors: requires read permissions for /etc/make.profile/../use.desc. requires read permissions for /etc/make.profile/../use.local.desc. Someone told me that karltk really works on this package, but according to his away on dev.g.o, he won't be around much this month. More and more cascading profiles will be appearing, so, there's going to be more need for this fix soon! I'd do it, but I'm swamped as it is!
wanted to say, also hit to this bug. lrwxrwxrwx 1 root root 48 Sep 19 22:33 /etc/make.profile -> ../usr/portage/profiles/default-linux/x86/2004.2/
Created attachment 40123 [details, diff] euse.patch here's the way i resolved the issue.
You want the perl equiv of this: PORTAGE_TREE="$(portageq portdir)/profiles"
Looking at it, euse is going to become quite difficult to manage due to cascades. Would probably be best to acquire the USE flags from 'portageq env USE'. Just remember that changing environment vars that portage uses will cause changes to the results... Which could be used to determine the final results of a change. There is no good interface to masked variables though. If someone wants to outline a set of 'required' and 'desireable' attributes to look up in an API of some sort, it'd be cool if you'd assign a bug to dev-portage@gentoo.org in the Portage Development project with all the info.
btw: ufed has also probs w/ the profiles ... <snip> couldn't open use.defaults at /usr/sbin/ufed line 513. </snip>
Created attachment 42000 [details] replacement written in bash Ok, here is a new euse written in bash that fixes this problem (and probably a few others). Please test and see if I've forgotten something important.
Looks good from what I can tell ; all the options seem to work as intended. Has my thumbs up.
Just wanted to say I have the problem too. Changing to a non-stacked profile solved the problem (default-x86-2004.2 in my situation). Please don't remove euse unless some other adequate solution comes up. It's very handy to have around. It's the "vi /etc/sudoers" vs "visudo" discussion all over again. :)
*** Bug 70571 has been marked as a duplicate of this bug. ***
*** Bug 71493 has been marked as a duplicate of this bug. ***
*** Bug 71722 has been marked as a duplicate of this bug. ***
*** Bug 72223 has been marked as a duplicate of this bug. ***
Has this new version been keyworded or put into cvs yet? I'd like to test it out in a packaged form or at least get it in there.
*** Bug 72852 has been marked as a duplicate of this bug. ***
in 0.2.0_rc1
