I just emerged x11-base/xorg-server-1.1.0. In postinst it printed this error message: !!! Error: Invalid usage of set action. exiting. The "!!! Error: " part is colored red. This seems to be coming from the line that reads eselect opengl set ${OLD_IMPLEM} in switch_opengl_implem which is called from pkg_postinst. Presumably, whatever this line was trying to do has not been done and my system is in some minor way borked as a result. Suggestions? Fix? Apparently it is no longer possible to follow the bugzilla instructions to include the output of "emerge --info" in this box, because I always now get "Comment Too Long". So I will attach that information separately.
Created attachment 88372 [details] Output of "emerge --info" on my system.
Heya jforman, looks like you need to increase the max comment length a bit -- this guy's emerge --info is too long.
What's the output of `eselect opengl list`?
(In reply to comment #3) > What's the output of `eselect opengl list`? The current output is (indented by two spaces): Available OpenGL implementations: [1] xfree [2] xorg-x11 * I haven't emerged anything since emerging xorg-server-1.1.0, so things should still be the same as they were when I got the error message. The "xfree" entry is probably nonsense that should have been cleaned up by the switch to xorg 17 months ago. Maybe the correct fixup was prevented when profiles/updates/1Q-2005 renamed my installed x11-base/xfree-4.3.99.902-r2 package to x11-base/xorg-x11-4.3.99.902-r2? Suggestions?
OK, now it's clear what the problem was. It tried to restore you to your old configuration, "xfree," after emerging. But that's an invalid setting, so it died. What's in /usr/lib/opengl/xfree?
(In reply to comment #5) > OK, now it's clear what the problem was. > > It tried to restore you to your old configuration, "xfree," after emerging. A good hypothesis. I don't think we can be completely certain that "xfree" was the old setting, as the error messages didn't include enough information. > But that's an invalid setting, so it died. It's certainly a setting that should not be there anymore. I don't think that is enough to be completely certain why it died, although I agree it is a good hypothesis. > What's in /usr/lib/opengl/xfree? If I run "find /usr/lib/opengl/xfree -ls", I get this output: 65743 4 drwxr-xr-x 3 root root 4096 Jan 27 2005 /usr/lib/opengl/xfree 65753 4 drwxr-xr-x 2 root root 4096 Jan 27 2005 /usr/lib/opengl/xfree/include 82647 260 -r--r--r-- 1 root root 258464 Feb 17 2004 /usr/lib/opengl/xfree/include/glext.h
What owns /usr/lib/opengl/xfree/include/glext.h? qfile, equery belongs, something like that can help you.
(In reply to comment #7) > What owns /usr/lib/opengl/xfree/include/glext.h? qfile, equery belongs, > something like that can help you. The command "grep /usr/lib/opengl/xfree /var/db/pkg/*/*/CONTENTS" reveals that no packages own this file. I now remember that the old opengl-update ebuilds used to print instructions saying to run "mv /usr/X11R6/include/GL/glext.h /usr/lib/opengl/xfree/include", and I am sure I followed these instructions at some point. You can see an example of this in pkg_setup at: http://www.gentoo.org/cgi-bin/viewcvs.cgi/x11-base/opengl-update/Attic/opengl-update-1.8-r1.ebuild?rev=HEAD&content-type=text/vnd.viewcvs-markup
I think the best fix for this will be to make sure eselect-opengl does proper sanity checking to allow a given implementation to be active. For now, just run `rm -rf /usr/lib/opengl/xfree` and `eselect opengl set xorg-x11` and you will be fine.
*** Bug 135579 has been marked as a duplicate of this bug. ***
I'm the reporter of the dup #135579. The problem for me is: aconite opengl # pwd /usr/lib/opengl aconite opengl # ls -al total 176 drwxr-xr-x 4 root root 4096 Apr 13 21:13 . drwxr-xr-x 205 root root 163840 Jun 4 18:01 .. drwxr-xr-x 3 root root 4096 Aug 23 2004 global lrwxrwxrwx 1 root root 16 Mar 24 2005 opengl -> /usr/lib//opengl drwxr-xr-x 5 root root 4096 Apr 13 21:25 xorg-x11 aconite opengl # I'll just delete the bogus symlink (I have these sorts of symlinks all over my system: must've been a bug in portage or something at some point.)
(In reply to comment #9) > I think the best fix for this will be to make sure eselect-opengl > does proper sanity checking to allow a given implementation to be > active. > > For now, just run `rm -rf /usr/lib/opengl/xfree` and `eselect opengl > set xorg-x11` and you will be fine. I did this a while ago and got no error at the time. Today I emerged x11-base/xorg-server-1.1.0-r1 and got the exact same error message again ("Error: Invalid usage of set action. exiting."). The explanation in comment 5 can not explain the error this time (and therefore was probably not the explanation for the previous occurrence), because the directory /usr/lib/opengl/xfree no longer exists on my system. The current output of "eselect opengl list" on my system is: Available OpenGL implementations: [1] xorg-x11 * Suggestions?
(In reply to comment #12) > Today I emerged x11-base/xorg-server-1.1.0-r1 and got the exact same > error message again ("Error: Invalid usage of set action. exiting."). > The explanation in comment 5 can not explain the error this time (and > therefore was probably not the explanation for the previous > occurrence), because the directory /usr/lib/opengl/xfree no longer > exists on my system. > > The current output of "eselect opengl list" on my system is: > > Available OpenGL implementations: > [1] xorg-x11 * Same thing here. Only xorg-x11 listed. HOWEVER, I /believe/ I understand the problem, if the time I've been spending hanging out on the portage-devel list has been doing me any good, anyway... =8^) The root problem is portage (perhaps new to 2.1?): I believe the issue is the one Brian Harring keeps harping on re paludis and the like, due to hard earned experience with portage and savior (the old name, forgot what it's called now, but his rewrite) -- properly saving and restoring the environment between ebuild stages. You may wish to confer with the portage folks on the details. Problem as manifest in xorg-server: If I'm not mistaken, what's happening is this. In pkg_setup, you do OLD_IMPLEM="$(eselect opengl show)" Great. That gets set, but it's only set for pkg_setup. Portage isn't recreating the environment correctly for further ebuild stages, and ${OLD_IMPLEM} is therefore unset when the value is used in pkg_postinst -> switch_opengl_implem as eselect opengl set ${OLD_IMPLEM} The result is that the call attempts to set a null implementation, which of course results in the error seen above. Effects: There will be zero effect for those who already had xorg-x11 set as their opengl implementation, because that's what the ebuild temporarily set it to, so not resetting it changes nothing. For those who have something else set, however, it will stay reset to xorg-x11 until they change it manually once again. Suggested fix (untested, based on my definitely novice knowledge of ebuilds an portage, may eat your babies and cause your computer to start spamming Nigerian 419 emails, etc =8^) : Use a file in ${T} containing the old setting. Something like this in pkg_setup: eselect opengl show > ${T}/user.opengl ... and this in switch_opengl_implem: eselect opengl set < ${T}/user.opengl Hope that's all it takes! =8^) Duncan
*** Bug 156756 has been marked as a duplicate of this bug. ***
I just tested this out with xorg-server-1.2.0-r1 and portage 2.1.2.2. It changes my implementation from nvidia to xorg-x11 at the start of compilation and restores it at the end. The problem seems to be fixed.
