[16:18] <dsmythies> apw: I made an 19.10 VM server and tried to compile the mainline there, using the exact same kernel config file. Indeed, it fails as per the Ubuntu mainline PPA. (Compiler: gcc (Ubuntu 9.1.0-6ubuntu2) 9.1.0) Which is no news for you, but for my own education.
[16:19] <apw> right the compiler has some new options enabled by default.


[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
[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
[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?
[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!
[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
[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
[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.
[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


[00:53] <boiko> trainguards: can someone please trigger a rebuild of telephony-service vivid amd64 on silo 80?
[00:55] <robru> boiko: done
[00:55] <boiko> robru: thanks
[00:55] <robru> boiko: you're welcome
[07:28] <anpok> trainguards: could you restart the arm64 xenial build in landing silo 006
[07:39] <Mirv> anpok: sure
[08:35] <dbarth> hey trainguards
[08:36] <dbarth> is there a way to accelerate a landing in progress on https://requests.ci-train.ubuntu.com/#/ticket/923
[08:37] <dbarth> in order to rebuild and test https://requests.ci-train.ubuntu.com/#/ticket/1003 faster
[08:37] <Mirv> dbarth: yes, if you swear not to close browser tabs regarding http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#ubuntu-system-settings-online-accounts and http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#account-plugins before they are Valid Candidates
[08:38] <Mirv> dbarth: I mean, if you make sure they eventually migrate
[08:38] <dbarth> ah
[08:38] <Mirv> dbarth: so just say "yes" and I'll merge the silo
[08:39] <dbarth> ahem, "yes"
[08:40] <Mirv> dbarth: done! thanks. the only reason the automerge does not happen automatically earlier is so that it's made sure the landers will look the xenial landing to the end of it.
[08:40] <dbarth> brilliant!
[08:40] <dbarth> thanks Mirv
[08:40] <dbarth> now i need to keep monitoring those tabs
[09:03]  * sil2100 doesnt have internet currently
[10:40] <rvr> pete-woods: ping
[10:42] <pete-woods> rvr: hi
[10:42] <rvr> pete-woods: How can I test the changes for silo 75?
[10:43] <pete-woods> rvr: good question. I'll upload an updated VPN editor app with the checkbox for "never default" in it
[10:44] <pete-woods> then if you connect the the canonical VPN, you should still be able to use the internet
[10:44] <rvr> pete-woods: Ok
[11:07] <pete-woods> rvr: I have updated the test plan on https://requests.ci-train.ubuntu.com/#/ticket/1070
[11:18] <jgdx> pete-woods, rvr, could also install silo 38, but yea, a bit late
[11:20] <Saviq> rvr, davmor2, I will pay good money for getting https://trello.com/c/QTDB4lAF/2857-996-ubuntu-landing-057-unity8-unity-scope-click-dobey through ;)
[11:24] <rvr> pete-woods: Thanks
[11:25] <davmor2> Saviq: it is next in the queue I think silo 57
[11:25] <Saviq> davmor2, just sayin'
[11:25] <rvr> Saviq: Yes, it's the next :)
[11:25] <Saviq> ;)
[12:52] <boiko> trainguards: can someone please trigger a rebuild of messaging-app xenial i386 on silo 52?
[12:57] <rvr> pete-woods: Wee. Seems I could connect to the VPN :)
[12:57] <pete-woods> rvr: cool
[12:57] <pete-woods> glad that worked
[12:59] <rvr> pete-woods: But I cannot browse
[12:59] <pete-woods> rvr: dammit
[13:00] <pete-woods> rvr: can you connect directly to an IP address? (e.g. <IP_ADDRESS> for google)
[13:00] <sil2100> boiko: on it
[13:00] <rvr> pete-woods: Ah, I can browse, but not to start.ubuntu.com
[13:01] <pete-woods> rvr: I think the canonical VPN owns the DNS entries for *.ubuntu.com and *.canonical.com
[13:01] <boiko> sil2100: thanks!
[13:01] <pete-woods> and probably breaks them, to be honest
[13:01] <rvr> pete-woods: Yeah, seems so
[13:01] <rvr> pete-woods: I can google
[13:02] <pete-woods> awesome
[13:02] <pete-woods> rvr: can you also connect to a host inside the VPN?
[13:17] <Saviq> davmor2, please give me updates on silo 57 when you have any :)
[13:36] <abeato> john-mcaleely, sil2100 I have a new device tarball for frieza: http://people.canonical.com/~abeato/avila/ubuntu/device_frieza-20160308.0.tar.xz
[13:36] <abeato> sil2100, would it be possible to have a new rc release with it?
[13:37]  * abeato got disconnected so not sure if somebody saw that ^^
[13:38] <sil2100> abeato: sure
[13:38] <sil2100> In a moment :)
[13:38] <abeato> sil2100, great, thanks
[13:38] <abeato> sil2100, sure, not in a hurry :)
[14:04] <morphis> sil2100: ping
[14:04] <sil2100> morphis: pong
[14:04] <morphis> sil2100: can you publish https://requests.ci-train.ubuntu.com/#/ticket/954 ?
[14:05] <sil2100> Looking
[14:05] <morphis> I think seb128 already reviewed the packaging changes before
[14:05] <morphis> seb128: or I am wrong?
[14:05] <seb128> I did
[14:05] <morphis> great :-)
[14:05] <morphis> seb128, sil2100: then lets get this landed finally
[14:06] <seb128> \o/
[14:07] <sil2100> Oh :)
[14:07] <sil2100> Ok then o/ Look okayish and since seb128 had a look at the binNEW bits then it should be good for release
[14:07] <morphis> sil2100: awesome
[14:16] <sil2100> abeato: new device-tarball rc image is in the channel
[14:16] <abeato> sil2100, nice, thanks!
[14:18] <Mirv> bzoltan_: sil2100: I'm a bit puzzled on what to do with the failing ppc64el tst https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-050/excuses.html - it seems to fail because of old/new u-s-s-o-a dependency issue (or do you see the log otherwise?). I wonder if you (mainly sil2100) agree that we could ask QA to re-test 050 already now with a pretty please on top? vivid is already green a
[14:18] <Mirv> nd xenial is besides that one test
[14:18] <sil2100> hmm
[14:18] <Mirv> that ppc64el issue seems to just linger, I've reran it four times but as you see britney even lists different version for s390x and ppc64el, not sure if it's going to get fixed without some manual refresh
[14:19] <Mirv> oh, correction, s390x is also running/queued and not always failed so that's also a "ack" blocker
[14:20] <Mirv> last week I spent Wednesday morning -> Friday waiting for autopkgtest results on 050 and sometimes it's not time well spent
[14:21] <sil2100> Mirv: yeah, it doesn't really look like any real regression
[14:24] <Mirv> ubuntu-qa/davmor2: ^ if you have time, please take silo 50 again into consideration while we try to wait/retry xenial ppc64el/s390x tests for one package. vivid is green already.
[14:24] <jibel> Mirv, does it fix the crash with the wizard?
[14:24] <Mirv> jibel: yes
[14:25] <Mirv> zsombi can answer any technical details if needed
[14:25] <jibel> Mirv, there is already media-hub and pulseaudio in the queue you have time to fix the failing arches
[14:26] <Mirv> jibel: sure just FYI so that you can mentally have it queued. autopkgtests builders have huge queues so one never knows how long it will take.
[14:26] <jibel> Mirv, yeah I'll mentally test it too ;)
[14:32] <rvr> mzanetti: Hmm... I updated Telegram on OTA9.1 on my own phone, and right now it displays a blank page when it's opened. Sometimes it takes a while to load, but now seems stuck. Have you seen that?
[14:33] <mzanetti> rvr, please try this:
[14:33] <rvr> mzanetti: Ok, it was the network
[14:33] <mzanetti> ah ok
[14:33] <mzanetti> good (well, not so good - but at least we know what's going on)
[14:33] <mzanetti> I wonder how I did end up owning telegram :D
[14:33] <rvr> mzanetti: Sorry :D
[14:34] <mzanetti> no prob :D
[14:34] <rvr> mzanetti: I guess Jin works in a different time zone
[14:34] <mzanetti> yep
[14:34] <mzanetti> also he's mostly working on other stuff... he's just keeping it rolling
[14:37] <Mirv> rvr: sounds familiar to me with earlier telegram versions too, sometimes that blank page startup happens and I need to start it again
[14:38]  * rvr wonders whether a bug exists for that
[14:38] <rvr> https://bugs.launchpad.net/telegram-app/+bug/1535344
[14:58] <rvr> pete-woods: Silo 75 approved
[15:27] <pete-woods> rvr: awesome, thanks!
[15:50] <pete-woods> jgdx: ^ FYI
[15:50] <jgdx> pete-woods, great news
[15:57] <davmor2> Saviq, dobey: just double checking but it looks like you lose the feed back that the app is downloading will trial it with dekko as that is pretty big
[15:59] <dobey> davmor2: was working fine for me
[16:00] <davmor2> Saviq, dobey: oh no I see what the issue is.  If the page hasn't finished loading the images so the orange bar at the bottom is still going it never updates the install % allow it to load all the page fully and then it does
[16:02] <dobey> Dakirby309-Simply-Styled-OS-Ubuntu.ico.png
[16:02] <dobey> err
[16:03] <davmor2> dobey: try it with utorch I think it is because a lot of the apps are pretty small and the images are taking longer than the app to download
[16:04] <dobey> davmor2: it should just show 0% and then immediately end up getting switched to the next preview then, though
[16:04] <dobey> davmor2: is that what happens?
[16:06] <davmor2> dobey: yeap I get the 0% so on dekko it is at like 30% before the images have finished loading so it is 0%-30%-35%-40% and so on utorch has a load of images so has finished before the images so never shows progress
[16:06] <davmor2> dobey: are we not caching the image they seem to reload on ever page
[16:06] <rvr> jhodapp: ping
[16:06] <Saviq> davmor2, hmm weird, image loading should be separate to that (and anyway that doesn't sound like something caused by that silo I'd say)
[16:06] <Saviq> I mean a pre-existing issue
[16:07] <davmor2> Saviq: most likely it's just I haven't tested it in a while so have only just noticed it :)
[16:07] <dobey> davmor2: the dash handles all the images
[16:07] <jhodapp> rvr, pong
[16:07] <dobey> davmor2: this is definitely not new
[16:07] <Saviq> davmor2, right, confirmed, old bug
[16:07] <davmor2> dobey: :)
[16:08] <davmor2> dobey: so you're saying it is Saviq fault
[16:08] <rvr> jhodapp: Hi. Was silo 19 rebuilt? I got a new card in trello
[16:08] <Saviq> davmor2, just tried on frieza with utorch, and while the files should be cached, they're possibly not cached at that size, so need to be resized every time, totally our fault
[16:08] <jhodapp> rvr, it was yes, but only added a code comment
[16:08] <davmor2> Saviq: is there a bug for that?
[16:09] <davmor2> Saviq: if not I will write one up
[16:09] <rvr> jhodapp: I see
[16:09] <Saviq> davmor2, please do
[16:13] <davmor2> Saviq: https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1554602
[16:14] <Saviq> davmor2, thanks
[16:14] <Saviq> sil2100, is anyone looking into devel-proposed not booting on mako since image #447 (or #446, confirming now)?
[16:15] <sil2100> Saviq: yes
[16:15] <Saviq> sil2100, do you know the bug#?
[16:15] <sil2100> Saviq: I mean... jibel was looking into that, stgraber and ondra were taking a look as well
[16:15] <sil2100> Not sure if there's anyone driving
[16:15] <sil2100> Yeah, one moment
[16:15] <sil2100> https://bugs.launchpad.net/canonical-devices-system-image/+bug/1551150
[16:15] <Saviq> ack
[16:16] <sil2100> Still no solution though...
[16:16] <Saviq> :S
[16:19] <ondra> Saviq it's in progress, but not top priority for me atm
[16:19] <Saviq> ondra, yeah, thanks, will monitor the bug
[16:22] <dbarth> rvr: this one still needs building again? https://requests.ci-train.ubuntu.com/#/ticket/893
[16:22] <dbarth> rvr: i've been rebuilding it 1000 times almost... ;)
[16:22] <rvr> sil2100 can you take a look ^
[16:27] <alecu> sil2100: which are the click packages that need the workarounds you just mentioned? Or is that something that applies to every click?
[16:33] <sil2100> alecu: from what I know there's a new camera-app that depends on the rc-proposed framework
[16:33] <sil2100> I know there will also be a few others in the nearest time as well
[16:33] <sil2100> This will be also relatively common
[16:36] <alecu> right
[16:41] <bzoltan_> sil2100:  I have flashed my krillin with  version 425 from ubuntu-touch/rc-proposed/ubuntu channel and tried apt-get update/dist-upgrade but it all hangs onSetting up bluez (5.37-0ubuntu5~overlay1) ... bluetooth stop/waiting
[16:41] <sil2100> morphis: ^ do you know anything about that?
[16:42] <sil2100> We published that version in the morning, IIRC it didn't require anything special from the device side
[16:43] <dbarth> hey trainguards or anyone able to help on ppa size issues
[16:43] <dbarth> we've got that oxide build ppas we'd like to get space extensions for:
[16:44] <dbarth> https://launchpad.net/~oxide-builds
[16:50] <cjwatson> dbarth: moment
[16:51] <cjwatson> dbarth: (fwiw the primary way to request this kind of thing is https://answers.launchpad.net/launchpad; but don't bother now)
[16:51] <cjwatson> dbarth: which of those PPAs, and what size do you need
[16:51] <cjwatson> ?
[16:52] <cjwatson> dbarth: bearing in mind that ppa.launchpad.net is critically short of space right now; it's due to be extended on Monday-ish but we somehow need it to limp on until then
[17:31] <rvr> Saviq: ping
[17:31] <Saviq> rvr, here
[17:31] <rvr> Saviq: https://bugs.launchpad.net/ubuntu/+source/ubuntu-settings-components/+bug/1436912
[17:31] <rvr> Saviq: That project is not set to expose translations to Launchpad, can you?
[17:32] <Saviq> rvr, oh sorry, right away
[17:35] <Saviq> rvr, done
[17:35] <rvr> Saviq: sil2100: Thanks. Now we must make sure that ubuntu-settings-components translations files are included in the language pack.
[17:36] <Saviq> rvr, https://code.launchpad.net/langpack-o-matic/ is responsible for that AFAICT
[17:37] <morphis> bzoltan_: you're using an older citrain version it seems
[17:37] <rvr> Saviq: I think that some projects include something in debian rules.
[17:38] <morphis> bzoltan_: restarting services during upgrade is prevented if you use latest citrain
[17:38] <Saviq> rvr, indeed, X-Ubuntu-Use-Langpack: yes
[17:38] <Saviq> rvr, it's there already
[17:38] <rvr> Saviq: Oh, great
[17:39] <rvr> So let's wait for the next export
[17:41] <Saviq> rvr, I *think* we might not be building .mo files in there at all :/
[17:42] <Saviq> ah mostly because we don't have a single .po there <facepalm />
[17:42] <Saviq> how did we miss enabling the translation on this...
[17:45] <Saviq> rvr, it's imported now, please look through https://translations.launchpad.net/ubuntu-settings-components/trunk/+pots/ubuntu-settings-components/es/+translate
[17:45] <Saviq> or get someone to, since they're your translations ;)
[17:46] <rvr> Saviq: \o/
[17:47] <Saviq> rvr, not sure how to get the import out of "needs review" in https://translations.launchpad.net/ubuntu/xenial/+source/ubuntu-settings-components though
[17:47] <Mirv> Saviq: fi translated too now :)
[17:47]  * Saviq has no powers for that
[17:47] <Saviq> Mirv, thanks :)
[17:47] <rvr> Done :D
[17:49] <rvr> Saviq: Those are reviewed and approved by translation teams
[17:49] <Mirv> Saviq: those are not "Needs review" anymore for Spanish or Finnish, but LP has a delay before it updates other data besides "Last Changed" column
[17:50] <Mirv> which might also mean there's a delay before the translations are actually downloadable. I think it might be around similar delay as in PPA publishing (~15mins), but not sure
[17:51] <Mirv> Saviq: well, now it updated actually already. es, fi, pl translated
[17:54] <Saviq> Mirv, yup
[18:19] <rvr> jhodapp: ping
[18:19] <jhodapp> rvr, pong
[18:19] <rvr> jhodapp: Silo 19 approved, but I have a question about media hub
[18:20] <jhodapp> rvr, awesome thanks, sure thing
[18:20] <rvr> jhodapp: I was playing an album, and I closed the music app
[18:20] <rvr> jhodapp: The music keeps playing
[18:20] <rvr> Is that intended?
[18:20] <rvr> I can use the indicator to go next/previous track
[18:20] <jhodapp> rvr, no it's not intended, were you testing on Arale by chance?
[18:20] <rvr> jhodapp: Yes
[18:21] <jhodapp> rvr, you might have hit the media-hub hang that I just fixed and set as approved in this request: https://requests.ci-train.ubuntu.com/#/ticket/1075
[18:22] <jhodapp> rvr, if you hit that again while testing that MR, then it'd be good to file a new bug
[18:22] <rvr> No phone calls this time
[18:22] <rvr> jhodapp: Hmm...
[18:23] <rvr> Checking without the silo packages
[18:23] <jhodapp> rvr, yeah I think you hit the deadlock issue
[18:31] <bzoltan_> morphis: I do no use citran... it is a simple apt-get dist-uograde what hangs
[18:31] <bzoltan_> morphis: what the citrain does to avoid that? I have now marked the bkuez to hold
[18:32] <morphis> bzoltan_: I would recommend to always use citrain to install a silo
[18:32] <morphis> it does a lot of neat things
[18:32] <bzoltan_> morphis: I have better tool for that :)
[18:32] <bzoltan_> morphis: i have suffered so much with various tools that i decided to use my own... since than life is easy
[18:33] <morphis> bzoltan_: https://bazaar.launchpad.net/~phablet-team/phablet-tools/trunk/view/head:/citrain#L89 is what you are looking for
[18:33] <morphis> bzoltan_: .. or not :-)
[18:33] <morphis> line 89 and 90 is what you want
[18:33] <morphis> ah + 91
[18:33] <bzoltan_> morphis: with this you can trust me :) i am doing more AP tests with more silos then the whole platform together :)
[18:34] <morphis> + the steps to revert those things
[18:34] <morphis> bzoltan_: possible :-)
[18:34] <morphis> I am just for a tool which is common and would do the same mistake for everyone then fixes a dozen of different mistakes
[18:34] <bzoltan_> morphis: + i did try citrain.. crashed, hanged
[18:35] <morphis> bzoltan_: what did crash? citrain or the upgrade?
[18:35] <bzoltan_> morphis: citrain
[18:36] <bzoltan_> morphis: I hev found it unreliable
[18:36] <bzoltan_> have
[18:37] <morphis> bzoltan_: it got better
[18:37] <bzoltan_> morphis: I am sure it did :)
[18:39] <Saviq> bzoltan_, silo 57 is publishing, will make sure it's built and tested again before morning
[18:39] <Saviq> s/it's/silo 50/
[18:39] <bzoltan_> Saviq: Cool, thanks.. will do
[18:42] <Saviq> bzoltan_, I did just say that *I* will make sure, but whatever you wanna do, sure ;)
[18:42] <Saviq> bzoltan_, I also filed a few OTA10 criticals in https://bugs.launchpad.net/bugs/+bugs?field.tag=ota10-sdk
[18:43] <Saviq> well, a couple, not few
[18:43] <Saviq> biab
[18:44] <bzoltan_> Saviq:  seeing that this landing of the UITK took two months.. i am sceptical that there will be any new landing in OTA10 :( Something is not right with this landing process... IMO we should have pushed the UITK a month ago to the rc-proposed and itterate 3-4 more quick landings. Now I am rolling this huge changelog for weeks... not good.
[18:44] <bzoltan_> sil2100: jibel: ^
[18:47] <rvr> jhodapp: Why are the MPRIS controls only activated in the indicator when the music app is in the foreground?
[18:49] <rvr> jhodapp: I think that what happened before was that I started reproducing an album using the scopes
[18:49] <rvr> jhodapp: So when I closed the music app, the scope queue was still on memory
[18:51] <ahayzen> rvr, sounds like bug 1534169
[18:52] <ahayzen> or at least part of what happens in the case
[18:52] <rvr> ahayzen: Yeah, I thought the music app was playing when it was the music scope
[18:53] <ahayzen> yeah confusing :-)
[19:00] <jhodapp> rvr, that's another bug that I've yet to fix
[19:00] <jhodapp> rvr, we'll be redoing the way media-hub tracks the current player and reports over MPRIS
[19:02] <jhodapp> rvr, bbiab, switching locations
[19:28] <jhodapp> rvr, doing a rebuild on silo 48 so you'll probably see second QA request on it, apologies for the noise
[20:50] <Saviq> trainguards, can we please force-merge https://requests.ci-train.ubuntu.com/#/ticket/996, I'd rather not wait for the armhf queue in proposed migration to go away... we're really pressed to land unity8 silos asap (britney was happy with that req last night)
[20:51] <robru> Saviq: looking
[20:53] <robru> Saviq: oh i see, it's mostly passed but just waiting for armhf.
[20:53] <Saviq> robru, yup
[20:53] <robru> Saviq: please do keep an eye on that to make sure it passes
[20:53] <Saviq> robru, will do
[20:53] <robru> Saviq: I'll merge for now
[20:53] <Saviq> robru, thank you
[20:54] <dobey> hmm
[20:56] <robru> Saviq: you're welcome.
[20:57] <robru> Oh god it's so slow. I need to get on that parallelism branch and get that in production asap
[23:26] <Saviq> trainguards, can anyone please click ♻ on https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-050/excuses.html ?
[23:27] <Saviq> I wonder if it has to be retried with all of proposed instead, since it's the proposed version that's the only one that passed yet http://autopkgtest.ubuntu.com/packages/u/ubuntu-system-settings-online-accounts/xenial/ppc64el/
[23:28] <robru> Saviq: you need a core dev, not a train guard
[23:28] <Saviq> grh
[23:28] <robru> Saviq: one day I'll make core dev and the distinction won't matter
[23:28] <Saviq> robru, actually I might need more than core dev, because a ♻ won't be enough
[23:29] <robru> Saviq: what do you need then?
[23:29] <Saviq> robru, someone with access to snakefruit
[23:29] <Saviq> https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure#Re-running_tests
[23:30] <Saviq> will wait for pitti in the morning, this should be a quickie
[23:30] <robru> Saviq: Hmmmmmmm. Try #ubuntu-release for people who can access snakefruit
[23:31] <Saviq> robru, yeah, sorry for the noise, will have to wait until tomorrow anyway
[23:32] <robru> Saviq: OK no worries
[23:33] <Saviq> Mirv, when you're up, to get https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-050/excuses.html passing you need u-s-s-o-a re-ran with the rest of proposed, since it only first passed with the proposed version (or well, wait for http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#ubuntu-system-settings-online-accounts to migrate)
[23:36] <Saviq> Mirv, oh well, but you should know - you landed it yourself https://requests.ci-train.ubuntu.com/#/ticket/923 ;P


[23:12] <satellit_> dfarning: I like latest USR w/ firefox......
[23:13] <satellit_> is cp: software updates working?
[23:21] <dfarning> satellit_, not yet. that is a major change.  In the mean time I think we will just delete the updater in the control panel.
[23:24] <satellit_> ok
[23:25] <satellit_> I still get a pop up for firefox on exit saying it would not start...but It does...(old behavior)
[23:26] <satellit_> I am installing to VM workstation now (w/updates)
[23:26] <dfarning> satellit_, hmm does that happen when firefox exits?  Firefox used to give that warning in ubuntu.
[23:27] <satellit_> still seems to. that was on CD with updates in install may be different...
[23:28]  * satellit_ that popup always was there...is in .xo on soas-v3 and v4 also
[23:29] <satellit_> it may be a timing issue as firefox takes a while to load


[00:47] <mup> PR snapcraft#4488 opened: build(deps-dev): bump pyinstaller from 4.10 to 5.13.1 <Dependencies> <Python> <Created by dependabot[bot]> <https://github.com/snapcore/snapcraft/pull/4488>
[03:47] <mup> PR snapcraft#4489 opened: chore(deps): update dependency pyinstaller to v5 [security] <Dependencies> <Created by renovate[bot]> <https://github.com/snapcore/snapcraft/pull/4489>


[11:06] <mectors> A quick question. Canonistack is not launching instances reliably. Is there any way I can kill a machine and tell juju to try to start another node. juju destroy-unit/machine/service do not work reliably.
[11:07] <pavel> you mean juju terminate-machine ?
[11:09] <mectors> It marks it as dying but it does not really terminates it because it never started up
[11:09] <mectors> so now I am stuck with an inconsistent state
[12:08] <AskUbuntu> E: Unable to locate package juju-core | http://askubuntu.com/q/310604
[13:29] <jcastro> hey jam, silly question
[13:30] <jcastro> but do you know how we ended up with packages in the PPA being built differently than in distro?
[13:30] <jcastro> I am wondering if we did that on purpose or if it's just a consequence of something
[13:30] <jam> jcastro: because the PPA was done first, but isn't "legitimate" for how they wanted the build to be done in Ubuntu
[13:31] <jcastro> ah ok
[13:31] <jam> jcastro: so it got fixed for official builds, and the changes need to be applied to the PPA
[13:31] <jam> but there is some reason it isn't trivial to do it
[13:31] <jam> mgz knows a bit more.
[13:35] <jcastro> I was just curious
[13:36] <pavel> Guys, can you explain me one very basic thing? Is it supposed that service instance would be stopped/started or rebooted?
[13:40] <mgz> jcastro: the ppa generation wasn't updated to use the new packaging, I'm going to try to sync up with dave on fixing that
[13:47] <marcoceppi> pavel: could you clarify that a bit? I'm not sure I understand what you're saying
[13:48] <pavel> I mean, what if I stop and start instance with service deployed by juju in aws console
[13:48] <pavel> marcoceppi, what will happen then?
[13:49] <marcoceppi> pavel: Depends on which version of juju you use
[13:49] <pavel> 0.7
[13:51] <marcoceppi> If you're using juju <= 0.7 Juju will provision a new unit to replace it when you stop an instance. In juju >= 1.0 Juju won't try to replace the stopped unit, but I'm not 100% certain things will "come back up" properly. In that the juju service on the unit will start, but the start hook won't be explicitly executed so your service will need to install itself as an upstart or init script properly configured to start on machine up. Also
[13:51] <marcoceppi> , relations might go haywire as well
[13:55] <pavel> I see
[13:56] <pavel> so there is no predictable behavior for this case
[13:56] <pavel> and I should suppose that instance always run
[13:56] <marcoceppi> pavel: not at the moment, no real predicatbility. It's best to remove and re-add units instead of turning them on and off via the console
[13:56] <pavel> because my problem is that I didn't find a way to increase root partition size on AWS with JuJu, so I use ephemerial storage mounted to /mnt
[15:15] <dpb1> Hi all -- is there a way in juju-core to associate a public IP through juju with just one service or unit?
[15:18] <mgz> nope, that would be handy though
[15:21] <mgz> I'm working on the addressing code currently, so if you have use-cases I'd really like if you could send a message to the list or something so they get recoreded


[10:52] <Koon> doko: do you already have a metabug # for the "default-jdk targets Java 1.6 bytecode" issue ? I have bug 283875 which is probably a dupe
[10:55] <doko> Koon: 264808
[10:56] <Koon> doko: should I fix tomcat5.5 in the same way you fixed ant ? or do you plan to change something globally ?
[10:58] <doko> Koon: no, please fix it locally, probably applying the fix for all runtime dependencies as well. why do you care about tomcat5.5, and not tomcat6?
[10:59] <Koon> doko: tomcat6 requires java 6.
[11:00] <doko> ahh, ok.
[11:00] <Koon> hmm. no
[11:00] <Koon> it requires java 5 in fact
[11:01] <Koon> however atm I made it depend on default-jre-headless | java6-runtime-headless
[11:02] <Koon> that should probably be fixed as well
[14:50] <persia> Team Meeting in #ubuntu-meeting in 10 minutes
[20:09] <islan> I am having a problem with Runtime issuing shell statements, was wondering if someone in here could help me
[20:09] <slytherin> islan: any example program? And which java are you using?
[20:10] <islan> using version 1.6.0_06
[20:11] <islan> the problem is it using BufferedReader to get a list of files for it to issue mv statements for individually
[20:11] <islan> it works fine, but when I use the * symbol it doesn't work at all
[20:11] <islan> the * is placed within the string issued to Runtime exec()
[20:12] <slytherin> islan: I wish I could help but I don't have Sun JRE installed.
[20:12] <islan> darn
[20:12] <slytherin> islan: does openjdk also give you same error?
[20:13] <islan> I don't think I have that


[01:24] <Noskcaj> ok
[07:18] <aixnr> Question about Ubuntu Core here. Does anyone know whether it has adopted the rolling release model instead of software versioning like Ubuntu currently does?
[07:33] <Noskcaj> jpds_, There's a new upstream release of efi-tools. Could you please package it and make the package amd64-any only
[21:41] <Noskcaj> Is anyone working on the openjpeg2 transition?