Merge lp://staging/~jhodapp/powerd/fix-music-app-next into lp://staging/powerd

First, I'd argue that powerd shouldn't have this sort of behavior at all, and that the media hub or whoever shouldn't release it's active state request until it's really okay for the device to suspend.

Assuming that powerd should have this behavior, this isn't the right way to do it. The point of using a wake lock here is to avoid a race with the in-kernel autosuspend and handling an incoming request. I.e., block suspend in the kernel until the reqeust can get handed over to the main thread and that thread disables suspend. If powerd were ever used with a kernel lacking autosuspend (e.g. the stock distro kernels) this will fail, because there's no notion of wake locks in these kernels.

It would be better to move the call to enter_suspend() to happen in a timeout 6 seconds in the future, but you've got to make sure that the timeout is cancelled if leaving the suspend state in the interim.

PASSED: Continuous integration, rev:137
http://jenkins.qa.ubuntu.com/job/powerd-ci/158/
Executed test runs:
    SUCCESS: http://jenkins.qa.ubuntu.com/job/powerd-utopic-armhf-ci/10
        deb: http://jenkins.qa.ubuntu.com/job/powerd-utopic-armhf-ci/10/artifact/work/output/*zip*/output.zip

Click here to trigger a rebuild:
http://s-jenkins.ubuntu-ci:8080/job/powerd-ci/158/rebuild

Seth, thanks for the feedback. I wasn't quite sure where it should be done and thought about doing that in enter_suspend() as well. It wasn't quite obvious to me what the difference is between the two. Maybe adding a code comment for both functions would be appropriate to make it absolutely clear what the difference is?

I could go either way for a fix, either in powerd or media-hub. I'm discussing your objections to putting this in powerd with rsalveti. I do know of a way of accomplishing this in media-hub and may decide to move it there.

Yeah, let's land this in media-hub for now, better to avoid races and regressions.