[00:00] <awe_> unfortunately, it's also taken a really long time to fix, and there are still lurking issues
[00:01] <slangasek> awe_: well, I've seen lots of discussion; what I haven't seen on the list is "the bug is fixed in devel, if you still have problems after upgrade here's how you you recover without having to reflash" or so
[00:02] <awe_> but the bug has been mentioned in the ML, and the bug does have explicit instructions
[00:05] <slangasek> awe_: as far as I'm concerned, if there aren't explicit instructions on how to recover in the bug description, this doesn't count ;)
[00:13] <awe_> slangasek, workaround added to the bug description
[00:27] <slangasek> awe_: cheers
[03:34] <imgbot> [03:35] <imgbot> [05:55] <robru> stgraber, ogra_ : uh, according to imgbot, image 135 took 9.5 hours to build...
[07:40] <ogra_> sil2100, there were new kernels, new hybris and a new android build ... we should roll an image ASAP to cover these
[07:41] <brendand> sil2100, didn't someone try to address the filemanager failures already?
[07:41]  * ogra_ doubts that ... this is a fresh release 
[07:41] <ogra_> (of filemanager)
[07:44] <brendand> ogra_, what do you mean? it's had failures since 132
[07:50] <ogra_> brendand, the same ones ?
[07:51]  * ogra_ sees a new failure in 135
[07:52] <brendand> ogra_, yes there is an extra one in 135, but the other two have been happening since 132
[07:52] <ogra_> right, but the new one seems to actually be caused by the new code
[07:54] <sil2100> brendand: popey's fixes should have helped, they didn't?
[07:54] <sil2100> ogra_: yeah, let's kick a new image indeed
[07:55] <brendand> sil2100, which fixes? were they meant to fix the Places tests?
[07:55] <ogra_> sil2100, try out your new powers ;)
[08:01] <cking> in
[08:02] <sil2100> brendand: popey mentioned something about a fix in the emulator
[08:02] <sil2100> So not sure
[08:02] <sil2100> ogra_: oooh ;)
[08:02]  * sil2100 tries
[08:05] <psivaa> sil2100: brendand: do you want me to rerun uitk tests?
[08:05] <psivaa> that has a qmlscene crash produced during the test
[08:05] <brendand> psivaa, yeah
[08:06] <sil2100> brendand, psivaa: yeah, I guess this is the flakyness as before
[08:06] <brendand> psivaa, and system-settings
[08:11] <popey> there was a new file manager in 135 which was supposed to fix the tests
[08:13] <ogra_> well, it didnt
[08:16] <sil2100> Are the same tests failing?
[08:16] <ogra_> yeah
[08:16] <brendand> sil2100, the two same ones and an extra one
[08:16] <ogra_> and a new one
[08:16] <tvoss> Mirv, good morning :)
[08:17] <tvoss> sil2100, ping
[08:17] <sil2100> tvoss: pong :)
[08:18] <tvoss> sil2100, for line 38: I'm aware of the conflict with silo 2, would like to fast-track that mp, though
[08:18] <popey> I'll have to ask balloons to help me with filemanager when he wakes, it was his fix I pushed through
[08:18] <popey> I don't know why it's failing.
[08:18] <popey> unless someone else is an autopilot expert?
[08:19] <brendand> popey, this was meant to be it? https://bugs.launchpad.net/ubuntu-filemanager-app/+bug/1342336
[08:19] <sil2100> tvoss: ok, so let me give you an ignore-conflicts, but please rebuild silo 002 when this lands
[08:19] <tvoss> sil2100, sure
[08:21] <Mirv> tvoss: hello!
[08:21] <popey> brendand: yes
[08:21] <tvoss> Mirv, hey, cancel my ping
[08:21] <Mirv> tvoss: and problem solved, I see
[08:21] <tvoss> Mirv, yup :)
[08:32] <sil2100> grrrr, hangout problem
[08:36] <tvoss> sil2100, got 5 to help with a packaging question?
[08:36] <sil2100> tvoss: in a meeting right now, but sure
[08:49] <brendand> popey, i reset https://bugs.launchpad.net/ubuntu-filemanager-app/+bug/1342336 to New
[08:53] <psivaa> sil2100: brendand: ogra_: the uitk has 21 failures on the re-run too :/ and a qmlscene crash
[08:53] <brendand> sil2100, the extra failure in filemanager is not reproducible. it's probably down to the crash
[08:54] <brendand> psivaa, well that would do the trick
[08:54] <brendand> definitely something wrong there
[09:19] <cjwatson> robru: It was started, failed to build, and then way later it was retried
[09:19] <cjwatson> And the bot (a) is predicting the next image number (b) doesn't notice failures
[09:23] <tvoss> Mirv, sil2100 silo 12 could do with some publishing
[09:23]  * tvoss being annoying
[09:25] <mandel> tvoss, who is not annoying when trying to land a silo? hehe
[09:25] <tvoss> mandel, :)
[09:31] <mvo_> tvoss: will do
[09:31] <tvoss> mvo_, thanks :)
[09:31] <mvo_> sorry for the delay
[09:33] <Mirv> thanks mvo
[09:42] <sil2100> Damn, it's so hot here...
[09:43] <brendand> sil2100, there's supposed to be a heatwave coming here, but i've not seen it yet
[09:43] <bzoltan> ogra_: do you know if it is possible to boot an emulator without the intro settings? I need to deploy an emulator straight to the shell.
[09:43] <brendand> well, it's going to reach 26 by the afternoon. that's what we call a heatwave here
[09:45] <cjwatson> heatwaves are relative :)  feels pretty unpleasant here
[09:49] <mvo_> sil2100: I'm off for lunch now and will resume duty in ~45min or so
[09:49] <xnox> cjwatson: most britons i know say anything above 20 degrees is "horrible weather" =)))))
[09:49] <sil2100> mvo_: ok
[09:49] <imgbot> [09:50] <imgbot> [09:53] <t1mp> who is working on qtubuntu to have a look at https://bugs.launchpad.net/ubuntu-app-launch/+bug/1329141 ?
[09:53] <cjwatson> xnox: aye
[09:54] <t1mp> it is basically blocking all merges to UITK
[09:54] <t1mp> tvoss: ^ any ideas?
[09:57] <popey> new camera in the store with hdr support...
[09:57] <tvoss> t1mp, haven't seen the bug before, don't know if someone is working on it
[09:58] <t1mp> tvoss: do you know who I can ask about it? it looks like nobody is working on it
[09:59] <tvoss> t1mp, hmmm, perhaps loicm has got an idea
[10:00] <t1mp> tvoss: ok, thanks I'll try to catch him
[10:00] <tvoss> t1mp, yw
[10:08] <popey> hmm, system settings crash on 135
[10:34] <brendand> popey, we need to be more regular in landing new versions of click apps
[10:34] <brendand> popey, it would be way easier to debug if we didn't have 12 revisions to consider
[10:37] <brendand> popey, it's probably this rev that did it: http://bazaar.launchpad.net/~ubuntu-filemanager-dev/ubuntu-filemanager-app/trunk/revision/213
[10:37] <brendand> popey, it's the same one that landed by accident before and broke filemanager in the same way
[10:38] <popey> brendand: on a hangout, will reply to this in a bit
[10:38] <Mirv> note that kalikiana's u1db-qt's changelog was overblown probably by some missing tag, but it only contains one change (the first one)
[11:02] <popey> brendand: I have had conversations with dpm and fginther about auto landing clicks in the store, which takes the human (me) out of the loop
[11:02] <popey> brendand: but that work hasn't been done yet, in the meantime we look at the clicks generated and push to the store fairly regularly, and as you can see from the spreadsheet we set alarms (yellow/red) when we dont update apps often enough
[11:03] <popey> brendand: https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AnZdnhOl8MU5dDJseW1vT1N5RkJvLUJHZTdhalRVd1E&usp=drive_web#gid=1
[11:03] <brendand> popey, the delta should be revs not days
[11:03] <popey> brendand: its both
[11:03] <popey> there are more columns
[11:04] <brendand> popey, i see it now. days is not really relevant though
[11:04] <popey> maybe not to you, but it is to me
[11:05] <brendand> popey, well i meant from a quality point of view. from a development point of view you might want to see if progress is being made, so yeah
[11:05] <popey> exactly
[11:06] <popey> I would like us to have fully automated clicks landing in the store. But we're not there yet.
[11:06] <brendand> popey, ok, good to hear that it's planned though
[11:27] <sil2100> om26er: hi!
[11:28] <sil2100> om26er: so, could you dogfood an image for us promotion-wise?
[11:28] <sil2100> om26er: smoketesting for #136 are still running but I suppose it might be a candidate
[11:28] <sil2100> om26er: could you give it a spin?
[11:28]  * sil2100 goes for lunch
[11:28] <sil2100> o/
[11:31] <om26er> sil2100, ok
[11:32] <ogra_> tvoss, are you actually abusing your silo for test builds and dvelopment ?
[11:32]  * ogra_ wonders if tvoss is aware of the 100s of mails he sends aroudn with each of these failing builds
[11:33] <tvoss> ogra_, well, kinda :) sorry for the spam
[11:33] <ogra_> use the canonical-arm-dev PPA ;)
[11:33] <tvoss> ogra_, not sure that I have access there :)
[11:34] <ogra_> now you do :)
[11:34] <ogra_> (for the next time at least )
[12:25] <sergiusens> why the double post?
[12:46] <sil2100> om26er: any luck with dogfooding? :)
[12:47] <om26er> sil2100, ingprogress
[12:47] <om26er> so far so good.
[12:48] <camako> sil2100, Mir 0.5 tested well, and will probably turn "testing done" green soon... Any blockers to land silo 18 on your end?
[12:49] <sil2100> camako: I think we should be good to land it normally today - no regressions in sight?
[12:49] <camako> sil2100, last round of testing about to be done... No regressions.
[12:49]  * camako crosses his fingers
[12:50] <sil2100> o/
[13:09] <rsalveti> ogra_: thanks for building 136
[13:09] <ogra_> thanks for the kernels and andriod :)
[13:10] <rsalveti> :-)
[13:12] <sil2100> rsalveti: we just hope you didn't break anything with those! As we're testing that image for promotion
[13:12] <sil2100> ;)
[13:12] <rsalveti> oh, :-)
[13:13] <rsalveti> hm, reboot/shutdown dialog should be part of the next image
[13:13] <rsalveti> nice
[13:15] <om26er> sil2100, Hi
[13:15] <om26er> sil2100, so videos are not launching from preview in the latest image
[13:16] <sil2100> ouch
[13:16] <sil2100> om26er: that was tested on the latest promoted one, yes?
[13:16] <om26er> sil2100, yes, it worked fine in that version
[13:17] <sil2100> om26er: ok, no promotion then I guess, since I suppose its a promotion blocking regression
[13:18] <sil2100> A visible one so to say
[13:19] <sil2100> om26er: could you fill in a bug? I wonder what could have caused this actually...
[13:23] <sil2100> ok, I see some media-hub and similar landings in 135
[13:24] <sil2100> om26er could you switch to 135 and confirm its broken there as well?
[13:31] <sil2100> The interesting thing is that the media-hub/mediascanner uploads were only no change rebuilds for the new dbus-cpp
[13:31] <sil2100> And the mediaplayer-app upload was only a small change IIRC
[13:33] <Mirv> self-publishing ^
[13:33] <Mirv> because even that kind of polishing is certainly not August's thing
[13:33] <sil2100> Mirv: ok!
[13:36] <om26er> sil2100, where to find diff between images
[13:36] <ogra_> http://people.canonical.com/~ogra/touch-image-stats/
[13:38] <alan_g> sil2100: tvoss asked you about this and I tried your incantation (which was what mterry suggested originally). It doesn't work. https://code.launchpad.net/~mir-team/mir/libmircommon/+merge/226704
[13:41] <Mirv> if there becomes a situation where someone would like to test whether Qt 5.3.1 would have a fix for the problem, see the wiki page https://wiki.ubuntu.com/Touch/QtTesting
[13:41] <Mirv> note that I haven't found any reported bugs that would be fixed (we've cherry-picked many patches already), and it's not going in before RTM anyway. but just in case it might bring extra information to test on it.
[13:48] <camako> sil2100, finished testing mir 0.5. All good.
[13:51] <om26er> sil2100, is there a way to upgrade from 133 to 135 ?
[13:53] <ogra_> om26er, it should ooffer 135 to you if you have 133 installed
[13:53] <ogra_> (it always offers to upgrade to the latest)
[13:53] <om26er> ogra_, 136 is the latest
[13:53] <ogra_> oh
[13:53] <om26er> ogra_, I want to upgrade to 135
[13:53] <ogra_> well, then use ubuntu-device-flash
[13:53] <om26er> it will save me a lot of time
[13:53] <om26er> hmm, complete download then.
[13:53] <ogra_> ubuntu-device-flash --channel=devel-proposed --revision=135
[13:54] <om26er> ogra_, system-image-cli doesn't have anything to force a build
[13:54] <om26er> ?
[13:54] <ogra_> i dont think you can enfocre a revision to go to ... only one you "come from"
[13:55] <mvo_> sil2100: silo-018 needs ack for a new binary package (libmirserver23) - the debdiff looks just fine, its just a packagename bump, what the procedure? it says I need to talk to a archive admin
[13:57] <ogra_> om26er, hmm, probably the --filter option might help
[13:57] <ogra_> if you force "delta only" it probably offers you the smallest delta, which would be 135
[13:57] <ogra_> but not sure
[13:58] <cjwatson> mvo_: I'll look
[13:59] <mvo_> thanks cjwatson
[13:59] <cjwatson> mvo_: you've acked the packaging changes?
[13:59] <mvo_> cjwatson: not yet
[14:00] <mvo_> should i?
[14:00] <cjwatson> mvo_: Well, a core-dev will need to
[14:00] <cjwatson> mvo_: Anyway, the new binary package is fine, AA ack
[14:01] <mvo_> ok, done
[14:01] <mvo_> thanks
[14:07] <sil2100> Damn, I feel terrible today, must be because of the heat
[14:16] <sil2100> om26er: hm, since I might have missed it, but did you fill in a bug for the b0rken video-playback from scopes?
[14:17] <om26er> sil2100, I will once I I try it on 135
[14:17] <om26er> its still being downloaded
[14:17] <sil2100> Ok, makes sense
[14:18] <sil2100> tvoss: ping! Did you have a moment to take a look at bug LP: #1338610 ?
[14:19] <sil2100> tvoss: I see charles pointed at you for more information
[14:21] <sil2100> popey: btw. since I'm completely not a click person, do you think the change you made to mediaplayer-app to hide the icon could have affected it not launching videos from the scopes? But I guess you only added a NoDisplay=true, right?
[14:21] <tvoss> sil2100, shelved, busy getting a silo landed right now :)
[14:21] <tvoss> sil2100, but will get to it asap
[14:21] <popey> sil2100: it shouldnt
[14:22] <sil2100> tvoss: thanks :) It's not a big issue, just wanted to make sure it's queued up in your TODO list somewhere
[14:22] <popey> sil2100: jhodapp tested it
[14:23] <tvoss> sil2100, with an emphasize on "somewhere" :)
[14:23] <jhodapp> sil2100: no, there's no way it would do that
[14:23] <sil2100> ;)
[14:24] <jhodapp> sil2100: does the mediaplayer-app come up after launching from the video scope, or not even coming up?
[14:24] <sil2100> om26er: ^
[14:26] <popey> it doesnt launch at all from video scope
[14:27]  * popey reboots and tries again
[14:28] <sil2100> hmmm
[14:29] <sil2100> Actually, the offending landing might have been in 134 even from what I see
[14:29] <sil2100> As libunity-scopes2 landed
[14:29] <sil2100> mhr3: hi! What did the recent unity-scopes-api landing carry? Could it have been responsible for the regression we're seeing with video playback not launching properly
[14:29] <sil2100> ?
[14:30] <mhr3> sil2100, no
[14:30] <ogra_> sil2100, ah, wasnt that the one with the extremely wordy changelog ?
[14:30] <ogra_> :P
[14:31] <mhr3> tedg, did you land the url-dispatcher change?
[14:31] <tedg> mhr3, Which one?
[14:32] <mhr3> tedg, file -> video?
[14:32] <tedg> mhr3, No, I marked it as land in a silo with the scopes.
[14:32] <tedg> mhr3, I did it, and charles reviewed, but it's waiting.
[14:32] <popey> sil2100: jhodapp http://paste.ubuntu.com/7809300/ thats what I get when I launch a video from the video scope
[14:33] <mhr3> tedg, k, does look like ual though^
[14:33] <om26er> jhodapp, the app doesn't come up
[14:34] <popey> also http://paste.ubuntu.com/7809306/ in my unity log
[14:34] <om26er> jhodapp, the app launching animating appears half onscreen and then goes away
[14:34] <sil2100> ogra_: exactly ;)
[14:34] <jhodapp> om26er: yeah I see that myself on the latest image
[14:34] <mhr3> sil2100, sounds like a desktop file gained NoDisplay=true, and something doesn't like that
[14:34] <kgunn> where is robru...i need to sing praises over this dashboard...man this thing is great!
[14:35] <jhodapp> mhr3: should it be something else?
[14:35] <popey> the simple test would be to edit the desktop file on the device and restart and try again
[14:36] <jhodapp> popey: yep
[14:36] <kgunn> ogra_: curious, when do you guys plan on an image spin ? (had 2 landings happen i'm curious about)
[14:36] <mhr3> jhodapp, tedg will probably know why he doesn't like NoDisplay :)
[14:36] <jhodapp> tedg: ^
[14:36] <ogra_> kgunn, we had one in the european morning ... i think sil2100 wanted one immediately after Mir landed
[14:37] <tedg> jhodapp, mhr3, if it's NoDisplay, it's not an application.
[14:38] <ogra_> kgunn, so i guess in a few hours, once Mir has migrated to the archive
[14:38] <kgunn> cool
[14:38] <jhodapp> tedg: so what's the proper way to not display the icon in the app scope but still have it launch?
[14:38] <tedg> jhodapp, Uhm, not. Why would you want that?
[14:38] <ogra_> (or faster if it moves quicker)
[14:39] <jhodapp> tedg: mediaplayer-app can't do anything except when launched from the video scope
[14:39] <jhodapp> tedg: so it makes no sense to launch it straight
[14:39] <sil2100> ogra_: I think Mir landed, so let me double-check and maybe kick a new image
[14:39] <jhodapp> popey: yep, works again after removing NoDisplay=true...so odd since it was working fine for me, no idea how
[14:39] <mhr3> tedg, imo that's misinterpreting NoDisplay
[14:39] <ogra_> sil2100, far from landed ... it only entered proposed
[14:39] <ogra_> (about 20min ago)
[14:39] <sil2100> ogra_: ok, then nvm!
[14:39] <popey> oh dear
[14:40] <mhr3> tedg, you probably want new X-UbuntuNoRun
[14:40] <jhodapp> tedg: so we definitely need a way of doing that
[14:40] <tedg> jhodapp, It makes no sense to me to have something that shows up as an app but then not have it in the app scope. Why not show the list of local videos when started?
[14:41] <jhodapp> tedg: because that's not what design designed for the mediaplayer-app
[14:41] <jhodapp> tedg: mediaplayer apps work this way on iOS and I'm assuming on Android as well
[14:42] <tedg> jhodapp, How do you select content independent of an app on those?
[14:42] <jhodapp> tedg: you launch it from somewhere else
[14:42] <jhodapp> tedg: like gallery, browser, etc
[14:44] <tedg> jhodapp, So yes, you can launch the video player that way, but it also shows up in applications. And then shows the recently played videos. (on Android)
[14:44] <jhodapp> tedg: ok, but that's besides the point...for Ubuntu Touch we don't want to display the mediaplayer-app icon in the app scope
[14:44] <tedg> mhr3, I'd argue that NoDisplay misinterprets the point of a Desktop file :-)
[14:45] <jhodapp> tedg: is there a way to accomplish this and still have it able to launch?
[14:46] <mhr3> tedg, maybe it is hacky, but it's just "dont display in menu" and not "don't dare to run"
[14:46] <tedg> jhodapp, As an application no, but the UX is seeming more like a trusted prompt session to me at this point.
[14:47] <tedg> tvoss, thoughts?
[14:47] <jhodapp> tedg: can you explain that some more?
[14:48] <tedg> jhodapp, Basically it's a set of Mir surfaces that are tied to an application. So I'd be saying "this is the gallery" even if on top of it there's a video playing in another app. Unity would present it as "Gallery" not an independent app.
[14:49] <tedg> Which makes sense to me. If it's not an application, it should be presented as part of something that is.
[14:49] <jhodapp> tedg: sounds reasonable, but what about the case where you launch it from the video scope?
[14:49] <jhodapp> tedg: what would it be apart of then?
[14:49] <tedg> jhodapp, the dash
[14:50] <tedg> jhodapp, That's what we're doing for purchases from the Click scope for instance.
[14:50] <jhodapp> tedg: implementation wise, how does it change?
[14:50] <jhodapp> tedg: from mediaplayer-app's perspective
[14:50] <ogra_> tedg, so we plan to keep the payui icon in the click scope ?
[14:50]  * ogra_ finds that extremely confusing ... why isnt that part of the store
[14:50] <tedg> ogra_, No, once trusted prompt session support lands it won't be an application anymore.
[14:50] <jhodapp> same here
[14:51] <tedg> jhodapp, You need a trusted helper to setup the prompt session. Then you tell media player to use it.
[14:51] <jhodapp> tedg: you set that up from within mediaplayer-app's C++ code itself/
[14:51] <jhodapp> ?
[14:51] <ogra_> we have the media-hub server
[14:52] <tedg> No, more like the media-hub would set it up.
[14:52] <tedg> jhodapp, Here's how it works in Pay: https://wiki.ubuntu.com/Pay/Architecture
[14:52] <tedg> pay-service does the setup, and pay-ui is, well, the UI.
[14:52] <jhodapp> tedg: when is the trusted helper stuff landing, any idea?
[14:53] <tedg> jhodapp, First pieces just landed. We need a couple more to complete it.
[14:53] <tedg> jhodapp, I was *just* harassing people about that :-)
[14:53] <jhodapp> tedg: ok, I doubt I could get to that before RTM though...is there a way we can "hack" remove the mediaplayer-app icon for now?
[14:53] <ogra_> harass more !
[14:54] <tedg> jhodapp, It's all software, there are always ways, but I'm -1 on them currently.
[14:55] <jhodapp> tedg: even if we had to blacklist mediaplayer-app in the click scope for now
[14:55] <tedg> Yup, -1 on that :-)
[14:55] <jhodapp> tedg: meaning you can't do it or don't want to do it?
[14:56] <ogra_> he doesnt like to ...
[14:56] <ogra_> :)
[14:56] <tedg> Don't want to. It's software, we can do anything.
[14:56] <jhodapp> tedg: but we have to do something like that and we have very limited time
[14:57] <jhodapp> tedg: it's very confusing to users to launch mediaplayer-app directly
[14:57] <tedg> jhodapp, I'd argue it's very confusing to users to see an app they can't launch in their panel.
[14:57] <jhodapp> tedg: but that's not up to us
[14:59] <tedg> I think this is one of those things we need to get right. So, I'd argue we have time for it.
[15:00] <jhodapp> tedg: that's in an ideal world...I know I don't have the time for it
[15:01] <jhodapp> tedg: you are welcome to take a stab at it if you have the time
[15:03] <jhodapp> tedg: what do you think?
[15:05] <tedg> jhodapp, I think spending the time on that is better than spending the time on adding work around and hacks.
[15:05] <tedg> jhodapp, Personally, I can't imagine getting to it.
[15:05] <tedg> Well, before the end of August.
[15:08] <jhodapp> tedg: right, so we need a very quick workaround and then we can file a bug to track actually doing it the proper way for an update to the RTM release
[15:15] <tvoss> jhodapp, why can't media-player app do anything unless when run from the video scope? That sound super wrong
[15:15] <jhodapp> tvoss: it doesn't have a way of displaying a list of media to play from within itself
[15:16] <jhodapp> tvoss: I'm not sure, that's how design wanted it
[15:17] <tvoss> bfiller, ^
[15:17] <tvoss> jhodapp, as I understand it, nothing prevents the media app from accessing content on the device, it is unconfined
[15:17] <jhodapp> tvoss: right, but there's no design for choosing content from within the mediaplayer-app
[15:18] <tvoss> bfiller, can you help out here? jhodapp , couldn't we replicate the music-app design?
[15:18] <popey> seems redundant to show content when we have the video scope
[15:18] <bfiller> jhodapp: what's the question?
[15:18] <ogra_> tvoss, volunteering to implement that ?
[15:19] <ogra_> bfiller, we cant hide the mediplayer icon from the click scope it seems
[15:19] <jhodapp> bfiller: design never provided a way to play video content from within the mediaplayer-app if you launch the app directly and not from a scope
[15:19] <ogra_> hiding it makes ubuntu-app-launch not consider it for execution
[15:19] <bfiller> ogra_, jhodapp : that's right
[15:19] <jhodapp> bfiller: and so yes, we need to be able to hide the mediaplayer-app icon from the click scope
[15:19] <jhodapp> bfiller: NoDisplay=true in the desktop file makes the app not launchable
[15:19] <bfiller> jhodapp: no we don't, the app displays an appropriate message when launched from the scope
[15:20] <bfiller> this has been discussed before with deisgn
[15:20] <bfiller> should be fine the way it is today
[15:20] <ogra_> uh, really ?
[15:20] <bfiller> yup
[15:20] <popey> with an icon that does nothing?
[15:20] <ogra_> thats rather ugly ...
[15:20] <jhodapp> bfiller: I still get a lot of messages from people confused about mediaplayer-app when they launch it directly
[15:20] <ogra_> popey, it does something
[15:20] <ogra_> tap it :P
[15:21] <bfiller> two options: hide it from scope or live with it :)
[15:21] <ogra_> its just pointless to have an error message generator icon by default
[15:21] <jhodapp> bfiller: right, I'd like to hide it but there doesn't seem to be a way currently
[15:21] <bfiller> I think we have a lot bigger problems then this guys
[15:22] <jhodapp> bfiller: agreed...that's why I wanted a simple way to not display the icon in the click scope, file a bug to do it a proper way later, and be done with it
[15:22]  * sil2100 just reads in
[15:23] <sil2100> So in the end the NoDisplay=true change caused the regression? I would say let's revert it and just leave the icon as it is
[15:23] <jhodapp> sil2100: yes, please revert it
[15:23]  * sil2100 checks if he can do it
[15:23] <jhodapp> sil2100: we can get you another MR that undoes it if necessary
[15:23] <sil2100> Hah, I seem to have teh powa, let me try
[15:24] <bfiller> jhodapp: apparently it's not that simple, tedg knows about it. It's what we wanted from the beginning but apparently there are issues with hiding it
[15:24] <jhodapp> bfiller: ok, so I guess we'll just revert it and live with the icon for now
[15:25] <bfiller> jhodapp: but yes please file a bug about it if you don't mind
[15:25] <sil2100> jhodapp: ok, so I could revert it manually (which would be faster probably) but since this change will be in for a while and is not jsut a 'quick temporary workaround', let me do it through CI Train so that it's all merged in and nice
[15:25] <jhodapp> bfiller: sure
[15:25] <jhodapp> sil2100: ok
[15:28] <alecu> hi all, I need some info on the procedure to build images...
[15:28] <alecu> the click scope needs to run a binary when the image is being built, to create a database of departments for the preinstalled apps.
[15:28] <alecu> We have the binary ready, and we'd like to know how to get it run in the image build process, and who to ping about this.
[15:28] <cjwatson> probably want to add a hook to livecd-rootfs
[15:29] <cjwatson> but actually
[15:29] <ogra_> yeah
[15:29]  * cjwatson thinks
[15:29] <ogra_> live-build/ubuntu-touch/hooks/60-install-click.chroot in livecd-rootfs should be the right place
[15:30] <cjwatson> is it definitely just preinstalled apps?  does the database get incrementally upgraded with user-installed apps?  how about carrier apps in /custom?  if the database also includes user-installed apps, what happens on image upgrade?
[15:30] <ogra_> yeah, probably an additional boot hook is needed
[15:31] <alecu> cjwatson: this database gets filled with new apps installed by the user, when they are installed by the click scope.
[15:31] <sil2100> jhodapp: can I get an approval from you? :) https://code.launchpad.net/~sil2100/mediaplayer-app/revert_239/+merge/227208
[15:31] <jhodapp> sil2100: sure
[15:32] <alecu> cjwatson: about carrier apps... I guess that the binary should be run after those are added by the carrier, yes.
[15:32] <jhodapp> sil2100: approved
[15:33] <alecu> cjwatson: regarding image upgrades... we need to think more about that point.
[15:34] <ogra_> we have a boot hook architecture for that bit
[15:34] <ogra_> (image updates always require reboots)
[15:34] <sil2100> jhodapp: thanks!
[15:35] <alecu> ogra_: sounds good
[15:35] <sil2100> ogra_: I would say, once we revert mediaplayer-app and mir migrates completely, let's kick a new image :)
[15:35] <ogra_> alecu, whatever extracts the customization tarball should also call your binary though ... since that might not require a reboot ... talk to cwayne for that
[15:35] <cjwatson> alecu: this needs more thought before you put anything in livecd-rootfs
[15:35] <cjwatson> alecu: I would recommend that you have multiple databases in different bits of the filesystem
[15:35] <cjwatson> alecu: if that's possible
[15:36] <alecu> cjwatson: right. I'll take a look at that.
[15:36] <ogra_> sil2100, yeah, i wonder what happens first :)
[15:36] <sil2100> I'm auto-publishing this one once it builds, so I hope it will only take a few moments
[15:36] <cjwatson> alecu: if it has to be a single database, then you should make sure it's in the writeable area of the filesystem, and you should generate the whole thing at boot time using a system-level click hook, rather than putting anything in livecd-rootfs
[15:37] <ogra_> depends how slow it is :)
[15:37] <cjwatson> alecu: though, thinking about it, if it's multiple databases, then you need to replicate all of click's logic for which of different versions of apps take precedence
[15:37] <cjwatson> alecu: so if it can be made fast enough to run at boot from a hook, then that would be preferable, IMO
[15:37] <cjwatson> alecu: and then you can just have a single database
[15:37] <alecu> cjwatson: the binary needs network access to generate this db, so that's why I'm proposing to generate it at image build time, or at carrier customization time.
[15:38] <ogra_> oh
[15:38] <cjwatson> alecu: then the merging is distinctly problematic
[15:38] <cjwatson> and you MUST have multiple databases in that case
[15:38] <cjwatson> it just won't work otherwise
[15:38] <cjwatson> there'll need to be one for preinstalled, one for custom, one for user-installed - and the scope will need to replicate all of click's logic
[15:38] <ogra_> the network bit at image build time might be problematic ... depending on waht you want to access
[15:38] <cjwatson> that too
[15:39] <cjwatson> is there a mail thread about this design?  I think it needs discussion
[15:39] <ogra_> but it will also be problematic on first boot ... before you even set up a SIM or WLAN
[15:40] <cjwatson> you could generate it once you have network access, perhaps?  or do you need it before?
[15:40] <ogra_> again ... depending how slow/resource hungry it is ...
[15:40] <cjwatson> really shouldn't need to be that slow
[15:40] <ogra_> you dont want your phone go down to its kneew after enabling the wlan for the first time
[15:41] <ogra_> *knees
[15:41] <alecu> cjwatson: I can start a mail thread with the thoughts on this so far.
[15:41] <cjwatson> the benefit of using click hooks for anything that needs to iterate over all installed packages is that click gives you a directory full of symlinks pointing to each of the installed apps; this honours things like users or carriers installing a newer version of a preinstalled app, users or carriers hiding a preinstalled app, etc.
[15:41] <cjwatson> also consider multi-user support
[15:41] <alecu> cjwatson: yes: we plan to have a local db for each user, with the apps they have installed.
[15:41] <cjwatson> if it's something visible per-user, then you might want to consider it being a user-level hook rather than system-level; individual users can hide individual preinstalled apps
[15:42] <cjwatson> alecu: is there a reason you can't just fish this out of the existing click database?
[15:42] <cjwatson> perhaps with some small extensions?
[15:42] <alecu> cjwatson: hmmm... it might be possible.
[15:43] <cjwatson> even if we have to extend click a little bit, it would be better than creating a whole new parallel database
[15:43] <cjwatson> but yeah, mail thread so that I can understand the requirements would be helpful
[15:44] <alecu> cjwatson: the thing is that the store side wants to be able to move apps between departments independently of the category the devels have set in the .desktop file
[15:44] <cjwatson> querying the click database at run-time should in general be fast enough
[15:44] <alecu> cjwatson: and also, there's no department in the manifest
[15:44] <cjwatson> hm, right, interesting
[15:44] <cjwatson> maybe we could have a libclick call to set the department or something
[15:45] <kgunn> sil2100:  can i get a silo for line45 & line16?
[15:45] <kgunn> line16 at your leisure, line45 i'm kinda antsy for
[15:46] <kgunn> sil2100: line7 is now irrelevant...should i delete ?
[15:47] <sil2100> kgunn: yeah, you can delete it
[15:47] <sil2100> Let me try assigning a silo for you
[15:47] <sil2100> At least for line 45 ;)
[15:48] <sil2100> (since I guess mvo_ is already off-duty)
[15:48] <bfiller> sil2100: I need silos for line 46 and 48 if you can. 46 would be the priority..
[15:48] <kgunn> thanks!
[15:48] <sil2100> bfiller: ok, then a silo for 46 (at least)
[15:48] <bfiller> sil2100: cheers
[15:50] <sil2100> kgunn: just be sure to coordinate with mterry, since he has unity8 locked in as well
[15:50] <kgunn> sil2100: yep...he's waiting on security reviews so no worries
[15:51] <brendand> popey, e
[15:51] <brendand> popey, ignore that. stray keystroke
[15:51] <popey> aww
[15:52] <sil2100> bfiller, kgunn: silos assigned for you (for now only for the priority ones)
[15:52] <mvo_> sil2100: I am about to leave indeed (and was in a meeting before (as you know :))
[15:52] <sil2100> ;)
[15:52] <kgunn> thanks
[15:52] <sil2100> No worries, I guess robru will pick up in a moment
[15:52] <mvo_> thanks for taking care of this sil2100
[15:55] <robru> yeah, I'm just having a problem where firefox is crashing on startup, trying to troubleshoot that now. I guess I can do landing work on my other laptop if anybody needs anything urgently
[15:57] <sil2100> ogra_, robru, plars, popey: I might be a few minutes late for the meeting
[15:59] <sil2100> ...oor maybe not
[16:00] <alecu> cjwatson: ogra_: I've found a thread where we discuss departments with the server and sdk guys, and a document describing the solution we implemented; will forward all of that to you.
[16:03] <cjwatson> alecu: thanks
[16:04] <popey> balloons: you around for the next hour to push some clicks to the store?
[16:04] <balloons> popey, I'm here
[16:04] <popey> brilliant
[16:04] <popey> want to get them in before next image build if possible
[16:04] <balloons> sure thing.. what's on the docket?
[16:05] <popey> balloons: all of them ☻
[16:05] <balloons> popey, :-)
[16:06] <balloons> k, submitting everything
[16:10] <popey> balloons: http://s-jenkins.ubuntu-ci:8080/job/clock-app-click/lastSuccessfulBuild/artifact/out/com.ubuntu.clock_1.0.461_all.click  please
[16:10] <popey> dpm: any reason not to push latest reminders trunk to store?
[16:11] <balloons> popey, I have sent requests for every app, using the last builds
[16:11] <balloons> just look at your queue I think you'll find it full
[16:11] <popey> oh, wow.
[16:11] <popey> well, some haven't biult yet
[16:11] <popey> e.g. calendar
[16:11] <dpm> popey, I guess simply because we didn't have any big features that had landed. But now with the Oxide switch, it might be a good time to do an update
[16:12] <popey> yeah
[16:12] <balloons> popey, I can push new stuff for anything you wish after you get through everything :-)
[16:12] <popey> thanks balloons
[16:12] <popey> weather and calendar are building
[16:12] <balloons> I did see that, but you wanted it now :-)
[16:13] <popey> well, i didnt, i wanted in the next hour ☻
[16:13] <popey> (I was going to wait for calendar)
[16:13] <balloons> I'll just resubmit then
[16:13] <popey> but never mind, i love the full push of them all, nice !
[16:13] <popey> we should always do that, just shove them all in ☻
[16:13]  * popey run the reviewer tools on them
[16:17] <plars> sil2100: oh, one thing I just thought of, did you ever get a chance to look, or find someone to look at the health-check failures to see if you believe they are legitimate regressions from trusty, or if a new baseline is in order? There's certainly a reproducible difference from trusty, but whether that's expected/acceptable probably needs to be decided on a case by case basis
[16:18] <balloons> popey, sent the new calendar up
[16:18] <popey> thanks balloons
[16:18] <sil2100> plars: ah, sorry about that, still didn't have a good look at that, I promise to do that next week - I actually wanted to get a promoted image before proceeding with that
[16:18] <sil2100> Which happened actually
[16:19] <plars> sil2100: understand :)
[16:32] <cjwatson> popey,balloons: Which libexiv2 ABI was gallery-app built against?  The one in utopic, or the one in utopic-proposed?
[16:32] <cjwatson> popey,balloons: Assuming you pushed that
[16:32] <popey> cjwatson: i just push whatever I'm given, I don't build it..
[16:33] <balloons> cjwatson, I did not. And it would be against utopic if you use jenkins
[16:33] <cjwatson> Can you find out?  It's a problem if it's -13
[16:33] <cjwatson> objdump -p <binary> | grep exiv2   should say
[16:35] <ogra_> phablet@ubuntu-phablet:~$ objdump -p /usr/share/click/preinstalled/com.ubuntu.gallery/2.9.1.1009/gallery-app|grep exiv2  NEEDED               libexiv2.so.12
[16:35] <ogra_> cjwatson, current one is 12
[16:36] <popey> confirmed on gallery build 1012
[16:37]  * ogra_ notes he is getting a new camera-app ... didnt we block that too ?
[16:38] <cjwatson> camera doesn't use exiv2, we checked that
[16:38] <ogra_> phablet@ubuntu-phablet:~$ objdump -p /usr/share/click/preinstalled/com.ubuntu.camera/3.0.0.297/camera-app|grep exiv
[16:38] <ogra_> phablet@ubuntu-phablet:~$
[16:38] <ogra_> yeah
[16:38] <cjwatson> stale seed comment
[16:38] <ogra_> yup
[16:38] <cjwatson> ok, all good for now
[16:39] <popey> robru: balloons I'm currently blocked approving core apps clicks into the store because the click reviewers tools doesn't like unicode in the .desktop files. so feel free to kick an image if you need to and we will approve these later.
[16:39] <robru> popey, how much later? I'm not in any super hurry
[16:39] <robru> popey, in fact I'm waiting for mediaplayer-app anyway
[16:39] <ogra_> yeah
[16:39] <ogra_> but that shouldnt have utf8 in the .desktop
[16:40] <popey> why?
[16:40] <popey> translations...
[16:40] <popey> http://paste.ubuntu.com/7809782/
[16:40] <ogra_> well, i thought because it was not supposed to be shown
[16:41] <ogra_> popey, erm
[16:42] <ogra_> popey, we dont have a mediaplayer-app click :P
[16:42] <ogra_> its a deb
[16:44] <ogra_> phablet@ubuntu-phablet:~$ click list |grep media
[16:44] <ogra_> phablet@ubuntu-phablet:~$
[16:44] <ogra_> ...
[16:44] <ogra_> phablet@ubuntu-phablet:~$ dpkg -l |grep mediaplayer
[16:44] <ogra_> ii  mediaplayer-app                                      0.20.5+14.10.20140502-0ubuntu3              armhf        Ubuntu Media player
[16:44] <ogra_> phablet@ubuntu-phablet:~$
[16:44] <ogra_> robru, so you should be fine once rmadison tells you it migrated
[16:47] <popey> robru: not much longer, it's a problem my end, I can fix, 30 mins.
[16:47] <robru> popey, sure, i can wait
[16:47] <popey> ta
[16:50] <cjwatson> BTW mir migrated a while back - shouldn't we have an image build for that?
[16:50] <robru> cjwatson, yeah, just waiting for mediaplayer-app and popey to upload some clicks
[16:50] <cjwatson> ok
[17:00] <sil2100> Yeah, since the 'mir-only image' idea is anyway tainted, as we landed many things in-between
[17:15] <robru> popey, how's it going?
[17:15] <popey> robru: good, a few done, few more to do
[17:15] <robru> popey, k, no worries.
[17:15] <popey> wont be long
[17:29] <popey> robru: all done
[17:29] <popey> thanks
[17:29] <robru> popey, sweeeet
[17:30] <robru> popey, ogra_ cjwatson : image kicked
[17:34] <imgbot> [17:36] <sil2100> \o/
[17:36] <sil2100> Ok, time to lay down, damn it's hot...
[17:36] <sil2100> o/
[17:39] <robru> oh awesome
[18:26] <tvoss> robru, hey there :)
[18:26] <tvoss> robru, for silo 2, in the ppa, could you cancel the powerpc build?
[18:26] <tvoss> robru, trust-store does not build on powerpc due to mir not being available there
[18:28] <tvoss> cjwatson, in case you are still around, could you cancel the powerpc build in silo 2?
[18:33] <cjwatson> well, not really necessary, it'd dep-wait if only the powerpc queue weren't backed up due to a gazillion gcc uploads
[18:33] <cjwatson> let's see
[18:33] <cjwatson> sigh, doko managed to occupy all the builders in parallel
[18:34] <cjwatson> tvoss: cancelled
[18:34] <tvoss> cjwatson, thank you :) with that, my silo should get ready to publis
[18:34] <tvoss> h
[18:34] <cjwatson> yep, should rescan in ~4 mins
[18:36] <cjwatson> tvoss: hmm, except that the last version in the archive built on all architectures
[18:36] <cjwatson> so I guess we'll have to tear something out
[18:37] <tvoss> cjwatson, tearing something out as in?
[18:37] <cjwatson> of the archive
[18:38] <cjwatson> you can't normally regress architecture support, so in order to allow this kind of thing we have to remove the no-longer-buildable binaries from utopic
[18:38] <cjwatson> tvoss: why doesn't trust-store build-depend on libmirclient-dev?
[18:39] <cjwatson> it must only be building by luck
[18:39] <tvoss> cjwatson, yup, you are very right :)
[18:39] <cjwatson> I guess something else depends on it on most architectures, but you can see the consequences in the arm64 build failure
[18:40] <tvoss> cjwatson, yup, would the build on arm64, powerpc and ppcel64 be prevented with that build dependency?
[18:44] <cjwatson> tvoss: well, it's failing now, so won't be worse :)
[18:44] <cjwatson> tvoss: I think it might build on arm64
[18:45] <tvoss> cjwatson, with the limitation in terms of platforms for the new version, do I need to do anything?
[18:46] <cjwatson> tvoss: anyway, while I'd appreciate it if you did that, it's not necessary right now
[18:46] <alecu> hey all: I've got a few branches that are passing the ci check
[18:46] <alecu> but are failing the autolanding step
[18:46] <cjwatson> tvoss: I've removed the no-longer-buildable binaries; wait until "rmadison -s utopic,utopic-proposed -S trust-store" no longer lists arm64/powerpc/ppc64el, which should happen in about 20 minutes
[18:46] <alecu> any ideas?
[18:46] <cjwatson> tvoss: and then you can do a watch-only build
[18:47] <cjwatson> (I don't know what you just did ...)
[18:47] <cjwatson> ah, the build-dep
[18:47] <cjwatson> ok, that should all work out in time then
[18:48] <tvoss> cjwatson, hopefully :)
[18:49] <cjwatson> I'll cancel the powerpc build again once it shows up
[18:50] <cjwatson> done
[18:52] <cjwatson> and scored up arm64
[18:53] <sergiusens> what's up with the powerpc builders?
[18:53] <alecu> fginther: do you know if there's any difference between the ci jenkins and the autolanding jenkins for click scope? There are a few click-scope branches that are passing the ci step, but are consistently failing the autolanding step, and only on armhf.
[18:54] <ogra_> sergiusens, the doko fever has them
[18:54] <sergiusens> ah
[18:54] <sergiusens> there goes my wish of testing and landing today :-P
[18:54] <sergiusens> gcc and friends?
[18:55] <ogra_> dunno, just referring to what cjwatson said above
[18:55] <cjwatson> sergiusens: doko uploaded at least five gcc packages at about the same time
[18:55] <cjwatson> I'm not 100% pleased :)
[18:55] <cjwatson> even with quite a good build farm that still doesn't leave a lot of room for anyone else
[18:56] <robru> tvoss, oops, sorry about that, was on lunch break
[18:56] <sergiusens> I guess build time doesn't affect the queueing system yet :-)
[18:56] <cjwatson> sergiusens: if you have specific things you're waiting for then tell me and I'll bump them up the queue a bit
[18:57] <robru> alecu, what branches? also ping cihelp for autolanding issues.
[18:57] <sergiusens> cjwatson: just https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-013/+build/6191982 ... but as I checked the link again; it started to build :-)
[18:57] <robru> alecu, or vanguard is cjohnston right now ;-)
[18:58] <alecu> robru: great.
[18:58] <robru> cjohnston, ^ fix this before my vanguard shift starts in 1.5 minutes please ;-)
[18:58] <cjwatson> sergiusens: ok
[18:58] <alecu> robru: the branches are: https://code.launchpad.net/~stolowski/unity-scope-click/provide-default-db/+merge/226849 and https://code.launchpad.net/~alecu/unity-scope-click/scopes-short-id/+merge/226820
[18:58] <cjohnston> robru: lol
[18:59] <alecu> :-)
[18:59] <cjwatson> sergiusens: yeah, sagari's on the case now, that should help
[18:59] <cjwatson> (it's pretty much our fastest builder, unless maybe the ppc64el ones are a bit better)
[19:00] <sergiusens> nice to see it servicing our builds then :-)
[19:00] <alecu> robru: we have a few more branches that show that the ci step seems to work fine, but those are the two trying to autoland and failing on armhf.
[19:01] <robru> alecu, hum, yeah, it looks like test failures, I'm not sure why those tests would pass in ci and fail in autolanding.
[19:01] <popey> balloons: can you keep an eye on bug 1343505 plese - am prepping branches
[19:01] <ogra_> oh, look, someone noticed the firends-app is gone ... on the ML
[19:01] <ogra_> seems we didnt clean up everything for him :(
[19:02] <robru> ogra_, hrm, how do we respond to that?
[19:02] <robru> cjohnston, any ideas with that autolanding failure? i'm stumped
[19:03] <cjohnston> robru: with 6 hours in between the ci and the autolanding, I'd guess maybe a new image.. fginther any ideas?
[19:03] <alecu> robru: yes, those failing tests are not new things in any of those two branches; one of those branches is not even related to anything in those tests.
[19:03] <robru> alecu, oh, so you expected the failures?
[19:03] <balloons> popey, ohh basically url-dispatcher in places it's not needed eh? You going to do all the mp's? If so I can review
[19:03] <ogra_> robru, dunno, have him check ~/.local/share/pplication for left over .desktop files, though that should have been removed not sure why it wasn't, thats likely a bug
[19:03] <popey> balloons: yeah
[19:03] <alecu> robru: no, we didn't expect those failures at all.
[19:03] <popey> balloons: assuming i dont bollocks up the cmake files
[19:04] <robru> ogra_, hm, are we reading the same mail? i read it more as "hey, bring back friends" and not as "hey, help me clean up a .desktop file now that friends is gone"
[19:05] <ogra_> robru, we read the same mail ... but we wont bring back friends so i ignored that tone ;)
[19:05] <ogra_> (and focused on the actual issue he seems to have)
[19:05] <robru> alecu, oh sorry I misread you. I thought you said those failures have been happening for a while, but what you said was, the branches don't affect the parts of the code that are failing tests
[19:05] <alecu> robru: exactly.
[19:06] <alecu> robru: (actually, one of the branches is related to the stuff being tested there, but it should not fail like that).
[19:07] <alecu> robru: so, the weird thing is why is it failing only on the autolanding jenkins, and why only on armhf.
[19:07] <fginther> cjohnston, robru, hmm, having a look.
[19:08] <robru> alecu, yeah it's all very weird.
[19:08] <robru> fginther, thanks
[19:09] <alecu> robru: I'm about to propose a branch to temporarily disable those two tests, since I want to unblock landings in the click scope, and since the tests seem to be working fine on amd64 and i386.
[19:10] <alecu> robru: if you can think of any solution, or find any difference on the jenkins, let me know and I'll re-enable those tests.
[19:10] <robru> alecu, hang on, fginther might fix it, he's the man.
[19:10] <alecu> ah, great.
[19:12] <fginther> alecu, there is a new version of libunity-scopes2_0.5.2+14.10.20140715-0ubuntu1_armhf.deb, could that have introduced a regression?
[19:12]  * alecu looks
[19:15] <alecu> fginther: it doesn't seem so. The failing tests are testing a feature that only depends on QSqlDatabase (and sqlite underneath it).
[19:15] <alecu> fginther: so I can't see how libunity-scopes could affect it.
[19:16] <fginther> alecu, there are a few different dependencies, libxdamage1_1%3a1.1.4-2_armhf.deb and python3 3.4.1-7. nothing obviously sql related
[19:16] <alecu> fginther: there was a recent click scope change for that dependency, though.
[19:16]  * alecu looks further.
[19:17] <alecu> here: http://bazaar.launchpad.net/~unity-team/unity-scope-click/devel/revision/328
[19:17] <alecu>          sqlite3 (>= 3.8.5),
[19:17] <fginther> alecu, I triggered a new -ci build of https://code.launchpad.net/~alecu/unity-scope-click/scopes-short-id/+merge/226820 to probe for any possible differences between the ci and autolanding jobs
[19:17] <alecu> that's the new dependency
[19:18] <alecu> fginther: great, thanks.
[19:18] <robru> infinity, cjwatson: who's around? need an archive admin ack for new binary package + looks like a few new deps. https://ci-train.ubuntu.com/job/landing-002-2-publish/lastSuccessfulBuild/artifact/packaging_changes_trust-store_0.0.1+14.10.20140717.8-0ubuntu1.diff
[19:18] <robru> yeah, that one
[19:19] <cjwatson> robru: one moment
[19:19] <robru> cjwatson, thanks
[19:20] <cjwatson> tvoss: Isn't this an ABI change?  Some symbols renamed
[19:21] <cjwatson> tvoss: I don't understand why this doesn't come with a SONAME change
[19:21] <tvoss> cjwatson, yup, but nothing used trust-store in the archive, yet
[19:21] <cjwatson> True
[19:21] <cjwatson> robru: Please wait for the arm64 build to finish though
[19:22] <robru> cjwatson, bah, citrain told me it was ready to publish! which means the build job completed!
[19:22] <cjwatson> It's an architecture not currently in utopic
[19:22] <cjwatson> Apparently citrain doesn't bother to wait for builds it doesn't think will be needed for proposed-migration, even if they're actually building right now
[19:23] <cjwatson> Which is kind of suboptimal design wrt the Launchpad copier
[19:23] <robru> cjwatson, yeah, I think we've run into this before (build job not waiting for all arches). I'm not very familiar with the logic that citrain uses to wait for which arches to finish building.
[19:23] <cjwatson> tvoss: a *directory* in /usr/bin/ ?  seriously?
[19:23] <cjwatson> -rwxr-xr-x root/root    195072 2014-07-17 20:05 ./usr/bin/trust-store-tests/remote_trust_store_test
[19:24] <tedg> It seems the spreadsheet is messed up for the silo 10 page.
[19:25] <cjwatson> tvoss: AA ack for now but please move those to /usr/lib/trust-store-tests/ - there's no point putting things under /usr/bin/ if they aren't going to be on the $PATH, which this won't be because subdirectory
[19:25] <tedg> It's looking empty but we have stuff in it.
[19:25] <tedg> (that we want to mark as tested)
[19:25] <cjwatson> robru: ok, the arm64 build failed so you can go ahead
[19:25] <robru> cjwatson, yaaaaay! failure makes it ok!
[19:26] <tvoss> cjwatson, here we go https://bugs.launchpad.net/trust-store/+bug/1343533
[19:26] <cjwatson> thanks
[19:26] <tvoss> thanks for the ack
[19:27]  * tedg wonders what would happen if he just marked 10 as tested.
[19:27] <robru> cjwatson, I think the next version of juju will install under /usr/bin/me/love/colin/long/time.
[19:28] <robru> tedg, marking a silo tested without testing? citrain may shoot deadly beams into your eyes and then explode.
[19:28] <tedg> robru, No, it's tested, just the spreadsheet is messed up.
[19:29] <robru> tedg, oh, i thought I fixed the recent spreadsheet implosion, hang on
[19:30] <robru> tedg, ok should be back now
[19:31] <cjwatson> robru: I have a big reject button here and not afraid to use it
[19:31] <tvoss> cjwatson, :)
[19:31] <robru> cjwatson, hehehe
[19:31] <tedg> robru, Cool, marked tested, thanks!
[19:31] <robru> tedg, you're welcome!
[19:32] <fginther> alecu, https://code.launchpad.net/~alecu/unity-scope-click/scopes-short-id/+merge/226820 passed another CI run after "Merge tip of devel", want to try and land this again?
[19:33] <alecu> fginther: sure
[19:33] <cjwatson> fginther: so what does it take to add new channels to the CI dashboard, for RTM?
[19:34] <cjwatson> fginther: for next week, I expect we'll have a channel called something like "stable-staging-proposed" (exact name TBD) as we dry-run
[19:34] <imgbot> [19:35] <imgbot> [19:36] <fginther> cjwatson, There is some jenkins configuration work to create some dedicated jobs for that channel and then some on the dashboard to make the results show up in the right place (plars, josepht,  please correct me if I'm wrong)
[19:36] <popey> ogra_: 403 on that url
[19:36] <robru> yaaaaaaaaaaaaaaaaaaaaaaay I made an image!
[19:36] <plars> fginther: indeed, what's the new channel?
[19:36] <plars> oh I see
[19:36] <plars> it's not there yet
[19:37] <plars> just let me know when it's there, and I'll set up smoke jobs on it
[19:37] <fginther> cjwatson, I've asked asac for input on where exactly the rtm image should show up on the dashboard
[19:38] <fginther> plars, that's about a days effort or less?
[19:38] <plars> fginther: yes
[19:38] <cjwatson> fginther,plars,josepht: do you need to have things configured for the apt archive that the image is built from as well, or is it just a channel?
[19:38] <popey> plars: fginther: will reminders appear on the dashboard soon?
[19:39] <plars> popey: at the moment, it has lots of dependency issues. I think balloons was taking a look at how to resolve that
[19:39] <cjwatson> plars: it won't be there until next week - is it possible to set things up in advance (once I agree the name with Stéphane, so tomorrow) so that we can dry-run as smoothly as possible?  I expect there'll be a fair few hiccups and it would be nice to avoid the ones we can predict at least :-)
[19:40] <plars> cjwatson: from the smoke test side, we should just need the channel name
[19:40] <plars> cjwatson: sounds good
[19:40] <fginther> popey, plars, I'm working to get adt-run working to do that. If it works and we can still grab the same set of artifacts, it shouldn't be too long
[19:40] <cjwatson> plars: ok, I'll let you know as soon as we've agreed the name then
[19:40] <cjwatson> thanks
[19:40] <popey> ok
[19:41] <cjwatson> plars: how about jobs for CI Train silo testing - is that also in your bailiwick?
[19:42] <plars> cjwatson: that's not me, sorry
[19:42] <cjwatson> ok
[19:54] <robru> cjwatson, are you talking about the jenkins jobs that control citrain assigning/building/publishing?
[20:33] <tvoss> robru, could you hit merge & clean on silo2 once the migration is done?
[20:34] <robru> tvoss, sure
[20:34] <tvoss> robru, also: could you reconfigure silo 5, I removed a source package
[20:34] <robru> tvoss, ok
[20:34] <tvoss> robru, thanks
[20:35] <robru> tvoss, which source package?
[20:35] <tvoss> ubuntu-system settings
[20:36] <robru> tvoss, ah you deleted it from the ppa already?
[20:36] <tvoss> robru, nope
[20:36] <tvoss> just from the spreadsheet
[20:36] <robru> tvoss, oh it's not in the ppa... i guess that one never built?
[20:37] <tvoss> robru, thank you
[20:37] <robru> tvoss, you're welcome!
[20:37] <cjwatson> robru: er, I think I'm horribly confused actually, never mind
[20:38] <robru> cjwatson, ok
[20:38] <alecu> fginther: even after merging tip of devel, it keeps failing like before: https://code.launchpad.net/~alecu/unity-scope-click/scopes-short-id/+merge/226820
[20:40] <fginther> alecu, I'm stumped, but the symptoms indicate there is some difference between the two jobs. I'm taking a closer look at that
[20:41] <alecu> thanks
[20:43] <robru> cjwatson, because if you want to poke at the citrain code and investage it for RTM issues, that code is at lp:cupstream2distro, under a dir called 'citrain'.
[20:45] <fginther> alecu, all of the autolanding failures are happening on the same host. I've disabled it and will try the job again while looking for other possible issues
[20:46] <cjwatson> robru: yep, have poked that before - sil said he was already working on it though
[20:46] <robru> yeah
[20:46] <cjwatson> robru: so I'm working through the other hundred things I have to do :)
[20:46] <robru> cjwatson, hehe
[20:51] <popey> robru: any idea why http://people.canonical.com/~ogra/touch-image-stats/137.changes is zero bytes long?
[20:51] <robru> popey, nope, but earlier it was 403'ing, so it seems like ogras script that generates those is broken
[20:51] <popey> ok
[20:52] <robru> fginther, just got a nagios ping about ps-mako-04, is that your doing just now?
[20:52] <fginther> robru, nope, that's not something I've done
[20:52] <robru> oh
[20:56] <robru> fginther, UGH my dns is broken, can't get into any *.ubuntu-ci pages even though I'm on the VPN
[20:56] <fginther> robru, the device is present and working. I have no idea what caused the alert
[20:57] <robru> fginther, alright then, thanks, I'll resolve it in pagerduty
[20:57] <robru> fginther, must have been temporary, pagerduty resolved itself
[20:58] <robru> fginther, now, ps-mako-03 is down ;-)
[20:58] <fginther> robru, yep, I just noticed that through nagios
[20:58] <robru> fginther, I dunno what's wrong with my DNS, the VPN has the DNS set there, and I can ping the ubuntu-ci DNS server
[20:59] <fginther> it failed to download the flash image and got stuck in flashboot.
[20:59] <fginther> robru, ps-mako-03 should be ok again soon. I applied https://wiki.canonical.com/UbuntuEngineering/CI/Playbook#Recovering_a_touch_device_from_a_stuck_job_when_image_failed_to_download
[21:00] <fginther> robru, DNS is rarely my friend when it doesn't work
[21:00] <robru> fginther, this is weird because it means I can't access any of the jenkinses either
[21:00] <fginther> robru, have you tried a VPN disconnect/connect ?
[21:01] <robru> fginther, well, I wasn't connected, so I had only just connected to the VPN just now when I noticed it wasn't working. I guess I can try to reconnect
[21:03] <robru> fginther, yep, nope, can't get it
[21:03] <fginther> robru, gah!! I told nagios to ignore cyclops-node09, but I guess I didn't due it right. Sorry for the alerts there
[21:04] <robru> fginther, no worries
[21:06]  * popey tickles balloons with bug 1343505
[21:33]  * balloons reviews bug 1343505 for popey
[21:34] <alecu> fginther: it landed now... thanks for fixing it!
[21:35] <fginther> alecu, hmmm. that's good and bad.. Good that it is passing now, bad that there is likely something mysteriously wrong with that host
[21:36] <fginther> alecu, I'll keep it from being used until we can figure out what's different about it
[21:36] <fginther> alecu, thanks for your patience
[21:36] <alecu> no problem, thanks for finding that.
[21:37] <popey> thanks balloons
[22:52] <kgunn> curious....unity8 in silo12 says packages still migrating, but link to jenkins says success...which is true?
[22:53] <robru> kgunn, what, this page? https://ci-train.ubuntu.com/job/check-publication-migration/31540/console
[22:53] <robru> kgunn, on that page, 'SUCCESS' means 'yes, we successfully checked on the status of these packages'
[22:53] <kgunn> robru: lol...ok
[22:53] <robru> kgunn, use rmadison when in doubt, it is authoritative