I have broken dependencies in my portage tree (amd64). The latest stable fam (2.7.0-r1) is installed but it doesn't provide the virtual/fam package.
emerge: there are no ebuilds to satisfy "virtual/fam".
!!! Problem with ebuild dev-python/gnome-python-2.0.0-r1
!!! Possibly a DEPEND/*DEPEND problem.
!!! Depgraph creation failed.
I am running a version of fam that was compiled in May. (before you added the PROVIDE="virtual/fam" to the eduild file.) This should somehow be detected by portage, potentially by creating a new version of the package.
Same problem here.
Reemerging fam fixed it for me as it replaces the outdated ebuild file in /var/db/pkg with the new one from the portage tree.
It seems this is a general problem when ebuild files are updated.
I have also had a few packages that wouldn't unmerge because of errors in the ebuild files. These errors were fixed in the portage tree but after i merged the package so the ebuild files in /var/db/pkg still contains errors making it impossible to unmerge. Quite annoying when it happens in old packages which have disappeared from the portage tree.
I have/had a similar problem.
Mine was because I have mplayer and mplayer-plugin installed with ~x86 keywords.
The new mplayer-plugin now requires the gecko-sdk, which is also masked by ~x86 (I think)
so, when I did an 'emerge --deep --tree world' my whole emerge failed as well.
I think (I am building as we go right now) that by manually 'USE_KEYWORDS=~x86 emerge --deep mplayer-plugin' I might be able to 'bypass' this bug.
Still, I have had previous issues along similar lines where I suggested that the failure of generating a particular branch in the depgraph tree should not cause the entire tree to fail.
*** Bug 73731 has been marked as a duplicate of this bug. ***
this is probably because of using an outdated profile. virtual/fam is defined in base profile & as such it should be picked up there.
I do not understand. How is this fixed?
*** Bug 74269 has been marked as a duplicate of this bug. ***
Profiles 2004.0 and 2004.2 are still listed as supported for AMD64.
*sigh* those are also stacked profiles now, the virtual is defined in base/virtuals and all profiles should inherit that. So either your profiles are messed up or out of date or just maybe there is a real bug here (i doubt that), but I cannot reproduce and so far nothing leads me to believe it is a real bug on our side.
I checkd my base/virtual and virtual/fam is defined. So why doesn't it get used?
in /usr/portage/profiles there are the following relevant subdirectories:
and default-linux/amd64/ provides
For AMD64 2004.0 and 2004.2 are old (non-stacked) profiles. virtuals/fam is undefined there.
no they're not.. and stop reopening this thing, just switch profiles according to the amd64 team those profiles are already or are going to be ditched tonight.
so consider them non-supported, let that close this thing i can't do the first thing about anyway and give me some darn peace instead of wasting time on non-issues
I can live with a closing of this bug as CANTFIX or WONTFIX. I count at least five reports of the problem here, so there must have been a problem.
I thougt we agreed on marking this bug as WONT FIX...
Yes, will not fix.
no i close it invalid because you shouldve updated your profile
and dont freaking reopen if ive already closed it
I guess you two are not friends. Also, since I was caught by this too, could their be a way for a user to select a gentoo emerge for automating a profile update. Might sound silly, but you guys know what to check for. I updated mine, first time I didn't simply install from the latest liveCD release, and ended up having problems. The first thing I ran into was that an "emerge -uD world" failed to install the gcc update. Not much else I could do when that wouldn't work.
I gave up trying to fix and ended up installing the latest release anyway. Sorry, didn't know where to post this comment. Maybe one of you could pass it along.
Would you mind filing a separate bug? This bug has been marked closed, which
means that few people are going to look at it. Since you're suggesting
something that doesn't really have anything to do with fam, per se, a separate
bug would be much more useful.