Bug #99823 dealt with the problem that sys-apps/portage had switched from using pid files to using nothing of the sort for genlop to recognise a sandbox process by, apart from the process name in the proc filesystem which was then used in the subsequent version of genlop (bug #100938) that ultimately fixed that bug. One complaint of mine at the time was that the developers changed the error message in a way that didn't match all the cases in which the error occured: # genlop -c !!! Error: no working merge found. (the -c option only works if there is an ongoing compilation, see manpage) In this case, for instance, there was no sandbox process for genlop to recognise because FEATURES=userpriv had been set: only an ebuild.sh process owned by portage:portage could tell genlop that there was an ongoing compilation. genlop -c also fails when there is an emerge running, but no sandbox. Even if the code that recognises ongoing emerge processes were not enhanced to pick up non-sandbox emerge processes as well, the above error message is plainly wrong in its explanation as to why it failed to find any running processes it could use, and adds an insulting RTFM to boot. Summarising, the error message should probably be replaced with something like this: !!! Error: no working merge found. until such time when genlop is again fixed to find these special emerge processes too.
manpage should be updated it does not work here with FEATURES set to sandbox userpriv user-sandbox as per the manpage. Receive same message no working merge found.
