Description of problem: The eggcups print queue manager tries to follow jobs queued for remote CUPS servers to the remote CUPS server. There is no reason I know of for it to do that. It should just watch the local job. Unless someone deliberately sets 'waitjob=no' on the queue or the job, the local job will stay around waiting for the remote job to finish. Cancelling the local job will cancel the remote job. Basically eggcups's 'follow remote jobs' feature is looking for a problem to solve, and just making everything worse in the process. It needs to be re-written to simply show the user the current queue. It doesn't need to track individual jobs -- CUPS does that. It doesn't need to maintain the status of each job -- CUPS does that. It also shouldn't bother with 'LocalJobStarted' etc -- it only needs to listen for 'QueueChanged' D-Bus events. They are sent whenever something has changed that makes it worth a print queue manager re-checking the queues. Version-Release number of selected component (if applicable): desktop-printing-0.19-17.0.1.fc6
Really, Tim ? Back when Colin and I were working on this, cups would loose all knowledge about a print job as soon as it was sent off to somewhere else, and it wasn't possible to get any updates for the (now remote) job via the local cupsd. If that works now, eggcups state machine can in fact be greatly simplified.
If it ever didn't work, it must have been a bug (now fixed). Or could it be you were thinking about when the job is completed? In that case, the job history for the job only resides on the remote server and not the local server (so e.g. 'lpstat -Wcompleted -o' on the local server won't show completed remote jobs).
eggcups needs to get status updates for the remote job until it is completed.
The ipp backend does this already, at 10s intervals. It fetches the printer-state-reasons job attribute from the remote server, sets its own state to copy it, and also logs an ERROR/WARNING/INFO about it. See report_printer_state() starting at backend/ipp.c:1428.