I'm using eix-0.15.6. When I eix-synced this morning, it showed every package as masked. Reproducible: Didn't try Steps to Reproduce: 1. eix-sync Actual Results: something like: [<] == app-admin/apache-tools ((~)2.2.11!t -> **2.2.8 **2.2.9 **2.2.10 **2.2.11): [D] == app-admin/emacs-updater (1.3@01/21/09; (~)1.3 -> **1.3): [D] == app-admin/eselect (1.0.11-r2@04/13/09; (~)1.0.11-r2 -> **1.0.10 **1.0.11-r2): [<] == app-admin/eselect-blas ((~)0.1 -> **0.1): Obviously, this is related to the new masking policy explained in the news 2009-03-29-eapi-prefix-deprecation.
I cannot see how this should be related to EAPI=prefix deprecation: eix ignores EAPI completely (except of indirectly for the eapi-suffixed ebuilds or when calling portage to execute the ebuild). There is mentioning of "prefix keywords". Are these not stored in KEYWORDS (in the ebuild or metadata/cache/* - with "eix -l" you can see what eix found) and ARCH (in your profile)?
Well, for example, ipython-0.9.1 % eix -l ipython: [D] dev-python/ipython Available versions: ** 0.8.4-r1 ** 0.9.1 Installed versions: 0.9.1(14:10:24 04/13/09)(gnuplot readline -doc -emacs -examples -smp -test -wxwindows) % grep KEYWORDS ipython-0.9.1.ebuild KEYWORDS="~amd64-linux ~x86-linux ~x86-macos" (I'm on x86-macos) Does the example above show the metadata/cache/ is broken? If it is the case, please change the summary.
(In reply to comment #2) > Does the example above show the metadata/cache/ is broken? It seems so, but just to be sure: Does grep -n x86 /usr/portage/metadata/cache/dev-python/ipython-0.9.1 show something? If yes, in which line? (The keywords should be in line 9).
grep -n x86 $EPREFIX/usr/portage/metadata/cache/dev-python/ipython-0.9.1 prints nothing. Actually, -0 on line 15 is the only visible content of that file.
grobian, please look into this. the metadata cache is extremely empty/broken. # return the number of lines in the cache file %% wc -l $EPREFIX/usr/portage/metadata/cache/dev-python/ipython-0.9.1 22 /home/jolexa/portage/linux-64/usr/portage/metadata/cache/dev-python/ipython-0.9.1 # return ALL the non blank lines %% grep -v '^$' $EPREFIX/usr/portage/metadata/cache/dev-python/ipython-0.9.1 -0 %% # to confirm it is tree wide, try another random package %% grep -v '^$' $EPREFIX/usr/portage/metadata/cache/app-portage/eix-0.15.6 -0 %%
Correct, metadata cache is screwed. Regenerating as we speak. Hopefully solved within an hour. Thanks for figuring this out. It is all related to the EAPI change the tree went through.
metadata is flowing to the rsync slaves now, please reopen if this problem persists after syncing in half an hour from now.
(In reply to comment #7) > metadata is flowing to the rsync slaves now, please reopen if this problem > persists after syncing in half an hour from now. > Looks good after last night's webrsync.
metadata cache is behind the tree, now. I think some settings are still incomplete. % ls metadata/cache/sys-apps/portage-* metadata/cache/sys-apps/portage-2.2.00.13200 metadata/cache/sys-apps/portage-2.2.00.13280 metadata/cache/sys-apps/portage-2.2.00.13286 % ls sys-apps/portage/portage-* sys-apps/portage/portage-2.2.00.13286-r1.ebuild sys-apps/portage/portage-2.2.00.13346.ebuild
I'm affraid this is caused by one of the portage ebuilds being EAPI="prefix" which the metadata cache gen doesn't understand. This ebuild is about to be nuked soon. Does it cause problems other than performance?
If I ignore the performance problem, I have nothing to do with this bug.
metadata seems not to be generated at all, I misunderstood comment #9
metadata was generated in the wrong location, hence never ended up in the rsync tree.
