Merge lp:~saviq/unity8/in-train-pot-update into lp:unity8
| Status: | Merged |
|---|---|
| Approved by: | Albert Astals Cid on 2015-12-09 |
| Approved revision: | 2077 |
| Merged at revision: | 2092 |
| Proposed branch: | lp:~saviq/unity8/in-train-pot-update |
| Merge into: | lp:unity8 |
| Diff against target: |
15 lines (+8/-0) 1 file modified
debian/rules (+8/-0) |
| To merge this branch: | bzr merge lp:~saviq/unity8/in-train-pot-update |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Albert Astals Cid (community) | Approve on 2015-12-09 | ||
| PS Jenkins bot | continuous-integration | Needs Fixing on 2015-12-03 | |
| Didier Roche | 2015-12-01 | Approve on 2015-12-03 | |
| Robert Bruce Park (community) | 2015-12-01 | Approve on 2015-12-01 | |
| Ubuntu Unity PS integration team | 2015-12-01 | Pending | |
|
Review via email:
|
|||
Commit Message
Update .pot file in debian/clean when in train
Description of the Change
* Are there any related MPs required for this MP to build/function as expected? Please list.
No
* Did you perform an exploratory manual test run of your code change and any related functionality?
Yes, see https:/
* Did you make sure that your branch does not contain spurious tags?
Yes
* If you changed the packaging (debian), did you subscribe the ubuntu-unity team to this MP?
Yes
* If you changed the UI, has there been a design review?
N/A
| Robert Bruce Park (robru) wrote : | # |
Looks mostly good to me, just wondering why you're testing for "-x /usr/bin/bzr". Is there a case where $SILONAME is defined but bzr isn't available? I think the test should just be for whether $SILONAME is defined or not.
Other than that I think it should be good on your end. Please test it out in a silo and let me know if it actually works. The 'bzr commit' will happen inside a chroot, and it's not clear to me whether bzr will actually be configured in there (I think it bind-mounts the home dir so it should have access to the hosts' bzr config but I'm not sure). What I'm trying to say is that if this doesn't work I probably need to fix it in the train side, so just let me know what's what.
| Michał Sawicz (saviq) wrote : | # |
> Looks mostly good to me, just wondering why you're testing for "-x
> /usr/bin/bzr". Is there a case where $SILONAME is defined but bzr isn't
> available? I think the test should just be for whether $SILONAME is defined or
> not.
Yeah, just avoiding potential pitfalls...
> Other than that I think it should be good on your end. Please test it out in a
> silo and let me know if it actually works. The 'bzr commit' will happen inside
> a chroot, and it's not clear to me whether bzr will actually be configured in
> there (I think it bind-mounts the home dir so it should have access to the
> hosts' bzr config but I'm not sure). What I'm trying to say is that if this
> doesn't work I probably need to fix it in the train side, so just let me know
> what's what.
Yeah, it does work, see the job in description, also lp:~ci-train-bot/unity8/unity8-ubuntu-xenial-landing-028
| Robert Bruce Park (robru) wrote : | # |
Awesome.
On Dec 1, 2015 12:36 PM, "Michał Sawicz" <email address hidden>
wrote:
> > Looks mostly good to me, just wondering why you're testing for "-x
> > /usr/bin/bzr". Is there a case where $SILONAME is defined but bzr isn't
> > available? I think the test should just be for whether $SILONAME is
> defined or
> > not.
>
> Yeah, just avoiding potential pitfalls...
>
> > Other than that I think it should be good on your end. Please test it
> out in a
> > silo and let me know if it actually works. The 'bzr commit' will happen
> inside
> > a chroot, and it's not clear to me whether bzr will actually be
> configured in
> > there (I think it bind-mounts the home dir so it should have access to
> the
> > hosts' bzr config but I'm not sure). What I'm trying to say is that if
> this
> > doesn't work I probably need to fix it in the train side, so just let me
> know
> > what's what.
>
> Yeah, it does work, see the job in description, also
> lp:~ci-train-bot/unity8/unity8-ubuntu-xenial-landing-028
> --
> https:/
> You are reviewing the proposed merge of
> lp:~saviq/unity8/in-train-pot-update into lp:unity8.
>
| Didier Roche (didrocks) wrote : | # |
I would rather:
override_
dh_auto_clean
# your update work here
Otherwise, +1, even if I think that this feature should be in the train itself
- 2077. By Michał Sawicz on 2015-12-03
-
Run dh_auto_clean, too
| PS Jenkins bot (ps-jenkins) wrote : | # |
FAILED: Continuous integration, rev:2077
http://
Executed test runs:
SUCCESS: http://
FAILURE: http://
UNSTABLE: http://
UNSTABLE: http://
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
FAILURE: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
Click here to trigger a rebuild:
http://
| Albert Astals Cid (aacid) wrote : | # |
Makes sense and seems to work.
* Did you perform an exploratory manual test run of the code change and any related functionality?
Not really, but trusting https:/
* Did CI run pass?
CI not affected
* Did you make sure that the branch does not contain spurious tags?
Yes
FAILED: Continuous integration, rev:2076
http://
Executed test runs:
SUCCESS: http://
FAILURE: http://
UNSTABLE: http://
UNSTABLE: http://
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
FAILURE: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
Click here to trigger a rebuild:
http://