Comment 4 for bug 1284217

I think we talked about this - there isn't a second UAS signal for the second CFU method call. Because an update check is already in progress when the second CFU is made, the second one returns immediately. The second call *can't* send a UAS because it doesn't yet know whether an update is available (that check is already in progress). Because CFU is asynchronous, there's nothing more it can really do.

But you will still get an UAS signal when the previously in-progress check is complete, and you will still get UpdateProgress signals once the download is in progress.

Shouldn't both the main panel and the Update panel both be listening on the D-Bus for the UAS signal? Why do you need two UAS signals?

You mention the "checking lock not acquired" message, but that's just a debugging log indicating that the lock was not acquired after the second CFU call. That makes sense - the first check is still running in the background. When that first check completes, you'll get the expected UAS signal.