Merge lp:~mterry/ubuntu-system-settings/split-bg into lp:ubuntu-system-settings
Status: | Merged | ||||
---|---|---|---|---|---|
Approved by: | Iain Lane | ||||
Approved revision: | 729 | ||||
Merged at revision: | 726 | ||||
Proposed branch: | lp:~mterry/ubuntu-system-settings/split-bg | ||||
Merge into: | lp:ubuntu-system-settings | ||||
Diff against target: |
148 lines (+70/-7) 4 files modified
debian/ubuntu-system-settings.postrm (+9/-0) plugins/background/background.cpp (+53/-5) plugins/background/background.h (+4/-0) plugins/background/utilities.js (+4/-2) |
||||
To merge this branch: | bzr merge lp:~mterry/ubuntu-system-settings/split-bg | ||||
Related bugs: |
|
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Iain Lane | Approve | ||
PS Jenkins bot | continuous-integration | Approve | |
Review via email: mp+222092@code.launchpad.net |
Commit message
Use XDG_GREETER_
Description of the change
Use XDG_GREETER_
The greeter is a separate user and often can't read files inside the user's $HOME. But ContentHub puts files there. So we need to move those files to the greeter location.
If the package is purged, we clean up after ourselves.
I didn't worry about migration. If we wanted to do it, I imagine on startup, we could move files from $HOME to the greeter data dir and also make sure that the AccountsService field is updated.
== Checklist ==
* Is your branch in sync with latest trunk (e.g. bzr pull lp:trunk -> no changes)
- Yes
* Did you build your software in a clean sbuild/pbuilder chroot or ppa?
- Yes
* Did you build your software in a clean sbuild/pbuilder armhf chroot or ppa?
- Yes
* Has your component "TestPlan” been executed successfully on emulator, N4?
- Yes
* Has a 5 minute exploratory testing run been executed on N4?
- Yes
* If you changed the packaging (debian), did you subscribe a core-dev to this MP?
- I am a core-dev
* If you changed the UI, did you subscribe the design-reviewers to this MP?
- NA
* What components might get impacted by your changes?
- None really, though we rely on behavior of LightDM
* Have you requested review by the teams of these owning components?
- NA
PASSED: Continuous integration, rev:726 jenkins. qa.ubuntu. com/job/ ubuntu- system- settings- ci/856/ jenkins. qa.ubuntu. com/job/ generic- deb-autopilot- utopic- touch/672 jenkins. qa.ubuntu. com/job/ generic- mediumtests- utopic/ 615 jenkins. qa.ubuntu. com/job/ ubuntu- system- settings- utopic- amd64-ci/ 48 jenkins. qa.ubuntu. com/job/ ubuntu- system- settings- utopic- armhf-ci/ 48 jenkins. qa.ubuntu. com/job/ ubuntu- system- settings- utopic- armhf-ci/ 48/artifact/ work/output/ *zip*/output. zip jenkins. qa.ubuntu. com/job/ ubuntu- system- settings- utopic- i386-ci/ 48 jenkins. qa.ubuntu. com/job/ generic- deb-autopilot- runner- mako/1104 jenkins. qa.ubuntu. com/job/ generic- mediumtests- builder- utopic- armhf/1283 jenkins. qa.ubuntu. com/job/ generic- mediumtests- builder- utopic- armhf/1283/ artifact/ work/output/ *zip*/output. zip s-jenkins. ubuntu- ci:8080/ job/touch- flash-device/ 8092 jenkins. qa.ubuntu. com/job/ autopilot- testrunner- otto-utopic/ 547 jenkins. qa.ubuntu. com/job/ generic- mediumtests- builder- utopic- amd64/754 jenkins. qa.ubuntu. com/job/ generic- mediumtests- builder- utopic- amd64/754/ artifact/ work/output/ *zip*/output. zip
http://
Executed test runs:
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
deb: http://
Click here to trigger a rebuild: s-jenkins. ubuntu- ci:8080/ job/ubuntu- system- settings- ci/856/ rebuild
http://