[00:15] <Saviq> robru, the test was invalid - it was trying to rebuild qtmir, which is not what autopkgtests are for and caused us trouble now that britney runs per trigger and not all of proposed
[00:15] <robru> ah
[00:16] <Saviq> thanks, g'night!
[00:16] <robru> Saviq: night
[02:04] <michi> trainguards: I have a weird failure in a silo.
[02:04] <michi> ppc64el fails, but there is no build log: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-006/+build/9419613
[02:04] <michi> Anyone around who can help?
[02:05] <robru> michi: no idea. I just hit retry in the hopes that it gives a log next time
[02:05] <michi> It’s also failed in silo 59, same story there.
[02:06] <robru> Well that's troubling
[02:06] <michi> It’s clearly an infrastructure thing. All the other arches built fine.
[02:07] <michi> Trying a rebuild...
[02:08] <robru> michi: right but if it was a one off, it'd seem more likely to work on a retry. If there's consistent failures then we may need to escalate to Colin
[02:08] <michi> Yeah
[02:08] <michi> robru: When does Colin normally come online?
[02:08] <michi> I don’t see him right now.
[02:09] <michi> Ah, no, he’s around...
[02:09] <robru> michi: UK time officially but he's known to keep irregular hours
[02:09] <michi> Well, that makes it around 1 am or so over there...
[02:10] <robru> michi: anyway the retries have logs showing live, just a question of if it'll keep them after
[02:10] <michi> I’ll keep an eye on them, thanks.
[02:13] <michi> robru: This is not looking good: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-006/+build/9419741
[02:14] <michi> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-059/+build/9419724
[02:14] <robru> michi: huh beats me. Maybe try wgrant
[02:15] <michi> wgrant: ^
[02:15] <michi> Can you help?
[02:16] <michi> cjwatson: In the unlikely case that you are still around, it looks like something is broken with the ppc64el builders for the train.
[02:28] <wgrant> robru, michi: Looking.
[02:28] <robru> Thanks
[03:55] <bzoltan> jibel: popey: I have fixed the 35 silo, so it is fully OK - https://requests.ci-train.ubuntu.com/#/ticket/1095 If you want it on OTA10 please put it on a quick line to QA and see if it is good for you.
[04:42] <slangasek> robru: why do the silo descriptions link to swift objects that aren't readable? (e.g. https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-066, https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_39a8dbb93caf4ec889f8a1b7f69885db/bileto-1186/2016-03-30_07:49:08/xenial/qtmir/content.diff)
[04:43] <robru> slangasek: because the artifacts are deleted when the silo lands
[04:43] <slangasek> robru: that silo isn't landed; it's stuck in -proposed
[04:43] <slangasek> robru: relatedly: why is the qtmir from that silo reported to no longer have any autopkgtests?
[04:43] <robru> slangasek: the description says landed right there. Probably force merged
[04:44] <slangasek> ok so who's force merging and why?
[04:44] <slangasek> (why do we even still allow force merges?)
[04:45] <robru> slangasek: Saviq asked me to force merge that one because it was stuck because of the same issue with dpkg breaking the packages to not run autopkgtests
[04:45] <slangasek> This doesn't get to land.  Someone needs to take responsibility for the fact that the autopkgtests have gone missing from the source.  Saviq ? (the only one of the three landers currently online...) http://autopkgtest.ubuntu.com/packages/q/qtmir/xenial/amd64/
[04:46] <slangasek> robru: what "same issue"?
[04:46] <robru> slangasek: it passed qa and just needed a small follow-up silo to fix the packaging to get it through proposed
[04:46] <robru> slangasek: the dpkg ftbfs in the backport ppa was meant to fix this
[04:47] <slangasek> hmm
[04:47] <robru> slangasek: instead Saviq started a new silo with packaging fixes that restore the autopkgtests
[04:48] <slangasek> I am unclear how it's dpkg's fault that the source package has no debian/tests directory
[04:48] <robru> slangasek: basically the autopkgtests were broken by my dpkg-buildpackage work because apparently vivid and newer automatically add the Testsuite: field but the trusty version doesn't
[04:48] <slangasek> or why it's acceptable to force-merge things that need source fixes in order to get into xenial
[04:48] <slangasek> robru: I just downloaded the source package from the archive; it has Testsuite: in the .dsc file
[04:49] <slangasek> but there are no actual debian/tests in the source package
[04:49] <robru> slangasek: Hmmmmmmm
[04:49] <robru> slangasek: i didn't actually look at it, I'm just going off what pitti told me
[04:49] <slangasek> $ pull-lp-source qtmir && grep Testsuite qtmir*.dsc
[04:49] <slangasek> Testsuite: autopkgtest
[04:49] <slangasek> $
[04:50] <robru> slangasek: pull-lp-source? That'll grab what's in xenial, not the broken one stuck in proposed
[04:50] <slangasek> nope
[04:50] <slangasek> pull-lp-source pulls the latest, == -proposed
[04:53] <robru> slangasek: so I'm just going off https://bugs.launchpad.net/bileto/+bug/1564084
[04:53] <ubot5`> Launchpad bug 1564084 in Bileto "Does not automatically add "Testsuite:" header any more" [Undecided,New]
[04:54] <robru> slangasek: and this is the silo Saviq put together to fix it: https://requests.ci-train.ubuntu.com/#/ticket/1206
[04:55] <slangasek> robru: right, so that's unrelated to what has happened to qtmir
[04:55] <slangasek> that bug reports a problem with a unity8 package, not with qtmir.  qtmir has the Testsuite header, autopkgtest tries to test it, and it fails because there are no tests in the source (and I can't see from the diff where they've gone)
[04:56] <slangasek> robru: however, if this was the bug you had suggested "only affected unity8", then that should certainly not be the case
[04:56] <robru> slangasek: https://code.launchpad.net/~saviq/qtmir/drop-testsuite-header/+merge/290468
[04:57] <slangasek> robru: where did the *tests* go?
[04:57] <robru> slangasek: Saviq said somewhere they were no good so he got rid of them.
[04:57] <slangasek> hmm
[04:58] <robru> slangasek: anyway ticket 1206 is supposed to fix everything and make everybody happy
[04:58] <slangasek> ok, then dropping the testsuite header is correct in that case
[04:58] <slangasek> well, it does not make me happy to have fewer tests ;)
[04:58] <robru> slangasek: it could have been rebuilt in the same old silo instead of force merging but he didn't want to re-qa the whole thing since it was already approved.
[04:59] <robru> slangasek: from what he said it sounded like the tests had no value, or negative value (eg flaky tests that didn't actually test anything meaningful)
[04:59] <robru> slangasek: I can't remember, I think it's in the scrollback in this channel if you look ~5 hours back
[05:02] <slangasek> robru: ok; so I've found the packaging diff and I don't see how Saviq justifies the claim that the tests were no good
[05:02] <slangasek> certainly not to where dropping them is better than keeping them
[05:03] <slangasek> and if we're force-merging because a one-line update to debian/control requires a complete QA re-test, then isn't that a bug in the QA workflow?
[05:04] <robru> slangasek: well if the silo is rebuilt for any reason it clears the qa approval
[05:04] <slangasek> i.e., either a rebuild with no changes to the upstream source requires a full QA retest, or it doesn't - regardless of it's done in this silo or another
[05:04] <robru> slangasek: bileto doesn't know that somethings' being rebuilt for a one line change or even for a no-line change
[05:04] <slangasek> sure
[05:04] <slangasek> but the lander can tell QA, and QA and rubberstamp
[05:04] <robru> right
[05:06] <robru> slangasek: anyway, I think the force-merge is sort of a red herring here, sure it's suboptimal but the real issue is just that you don't approve of the tests being deleted. which I think you should take up with Saviq since I'm not really familiar with why they're being dropped
[05:06] <robru> slangasek: I can't seem to find the message, I thought it was IRC, maybe it was an MP comment or something somewhere
[05:06] <slangasek> robru: no, I don't approve of the tests being deleted, *AND* I don't approve of things being force-merged and left in xenial-proposed
[05:08] <robru> slangasek: I was under the impression that it's ok to force merge when things are stuck as long as people promise to keep an eye on it, and in this case Saviq has a new silo to fix this already prepped, so it seemed ok to me
[05:11] <slangasek> robru: hmm; I wasn't aware that was the accepted practice - at this point in the release cycle, it does mean e.g. release team members going on wild goose chases in update_excuses
[05:13] <robru> slangasek: how does force merge impact release team people? stuff sitting in proposed would look the same to them regardless of if the ticket is merged or not? I don't see the big deal with force merging really since it just means trunk is slightly ahead of distro for a short while. sometimes if there's two conflicting silos and one is being a little slow to
[05:13] <robru> migrate I'll get asked for force merge so that the other silo can be rebuilt sooner, eg, to unblock people wanting to land conflicting silos.
[05:13] <robru> slangasek: it's not an every-day thing but it happens sometimes when people are rushing to get OTAs out the door.
[05:23] <slangasek> robru: hmm, perhaps it's marginal and you should ignore my late-night rant :) but it took extra time to track down the landing because it was force-merged, so it was no longer listed on requests.ci-train.u.c
[05:28] <robru> slangasek: no i think your concerns are justified, there's definitely gaps in the discoverability of information in the system. just needs some iterations here and there
[08:13] <popey> bzoltan: Thanks. i haven't tested a silo for a while, what's the easiest way for me to test that on a device?
[08:15] <bzoltan> popey: I think that /usr/bin/citrain device-upgrade 35 [DEVICE-PASSWORD] is the easiest way
[08:16] <popey> thanks
[08:27] <tvoss> Mirv, for reference: https://code.launchpad.net/~thomas-voss/platform-api/build-modules-as-shared-libraries/+merge/290571
[08:49] <Mirv> tvoss: oh, ok!
[09:02] <popey> bzoltan: jibel silo 35 works for me.
[09:03] <bzoltan> popey: Cool. The Automated Signoff is running, after that i think the packages can be released to xenial  too
[10:10] <bzoltan> jibel: popey: ready to land https://requests.ci-train.ubuntu.com/#/ticket/1202
[10:13] <popey> sweet!, thanks bzoltan
[10:13] <bzoltan> popey:  with pleasure .. nice to fix bugs quickly
[11:20] <popey> bzoltan: i see rvr has a problem with that landing
[11:21] <popey> bzoltan: https://trello.com/c/nGHexJw8/3001-1202-ubuntu-landing-035-ubuntu-ui-toolkit-bzoltan
[11:21] <popey> rvr: any chance you can put videos on people.canonical.com rather that private share, as they're inaccessible to community people. ta
[11:29] <rvr> popey: I have problems accessing people, bad ssh config or something
[11:29] <rvr> I'll try to fix
[11:58] <bzoltan> rvr: popey: is that indicator color issue somehow related to this silo35?
[12:00] <ahayzen> bzoltan, i think Tim's fix was just for MainView's .. that probably comes from Unity8 itself ? I think... and was there before silo035
[12:00] <bzoltan> ahayzen:  indeed
[12:01] <bzoltan> ahayzen: I can spend some time with checking how unity is using palette values, but not with this silo
[12:01] <bzoltan> ahayzen: i would need a day to go thru all the color settings in unity
[12:01] <ahayzen> yeah sounds like a separate issue to this one, silo035 was trying to fix the colours on app launch not todo with the shell
[14:02] <jibel> tvoss, did you publish 33?
[14:03] <tvoss> jibel, nope, do I need to?
[14:03]  * sil2100 is on it
[14:03] <jibel> thanks
[14:03] <sil2100> https://code.launchpad.net/~thomas-voss/location-service/fix-1447110/+merge/289979
[14:03] <sil2100> Needs approval
[14:03] <sil2100> tvoss: ^
[14:03] <tvoss> sil2100, ack
[14:03] <tvoss> ssweeny, mind top-approving: https://code.launchpad.net/~thomas-voss/location-service/fix-1447110/+merge/289979
[14:04] <ssweeny> tvoss, done
[14:04] <tvoss> sil2100, ^
[14:08] <rvr> bzoltan: Silo 35 approved
[14:10] <sil2100> \o/
[14:11] <sil2100> Publishing that as well
[14:25] <sil2100> bzoltan: ^
[14:25] <ahayzen> \o/
[14:25] <sil2100> bzoltan: please review https://code.launchpad.net/~tpeeters/ubuntu-ui-toolkit/fasterWindowColorTrunk/+merge/290458 and https://code.launchpad.net/~bzoltan/ubuntu-ui-toolkit/cherry_pick-gles/+merge/290461
[14:49] <sil2100> Eh
[14:49] <sil2100> Publishing forcing the unapproved branches
[14:50] <sil2100> We don't have time to spare
[15:04] <tvoss> ssweeny, would you mind if we take https://requests.ci-train.ubuntu.com/#/ticket/1104 prior to your ls landing?
[15:04] <ssweeny> tvoss, go right ahead :)
[15:59] <sil2100> jibel, robru, rvr: I guess we cancel the LT meeting since we have the status meeting at the same time, right?
[15:59] <sil2100> Or maybe we do both at once!
[15:59] <jibel> sil2100, yeah, I didn't plan to attend the landing meeting
[15:59] <jibel> it's a bit redundant
[16:00] <pmcgowan> sil2100, jibel should be quick
[18:11] <pmcgowan> sil2100, whats up with silo 68, its not publishing due excuses
[18:17] <pmcgowan> trainguards can you check silo 68? does someone just need to push it?
[18:18] <robru> pmcgowan: according to britney the android package has unsatisfiable depends but somehow QA approved it anyway.
[18:18] <robru> pmcgowan: but yeah this doesn't block publication, if somebody wants to publish it they can
[18:19] <pmcgowan> robru, this happened with something the other day and we just published
[18:19] <pmcgowan> robru, who can publish it?
[18:19] <robru> pmcgowan: any core dev can do it
[18:19] <pmcgowan> that again :)
[18:20] <pmcgowan> I nominate you for core dev
[18:20] <pmcgowan> mterry, ?
[18:20] <robru> pmcgowan: yeah that's on my to-do list but it's been getting away on me, sorry
[18:20] <robru> ken is mysteriously not here, he's my go-to core dev
[18:21] <mterry> pmcgowan: maybe...?  robru, what's the story with unsatisifable depends?
[18:21] <robru> mterry: https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-068/excuses.html but I dunno, i guess android package is special
[18:22] <pmcgowan> mterry, this same thing happened with a silo the other day and ken just pushed it in
[18:22] <pmcgowan> but I dont know why
[18:22] <mterry> the hidden assumption there being that that was the right thing to do?
[18:22] <pmcgowan> seemed to be, somehow ken knew it was bogus, but I really dont know
[18:23] <robru> mterry: I see it this way: this silo isn't actually introducing the unsatisfiable depends (if you look at the diff), so I guess it's a false positive in britney or eg I guess the image builder just pulls it in regardless of the depends or something
[18:24]  * mterry is going throught that silo's packaging diffs and then if nothing crazy, is happy to publish
[18:24] <robru> mterry: yeah you should be reviewing diffs before publishing generally ;-)
[18:24] <dobey> hrmm
[18:24] <robru> mterry: https://requests.ci-train.ubuntu.com/#/ticket/995
[18:25] <dobey> robru: i think it's because the autopkgtests environments don't have multi-arch on maybe? if i install "ubuntu-emulator-runtime" on my machine, it pulls in the :i386 one
[18:25] <mterry> robru: uh.. android-tools-5.1.1r36+git20160322/debian/android-tools-adb.postinst does some crazy stuff, including modifying the current user's (whoever that might be when installing!) ~/.android/adb_usb.ini...
[18:26] <robru> mterry: isn't postinst just run by root?
[18:26] <mterry> robru: if you're running sudo, I'm guessing $HOME is still your user
[18:27] <dobey> eww
[18:27] <dobey> that is nasty
[18:27] <robru> it's clearly just appending device IDs so that they work without clobbering the existing file
[18:27] <mterry> robru: or creating the file
[18:28] <mterry> robru: that's against policy though, to muck with user files.  I think we do it in very few cases.  But usually we have user-migration scripts to do that in a sane way
[18:28] <dobey> and that obviously doesn't help other users on the system who aren't the one running the apt-get install/upgrade
[18:29] <mterry> robru: er session-migration
[18:29] <mterry> robru: This should use a session-migration script, not muck with files directly.  I can't ACK this
[18:30] <robru> mterry: hang on, something funny is going on. I can't find this postinst script in the input mp.
[18:30] <dobey> android-tools isn't managed in launchpad
[18:31] <dobey> the indicator mp obviously won't have it
[18:31] <robru> oh, manual packages. great
[18:31] <dobey> yup
[18:32] <dobey> i don't understand why that wasn't done in a patch though, instead of a hacky postinst
[18:32] <robru> morphis: what's up with android tools? ^^
[18:32] <dobey> the comment even claims the source has some list compiled into the default client; obviously we should be patching that list
[18:34] <mterry> dobey: agreed
[18:34] <dobey> ondra just left though i think
[18:35] <pmcgowan> I don't even think thats true
[18:35] <dobey> which part?
[18:35] <pmcgowan> things work fine without those
[18:35] <pmcgowan> I thought they were added elsewhere
[18:35] <dobey> without the adb_usb.ini ?
[18:35] <pmcgowan> yeah
[18:36] <pmcgowan> BQ and Meizu is not exactly new to us
[18:36] <dobey> oh they were
[18:36] <dobey> +++ android-tools-5.1.1r36+git20160322/debian/patches/add-bq-vendor-id.patch	1970-01-01 00:00:00.000000000 +0000
[18:37] <dobey> so someone needs to regeenrate a source package without the postinst muck, and re-upload to the silo ppa for both xenial/vivid
[18:37] <dobey> (i don't have permissions to upload to the PPA)
[18:38] <pmcgowan> who does?
[18:38] <pmcgowan> I can email ondrej as he said he would be back online later
[18:38] <dobey> i presume robru does. mterry does as well i guess, being a core dev
[18:39] <dobey> mterry: ^^ can you strip that postinst muck out and tweak the version numbers, and re-upload to the PPA?
[18:39] <robru> pmcgowan: yes for silo PPA uploads, it's core devs + me
[18:40] <robru> but best let mterry do it so he can get it just right I think ;-)
[18:40] <mterry> dobey: so...  looks like the old patch got dropped, but the new IDs are still in the merged debian-changes
[18:40] <mterry> dobey: so I agree I'm not sure why the postinst stuff was done...
[18:41] <mterry> pmcgowan: morphis is best to do this, is he not around?
[18:41] <pmcgowan> mterry, dont know we can wait if its best
[18:42] <dobey> probably best to know who did that change exactly, and why
[18:42] <mterry> pmcgowan, robru: this is why I hate this "packaging-ACK" system -- last minute NACKs suck
[18:42] <pmcgowan> indeed
[18:42] <dobey> mterry: agreed
[18:43] <robru> mterry: totally agree, but I can't think of a way to get the ACKs coming sooner. there's no way to stop people making mistakes until they try to publish
[18:43] <mterry> dobey: well....  worst case if we strip out the bogus postinst stuff is that there is some manual config needed on dev machines.  But we won't break anything.  And that can be fixed by future patch...
[18:43] <mterry> robru: unity8 has a merge checklist, one of which is getting a packaging ACK if there are packaging changes.  Hard to FORCE that on other projects, but they should all be doing that
[18:44] <robru> mterry: agreed, should we talk to upper management and get this enforced on all projects? ;-)
[18:44] <dobey> mterry: well, the IDs seem like they are still added. the diff just looks a little weird because the patches all have the source dir with version in them as the reference
[18:44] <dobey> but maybe i read the diff wrong too
[18:44] <dobey> who knows
[18:45] <mterry> dobey: I agree they look like they are still added.  I'm just confused that the postinst stuff was added in first place.  So if our first blushes are correct, removing postinst bits is harmless.  If we're wrong, at worst some devs have to add some manual bits until someone can correct better...
[18:45] <mterry> So I'm just going to do the quick change and hope it is enough
[18:46]  * mterry patches
[18:46] <dobey> mterry: well if the ID patches are required for existing phones, and they are in fact removed, i guess it will break adb for all the current devices too
[18:47] <mterry> dobey: true...  not just dev machines but like all our test tooling  :)
[18:47] <dobey> mterry: but i guess it will be easier to tell if the patches are still there in an unpacked tree, too
[18:47] <mterry> dobey: I'll try it on my phones here at least
[18:47] <dobey> ok
[18:48] <dobey> if krillin still works, i guess it should be good
[18:48] <dobey> robru: fwiw, i /hate/ the checklist thing on unity8
[18:49] <dobey> would be nice to automate most of that work though
[18:51] <mterry> dobey: oh why?
[18:56] <mterry> dobey: ok...  recompiled locally, installed new adb.  did adb kill-server, made sure I didn't have my own ~/.android/adb_usb.ini...  Was able to get into both krillin and arale
[18:56] <mterry> dobey: I guess that's good enough
[19:00] <mterry> robru, pmcgowan: new android-tools for xenial & overlay are building in silo 68
[19:01] <robru> mterry: thanks
[19:01] <mterry> Packaging for everything else seemed fine enough
[19:01] <robru> mterry: right, android was the one blocked by unsatisfiable depends, so that one was ok after all
[19:04] <dobey> mterry: i find the whole concept of "copy and paste this big block of text into your MP and answer all the questions" a bit insulting really.
[19:04] <mterry> dobey: eh I like it as a simple way to avoid forgetting things
[19:05] <mterry> dobey: I'm a forgetful person  :)
[19:05] <dobey> mterry: i like "make check" as a simple way of not forgetting things :)
[19:06] <pmcgowan> mterry, awesome thanks
[19:09] <dobey> i don't know if there are tools for covering all parts of the debian policy, but would be nice to automate some of the stuff that we require a packaging ACK for, when it is possible
[19:10] <mterry> dobey: heh, snapshot the system before, if there are any deltas in $HOME, complain.  Repeat for all possible contents of $HOME  :)
[19:11] <mterry> dobey: or I suppose just grep for ~ or $HOME in a clever way in debian/
[19:11] <dobey> mterry: grep HOME debian/*.postinst seems easier
[19:11] <dobey> heh
[19:12] <mterry> dobey: but you won't catch malicious people assembling variable names out of H, O, M, and E, who just want to write code and hate your checker
[19:12] <dobey> mterry: or encode it into some lintian check if there isn't one already
[19:12] <dobey> well, we should fire those people :P
[19:13] <mterry> dobey: yeah... but how to fire them automatically...?  :P
[19:14] <dobey> mterry: like this: https://www.youtube.com/watch?v=Km6bFBSVty4
[19:15]  * mterry dusts off his fax machine
[19:17] <dobey> i guess we should also maybe have an apparmor rule that prevents dpkg scripts from screwing with $HOME
[19:17] <dobey> whoot
[19:18] <dobey> huh
[19:19] <dobey> mterry: i still see the postinst block in the xenial packaging diff
[19:20] <dobey> err, no
[19:20] <dobey> vivid
[19:20] <dobey> no, both
[19:20] <mterry> dobey: do you see a new changelog entry by me?
[19:20] <dobey> no
[19:20] <mterry> dobey: the packages aren't "published" in that PPA yet
[19:20] <mterry> dobey: I don't know what queuebot is on about
[19:21] <dobey> oh
[19:21] <dobey> hmm
[19:21] <dobey> ah ok
[19:24]  * mterry regenerates silo diffs
[19:26] <mterry> pmcgowan, robru: so I'm guessing you need to re-acquire QA signoff on silo 68?  Probably a quick smoketest to make sure it's still working is enough?  Tell QA folks to rm ~/.android/adb_usb.ini, run "adb kill-server" and then try to adb into their device to confirm the change is OK.
[19:34] <robru> ToyKeeper: jibel: ^
[19:35] <mterry> dobey: chagnes regenerated
[19:35] <pmcgowan> mterry, thanks
[19:36] <dobey> great
[19:37] <pmcgowan> mterry, is the whole silo rebuilding?
[19:37] <mterry> pmcgowan: shouldn't be?  I did a diff-regeneration-only build, but that said it finished
[19:38] <pmcgowan> great
[19:46] <robru> mterry: ok I commented on the ticket & the trello board, hopefully qa notices that soon enough
[20:20] <ToyKeeper> D'oh.  New adb silo isn't done after all?
[20:21] <ToyKeeper> ... and the suggested test will break some other things I have running.  I may want to wait a bit until the other tests finish.
[20:22] <pmcgowan> ToyKeeper, its a "really simple change" but prefer to sanity check
[21:55] <robru> Saviq: if you get a sec pls review https://code.launchpad.net/~robru/qtmir/inline-gles-quilt/+merge/290646
[21:59] <robru> ToyKeeper: "Tell QA folks to rm ~/.android/adb_usb.ini, run "adb kill-server" and then try to adb into their device to confirm the change is OK."