Bluetooth Menu

Merge lp://qastaging/~charlesk/indicator-bluetooth/lp-1530807-watch-bluez-owner-on-bus into lp://qastaging/indicator-bluetooth/15.10

  1. lp-1530807-watch-bluez-owner-on-bus
  2. Merge into trunk.15.10
Proposed by Charles Kerr
Status: Merged
Approved by: Charles Kerr
Approved revision: 98
Merged at revision: 94
Proposed branch: lp://qastaging/~charlesk/indicator-bluetooth/lp-1530807-watch-bluez-owner-on-bus
Merge into: lp://qastaging/indicator-bluetooth/15.10
Diff against target: 142 lines (+56/-18)
1 file modified
src/bluez.vala (+56/-18)
To merge this branch: bzr merge lp://qastaging/~charlesk/indicator-bluetooth/lp-1530807-watch-bluez-owner-on-bus
Reviewer Review Type Date Requested Status
Xavi Garcia Approve
PS Jenkins bot (community) continuous-integration Approve
Review via email: mp+286003@code.qastaging.launchpad.net

Commit message

Change the indicator's Bluez class to watch for 'org.bluez' to appear/vanish on the system bus.

Description of the change

Several people experiencing bug #1530807 have stated that restarting indicator-bluetooth solves the issue, so the bug appears to be a timing issue with the indicator's startup.

Change the indicator's Bluez class to watch for 'org.bluez' to appear/vanish on the system bus and update accordingly. The class was previously brittle in that it assumed org.bluez would be up and running before the indicator started.

To post a comment you must log in.
Revision history for this message
PS Jenkins bot (ps-jenkins) wrote :

PASSED: Continuous integration, rev:98
http://jenkins.qa.ubuntu.com/job/indicator-bluetooth-ci/41/
Executed test runs:
    SUCCESS: http://jenkins.qa.ubuntu.com/job/indicator-bluetooth-wily-amd64-ci/3
    SUCCESS: http://jenkins.qa.ubuntu.com/job/indicator-bluetooth-wily-armhf-ci/3
        deb: http://jenkins.qa.ubuntu.com/job/indicator-bluetooth-wily-armhf-ci/3/artifact/work/output/*zip*/output.zip

Click here to trigger a rebuild:
http://s-jenkins.ubuntu-ci:8080/job/indicator-bluetooth-ci/41/rebuild

review: Approve (continuous-integration)
Revision history for this message
Xavi Garcia (xavi-garcia-mena) wrote :

just one question:
Why does it call init_bluez_state_vars () from the constructor and also from on_bluez_appeared?

do we need the call from on_bluez_appeared?

review: Needs Information
Revision history for this message
Xavi Garcia (xavi-garcia-mena) wrote :

Approving after discussion with alecu.
If we are not restarting the indicator it makes sense to re-initialize everything

review: Approve
Revision history for this message
Charles Kerr (charlesk) wrote :

Xavi, the idea was to have the indicator reset its state whenever org.bluez appeared on the bus, not just for the bootstrap case but also to handle bluez being stopped and restarted.

I agree that reinit'ing is probably not necessary in on_bluez_appeared() because the bootstrap case is handled in the ctor and the restart case is handled in on_bluez_vanished().

Since this MP's siloed and tested, though, let's leave this wart in for now and I'll make sure to clean it up when I come back and add bluez5 mock tests after the emergency landing.

Preview Diff

[H/L] Next/Prev Comment, [J/K] Next/Prev File, [N/P] Next/Prev Hunk
The diff is not available at this time. You can reload the page or download it.

Subscribers

People subscribed via source and target branches