| Summary: | app-portage/gentoolkit - revdep-rebuild problem with lockfile | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | Jason King <jlist> |
| Component: | Tools | Assignee: | Portage Tools Team <tools-portage> |
| Status: | RESOLVED TEST-REQUEST | ||
| Severity: | normal | CC: | michael |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Jason King
2007-10-11 14:35:27 UTC
Which gentoolkit version is this about? app-portage/gentoolkit-0.2.4_pre7 What arguments did you pass to revdep-rebuild? It would be good to see the preceding output. Also, please attach the .revdep-rebuild* files. Thanks No args to revdep-rebuild, and the .revdep-rebuild* files were deleted long ago. The problem is just that somewhere in the revdep-rebuild it does some ebuild step which gets the "waiting for lock on /var/db/.pkg.portage_lockfile" result, and revdep-rebuild doesn't recognize this as a special case, so just parses the output as package names and proceeds with the merge. I thought this would be pretty easy to track down, which was why I didn't attach (or keep) the .revdep-rebuild* files, sorry. The really serious part of this bug was fixed with a patch submitted to similar bug #205227. The truth is you should not be running revdep-rebuild while you're emerging other stuff anyway. If you really need this thing fixed, do grep -vF 'waiting for lock' against $LIST.5_order after it gets generated in the get_build_order() function. That should fix it. Jason, please test and confirm this bug is fixed. |