[07:26] <Mirv> alex-abreu: not top approved MP https://code.launchpad.net/~abreu-alexandre/webbrowser-app/context-menu-to-overlay-webviews/+merge/282489
[07:35] <robru> Mirv: ^^ oh, amazing. two silos both with webbrowser-app went through QA.
[09:02] <pete-woods> hey folks, cojld I get a packaging ack for:
[09:02] <pete-woods> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_39a8dbb93caf4ec889f8a1b7f69885db/bileto-872/2016-02-12_14:33:42/vivid/libqofono/packaging_changes.diff
[09:02] <pete-woods> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_39a8dbb93caf4ec889f8a1b7f69885db/bileto-872/2016-02-12_14:33:42/vivid/indicator-network/packaging_changes.diff
[09:02] <pete-woods> this is to make ofono an optional dependency of indicator-network / libqofono
[09:03] <pete-woods> as both apparently handle it fine, and it eases cross-building
[09:09] <pete-woods> traininguards: ^
[09:09] <sil2100> pete-woods: hey! Let me take a look in a moment :)
[09:09] <pete-woods> thanks
[09:22] <sil2100> pete-woods: ok, looks goodish, I checked that we have ofono-scripts in the seeds so ofono should be still pulled in correctly in touch
[09:22] <Mirv> pete-woods: traininguards :D
[09:22] <Mirv> I first thought my hilights setup is broken
[09:25] <davmor2> Mirv: no just pete-woods ability to type, that makes be worry for his code :D
[09:26] <Mirv> dbarth: two silos went through QA but couldn't be published - https://requests.ci-train.ubuntu.com/#/ticket/893 had multiple commits to indicator-datetime done after the latest build in the PPA, and https://requests.ci-train.ubuntu.com/#/ticket/955 has MP not approved plus also needed a rebuild since unity-webapps-qml + webbrowser-app was in QA at the same time and were published
[09:27] <pete-woods> ha!
[09:27] <pete-woods> fortunately I use an IDE with auto-complete
[09:27] <pete-woods> wheras I IRC like I talk
[09:27] <pete-woods> i.e. without extensive review
[09:28] <dbarth> Mirv: ah, let me check that
[09:28] <dbarth> Mirv: yeah, the indicator-datetime is due to unit tests being added; i checked with charles
[09:32] <Mirv> dbarth: right, so just get them retested (unit tests changes of course shouldn't change anything) and sign them off again
[09:37] <dbarth> Mirv: ack
[09:40] <dbarth> Mirv: there is also a branch to make it xenial+vivid compatible
[09:40] <dbarth> Mirv: i assume the result will have to go through qa again, right (and unfortunately)
[09:40] <dbarth> so can i add this one as well, re-test myself and hand that over to qa?
[09:40] <dbarth> wdyt?
[09:40] <dbarth> this the packaging branch: https://code.launchpad.net/~charlesk/indicator-datetime/unified-eds-code/+merge/284789
[09:41] <Mirv> dbarth: yes, I think it makes sense if you're fairly sure it doesn't then fail QA because of that new branch
[09:42] <dbarth> Mirv: nope, but i'll need to update the silo definition to re-target both vivid and xenial
[09:46] <pete-woods> trainguards / davmor2: hi guys. my silo that fixes the ARM crash in libgcrypt doesn't seem to be making its way into the QA dash (https://requests.ci-train.ubuntu.com/#/ticket/978). am I doing something wrong?
[09:46] <pete-woods> oh wait,  the "automated signoff" is still running
[09:46] <pete-woods> and apparently has been for a while now (since last week)
[09:49] <Mirv> pete-woods: can you bring pitti with https://requests.ci-train.ubuntu.com/static/britney/vivid/landing-070/excuses.html about the ppc64el ones being stuck?
[09:49] <Mirv> s/bring/ping/
[09:50] <Saviq> sil2100, hey, I've verified the fix in https://requests.ci-train.ubuntu.com/#/ticket/1001 - train is unhappy because of autopkgtest but that's because those packages are missing a lot compared to trunks
[09:50] <Mirv> pete-woods: it's good to raise it up indeed if stuff seems stuck when looking at the excuses link from the ticket page
[09:50] <Saviq> sil2100, so AFAICT can be copied to emergency snapshot
[09:51] <pete-woods> Mirv: okay, will do
[09:51] <sil2100> Saviq: hey! I already copied it during the weekend ;) Risky, but I wanted QA to be able to start, allowing a re-spin if anything is b0rken
[09:51] <sil2100> Saviq: thanks for testing it!
[09:51] <Saviq> sil2100, oh ok
[09:52] <Saviq> sil2100, not really risky, was QA'd already before adter all
[09:52] <Saviq> *after
[09:56] <Mirv> rhuddie: can you give me details on autopilot OSK bug? I mean the bug number / workaround
=== vrruiz_ is now known as rvr
[09:59] <rhuddie> Mirv, i think this is the one you want: https://bugs.launchpad.net/ubuntu/+source/ubuntu-keyboard/+bug/1542224
[10:00] <ubot5`> Launchpad bug 1542224 in unity8 (Ubuntu) "[regression] OSK suppressed in autopilot tests" [Critical,Triaged]
[10:01] <rhuddie> Mirv, if you want to work-around it, you could try killing maliit-server, in which case the simulated keyboard should be used rather than OSK when you use the textfield write() method
[10:05] <Mirv> rhuddie: ok, thanks for the workaround information too
[10:07] <rhuddie> Mirv, no problem
=== _salem is now known as salem_
[11:19] <dbarth> Mirv: hey, on another front, there was https://requests.ci-train.ubuntu.com/#/ticket/923 which is blocked, probably due to an oxide multi-arch wait-dep
[11:30] <Mirv> dbarth: the excuses page explains that u-s-s-o-a has a dependency on oxide qml plugin on arm64, powerpc, ppc64el and s390x where oxide however is not available
[11:31] <Mirv> dbarth: maybe the dependency should be on [amd64 armhf i386] only but u-s-s-o-a still building on the other archs?
=== chihchun is now known as chihchun_afk
[13:33] <rvr> Saviq: Hi
[13:34] <Saviq> rvr, uh oh! :)
[13:34] <Saviq> rvr, how can I help?
[13:36] <Mirv> Saviq: is QA the bringer of bad news usually? :)
[13:36] <rvr> Saviq: I'm testing silo 51
[13:37] <rvr> Saviq: When you tested "Dash doesn't accept input (appears frozen) after youtube scope auth", did account freeze after login?
[13:38] <Saviq> rvr, no, everything seemed fine
[13:38] <Saviq> Mirv, when they ask you questions during testing of your silo ;)
[13:40] <rvr> Saviq: Well, right now, Accounts freezes after login in the YouTube scope, on screen with "Google" and the spinner.
[13:40] <rvr> Tested in frieza and krillin
[13:41] <rvr> Saviq: Also there is at least one "phone" mention left in the wizard, for Location, but don't know whether it is intended or not.
[13:42] <Saviq> rvr, that page comes from the here terms, will follow up with the custom image
[13:43] <Saviq> rvr, and will check the freeze in a moment
[13:43] <rvr> Ok
[14:05] <rvr> Saviq: It also freezes without the silo
[14:06] <rvr> mardy: ping
[14:07] <mardy> rvr: pong
[14:07] <rvr> mardy: Are you aware of a freeze problem with Google?
[14:07] <mardy> rvr: ah, I just read the backlog
[14:08] <mardy> rvr: yes, bug 1544063
[14:08] <ubot5`> bug 1544063 in webapps-sprint "UI freezes when trying to log in from youtube scope" [Critical,In progress] https://launchpad.net/bugs/1544063
[14:08] <rvr> mardy: Ah, then it is not fixed with the silo
[14:08] <mardy> rvr: for an unlucky alignment of the stars, we are affected by two different types of freeze
[14:09] <rvr> Bug #1534541: Dash doesn't accept input (appears frozen) after youtube scope auth
[14:09] <ubot5`> bug 1534541 in unity8 (Ubuntu) "Dash doesn't accept input (appears frozen) after youtube scope auth" [Critical,In progress] https://launchpad.net/bugs/1534541
[14:09] <rvr> mardy: Oh
[14:09] <mardy> rvr: the silo fixes a freeze when a trusted session ends; but then there is another freeze (well, technically it's just OA waiting undefinitely) in OA
[14:10] <rvr> mardy: I see!
[14:10] <rvr> mardy: Well, I guess one silo must land before the other
[14:10] <mardy> rvr: do you have another google account? as far as I've been told, not all accounts are affected by the latter freeze
[14:10] <rvr> mardy: Yes, I have a number of them for tests
[14:10] <mardy> rvr: you could try another one
[14:11] <mardy> rvr: or actually, the description of bug 1544063 contains a fix which you can apply yourself
[14:11] <ubot5`> bug 1544063 in webapps-sprint "UI freezes when trying to log in from youtube scope" [Critical,In progress] https://launchpad.net/bugs/1544063
[14:12] <rvr> Yeah, one liner
[14:12] <mardy> rvr: if you change that line, and things work fine, then you can safely land silo 51
[14:12] <rvr> Good idea
[14:22] <pete-woods> ^ woot!
=== bpierre_ is now known as bpierre
[14:31] <rvr> mardy: Saviq: It works with the OA's patch :)
[14:32] <rvr> Even without the silo :P
[14:46] <rvr> Saviq: How can I check the splash spinner? Not sure what is it.
[14:46] <Saviq> rvr, when you launch an app, the orange spinner in the center
[14:47] <rvr> Saviq: Ack
[14:47] <Saviq> rvr, before, it showed up straight away, now only after 2s (so in theory if app started within 2s, it won't show)
[14:47] <rvr> Saviq: I see
[15:41] <Saviq> rvr, you said FAIL on the youtube thing on silo 51, that's cleared up now is it?
[15:43] <rvr> Saviq: Yes, cleared
[15:43] <Saviq> ack
[16:09] <rvr> Saviq: Silo approved
[16:09] <Saviq> rvr, thanks!
[16:10] <Saviq> sil2100, FYI ↑
[16:10] <sil2100> \o/
[16:10] <sil2100> Wooo!
[16:10] <sil2100> Just one silo left, publishing
=== chihchun_afk is now known as chihchun
[16:11] <sil2100> Saviq: the mir inside the silo was to make britney happy, right?
[16:12] <Saviq> sil2100, correct, not needed any more
[16:20] <sil2100> Saviq: the silo is publishing now, just taking its sweet time while checking unity8 merges
[16:20] <sil2100> Annoying that it takes so long
[16:21] <Saviq> sil2100, it's published
[16:21] <sil2100> https://ci-train.ubuntu.com/job/ubuntu-landing-051-2-publish/10/console <- not yet
[16:21] <Saviq> sil2100, yeah, robru said those status jobs only run every 15 mins, simply because they take 10mins to run...
[16:21] <Saviq> $ apt-cache policy qtubuntu-android
[16:21] <Saviq> qtubuntu-android:
[16:21] <Saviq>   Zainstalowana: 0.60+15.04.20150318-0ubuntu3
[16:21] <Saviq>   Kandydująca:   0.62+15.04.20160111-0ubuntu2
[16:21] <Saviq>   Tabela wersji:
[16:21] <Saviq>      0.62+15.04.20160111-0ubuntu2 0
[16:21] <Saviq>        1100 http://ppa.launchpad.net/ci-train-ppa-service/landing-046/ubuntu/ vivid/main armhf Packages
[16:21] <Saviq>  *** 0.60+15.04.20150318-0ubuntu3 0
[16:21] <Saviq>          50 http://ports.ubuntu.com/ubuntu-ports/ vivid/universe armhf Packages
[16:21] <Saviq>         100 /var/lib/dpkg/status
[16:21] <Saviq> sil2100, it is ↑ ;)
[16:22] <sil2100> Strange!
[16:22] <sil2100> ;)
[16:22] <sil2100> Ok, me goes afk in that case
[16:22] <sil2100> brb
[16:23] <Saviq> sil2100, re: platform-api, a new one was already in the snapshot, so that's what qtmir built against and pulled it in anyway, but it works fine with that
[16:38] <Saviq> robru, oop? https://ci-train.ubuntu.com/job/ubuntu-landing-051-2-publish/10/consoleFull
[16:38] <Saviq> could that be mir after all?
[17:01] <Saviq> sil2100, you around? https://ci-train.ubuntu.com/job/ubuntu-landing-051-2-publish/10/console failed, I'd say because of mir after all, could you remove from silo and re-publish?
[17:33] <Mirv> Saviq: the silo 51 apparently has wrong info in it about it having mir while it has not, thus the publish failed
[17:33] <Saviq> Mirv, well, it does (did?) have mir in it
[17:34] <Mirv> Saviq: did, I guess, nothing to be seen https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-051/+packages it says "ready to build"
[17:34] <Saviq> sil2100, did you remove mir from that silo ↑?
[17:34] <Mirv> Saviq: there's no mir MP:s in the request either
[17:34] <Mirv> so it doesn't feel like the mir would be in that silo
[17:34] <Saviq> Mirv, they were there to make britney happy, not needed any more, but wasn't needed to remove either
[17:35] <Saviq> anyway
[17:35] <Saviq> now that you cleared it from sources, should publish fine
[17:35] <Mirv> Saviq: ah ok, britney hacking... well trying again
[17:35] <Saviq> sil2100, please publish silo 51
[17:35] <Saviq> Mirv, or you, thanks! :)
[17:36] <Saviq> Mirv, actually, was not to make britney happy, but rather to make citrain tool happy for when new mir was in proposed
[17:36] <Saviq> aanyway
[17:41] <Mirv> it's taking ages, but let's see in 10 mins
[17:46] <sil2100> Yeah, I removed mir but maybe pressed publish too early
[17:51] <Mirv> Saviq: sil2100: ok 051 publish is successfully done
[17:51] <Saviq> Mirv, thanks!
[17:51] <Saviq> sil2100, no, there was no need to remove it, since it was already published
[17:51] <Saviq> sil2100, train would just go over it (and if you removed, you needed to remove it form sources: in bileto)
[17:52] <sil2100> hm, though the train propagates the sources list by itself from the contents
[17:52] <sil2100> Oh well, too many changes happening
[17:52] <sil2100> Anyway, it's published now from what I see
[17:53] <Mirv> sil2100: a core-dev would be needed to publish https://requests.ci-train.ubuntu.com/#/ticket/978
=== alan_g is now known as alan_g|EOD
[18:30] <sil2100> rvr: hmmm, I see you mentioned issues with silo 79
[18:30] <sil2100> rvr: does that only happen with the silo installed?
[18:30] <sil2100> john-mcaleely, jibel: ^ should we block until this gets resolved?
[18:31] <sil2100> I guess this might take too long
[18:32] <jibel> sil2100, it happens without the silo too, but it makes the silo impossible to verify
[18:37] <john-mcaleely> hmm tricky
[18:38] <john-mcaleely> jibel, so, should we land the silo, and hope, or propose to live without it?
[18:42] <sil2100> hmm
[18:44] <john-mcaleely> do two builds, one without, one with?
[18:45] <sil2100> Yeah, I could kick a new build right now and we can re-build later on once we have a decision
[18:45] <john-mcaleely> works for me
[18:46] <sil2100> Ok, let's just do it ™
[18:47] <john-mcaleely> :-)
[18:47] <sil2100> Rootfs building, once it's built and imported to rc-proposed I'll copy it to rc :)
[18:47] <john-mcaleely> oooh
[18:47] <sil2100> Hopefully shouldn't take too long
[18:50] <sil2100> robru: no slangasek, I recommend skipping the internal meeting ;)
[18:50] <robru> sil2100: +1
[18:59] <robru> sil2100: Mirv: Saviq: train will automatically add source packages to source package name list based on MPs + PPA contents, but does not remove, in the event of manual source packages.
=== salem_ is now known as _salem
=== salem_ is now known as _salem
[20:13] <robru> oh heh
[20:14] <robru> it approved based just on vivid and then when xenial started it flipped back to running
[20:14] <robru> hmmmm
[20:18] <alecu> rvr: just saw your comments on charles's silo: https://trello.com/c/uqSFc5VT/2771-1002-ubuntu-landing-079-indicator-bluetooth-charles
[20:19] <rvr> alecu: Already discussed with morphis
[20:19] <rvr> alecu: He was investigating
[20:19] <alecu> rvr: so, you think those are not related to this silo?
[20:20] <rvr> alecu: Well, the issue is not fixed with the silo
[20:21] <alecu> rvr: yes, it's not completely fixed, but from what we can see this fix is needed too, right charles?
[20:36] <Saviq> robru, yeah, I know, all resolved, sorry for bugging you
[20:36] <robru> Saviq: no worries
[20:37] <Saviq> robru, I didn't reply to your email yet, but were thinking... why shell out where (I suppose?) there are perfectly valid bzr/git modules out there?
[20:39] <robru> Saviq: well we shell out to bzr because a) I inherited it this way and it would be insane to invest effort on bzr at this point, b) the bzr modules are unmaintained, and c) whatever is available probably isn't available for python3 in trusty.
[20:40] <robru> Saviq: git probably has better modules, but even if it does, I doubt they exist for python3 in trusty
[20:40] <robru> Saviq: so shelling out is just a nice standard way to have things kinda Just Work without thinking too hard about stuff.
[20:41] <robru> Saviq: also in my experience, a lot of times when I compare python modules to shelling out to commandline tools, the python module api is often much lower-level than what shell exposes, so you end up writing a lot more code to interact with the api than with simply shelling out to the command you want to do.
[20:43] <robru> which is strange but yeah, I'd rather have one line of "call('bzr', 'commit', ...)" than 100 lines of "instantiate bzr object, set this, call that method, catch this exception, etc etc"
[21:02] <Saviq> robru, b) I think is bogus as you could say that about bzr as well ;)
[21:03] <Saviq> the py3 argument I get
[21:05] <Saviq> and I probably agree with the ease with which you can shell out, at the expense of having less control, but maybe that's ok
[21:30] <robru> Saviq: yeah we haven't needed much control. it's been working fine as is for years
[21:30] <robru> Saviq: re: b), yeah bzr itself is also  unmaintained but the difference is we're not writing new code with it. why would we write new code with an unmaintained module that's going away?
[21:31] <Saviq> robru, sure, I understand
[21:44] <Saviq> robru, can you do anything about a stuck autopkgtest? or at least determine whether it's stuck? http://people.canonical.com/~ubuntu-archive/proposed-migration/xenial/update_excuses.html#unity-api
[21:46] <robru> Saviq: nope I have no power over that. how long's it been stuck for? it's not in running.shtml so I guess -proposed didn't even trigger it yet?
[21:46] <Saviq> robru, or that it missed its completion - the i386 run completed 1927 UTC
[21:46] <Saviq> so over two hours ago
[21:47] <robru> Saviq: yeah I guess that's a bug. the only person I know for sure is pitti but I guess other people should also be able to poke that. try finding Colin or Adam
[21:47] <Saviq> yup, tx
[21:47] <robru> yw