Merge lp:~3v1n0/bamf/upstart-support into lp:bamf
| Status: | Merged |
|---|---|
| Approved by: | Andrea Azzarone on 2015-11-20 |
| Approved revision: | 651 |
| Merged at revision: | 621 |
| Proposed branch: | lp:~3v1n0/bamf/upstart-support |
| Merge into: | lp:bamf |
| Prerequisite: | lp:~ci-train-bot/bamf/bamf-ubuntu-xenial-landing-011 |
| Diff against target: |
64 lines (+20/-5) 4 files modified
data/Makefile.am (+10/-2) data/bamfdaemon-dbus-runner.in (+7/-0) data/bamfdaemon.conf.in (+2/-2) data/org.ayatana.bamf.service.in (+1/-1) |
| To merge this branch: | bzr merge lp:~3v1n0/bamf/upstart-support |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Andrea Azzarone | 2015-11-06 | Approve on 2015-11-20 | |
| PS Jenkins bot | continuous-integration | Approve on 2015-11-19 | |
|
Review via email:
|
|||
Commit Message
BamfDaemon: add upstart session support
- 649. By Marco Trevisan (Treviño) on 2015-11-06
-
BamfDaemon: add upstart support
- 650. By Marco Trevisan (Treviño) on 2015-11-19
-
data: add bamfdaemon-
dbus-runner, to run the daemon using upstart if possible
| PS Jenkins bot (ps-jenkins) wrote : | # |
PASSED: Continuous integration, rev:650
http://
Executed test runs:
SUCCESS: http://
SUCCESS: http://
deb: http://
Click here to trigger a rebuild:
http://
- 651. By Marco Trevisan (Treviño) on 2015-11-19
-
bamfdaemon: make start/stop depending on hud and unity-panel-service
| PS Jenkins bot (ps-jenkins) wrote : | # |
PASSED: Continuous integration, rev:651
http://
Executed test runs:
SUCCESS: http://
SUCCESS: http://
deb: http://
Click here to trigger a rebuild:
http://
| Martin Pitt (pitti) wrote : | # |
This adds quite a lot of complexity and potential for brittleness. You already had a followup fix for bamfdaemon-
start on (starting hud or starting unity-panel-service or starting unity7)
is correct and complete for all times. I. e. if someone tries to use bamf under Ubuntu GNOME, you will get 25s D-Bus timeouts.
D-Bus activation starts up the service *exactly* when and if it's needed, provides automatic restarts, and avoids all of this.
What was the rationale for this? It would be nice if commit logs would explain the "why", not (just) the "what". Thanks!
| Martin Pitt (pitti) wrote : | # |
To be precise, I think we should drop data/bamfdaemon
| Marco Trevisan (Treviño) (3v1n0) wrote : | # |
As explained in IRC, my POV was to ensure bamf is running with the same environment variables we had in unity, plus ensuring it to be respawn when killed or crashed, without having to directly call a dbus method (that for the way libbamf is done, might happen late, or only on user actions).

PASSED: Continuous integration, rev:649 jenkins. qa.ubuntu. com/job/ bamf-ci/ 119/ jenkins. qa.ubuntu. com/job/ bamf-wily- amd64-ci/ 4 jenkins. qa.ubuntu. com/job/ bamf-wily- armhf-ci/ 4 jenkins. qa.ubuntu. com/job/ bamf-wily- armhf-ci/ 4/artifact/ work/output/ *zip*/output. zip
http://
Executed test runs:
SUCCESS: http://
SUCCESS: http://
deb: http://
Click here to trigger a rebuild: s-jenkins. ubuntu- ci:8080/ job/bamf- ci/119/ rebuild
http://