[04:09] <camako> Silo 10 received QA approval but britney seems to be still running... Is that going to prevent it from being published?
[04:39] <robru> camako: no, publish doesn't (yet) block on that, but may in the future if we get it to run more reliably.
[06:14] <camako> robru, o good. So it is ready to be published then?
[06:25] <robru> camako: yeah, go ahead and publish
[06:29] <camako> robru, Hmmm got an error ^^ . Is this due to packaging changes needing to be ack'ed by a core dev?
[06:34] <robru> camako: yes
=== chihchun_afk is now known as chihchun
[09:09] <popey> sil2100, https://bugs.launchpad.net/canonical-devices-system-image/+bug/1539352
[09:09] <ubot5> Launchpad bug 1539352 in Canonical System Image "Removed clicks come back on OTA update" [Undecided,New]
[09:11] <sil2100> popey: hm, yeah, I suppose it's pulling all those back that we had in the custom tarballs
[09:13] <popey> yeah
[09:14] <sil2100> I would also consider this as a bug
[09:14] <sil2100> But, let the designers say their word too ;p
[09:26] <Elleo> trainguards: the autopkgtests failed on xenial for this silo: https://requests.ci-train.ubuntu.com/#/ticket/887 I'm not sure it's anything to do with the package though (gets an Operation not permitted killing something related to lxc then shows a timeout), any ideas?
[09:27] <robru> Elleo: get pitti to retry it
[09:27] <Elleo> robru: okay, thanks
[09:27] <jibel> robru, could you port the 'retry' feature?
[09:28] <robru> jibel: yeah eventually. There's a lot of dots to connect
[09:28] <robru> jibel: also it'll be based on archive upload permissions, not silo build permissions
[09:31] <jibel> robru, okay, I don't know what it technically involves, but there are failures like this every day on armhf and pinging pitti is not the way forward, can trainguards retry jobs at least?
[09:32] <robru> jibel: nope, as far as i know it's only pitti. We're doing a sprint next week, not sure if we'll get to this but it's on the list
[09:33] <jibel> robru, thanks
[09:33] <robru> jibel: yw
[09:34] <Mirv> fixing the bottleneck of retrying autopkgtests would be very welcome indeed
=== chihchun is now known as chihchun_afk
[11:20] <sil2100> jibel: hey! Maybe you know: will we need the new libertine for 9.5 too?
[11:23] <Saviq> trainguards, please remove qtmir{,-gles} and unity-api from silo 19, we can't wait for mir to migrate ;/
[11:25] <jibel> sil2100, we need it
[11:26] <davmor2> sil2100: like the one I'm testing in silo 39
[11:26] <jibel> sil2100, I am not really concerned about it since there is no risk of regression so we should get the latest stuff for pd
[11:26] <jibel> of regression on the phone*
[11:31] <sil2100> Saviq: is mir making problems with migration?
[11:32] <Saviq> sil2100, well, *mir* isn't, our dummy qtmir test is
[11:32] <Saviq> (dummy == just build the packages)
[11:32] <Saviq> because it tried to build the released version against new mir (as Britney should), just that it couldn't work
[11:35] <jibel> sil2100, how do you keep track of the package to copy for 9.5?
[11:35] <jibel> +s
[11:44] <sil2100> Saviq: so its not using proposed, hm?
[11:44] <sil2100> Saviq: ok, let me remove those from the PPA then, just give me a minute
[11:44] <Saviq> sil2100, that's what changed recently - it only takes what's required from proposed, and the rest from main
[11:45] <Saviq> i.e. the "trigger"
=== _salem is now known as salem_
[11:49] <sil2100> jibel: currently O don't, I wait for the decision from Pat if we use the whole rc-proposed or not
[11:52] <jibel> sil2100, as of yesterday afternoon, he was okay to use rc-proposed then control what landed yesterday and today
[11:53] <jibel> sil2100, and the packages that landed since yesterday are all required for 9.5
[11:53] <jibel> so are all the silos we are verifying
[11:53] <jibel> sil2100, do you have the list of changes again?
[11:57] <sil2100> The ones in rc-proposed?
[11:57] <sil2100> I sent a pastebin link  hm, would need to find it
[11:58] <sil2100> Saviq: done a bit ago, could you remove those from the config?
[11:58] <Saviq> sil2100, just did
[11:58] <jibel> sil2100, nvm, found it
[11:59] <cjwatson> popey: well, my original design for the click database handled that correctly, and then I was overridden.
[12:00]  * cjwatson warned about exactly this problem </broken-record>
[12:01] <jibel> sil2100, I think it's fine to snapshot the overlay now and take the current state of rc-proposed. The only package which doesn't contain any fix for 9.5 is indicator-sound
[12:12] <popey> cjwatson, :(
[12:38] <Saviq> sil2100, can you please restart the failed unity8 builds in https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-019 they still pulled in the unity-api you removed from the PPA
[12:38] <Saviq> jibel, sil2100, cimi's verifying that silo, I'm travelling to Brussels now, so won't be around much until the evening
[12:40] <Saviq> it'd be good to get it into OTA 9.5, but as it stands now I'm not sure we'll make it in time, nothing's going according to plan
[12:49] <cjwatson> Saviq: done
[12:49] <cjwatson> (only amd64 and armhf; i386 had succeeded and the rest aren't relevant)
=== alan_g is now known as alan_g|lunch
[13:08] <sil2100> Saviq: is this landing which is required by the new framework we added?
[13:09] <rvr> kenvandine: ping back when available
[13:10] <cimi> sil2100, he might be travelling now, can I have some context so I can help you?
[13:16] <sil2100> cimi: so, regarding the unity8 landing for ota-9.5
[13:18] <kenvandine> rvr, pong
[13:18] <rvr> kenvandine: Hi
[13:19] <rvr> kenvandine: Do you know why krillin shows the bluetooth address but mako does not?
[13:19] <kenvandine> i don't know
[13:19] <kenvandine> but
[13:19] <kenvandine> dobey commented last night that bluetooth wasn't working for him on mako now
[13:19] <kenvandine> same with my flo
[13:19] <kenvandine> perhaps that's related?
[13:20] <sil2100> cimi: I somehow remember someone mentionjng that a unity8 landong was providing some new things that we want to make available in the new ota-9.5 framework
[13:21] <sil2100> Can't remember the context and don't have logs handy tho
[13:22] <kenvandine> rvr, do you see devices to connect on mako?
[13:23] <kenvandine> rvr, not a regression, i don't see the BT address on mako without silo 29
[13:24] <rvr> kenvandine: Hmm...
[13:24] <kenvandine> to be fair though we didn't see BT address on any device without silo 29
[13:24] <rvr> kenvandine: Let me check without the silo, this looks broken
[13:24] <kenvandine> not since the bluez5 transition
[13:25] <Saviq> sil2100, yeah, it would, but with the mir landing going in only now we didn't make it
[13:26] <Saviq> sil2100, so we'll have to create a new framework in rc-proposed before OTA10
[13:26] <Saviq> so that we have it in time for... you know what
[13:27] <kenvandine> rvr, i think this is bug 1530807
[13:27] <ubot5> bug 1530807 in indicator-bluetooth (Ubuntu) "Bluetooth cannot be activated on Nexus 7" [High,Confirmed] https://launchpad.net/bugs/1530807
[13:27] <kenvandine> rvr, with silo 29 i can see the BT address on my mako
[13:28] <kenvandine> rvr, but davmor2 said it's hit or miss on flo, depending on the flash
[13:28] <kenvandine> and there's some that suspect it also affects mako
[13:29] <kenvandine> rvr, http://people.canonical.com/~kenvandine/mako_bt_address.png
[13:30] <kenvandine> just now before installing silo 29 i didn't have the BT address
[13:30] <rvr> kenvandine: o_O
[13:30] <kenvandine> dobey, i saw yesterday you complained about bluetooth on mako, do you think you saw bug 1530807 ?
[13:30] <ubot5> bug 1530807 in indicator-bluetooth (Ubuntu) "Bluetooth cannot be activated on Nexus 7" [High,Confirmed] https://launchpad.net/bugs/1530807
[13:30] <Saviq> cjwatson, thank you
[13:31] <rvr> That's what I saw with the silo, the bluetooth couldn't be activated
[13:31] <kenvandine> rvr, yeah, same bug then
[13:31] <rvr> No indicator bluetooth, not visible
[13:31] <kenvandine> rvr, comment on that bug that you can confirm it affects mako too
[13:33] <rvr> Yeah, already done it
[13:33] <kenvandine> rvr, thx
[13:33] <kenvandine> rvr, davmor2 said it depends on the flash, like the state it was in when you flashed the device
[13:33] <kenvandine> so it doesn't seem to effect everyone
[13:34] <rvr> Let's see with this new reflash
[13:35] <rvr> Not bluetooth indicator by default...
[13:35] <rvr> No nothing
[13:36] <rvr> It did work yesterday :-/
[13:38] <kenvandine> yeah, i think now that it's broken it'll stay broken
[13:38] <kenvandine> my flo was fine last week too
[13:38] <kenvandine> not anymore :/
[13:38] <kenvandine> and i've flashed it several times with no luck
[13:41] <kenvandine> rvr, but that's not because of silo 29, so shouldn't block it
[13:46] <davmor2> kenvandine: the hybris landing killed bt on mako and flo
[13:47] <davmor2> kenvandine: flo was always a bit iffy but hybris done killed it good :)  blame morphis when he is back on Monday ;)
[13:49] <rvr> kenvandine: Ok, I'll continue testing then
[13:49] <davmor2> kenvandine, rvr: should be fine to test on krillin or arale till morphis fixes the hybris issue
[13:49] <rvr> davmor2: Sure
[13:49] <Elleo> sil2100: am I right in remembering something special had to be done when landing a silo that has a missing changelog version error? (there was a manual upload to xenial with a patch that's now in trunk, so it can be ignored safely): https://requests.ci-train.ubuntu.com/#/ticket/887
[13:51] <Saviq> jibel, I've put silo 19 in Lander: Approved to get Britney results asap, please wait for cimi's ACK before you guys jump on it
[13:54] <Saviq> jibel, need to go flight mode, be back around in ~1h
=== alan_g|lunch is now known as alan_g
=== chihchun_afk is now known as chihchun
[14:13] <rvr> kenvandine: "BT Devices of type smartphone shown as Other in the device panel". I have tried with another krillin and an iPhone, and I see no difference between OTA9 and silo 29, the icon is the phone. Which device did you use for "smartphone" type?
[14:27] <kenvandine> rvr, same icon for both
[14:28] <rvr> kenvandine: Yeah, I wanted to check the type "smartphone", but seems I don't have one
[14:28] <kenvandine> we treat the type the same for those
[14:30] <kenvandine> rvr, oh... wait
[14:30] <kenvandine> that fix isn't in the same silo
[14:30] <kenvandine> sorry
[14:30] <kenvandine> i'll land that bug fix separately
[14:30] <kenvandine> https://code.launchpad.net/~ken-vandine/ubuntu-system-settings/lp1534221/+merge/282623
[14:32] <kenvandine> rvr, i edited the landing, sorry about that
[14:32] <rvr> Ack
[14:32] <kenvandine> somehow i got both branches linked to that bug #
[14:37] <dobey> hmm
[14:53] <sil2100> Elleo: yeah, in that case you can build with the FORCE_REBUILD flag
[14:55] <Elleo> sil2100: it was the publishing stage I was wondering about, rather than the build stage, but it seems to be publishing fine
[15:05] <Saviq> robru, what do you think about adding a "In progress" state for lander sign-off, that will trigger Britney - this way both would happen in parallel instead of being queued
[15:22] <camako> trainguards, I think silo 10 (Mir 0.19) is stuck in proposed. Can you help plz? http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#mir
[15:22] <camako> looks like It's pulling in old mir, not the one that is contained in the silo.
[15:27] <rvr> kenvandine: Automated Signoff	Failed
[15:27] <rvr> kenvandine: Do you know why?
[15:28] <kenvandine> rvr, that's the autopkgtest for ubuntu-system-settings-online-accounts in xenial
[15:28] <kenvandine> fails all the time... i was just bugging dbarth_ about that :)
[15:28] <kenvandine> rvr, it's definately not related to system-settings
[15:28] <rvr> kenvandine: Ok :)
[15:28] <rvr> kenvandine: I approved the silo :)
[15:29] <kenvandine> thx
[15:29] <kenvandine> it's not even starting up during the test
[15:29] <jibel> not all the time otherwise it wouldn't be considered a regression
[15:30] <kenvandine> true
[15:30] <kenvandine> it happens often though
[15:30] <kenvandine> jibel, any ideas?
[15:30] <kenvandine> looks like it's failing to launch uss-oa
[15:30] <kenvandine> complaining about /proc
[15:31] <kenvandine> adt-run [09:22:44]: test autopilot: [-----------------------
[15:31] <kenvandine> grep: /proc/cpuinfo: Transport endpoint is not connected
[15:34] <jibel> kenvandine, no idea, I didn't look at the failure.
[15:47] <camako> sil2100,  Silo 10 (Mir 0.19) is stuck in proposed. Can you help plz? http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#mir
[15:47] <camako>  looks like It's pulling in old mir, not the one that is contained in the silo.
[15:48] <oSoMoN> trainguards: I marked silo 14 approved about 45mins ago, and the automated signoff hasn’t kicked in yet, known issue?
[15:59] <kgunn> slangasek: hey, is there someone about that might be able to help out camako ?
[16:04] <kgunn> camako: curious, why do you say "looks like it's using mir18 instead of 19" ?
[16:04] <kgunn> like where did you look to determine that
[16:04] <camako> kgunn, by clicking on the failures
[16:04] <kgunn> :)
[16:08] <kgunn> camako: but when i click and look, i see libmirserver37 installing which is mir19
[16:13] <kgunn> camako: oh wait...you're saying the mir is correct, but the qtmir is 0.4.7+16.04.20160122-0ubuntu1 and it should be using 0.4.7+15.04.20160127.1-0ubuntu1
[16:14] <kgunn> ....or 0.4.7+16.04.20160127.1-0ubuntu1 as the case my be
[16:15] <kgunn> sil2100: i pung slangasek, but no answer....who might know/be able to help ^
[16:15] <oSoMoN> trainguards: it’s been more than an hour and the automated signoff hasn’t kicked in for silo 14 yet, can you guys trigger it manually?
[16:15] <oSoMoN> or am I missing something
[16:15] <oSoMoN> ?'
[16:16] <kgunn> sil2100: in other words, if qtmir and mir are built and released together in the silo...shouldn't the autopkg tests use the qtmir src from the silo vs the one previously in archive?
[16:27] <oSoMoN> oh, automated testing finally running on silo 14
[16:27] <oSoMoN> whoever made it happen, thanks!
[16:33] <dobey> trainguards: hi, https://requests.ci-train.ubuntu.com/#/ticket/910 <- autopkgtests have been "Running" for over 24 hrs now. seems blocked on a test in progress marked "always failed" but which doesn't seem to still be running on the list of running tests
[16:34] <dobey> trainguards: can we do something to get this silo off to QA as it has an important fix for 9.5?
[16:40] <kgunn> trainguards: can someone at least kick off a retry of qtmir autopkg tests per
[16:40] <kgunn> http://people.canonical.com/~ubuntu-archive/proposed-migration/xenial/update_excuses.html#mir
[16:40] <kgunn> it's gumming up the entire train
[16:40] <kgunn> for ota9.5 landings
[16:42] <sil2100> kgunn: let me try that, not sure if I have the powers
[16:42] <camako> dobey, it's already received QA approval
[16:42] <dobey> camako: eh?
[16:42] <camako> it's now in proposed
[16:42] <camako> yep
[16:42] <dobey> camako: are we talking about the same thing?
[16:43] <camako> dobey, oh sorry
[16:43] <camako> haha
[16:43] <camako> I read the ticket number wrong
[16:43] <camako> never mind
[16:43] <cjwatson> kgunn,sil2100: I don't think it's that simple.  See Saviq's recent remarks on #ubuntu-devel
[16:44] <cjwatson> (I haven't been following exactly, but just want to avoid you wasting time repeatedly throwing it against the wall when it's already been analysed)
[16:46] <sil2100> dobey: hm, I guess in this case it would be best if you poke jibel
[16:46] <sil2100> dobey: they might try and pick up the silo nevertheless
[16:46] <sil2100> dobey: anyway, I guess robru would need to see this
[16:46] <sil2100> cjwatson: thanks!
[16:47] <dobey> sil2100: hmm, ok
[16:48] <dobey> alecu, jibel: ^^ can we get silo 005 through QA please? seems to be somehting causing ci train to be especially slow with this, and it seems hanged on waiting for always failed tests that are no longer running :-/
[16:48] <sil2100> ;/
[16:51] <jibel> dobey, sure, moved the card to the 'ready for testing' queue
[16:51] <jibel> someone will pick it up
[16:51] <dobey> jibel: thanks
[16:53] <slangasek> camako, kgunn: so the problem is that the packages from the silo can only be used together, but the autopkgtest from qtmir tries to check whether the new mir causes the qtmir in the archive to regress; to which the answer is "yes but that's irrelevant".  Yes, we know proposed-migration can't always do the right thing to ensure the packages from a silo are only tested together; there may be a cleve
[16:54] <slangasek> r way around this, but the only thing I can think of ...
[16:54] <slangasek> ... right now is for the release team to hint it in (which I'll do now)
[16:54] <sil2100> slangasek: thank you!
[16:55] <sil2100> Yeah, that makes sense
[16:56] <camako> slangasek, thanks
[16:58] <camako> This will cause problems going forward... As qtmir and mir are developed/released in lockstep. Be good to find a solution.
[16:59] <camako> ... like 'don't check for regressions in the archive version of qtmir if there is a newer qtmir landing along with the new version of mir'
[16:59] <camako> kgunn, saviq ^
[17:00] <sil2100> Funny we didn't have this before
[17:00] <camako> This applies to usc/mir also
[17:00] <camako> yes curious indeed
[17:05] <kgunn> slangasek: cjwatson thanks for the explanations
[17:05] <kgunn> and the help
[17:06] <cjwatson> sil2100: the pinning to test autopkgtests only against a subset of -proposed rather than everything in -proposed is relatively new
[17:07] <kenvandine> rvr, silo 29 has the BT smartphone fix
[17:10] <sil2100> cjwatson: ok, that would explain it, thanks :)
[17:11] <sil2100> We probably didn't have a mir release after it got deployed
[17:12] <slangasek> camako: the problem is that proposed-migration is not aware of silos, so has no definition of "alongside".  For now, just ping the release team (#ubuntu-release) to get a hint added for you, we should be able to unblock quickly
[17:13] <camako> slangasek, ack... Is the ping needed everytime this is encountered, or is this a one-time hint addition?
[17:14] <slangasek> camako: each time the problem hits, because hints are version-specific
[17:14] <camako> slangasek, ack. Thanks
[17:16] <camako> slangasek, so for silo10, we should expect migration happening soon? No action on my part?
[17:16] <sil2100> Didn't we have like some auto-hint for unity8 in the past? Can't remember the context
[17:18] <slangasek> camako: yes, should be automatic from here
[17:18] <camako> ok thx
[17:19] <dbarth_> sil2100: about oxide 1.12, could i get some grace time to have it go on monday?
[17:20] <dbarth_> sil2100: i'd like to have it in ota 9.5, now that i get a handle on updating cordova apps, but there is still a minor regression we're still confirming right now
[17:20] <dbarth_> sil2100: ie, there was a regression prior to #236 with the mobile spec, but that seem ok by now; just would like to get to the bottom of things to make sure there is no other skeleton there
[17:21] <dbarth_> (mobile spec = cordova mobilespec test app)
[17:25] <sil2100> dbarth_: hmm, I'm wondering about that, sadly we already have so many fixes queued up that I'm not sure if we'll be able to fit more
[17:25] <sil2100> The schedule is really tight
[17:26] <cjwatson> sil2100: you're probably remembering the specialised hack to pretend that unity8 exists on all arches
[17:26] <sil2100> jibel: ^ what do you think? I suppose with the current number of silos needed it would not be not wanted
[17:26] <sil2100> cjwatson: oh, yeah, probably that
[17:28] <jibel> sil2100, dbarth_ it's too late. what is the impact if it lands in OTA10?
[17:29] <dbarth_> jibel: security fixes, webrtc support
[17:30] <jibel> dbarth_, bug reports?
[17:32] <dbarth_> jibel: hmm, hang on
[17:33] <dbarth_> jibel: http://www.ubuntu.com/usn/usn-2825-1/ and http://www.ubuntu.com/usn/usn-2860-1/ mostly
[17:34] <dbarth_> the reason i've held oxide this week is the cordova regression we've now managed (mostly)
[17:34] <dbarth_> ie https://bugs.launchpad.net/cordova-ubuntu/+bug/1539151 (fixed in cordova itself)
[17:34] <ubot5> Launchpad bug 1539151 in Cordova Ubuntu "Cordova webview can start, but won't be made visible" [Critical,Fix released]
[17:35] <sil2100> oxide is big
[17:35] <dbarth_> i know
[17:35] <sil2100> By big I mean big in testing and risk
[17:35] <sil2100> hmmm
[17:37] <dbarth_> ota-9.6? ahem
[17:37] <jibel> dbarth_, new oxide so late it's really playing with fire. prepare a silo and we'll discuss on Monday with Pat
[17:37] <dbarth_> i mean we can't risk ota-9.5, but could have something ready just in case
[17:38] <dbarth_> jibel: yup, agreed, and ota-10 is not /that/ far also
[17:40] <jibel> dbarth_, maybe we'll have a 9.75 ;)
[17:53] <dbarth_> eh
[17:56] <oSoMoN> jibel, the silo with oxide 1.12.5 has been around (and tested) for a while (silo 48), it’s been held until now because of the cordova issue, but it’s not coming out of the blue just now
[17:56] <oSoMoN> (in case that makes a difference)
[18:30] <sil2100> mardy: hey!
[18:30] <sil2100> mardy: I would like to create a batch silo for gnome-control-center-signon and other 2 multi-arch-enablement-required projects and release those all together
[18:30] <sil2100> mardy: would that be ok?
[18:39] <oSoMoN> sil2100, jibel: is silo 14 on the list of expected landings for ota-9.5 ? (hint: it should be). autopkg tests are still running on it, I expected it’ll be ready for QA validation any minute now
[18:52] <sil2100> oSoMoN: yes :)
=== salem_ is now known as _salem
[19:07] <pmcgowan> sil2100, how goes it
[19:07] <sil2100> pmcgowan: OTA-9.5?
[19:08] <sil2100> pmcgowan: hah, well... not 'terrible' I would say, we landed silo 12, the new mir and a few other fixes, with others getting close to landing
[19:08] <sil2100> pmcgowan: unity8 will potentially land around Monday, otherwise I'll have to remove the framework from the images
[19:09] <pmcgowan> sil2100, assuming we can ship with full screen apps, not sure about that
[19:09] <sil2100> pmcgowan: jibel sent out a nice summary of the remaining work after the status meeting
[19:09] <pmcgowan> yes saw that
[19:10] <sil2100> But essentially QA will start testing after all is landed on Monday
[19:10] <sil2100> Hope we'll make it ;)
[19:10] <pmcgowan> we always seem to
[19:10] <sil2100> I know bfiller_ has a few apps scheduled, waiting for unity8 to land
[19:16] <Saviq> hey ppl
[19:18] <Saviq> jibel, silo 19 is good to go from our PoV, Britney is complaining about bug #1532358 and apparently we've not fixed one of our flaky tests well enough for it
[19:18] <ubot5> bug 1532358 in unity-scopes-shell (Ubuntu) "flaky autopkgtests cause migration issues" [High,In progress] https://launchpad.net/bugs/1532358
=== chihchun is now known as chihchun_afk
[20:11] <robru> Trevinho: gonna need you to commit http://launchpadlibrarian.net/235574546/unity_7.4.0+16.04.20151218-0ubuntu1_7.4.0+16.04.20151218-0ubuntu2.diff.gz to unity trunk
[20:15] <mardy> sil2100: hi! Certanly, that would be ok with me
[20:28] <robru> Saviq: I was asked specifically to require lander approval before involving britney because autopkgtest resources are quite limited.
[20:29] <robru> dobey: there's definitely some sort of issue with autopkgtests for unity8 in armhf. something is glitching out and causing them to be retried repeatedly. we're going to dive into that next week
[20:30] <robru> dobey: for now I'm making that change so that the train only waits for tests that can regress rather than considering RUNNING-ALWAYSFAIL as running, which should unblock your silo
[20:31] <dobey> robru: great
[20:31] <robru> but that's really just a bandaid because it's just luck that unity8 tests never passed. doesn't solve the underlying problem of autopkgtests being retried inappropriately
[20:32] <dobey> right
[20:32] <dobey> but it's a step in the right direction, since we shouldn't be blocking on always failed anyway
[20:33] <robru> dobey: oh wow, britney runs are currently taking 40 minutes each. so your silo should say 'Approved' in 80 minutes (40 minutes for the last run with old code to finish, plus another 40 minutes for the new run with new code)
[20:34] <dobey> robru: well, at last jibel moved put it in ready to test earlier, and alesage is testing it, it seems
[20:34] <robru> dobey: yeah, that's good. I just mean britney will approve it.
[20:35] <dobey> right
[20:35] <dobey> and i guess maybe create yet another card on trello
[20:40] <robru> probably
[21:17] <robru> dobey: well, as per usual, I rolled something out to production without testing it first and it exploded, now I'm rolling out a fix without testing it... happy friday!
[21:21] <dobey> robru: yay agile!
[21:22] <robru> dobey: can't spell fragile without agile!
[21:24] <robru> dobey: seriously though, my fix should have worked, but the rollout pulled in a new version of britney with incompatible changes that I wasn't anticipating so I had to fix that up separately
[21:57] <robru> oooh
[22:20] <dobey> robru: lol, looks like 941 there is already landed though
[22:20] <dobey> haha, and now there are 3 cards for 872 on the qa trello
[22:22] <robru> dobey: what makes you think 941 if landed? There's no record of it being published and its status is "built"
[22:22] <dobey> huh
[22:23] <dobey> oh, the bug is a lie i guess
[22:23] <dobey> https://bugs.launchpad.net/ubuntu/+source/ubuntu-system-settings/+bug/1534221/comments/1
[22:23] <ubot5> Launchpad bug 1534221 in Canonical System Image "BT Devices of type smartphone shown as Other in the device panel" [Medium,In progress]
[22:28] <dobey> robru: nevermind me then. i blame ken for not being able to manage the bugs properly :)
[22:28] <robru> Heh
[22:45] <dobey> yay; too bad i don't think i can publish it myself
[22:45] <robru> dobey: give it a shot and then if it needs an ack just find a core dev
[22:46] <dobey> robru: well i don't have upload privs, i mean
[22:47] <robru> dobey: right but if there's no packaging diff and no manual sources then anybody can publish
[22:47] <dobey> oh, i thought upload privs were required
[22:47] <dobey> in that case, i guess i will try then :)
[22:48] <robru> dobey: only if there's a packaging diff out a manual source
[23:19] <dobey> cool, i guess it worked
[23:19] <dobey> huzzah for robots
[23:33] <robru> yes that is a successful publish