[I know that the headers are wrong; sorry for that] > I try the same on a relatively young gentoo server I'm managing and > * dev-python/snakeoil > Available versions: <yellow>~0.3.6.4 ~0.3.6.5 ~0.3.7</yellow> [...] > It's unkeyworded, however
Did you verify with portage that it is unkeyworded? (There could be many other reasons why it is not). In other words: Does emerge -a =dev-python/snakeoil-0.3.7 really not complain? As I understand, you already compared the output of eix --dump. I suppose you verified that this output was created in the same environment (i.e. with the same user and the same environment variables) in which you call eix later on? If this is the case, already most causes of different eix configuration are excluded (e.g. LOCAL_PORTAGE_CONFIG should be "true" on both machines; just to make sure, you can also try with eix --print LOCAL_PORTAGE_CONFIG). Please also verify with "type -a eix" that you do not use by accident some wrapper (shell function, alias, or script) which could set some eix command line options. The only difference I could still imagine is that you have set an environment variable which portage ignores but eix does not. For instance, does eix --print ARCH (and similarly eix --print ACCEPT_KEYWORDS) show the correct architecture (x86 or amd64) which matches with the entry in your package.keywords file? Does removing the ~x86/~amd64 in that file change the output? Other possible causes: Perhaps some file, most probably package.keywords file cannot be opened for some reason by eix. Therefore the simple question: Do you run eix with root permissions as you probably do with portage? And just to be sure: Does "strace eix -e snakeoil" show you that package.keywords was succesfully opened by eix? If nothing gives a hint, I suggest that you open an eix bug. Regards Martin Väth
