[06:59] <tvoss_> good morning :)
[07:02] <tvoss> mandel, around?
[07:02] <tvoss> davmor2_, around?
[07:42] <mandel> tvoss, yes, tel me
[07:42] <mandel> tvoss, have we landed anythign?
[07:42] <mandel> anything*
[07:42] <tvoss> mandel, I patched out build-deps that are not in main, yet. Can you give the ppa a final spin?
[07:42] <mandel> tvoss, sure
[07:42] <tvoss> mandel, thanks
[08:25] <ogra_> sil2100, i have a DSL technician coming within the next hour ... so i wont be able to attend i guess (i will try but i thik i saw the car on the street already)
[08:25] <sil2100> ogra_: ACK
[08:26] <tvoss> stgraber, good morning
[08:27] <sil2100> tvoss: Stephane will most probably be up much later
[08:28] <tvoss> sil2100, ack and thx
[08:49] <sil2100> davmor2_: hi! Are you on holiday today?
[08:57] <psivaa> sil2100: https://bugs.launchpad.net/ubuntu-app-launch/+bug/1335778 for qmlscene crash
[08:57] <sil2100> psivaa: thanks!
[08:58] <psivaa> yw
[09:02] <popey> sil2100: where do bugs in snap decisions go?
[09:08] <sil2100> popey: hmmm... depends, unity8 is responsible for rendering those I guess, but it's not always true to target it instead of the project generating the snap-decision notification
[09:08] <sil2100> popey: what problem do you have?
[09:09] <popey> the colour of text in them is unreadable
[09:09] <ogra_> cjwatson, where to eth build logs hide nowadays (seems they are not mirrored anymore to people.u.c)
[09:09] <ogra_> *where do the
[09:09] <ogra_> (my god)
[09:09] <sil2100> popey: than I would target unity8 - I just hope nothing changed with that
[09:09] <ogra_> cjwatson, ah, ignore ... Laney helped
[09:10] <popey> sil2100: no, long standing issue I think, not regression
[09:22] <popey> sil2100:  bug 1335787
[09:23] <popey> I know you're a heavy social media user, would be good to get a confirmation ☻
[09:23] <sil2100> Me ;p ?!
[09:45] <sil2100> popey: in case davmor2_ is not around today... how busy are you today? Do you think you could do promotion-wise dogfooding in davmor2_'s stead?
[09:50] <popey> sil2100: if he's not about, sure.
[09:50] <popey> sil2100: which image?
[09:51] <sil2100> popey: I would say #105, it *should* have all the fixes for our blockers
[09:52] <sil2100> brendand: could you then do a quick look at the AP failures we're having and give us a sign if you think we shuoldn't promote the image because of those?
[09:53] <brendand> sil2100, ok
[09:54] <popey> sil2100: ok
[09:56] <sergiusens> popey: I think that bug is specific to friends; they choose the color
[09:56] <popey> interesting
[09:56] <popey> thanks sergiusens
[09:56] <jibel> hey, since a recent build (between 102 and 104) system logs are full of messages from healthd. I filed bug 1335748 . The message itself might be harmless but it makes the logs grow pretty quickly
[09:57] <brendand> sil2100, there seems to be a few tests missing. the normal test count is 857
[09:57] <sergiusens> jibel: right; there's a patch for that coming
[09:57] <brendand> sil2100, there are only 826 run
[09:57] <jibel> sergiusens, ok, thanks
[09:57] <davmor2_> Morning all
[09:58] <davmor2> sil2100: we looking at any image for promotion?
[09:58] <popey> sil2100: looks like I'm not needed? ^
[09:59] <davmor2> sil2100: I forgot to say I wouldn't be back in time for the meeting but would for the start of my normal hours
[10:01] <sil2100> ;)
[10:01] <sil2100> popey: yeah
[10:01] <sil2100> davmor2: hey! Yeah, #105 would need some love from a dogfooder
[10:01] <davmor2> sil2100: no worries
[10:02] <sil2100> brendand: hmmm, maybe the health tests are missing now?
[10:02] <tvoss> davmor2, ping
[10:03] <davmor2> tvoss: hello
[10:04] <tvoss> davmor2, could you give silo11 another spin? I patched out all the build-deps that are not in main (yet). Just to make sure that everything still works :)
[10:05] <davmor2> tvoss: I can once the testing for the dogfooding is done so it will be after Lunch
[10:05] <oSoMoN> sil2100, hey, can silo 2 be published, please?
[10:05] <tvoss> davmor2, ack
[10:06] <brendand> sil2100, oh yes, indeed
[10:10] <brendand> sil2100, i don't see anything specifically to block promotion. just ask davmor2 to do some particularly good dogfooding on terminal-app and address-book-app
[10:10] <sil2100> oSoMoN: one moment
[10:11] <davmor2> brendand: you're just not trying to break things then are you ;)
[10:11] <brendand> davmor2, no
[10:12] <davmor2> brendand: hahaha :)
[10:12] <brendand> davmor2, you're the one with the hammer
[10:14] <davmor2> brendand: I'll have you know I'm a professional I have a selection of hammers, toffee→Mjölnir :)
[10:14] <sil2100> oSoMoN: ok, I'm back from the phone
[10:14] <sil2100> oSoMoN: is this like a feature, or a bug-fix ;)? If it's a feature, is it a big one or a small one?
[10:15] <sil2100> (asking because we're in TRAINCON-0
[10:15] <sil2100> )
[10:15] <oSoMoN> sil2100, it’s a feature, that was there but had been disabled since the switch to oxide, and is now being re-enabled
[10:15] <oSoMoN> damn this stupid traincon0 state
[10:15] <sil2100> oSoMoN: how would you assess the regression risk of this?
[10:16] <sil2100> Yeah... we should get rid of it soon, if we'll be able to promote #105
[10:17] <oSoMoN> sil2100, given that the feature is fully autopilot-tested, and that the overall test coverage of the app is high, I would say the risk is low, but obviously I’m biased…
[10:18] <brendand> davmor2 rhymes with thor
[10:18] <brendand> kind of
[10:18] <brendand> if you drop the 2
[10:19] <davmor2> brendand: that's a stretch even for you :)
[10:19] <brendand> davmor2, what's that supposed to mean!
[10:21] <davmor2> brendand: You're QA so you are used to thinking outside the box but that is so far outta the box that the box is pinhole in the sky ;)
[10:21] <brendand> davmor2, what box?
[10:21] <brendand> ;)
[10:23] <davmor2> brendand: nice
[10:23] <asac> davmor2: hello
[10:23] <davmor2> asac: hello
[10:23] <asac> davmor2: is it true that the webbrowser AP failures are not reproducible on local device?
[10:24] <davmor2> brendand: ^
[10:24] <brendand> asac, i haven't been able to reproduce them yet
[10:25] <davmor2> asac: I've not seen any issues using the device day to day
[10:25] <asac> davmor2: well, i wondered if you managed to run the APs
[10:25] <asac> and have them fail
[10:25] <asac> you are not doing these at all?
[10:26] <asac> is selene still doing AP tests?
[10:26] <davmor2> asac: I don't run the AP's at all brendand is though hence pointing him at the question
[10:27] <davmor2> asac: brendand and elopio are the 2 main guys spearheading the AP test failures
[10:27] <asac> brendand: its odd that you dont see them
[10:27] <brendand> asac, are you expecting someone to be running the AP tests outside of CI?
[10:27] <asac> brendand: they are happening every day
[10:27] <asac> yes
[10:27] <asac> if folks claim that the APs are not reproducible
[10:27] <asac> then we have to double check that claim
[10:28] <brendand> asac, well the problem is we can't reproduce the exact environment they are run in
[10:28] <asac> i know, but its very close
[10:28] <asac> so we always should continue figuring the difference
[10:28] <asac> and close th gap further
[10:28] <brendand> asac, from what i understand there is a mere reboot between test suites
[10:28] <asac> right
[10:28] <asac> so that might be an angle
[10:29] <asac> what is key is that we get a way to reproduce them to the devs
[10:29] <asac> so they can fix
[10:29] <brendand> asac, so if the test suites aren't cleaning up properly the state then it could cause issues
[10:29] <asac> i could
[10:29] <asac> yes
[10:29] <asac> but is that the reason ? :)
[10:29] <asac> this thing is long enough broken reliable that we should really check out whats going on
[10:30] <asac> ogra_: there?
[10:30] <asac> brendand: so if the theory is that they fail because of dirt we can ask plars to make a special run that just makes a clean phone install and just runs this
[10:31] <asac> if we know its dirt then thats a step forward
[10:31] <brendand> asac, that would be a great idea
[10:31] <brendand> asac, best would be for each suite to have it's own device :)
[10:31] <asac> always continue to find out
[10:31] <brendand> not cheap i know
[10:31] <asac> well, you can dream, yes, but reality is what we have to deal with first
[10:32] <brendand> asac, but more seriously we can isolate the misbehaving ones
[10:32] <asac> if you see it not reproducible, the way to fix it is to debug and plars_ is at your command for that
[10:33] <asac> plars_: psivaa: can you guys can makea  run of the webbrowser-app AP happening
[10:33] <asac> on a clean install?
[10:33] <asac> e.g. just boot-and-install -> reboot -> webbrowser-app
[10:33] <psivaa> asac: ack, will do
[10:34] <asac> psivaa: cool. please let brendand and me know
[10:34] <psivaa> asac: ack
[10:34] <brendand> psivaa, we mean to have that permanently, not just once
[10:34] <psivaa> brendand: ohh?
[10:34] <brendand> psivaa, so on every run, webbrowser will have its own clean install and run
[10:34] <brendand> psivaa, yes
[10:35] <brendand> asac, correct ? ^
[10:35] <sil2100> Permanently?
[10:36] <sil2100> I wouldn't want that to be permanent, as this would mean we have a separate way of running webbrowser-app than others
[10:36] <sil2100> Which doesn't give good final results in comparison to other suites
[10:37] <davmor2> sil2100: I just noticed a minor regression in dialer app with dual calls but I'm assuming that isn't so important one call works fine :)
[10:38] <asac> brendand: we dont have that permanently right now.
[10:38] <asac> but doesnt matter for this case
[10:38] <asac> if in doubt you can always work with CI vanguards to get a clean rerun
[10:39] <asac> to check if thats the different
[10:39] <asac> its not perfect, but rest assure it's in the backlog somewhere and will get done eventually :)
[10:40] <asac> anywya, we want test suites to run through with and without clean or reboot in between
[10:41]  * sil2100 jumps out to the post office real quick
[10:41] <asac> sil2100: you like snail mail? :)
[10:41] <ogra_> asac, semi "there", yes
[10:42] <asac> ogra_: so you wear only 25% of your cloth? :)
[10:42] <asac> or lost your tobacco :P?
[10:42] <asac> lol
[10:42] <ogra_> heh, no, but i'm distracted by t-online
[10:43] <ogra_> (they messed up my SDSL two weeks ago ... had a tech. here but he didnt manage to get it back up yet)
[10:43] <asac> lock them in your cellar until its fixed
[10:43] <asac> :)
[10:43] <ogra_> heh, well, he is gone ... got to get a new one now :(
[10:43] <asac> see ... you should have locked him in right away
[10:44] <ogra_> yeah, to late
[10:44] <asac> ogra_: have you ever run APs lately?
[10:45] <ogra_> the last time was a while ago (and my test device currently has the new developer mode code on it, i wouldnt like to re-flash until i could land that after TRAINCON-0 is over)
[10:46] <ogra_> asac, bug 1334676 will get you weird results though
[10:46] <asac> ogra_: i have 95?
[10:46] <asac> (devel)
[10:47] <asac> oh we are in TRAINCON-0 already
[10:47] <asac> sil2100: is QA helping testing silos etc.?
[10:47] <ogra_> asac, you should have 87 i think
[10:49] <asac> ogra_: so since that you can reproduce AP test failures locally?
[10:49] <asac> since dbuss bug
[10:50] <ogra_> you need to use a special option that UTAH uses too
[10:51] <ogra_> asac, phablet-test-run -A '--timeout-profile=long' ...
[11:06]  * ogra_ gets off the phone and feels like killing someone
[11:07] <psivaa> brendand: asac: so the webbrowser test alone was run on a freshly flashed mako and the tests are still failing:
[11:07] <psivaa> http://q-jenkins.ubuntu-ci:8080/job/utopic-touch-mako-smoke-daily/373/consoleText
[11:07] <asac> right
[11:07] <asac> :)
[11:08] <psivaa> http://ci.ubuntu.com/smokeng/utopic/touch/mako/105:20140630:20140625/8793/webbrowser_app/
[11:08] <asac> i am sure if you download and run it locally it also fails
[11:08] <ogra_> likely
[11:08] <psivaa> :)
[11:08] <asac> well, folks tell me the are all not reproducible
[11:08] <ogra_> but dont forget -A '--timeout-profile=long'
[11:08] <ogra_> else it will fail for sure
[11:08] <asac> ogra_: whats that?
[11:08] <ogra_> see above
[11:09] <asac> why isnt that the default for phablet-flash?
[11:09] <asac> err phablet-testrun
[11:09] <ogra_> the workaround for bug 1334676
[11:09] <ogra_> because then your tests take 10x as long
[11:09] <ogra_> we dont want that as default
[11:09] <ogra_> but it works around the dbus timeouts
[11:10] <ogra_> (it is the default in UTAH for whatever reason)
[11:37] <sil2100> asac: yeah, I have asked om26er to fill in as our QA-sign-off person, but currently we seem to be ok
[11:38] <sil2100> As not many landings are ready to be released
[11:38] <sil2100> davmor2: how's the testing going so far?
[11:40] <davmor2> sil2100: dual calls has a regression you now can't seem to hang up on them other than that pretty good so far.
[11:40] <sil2100> davmor2: yeah, that one I saw you mention earlier, but well ;) I guess it's not super big - we would need a bug for that though
[11:41] <davmor2> sil2100: yeah as soon as I finish I'll write it up
[11:41] <sil2100> Thank you :)
[11:42] <davmor2> sil2100: might of just noticed another slightly more serious one though.
[11:43] <davmor2> popey: can you play a piece of music from the dash and tell me which speaker it plays out of please
[11:43] <sil2100> Crap...
[11:43] <davmor2> popey: same in the music app
[11:43] <popey> davmor2: the right one
[11:43] <popey> loudspeaker
[11:43] <davmor2> for me it seems to play out of the earphone
[11:44] <popey> same in music app, works as expected
[11:46] <davmor2> okay that was wierd so ear speaker, plug in headset remove headset no loud speaker so it was set to play through loud it just wasn't
[11:47] <davmor2> I wonder if switching loud speaker on and off in call were the cause of that
[11:48]  * davmor2 reboots and tries again
[11:48] <davmor2> nope reboot and it's playing in the ear speaker again
[11:51] <asac> sil2100: allright. dont relax the -0 approach
[11:52] <asac> if QA is a bottleneck its partly intended, but if its too much slow down let me know
[11:52] <sil2100> asac: ACK :)
[11:52] <asac> sil2100: at best coordinate with jfunk every time we start traincon-0
[11:52] <asac> or at least forward announce just about that to qa list
[11:52] <asac> thx
[11:55] <sil2100> asac: the traincon-0 was announced in the landing team on Friday, so it's not a shocker
[11:55] <asac> sil2100: right, its part of the normal mail
[11:55] <asac> we should send special mail just about that
[11:55] <asac> so i can forward and get proper attention etc.
[11:55] <oSoMoN> sil2100, hey, regarding silo 2, the packaging changes were acked by didrocks (see the MR)
[11:56] <asac> also since jfunk has to contribute significant engineers we should alywas coordinate with him that we do it etc.
[11:56] <sil2100> asac: ok, will send it out now, since basically today is the first day of TRAINCON-0
[12:01] <asac> cool
[12:01] <asac> sil2100: just a nice mail: TRAINCON-0 in effect
[12:01] <asac> :)
[12:10] <brendand> psivaa, it would be good to try and reproduce the conditions in which those tests were run locally
[12:10] <brendand> psivaa, is there a script or something that will do all the steps, including provisioning, setup etc
[12:10] <psivaa> brendand: yes, just a sec
[12:16] <psivaa> brendand: http://bazaar.launchpad.net/~ubuntu-test-case-dev/ubuntu-test-cases/touch/view/head:/scripts/provision.sh should do the provisioning
[12:18] <psivaa> and then http://bazaar.launchpad.net/~ubuntu-test-case-dev/ubuntu-test-cases/touch/view/head:/scripts/run-autopilot-tests.sh with -a webbrowser_app will run the webbrowser test
[12:18] <psivaa> brendand: http://bazaar.launchpad.net/~ubuntu-test-case-dev/ubuntu-test-cases/touch/view/head:/README-cli.rst has some information
[12:48] <brendand> psivaa, provision.sh doesn't run without a file called magners-wifi?
[12:51] <psivaa> brendand: yes, that was for the lab, in your local setup you could either modify provision.sh or run 'phablet-network -n $NETWORK_FILE'
[12:51] <brendand> psivaa, ok
[12:52] <psivaa> brendand: sorry, dint mention that
[12:52] <camako> sil2100, are you not assigning silos during TRAINCON-0 or is that indeed ok? I have one pending... row 25 :-)..
[12:53] <sil2100> camako: hi! I'm starting lunch now, that's why I didn't assign yet ;)
[12:54] <ogra_> camako, silos get assigned but need special QA team signoff and testing
[12:54] <camako> sil2100... was just curious... no hurry...
[12:54] <camako> ogra_, sure... was just gonna get a head start on testing etc... hoping TRAINCON-0 will not last very lng
[12:55]  * ogra_ hopes so too 
[12:55] <ogra_> :)
[12:57] <brendand> psivaa, why would i get 'unknow flag developer mode'?
[12:58] <psivaa> brendand: just a sec
[12:58] <brendand> psivaa, actually i probably need to upgrade ubuntu-device-flash
[12:59] <psivaa> brendand: that'd run 'ubuntu-device-flash --bootstrap --developer-mode --channel ubuntu-touch/utopic-proposed'
[12:59] <psivaa> which is what we are running in the lab. so yea you might need to upgrade that
[12:59] <brendand> psivaa, yeah got it now
[13:01] <tvoss> davmor2, ping
[13:01] <davmor2> tvoss: hello
[13:02] <davmor2> sil2100: okay so everything seems to work.   I don't understand the issue with the loud speaker/earpiece switch but I can't reproduce it
[13:03] <davmor2> sil2100: so just the hangup issue on dual calls that I will bug now
[13:09] <plars> brendand: yeah, you'll need a somewhat recent version of phablet-tools and ubuntu-device-flash
[13:10] <plars> brendand: psivaa: so what's the deal you and asac were talking about earlier with wanting a permanent clean run of webbrowser-app? It gets run on every single new image. If some other test is interfering with it, we should figure out how and fix that
[13:10] <plars> but I would doubt that a bit
[13:11] <psivaa> plars: yea, webbroser failed when ran on its own in tha lab
[13:11] <asac> plars: i dont want permanent clean run :)
[13:11] <asac> plars: i just wanted to get one clean run to eliminate FUD
[13:11] <asac> :(
[13:11] <asac> :)
[13:11]  * ogra_ wants permanent clean runs of all tests all the time 
[13:11] <plars> ok, that makes more sense :)
[13:11] <asac> plars: do you know when that reproducible failure started?
[13:11] <ogra_> pretty recently
[13:12] <asac> thats exactly not the answer i want :P
[13:12] <psivaa> asac: that was on image 92
[13:12] <asac> ok
[13:12] <psivaa> and we see a number of web related updates on that
[13:12] <asac> psivaa: and before webbrowser was "flaky"?
[13:12] <psivaa> asac: not really
[13:12] <asac> sil2100: ^
[13:12] <asac> psivaa: thanks
[13:12] <psivaa> we had failures before but not to this extent
[13:13] <psivaa> http://people.canonical.com/~ogra/touch-image-stats/92.changes
[13:13] <plars> asac: I mentioned last week that they had been failing for a bit, but due to the recent autopilot issues we decided on the landing call that it made sense to look at it after that fix goes in
[13:13] <asac> psivaa: did thowse failres before happen reliably?
[13:13] <ogra_> psivaa, i think it started in 91 already
[13:13] <ogra_> ah, no
[13:13] <ogra_> i'm wrong
[13:14] <asac> psivaa: have one example of the failures that happened for a while before?
[13:14] <psivaa> asac: let me check
[13:14] <ogra_> i dodnt think we had any for a while before 92
[13:15] <plars> 92/93 had a few failures, then 94 went back to 100%, then ever since then random numbers of webbrowser tests failing
[13:16] <ogra_> plars, right, but beofre 92 we didnt have any webbrowser failures for at least ten images (i didnt go back further)
[13:16] <asac> plars: so 94 was either a lottery win or we have the current problem starting 95?
[13:17] <plars> asac: I'd say the flakiness started at 92
[13:17] <psivaa> asac: 83,82,81 had failures before this, but they appear to be flaky
[13:17] <psivaa> http://ci.ubuntu.com/smokeng/utopic/touch/mako/83:20140616:20140530/8570/webbrowser_app/
[13:17] <ogra_> plars, asac, i wouldnt trust 94 results at all ... see the UITK test in there, it totally misbehaved
[13:17] <psivaa> asac: plars: since 92 the failures might be with different tests but atleast one fail everytime since then
[13:18] <ogra_> we got a new browser in 92 ... and with that it started to fail pretty reliable
[13:18]  * asac wonders where thomis cool dashboard feature ended up be
[13:18] <ogra_> asac, ++
[13:18] <ogra_> we really need that asap ... would be soo helpful right now
[13:18] <asac> oh i think it didnt allow to drill down to indiviudal tests?
[13:19] <asac> "where is thomi"? :)
[13:19] <oSoMoN> sil2100, re- silo 2, have you seen my message about packaging changes?
[13:19] <ogra_> it showed exactly the overview we want right now
[13:19] <asac> this guy has to move i am sure
[13:19] <asac> ChickenCutlass: do you have a big house where thomi could live until october? :)
[13:19]  * ogra_ doesnt mind if he has to do the drilling down on the old dashboard 
[13:19] <asac> oh i know the answer: ogra's house :P
[13:19] <ogra_> lol
[13:19] <ChickenCutlass> ha
[13:20] <asac> thats big and you can even do evening exercise
[13:20] <ogra_> he can have a tent in my garden (if he mows the lawn at least twice a week)
[13:20] <asac> moving things from A to B to T (trash) :)
[13:20] <asac> i think OZ folks know best how the sheep keep the gras low :)
[13:20] <ogra_> oh
[13:20] <asac> he might gain some weight finally :P
[13:21] <ogra_> he could bring a sheep or two ... susie would forever love him
[13:21] <asac> or be on sheep-diet :P
[13:21] <asac> you could offer that as a survival tour to rich people :P
[13:21] <ogra_> heh
[13:25] <asac> how is the sqlite regression going?
[13:25] <asac> ogra_: ?
[13:25] <ogra_> no idea
[13:25] <ogra_> not on my plate (i was busy the whole weekend with developer mode)
[13:26] <sil2100> oSoMoN: yes, I saw those :) QA needs to sign-off the silo still though
[13:26] <sil2100> oSoMoN: the packaging changes are ok
[13:27] <sil2100> oSoMoN: no worries, om26er_ is on it already
[13:27] <oSoMoN> sil2100, excellent, thanks!
[13:27] <om26er_> o/
[13:28] <brendand> psivaa, i think there are some steps missing. after provision, the wizard is up, and the image is not writable
[13:28] <ogra_> did you call phablet-config --writable-image ?
[13:28] <asac> sil2100: sqlite regression ... is that good now?
[13:28] <ogra_> (or however exactly this is called)
[13:29] <psivaa> brendand: it could be that provision.sh exited before it finish all it's steps because of the we dint setup the network config file
[13:29] <sil2100> asac: yes, it got fixed but with a unit test disabled
[13:29] <sil2100> asac: but thostr_ and others are working on the real fix in sqlite3
[13:29] <brendand> psivaa, no it exited with success
[13:30] <asac> sil2100: how did we get the sqlite3 changes that caused this?
[13:30] <asac> from debian as merge?
[13:30] <sil2100> asac: new upstream release has been imported into Ubuntu
[13:30] <ogra_> asac, right, merge/sync
[13:30] <sil2100> asac: doko did it, I guess it was a merge from Debian
[13:30] <thostr_> sil2100: asac: we're working on it, but fix won't be there unitl tomorrow (jamesh working on it)
[13:31] <asac> ic
[13:31] <thostr_> sil2100: asac: as sil2100 told me earlier this shouldn't block promotion for now
[13:31] <asac> thostr_: i dont care so much about when you do the fix, i care about you guys suffering :/
[13:31] <asac> :(
[13:32] <sil2100> thostr_: thanks!
[13:32] <psivaa> brendand: apologies, for that to be writable we should run provision with -w. now could you run 'phablet-config writable-image' pls
[13:32] <sil2100> camako: ok, silo assigned, but please wait with building it maybe for now
[13:33] <sil2100> camako: as platform-api should soon land from another silo
[13:33] <sil2100> camako: and you would have to rebuild anyway
[13:33] <sil2100> sergiusens: hi! Are you around? How's the silo 007 testing going?
[13:33] <camako> sil2100... thanks for the silo ... sure
[13:35] <popey> davmor2: how do you put music/video on your device?
[13:35] <popey> do you use mtp or adb push?
[13:35] <davmor2> popey: adb then change the permissions
[13:35] <popey> bah
[13:36] <davmor2> popey: sergiusens said to pick on somebody about the fact you couldn't do it via mtp
[13:36] <sil2100> davmor2, popey: so uploading music/video through mtp doesn't work now?
[13:37] <davmor2> sil2100: not for scripting you can manually
[13:37] <ogra_> sil2100, i think uploading 10TB of music/video doesnt
[13:37] <sil2100> Ah, ACK
[13:37] <sil2100> 10TB? Damn...
[13:37] <ogra_> these guys are crazy :)
[13:37] <davmor2> ogra_: I only have 4.2 GB of music
[13:37]  * sil2100 looks at his mako phone with disappointment
[13:38] <sil2100> I got the 'cheap' version of 16GB ;/
[13:38] <ogra_> you will love the BQ and Meizu ;)
[13:38] <ogra_> they have SD slots
[13:38] <sil2100> !
[13:38]  * sil2100 wants
[13:38] <popey> woah
[13:38] <popey> i copy very small amounts of music
[13:38] <davmor2> ooooooo la-de-dah
[13:38] <popey> it craps out every time
[13:38] <popey> serious issue, bug already filed
[13:38] <ogra_> popey, pnly 5TB ?
[13:38] <ogra_> *only
[13:38] <popey> pffft
[13:38] <ogra_> :)
[13:39] <popey> bug 1317263
[13:39] <sil2100> Woha, #15?
[13:40] <sil2100> NOTAREGRESSION
[13:40] <sil2100> Ship it
[13:40] <sil2100> ;)
[13:40] <popey> ☹
[13:40] <ogra_> it probably just doesnt like amy winehouse
[13:41] <sil2100> But anyway, jokes aside... damn, that's an old bug - why didn't anyone work on it?
[13:41]  * ogra_ guesses cyphermox_ has built in a filter so that you can only copy what he approves
[13:41] <davmor2> ogra_: No it's popey it'll be Led Zeppelin
[13:41] <popey> It was a cover.jpg in my case today
[13:41] <ogra_> what was on it ?
[13:42] <popey> A picture of my poking you with a stick.
[13:42] <sil2100> hah
[13:42] <davmor2> ogra_, popey: it's the porn filter killing the flesh tone on Electirc ladyland cover
[13:43] <ogra_> popey, see, that will *never* pass the content filter :)
[13:43] <popey> meanwhile.. back at the point.
[13:43] <plars> electric ladyland? what kind of music do you listen to davmor2??
[13:43] <plars> :)
[13:44] <popey> sil2100: it's very annoying, and while it's been around for a while, it would be very nice to get fixed
[13:44] <davmor2> plars: Nothing wrong with Jimi Hendrix
[13:44] <popey> is there a problem with gallery in devel? it wont load?
[13:44] <om26er> oSoMoN, which package provides webapp_container testsuite ?
[13:44] <sil2100> popey: yeah, I think it's time to finally get some attention on that, especially that we're slowly closing up things like adb and ssh
[13:44] <popey> asking on behalf of mhall119 who is afk
[13:45] <oSoMoN> om26er, webapp-container-autopilot
[13:45] <sil2100> So mtp will be the main way of pushing files to the device
[13:45] <ogra_> sil2100, right
[13:45] <davmor2> popey: Iirc I think it might actually be an issue in gvfs rather than mtp as such but I could be dreaming
[13:45] <plars> never heard of that one
[13:45] <popey> libmtp is what farts out the error
[13:46] <ogra_> well, you should be able to watch if mtp-server crashes
[13:46] <popey> davmor2: do you have a device running devel?
[13:46] <ogra_> while copying
[13:46] <davmor2> nope all on proposed
[13:47] <ogra_> popey, i do ...
[13:47] <popey> ogra_: is gallery broken?
[13:47]  * ogra_ sighs about the icons constantly re-ordering 
[13:47] <popey> 14:46:41 < mhall119> popey: hmm, logs say something about not being able to read image file formats
[13:47] <ogra_> popey, works
[13:47] <ogra_> (yes, i see the conversation)
[13:48] <popey> http://paste.ubuntu.com/7726525/
[13:49] <popey> thats what I get from mtp-server.log
[13:50] <cyphermox_> davmor2: popey: it definitely is mtp, not gvfs that crashes. in logs it clearly died
[13:50] <sergiusens> ogra_: I can mount and read with mtpfs
[13:50] <sergiusens> ogra_: but I can't write
[13:50] <cyphermox_> at least, in some logs I received back then
[13:51] <ogra_> sergiusens, works fine from nautilus
[13:51] <sergiusens> ogra_: yeah, I know
[13:51] <davmor2> cyphermox_: :(
[13:51] <sergiusens> ogra_: just doen't with plain old cli, mount and mtpfs
[13:52] <davmor2> cyphermox_: on a plus side though more work for you right? :D
[13:52] <ogra_> sergiusens, i never tried that
[13:56] <popey> command line?
[13:56] <popey> retro
[14:00] <sergiusens> popey: just like adb ;-) more for scripting purposes than anything else :-)
[14:00] <sil2100> sergiusens: hi! How's silo 007 going? :)
[14:01] <sergiusens> sil2100: the platform-api thing needs some fixing; fwiw, the ap slowness is not a usensord issue ;-)
[14:03] <sil2100> sergiusens: ok, so the fix for our issues is in platform-api then?
[14:04] <sergiusens> sil2100: yeah; autopilot tries to connect to the anonymous name created by the client connection
[14:04] <sergiusens> sil2100: it could be landable as is, but the examples would be broken
[14:06] <davmor2> sil2100: https://bugs.launchpad.net/ubuntu/+source/dialer-app/+bug/1335866
[14:06] <ogra_> yay, new bugs
[14:06] <tvoss> davmor2, ping again :) sorry, got distracted
[14:06] <sil2100> \o/
[14:06] <sil2100> davmor2: thanks :) I'll include it in the e-mail
[14:07] <davmor2> tvoss: moving over to to try it in a second
[14:07] <davmor2> sil2100: other than that I haven't hit anything massive
[14:07] <tvoss> davmor2, thanks
[14:07] <sil2100> davmor2: so... do you think you could give a +1 on promoting #105 then?
[14:08] <sil2100> davmor2: did you check webbrowser-app, terminal-app and address-book-app in more detail?
[14:08] <sil2100> As we had some failures there
[14:09] <davmor2> sil2100: no but I can
[14:09] <sil2100> davmor2: just to be sure that it didn't regress, as per brendand's proposition :)
[14:10] <davmor2> oh if the phone filps there is no header on terminal
[14:10] <ogra_> dont flip !
[14:12] <sil2100> Flipping is an unsupported feature... ;p
[14:12] <sil2100> j/k
[14:18] <davmor2> sil2100: do we know how the phones are positioned?  Are they stood upright or lying down?  If they are lying down terminal sometimes opens in portrait rather than landscape
[14:19] <sil2100> oh
[14:19] <sil2100> That's an interesting observation
[14:19] <sil2100> plars: can you give some input on this ^?
[14:19] <sil2100> I suppose they're standing?
[14:19] <ogra_> i think they do
[14:20] <plars> sil2100: I know this came up before the move, and they were positioned so that they were sitting upright
[14:20] <plars> sil2100: but a lot could have changed since then - rfowler_: do you know how they are currently positioned?
[14:21] <plars> sil2100: I know there are space constraints now that may have required him to do something different
[14:24] <sil2100> plars: it's just a theory, but maybe only a few devices are lying down? That could explain why it happens so rarely
[14:24] <plars> sil2100: so I just confirmed with someone in the lab, they are lying down flat
[14:25] <sil2100> plars: all devices?
[14:25] <plars> sil2100: yep
[14:25] <sil2100> plars: thanks :)
[14:25] <sil2100> davmor2: so, you might be right - it's anyway a bug in terminal then that the header disappears
[14:25] <davmor2> sil2100: might be deliberate to give more space
[14:27] <sil2100> I think we should run terminal-app autopilot tests with the phone in landscape explicitly
[14:27] <sil2100> And see if it's failing locally then
[14:29] <davmor2> sil2100: so in the 10 times I've opened the terminal app lay on my desk it has opened in portrait once but it might be happening more if there is a rack with stuff moving?
[14:29] <sil2100> davmor2: yeah, well, the terminal-app failures are happening rarely, not always, so I would suppose it might be the case
[14:29] <davmor2> \o/
[14:29] <davmor2> brendand: ^
[14:30] <sil2100> I mean, the theory makes sense at least
[14:30] <davmor2> screenshot would help with that :)
[14:30] <brendand> plars, that could explain a lot of stuff
[14:31] <sil2100> Actually, yeah, so I heard a screenshot feature is available in autopilot, so hm, why isn't it happening in the lab?
[14:31] <brendand> plars, we should make sure orientation is kept the same for all devices
[14:31] <brendand> plars, portrait probably
[14:33] <brendand> sil2100, it doesn't work on devices at the moment. it's being worked on
[14:34] <sil2100> Ah, k
[14:35] <rfowler_> plars: all the phones are back side down on shelves
[14:36] <plars> brendand: I don't think there's a lot we can do about that at the moment - but I really think there should be a way to lock it to an orientation if it matters for the test. It should not be used unless it really matters though as it can just conceal bugs (that would have been the potential here)
[14:49] <popey> fginther: the music-app build is pulling in the grilo binary, which shouldn't be needed anymore. is there some script behind the click package at http://s-jenkins.ubuntu-ci:8080/job/music-app-click/ which does this?
[14:50] <popey> fginther: http://s-jenkins.ubuntu-ci:8080/job/music-app-click/lastSuccessfulBuild/console i see mv x/usr/lib/arm-linux-gnueabihf/qt5/qml/org ../install_dir/lib/arm-linux-gnueabihf/ which shouldn't be done...
[14:53] <fginther> popey, the only thing the jenkins job does is add the core-apps PPA, there's no script being executed. just the package build
[14:54] <popey> fginther: see the bottom of that log file, it manually copies in a binary
[14:54] <fginther> looking
[14:54] <om26er> oSoMoN, Hi! the selection is working in the browser but the selector is not intuitive, but I guess this silo is only meant to test if its really working
[14:54] <fginther> popey, ah, thanks for correcting me
[14:55] <popey> fginther: np, we have a bug for it.  bug 1335764 - I assigned you, feel free to reassign if that's not right
[14:55] <oSoMoN> om26er, yeah, it’s only re-enabling the feature as it existed before, it’s not meant to improve it
[14:56] <om26er> oSoMoN, ok, I QA ack'd the silo. :)
[14:56] <fginther> popey, I've disabled the mv, and rebuilding.
[14:56] <oSoMoN> om26er, QA-thanks!
[14:56] <davmor2> sil2100: so for me browser, terminal and addressbook all seem fine
[14:57] <popey> thanks fginther
[15:00] <elopio> fginther: I need you for like three different things this week.
[15:00]  * elopio stands in the line to receive fginther's blessings.
[15:00] <fginther> elopio, we have a vanguard :-)
[15:01] <elopio> fginther: it's for the two jobs that you were working on. The one for ubuntu_experience_tests and the one for unity-click-scope. Can the vanguard access them too?
[15:02] <fginther> elopio, right now some of that work is tied up on my desktop :-(. I'll figure out a way to spread this around
[15:03] <elopio> fginther: thanks.
[15:05] <sil2100> davmor2: excellent, so in overall... a +1 from you on promotion :D?
[15:06] <davmor2> sil2100: so the phone is in no worse a state than it has been as far as I can tell :)
[15:07] <sil2100> \o/
[15:07] <sil2100> ogra_: I think it's time to risk it and promote our first 5.3 enabled image
[15:07] <ogra_> oh my
[15:07] <ogra_> sil2100, i will show up at yur home if something stops working, mind you ! :)
[15:07] <sil2100> ogra_: it's not a perfect one, but davmor2 gives a +1 from dogfooding and brendand gave a +1 on the AP front
[15:07] <davmor2> ogra_: don't sound so shocked you know qt5.3 fixes the world
[15:07] <sil2100> Oh noes!
[15:08] <ogra_> (i'll bring a beer)
[15:08] <sil2100> #blamedavemor2andbrendandnotme!
[15:08] <ogra_> :)
[15:08]  * sil2100 runs away from responsibility
[15:08] <sil2100> ;)
[15:08] <davmor2> sil2100: blame popey (TM)
[15:08] <ogra_> in a meeting atm will promote right afterwards
[15:08] <sil2100> ogra_: thanks!
[15:22] <davmor2> tvoss: tests running
[15:38] <ogra_> sil2100, davmor2, which image was that again (my upstairs client misses the backlog)
[15:39] <davmor2> ogra_: 105
[15:39] <sil2100> ogra_: 105
[15:39] <ogra_> thx
[15:39] <ogra_> promotion running ...
[15:40] <ogra_> [15:44] <sil2100> Thanks :)
[15:46]  * asac shiver about his very own clumsiness
[15:46] <asac> i really put my headset to the left of me into my coffee mug :)
[15:47] <asac> promoted?
[15:47] <ogra_> read backlog :P
[15:47]  * ogra_ points to the line with the three equal signs 
[15:48] <asac> ogra_: yeah, thats why i asked :)
[15:48] <asac> wondered if there might have been a typo
[15:48]  * asac updates
[15:54] <ogra_> sigh ... first boot afterupgrade is unbearable long
[15:56] <ogra_> wow, that were severasl minutes
[15:56] <ogra_> hmm
[15:56] <ogra_> and the welcome wizard ...
[15:56] <ogra_> then another boot animation ..
[16:20] <davmor2> mterry: did you say there was a bug for the keyboard not appearing straight away after the welcome screen is run?
[16:22] <mterry> davmor2, uh...  I can't find it now
[16:22] <mterry> I don't remember
[16:23] <davmor2> mterry: no worries I'll report a new one then and we can always dupe it
[16:25] <ogra_> zbenjamin, are you still working on the fix for the sdk test (where qtsensors5-dev needs to be renamed, we talked about it a week ago and were wondering when the fix will land)
[16:27] <zbenjamin> ogra_: zoltan told me he can do that, so i did not follow up on that
[16:27] <zbenjamin> ogra_: i will ping him tomorrow about it
[16:27] <ogra_> zbenjamin, can you at least make sure it doesnt get forgotten in your team ?
[16:28] <ogra_> thanks :)
[16:28] <ogra_> thats enough :)
[16:30] <davmor2> sil2100: https://bugs.launchpad.net/ubuntu/+source/ubuntu-keyboard/+bug/1335917
[16:34] <sil2100> davmor2: thanks ;)
[16:42] <popey> blimey, we promoted 105?
[16:43] <ogra_> popey, so we did
[16:51] <brendand> sil2100, silo007 at least does what it's meant to do :)
[16:51] <sil2100> brendand: you  tested it? ;)
[16:52] <brendand> sil2100, to make sure it fixes the bug, yes
[16:52] <sil2100> \o/
[16:52] <sil2100> Thanks!
[16:54] <kgunn> Ursinha: ....not sure but we may be experiencing same prob as last week
[16:54] <kgunn> Ursinha: <alan_g> kgunn: Data point: autolanding https://code.launchpad.net/~afrantzis/mir/fix-1332632-input-for-resized-surfaces/+merge/224575 took 5 hr 30 min to fail. (That long because of waits for mako we've discussed before.)
 We now have 5 MPs queued to land. - five hours each is more than a day.
[16:55] <kgunn> any help to speed this up, we will be grateful
[16:55] <kgunn> ev_: ^^ just fyi
[16:55] <ogra_> kgunn, slow autopilot ?
[16:55] <Ursinha> kgunn: let me look
[16:56] <ogra_> kgunn, thats what brendand is referring to above ...
[16:56] <alan_g> Ursinha: it looks like slow turnaround on mako queue
[16:56] <alan_g> (As per topic)
[16:57] <ogra_> sil2100, you need to update the channel topic ;)
[16:57] <kgunn> ogra_: you saying there's a bug fix coming to address this ?
[16:57] <sil2100> ogra_: righto', after the e-mail ;)
[16:57]  * kgunn must go eat/run
[16:57] <ogra_> kgunn, if it is the same issue that slows down smoketesting it will be fixed with silo 7 landing
[16:58] <Ursinha> alan_g: yeah, I'm reading an email fginther sent on Friday describing the problem, might be related to that
[16:59] <kgunn> ogra_: thanks...i think we may be experiencing something diff
[17:06] <robru> stgraber, https://ci-train.ubuntu.com/job/landing-011-2-publish/ can I get you to ACK these two packaging diffs?
[17:11] <davmor2> ogra_: you were saying that the orientation sensor is off when it is lay down flat.  How does the app know what orientation to be in then?
[17:12] <stgraber> robru: NAK, this will break a bunch of packages
[17:12] <robru> ok
[17:12] <ogra_> davmor2, i didnt say off, but it has a pretty massive threshold now so you need to tilt it pretty heavily for having it pick up a change
[17:12] <stgraber> robru: libubuntu-location-service0 => libubuntu-location-service1 without rebuilding all the rdepends of libubuntu-location-service0 to transition to libubuntu-location-service1
[17:12] <ogra_> davmor2, ricmm has details (since he did the fix)
[17:13] <robru> stgraber, ok thanks, i noted that in the spreadsheet
[17:16] <davmor2> ricmm: if the phone is on it's back and the terminal app is opened some times it opens in portrait instead of landscape we are wondering what might cause this and if there is a way to get info on it.  It seems that all the lab devices are lay on their backs and we are wondering if this is causing some of the flackiness in testing.
[17:19] <ricmm> davmor2: in what orientation would you deem the phone is if on its back?
[17:19] <ricmm> other than "on its back"
[17:21] <davmor2> ricmm: I have no idea and I'm assuming the apps and phone don't either.
[17:24] <ogra_> ricmm, default
[17:24] <ogra_> if it has been freshly installed and gotten no event yet i woould expect it to be in default oriantation
[17:25] <davmor2> ogra_: default for video would most likely be portrait and not landscape
[17:27] <ricmm> it should be defaulting tho, not moving
[17:28] <ricmm> davmor2: so you reproduced it? with latest?
[17:29] <davmor2> ricmm: yeah I'm not sure if it is flackiness in the app, a setting or a sensor though.  But I opened terminal 10 times and 1 time about 5-6 in the terminal opened in portrait rather than landscape
[17:30] <davmor2> ricmm: I can try it with other apps if you want but that will have to wait till tomorrow I have enough on my plate today
[17:52] <ricmm> davmor2: we can talk about it tomorrow
[17:53] <ricmm> thats certainly odd as there should be *no* orientation events coming through when the sensor starts
[17:53] <ricmm> until it gets out of the "flat" state
[17:53] <sil2100> o/
[17:53] <ogra_> well, probably the app does the wrong thing with the orientation data
[17:54] <ogra_> mangles it or some such
[17:54] <ogra_> i cant imagine its the sensor api
[18:03] <davmor2> ogra_, ricmm: Indeed but it still happens I'll have a play with it tomorrow on a few apps and see what happens in other apps.
[18:04] <ogra_> bah
[18:04] <ogra_> lightdm just crashed here
[18:04] <ogra_> (on 105)
[18:05] <davmor2> ogra_: why are you breaking this now ;)
[18:05] <ogra_> dunno, i only swiped in the launcher
[18:05] <ogra_> and got the boot animation ...
[18:05] <davmor2> what the never seen that
[18:06] <ogra_> session restarted fine ...
[18:26] <robru> oh ho ho!
[18:26] <robru> stgraber, ^ is this your doing?
[18:29] <stgraber> robru: yep
[18:29] <robru> stgraber, pretty slick!
[18:29] <stgraber> I'll add silo state monitoring later today too
[18:30] <robru> stgraber, ah, I was just going to ask if it was already at feature parity or still under development ;-)
[18:31] <stgraber> robru: it's weird that it triggered on line 17 though, unless someone either flipped the ready flag on/off or cleared request-id for some reason
[18:31] <robru> stgraber, one warning, on a couple occaisions the google spreadsheet has become irreparably corrupted and required starting over with a totally new spreadsheet, so don't hard-code the URL in too many places because it might need to change periodically ;-)
[18:31] <stgraber> yeah, it's a global variable at the top of the plugin, that's easy enough to change
[18:31] <robru> stgraber, yeah, that's not a bug in queuebot, that's a bug in the spreadsheet or the jenkins merge job or something. the other bot also pinged that line 17 was ready when it really just landed. for some reason the 'landed' flag got lost, i set it manually
[18:32] <stgraber> the bot will basically show that message every time a line is marked as ready and doesn't have a request-id already, I could do a few extra checks but when things go normally, that shouldn't be required
[18:32] <robru> stgraber, nah it shouldn't be necessary, whatever cleared the request id should be identified and fixed (i have no idea)
[18:34] <stgraber> what I'll land later today is another simple queuebot plugin that'll monitor http://people.canonical.com/~platform/citrain/ and anytime the status of one of those changes will print the old status and new status and who's the lander, that should be a good first start
[18:37] <robru> stgraber, oh, EXCELLENT. yes the spreadsheet is basically rubbish, that json backend is much more accurate and updates faster. your bot will know status changes before our bot does ;-)
[18:37] <robru> stgraber, spreadsheet is only really necessary for new requests and whether or not a request is testing: pass
[18:50] <tvoss> stgraber, hey there :)
[18:51] <tvoss> robru, ping
[18:51] <robru> tvoss, hiya
[18:52] <tvoss> stgraber, looking at your comment on silo11
[18:52] <tvoss> stgraber, would you mind elaborating?
[18:54] <tvoss> robru, perhaps you can help me to understand the packaging NAK on silo11 from stgraber?
[18:54] <robru> tvoss, let me reread it, one sec
[18:55] <robru> oh right
[18:55] <robru> tvoss, so you have to find out what packages depended on libubuntu-location-service0, and then rebuild them all against libubuntu-location-service1.
[18:58] <robru> tvoss, so these guys:
[18:58] <robru> http://paste.ubuntu.com/7727812/
[19:03] <tvoss> robru, so that's ubuntu-touch and ubuntu-desktop-next then
[19:03] <robru> tvoss, and mir?
[19:04] <tvoss> robru, why mir?
[19:04] <robru> tvoss, isn't libubuntu-application-api-mirserver1 part of mir?
[19:04] <tvoss> robru, no, it links against mir
[19:05] <robru> ah
[19:05] <robru> tvoss, ok, so just update those seeds then
[19:05] <tvoss> robru, the seeds? I have *never* done that before
[19:06] <tvoss> ogra_, ^ can you help here?
[19:06] <robru> tvoss, yeah, ubuntu-touch is a seed, also i'm assuming ubuntu-desktop-next is a seed but i never saw that one before
[19:07] <robru> tvoss, although hmmm, the seed probably is not specifying -service0 directly, but pulling it in indirectly, so I'm not sure how to update that
[19:07] <tvoss> rsalveti, around?
[19:09] <robru> tvoss, good people to poke might be xnox or cjwatson (and of course ogra_) according to https://launchpad.net/ubuntu-seeds but I don't know that much about it, sorry
[19:10] <tvoss> robru, thanks
[19:10] <robru> tvoss, you're welcome
[19:11] <ogra_> tvoss, robru hmm ?
[19:12] <robru> ogra_, ok so stgraber gave a packaging NAK on the diff in silo 11, citing rdeps need to be rebuilt. but the rdeps are just seeds so we're not sure how to proceed
[19:12] <ogra_> so your api bumped ? ... that means find all the revers build-deps (note, not the deps) and prepare a silo with all the packages in it
[19:12] <tvoss> ogra_, that is the case for silo 11, for reverse-build-depends
[19:13] <robru> ogra_, http://paste.ubuntu.com/7727812/
[19:13] <ogra_> robru, right, we will then need to chnage the seeds too s/-0/-1/ thats trivial, just land it and i can change the seeds then
[19:13] <ogra_> robru, reverse *build*-depends ...
[19:13] <robru> oooog
[19:14] <robru> ogra_, is there a command for that?
[19:14] <tvoss> robru, reverse-build-depends?
[19:14] <tvoss> :)
[19:14] <ogra_> grep-dctl
[19:15] <robru> hm, ok. didn't see it under apt-cache :-P
[19:15] <ogra_> err grep-dctrl
[19:15] <ogra_> grep-dctrl -FBuild-Depends  libubuntu-location-service-dev  -sPackage /var/lib/apt/lists/*Sources
[19:15] <ogra_> i suppose that one could work (not sure, untested)
[19:16] <robru> ogra_, ok, so that command comes up with platform-api but the 'reverse-build-depends' command came up empty
[19:16] <robru> although the empty one was because I searched -service0 instead of -service-dev
[19:16] <robru> ok
[19:17] <robru> tvoss, ok so you need to rebuild platform-api ;-)
[19:17] <ogra_> right
[19:17] <robru> but that one's already in the silo
[19:17] <ogra_> and i can only update the seeds *after* the package is in the archive proper
[19:17] <robru> ogra_, so I think it looks good then
[19:17] <tvoss> robru, I did, see the silo
[19:17] <robru> tvoss, right
[19:17] <robru> ok i'm publishing this
[19:19] <ogra_> tvoss, ping me tomorrow morning (that will take a while to migrate from -proposed) and remind me to bump the version in the seed
[19:19] <robru> ogra_, ok, it's published.
[19:19] <tvoss> ogra_, ack and thx
[19:20] <robru> ogra_, thanks!
[19:20] <ogra_> np
[19:41] <stgraber> robru: I've got a basic silo monitoring tool now, I'll keep it running here for a little while to make sure it works fine and then will turn it on for the channel
[19:41] <robru> stgraber, sweet
[19:56] <robru> I dunno, a new camera-app icon? that sounds like a big landing, I think we'll need QA signoff and extra testing here
[19:56] <robru> bfiller, you got silo 2
[19:58] <bfiller> robru: actually scratch that, sorry (: I don't need the silo for the camer-app, was about to delete the line
[19:58] <bfiller> this is going to land in another silo
[19:59] <robru> bfiller, ah ok
[19:59] <bfiller> sorry about that
[19:59] <robru> bfiller, no worries!
[20:12] <t1mp> fginther: are there any updates on the slowness of jenkins? It still seems to take >9h (still waiting) to land an approved MR, see https://code.launchpad.net/~tpeeters/ubuntu-ui-toolkit/101-headerActionsDeprecationWarning/+merge/224965
[20:13] <t1mp> with 'land' I mean 'merge into our staging branch' :)
[20:21] <stgraber> robru: waiting for you to process that one ^ :)
[20:22] <stgraber> oh, nevermind
[20:35] <fginther> t1mp, the fix is in flight (in a silo and fairly urgent). I'm going to try to move around some resources to help. The backlog is not improving today
[20:43] <stgraber> robru: we should now have basic silo tracking, I guess I may have to patch it a bit later to shorten some of the state messages, we'll see
[20:47] <t1mp> fginther: ok, thanks. So it should be fixed in a few days?
[20:48] <fginther> t1mp, oh yes
[20:48] <t1mp> great, thanks
[20:48] <t1mp> elopio: hello
[20:48] <t1mp> elopio: can you review the updated tests in this MR when you have time? https://code.launchpad.net/~tpeeters/ubuntu-ui-toolkit/110-headerInput/+merge/224994
[20:49] <t1mp> elopio: ah, you did before I asked you :)
[21:10] <boiko> robru: hi, would it be possible to get a silo assigned to line 28?
[22:14] <cjwatson> Hm, I guess https://jenkins.qa.ubuntu.com/job/click-devel-utopic-amd64-ci/14/? means that somebody merged https://code.launchpad.net/~cjwatson/cupstream2distro-config/click-coverage/+merge/225055 maybe?
[22:37] <camako> robru, do you know why I'm getting the following :
[22:37] <camako> https://ci-train.ubuntu.com/job/landing-006-1-build/78/console
[23:01] <cjwatson> fginther: https://jenkins.qa.ubuntu.com/job/click-devel-utopic-amd64-ci/14/? - were you applying some hook changes locally?  see https://code.launchpad.net/~cjwatson/cupstream2distro-config/click-coverage/+merge/225055
[23:02] <cjwatson> Looks like a slightly different hook list there