eix showing question mark in package status [SOLVED]

[Lu Tze]

I have a problem with eix which started a while ago but I didn't pay attention to it until it became a nuisance. Eix shows a question mark for the status of many packages, both in portage and in overlays:

[thumper]

I've never seen eix do that, do you use eix-sync?

[Lu Tze]

I usually run emerge --sync and eix-update -a /var/lib/layman/science manually because eix-sync doesn't pick up the fact that I have an overlay (this is a separate issue which I have been ignoring). In saying that, I have tried running eix-sync as well, but the result is the same.
_________________
"My brother sent me a postcard the other day with this big satellite photo of the entire Earth on it. On the back it said: "Wish you were here"" - Steven Wright

[Lu Tze]

It seems that eix is marking testing versions (~) with [?], for example:

[mv]

You have probably misconfigured portage: The unstable versions you have installed are not marked unstable in your package.accept_keywords. That's why a fresh emerge of the package would install a lower version. Have you perhaps done a stupid thing like installing with ACCEPT_KEYWORDS='~amd64' being set temporarily?
Similarly, if your /etc/portage/repos.conf is set up correctly (and you do not override it with PORTDIR_OVERLAY), eix will automatically see the overlay; do not use -a.

[Lu Tze]

Thank you for your reply, mv.

Unstable packages are inserted in package.accept_keywords, e.g., I have dev-qt/qt-creator ~amd64 in /etc/portage/package.accept_keywords/x86. I never install anything with temporary ACCEPT_KEYWORDS='~amd64'.

This is my repos.conf/gentoo.conf:

[Lu Tze]

Ahem, my own paranoia seems to have played a bad trick on me again.

mv's comment pointed me in the right direction. It turns out that the directories package.accept_keywords and repos.conf (as well as some others in /etc/portage) had permissions set to 700, which is probably the result of creating them manually when I migrated my package.keywords to package.accept_keywords/x86 and from make.conf entries to separate files under repos.conf. The thing is that I have set the default umask for new directories for root to 077, so these directories (and everything under them!) were created with permissions 700. I changed the permissions to 755 and now eix works as expected:

[Tony0945]

[A.S. Pushkin]

I've run into this [?] and wondered about it, but still do not understand. In fact this has raised more questions.

Do we do an emerge --sync or eix-sync to update portage?

TIA
_________________
ASPushkin

"In a time of universal deceit - telling the truth is a revolutionary act." -- George Orwell

[qsmodo]

[mv]

[cboldt]

FWIW, my systems connect the `emerge --sync` and `eix-update` steps, but do not use eix-sync to update the portage tree.

The two steps are linked at /etc/portage/repo.postsync.d/egencache

I don't recall where this script originated, most of it isn't mine. It's been changed so as to enable the `eix-diff` function, and to quiet the output during operation of eix-update.

[mv]

[cboldt]

Very good point, and I should have been more thoughtful in response.

I agree repos.postsync.d is not the right hook, and that postsync.d is correct.

Either one just happens to work in my circumstance which has no auto update of ANY repo beyond "gentoo." The stage 3 tarball includes the repos.postsync.d directory, and with the parameters being passed, this (incorrect) location has more flexibility in the long run

Funny thing is, last week I had a mix (four machines here, an extra in use as I migrate a LAN of three from x86 to amd64) of executable script, most in postsync.d and one in repos.postsync.d. I decided to make them all common/the same, sticking with the folders in the stage 3 tarball.