=== chihchun_afk is now known as chihchun
=== chihchun is now known as chihchun_afk
=== chihchun_afk is now known as chihchun
[07:20] <imgbot> === IMAGE 184 building (started: 20150424-07:20) ===
[07:23] <Mirv> that was late
[07:29] <ogra_> yeah, recently they are all late, very weird
[07:30] <ogra_> oh, but this one was manual :)
[07:30] <ogra_> the cronjob is disabled it seems
=== chihchun is now known as chihchun_afk
[08:03] <sil2100> Yeah ;)
[08:04] <sil2100> I wanted to build this one yesterday night, but we lost internet access and I couldn't log into nusakan
[08:04] <sil2100> So I gave up and just did it in the morning
[08:19] <Mirv> hmm
[08:19] <mardy> Mirv: to debug the problem with silo 18, you could do "echo LoggingLevel=2 > ~/.config/signond.conf", then send me the syslog
[08:20] <Mirv> mardy: ok. I'm testing something else right now to workaround the problem, but writing that down.
[08:28] <Mirv> sil2100: tsdgeos: mardy: etc: hmm. I may have a workaround for #1421009, based on the unity8 boot loop test case ...
[08:29] <tsdgeos> Mirv: you mean seed the cache?
[08:29] <Mirv> tsdgeos: no.
[08:29] <Mirv> and you're not going to be impressed :D but... 30 reboots now solid.
[08:29] <Mirv> http://paste.ubuntu.com/10877014/
[08:30] <tsdgeos> he he
[08:40] <imgbot> === IMAGE 184 DONE (finished: 20150424-08:40) ===
[08:40] <imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/184.changes ===
=== mzanetti_ is now known as mzanetti
=== chihchun_afk is now known as chihchun
[09:04] <sil2100> Evil
[09:07] <sil2100> ...but we like evil
[09:08] <sil2100> Mirv: give me a sign what to test and how, I need to prepare my device
[09:09] <Mirv> sil2100: start with the Test Case I added in bug #1421009 description so that you can verify you can get the problem on an unmodified vivid. maybe after around 10-20 minutes (or earlier), you should notice it is not rebooting anymore, the script execution has stopped and if you check the device the unity8 lock screen has a black background and it's hanged (at least on my mako). note that "Unlock attempt 1 failed" is normal and happens on each boot
[09:09] <ubot5> bug 1421009 in qtbase-opensource-src (Ubuntu) "unity8 sometimes hangs on boot" [Critical,In progress] https://launchpad.net/bugs/1421009
[09:09] <Mirv> it's useful to know the bug we're fixing in the first place. meanwhile, I'm trying with lower values and will give the next piece of instructions when you're able to reproduce the bug
[09:10] <Mirv> ogra_: from what I can deduce, .override file is identical to a .conf file and simply is executed instead of the .conf file when .override exists?
[09:20] <mardy> Mirv: right, the networkmanager qt plugin uses dbus to talk to NetworkManager; the bug might be there
[09:20] <ogra_> Mirv, well, if you only put lines ther that exist in the .conf it will replace them ... i.e. you can just have an override with a "start on" stanza that replaces the default
[09:21] <sil2100> Mirv: the loop is to be executed on the desktop, right?
[09:21] <sil2100> Ah, right, I see adb commands
[09:21] <sil2100> So yes
[09:24]  * sil2100 executes it on vanilla vivid
[09:25] <ogra_> yummy, vanilla
[09:25] <ogra_> now you made me think about icecream !
[09:26] <davidbarth> o/ hello trainguards, could i get a reconfiguration of silo 22 please? (I swapped a branch for another)
[09:27] <Mirv> ogra_: oh, like section based? so I could have network-manager.override with only content http://pastebin.ubuntu.com/10877298/ ?
[09:27] <ogra_> Mirv, that should work, yeah
[09:27] <Mirv> mardy: yeah, this'd be the workaround for the original bug of unity8 hanging without affecting Qt DBus even though that means Qt DBus is still not multi thread safe (but the only real problem we know to have is so far the boot problem)
[09:28] <ogra_> (try it first indeed)
[09:28] <Mirv> sil2100: yes
[09:30] <davidbarth> ah no in fact i can reconfig myself; all good
[09:34] <sil2100> Mirv: so far vanilla vivid is looping pretty nicely, no hang for now
[09:34] <sil2100> chrisccoulson: ping
[09:35] <sil2100> chrisccoulson, davidbarth: hey guys, how's the work on 1.7.4 going?
[09:35] <sil2100> chrisccoulson, davidbarth: it seems QA can't sign-off oxide 1.7.3 due to the tab experience being completely broken
[09:35] <sil2100> chrisccoulson, davidbarth: so we would really need a fixed version today...
=== oSoMoN_ is now known as oSoMoN
[09:37] <Mirv> sil2100: I think it's really slow going in order to know if we have a fix for real. tsdgeos said 30 boots should be safe, but I'm not sure if they tested on arale (but then again, don't we have "1/10" reports on arale currently?)
[09:38] <sil2100> Mirv: not sure how many reboots it was right now, probably around 20, and so far it's still looping
[09:38] <sil2100> I'll let it go for 20 more minutes
[09:39] <Mirv> sil2100: ok, that's not really good news, since of course we'd need to be reliably to reproduce the problem in order to say there's a workaround
[09:39] <chrisccoulson> sil2100, a fix for what?
[09:41] <sil2100> chrisccoulson: davidbarth mentioned there's a hypothetical fix in the works for stability with many webviews
[09:42] <sil2100> chrisccoulson: since QA mentioned that webbrowser has really really broken tab functionality with 1.7.3, so I hoped this fix might help
[09:42] <chrisccoulson> sil2100, I'm not aware of that. I had an occasional browser crash which disappeared after updating my image, and trunk is a bit broken
[09:43] <sil2100> davmor2: ^ can you report the oxide issues you saw to chrisccoulson with details?
[09:43] <sil2100> Maybe those issues you saw are new and neither davidbarth or chrisccoulson saw those
[09:43] <davmor2> sil2100: yeap next bug on my list
[09:43] <chrisccoulson> it would be nice if people actually reported issues to me. I wasn't aware of it and there obviously is no fix if I'm not aware of it
[09:44] <davmor2> sil2100: oSoMoN commented on them
[09:44] <sil2100> chrisccoulson: I suppose it was something that was reported to oSoMoN or davidbarth
[09:44] <sil2100> davmor2: he didn't forward it to chrisccoulson then?
[09:44] <sil2100> Mirv: btw. did we have any confirmed cases of the hang happening on arale at all?
[09:46] <Mirv> sil2100: I guess we'll need to collect info. does ogra or jibel know? I thought "someone" has tested that arale randomly fails to boot / hang at unity8 lock screen.
[09:47] <Mirv> sil2100: comment #52 on the bug states that "I see this on normal boots of mako and arale; roughly 30% of the time...
[09:48] <Mirv> 30% is a lot, though, so I wonder if the test case is the best possible?
[09:48] <ogra_> i never see that
[09:49] <Mirv> the really, really original bug report states what we know that sometimes a test fails because of the boot issue, on krillin specifically
[09:50] <Mirv> tsdgeos: Saviq: so when you were executing the unity8 boot loop test case, was that mako/krillin/arale?
[09:53] <davmor2> chrisccoulson: sil2100 https://bugs.launchpad.net/ubuntu/+source/oxide-qt/+bug/1448010
[09:53] <ubot5> Ubuntu bug 1448010 in oxide-qt (Ubuntu) "Browser tab movement is jumpy and unpridicatble in 1.7.3" [Undecided,New]
[09:54] <tsdgeos> Mirv: mako
[09:54] <chrisccoulson> davmor2, but this is a webbrowser-app feature. Oxide doesn't have anything to do with the tab spread
[09:54] <tsdgeos> sorry my interwebs are awful today
[09:55] <davmor2> chrisccoulson: hmmm I wonder why it is so smooth in the older version then?
[09:56] <Mirv> ok I'll continue with my mako then anyhow, regardless of how it goes with arale
[09:57] <Mirv> sil2100: the removal of QML cache is supposed to simulate first boot from factory
[09:57] <sil2100> Mirv: so far no hangs
[09:57] <davmor2> chrisccoulson: let me have a play on krillin this morning I'l capture a video
[09:57] <Mirv> sil2100: I'm not really sure if that's good news or bad news ;)
[09:57] <sil2100> Yeah ;p
[09:57]  * sil2100 wants it to hang finally
[10:00] <chrisccoulson> oSoMoN ^
[10:01] <sil2100> Mirv: ah ha!
[10:01] <sil2100> Mirv: I think it happened!
[10:01] <Mirv> sil2100: five tries, script errors out, unity8 hanged?
[10:02] <sil2100> Mirv: ': Unlock attempt 1 failed, script output: 'Error: Timeout was reached - now the screen is on the main screen but without the libusermetrics wheel, just the clock and a black screen
[10:03] <sil2100> Consecutive unlock attempts fail
[10:03] <sil2100> Device unresponsive
[10:03] <sil2100> Ok, win
[10:03] <Mirv> sil2100: can you copy-paste the so far log to a file, then grep passed file | wc -l ?
[10:03] <Mirv> so we get the amount of reboots that were done
[10:03] <oSoMoN> chrisccoulson, davmor2: thanks, I triaged the bug accordingly, I don’t have my arale handy right now, but I’ll test and confirm this afternoon
[10:03] <chrisccoulson> oSoMoN, thanks
[10:04] <sil2100> Mirv: 57
[10:04] <davmor2> oSoMoN: checking on krillin too
[10:04] <Mirv> sil2100: ouch, that's awfully lot
[10:05] <sil2100> Well, might not mean anything, races involve probability and probability likes to be a jackass
[10:05] <Mirv> sil2100: then it's possible we don't really know if my workaround helps or not, even though on mako it'd generally happen quicker
[10:05] <sil2100> Mirv: let me spin it here then
[10:06] <abeato> trainguards, can I have a silo for lone 53?
[10:06] <abeato> s/lone/line
[10:07] <Mirv> abeato: ok
[10:07] <sil2100> Mirv: let me try with your workaround now
[10:07] <abeato> thx
[10:08] <Mirv> sil2100: yeah, just apply it manually for now, I haven't progressed on testing the .override etc
[10:09] <Mirv> sil2100: I'm not sure if it matters but it seemd the indentation is with tabs, so I did it similarly for those sleep lines
[10:10] <sil2100> Ok, running it now
[10:11] <Mirv> I now had only "sleep 1" and only after, not before, and got failures after 22 reboots. so I'm now going to be more systematic and getting a couple of errors without changing anything, and then try really hard with eg. sleep 2/2 or so. my original sleep 4/4 ran for about 50 boots, which is less than your arale (but arale might hit it less often, as reportedly 30 should be enough on mako)
[10:21] <sil2100> Mirv: I have bad news
[10:21] <sil2100> :<
[10:23] <sil2100> Mirv: the workaround seems to not work, after 17 loops it hanged
[10:24] <Saviq> Mirv, mako
[10:27] <davidbarth> sil2100: on that issue, there is no fix, cause the problem itself is not fully understood; we couldn't reproduce issues yesterday evening, apart from the oom_killer
[10:28] <davidbarth> while i was observing non-oom_killer related problems earlier in the afternoon with oSoMoN
[10:28] <sil2100> Things look better and better with our RC ;)
[10:38] <Mirv> sil2100: :( so it seems a) arale might be different beast, b) it's really fluctuating, and 30 reboots after all is not enough to test a fix, or even 50
[10:47] <sil2100> Mirv: http://paste.ubuntu.com/10877628/ this is my n-m.conf
[10:54] <Mirv> sil2100: looks similar to what I tested
[10:54] <Mirv> mmh, a bit frustrating, but I wonder if we understand enough of the problem, and if all the black background errors are caused by this problem or something else
[10:55] <Mirv> on my krillin rtm I had a reboot when I had similar unity8 hang / black background
[10:55] <Mirv> Saviq: tsdgeos: is there anything else that would be useful to check when the failure happens, to check whether we're hitting this DBus problem or something else?
[10:56] <tsdgeos> Mirv: gdb and see the backtrace
[10:57] <Mirv> tsdgeos: from the running process, or would it be ok to check the .crash file after it's generated?
[10:57] <Saviq> Mirv, if it rebooted then it's not the deadlock
[10:57] <tsdgeos> Mirv: it doesn't generate a .crash file
[10:57] <Saviq> Mirv, the deadlock does not cause a crash, so that must've been something different
[10:58] <Mirv> Saviq: what, my krillin example? I meant, after a reboot I once had a black background on krillin and a hang, I didn't check it further than eventually forced a reboot by pressing power button
[10:58] <Mirv> sil2100: do you still have it running or did you reboot? you could try gdb -p [pidofunity8] and bt
[11:00] <Saviq> Mirv, if you have a deadlock on boot, the only reason we know is dbus, but what tsdgeos said - attach when it's hung and see the trace
[11:00] <Mirv> tsdgeos: Saviq: anyway, for testing the eventual upstream fix, it seems 30 reboots is not enough, and not even 50. we don't know the upper limit of possibly passing reboots without changes.
[11:00] <Mirv> Saviq: ok, thanks
=== MacSlow is now known as MacSlow|lunch
[11:07] <sil2100> Mirv: still have it running
[11:07] <Mirv> sil2100: oh right your next run. I also started my next run already, the previous one on mako (without changes) failed after 30 reboots.
[11:08] <Mirv> it seems our previous test case was not good enough, so we need to have a real test case before any fix can be tested
[11:08] <sil2100> The bt:
[11:08] <sil2100> (gdb) bt
[11:08] <sil2100> #0  0xb621a620 in syscall () from /lib/arm-linux-gnueabihf/libc.so.6
[11:08] <sil2100> #1  0xb63cfe12 in QBasicMutex::lockInternal() () from /usr/lib/arm-linux-gnueabihf/libQt5Core.so.5
[11:08] <sil2100> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
[11:09] <Mirv> ah right still running as in still that failure there, nice
[11:09] <sil2100> Yeah ;)
[11:09] <Mirv> tsdgeos: is that ^ enough to validate that it's this dbus problem? clearly a locking problem but can we get the DBus visible some way?
[11:22] <davmor2> Mirv: does that mean we are back to landing QT7 to fix the world?
[11:24] <Mirv> davmor2: we're back to finding out what was the problem in the first place
[11:24] <davmor2> Mirv: :(
[11:25] <Mirv> when we have a test case, in addition to Qt 7 we might take my idea of adding a delay but apply it somewhere like for example inside unity8 before it calls usermetrics or NM or something
[11:25]  * sil2100 off to prepare lunch
[11:25] <sil2100> Mirv: indeed, that might make sense
[11:27] <Mirv> since the only known problem right at the moment is a boot time random failure
[11:29] <Mirv> tsdgeos: unping, I got a better retrace now on my mako which involves QDBus and I can improve the test case now
[11:31] <tsdgeos> sorry was busy elsewhere
[11:32] <Mirv> sil2100: if you're still there with the arale hang when you come back from lunch, try sudo apt install qtbase5-dbg libc6-dbg and backtrace again, and compare if you get the same QDBusDispatchLocker related line that I'll be adding to the bug test case
=== _salem is now known as salem_
[11:49] <sil2100> Mirv: installing packages while preparing roast
=== pete-woods is now known as pete-woods-lunch
[11:54] <sil2100> Mirv: yeah, I see it's locking on QDBusDispatchLocker indeed
[11:54] <sil2100> Let me pastebin the whole backtrace (bt, not bt full)
[11:56] <sil2100> Mirv: http://paste.ubuntu.com/10878086/ <- but I suppose you have the same
[12:04] <Mirv> sil2100: yeah, I updated the description, looks the same. now we at least have what to look for, but we'd need the upper limit of reboots that can happen without the problems seen. I'm currently guessing a 100, although it might be lower on mako (30 my maximum so far)
=== MacSlow|lunch is now known as MacSlow
[12:28] <Mirv> tsdgeos: if we follow up on the idea that Qt patching at this point still seems risky, and the only known problem is the boot time simultaneous DBus usage, can you think of as ugly hacks as mine inside Unity 8 that would eg separate Network Manager <-> usermetrics calls by delaying eg usermetrics? I can take care of all testing once I've the test case 100% proof.
[12:28] <Mirv> regression on boot time is less worse than the possibility of a deadlock
[12:39] <Kaleo> trainguards: need a silo for row 54 :) camera-app landing
[12:40] <Mirv> Kaleo: ok
[12:40] <Kaleo> Mirv, thanks!
[12:52] <Mirv> Kaleo: I don't where bot went but you got silo 011
[12:52] <Kaleo> Mirv, thank you
[12:53] <sil2100> tsdgeos, Mirv: keep me updated guys ;)
[12:55] <Mirv> sil2100: I'm currently just getting data on the upper limit of possibly successful reboots on mako without any changes. but it seems mako is slower at it than your arale :) I've only 3 runs now collected, and the current one is at 36 at the moment without problems.
[12:55] <Mirv> sil2100: btw, did you really mean to publish ubuntu-keyboard, ubuntu-system-settings to vivid in the morning...
[12:55]  * Mirv hopes w will open soon :)
[12:58] <sil2100> Aaaaa
[12:58] <sil2100> Ok, I'll never get used to checking the dashboard for the target
[12:58]  * sil2100 copies it over to the overlay PPA
[12:58]  * sil2100 sighs
[13:04] <sil2100> Fixed, that what happens when one publishes in haste
=== chihchun is now known as chihchun_afk
[13:08] <oSoMoN> ubuntu-qa: what’s the status of testing of silo 21 ? I understand that, given that it was already under review when the freeze happened, it still has a chance to land, is that correct?
[13:09] <rvr> Hmm
[13:10] <davmor2> oSoMoN: I think om26er is looking at it not sure he is on yet though
[13:10] <sil2100> oSoMoN: I think Omer is testing it
[13:10] <rvr> oSoMoN: om26er is not connected
[13:10] <sil2100> Don't see him around right now, but he's the one that has it on his plate
=== chihchun_afk is now known as chihchun
=== chihchun is now known as chihchun_afk
[13:59] <sil2100> davmor2, rvr: hey, any news on the ofono silo?
[13:59] <sil2100> Did they rebuild it and re-handed-over for testing?
[13:59] <rvr> davmor2: ?
[14:12] <oSoMoN> om26er, hey, what’s the status of testing on silo 21 ?
[14:12] <om26er> oSoMoN, in progress, I just signed in, Will be tested in an hour.
[14:13] <oSoMoN> om26er, thanks. you had questions yesterday, sorry I wasn’t around to answer them, did you manage to get everything answered?
[14:13] <om26er> oSoMoN, yes, Bill answered them later in the day but unfortunately I was near EOD then.
[14:13] <oSoMoN> ok
[14:15] <pmcgowan> oSoMoN, so per your last report the tabs behavior is not new?
[14:16] <oSoMoN> pmcgowan, correct, it exists on the current vivid-proposed image
[14:18] <pmcgowan> oSoMoN, so while thats not good, it would say to me we can land 1.7
[14:19] <oSoMoN> pmcgowan, yes, in any case it’s very unlikely that this issue is linked to oxide at all (the tabs list view uses image captures, not live webviews)
[14:19] <sil2100> Oh, it does?
[14:19] <sil2100> Then why didn't QA accept it?
[14:19] <sil2100> davmor2: ^ did you compare with webbrowser in the old oxide?
[14:20] <pmcgowan> oSoMoN, yeah I wondered about that
[14:21] <pmcgowan> more arale graphics dependent
[14:21] <sil2100> Then there's some serious misinformation going on here
[14:21] <oSoMoN> yeah, it really feels like something lower down in the graphics stack
[14:22] <pmcgowan> sil2100, I think just an assumption as not previously reported for some reason
[14:22] <pmcgowan> sil2100, so lets see if we can land that silo now
[14:23] <sil2100> davmor2, rvr, om26er: can we get anyone of you guys signing-off the oxide silo once again?
[14:24] <davmor2> sil2100: so silo16 is good to go as is if that is the consensus. it's only blocked due to the tab behaviour
[14:26] <davmor2> pmcgowan: ^
[14:27] <sil2100> Ok, setting it to signed-off and publishing
[14:27] <pmcgowan> davmor2, vg
[14:32] <sil2100> chrisccoulson: you have PPU rights for oxide, right?
[14:37] <cwayne> sil2100, did that unity-api fix for favorited scopes make it in?
[14:41] <sil2100> mandel: hey!
[14:42] <sil2100> mandel: http://bazaar.launchpad.net/~mandel/location-service/better-position-selection/revision/202 has not been built in silo 24
[14:42] <mandel> sil2100, triggering, sorry some docs updates and forgot
[14:42] <sil2100> mandel: it's a change in code, but this basically shouldn't require a re-test I suppose...
[14:42] <mandel> sil2100, nope, is just adding a const to a method and some typos
[14:42] <sil2100> mandel: anyway, let's rebuild and re-push
[14:44] <sil2100> Mirv, tsdgeos: any news on the hang by any chance? ;)
[14:45] <mandel> sil2100, is building already, sorry for that
[14:45] <sil2100> No worries, there was so many things today that I missed pinging you actually
[14:46] <tsdgeos> sil2100: i haven't been doing any of that today, left it in Mirv's hands
[14:46]  * sil2100 needs to AFK for a bit, bbl
[14:55] <Mirv> tsdgeos: did you note my question about workarounds 2.5h ago or did your network eat it?
[14:55] <tsdgeos> Mirv: that was me being at lunch and then not realizing, sorry :/
[14:56] <tsdgeos> Mirv: so i take delaying nm wasn't good?
[15:01] <Mirv> tsdgeos: yes, at least not enough on arale. plus, we might have over 50 reboots without problems currently so testing a fix or workaround would require a hundred or so.
[15:03] <Mirv> but given how the boot problem came to be, some workaround should be realistic
[15:04] <tsdgeos> i disagree
[15:05] <tsdgeos> Mirv: anyway delaying metrics is kind of hard
[15:05] <tsdgeos> since it's the first thing that you see on the phone
[15:05] <tsdgeos> delaying that is not a good idea i'd say
[15:18] <ogra_> sil2100, is there also a ringtone related rc blocker open currently ?
[15:18] <ogra_> (just got asked in  meeting)
[15:18] <Mirv> tsdgeos: a 1s delay in the right spot for example when NM is still initializing wouldn't too bad, but I'm open to any suggestions to avoid parallel qdbus usage during boot up
[15:19] <Mirv> tsdgeos: I'm not sure if nm is only called when indicators are shown, but optimally the deparallization would happen when ubuntu logo is still spinning.
[15:20] <tsdgeos> Mirv: no nm has nothing to do with the indicators in here, it's qt's internal nm backend, not the "indicator nm" backend
[15:21] <Mirv> tsdgeos: you know it the best, I was just guessing why they overlap
[15:21] <tsdgeos> Mirv: honestly i don't know much more than you
[15:22] <mandel> sil2100, build done successfully, no need to test the addition of const to a var
[15:28] <oSoMoN> trainguards: QA signed off silo 21, can it be published, please?
[15:28] <Mirv> tsdgeos: yeah, but you might throw some MP:s showing example how to affect unity8 calling things that call qdbus. the key would be to first have a bad workaround that works, and when we know we can have a workaround, we can think how the workaround could be non user visible. of course there may be other components besides u8 to tinker, like whatever calls qt nm backend (I thought it might be indicator)
[15:29] <tsdgeos> Mirv: i don't think i'll be able to work on that, i'm on london next week on a sprint
[15:30] <Mirv> tsdgeos: ok. of course all about prioritization at the end. I can try continue trying things I can think of.
[15:46] <oSoMoN> trainguard: ping? (re silo 21)
[15:46] <oSoMoN> I meant, trainguards
[16:23] <rvr> The team named '~ci-train-ppa-service' has no PPA named 'ubuntu/landing-026'
[16:23] <rvr> Hmm
[16:23] <robru> oSoMoN: done
[16:23] <rvr> robru: Have you changed anything or it is me?
[16:23] <robru> rvr: the ppa would be named 'landing-026'
[16:23] <oSoMoN> robru, thanks man!
[16:23] <robru> oSoMoN: you're welcome
[16:24] <robru> rvr: what tool are you using that gave that error?
[16:25] <rvr> robru: I updated yesterday to Vivid, so maybe my phablet-tools-citrain is not the correct one
[16:26] <robru> rvr: the version in vivid should be fine, I haven't touched that code in quite a while...
[16:26] <robru> rvr: what's the command you ran?
[16:26] <rvr> citrain device-upgrade 26 <passwd>
[16:30] <robru> rvr: hm it worked for me...
[16:31] <robru> rvr: where did the error come from? phablet-config? can you show me a paste of the command output?
[16:34] <rvr> robru: http://paste.ubuntu.com/10879757/
[16:36] <robru> rvr: what image is flashed on your phone? that sounds like you have an ancient version of add-apt-repository from before rtm split
[16:37] <rvr> robru: Thing is, this worked before
[16:38] <rvr> I was just reflashing to check an issue without and then with the silo
[16:39] <robru> rvr: right. so the thing is, nothing changed in citrain script in many many months ;-) citrain calls phablet-config, phablet-config calls add-apt-repository. So for some reason you got a version of add-apt-repository that doesn't understand ppa:team/distro/ppa-name syntax
[16:39] <rvr> Weird
[16:40] <rvr> Well, manually it works o_O
[16:43] <robru> rvr: https://pastebin.canonical.com/130321/ here's my paste, worked fine. that's on krillin, not sure what image number though
[16:47] <rvr> robru: launchpad connection is very slow, maybe is that
[16:47] <robru> mandel: https://code.launchpad.net/~thomas-voss/location-service/fix-1447161/+merge/257097 need this approved.
[17:00] <rvr> Approving silo 26
[17:08] <sil2100> Back
[17:10] <ogra_> rvr, were you looking into silo 02 before ... seems there is a wrong test plan and i cant log in to the spreadsheet to change it
[17:10] <sil2100> ogra_: what test plan should it have?
[17:10] <sil2100> I can change it
[17:12] <ogra_> "install the VibrateMe app, set vibration to 20sec ... suspend the phone via power button ... without fix it wont stop, with fix it will stop vibrating after the selected time"
[17:12] <ogra_> (the current test plan completely works around the usensord API we want to test by using sysfs)
[17:14] <robru> rvr: did you mark it in the spreadsheet?
[17:14] <sil2100> ogra_: modified o/
[17:14]  * ogra_ hugs sil2100 
[17:15] <ogra_> sil2100, did you see my ping in the backlog ?
[17:15] <sil2100> robru, rvr: I published silo 26, it's a critical
[17:15] <ogra_> ChickenCutlass, asked me about a ringtone bug he thought was an RC blocker
[17:15] <sil2100> ogra_: let me check that
[17:15] <ChickenCutlass> ogra_ yes pmcgowan has the bug number
[17:15] <ogra_> since i dont remember that being mentioned in the LT meeting i thought i'd betetr ask you :)
[17:17] <rvr> ogra_: silo 2 is alesage
[17:17] <sil2100> ogra_: hm, yeah, I don't see it in the priorities spreadsheet, but I remember seeing the bug somewhere before
[17:17] <rvr> robru: Yeah, I marked it
[17:17] <pmcgowan> https://bugs.launchpad.net/ubuntu/+source/telephony-service/+bug/1447606
[17:17] <ubot5> Ubuntu bug 1447606 in Canonical System Image " incoming call ringtone is not played repeatedly" [Critical,In progress]
[17:17] <ogra_> rvr, thanks ...
[17:18] <ogra_> sil2100, i guess we want that on the blocker list :)
[17:18] <alesage> ogra_, validating that now
[17:18] <ogra_> alesage, thanks
[17:19] <sil2100> Hah, I knew I saw this bug somewhere, but the title was misleading ;)
[17:20] <robru> oh, queuebot has been offline since noon yesterday
[17:20] <sil2100> Yeah, it's on the blocker list
[17:20] <ogra_> (likely needs krillin as this is the only device actually going to deep sleep)
[17:20] <ogra_> sil2100, awesome, thanks
[17:20] <ogra_> ChickenCutlass, all fine then
[17:20] <alesage> ogra_, that helps thanks
[17:20] <ChickenCutlass> great
=== robru changed the topic of #ubuntu-ci-eng to: Need a silo or CI Train support? ping trainguards | Need help with something else? ping cihelp | Train Dashboard: http://bit.ly/1mDv1FS | QA Signoffs: http://bit.ly/1qMAKYd | Known Issues: devel (vivid) touch landing gates now closed! queuebot is on vacation, please ping trainguards manually
[17:54] <sil2100> pmcgowan: the vibration fix just landed \o/
[17:55] <pmcgowan> sil2100, nice, just hit that this morning
[17:55] <sil2100> queuebot: welcome back!
=== robru changed the topic of #ubuntu-ci-eng to: Need a silo or CI Train support? ping trainguards | Need help with something else? ping cihelp | Train Dashboard: http://bit.ly/1mDv1FS | QA Signoffs: http://bit.ly/1qMAKYd | Known Issues: devel (vivid) touch landing gates now closed!
[17:56] <sil2100> pmcgowan: btw. what magic could you do to make tsdgeos and maybe some people from Unity8 help Mirv with the unity8 hang-on-boot issue?
[17:58] <sil2100> Since that's the biggest thing blocking us from testing, and I think it would require as many people possible working on this starting next week
[18:01] <pmcgowan> sil2100, agreed will see where I can find more eyes on it
[18:09] <cjwatson> heads-up, you may have problems publishing anything that started building in silos between about 13:26 and 17:59 UTC today due to us having to revert the switch to new-style ddebs until we fix a problem with it
[18:09] <cjwatson> #launchpad-ops internal if you need details
[18:09] <cjwatson> (I'm afraid I have to go and can't help further, but some information is better than none)
[18:12] <davmor2> sil2100: pmcgowan, abeato: after a rocky start silo 007 is good.
[18:12] <pmcgowan> yay
[18:16] <pmcgowan> abeato, do we need to tweak rtm silo 0 also?
[18:17] <ChrisTownsend> cihelp: Hi!  We've been seeing a weird failure on our 386 Unity CI runs.  For example: https://jenkins.qa.ubuntu.com/job/unity-vivid-i386-ci/95/console
[18:17] <ChrisTownsend> Notice that gdk is trying to open a Mir backend which is completely wrong.
[18:18] <wgrant> camera-app in https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-011/+packages will need to be rebuilt if it's heading for a primary archive.
[18:18] <wgrant> But it looks like it's headed for the overlay PPA, in which case it's fine.
[18:19] <wgrant> sil2100: ^^
[18:24] <mandel> robru, is approved, right?
[18:25] <sil2100> wgrant: yes, it's for the overlay PPA
[18:26] <robru> mandel: well, it wasn't at the time I pinged, but then sil2100 rammed it through
[18:26] <mandel> robru, ah, it should have, weird
[18:27] <sil2100> pmcgowan: thanks :)
[18:28] <sil2100> mandel: I overrode one unapproved branch as it was a blocker fix with high priority
[18:28] <davmor2> pmcgowan: if it has the same fix in for puk code yes
[18:28] <mandel> sil2100, perfectly ok, I though everything was approved, jhodapp went through both branches
[18:28] <pmcgowan> davmor2, yeah I am not sure
[18:29] <jhodapp> sil2100, mandel I had approved both branches
[18:29] <sil2100> jhodapp: there was a branch from tvoss that wasn't approved IIRC
[18:29] <sil2100> Anyway, all good now
[18:29] <jhodapp> sil2100, ok great
[18:30] <davmor2> pmcgowan: on a plus side I have a crapped out sim to test it with now
[18:30] <pmcgowan> its the little things
[18:31] <pmcgowan> davmor2, very funny btw, robot overlords
[18:31] <davmor2> pmcgowan: thought it would be appreciated :)
[18:35] <cjwatson> Ah, perhaps my publishing warning doesn't apply to vivid, because you're sending everything to the overlay PPA.
[18:35] <cjwatson> It will probably still apply to ubuntu-rtm/14.09.
[18:35] <cjwatson> And I see wgrant worked that out before me :)
[18:36] <cjwatson> wgrant: How did that work?  Presumably the overlay PPA has ddebs switched off too ...
[18:36] <cjwatson> Oh, the check is just for primaries isn't it
[18:38] <wgrant> cjwatson: Yes, it's just that I didn't want weird stuff in the primary archive that gets sent out to mirrors and blah.
[18:38] <wgrant> The check is really obsolete now that publish_debug_symbols is a flag.
[18:38] <wgrant> I may just remove the check on Monday.
[19:07] <ChrisTownsend> cihelp: Anybody available to help today?
[19:19] <fginther> ChrisTownsend, sorry about that. I'll have a look
[19:20] <ChrisTownsend> fginther: Ok, no worries, just didn't know if I should ping again on Monday:)
[19:20] <ChrisTownsend> fginther: And thanks
[19:29] <fginther> ChrisTownsend, I don't see anything obviously wrong just yet. I've kicked off a couple of test builds to see if something has gone wrong with that specific builder. Will get back to you when that's finished
[19:29] <ChrisTownsend> fginther: Ok, it's very strange.  I've seen this on 2 separate MP's only on 386.
[19:30] <fginther> ChrisTownsend, these builders are also used for mir, which made me think there was a possible process leak that caused the problem, but I don't see any evidence of that yet, it was just my first guess
[19:31] <ChrisTownsend> fginther: Ok, thanks
[19:44] <jhodapp> robru, can I please get a silo for line 55?
[19:44] <robru> jhodapp: one sec
[19:45] <jhodapp> k
[19:47] <robru> jhodapp: silo 2
[19:49] <jhodapp> thanks robru
[19:49] <robru> jhodapp: you're welcome
=== salem_ is now known as _salem
[21:44] <alecu> ping trainguards: hi! I'm trying to reconfigure ubuntu/landing-014, and I get this: """ERROR unity-scope-click was not in the initial list of components for that silo. Please ask the trainguards to reconfigure this silo for you."""
[21:56] <sil2100> alecu: hey! Yeah, we'll reconfigure it for you in a moment
[21:58] <alecu> thanks! but isn't it like 4AM in your timezone? you should have eowd already!
[21:59] <alecu> :-)
[22:04] <sil2100> Noo, it's midnight here, still early
[22:04] <sil2100> Although I need to go to sleep soon since I need to wake up in 7 hours for practice
[22:04] <sil2100> alecu: reconfiguring
[22:05] <cwayne_> sil2100, psh, who gets 7 hours of sleep :P
[22:06] <sil2100> cwayne_: hey, if I finish work now I won't be able to go to sleep straight away ;p
[22:06] <sil2100> I'll be lucky to be done with everything in an hour ;)
[22:06] <cwayne_> not with that attitude you won't
[22:07] <sil2100> I think I'll kick a new image in the meantime
[22:10] <alecu> thanks!
[22:15] <imgbot> === IMAGE 185 building (started: 20150424-22:15) ===
[22:52] <sil2100> o/
[23:35] <imgbot> === IMAGE 185 DONE (finished: 20150424-23:35) ===
[23:35] <imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/185.changes ===