[00:06] <ToyKeeper> So, after configuring a facebook account in UT in the online accounts app...  should the facebook app still be asking for username and password?
[00:07] <xnox> ToyKeeper: i think so. facebook app is a webapp. online account / facebook would only work with something like friends app, no?
[00:07] <ToyKeeper> ... but IIRC the Friends app was removed.
[00:08] <xnox> ToyKeeper: correct.
[00:09] <ToyKeeper> Seems like we should probably either remove the facebook account setting or attach something useful to it.
[00:14] <ToyKeeper> ... like make it sync contacts.
[00:16] <slangasek> stgraber, bdmurray: ok, so since there are multiple channels per release, that implies that in fact we need channel+version+device_name for a unique identifier?
[00:20] <popey> ToyKeeper: other things use fb online account, not the fb webapp though
[00:20] <ToyKeeper> popey: What other things?
[00:21] <popey> share photos from gallery
[00:21] <ToyKeeper> (I mean, what actually uses it today?)
[00:21] <veebers> trainguards:   Looking for help, silo-10 failed to publish I've since sorted out the MP issue, is there a button I can push myself to proceed?
[00:23] <xnox> veebers: you want reconfigure or build?
[00:24] <veebers> xnox: I'm hoping to publish. THe testing has been done but due to traincon-0 the other day the publishing was delayed
[00:25] <xnox> veebers: triggered re-publishing, sponsored on your behalf
[00:25] <cjwatson> ok, can't you just press publish again?
[00:26] <cjwatson> mkay
[00:26] <veebers> xnox: awesome cheers.
[00:26] <veebers> cjwatson: that's what I was unsure of :-)
[00:26] <veebers> In the past I've just set testing to done
[00:26]  * xnox re-acks, republishes again
[00:27] <xnox> veebers: all good.
[00:27] <cjwatson> veebers: note my comment on https://code.launchpad.net/~thomir/autopilot-qt/trunk-add-build-flags/+merge/228218 BTW
[00:27] <cjwatson> for future cleanup
[00:28] <veebers> cjwatson: ack, sorry missed that comment earlier
[00:28] <veebers> xnox: thanks
[00:31] <cjwatson> alecu,dobey: ^-
[00:31]  * alecu looks
[00:35] <alecu> thanks for spotting that; I'm asking for another review and will ask again.
[00:35] <cjwatson> you can't top-approve it yourself if it's already adequately reviewed?
[00:35] <cjwatson> that's all it needs
[00:35] <veebers> xnox, cjwatson : is the bots comment about 'not available at the destination' an error or a status update?
[00:36] <cjwatson> veebers: status update
[00:36] <veebers> cjwatson: ack, thanks :-)
[00:36] <cjwatson> ah, there we go
[00:36] <cjwatson> dobey: thanks
[00:36] <alecu> cjwatson: ah, I thought it needed a review after my latest commit of translation updates.
[00:36] <cjwatson> alecu: no, all MPs must be top-approved before publishing
[00:36] <cjwatson> that's all
[00:37] <alecu> great, thanks.
[00:43] <dobey> alecu: yeah, it's the same thing tarmac complains about if you top-approve something, and then push a new revision to it
[00:44] <cjwatson> I don't think so, this one wasn't top-approved to start with was it?
[00:44] <cjwatson> it's not my experience that LP magically reverts things away from top-approved
[02:04] <imgbot> [03:29] <imgbot> [03:29] <imgbot> [04:28] <bzoltan1> Goodmorning, is anybody active from the landing team?
[06:17] <oSoMoN> hi all
[06:17] <oSoMoN> any idea why webbrowser-app 0.23+14.10.20140730.2-0ubuntu1 has been stuck in the proposed pocket for 4 hours now? it usually migrates to the release pocket much faster than that
[07:30] <cjwatson> oSoMoN: did you check the reports?
[07:32] <cjwatson> oSoMoN: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#webbrowser-app "Not touching package due to block request by freeze (contact #ubuntu-release if update is needed)" - all packages that are on images participating in 14.10 alpha 2 are frozen until later today
[07:32] <oSoMoN> cjwatson, I thought the freeze would start being in effect later today?
[07:33] <oSoMoN> ah, got it, it’s 14.10 alpha 2 freeze, not the rtm beta freeze
[07:33] <oSoMoN> sorry for the confusion
[07:33] <cjwatson> I have no idea about any RTM beta freeze
[07:34] <oSoMoN> cjwatson, well the rtm beta milestone is today, and I assumed there would be some sort of freeze, but obviously that’s an unfounded assumption
[07:35] <cjwatson> I think that's just a feature delivery milestone, yeah
[07:35] <oSoMoN> I’m a bit dense today and mixing up things, sorry…
[07:35] <tvoss> davmor2, you around, yet?
[07:35] <cjwatson> Freezing seems counterproductive really - we'll be branching off the most recent promoted image, when we branch
[07:35] <oSoMoN> cjwatson, yeah, it makes sense
[07:36] <cjwatson> Better off trying to get as many of the feature branches as possible done before then
[07:44] <sil2100> tvoss: davmor2 should be around in about 40 minutes ;)
[07:44] <tvoss> sil2100, thanks
[07:55] <tvoss> sil2100, ping
[07:56] <sil2100> tvoss: pong!
[07:56] <tvoss> sil2100, can I get a silo for line 33?
[07:56] <psivaa> sil2100: if you're wondering of the missing tests with 162.. i've kicked them off. should be in soon.
[07:56] <sil2100> tvoss: sure, let me just finish the publishing of other silos and assign one for you
[07:57] <tvoss> sil2100, thank you
[08:00] <bzoltan> sil2100:  May I ask for a silo?
[08:00] <sil2100> bzoltan: hello! We're a bit lowish on silos, but let me assign one once we get some free (which should be soonish)
[08:08] <sil2100> bzoltan: uh! it seems someone locked the UITK already
[08:08] <bzoltan> sil2100:  what is that?
[08:08] <sil2100> bzoltan: silo 15 (row 15) from bfiller, something related to the address book or such?
[08:09] <sil2100> I can assign if you guys coordinate
[08:09] <bzoltan> sil2100: OMG... that is wrong.  Renato should not just pick up a UITK development branch and propose to the trunk. We have a staging branch for that
[08:13] <bzoltan> sil2100: that is exactly what we want to avoid...people landing on our trunk stuff what is not tested.
[08:14] <bzoltan> sil2100: but hey ... that line15 silo is for testing. It is not meant to land.
[08:14] <bzoltan> sil2100:  should not people stop using the Silos for development? They can set up PPAs in their projects and can push their source packages and test the PPA the way they want.
[08:17] <sil2100> bzoltan: amen!
[08:17] <sil2100> bzoltan: yeah, so we don't mind giving people silos for development, but it becomes a really big problem when they're hogging them for weeks
[08:17] <bzoltan> sil2100:  So I think we are fine with proceeding with the real UITK landing.
[08:17] <sil2100> bzoltan: and there are other dedicated PPAs that can be used for testing
[08:17] <sil2100> bzoltan: right! Let me assign
[08:18] <bzoltan> sil2100:  Oh yes... only the UITK and SDK has like 6 PPAs
[08:19] <sil2100> bzoltan: you got the border silo! Silo 20 for your disposal ;)
[08:19] <bzoltan> sil2100: sweet. I hope to release it today
[08:23] <ogra_> sil2100, hmm, i still see a ton of DENIED for calendar in https://jenkins.qa.ubuntu.com/job/utopic-touch-mako-smoke-daily/613/artifact/clientlogs/calendar_app/syslog/*view*/
[08:23] <ogra_> (and there seem to be some for media-hub as well)
[08:24] <ogra_> in https://jenkins.qa.ubuntu.com/job/utopic-touch-mako-smoke-daily/615/artifact/clientlogs/music_app/syslog/*view*/ (other device) there are quite a few for notes-app
[08:25] <sil2100> hm
[08:25] <sil2100> At least it doesn't seem to break anything
[08:26] <ogra_> calendar has 4 failures ... notes has one
[08:26] <ogra_> (music has 8 if the media-hub is related here)
[08:29] <davmor2> tvoss: hey, so playing with silo 008 last night only issue I've hit so far is that reminders isn't seeing any notes.  I'm just going to look in to that a little incase it isn't related and then I'll do a mini dogfood for calls sms mms etc
[08:29] <tvoss> davmor2, thanks
[08:30] <tvoss> sil2100, can you hold back on silo8 a little until davmor2 gives his final ack?
[08:30] <sil2100> tvoss: too late
[08:30] <sil2100> tvoss: it has already been published in the morning...
[08:30] <tvoss> sil2100, ack. Will hotfix if issues arise
[08:30] <tvoss> davmor2, would be great if you could finish your mini-dogfooding, though
[08:32] <davmor2> tvoss, sil2100: sms is okay so that's a start
[08:32] <tvoss> davmor2, cool
[08:35] <davmor2> popey: in reminders do you see your notes and notebooks?
[09:05] <t1mp> bzoltan, sil2100 silo 15 was only for testing at the sprint last week, for UITK I was collecting all the visual changes that we made and were not ready to be merged into UITK staging in an rtm-fit-finish branch so that renato could work with them in the apps
[09:07] <t1mp> that silo was never intended to land
[09:08] <bzoltan> t1mp: if not intended to land then it should not be in a silo
[09:08] <t1mp> renato: we were just discussing silo15
[09:09] <Guest78593> bzoltan, time, we need sdk on silo 15 to build the apps otherwise the apps will fail, since we are using the stuff from your branch
[09:10] <bzoltan> renatou: that is fine, but why do not you use a regular PPA for that? Why to block a silo and why to lock all projects you porpose to?
[09:11] <t1mp> renatou: we like to land a 'real' UITK now so we need to get rid of silo 15
[09:12] <bzoltan> renatou: t1mp: just branch all the branches you want to play with and issue the `dch -i;debuild -i -I -S -sa` and dput the source packages to the PPA. Ask the IS to turn on the armhf builds and that is it. You will have a resident testing Silo.
[09:13] <renatou> t1mp, what is the problem I do not understand
[09:13] <bzoltan> t1mp:  it is fine now.. but the landing team has to look up the reason for the lock and that takes time.
[09:14] <t1mp> renatou: we could not land a new UITK because there was already a silo (15) that has UITK changes
[09:14] <cjwatson> turn on armhf and probably make it devirtualised
[09:14] <bzoltan> renatou: I wrote what the problem is... whenever you add a UITK branch to the CI landing sheet  all UITK landings will be blocked
[09:14] <cjwatson> unless ubuntu-ui-toolkit works in a virtualised PPA now, which isn't impossible
[09:14] <bzoltan> renatou: ^
[09:15] <t1mp> what is a virtualised ppa?
[09:16] <ogra_> a PPA building in a VM (vs a PPA building on real hardware)
[09:16] <renatou> bzoltan, I think you can remove it until you release and put back after it
[09:17] <bzoltan> renatou: I do not want to and will not touch other people's landing request.
[09:17] <t1mp> ogra_: ahh :)
[09:17] <renatou> bzoltan, ok,  when bill arrive I will ask him
[09:17] <bzoltan> renatou: and I never add other project's branch to my landing without asking the lander of that project.
[09:17] <cjwatson> eventually everything will be in VMs but it'll take a while yet
[09:18] <cjwatson> then we can just scale out the builder infrastructure smoothly and there will be unicorns
[09:18] <t1mp> bzoltan: they asked me for the branch to collect stuff which they can add to the silo
[09:19] <t1mp> bzoltan: I didn't tell you.. I guess nobody foresaw problems with it
[09:19] <t1mp> since it was only for quick testing
[09:20] <t1mp> it makes sense now to put stuff in ppas, but a silo seems like a quicker solution to set up
[09:20] <bzoltan> t1mp: well.. we do not land stuff directly to the trunk.. so that should have been clear :) But in general... I do not touch yours, you do not touch mine :) I think that is the safe way.. unless we agree that we have fun by touching each other's things
[09:21] <bzoltan> t1mp: and I do mean branches and MRs here!
[09:21] <t1mp> haha nice way of putting it ;)
[09:21] <t1mp> bzoltan: I know that we don't land to trunk, the branch in the silo was only for testing, not for landing (there is not even an MR)
[09:21] <bzoltan> t1mp:  with the good old PPAs it is two commands more... create the source and dput the source
[09:21] <t1mp> is silo 15 deleted now?
[09:22] <bzoltan> t1mp:  actually there was an MR
[09:23] <t1mp> oh, I see
[09:23] <bzoltan> rsalveti: ping
[09:26] <renatou> I created the MR and marked it as "work in progress", everybody can do that
[09:26] <renatou> I did not see that as a problem
[09:26] <bzoltan> rsalveti: I am not sure what to do with the ubuntu-ui-toolkit/gles branch
[09:26] <bzoltan> renatou: Do you see it now?
[09:26] <renatou> what?
[09:28] <bzoltan> renatou: 1) using teh limited number of silosfor development when they are  meant for landing stuff 2)whenever you add a UITK branch to any Silo, all upcoming UITK landing requests will be blocked, regardless of the comments in your request or the status of the MRs in your request.
[09:29] <bzoltan> renatou:  that is why I suggest you to use the PPAs under your project for development. You can create as many you need and you can asdk the #is to set it up they way you need (armhf builds, real hw)
[09:29] <Saviq> bzoltan, 2) is not true, you just need to ask for the landing team to ignore conflicts and let everyone that has a silo with your project in that's the situation
[09:30] <renatou> we still landing our apps even with the branches on silo15
[09:30] <bzoltan> Saviq: but that is just waste of time..
[09:30] <Saviq> bzoltan, no it's not, not when the silo is under active work
[09:30] <Saviq> bzoltan, and PPAs are not that easy, armhf builders are virtualized by default, and the builds fail for whatever wants to use threads
[09:30] <bzoltan> Saviq: It is OK for me. It is not that important.
[09:31] <bzoltan> Saviq:  the Silos are PPAs too...
[09:31] <cjwatson> Saviq: note my "devirtualised" comment above
[09:31] <cjwatson> also it's worth rechecking your assumptions about virtualised builds given the complete replacement of the virtual builder infrastructure on Monday
[09:32] <Saviq> cjwatson, do they not use QEMU any more?
[09:32] <cjwatson> may well still fail - we think we probably want to import SUSE's grotty qemu-user patch to limit it to a single thread - but the failure modes may be different as now it's based on trusty kernel+qemu rather than a frankenstein bodge on hardy
[09:32] <cjwatson> still using qemu, just much newer
[09:33] <cjwatson> not saying it will definitely work now, just that it's worth rechecking assumptions that date from before this week
[09:33] <Saviq> this will all be solved by CI airline anyway :P
[09:33] <cjwatson> sure, but the devirtualised builder infrastructure doesn't scale, by definition
[09:33] <cjwatson> so we still need to fix this
[09:33] <Saviq> sure
[09:34] <cjwatson> hm, in fact the qemu version was possibly the same by the end, looks like 2.0.0+dfsg-2ubuntu1 was backported.  We've seen the newer kernel make a difference for some projects though
[09:35] <cjwatson> the only thing that CI airline will solve here is not having a fixed pool of silos
[09:35] <cjwatson> and maybe being better about clashes
[09:41] <Saviq> trainguards, can we please remove unity-scope-{mediascanner,click} from silo 005?
[09:41] <Saviq> I'm reconfiguring the silo without them
[09:44] <camako> cihelp, could I get a silo for row 40 (mir 0.6.0)?
[09:44] <cjwatson> camako: you want the "CI Train support" person in the topic (also there are no free silos right now)
[09:45] <camako> cjwatson, Ah ok.. Sorry about that..
[09:46] <camako> sil2100, waiting for a silo assignment for row 40 (understand all silos full)...
[09:53] <camako> sil2100, oh it seems we want one more MP to get in.. Updating the sheet.
[09:53] <ogra_> hmm, i thought the new webbrowser landed
[09:54] <ogra_> doesnt look new in 162
[09:54] <ogra_> oh, it didnt make it into any image yet
[10:01] <cjwatson> ogra_: alpha 2 freeze
[10:03] <davmor2> tvoss, sil2100 so silo 008 is looking okay.  The issue with reminders is showing on devices that don't have silo 008 enabled too so that isn't related
[10:03] <tvoss> davmor2, \o/ thank you
[10:05] <Saviq> sil2100, can you add qtmir to the list of packages requiring -gles twin?
[10:05] <sil2100> Saviq: ok!
[10:06] <Saviq> sil2100, and drop scope-{click,mediascanner} from silo 005 in the mean time :)
[10:07] <ogra_> cjwatson, ah, thanks ...
[10:07] <sil2100> Saviq: there no longer is any click or mediascanner scope in 005 :)
[10:07] <Saviq> sil2100, ah, someone cleared it up, thanks
[10:07] <sil2100> Saviq: ok, and I'll add the qtmir package to the twin list in a moment
[10:08] <Saviq> sil2100, awesome, thanks
[10:08] <sil2100> camako: right, not silos free, but some packages should finish migrating in a moment
[10:09] <tvoss> sil2100, what's going on with silo 8?
[10:10] <sil2100> tvoss: ugh, did someone try to rebuild? It was published :|
[10:13] <tvoss> sil2100, seems so ...
[10:13] <tvoss> sil2100, what do we do?
[10:13] <ogra_> mterry, losking works, but the UI is to slow to properly use it when unlocking
[10:13] <ogra_> *locking
[10:14] <davmor2> ogra_, sil2100: so the reminders thing is down to apparmor="DENIED" by the look of syslog
[10:14] <davmor2> but I'll confirm that once I'm on a fresh 162
[10:14] <mterry> ogra_, how do you mean?
[10:15] <ogra_> davmor2, yeah, i think jdstrand should grab all syslogs from the last three devices that rean the smoketests and actually check them
[10:15] <ogra_> mterry, the unlock UI with the number pad ... it takes about 3-4sec to recognize a tap from me
[10:16] <ogra_> so punching in the numbers is more a matter of luck
[10:16] <mterry> ogra_, whoa...  I don't see that.   I'm on N4 though...
[10:17] <sil2100> tvoss: hmm
[10:17] <sil2100> tvoss: ok, I see what happened
[10:18] <sil2100> tvoss: someone pressed the wrong button and tried rebuilding on the wrong silo, as robru's dashboard can be confusing sometimes
[10:19] <sil2100> tvoss: so what we do now is we wait for it to migrate and manually track it
[10:19] <tvoss> sil2100, okay
[10:20] <davmor2> I'm shutting down xchat for 5 while I back it up I'll get any pings when I get back
[10:36] <bzoltan> sil2100:  may I get a silo for the QtCreator plugin in the line 41? I will release it an hour after the build is ready.
[10:37] <davmor2> sil2100: regression in the guide the last slide slide left doesn't seem to be exiting the slides
[10:37] <sil2100> davmor2: oh, that seems to be new
[10:38] <sil2100> bzoltan: sure
[10:39] <bzoltan> sil2100:  the number 1? wow,that is nice :) thanks
[10:39] <tvoss> that moment when you realize that location service is a trusted helper and your acceptance tests are failing
[11:03] <camako> sil2100, hope you got some silos left  :-)
[11:06] <popey> sil2100: davmor2 good news, I get to keep my 2nd phone ☻
[11:06] <davmor2> popey: yay I'd miss you cursing the alarms on hangouts if you were only down to one ;)
[11:06] <popey> hah
[11:07] <popey> oh, btw I did a fresh flash and when i got the new welcome wizard I turned the phone off (to ship it)
[11:07] <popey> when I turned the phone back on, there was no wizard
[11:07] <popey> this seems sub-optimal
[11:07] <davmor2> popey: indeed
[11:07]  * popey will file a bug
[11:08] <davmor2> popey: when you go through the slides for the guide see if it exits for me please it didn't for me just
[11:08] <davmor2> I need to file a bug for then,  I need my reminders app back damn it
[11:27] <popey> thostr_: looks like something in ms2 has broken music app - https://bugs.launchpad.net/music-app/+bug/1350529 this broke all the tests as it's loading some odd "untitled" artwork (watch the videos linked at http://<IP_ADDRESS>:8080/job/generic-mediumtests-utopic/1210/#showFailuresLink )
[11:28] <popey> sil2100: ^^ this should be a promotion blocker.
[11:28] <sil2100> ugh
[11:34] <sil2100> popey: thanks for the info :)
[11:34] <popey> np
[12:11] <thostr_> popey: investigating... we did actually a test run of music apps but apparently something went wrong
[12:13] <tvoss|lunch> sil2100, ping
[12:22] <camako> sil2100, is there a chance of getting a silo soon? Any landings near completion?
[12:22] <tvoss> sil2100, silo 8 still seems weird
[12:25] <sil2100> tvoss: let me fix that
[12:26] <tvoss> sil2100, should give us a silo back
[12:26] <sil2100> camako: oh, I see your silo is set to ready now, sorry before me going to lunch it was still as 'No'
[12:27] <camako> sil2100, np.. had to update some MPs
[12:29] <sil2100> camako: so, qtmir and unity-mir are already allocated by silo 14
[12:29]  * camako looks
[12:30] <sil2100> camako: I can assign a silo if you rebuild once that lands, but not sure when that happens
[12:31] <camako> sil2100, since it's kgunn's silo we can easily coordinate (kgunn might prefer mir 0.6.0 to get ahead)
[12:31] <sil2100> Sure, let me assign then
[12:33] <camako> sil2100, thanks
[12:50] <camako> sil2100, I had a mistake in the order of MPs (and got a merge conflict). I corrected the order now. Do you have to reconfig the silo or can I just build?
[12:50] <camako> silo2100, landing-009
[12:50] <sil2100> camako: you will have to reconfigure before you rebuild, you can do that by pressing the reconfigure button
[12:51] <camako> sil2100, ah I see. That's pretty cool.
[12:51] <sil2100> camako: if you didn't add or remove any 'projects', but just changed the order of merges or added some new ones to existing projects in the silo, then you can reconfigure the silo yourself :)
[12:51] <sil2100> camako: if you added something completely new, then we need to do it for you
[12:52] <tvoss> sil2100, can I get a silo for line 42?
[12:52] <camako> sil2100, gotcha
[12:52] <sil2100> tvoss: it's not set to ready :) !
[12:53] <tvoss> sil2100, it is in my spread sheet
[12:53] <tvoss> :)
[12:53] <bzoltan> sil2100: The silo1 is good to be published
[12:53] <sil2100> tvoss: I see it now :)
[12:53] <sil2100> bzoltan: I know! Just pressed publish
[12:53] <bzoltan> sil2100: thanks :)
[12:53] <sil2100> bzoltan: approve teh merges please ;)
[12:54] <bzoltan> sil2100:  sure
[13:07] <tvoss> sil2100, line 42, line 42, line 42
[13:08] <sil2100> tvoss: oh, the assignment failed, it seems you have location-service already in silo 10 :)
[13:08] <tvoss> sil2100, just overwrite it, I'll take care
[13:20] <sil2100> jdstrand: hello!
[13:23] <kgunn> camako: i think that unity-mir just needs some testing, let me try to get that outta the way (landed or rejected)
[13:25] <camako> kgunn, ok.. we don't even need to land the MP for unity-mir for 0.6.0 but I was just doing it for thoroughness/cleanliness
[13:26] <jdstrand> sil2100: hey
[13:29] <sil2100> jdstrand: when looking at the syslogs for the test results of the recent image we noticed many different apparmor denials
[13:30] <jdstrand> sil2100: has anyone filed bugs or listed them anywhere?
[13:30]  * jdstrand didn't see bugs this morning, but maybe missed them
[13:30] <sil2100> jdstrand: we're not sure if they're causing any problems, but still we saw many during for instance calendar or music
[13:31] <sil2100> jdstrand: not sure if we have any bugs for those
[13:31] <jdstrand> sil2100: can you give me a list of links to look at?
[13:32] <sil2100> Sure, one moment
[13:32] <sil2100> jdstrand: https://jenkins.qa.ubuntu.com/job/utopic-touch-mako-smoke-daily/613/artifact/clientlogs/calendar_app/syslog/*view*/ <- calendar app denials here
[13:34] <sil2100> jdstrand: https://jenkins.qa.ubuntu.com/job/utopic-touch-mako-smoke-daily/615/artifact/clientlogs/notes_app/syslog/*view*/ <- here notes app and some gallery app ones I see
[13:34] <jdstrand> sil2100: what timestamp? this has all the apparmor-easyprof-ubuntu denials in it
[13:35] <jdstrand> sil2100: oh, this is the fakeenv stuff
[13:35] <sil2100> This is from the latest image smoketesting, i.e. #162 http://ci.ubuntu.com/smokeng/utopic/touch/mako/162:20140731:20140728.1/9386/
[13:36] <jdstrand> sil2100: if it says 'fakeenv' in the denial, balloons is aware of the issues there
[13:36] <jdstrand> the /var/cache/fontconfig/ denial is probably related to the fakeenv not being complete
[13:37] <jdstrand> sil2100: the calendar is ok
[13:37] <sil2100> Ah, ok
[13:38] <sil2100> Yeah, I see fakeenv in calendar indeed
[13:38] <sil2100> The notes ones are worring us though
[13:39] <jdstrand> sil2100: the gallery-app is doing something wrong ti try to read /home/phablet/.local/share/applications/. apps aren't allowed to do that
[13:40] <jdstrand> sil2100: the notes-app denial tofor /home/phablet/.local/share/notes-app/ is a bug in notes-app not using the right path (ie, one that matches its click name)
[13:41] <jdstrand> sil2100: so, calendar is ballons fakeenv work, notes-app is a bug in notes-app and gallery is it is trying to do something it isn't supposed to
[13:41] <sil2100> ACK
[13:42] <sil2100> ogra_, brendand, popey: ^
[13:42] <jdstrand> sil2100: I imagine the notes-app isn't behaving properly
[13:42] <sil2100> jdstrand: I heard it was really behaving strangely recently, but not sure if related
[13:43] <ogra_> jdstrand, there were media-hub ones too
[13:43] <jdstrand> it isn't able to write to its application directory, so, depending on what it is trying to do, I imagine it wouldn't work well
[13:43] <jdstrand> ogra_: where?
[13:43] <ogra_> in both of the sysllogs i looked at this morning
[13:44] <jdstrand> ogra_: can you give a url?
[13:44] <ogra_> the two above
[13:44] <jdstrand> it isn't in https://jenkins.qa.ubuntu.com/job/utopic-touch-mako-smoke-daily/615/artifact/clientlogs/notes_app/syslog/*view*/
[13:44] <brendand> sil2100, i'm pretty sure notes-app has absolutely nothing to do with apparmor
[13:45] <brendand> sil2100, it's either uitk or the app itself
[13:45] <jdstrand> brendand: are you the developer of notes-app?
[13:45] <ogra_> jdstrand, thats weird ... i promise you there were three denials per syslog
[13:45] <brendand> jdstrand, no
[13:45] <ogra_> even identical ones for both devices
[13:45] <jdstrand> maybe I am blind
[13:45] <sil2100> hm, wait
[13:45] <ogra_> psivaa, did anything get re-run so that syslog was re-created ?
[13:46] <jdstrand> as for notes-app-- it likely just needs to set applicationName correctly in its QML
[13:46] <ogra_> jdstrand, no, you arent, they are gone
[13:46] <jdstrand> ogra_: you mena this: kernel: [  361.379185] type=1400 audit(1406785498.576:119): apparmor="DENIED" operation="file_mmap" profile="/usr/bin/media-hub-server" name="/tmp/orcexec.mF4JRO" pid=3501 comm="multiqueue0:src" requested_mask="m" denied_mask="m" fsuid=32011 ouid=32011
[13:46] <sil2100> https://jenkins.qa.ubuntu.com/job/utopic-touch-mako-smoke-daily/615/artifact/clientlogs/music_app/syslog/*view*/ <0 this had media-hub denials for sure
[13:46] <psivaa> ogra_: sorry missing the context. reading the backlog
[13:46] <ogra_> jdstrand, yeah
[13:47] <ogra_> psivaa, the syslog's seem to be different from the ones i looked at this morning
[13:47] <ogra_> for 162
[13:47] <jdstrand> I may have filed a bug for that
[13:48] <jdstrand> fyi, that media-hub denial is just noisy
[13:49] <jdstrand> the way gstreamer works is it tries several deifferent locations until it finds one it can use
[13:49] <ogra_> ok
[13:49] <ogra_> we had these 8 test failures in music-app so i was thinking they could be related
[13:49] <jdstrand> well, actually, it is 'm', so maybe not
[13:49] <jdstrand> it might be now that I think about it more
[13:50] <jdstrand> if it was 'w', then it would be what I said
[13:50] <jdstrand> but 'm' indicates it wrote it but couldn't mmap it
[13:51] <ogra_> i wonder if recent kernel changes bite us
[13:51] <ogra_> with all these apparmor issues coming out of the blue
[13:51] <jdstrand> no
[13:52] <jdstrand> openssl was a curl change. pat's was a bug in the upstart job, this is something else, notes-app is just a bug, fakeenv was always there and gallery-app is it just doing something it shouldn't
[13:52] <psivaa> ogra_: there were a number of tests that had to be manually started but they should not have changed the syslogs that were already synced
[13:52] <ogra_> psivaa, ok. thanks
[13:52] <ogra_> jdstrand, well, i find it significant that everything seems to happen at the same time :)
[13:53] <ogra_> but thats probably just a murphy-ism
[13:53] <jdstrand> I don't think it is-- I bet all of this except the curl change were there but no one noticed them
[13:54] <jdstrand> but people were freaked out about the openssl.cnf so people started looking harder
[13:54]  * jdstrand has asked for CI to report apparmor denials for a long time
[13:54] <jdstrand> that didn't come out right
[13:55] <ogra_> well, indeeed we only look deeper in the landing meeting if something fails
[13:55] <jdstrand> I identified that a good report would be apparmor denials on all the test runs, and mentioned it to CI a long time ago
[13:56] <jdstrand> I think people are just busy and it is an improvement, not a pressing issue
[13:56] <ogra_> right, i know paul said he has that on his TODO but other higher prio stuff to solve first
[13:56] <jdstrand> what I advised paul to do was different> I wanted to =have an infrastructure test to verify the autopilot rules were applied. both would be great
[13:59] <jdstrand> sil2100, ogra_, jhodapp: fyi, bug #1350870
[13:59] <sil2100> Oh, so it's known, thanks
[13:59] <jdstrand> I added the rule to the bug to add to the policy
[13:59] <jdstrand> sil2100: no, I just filed it
[13:59] <jdstrand> I was thinking of something else
[13:59] <ogra_> since 37 seconds :)
[14:00]  * jdstrand added the rtm14 tag
[14:01] <jdstrand> that may fix whatever media playback bugs you saw
[14:02] <sil2100> \o/
[14:02] <jdstrand> I did say *may* :P
[14:03] <sil2100> .o.
[14:03] <jdstrand> hehe
[14:03] <jhodapp> jdstrand, you need me to add the rule change to media-hub?
[14:04] <jdstrand> it would be easy for someone seeing the playback issue to verify
[14:04] <jdstrand> jhodapp: yes please
[14:04] <jhodapp> jdstrand, and yes, access to the orc memory is very important for software rendering of video
[14:04] <jhodapp> and other things
[14:04] <jdstrand> jhodapp: I would imagine in front of any silo landing if possible based on what I've heard here. but may want to talk to sil2100, et al on the priority
[14:06] <jhodapp> ok
[14:07] <bzoltan> sil2100:  I forget to say that the silo1 is OK now
[14:08] <sil2100> bzoltan: thanks! Published :)
[14:08] <popey> davmor2: what's that "notification" thing in online accounts for google accounts?
[14:09] <davmor2> popey: your guess is as good as mine
[14:09] <popey> heh
[14:09] <davmor2> popey: who deals with online account they might know
[14:40] <bregma> sil2100, could we get a priority on assigning a silo for line 34, it contains critical FTBFS fixes
[14:41] <sil2100> bregma: ACK, I remember it not being set to ready in the morning
[14:41] <sil2100> Assigning
[14:41] <bregma> thank you very much
[14:42] <pmcgowan> popey, davmor2 you can get gmail notifications
[14:42] <davmor2> pmcgowan: oh nice
[14:43] <davmor2> I don't use gmail though :D
[14:43] <ogra_> we just need dekko notifications too !!!
[14:47] <popey> pmcgowan: ooh
[14:51] <popey> davmor2: did you file a bug for the power button sensitivity?
[14:51] <jhodapp> sil2100, got a high priority bug fix for the media-hub-server apparmor denial bug in spreadsheet line #45
[14:51] <jhodapp> sil2100, know if any silos will be freeing up soon?
[14:52] <davmor2> popey: you mean the power dialog popup?
[14:52] <sil2100> jhodapp: hmmm, let me take a look
[14:52] <popey> davmor2: yeah, when you wake the phone the power down dialog pops up
[14:53] <davmor2> popey: https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1349362
[14:54] <popey> oh ta
[15:11] <dbarth> ogra_: hey, is there a step i missed to get an update of twitter in the image?
[15:11] <dbarth> ogra_: i have twitter 1.0.13 approved, but image 165 still contains 1.0.10 it seems
[15:11] <ogra_> 165  ?
[15:12] <dbarth> uh, yes; or was that 156 that lucio told me about
[15:13] <ogra_> but if it was approved but doesnt show up i think you should talk to the store guys
[15:21] <bzoltan> sil2100:  I have added the gles package to the Silo20. Could you help me with thatplease
[15:22] <sil2100> bzoltan: hi! How did you add this package?
[15:22] <t1mp> bzoltan: how are the tests for the landing going?
[15:24] <thostr_> sil2100: do you know how long alpha freeze will take? meaning would it be worth to reassign silos blocked by that?
[15:26] <dbarth> ogra_: ok
[15:26] <rsalveti> bzoltan1: saw your gles uitk pings here now, but guess you should be good now :-)
[15:46] <Saviq> sil2100, can we land non-desktop stuff at all? we've silo 5 that's good to go
[15:47] <ogra_> why wouldnt you
[15:48] <Saviq> ogra_, freeze
[15:48] <ogra_> Saviq, and ?
[15:48] <ogra_> :)
[15:48] <Saviq> ogra_, people were complaining they can't land ;)
[15:48] <ogra_> only applies to packages seeded in desktop, server or any flavour
[15:48] <Saviq> kk
[15:48] <Saviq> silo 5 at the ready, then!
[15:49] <Saviq> oops no more lines in the spreadsheet, does that mean RTM is upon us? ;)
[15:50] <ogra_> i thibnk something changed and robru wrote a mail about it
[15:50] <rsalveti> ogra_: freeze should be gone later today, right?
[15:51] <ogra_> rsalveti, heh ask the release team ... theoretically, yeah
[15:51] <seb128> ogra_, http://people.canonical.com/~platform/citrain_dashboard/#?q=
[15:51] <seb128> ups
[15:51] <seb128> Saviq, ^
[15:51] <rsalveti> ogra_: coo
[15:51] <rsalveti> l
[15:51] <seb128> ogra_, rsalveti: you can upload, things are just blocked in utopic-proposezd
[15:51] <robru> Saviq, you mean blank lines? just added more
[15:51] <rsalveti> right
[15:51] <ogra_> seb128, we have our own unblock mechanism for proposed (if needed)
[15:52] <seb128> ogra_, ?
[15:52] <seb128> your own?
[15:52] <Saviq> robru, yeah ;)
[15:52] <seb128> ubuntu has a standard way to unblock things
[15:52] <Saviq> seb128, what about the dashboard?
[15:52] <ogra_> seb128, yep, and there is an override for touch packages
[15:52] <seb128> Saviq, that's what replaces the tabs in the gdoc
[15:52] <seb128> ogra_, well, many are common to desktop images
[15:52] <seb128> e.g webbrowser-app
[15:54] <ogra_> yep
[15:56] <bdmurray> slangasek: so the last thing you said for a unique counter was channel+version+device_name however that looked like a question
[15:57] <slangasek> bdmurray: the question is "do you agree that this makes sense"
[15:57] <slangasek> apologies for my casual punctuation :)
[15:58] <ogra_> slangasek, bdmurray, i know both of you touched this area, do you remember what used to create the missing file from bug 1350722 ?
[15:58] <ogra_> (i definitely have it on older installs here)
[15:59] <slangasek> ogra_: I haven't touched that area at all, actually
[15:59] <ogra_> oh ?
[15:59] <bdmurray> ogra_: apport-noui off the top of my head
[15:59] <slangasek> ogra_: the team has, but not me :)
[15:59] <ogra_> heh, ok
[16:00] <bdmurray> ogra_: oh actually you need to use ubuntu-system-settings
[16:00] <ogra_> bdmurray, oh, se we dont pre-create it
[16:00] <ogra_> *so
[16:01] <bdmurray> ogra_: its supposed to show up in the wizard - https://code.launchpad.net/~cimi/ubuntu-system-settings/wizard.privacy/+merge/213124
[16:01] <ogra_> bdmurray, right, so creating it during build is the wrong thing then
[16:01] <ogra_> thanks
[16:04] <awe_> robru, sergiusens, 1.5.4-0ubuntu1 doesn't work due to the package being native.  You both OK with version just being "1.5.4"?  Otherwise I'm going to update with all of robru's suggested changes
[16:04] <sil2100> ogra_: ok, we're in another meeting right now ;/
[16:04] <robru> awe_, why is the package native? make it split.
[16:04] <sil2100> ogra_: I might not make it on time...
[16:06] <awe_> robru, because there is no official upstream
[16:06] <awe_> this is a fork of a nemomobile package
[16:07] <robru> awe_, right, so we use split packaging mostly by default in citrain.
[16:07] <robru> awe_, if you're forking it, then you're the upstream, and when we're the upstreams, we generally use split packaging in citrain.
[16:07] <awe_> right, but some project aren't ( nuntium for instance )
[16:07] <awe_> which is what this is based on
[16:08] <awe_> robru, I'd really prefer not to have to redo this, but if it's a *must*, then please point me at a guide on how to do so...
[16:08] <robru> awe_, do you have any philosophical reason for not using split packaging? 'we inhereted it this way' isn't really a valid reason. citrain is geared towards split packaging, the support for native packaging was only hacked in by some curmudgeons
[16:08] <robru> awe_, you don't need to redo anything
[16:08] <robru> awe_, just copy in one file, it makes it split.
[16:09] <robru> awe_, http://bazaar.launchpad.net/+branch/friends/view/head:/.bzr-builddeb/default.conf insert this file (note directory structure) and then foo-0ubuntu1 will work fine and citrain will be happy
[16:09] <bdmurray> slangasek: yes, that makes sense as a specific bucket. are there any other buckets we should create though? like channel+version (no device)
[16:12] <slangasek> bdmurray: I think the best for that might be version ubuntu:DistroRelease
[16:13] <slangasek> bdmurray: because 'channel' is too narrow, we don't want results from an image to be counted differently based on whether it's promoted or not
[16:14] <slangasek> bdmurray: so yes - two counters, one that corresponds to the rootfs version (version ubuntu:DistroRelease) and one that corresponds to the exact per-device image (the tuple we said above)
[16:15] <slangasek> ogra_, bdmurray: ok, does that mean we're not autosubmitting crashes by default?  I thought this was meant to be opt-out... this feels like a question I've asked before, is there a spec for this?
[16:16] <bdmurray> slangasek: ev might know more but aiui it is meant to be opt out and phone wizard will have submit crashes checked by default
[16:16] <ogra_> well, i dont get why the file exists on older installs
[16:17] <ogra_> i.e. images where the wizard didnt exist
[16:17] <slangasek> ogra_: ^^ so based on that, it sounds to me like if that file is needed to trigger autosubmissions, then there's still a bug
[16:17] <ogra_> slangasek, yeah
[16:17] <ogra_> if we want it as a default we should create it
[16:18] <slangasek> ogra_: are you sure that file is needed in order for autosubmissions to happen, though?
[16:18] <awe_> robru, that work.  thanks.  just building a deb to test that the install change you mentioned works properly, then I'll update the merge
[16:18] <bdmurray> yes
[16:18] <slangasek> ok
[16:18] <ogra_> slangasek, yup see /etc/init/apport-noui.conf on a phone
[16:19] <slangasek> then yes, please create it ;)
[16:19] <ogra_> ok, adding to livecd-rootfs then
[16:19] <ogra_> err ... hmm
[16:19] <imgbot> [16:19] <ogra_> the dir will be writable which means there is a bind mount on top
[16:19] <ogra_> i cant create it at build time
[16:20] <robru> awe_, sorry, I should have noticed it was missing when I did the review. I was mostly looking at what was in the diff, didn't occur to me to think about what wasn't there.
[16:20] <slangasek> how was this done before?
[16:20] <ogra_> thats what i'm asking all the time :)
[16:20] <davmor2> ogra_: did the landing meeting happen already?
[16:21] <ogra_> davmor2, indeed
[16:21] <ogra_> nothing really to discuss, we didnt have any image during the day
[16:21] <davmor2> ogra_: ohhh what in 163
[16:21] <ogra_> davmor2, whatever landed during the day
[16:21] <ogra_> :)
[16:22] <davmor2> ogra_: so no fixes then
[16:22] <ogra_> davmor2, a bunch of changes to logging etc (i mailed about that)
[16:22] <ogra_> nothing fancy i think ... many packages couldnt land due to alpha freeze
[16:22] <davmor2> oh I haven't played catch up there yet
[16:25] <sil2100> davmor2: how long does a standard dogfood run take for you?
[16:25] <davmor2> sil2100: around 2 hours+ now
[16:30] <ToyKeeper> Hmm, whatever happened with the effort to automate the most time-consuming parts of dogfooding?
[16:30] <popey> ToyKeeper: which bits?
[16:31] <ToyKeeper> Mostly, settings and indicators.
[16:31] <ToyKeeper> (which is mostly settings and more settings)
[16:33] <Saviq> trainguards, any hope for publishing silo 5?
[16:34] <awe_> robru, just pushed a new version with all the fixes applied
[16:34] <robru> awe_, sweet
[16:36] <sil2100> Saviq: yeah :)
[16:36] <ev> slangasek, bdmurray, ogra_: we should definitely be opt-out for error reporting. That's what was agreed to with design absolutely ages ago.
[16:36] <sil2100> robru: could you do some monkey button-pressing ^ ?
[16:36] <sil2100> ;p
[16:36] <ev> if it's not doing that, it's a bug :)
[16:37] <robru> sil2100, yeah what's up?
[16:37] <sil2100> robru: Saviq's unity8 silo needs publiiishiin'
[16:38] <ogra_> ev, to opt out you need to default to "in" ... thats the part we are missing
[16:39] <jhodapp> sil2100, can I get a silo for line 38 in the spreadsheet?
[16:40] <sil2100> jhodapp: ah! Right, I freed up one silo just for you, now's the right time
[16:40] <sil2100> Let me do that
[16:40] <jhodapp> sil2100, thank you
[16:40] <sil2100> jhodapp: sorry I didn't notice it's done already...
[16:40] <jhodapp> np
[16:40] <robru> Saviq, some MPs in silo 5 are not approved, can you check that?
[16:40] <jhodapp> I just noticed one got freed up :_
[16:41] <sil2100> Daaamn, dogfood is sooo sloooow
[16:41] <Saviq> robru, oh are they, checking
[16:42] <robru> Saviq, seems  https://code.launchpad.net/~unity-team/unity-scopes-shell/overview/+merge/227745 and https://code.launchpad.net/~aacid/unity8/implementOverlayColor/+merge/228162 need approving
[16:42] <robru> sil2100, ^^ it'd be handy if the publication job could print the unapproved merges. it's hard to find the one or two unapproved in a big list when you have to check them all.
[16:43] <robru> sil2100, maybe I'll submit a branch ;-)
[16:43] <sil2100> robru: aye! :) I might do it in a moment, as I'm tired of the RTM-hacking already, I need a chaange
[16:43] <robru> sil2100, oh ok, be my guest ;-)
[16:44] <Saviq> robru, damn, sorry, have to pull one MP
[16:44] <robru> Saviq, no worries, just reconfigure and rebuild and retest! ;-)
[16:44] <sil2100> ...;p
[16:44] <Saviq> _just_
[16:47] <bzoltan> sil2100: may I ask a reconfigure for the silo20? I have added the -gles MR for the UITK.
[16:48] <robru> sil2100, oh btw, I hope this is obvious but if not I just want to make it clear: please please please make the rtm ppa names match the rtm silo json names in a predictable programmatic way. otherwise queuebot and the dashboard will fill up with super ugly corner cases. lots of code in lots of separate places is making assumptions that I can just generate names like landing-nnn and then use that value for everything, like ppa links, jenkins job
[16:48] <robru> links, backend json urls, etc etc
[16:50] <bzoltan> robru: could you help me please ^^
[16:50] <sil2100> robru: I'll do my best! Right now I had to work-around some cornercases because of dogfood etc., but I'll try hacking things up as well as possible
[16:50] <sil2100> bzoltan: robru will most probably be your guide now :)
[16:50] <robru> sil2100, so eg I just saw http://people.canonical.com/~platform/citrain/landing-000.rtm for the first time, if that's the name we're going with (I'm ok with it), then please make PPAs that match at https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-000.rtm and same with the jenkins job URLs
[16:50] <robru> sil2100, thanks
[16:50] <robru> bzoltan, hi
[16:50] <robru> bzoltan, ok
[16:51] <robru> bzoltan, ok, good to go
[16:53] <sergiusens> awe_: robru nuntium uses split packaging as well fwiw
[16:54] <awe_> sergiusens, I can't change the Owner to "phablet-team" as it doesn't show up in the drop-box, whereas "Canonical Phonedations Team" does?
[16:55] <robru> ok folks! We got 10 silos marked as ready for assignment, and 1 silo available! first person to ping me gets it
[16:55] <sergiusens> awe_: I mean; the development series lp:... points to lp:~awe/.../trunk
[16:55] <awe_> sergiusens, never mind
[16:55] <awe_> phone it
[16:55] <sergiusens> awe_: you need to change that to lp:~phablet-team/.../trunk
[16:55] <sergiusens> development focus*
[16:56] <robru> dbarth, alex-abreu: what's going on in silo 13? build job aborted?
[16:57] <alex-abreu> robru, 13? no idea
[16:57] <robru> alex-abreu, how about 19? I think there was some confusion there. you were saying it didn't work in trusty. what I need to know is, does it work in utopic?
[16:58] <alex-abreu> robru, I'll test it today,
[16:58] <robru> alex-abreu, thanks!
[16:58] <awe_> sergiusens, check it now?
[16:59] <robru> Saviq, hey, what's going on with spreadsheet line 4? that got freed a month ago but the request is still there. is that still being pursued? it's so stale I'd like to delete it if it's abandoned.
[17:00] <Saviq> robru, yes, it's just at the bottom of our prio list...
[17:00] <Saviq> robru, but yes, we'll land it
[17:00] <sil2100> ogra_, davmor2: so, could you guys give me a quick update on the current situation of our images? Since I dug myself a bit in the RTM work - the media-hub apparmor issues seem to be fixed in the landing from jhodapp, right?
[17:01] <robru> Saviq, ok, no worries then. I just thought it might be getting bitrotty or something
[17:01] <sergiusens> awe_: approved
[17:01] <sergiusens> requesting silo now
[17:02] <robru> alex-abreu, how about silo 11? what's going on there?
[17:02] <bzoltan1> robru: thank you
[17:02] <robru> bzoltan1, you're welcome
[17:02] <jhodapp> sil2100, yes, although I need to test with the silo image still once I get a silo
[17:03] <sil2100> jhodapp: silo is assigned since some time, it's silo 12 :)
[17:03] <awe_> sergiusens, can you or mandel handle the silo aspect?
[17:03] <sergiusens> awe_: already requested
[17:03] <sil2100> It's ready for action!
[17:03] <jhodapp> sil2100, oh great thanks, didn't get a ping about it from the bot
[17:03] <davmor2> sil2100: 162 is still having issues with apparmour for thing like reminders ie no notes appear in it.  there are other niggles around that, 163 just got spun up so I'll see if there are any fixes in there for stuff
[17:03] <sil2100> davmor2: ok, thanks :)
[17:03] <alex-abreu> robru, testing today too
[17:03] <robru> alex-abreu, ok great, would love to free those ones up asap
[17:04] <awe_> piiramar, merge approved ( I asked sergiusens or mandel to handle the silo ); please ping tiago directly re: telephony-service merge; you probably need to wait for tonegen to land first
[17:04] <slangasek> ogra_: how can we add a smoke test to ensure that autoreporting continues working?
[17:04] <Saviq> robru, it sure is, but we have some polish prepared ;)
[17:05] <robru> Saviq, haha ok
[17:05] <ogra_> slangasek, plars probably could check for the existience of the file from his scripts
[17:05] <sil2100> Polish!
[17:05] <slangasek> ogra_: at minimum, we should test that we can deliberately crash an application and get all the right files under /var/crash
[17:06] <ogra_> slangasek, at the current time i would call that an advanced requirement, but yeah :)
[17:07] <slangasek> ogra_: I consider it a baseline sanity-check, because we aren't getting proper end-to-end testing and things keep regressing out from under us in different places
[17:08] <ogra_> slangasek, oh, i fully agree ... i just dont see anyone having time for it
[17:08] <slangasek> plars: how would we go about integrating smoke tests for whoopsie?
[17:09] <sil2100> davmor2: do we have a bug for the reminders issue?
[17:09] <ogra_> (btw, we review the .crash files every day during the meetings ... so as long as there are broken apps we know if whoopsie creates them :) )
[17:09] <ogra_> (will get tricky if nothing crashes anymore indeed :)  )
[17:09] <plars> slangasek: sorry, trying to deal with a critical server problem at the moment. I haven't seen the backscroll yet. Depends on the test. Is it something you have a script for already?
[17:10] <slangasek> plars: it's something I can script quickly with my current motivation level ;)  But I would need to know where to integrate it
[17:10] <plars> slangasek: is it something that runs one time as a test, or does it need to be integrated into the process after every single test suite runs? (like systemsettle)
[17:11] <ogra_> once should be sufficient
[17:11] <ogra_> as its own "whoopsie" or "apport" test
[17:11] <ogra_> just making sure it is functional at all
[17:11] <plars> slangasek: either way, I'd be happy to help. It will go somewhere in lp:ubuntu-test-cases/touch. We have a simple whoopsie test in the default tests now iirc. It would probably go somewhere like that
[17:17] <dobey> cihelp: hi, it appears that jenkins has not the tests against the latest revisions of a few different branches (at least one of which where the last revision was a couple days ago)
[17:17] <fginther> dobey, can you provide some example(s)?
[17:17] <cjohnston> dobey: if you give me some more info we may be able to help
[17:18] <dobey> https://code.launchpad.net/~unity-team/unity8/dash-as-app/+merge/228534 is one MP where it's not been run on the latest revision
[17:18] <dobey> https://code.launchpad.net/~dobey/ubuntuone-credentials/fix-cancel/+merge/228961 is another
[17:21] <dobey> i could request new builds myself, but thought it better to see why it didn't run automatically
[17:24] <fginther> dobey, cjohnston, jenkins will not run -ci jobs once the MP is top approved. Is there a chance that the latest revisions were pushed and then top approved shortly after?
[17:26] <dobey> fginther: ah ok, i thought it always would.
[17:26] <dobey> fginther: that explains it then. i guess i should just manually request a jenkins run if i want it to happen?
[17:28] <fginther> dobey, either that or temporarily change the review state and it should get picked up on the next poll interval (which is every 15 minutes)
[17:29] <dobey> ok
[17:30] <dobey> thanks
[17:40] <robru> sergiusens, alecu awe_: anybody around to build & test a silo if I give you one? got 1 available, first to ping me gets it
[17:41] <alecu> robru: me!
[17:41] <robru> alecu, hehe, ok
[17:42] <robru> alecu, ok you got 17, please build
[17:44] <imgbot> [17:44] <imgbot> [17:44] <Saviq> robru, silo 5 tested & ready, please publish
[17:45] <Saviq> kgunn, ↑ you'll have a silo soon after
[17:45] <renatou> hey guys my app unit test that uses xvfb stop to work
[17:45] <renatou> I am getting this message
[17:45] <ogra_> mandel, bah, the location-service change didnt make 163 ...
[17:45] <renatou> 1: UbuntuClientIntegration: connection to Mir server failed. Check that a Mir server is
[17:45] <ogra_> mandel, will be in 164 though
[17:45] <renatou> 1: running, and the correct socket is being used and is accessible. The shell may have
[17:45] <renatou> 1: rejected the incoming connection, so check its log file
[17:45] <renatou> 1: Aborted (core dumped)
[17:46] <Saviq> renatou, coming
[17:46] <mandel> ogra_, ok, thx
[17:49] <kgunn> Saviq: thanks...busy with mir rdep weirdness with mesa anyway :)
[18:14] <kgunn> robru: you ever seen a silo get weird like this ?
[18:14] <kgunn> https://launchpadlibrarian.net/181215823/buildlog_ubuntu-utopic-i386.mir_0.6.0%2B14.10.20140731.2-0ubuntu1_FAILEDTOBUILD.txt.gz
[18:14] <kgunn> its like it can't fine libmirclient-dev
[18:14] <kgunn> oops/fine/find
[18:15] <kgunn> wonder if its one of those, needs a clean silo things ?
[18:15] <robru> kgunn, me? see a silo get weird? ... never!
[18:15] <robru> ;-)
[18:15] <kgunn> lol
[18:16] <robru> kgunn, yeah, that error message is basically useless, I need to dig in a bit
[18:16] <kgunn> ack
[18:19] <robru> kgunn, libmirclient-dev isn't new in 0.6 is it? this is really weird
[18:23] <davmor2> ogra_: hmmm why hasn't my phone pinged to say there is a new image?
[18:24] <Saviq> fginther, hey, we're having issues in our qmluitests job that some of the .xml test output files are not interpreted for failures
[18:24] <slangasek> plars: it would be a stand-alone test; we would want to pick some particular application, make sure it's installed (if necessary), kill it, and watch for correct results
[18:24] <fginther> Saviq, that's really bizaar
[18:25] <ogra_> davmor2, dnno, because it is lazy ?
[18:25] <Saviq> fginther, if you look for FAIL! in this log for example http://s-jenkins.ubuntu-ci:8080/job/unity-phablet-qmluitests-utopic/695/consoleFull
[18:25] <Saviq> fginther, you can find a failure CardCreatorTest::testKnownCases
[18:26] <Saviq> fginther, but those tests don't exist in the report in http://s-jenkins.ubuntu-ci:8080/job/unity-phablet-qmluitests-utopic/695/testReport/?
[18:27] <robru> kgunn, ok, so it seems like a cyclical dependency. mir build-deps on mesa, but then mesa-dev depends on mirclient-dev, but it can't install mirclient-dev because that's what it's trying to build
[18:27] <Saviq> fginther, at least the command line says it does output to a file -o /tmp/buildd/unity8-8.00+14.10.20140729.1bzr1091pkg0utopic695/obj-x86_64-linux-gnu/CardCreatorTest.xml,xunitxml
[18:27] <Saviq> fginther, and it does locally
[18:27] <Saviq> fginther, could (are) those files be artifacts, just hidden or something?
[18:27] <fginther> Saviq, it looks like CardCreatorTest.xml is the name of the file the results are in?
[18:27] <Saviq> fginther, yes
[18:28] <fginther> Saviq, ok. the job is only looking for *test*.xml files. We just need to add *Test*xml
[18:28] <Saviq> fginther, d'oh
[18:29] <Saviq> fginther, we really need to convert that into autopkgtests....
[18:30] <fginther> Saviq, I made the change, we should check back with run 712 to make sure it worked as expected
[18:30] <fginther> err 711
[18:30] <Saviq> fginther, awesome, thanks
[18:34] <slangasek> plars: so in this testing framework, how would I specify that a particular click app should be installed and started noninteractively?  I'm not sure if I want to do that, versus just killing some system process that I know will be present and running; but if it's straightforward to start an app, that's probably less intrusive on the testbed
[18:38] <kgunn> robru: but how did this ever work before ?
[18:38] <robru> kgunn, dunno, still playing, sorry
[18:38] <robru> kgunn, trying to reproduce it locally so i can experiment
[18:40] <plars> slangasek: someone in QA would be better to talk to on that, normally we don't do it through the ci scripts, but rather they handle it through autopilot tests.  iirc it can be done through the cli though
[18:40] <kgunn> robru: so i don't think it'd be related...but in mir's control file, i noticed
[18:41] <kgunn> there was a recommends: mir-doc removed
[18:41] <kgunn> which in turn had a depend on libmirclient-dev
[18:41] <plars> slangasek: if you are just testing whoopsie though, do you really need to start a click app? or can it be any process?
[18:42] <slangasek> plars: actually, come to think of it, a non-click app is better so that there's an associated .deb
[18:42] <slangasek> plars: so yes, it can be any process that's run from a system executable
[18:42] <bzoltan> robru:  the qtcreator plugin is blocked because of some infrastructure hickup https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-qtcreator-plugin-ubuntu/lastBuild/console Can you or anybody motivate that piece of art to try it again?
[18:43] <slangasek> plars: do you have a process in mind? :)
[18:43] <plars> slangasek: I've used sleep in the past for doing things by hand - ex. sleep 10 & ; kill -SEGV %1
[18:43] <slangasek> plars: yeah, that probably does the job, thanks
[18:45] <robru> bzoltan, ugh, I'm locked out of the VPN at the moment
[18:45] <robru> infinity, any chance you can look at bzoltan 's jenkins failure and rerun that job? looks transient ^
[18:45] <robru> slangasek, or you ^
[18:47] <infinity> Looking.
[18:48] <robru> infinity, thanks
[18:50] <kgunn> robru: after googling...could that actually be it ? if mir-doc was previously "recommends" on mir-demos, and mir-demos were used as part of ci...then it'd pull in libmirclient-dev
[18:51] <robru> kgunn, it's worth trying. apologies my pbuilder is taking forever to build here, once I reproduce it I can test that
[18:51] <kgunn> robru: ok, going for a run to burn beer calories...will try in a bit
[18:52] <robru> kgunn, ok
[19:01] <infinity> robru: Or, someone else will retry it before I set up my VPN and check. :P
[19:02] <robru> infinity, heh. my vpn keys are unfortunately on my other laptop, on the other side of the atlantic
[19:02] <popey> if anyone fancies can they confirm bug 1350993
[19:07] <robru> kgunn, naturally, I'm building it in a local pbuilder without issue.
[19:08] <davmor2> popey: confirmed
[19:08] <robru> infinity, ugh, I'm having a duh moment. can you remind me how to troubleshoot this sort of thing: https://launchpadlibrarian.net/181215823/buildlog_ubuntu-utopic-i386.mir_0.6.0+14.10.20140731.2-0ubuntu1_FAILEDTOBUILD.txt.gz ?
[19:09] <robru> infinity, tried building it locally in pbuilder, worked no problem.
[19:10] <infinity> robru: Without even looking, I'll assume libmirclient has another SOVER bump and it's in universe.
[19:10] <infinity> robru: And your pbuilder isn't main-only.
[19:11]  * infinity looks.
[19:11] <robru> i dont even
[19:11] <infinity> But no, I'm wrong.  Let me look harder. :P
[19:12] <robru> infinity, don't look too hard, I need more to be told how to look than to be looked after
[19:12] <davmor2> ogra_, jdstrand: I'm still getting no notes in reminders and this in syslog, http://paste.ubuntu.com/7916937/   I see a whole  heap of other denied's do you want me to drop my syslog somewhere?
[19:12] <infinity> robru: Sure.  So, my firs step is to schroot into a utopic-i386 chroot and manually try the apt-get install line from the build log.
[19:13] <infinity> Which works.  So, next, I get to add the PPA to the mix.
[19:14] <infinity> echo "deb http://ppa.launchpad.net/ci-train-ppa-service/landing-009/ubuntu utopic main" > /etc/apt/sources.list.d/argh.list
[19:14] <infinity> Which reproduces the problem nicely.
[19:14] <robru> hm
[19:15] <infinity> Then I add the problematic packages to the cmdline.
[19:15] <davmor2> pmcgowan: you say the notifications should work on gmail, it doesn't yet I tested it, not pings, not numbers anywhere, 1 mail in the inbox :(
[19:15] <robru> infinity, wait wait don't tell me
[19:15] <infinity> robru: http://paste.ubuntu.com/7916970/
[19:16] <pmcgowan> davmor2, I have not tried myself but was told by others it worked, someone blogged a screenshot
[19:16] <pmcgowan> maybe alex-abreu would know
[19:18] <infinity> robru: Was this one rebuilt a few times?
[19:18] <kenvandine> robru, any room for me to snag a silo for some stuff that isn't quite ready to land?
[19:18] <robru> infinity, uh, I might have rebuilt it once or twice thinking it was transient
[19:18] <popey> thanks davmor2
[19:18] <popey> davmor2: also, if you have a desktop around bug 1351003
[19:18] <infinity> robru: Cause it looks like what happened is there was arch skew causing failures, someone freaked out, republished a couple of times, and now there's skew with old binaries that haven't been removed yet.
[19:18] <robru> kenvandine, nope, not one single silo free.
[19:18] <infinity> robru: So, you need to learn to stop pressing that button.
[19:19] <robru> infinity, but I pressed it after it had already failed?
[19:19] <infinity> robru: It didn't fail on i386 the first time, and now you have this. ;)
[19:19] <kenvandine> i guess those that are migrating will be like that until the freeze is up?
[19:19] <alex-abreu> davmor2, I dont think the push helpers updates have landed in the click packages for the webapps yet, although they work in "staging"
[19:19] <robru> infinity, what? no. I only retried armhf
[19:19] <infinity> robru: Anyhow, a failed build shouldn't lead to reuploading.  It should lead to retrying the LP build.
[19:19] <robru> infinity, no, I didn't reupload anything. I said I retried it.
[19:19] <robru> infinity, maybe kgunn reuploaded it
[19:20] <infinity> robru: Well, this has been reuploaded (ie: CI-rebuild, rather than LP-rebuild) 3 times today.
[19:20] <robru> infinity, ok, wasn't me
[19:20] <infinity> robru: And the current skew is with a version that doesn't exist in the PPA anymore as a result.
[19:20] <robru> infinity, i didn't even ci-build it once
[19:20] <davmor2> alex-abreu: ah that would do it then
[19:20] <infinity> robru: So the only solution is to wait a bit for LP to cull those binaries.
[19:20] <robru> infinity, how long is "a bit"?
[19:20] <davmor2> alex-abreu: although there were 4 web apps
[19:21] <infinity> wgrant: How long does it take for old binaries to disappear from a PPA's Packages file?
[19:21] <alex-abreu> davmor2, the branch is here https://code.launchpad.net/~ralsina/webapps-core/push-helpers/+merge/228177
[19:21] <davmor2> popey: is that a 14.04 live cd :)
[19:22] <popey> davmor2: no, 14.10
[19:22] <slangasek> plars: ok, what's the relevant convention here?  Should I be creating a new directory under tests/default, or somehow adding this under tests/default/whoopsie?
[19:22] <davmor2> popey: oh so not 14.40 either way ;)
[19:23] <infinity> robru: Oh, the best part is that the first upload succeeded on all arches, but someone reuploaded anyway. :(
[19:23] <infinity> That button is far too attractive.  People don't seem to care that "reupload over and over" wastes resources and time.
[19:24] <infinity> robru: So, I'm going to manually delete the upload that worked fine.
[19:24] <infinity> robru: And check back in a bit and see if the world has cleared up.
[19:24] <popey> bah
[19:25] <Wellark> any ideas when we might get silos free'ed?
[19:25] <Wellark> we wants it
[19:26] <robru> infinity, nah, reupload was necessary because there were new commits
[19:27] <jdstrand> davmor2: stepping into a meeting. I can help in a bit (or perhaps tyhicks can)
[19:28] <davmor2> jdstrand: no worries
[19:30] <robru> infinity, looks like your qtcreator retry was successful, am I reading that right? thanks
[19:30] <robru> or rather, it seems it was jibel
[19:30] <robru> jibel, thanks for retrying qtcreator
[19:31] <infinity> robru: Ahh, yes, there was one commit between the first upload and .1... But between .1 and .2, there wasn't.
[19:31] <robru> infinity, hm? I'm not sure what version I was looking at, but I saw two commits in between some of the build jobs (it went from r1812 to r1814)
[19:32] <infinity> robru: Anyhow, deleting the old one completely from the PPA seems to have made my chroot happy.  Retrying the builds now.
[19:32] <robru> infinity, ok thx
[19:32] <davmor2> tyhicks: I'm hitting a whole heap of apparmor denied's and I'm getting no notes in the reminders app.  is this something you can have a look at all?
[19:33] <davmor2> popey: confirmed your cd issue
[19:33] <popey> ta
[19:34] <davmor2> brb
[19:48] <tyhicks> davmor2: can you provide a paste of the denials?
[19:50] <jhodapp> robru, no longer need silo 12, you can clean/free it...but I do need a new silo for landing audio-recording which is line #31 in the spreadsheet
[19:50] <robru> jhodapp, cool
[19:51] <robru> jhodapp, so 12 is a failure? should I delete it's spreadsheet line?
[19:51] <jhodapp> robru, no just needed it for testing...it was only an apparmor policy change and jdstrand directly uploaded it after testing
[19:51] <robru> jhodapp, oh so it's landed then?
[19:52] <jhodapp> robru, should be
[19:52] <robru> jhodapp, ok
[19:52] <davmor2> tyhicks: http://people.canonical.com/~davmor2/syslog.txt there you go
[19:52] <robru> jhodapp, you got 3
[19:52] <jhodapp> thanks robru
[19:52] <robru> jhodapp, you're welcome
[19:52] <jhodapp> robru, excited to get this landed!
[19:52] <robru> jhodapp, yeah!
[19:53] <davmor2> tyhicks: I think most of the top ones from mediascanner you can ignore I think that was from me adb copying the files across,  It's the stuff towards the bottom
[19:53] <robru> kenvandine, still around if I give you that silo? I got 5 that just freed ;-)
[19:53] <slangasek> plars: so writing the actual test is easy, but lp:ubuntu-test-cases/touch/ seems woefully underdocumented; despite the toplevel framework telling me it's "very easy" to run tests the same way as in the lab, it goes on to tell me lots of things that are unrelated to running the tests in this branch
[19:54] <infinity> robru: Anyhow, for education's sake, the important mechanic here was that, just like the real archive, PPAs don't remove old binaries until the new source has built.
[19:54] <jhodapp> robru, oh and yes, you can clean out that line in the spreadsheet for the silo you just freed
[19:54] <robru> jhodapp, thanks
[19:54] <infinity> robru: So, the way to fix the issue with the old binaries being uninstallable was to go to +deletepackages and forcefully remove the old source (and its bianries).
[19:54] <robru> infinity, ugh, ok. that error message in the build log completely fails to convey that information
[19:55] <robru> sergiusens, awe_ bfiller: anybody around for a silo? some just freed up
[19:55] <popey> where do lock screen bugs go?
[19:55] <infinity> robru: Right, hence drilling down in a chroot to see WHY the package was failing to install.
[19:55] <popey> (the new lock screen)
[19:55] <infinity> popey: unity.
[19:55] <bfiller> robru: yes please!
[19:55] <popey> ta
[19:55] <sergiusens> robru: the tone generator one would be good to have
[19:55] <sergiusens> robru: I'm about to free 16 soon btw
[19:56] <infinity> popey: But the lockscreen doesn't have bugs, it just has new features that you need adjust your workflow and expectations around.
[19:56] <bfiller> robru: line 29 would be good
[19:56] <infinity> popey: For instance, I now expect to be able to log in by holding down <enter> for 5 seconds.
[19:56] <popey> Good luck with that.
[19:56]  * popey recalls doing that on a PR1ME system in 1988
[19:57] <robru> bfiller, ok you got silos 1 and 2
[19:57] <bfiller> robru: cheers
[19:57] <robru> bfiller, you're welcome
[19:58] <tyhicks> davmor2: are you asking about all of the denials towards the bottom or just the denials that the reminders app is seeing?
[19:58] <robru> sergiusens, oh, citrain can't handle MPs where the trunk doesn't already have packaging. please merge it manually and then submit a null MP for the citrain release.
[19:58] <popey> infinity: here's your not a bug 1351027
[19:59] <davmor2> tyhicks: reminders is the important one as it is the one that no longer works, I'm assuming the osmtouch one will stop something functioning too
[20:01] <kenvandine> robru, i'll take one if i can have one :)
[20:01] <davmor2> tyhicks: is it just that apparmor rules got more strict and the app devs need to mod things?  as  this was stuff that worked previously
[20:02] <robru> kenvandine, hah, 15 or 41?
[20:02] <kenvandine> robru, i just clicked the button :)
[20:03] <tyhicks> davmor2: I'm not sure. I don't see rules that ever allowed reminders to chmod /run/user/32011 or for osmtouch to mkdir ~/.cache/QtLocation
[20:03] <robru> kenvandine, sneaky!
[20:03] <tyhicks> davmor2: and I haven't seen anyone else reporting these denials or issues
[20:03] <kenvandine> that's me :)
[20:03] <davmor2> popey: ^ can you get the notes in reminders app?
[20:04] <tyhicks> davmor2: I think we may need to wait for jdstrand to take a look. I'm not yet familiar enough with the policy on the phone but it doesn't seem like either app should be allowed to do those things.
[20:04] <davmor2> tyhicks: thanks
[20:05]  * jdstrand is back
[20:05] <tyhicks> ah, good
[20:05] <tyhicks> jdstrand: have a look at davmor2's denials: http://people.canonical.com/~davmor2/syslog.txt
[20:05] <Wellark> uuh! I see two available silos. can I have one?
[20:06] <jdstrand> fsuid=32011 ouid=0
[20:06] <Wellark> thostr_ already eod'ed but the details are filled in
[20:06] <tyhicks> jdstrand: there are a ton of mediascanner denials that you can ignore - look down towards the bottom at the reminders and osmtouch denials
[20:06] <jdstrand> davmor2: did you copy files over with adb?
[20:06] <jdstrand> ah
[20:06]  * jdstrand looks
[20:06] <robru> jhodapp, don't forget to build in silo 3
[20:06] <jdstrand> (cause the mediascanner ones just need a chmod phablet ... to work)
[20:07] <jhodapp> robru, thanks...it won't build successfully quite yet...rsalveti has to land the Android side changes soon
[20:07] <rsalveti> right
[20:07] <Wellark> oh, well.. I can wait until tomorrow. maybe I should get some sleep also
[20:07] <tyhicks> jdstrand: he did say that he used adb to copy files over and that was the cause of the mediascanner denials
[20:07] <rsalveti> and for that I need the qtmir guys to fix platform-api first
[20:07] <robru> jhodapp, ah ok, silo was looking lonely, sorry ;-)
[20:07] <rsalveti> because currently the android build is broken
[20:07] <jhodapp> robru, np :)
[20:07] <rsalveti> can't even rebuild it
[20:07] <jhodapp> rsalveti, oh no
[20:08] <jhodapp> rsalveti, are they working on it?
[20:08] <davmor2> jdstrand: yeah mtp dies after about 300MB  and can't be scripted to transfer currently, So I transfer via adb and then chown -R the dir
[20:08] <rsalveti> ricmm_: you might be able to take a look at that if you get the time
[20:08] <rsalveti> jhodapp: they were, but they are now gone (eod)
[20:08] <jhodapp> ugg
[20:08] <jhodapp> :)
[20:08] <rsalveti> ricmm_: I think it's broken because we're still building the ubuntuappmanager
[20:08] <rsalveti> on the android side
[20:08] <rsalveti> we should just remove that completely now
[20:09] <jdstrand> davmor2: reminders is doing something wrong with the /run/user/32011/ denial
[20:09] <popey> davmor2: i see no notes
[20:09] <popey> davmor2: yeah, mtp being broken is quite frustrating
[20:09] <tyhicks> jdstrand: agreed - that's not something that we'd want to allow
[20:09] <jdstrand> (it could very well be an underlying library, just saying, apps aren't supposed to have 'w' on /run/user/32011/
[20:09] <jdstrand> )
[20:09] <robru> kenvandine, looks like that build error is due to a no-change rebuild, in that case it's ok to force-override the build rather than bother to sync a no-change
[20:09] <jdstrand> davmor2: we just fixed the media-hub denial moments ago
[20:10] <jhodapp> rsalveti, ok, I've tested the full recording (video/audio) quite a bit now on a freshly wiped image 162 with confinement of the camera-app
[20:10] <davmor2> jdstrand: yeap I wasn't too worried about that one as I knew there was a fix in the works
[20:10] <rsalveti> jhodapp: great
[20:10] <jdstrand> /home/phablet/.cache/QtLocation/ is not a valid path. seems the app is not using the location service
[20:11] <jhodapp> rsalveti, the only thing wrong with it seems to be the 90 rotation to the left, but that's an old issue to resolve soon
[20:11] <ricmm_> rsalveti: whats up
[20:11] <jdstrand> davmor2: /dev/fb0 is just noise
[20:11] <jdstrand> I've taken a note to silence it in the next upload
[20:11] <jhodapp> jdstrand, hehe, looks like you really do need to hide that one :)
[20:11] <rsalveti> jhodapp: right
[20:12] <jdstrand> well, rsalveti and I discussed that a while back. we thought we'd not hide it to remind that something is trying to do it, but I think the confusion caused outweighs that
[20:12] <jhodapp> rsalveti, have you tried playing a video recorded with our camera-app on an Android phone?
[20:12] <ricmm> rsalveti: what kind of duplicate headers? which?
[20:12] <ricmm> I'm pulling to check
[20:13] <rsalveti> ricmm: event.h
[20:13] <jdstrand> davmor2: apps aren't supposed to have 'r' access on /home/phablet/.local/share/applications/. that is an info leak. dekko should be fixed
[20:13] <jdstrand> /usr/share/applications/ is less worrisome, but isn't needed and will likely be fixed with the other one
[20:13] <jdstrand> (for free)
[20:13] <davmor2> jdstrand: nice so that is a bug against dekko then
[20:14] <rsalveti> jhodapp: jdstrand: right, I still don't think we need to let it write into fb0
[20:14] <rsalveti> but yeah, I don't think anyone ever had the time to actually look at that
[20:14] <rsalveti> and understand why the camera-app needs that
[20:14] <jdstrand> rsalveti: right. I would do an explicit deny rule, which will still deny but suppress the logging
[20:14] <rsalveti> right
[20:14] <rsalveti> might be better
[20:14] <jdstrand> I use the camera app all the time and it doesn't seem to need it at all
[20:14] <jdstrand> there are a few things that are noisy like that
[20:15] <jdstrand> probably way down in a library. I would guess it is doing an open for some sort of capabilities
[20:15] <jdstrand> check

[20:16] <jdstrand> davmor2: so, of those, media-hub is a real bug and fixed. dekko needs a fix, but that is just noise. reminders is probably the same. osmtouch needs to use the location-service
[20:17] <davmor2> jdstrand: thanks for that I will file bugs and then we can loose some of the noise :)
[20:18] <jdstrand> davmor2: oh, and /dev/fb0, but I'll do that myself
[20:19] <tyhicks> thanks jdstrand - that would have taken me a while to sort out :)
[20:19] <jdstrand> no worries
[20:19] <jdstrand> tyhicks: I tagged you in another channel :)
[20:20] <jdstrand> tyhicks: I didn't know how long my call would take and wanted to make sure davmor2 wasn't blocked on something. happy to review the denials for him
[20:21] <tyhicks> we're even :)
[20:21] <jdstrand> \o/
[20:22] <davmor2> popey: https://bugs.launchpad.net/reminders-app/+bug/1351041
[20:23] <popey> confirmed
[20:28] <kenvandine> oh sigh...
[20:32] <kgunn> robru: looks like you kicked a mir build, did you figure something out ?
[20:32] <awe_> robru, sorry... just got back.  any left?
[20:32] <kgunn> i was just about to test my recommends theory
[20:33] <robru> kgunn, yeah, infinity saw the problem was caused by stale packages in the PPA from previous uploads, deleted those, and rebuilt
[20:33] <robru> awe_, yes, but i need you to do something before I can give a silo ;-)
[20:34] <awe_> what would you like me to do???
[20:34] <awe_> ;)
[20:35] <nik90> robru: hey, I found some issues with regards to the emulator image 165 and higher, https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1351048
[20:35] <robru> awe_, so, citrain makes the assumption that your MP target branch (ie, trunk) already has packaging info. if it can't find packaging there, it just explodes. so I'm going to need you to merge to trunk manually, and then make a new empty MP for us to build in the silo
[20:35] <nik90> robru: I was asked by rsalveti to inform the landing team about this
[20:36] <awe_> robru, ;D
[20:36] <robru> nik90, thanks
[20:36] <awe_> robru, how do I create an empty MP?  Just submit the a copy of trunk against itself?
[20:38] <robru> awe_, yeah, something like that. if LP doesn't let you MP trunk against itself, then push trunk to a secondary place, and then MP that back into trunk without making any commits.
[20:38] <robru> awe_, it's a big clunky but citrain is 100% focused on MP management, there's no way to say 'just build trunk', it needs the MP
[20:39] <awe_> ok, let's try the first method...
[20:46] <robru> kgunn, does dash-as-app mean that it'll be possible to write a click app that replaces the dash? I'd love to tinker with designing my own home screen like is already possible on android ;-)
[20:47] <plars> slangasek: if you take a look at tests/default, you will see some examples there of where I think this test will fit in easily
[20:47] <kgunn> :) unfortunately no...its more about how the system views it
[20:47] <kgunn> robru: but if you got a silo i'd sure like one :)
[20:47] <plars> slangasek: or as I said, if you have the script already, just pitch it over the wall to me and I'll get it integrated
[20:48] <robru> kgunn, just enough for you and awe_ !
[20:48] <kgunn> robru: i can probably give up row 15....we went back to the drawing board on that one
[20:49] <robru> kgunn, oh sweet, thanks
[20:49] <robru> kgunn, note, unity8 conflicts in silo 5
[20:50] <kgunn> robru: oh yeah, i'll wait on silo5 to finish migrating
[20:50] <infinity> robru: So, mir worked, but it looks like everything else in silo 9 hates it. :P
[20:50] <robru> infinity, oh?
[20:50] <kgunn> infinity: yeah...prolly the "ignore twins"
[20:50] <kgunn> qtmir has a twin
[20:51] <infinity> ...?
[20:51] <infinity> There was a packaging change in mir that dropped a protobuf dep.
[20:51] <robru> infinity, yeah, you know? http://cdn.screenrant.com/wp-content/uploads/Twins-1988-movie.jpg
[20:51] <kgunn> infinity: well, i saw silo9 qtmir failure...so i assumed
[20:51] <kgunn> robru: greatness!
[20:51] <robru> ;-)
[20:52] <infinity> And now platform-api fails with:
[20:52] <infinity> CMake Error: The following variables are used in this project, but they are set to NOTFOUND.
[20:52] <infinity> Please set them or make sure they are set and tested correctly in the CMake files:
[20:52] <infinity> PROTOBUF_LIBRARY (ADVANCED)
[20:52] <infinity> Likely not a coincidence.
[20:52] <kgunn> ah crap
[20:53] <robru> kgunn, you done goofed! can't assign because not all your MPs target the same branches. they don't gotta target trunk but they all gotta target the same place
[20:53] <kgunn> robru: ack, my team just dumped the list on me...i'll follow up
[20:54] <robru> kgunn, and re:15, how far back to the drawing board did you go? can I delete that line from the spreadsheet or do you intend to fix up those branches and try again later?
[20:54] <awe_> robru, it let me create a dummy MP: https://code.launchpad.net/~phablet-team/tone-generator/dummy-branch/+merge/229121
[20:54] <robru> awe_, cool, can you put it in the spreadsheet?
[20:54] <awe_> sergiusens_, ^^
[20:54] <awe_> robru, don't think I have write perms
[20:55] <kgunn> robru: go ahead and delete
[20:55] <kgunn> row15
[20:55] <robru> kgunn, hah, row15. good thing you clarified, I was thinking silo 15
[20:55] <robru> awe_, one sec
[20:56] <kenvandine> bfiller,  i removed the duplicate MP in the spreadsheet and added the api_v1 MP
[20:56] <kenvandine> i'll let you do the reconfigure :)
[20:57] <bfiller> kenvandine: doing now
[20:57] <kenvandine> bfiller, thx
[20:57] <robru> awe_, ok, I added you on the spreadsheet and gave you build perms in jenkins too
[20:59] <bfiller> kenvandine: building
[20:59] <bfiller> kenvandine: any MR for the fix florian needs yet?
[21:01] <robru> awe_, you should have gotten an email with the spreadsheet link. you're gonna want to pop that new MP into cell F32, just delete the old MP from there
[21:02] <awe_> robru, ack
[21:04] <awe_> robru, done + test plan added; I added an Approve review to the MP, should I top-approve too?
[21:04] <robru> awe_, yessir
[21:05] <awe_> also, will things build automatically?  I see you game me build perms too??
[21:05] <awe_> MP all set
[21:05] <awe_> fyi, sergiusens_ and piiramar will take ownership of this tomorrow ( sergiusens_ for silo mgmt, and piiramar for testing )
[21:06] <robru> awe_, alright, now go to the dashboard and click build on silo 5 ;-)
[21:06] <kgunn> robru: try me now on dash as app...sorry bout that
[21:06] <awe_> k
[21:06] <robru> kgunn, no worries
[21:07] <robru> kgunn, qtmir conflicts with silo 9 ;-)
[21:09] <kgunn> robru: yep, that's ok ...i got my eyes on both
[21:10] <kgunn> robru: we'd likely land silo9 first, then dash-as-app
[21:10] <robru> kgunn, ok, you got 7 now
[21:12] <sergiusens_> robru: can you reconfigure 16 for me? I want to piggyback a crit bugfix there for push which would prevent my fixes curently there ever being exposed anyways
[21:13] <robru> sergiusens_, done
[21:13] <sergiusens_> thanks
[21:23] <elopio> robru: I need some help figuring out why is this trying to run the tests with python2:
[21:23] <elopio> https://jenkins.qa.ubuntu.com/job/autopilot-testrunner-otto-utopic/1873/consoleFull
[21:24] <robru> elopio, one sec
[21:29] <robru> elopio, what branch is that from?
[21:29] <elopio> robru: https://code.launchpad.net/~barry/dialer-app/py3autopilot/+merge/228892
[21:34] <imgbot> [21:37] <robru> elopio, wow, i don't have a clue. branch looks fine
[21:37] <robru> fginther, ^^ any ideas why that branch is getting python2 instaad of 3?
[21:37] <elopio> robru: yes, I checked that it puts the files on the right dir.
[21:39] <elopio> where does that Python choice: python2 come from?
[21:39] <elopio> that doesn't seem to be phablet-test-run
[21:39] <robru> elopio, yeah for sure, that's why it's not running any tests. it installs them under the python3 path and then however it's picking python2 can't find the tests
[21:40] <fginther> robru, elopio, I know exactly why this is...
[21:41] <fginther> elopio, the autodetection for checking of a tests needs 2 or 3 wasn't working any more. So long story short, dialer-app was setup to default to python2
[21:42] <fginther> ugliness abounds
[21:42] <fginther> I'd love to remove it if you want to land this branch
[21:43] <elopio> fginther: well, the thing is that I'm not sure this branch will pass. It passes here, but it has been a nightmare to get it green on jenkins.
[21:44] <elopio> fginther: is there a way to run this branch to confirm it's all good before changing it to python3 for all the branches?
[21:44] <fginther> elopio, I can make the python3 check smarter
[21:44] <fginther> just a minute and I'll have something to test this
[21:45] <elopio> fginther: thanks. You shouldn't be allowed to take vacations :)
[21:47] <elopio> I'll have to actually investigate things myself while you are not around :(
[21:51] <slangasek> plars: it's very difficult to write the script without knowing the environment it's going to be executed in, and the test harness's reporting interfaces.  I expect to be able to distinguish between different causes of failure, at different stages of the test.  How do I report that?  Do I declare that as multiple tests with interdependencies, setup/teardown, etc?
[21:52] <fginther> elopio, I have a test queued up, that will hopefully prove if I know what I'm talking about
[21:52] <elopio> thanks fginther.
[21:58] <barry> how do you not get swamped with build failure emails? :(
[22:01] <alecu> hi trainguards: we tested silo 17, and found some issues that need further debugging on our part. Can I ask to free silo 17 then?
[22:07] <fginther> elopio, http://s-jenkins.ubuntu-ci:8080/job/autopilot-testrunner-otto-utopic/1891/console
[22:07] <fginther> elopio, it used python3
[22:07] <elopio> fginther: great, that's good. But 4 errors it's pretty sad.
[22:08]  * elopio waits for the videos.
[22:08] <elopio> fginther: if I rebuild the results from the MP link, will it run with py3?
[22:08] <plars> slangasek: so you are saying it's more than one test? basically for this type of test, if it returns 0 it passes, if it returns anything else it's understood to be failed by the test runner.
[22:09] <fginther> elopio, I just need to push the fix first, give me a couple minutes
[22:09] <elopio> fginther: it failed because the lock screen appeared.
[22:09] <plars> slangasek: if it's a single failure but you want to report the reason for the failure, you can just print or echo that as part of the output before exiting. If you want to make it into more than one distinct testcase, that's possible as well though
[22:09] <slangasek> plars: the "test" is "did /var/crash/_bin_sleep.0.uploaded get created"; but it can fail at several points leading up to that, and I want more fine-grained information
[22:10] <slangasek> plars: ok - so exit status + text output, that's sufficient for me, thanks
[22:10] <slangasek> plars: what user will the tests run as on the phone, root or phablet?
[22:11] <plars> slangasek: right now, root since that's what you get when you adb
[22:11] <plars> slangasek: if you want to have the phablet user run it, you can just use sudo
[22:12] <ogra_> note that this will change soon though
[22:12] <slangasek> plars: yep - just needed to know the initial state of the env since crash filenames depend on the uid, thanks
[22:12] <kenvandine> bfiller, not yet...
[22:12] <kenvandine> i'll get that landed while you're out ;)
[22:12] <plars> ogra_: yeah, I did some stuff to help make sure we were ready for that as much as I could, but we will need to still be careful. I'm sure there could still be some corner cases lurking
[22:13] <plars> ogra_: any idea when, and if we can get some kind of test build for this?
[22:13] <plars> ogra_: iirc there were some phablet-tools fixes needed as well
[22:13] <ogra_> plars, yeah, and changing phablet-tools is my biggest horror
[22:13] <ogra_> i got phablet-shell working with a dedicated, user owned sshd ... but phablet-network is still not solved
[22:14] <fginther> elopio, I've pushed the fix for dialer-app with python3
[22:15] <barry> fginther: cool!  was it a bug in the branch?
[22:15] <fginther> elopio, I have no idea why the screen would be locking, perhaps the unlock screen logic has changed
[22:15] <robru> fginther, yeah we did recently land some changes to the lockscreen i think
[22:17] <fginther> barry, no, it was a bug in the test runner. I started to see new tests that were python3 but didn't have a dependency on python3-autopilot (they depend on other test suites instead). I put a fix in to address this and ended up breaking python3 checking for dialer-app
[22:17] <barry> fginther: gotcha.  thanks for fixing it
[22:18] <fginther> robru, whould those lockscreen changes apply to unity7?
[22:18] <robru> fginther, oh no, i meant on unity8, sorry
[22:18] <fginther> robru, no worries
[22:19] <robru> alecu, oh yeah, I can free it ;-)
[22:23] <alecu> robru: thanks. Now, I have a different landing, and a question. Should I have reused that same silo by changing the row on the spreadsheet, or am I doing right by filling a new row and asking for a different silo?
[22:24] <robru> alecu, depends what the new silo is... is it the exact same source packages?
[22:24] <alecu> robru: no, they are different source packages.
[22:25] <robru> alecu, then a new silo is better. citrain doesn't delete source packages from a silo when you drop the from the spreadsheet, so I have to delete them manually. but freeing the silo and then getting a new one deletes it, so it's better that way (easier)
[22:25] <robru> alecu, are you ready for the new one already?
[22:26] <alecu> yes, as of right now :-)
[22:27] <alecu> hmmm... only line 34 is
[22:27] <alecu> 30 is the one I asked to be dropped.
[22:27] <alecu> I'm setting line 30 to "Not ready"
[22:28] <robru> alecu, thanks
[22:28] <alecu> thank you, sir :-)
[22:28] <robru> alecu, you're welcome, you got 12 now
[22:30] <sergiusens_> robru: hey, why doesn't this work? https://ci-train.ubuntu.com/job/landing-016-1-build/118/console
[22:30] <sergiusens_> or do what I expect at least
[22:31] <robru> sergiusens_, you need to FORCE_REBUILD
[22:31] <sergiusens_> ok
[22:32] <sergiusens_> robru: is that the rule for empty commits?
[22:46] <robru> sergiusens_, mmmmm maybe? it has some logic for detecting if there was nothing new and then not uploading it. so I guess yeah
[22:47] <rsalveti> robru: bfiller: kgunn: another important emulator regression: bug https://bugs.launchpad.net/ubuntu/+source/android/+bug/1351097
[22:48] <rsalveti> not sure yet what caused it
[22:48] <alecu> rsalveti: perhaps its "swipe" instead of "swap" ?
[22:48] <rsalveti> ops, lol
[22:48] <robru> rsalveti, can you email that to sil2100?
[22:49] <rsalveti> my brain got confused because ogra was talking about swap at the same time I opened up this bug
[22:49] <ogra_> lol
[22:49] <robru> i gotta sign off, nearly 1AM here... g'night folks
[22:49] <rsalveti> robru: sure
[22:49] <ogra_> here too :P
[22:49] <ogra_> excuses
[22:49] <ogra_> :)
[22:49] <rsalveti> robru: where are you living now?
[22:49] <ogra_> he beca,me semi-fench
[22:49] <robru> rsalveti, still live in the same place, but I'm in strasbourg for GUADEC
[22:50] <rsalveti> oh, ok
[22:50] <robru> rsalveti, also jetlagged, can barely keep my eyes open ;-)
[22:50] <rsalveti> right :-)
[22:50] <rsalveti> got to sleep
[22:50] <robru> ciao!
[22:50] <rsalveti> *go
[23:04] <imgbot> [23:04] <imgbot> [23:18]  * alecu looks