Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 173571 - app-admin/eselect-opengl-1.0.6-r1: "Unrecognized option: (none)" in pkg_postinst
Summary: app-admin/eselect-opengl-1.0.6-r1: "Unrecognized option: (none)" in pkg_postinst
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: x86 Linux
: High normal (vote)
Assignee: X11 External Driver Maintainers
URL:
Whiteboard:
Keywords: InVCS
: 242112 (view as bug list)
Depends on:
Blocks:
 
Reported: 2007-04-06 14:45 UTC by Celso Fernandes (icezimm)
Modified: 2009-06-23 11:42 UTC (History)
7 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Celso Fernandes (icezimm) 2007-04-06 14:45:01 UTC
after emerging x11-xorg, everything goes fine till come to eselect, than after source has been compiled, I got a Unrecognized option: (none), eselect was killed but the merge continues without detect the problem

when I try to re-emerge, the error continues.

Reproducible: Always

Steps to Reproduce:
1. emerge app-admin/eselect-opengl
2.
3.

Actual Results:  
>>> Merging app-admin/eselect-opengl-1.0.5 to /
--- /usr/
--- /usr/share/
--- /usr/share/eselect/
--- /usr/share/eselect/modules/
>>> /usr/share/eselect/modules/opengl.eselect
--- /usr/lib/
>>> /usr/lib/opengl/
>>> /usr/lib/opengl/global/
>>> /usr/lib/opengl/global/include/
>>> /usr/lib/opengl/global/include/glxext.h
>>> /usr/lib/opengl/global/include/glext.h
!!! Error: Unrecognized option: (none)
/usr/portage/app-admin/eselect-opengl/eselect-opengl-1.0.5.ebuild: line 65: 27846 Killed                  eselect opengl set "${impl}"
>>> Regenerating /etc/ld.so.cache...
>>> app-admin/eselect-opengl-1.0.5 merged.

>>> No packages selected for removal by clean
Comment 1 Michael 2007-04-07 08:48:30 UTC
Same problem here:
eselect opengl set xorg-x11 lead to "Killed" message.

glxinfo says that Direct Rendering works but everything is horrible slow.
Comment 2 Sascha G. 2007-04-09 18:48:40 UTC
I do not know whether it is the same or a different problem, but I have observed the following during the merge of xorg-server in addition to the other issue mentioned in this bug:

[...]
>>> Regenerating /etc/ld.so.cache...
>>> Original instance of package unmerged safely.

Switching to xorg-x11 OpenGL interface.../usr/share/eselect//libs/core.bash: line 119: /usr/bin/sed: No such file or directory
!!! Error: Failed to create //usr//lib/libGL.la
/usr/portage/x11-base/xorg-server/xorg-server-1.2.0-r3.ebuild: line 495: 26585 Killed
eselect opengl set ${OLD_IMPLEM}
[...]

In /usr/share/eselect//libs/core.bash it says:
# GNU sed wrapper (real path to GNU sed determined by configure)
sed() {
    /usr/bin/sed "$@"
}

So sed is not being correctly located.
Comment 3 Sascha G. 2007-04-09 18:55:00 UTC
Please forget my last comment. I emerged eselect (I thought it belonged to eselect-opengl...) again after my last comment, now it points to /bin/sed. Oh well.
The issue with eselect-opengl still stands, though.
Comment 4 Gary HUnt 2007-04-23 00:20:38 UTC
I had 2 versions of sed. fixed that. re emerged
eselect which this time found the newest sed, however the ( switching opengl interface..... Killed. ) still remains.

When I run eselect opengl set <interface>, it looks as though eselect has terminated... with the Killed response. However if I check the running processes, it shows that eselect is still running and creates up to 4 child processes; 3 eselect and 1 pgrep. Eselect then kills the child processes then creates new ones. This cycle continues indefinately until I manually kill the parent eselect process.

Gary
 
Comment 5 Peter Avramucz 2007-04-24 18:18:37 UTC
Same here...
~x86
Comment 6 Antek Grzymała (antoszka) 2007-09-11 19:33:13 UTC
Same here *STILL*. x86.
Comment 7 Antek Grzymała (antoszka) 2007-09-13 19:16:15 UTC
Looks like this bug is caused by a rogue file in /etc/env.d/, check your files for anything not keeping the ENV=VALUE format.
Comment 8 Gary HUnt 2007-09-15 01:15:21 UTC
(In reply to comment #7)
> Looks like this bug is caused by a rogue file in /etc/env.d/, check your files
> for anything not keeping the ENV=VALUE format.
> 

I think that fixed it. thanks!
Comment 9 alfredo perez 2007-09-26 15:16:57 UTC
I am getting very similar error

!!! Error: Unrecognized option: (none)
/usr/portage/app-admin/eselect-opengl/eselect-opengl-1.0.5.ebuild: line 65: 23761 Killed 

I checked files in /etc/env.d and they all seem with ENV=VALUE format

should I open a new bug for this issue?
Comment 10 Neil Cathey 2007-10-26 02:13:25 UTC
I don't know if anyone's still having a problem here, since there's been no activity for a while, but I recently hit this bug on a new install.  Here's how I fixed it (or, if you don't want to read all of this, re-emerging sys-apps/file fixed it for me):

#eselect opengl set nvidia
Switching to nvidia OpenGL interface...Killed

I looked at /usr/share/eselect/modules/opengl.eselect.  I put in dummy 'echo' commands to find out where it was failing, and discovered it was line 232:

do_action env update &> /dev/null

I took out the redirect to /dev/null, and got some additional output:

#eselect opengl set nvidia
Switching to nvidia OpenGL interface...Skipping non-text file /etc/env.d/00basic.
Skipping non-text file {lists all files in /etc/env.d}.
Killed

I figured out that "do_action env" executes in /usr/share/eselect/modules/env.eselect which contains this line:

mime=$(file -i ${envfile} | cut -d ' ' -f 2 | sed -e 's/;$//')

If I run

#file -i /etc/env.d/00basic | cut -d ' ' -f 2 | sed -e 's/;$//'
ERROR:

and "ERROR:" does not match MIME_WHITELIST.  The same command returns "text/plain" on a working box.

#file -i /etc/env.d/00basic
/etc/env.d/00basic: ERROR: text/plain; charset=us-ascii

The other box returns the same line, minus the "ERROR:".  So, I re-emerged sys-apps/file, and that fixed it.  I don't know why file was having a problem, but at least it doesn't throw out the extra "ERROR:".  And eselect opengl is now happy.

After a little further investigation, I discovered something odd.  When sys-apps/file is compiled or recompiled in a chroot, it always adds in the extra "ERROR:" that throws off eselect opengl.  Once the chroot is moved to the destination machine (I was setting up Gentoo in a chroot for an older, slower machine), file still throws out "ERROR:".  When sys-apps/file is compiled again on the destination machine, file is happy.  I don't know if I had something funky going on with my chroot, or if there's a bug in sys-apps/file, but it was definitely repeatable for me.  YMMV.
Comment 11 Jeremy Huddleston (RETIRED) gentoo-dev 2007-10-27 22:53:35 UTC
Based on comment #10, reassigning...
Comment 12 Matthias B. 2008-01-11 17:40:29 UTC
I am seeing this bug but here it has nothing to do with file. AFAICT the matter is as follows:

1. eselect-opengl-1.0.6-r1.ebuild has the following in pkg_postinst

        local impl="$(eselect opengl show)"
        if [[ -n "${impl}" ]] ; then
                eselect opengl set "${impl}"
        fi

2. "eselect opengl show" tries to evaluate /etc/env.d/03opengl. I don't know which package is supposed to provide that file (Doesn't Gentoo have anything like the Debian online package database that could answer me that question?) but I don't have it. And I'm quite certain that's as it's supposed to be. I haven't installed Mesa or anything else OpenGL, yet, so why should I have /etc/env.d/03opengl?.

3. `eselect opengl show` returns "(none)"

4. The pkg_postinst will consequently call

   eselect opengl set '(none)'

and this causes the error message.

5. My conclusion is that the pkg_postinst() of eselect-opengl-1.0.6-r1.ebuild is buggy. It seems as if the 

if [[ -n "${impl}" ]] ; then

test is supposed to prevent the issuing of the eselect opengl set command in the case that no opengl has been installed. Apparently it expects that in the case of no opengl present `eselect opengl show` will return the empty string. I don't know, maybe it did in an earlier version. However, now `eselect opengl show` returns "(none)" if no opengl is installed. So the pkg_postinst should read

        local impl="$(eselect opengl show)"
        if [[ -n "${impl}" ]] ; then
           if [[ "${impl}" != '(none)' ]]; then
                eselect opengl set "${impl}"
           fi
        fi

to account for the "(none)" return.
In any case, the error message seems harmless, because if my assumption is correct, then the eselect opengl set should not have been called in the first place, so it doesn't matter if it doesn't work.

p.s.: I suggest to change the summary to 
"eselect-opengl: Unrecognized option: (none) during emerge"
This is more descriptive of the bug. With the current summary, the issue is hard to find and someone with the same problem might not find his way here.
Comment 13 Ulrich Müller gentoo-dev 2009-04-17 09:14:44 UTC
(In reply to comment #12)
Your analysis of the problem seems correct.

Reassigning to x11-drivers, since the problem is in the app-admin/eselect-opengl ebuild. Matthias' bugfix from comment #12 looks good to me.


(In reply to comment #10)
> #file -i /etc/env.d/00basic
> /etc/env.d/00basic: ERROR: text/plain; charset=us-ascii

This is a different problem. Please file a new bug report if this is still an issue. (I'd say something is wrong with your chroot or your "file" command.)
Comment 14 Tomáš Chvátal (RETIRED) gentoo-dev 2009-06-23 11:40:20 UTC
Ebuild fixed.
Thanks for investigation and the fix.
Comment 15 Tomáš Chvátal (RETIRED) gentoo-dev 2009-06-23 11:42:22 UTC
*** Bug 242112 has been marked as a duplicate of this bug. ***