I meant help by providing a bit more info. But I've worked out the problem in those two cases (I told you the virtual code might be flaky).

Lines 1916ff:

Code:

for p in others:
myprovide = vardbapi.aux_get(cpv, ["PROVIDE"])[0].split()
if mycp not in provide:
continue

Change 'provide' in that if to 'myprovide'. Stupid typos. But I'd be interested in that debug info anyway-- I'd like to know why your system is causing it to throw errors on baselayout and coreutils when mine isn't.

There's no such package, actually. There's a games-util/qstat-2.6 and games-util/qstat-2.5c in the tree, but nothing like games-util/qstat-25. Trying to emerge it, which should normally give an error message saying you should append a '=', it outputs this error message:

Which I don't consider normal. I'm no portage developer, but I believe thebell should have a solution.
At the first sight it's a broken dependency, i.e. either a typing mistake or the package was renamed/deleted._________________Best regards,
neonik

netshot-0.0.8 - script that takes screenshots, generates their thumbnails and uploads them all! (has not been updated).

There's no such package, actually. There's a games-util/qstat-2.6 and games-util/qstat-2.5c in the tree, but nothing like games-util/qstat-25. Trying to emerge it, which should normally give an error message saying you should append a '=', it outputs this error message:

Which I don't consider normal. I'm no portage developer, but I believe thebell should have a solution.
At the first sight it's a broken dependency, i.e. either a typing mistake or the package was renamed/deleted.

Yah, I noticed that the package didn't exist. I did try copying the 2.5c ebuild naming it 25c (since it seems to be that). However, it still failed.

Should I need to do anything now? Rebuild some cache or something? Because gtk+ (so I assume xorg-x11 as well) still fails on qstat-25.

What? I thought I got rid of qstat-25c. During the unmerge of the older version I saw this, but don't know if it means anything significant. It just confirms what you said and what I originally suspected:

BTW, in the future, shouldn't reverse dependancy checking be able to handle a non-existant ebuild without dying? I notice that some ebuilds get renamed from time to time. So, it would be safer if the patched emerge could handle these without choking. (Eg, there was once an ebuild for bittorrent-theshadow, or something similar. But it has since been renamed to bittornado to match the project's new name)_________________rcxAsh

Sorry all, but I've been out of the loop for a while, and kinda lost this thread.

rcxAsh: that's an interesting problem. It does seem to choke on some dep atoms that are otherwise accepted, and I can't quite work out why, since it uses Portage's existing atom matching functions. As for dying on non-existant ebuilds, it definitely shouldn't, but I can't see how it would at the moment. The revdep code doesn't even look in the portage tree. I'm on a different computer at the moment, but I'll have a look at that as soon as I get back.

The latest patch is against 2.0.51_pre20, so it probably won't apply cleanly to .50. Those two rejects are fairly simple to fix though-- just open up emerge in an editor, remove the lines with a '-' next to them, and add the ones with a '+'.

Hi is this project alive yet? i would like to help testing
btw thanks for your work

It worked last time I tried it, but it hasn't been updated to the latest portage versions, so it might not now. I doubt I'll be updating it any further either, since jstubbs is working on a completely new dependency engine for portage-2.1 which will make this unnecessary.