[00:44] <bfiller> robru: I need rtm silos for line 81,82, and 83 when you have a chance
[00:44] <bfiller> robru: scratch that, 80, 81, and 82 I mean
[00:44] <robru> bfiller: oh goodies
[00:46] <robru> bfiller: well, let's do everything in 3's today! You got silos 6, 9, and 12.
[00:46] <bfiller> I love threes :)
[00:49] <robru> bfiller: i landed some changes to the build job today, let me know if anything explodes (should be good, I tested it all day before landing)
[00:49] <bfiller> robru: will do
[00:49] <robru> bfiller: thanks
[01:17] <robru> oooh
[03:53] <bzoltan> trainguards: I have flipped the "tested" switch for the silo17 with the QtC plugin. It has changes in the debian/ folder as it provides the new -autopilot package. This change was one of the main target of the 14.10 SDK tools.
[04:03] <Mirv> robru: mine has many builds (=manual uploads), but it's a preparation silo that will stay there for a good while so the status is not very useful to have updated
[04:23] <robru> Mirv: OK no worries, just wanted to test the newly-refactored build job, but bill built a bunch, looks good.
[04:26] <Mirv> bzoltan: I'm worrying slightly more about the autopilot tests being a new feature and there being no FFe
[04:27] <Mirv> (than the packaging changes as such)
[04:54] <bzoltan> Mirv:  the package change is that it introduces a new package
[04:55] <bzoltan> Mirv:  Well, the autopilot package is not pulled by any dependency and does nothing special than tests the QtC plugin.
[04:59] <Mirv> bzoltan: yeah, it's nothing special, but because it's a new package it will stop at archive admins' hands anyway so I'm just wondering before-hand what they'd think about it
[05:00] <Mirv> adding tests of course sounds of course always welcome, and the click support additions are more like bug fixes themselves, so maybe it's alright
[05:01] <Mirv> bzoltan: couldn't you do the debian/rules file installations from the qmake files instead of hand-copying so many files?
[05:02] <Mirv> not that it would be completely wrong, but ideally there wouldn't be any need for dh_override_auto_install
[05:57] <bzoltan> Mirv:  I  lost the net, I am not sure if you have seen my last two lines.
[05:59] <Mirv> alright, no I didn't, but I see them now in msg
[07:15] <bzoltan2> Mirv:  I made two new lines with the UITK landings... both RTM and Utopic... whichever can land first. Obviously RTM is the priority. It has 4 RTM bugs fixed.
[07:21] <brendand> ogra_, i'm testing silo 7 now - i guess it will require me to go through all the recovery mode dance etc, etc?
[07:45] <tsdgeos> is jenkins qa down?
[07:45] <tsdgeos> jenkins.qa.ubuntu.com/job/unity-phablet-qmluitests-utopic/1444 doesn't load here
[07:46] <tsdgeos> and obviously it came back after 5 minutes the moment i mentioned it here :D
[07:51] <Mirv> bzoltan2: ok. rtm first I'd say
[07:52] <bzoltan2> Mirv: Yes, I agree
[08:04] <Mirv> bzoltan2: sorry, took a while, assigned and kicked a build
[08:05] <bzoltan2> Mirv:  no hurry :) thanks
[08:06] <Mirv> (and rekicked)
[08:06] <Mirv> the build job has been reimplemented by robert, that first error sounds a bit like something might be a amiss. forcing (ignore step) + ignore dual works though.
[08:18] <davmor2> Morning all
[08:41] <brendand> davmor2, do you know where to get the custom tarball?
[08:41] <davmor2> brendand: yes from the channel
[08:42] <brendand> davmor2, ok
[09:18] <Mirv> pstolowski: thostr_: ^ both your unity-scope-mediascanner2 and mediascanner2 landings how now rtm silo and are building, so should be ready for testing soon.
[09:18] <pstolowski> Mirv, thanks
[09:19] <Mirv> pstolowski: in your scopes-shell landing, the MP URL is not MP URL but branch
[09:20] <Mirv> the fix-delete-later one
[09:20] <pstolowski> Mirv, ah, sorry, fixed
[09:20] <Mirv> thanks!
[09:22] <mzanetti> trainguards: silo utopic/006 tested. ready to go.
[09:23] <mzanetti> hmm... seems its not mirrored yet to a rtm silo.
[09:23] <mzanetti> we might want to do that first I guess
[09:25] <Mirv> kgunn: mzanetti there's unbuilt and untested unity 8 rtm-011 landing "Unity8 indicator polish fixes ("
[09:25] <Mirv> mzanetti: it's enough the sync silo is synced before the utopic one is cleaned
[09:25] <mzanetti> Mirv: oh... I thought kgunn tested the indicators polish for rtm already
[09:25] <mzanetti> Mirv: I can test that now
[09:26] <Mirv> mzanetti: ok. build it first, though :)
[09:26] <mzanetti> ack, building
[09:27] <mzanetti> Mirv: hmm... what does that mean? (silo rtm/11)
[09:29] <Mirv> mzanetti: err.. I don't know
[09:29] <Mirv> as usual, I'll workaround instead of trying to understand the error since it's beyond me
[09:29] <mzanetti> :D
[09:29] <mzanetti> that's you get the job done
[09:31] <ogra_> mzanetti, yo ...
[09:31] <mzanetti> ogra_: :)
[09:31] <ogra_> mzanetti, we seem to see unity8 crashes in app tests with the last utopic image
[09:31] <Mirv> mzanetti: ok the packages are binary copied now manually, just needs maybe 10-20mins so that they are Published instead of Pending
[09:32] <Mirv> as seen at https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu-rtm/landing-011/+packages
[09:32] <mzanetti> Mirv: so I can already start testing that ppa now, right?
[09:32] <mzanetti> ogra_: have some more details?
[09:32] <ogra_> mzanetti, if you scroll to the bottom of http://ci.ubuntu.com/smokeng/utopic/touch/mako/264:20141001:20140929.1/10758/ubuntu_calculator_app/
[09:32] <Mirv> robru: possibly interesting build failure https://ci-train.ubuntu.com/job/ubuntu-rtm-landing-011-1-build/40/console (workarounded now by manually copying packages)
[09:32] <ogra_> there is a .crash file
[09:33] <ogra_> unity8 itself also seems to have a bunch of errors doing its own tests in utopic http://ci.ubuntu.com/smokeng/utopic/touch/mako/264:20141001:20140929.1/10758/unity8/
[09:35] <ogra_> mzanetti, it seems rtm is fine ... so i think it would be good to find the issues before something migrates over
[09:36] <mzanetti> ogra_: that's a race condition... we're investigating into that
[09:36] <ogra_> cool, thanks !!
[09:36] <mzanetti> ogra_: but I think its in rtm too... just not happening always
[09:36] <ogra_> ah
[09:36] <mzanetti> ogra_: not sure what's up with the calculator tests yet... will check out
[09:36] <mzanetti> ogra_: do you know how I get the calculator tests on my device?
[09:37] <ogra_> https://wiki.ubuntu.com/Touch/Testing
[09:37] <ogra_> under "Running click tests"
[09:39] <mzanetti> ogra_: hmm... seems to fail with an exception
[09:39] <mzanetti> list index out of range
[09:39] <ogra_> do you have the patest phablet-tools ?
[09:39] <ogra_> *latest
[09:42] <dbarth> hi trainguards; silo rtm 16 ready to land now
[09:42] <mzanetti> ogra_: I didn't have that. now I upgraded. still happening though
[09:43] <ogra_> weird
[09:43] <mzanetti> well... let me upgrade everything... might take a bit
[09:48] <Mirv> mzanetti: yes, now ready
[09:49] <mzanetti> Mirv: thanks
[10:05] <Mirv> dbarth: you probably mean rtm 018? it's goind for QA signoff now.
[10:25] <ogra_> mzanetti, hmm i cant reproduce the unity8 crash when running the calculator tests here ...
[10:25]  * ogra_ re-runs again 
[10:25] <mzanetti> ogra_: phablet-test-setup still not working for me
[10:26] <ogra_> mzanetti, did you run "phablet-config autopilot --dbus-probe enable" first ?
[10:26] <ogra_> thats what i do ...
[10:26] <ogra_> and then:
[10:26] <ogra_> phablet-click-test-setup --click com.ubuntu.calculator;  phablet-test-run ubuntu_calculator_app
[10:27] <cjwatson> bzoltan2: That new version of click is in utopic now, by the way.  Not RTM yet - need to test that today and put through QA.
[10:27] <ogra_> runs fine here
[10:27] <mzanetti> ogra_: hmm.. no... didn't run that... from that wiki page I understood that's to be ran after installing the click packages... will try
[10:28] <cjwatson> camako,robru: Which specific builds are you talking about here?  All the virtualised builders in the Launchpad build farm are on trusty nowadays, but it's true that the devirtualised farm is still on precise.
[10:28] <cjwatson> (Mostly.  Being devirtualised it's not totally homogeneous, especially across architectures.)
[10:29] <ogra_> mzanetti, "phablet-click-test-setup" standalone would just install all click tests ..
[10:29] <ogra_> (no need for that)
[10:30] <mzanetti> ogra_: yeah... I tried with adding --click ...
[10:30] <cjwatson> camako,robru: The problem with upgrading the devirtualised build farm has historically been concerns about what effect it's going to have on building security updates for older but still-supported distributions (say, lucid-security or precise-security).  Possibly we can get over that ...
[10:41] <lool> (about to publish this one, any reason not to?)
[10:41] <lool> then will need a rtm silo  :-)
[10:42] <dbarth> Mirv: indeed rtm 18
[10:42] <bzoltan2> cjwatson: All right, the SDK counterpart has landed too few hours ago. Good job :) thank you.
[10:46] <Mirv> lool: oh, you're our tvoss now? how about testing rtm-001 with location-service?
[10:46] <Mirv> (the previous version, already in utopic)
[10:46] <lool> Mirv: hmm pretty sure that wont work
[10:46] <lool> or rather, that it needs a coordinated landing
[10:49] <Mirv> lool: anyhow, that ^ can't make it into rtm before the previous landing, since ^ already includes the previous landing (that landed together with dbus-cpp) also.
[10:49] <Mirv> either the 001 should be combined into the upcoming location-service rtm silo, or 001 should be landed first.
[10:50] <lool> Mirv: right; what I believe is that 001 or anything subsequent needs a coordinated update of the custom tarball
[10:50] <lool> it might be less effort for QA etc. to do a single location-service landing with everything I guess
[10:51] <Mirv> ok. added some notes to both landings in the spreadsheet for now.
[10:51] <Mirv> combining might be as easy as updating rtm-001 description and resyncing the location-service from utopic. but it's up to you to decide. certainly it'd mean less QA work.
[10:58] <Mirv> interestingly, the dbus-cpp change already landed together with media-hub
[11:07] <bzoltan2> Mirv:  do you know who is the LP guru/jedi I could ask to change the UITK project setup?
[11:10] <cjwatson> What do you need changing?  (I probably don't have relevant permissions, but I expect I could figure out who does)
[11:11] <Mirv> bzoltan2: ^ same question
[11:13] <Mirv> mzanetti: stop breaking the good train! :)
[11:13] <mzanetti> Mirv: :D
[11:13] <mzanetti> I don't even know what I'm doing to break it
[11:14] <Mirv> mzanetti: the -gles branch's watch file is wrong, should point to 007
[11:14] <mzanetti> ah right.... that's the other one...
[11:14] <mzanetti> will update
[11:14] <mzanetti> thanks
[11:28] <bzoltan2> cjwatson: I would need to add new milestones
[11:29] <bzoltan2> cjwatson: and it seems that only Kaleo could do that, but he is nor really working on the project anymore
[11:30] <cjwatson> bzoltan2: What have you tried?  The project driver should be able to do that.
[11:30] <cjwatson> (= ~ubuntu-sdk-team)
[11:30] <Mirv> bzoltan2: you seem to be admin of both https://launchpad.net/~pspmteam/+members and https://launchpad.net/~ubuntu-sdk-team/+members , so I cannot immediately see why you couldn't have "Create milestone" button on https://launchpad.net/ubuntu-ui-toolkit/trunk
[11:32] <cjwatson> bzoltan2: If you don't, then I can (due to being in ~registry), but I believe you should be able to do it yourself.
[11:33] <bzoltan2> cjwatson: \o/ cool... Me idiot I was looking for that button on the milestones page
[11:33] <Mirv> psivaa: first .crash retraced https://bugs.launchpad.net/ubuntu/+source/mediascanner2/+bug/1376219
[11:53]  * Mirv afk, back later
[11:54] <ogra_> brendand, what happened to the fix of phablet-click-test-setup ? would it be ready ?
[11:54] <ogra_> (i just ran into it with the patest unity8 landing ... cant run the tests on latest utopic anymore)
[11:54] <ogra_> *latest
[11:55] <asac> sil off today?
[11:59] <ogra_> asac, ge cracked his wrist
[11:59] <ogra_> *he
[12:01] <brendand> ogra_, it hasn't been merged yet: https://code.launchpad.net/~nskaggs/phablet-tools/fix-1371241-try2/+merge/236385
[12:01] <asac> ogra_: ouch
[12:01] <ogra_> brendand, yes, i was planning to do a clean up of the phablet-tools backlogs today (there are phablet-shell and demos-setup fixes too that could land together)
[12:02] <bfiller> Mirv: ubuntu silo 1 and silo 9 are ready to be released, but they are not in sync with rows in spreadsheet. In fact there is no row in spreadsheet for silo 1 at all
[12:02] <ogra_> brendand, heh, i think thats the wrong one :P
[12:03] <brendand> ogra_, i wasn't aware of any other
[12:03] <cjwatson> brendand: do you have an opinion on whether https://launchpad.net/ubuntu/+source/glibc/2.19-10ubuntu2 would need QA testing for ubuntu-rtm as well as dev testing?  The emulator doesn't seem to be broken on RTM right now, but it's a potential time-bomb that could be tripped by fairly innocent changes to other packages
[12:03] <cjwatson> and grr, looks like I still need to poke at autopkgtests there
[12:04] <ogra_> cjwatson, how hard would a rollback be ? we could just land it, have a full smoke tests and if needed roll it back
[12:04] <cjwatson> ogra_: probably relatively straightforward at least if I'm around to do the right removes/copies
[12:05] <ogra_> well, i'd do it that way then ... just let the automation catch potential issues and be prepared to roll back
[12:05] <ogra_> but thats indeed time consuming
[12:05] <cjwatson> I didn't think "just land and roll back if needed" was the approved philosophy for RTM though :P
[12:05] <brendand> ogra_, what other change to phablet-click-test-setup?
[12:07] <ogra_> brendand, hmm, might actually be the right one ... i'm a bit irritated that everything is yellow on that page
[12:09] <ogra_> brendand, yeah, applying that here helps ... i'll try to land it then
[12:12] <brendand> cjwatson, yeah i think so
[12:15] <bzoltan2> Mirv:  We have a cool UX fix in the line 88. It will take an hour or two to release it.
[12:18] <om26er> cprov, Hi! the dashboard have results for calendar app, while its removed from the image. Is there a reason not to remove that from the dasboard ?
[12:19] <cprov> om26er: perhaps there is a stray line in the spreadsheet, let me check
[12:21] <cprov> om26er: do you mean the silo 9, right ?
[12:22] <om26er> cprov, I didn't see the silo. I am talking about this dashboard http://ci.ubuntu.com/smokeng/utopic/touch/mako/264:20141001:20140929.1/10758/
[12:23] <om26er> weather app is no longer in the image but its results are still there.
[12:24] <cprov> om26er: oh, sorry, I was thinking about the train dashboard (biased, sorry).
[12:24] <om26er> ;)
[12:24] <cprov> om26er: let me check why it is still listed, I will come back to you.
[12:24] <om26er> cprov, alright, thanks
[12:36] <cprov> om26er: ubuntu_weather_app is a click package and is tested from the click-store based on a jenkins configuration file we control.
[12:36] <cprov> om26er: that explains why it is being tested, even if it is not included in the image.
[12:37] <popey> since when was it removed from the image?
[12:37] <om26er> popey, last week I believe.
[12:38] <popey> wat, no. calendar was removed.
[12:38] <om26er> cprov, ok, I will talk to plars on that and see what we can do.
[12:40] <cprov> om26er: np
[12:40] <popey> om26er: http://people.canonical.com/~ogra/touch-image-stats/258.changes 258 had an update, i see no removal.
[12:41] <om26er> popey, I don't see it on my phone
[12:41] <popey> om26er: what device / channel / version ?
[12:42] <om26er> I noticed it when the 'Upcoming event' menu stopped opening the calendar, first I thought that was a bug
[12:42] <om26er> popey, image 264 - utopic-proposed
[12:42] <popey> om26er: wait, you said _weather_
[12:42] <popey> now you mention calendar.
[12:42] <popey> I know calendar was removed. I'm asking about weather.
[12:43] <om26er> I said calendar above.
[12:44] <popey> 13:23:05 < om26er> weather app is no longer in the image but its results are still there.
[12:44] <popey> no, you said weather
[12:44] <om26er> popey, <om26er> cprov, Hi! the dashboard have results for calendar app, while its removed from the image. Is there a reason not to remove that from the dasboard ?
[12:45] <om26er> seems the second time, even I forgot to call it calendar :D
[12:45] <popey> heh
[12:45] <popey> lolz ☻
[12:45] <cprov> om26er: oh, okay then
[12:47] <ogra_> sergiusens, i'd like a top approval for https://code.launchpad.net/~ogra/phablet-tools/fix-phablet-shell-without-local-key/+merge/236696
[12:52] <pstolowski> Mirv, hey, if it's not too late, can I squeeze one more MP for same project  into line #86, rather than create a new request?
[12:53] <ycheng> trainguards help needed for landing
[12:55] <dbarth> trainguards can i get a silo reconfig on utopic 14?
[12:56] <dbarth> extra polish, but comes in 2 new branches
[12:58] <ycheng> trainguards I have no permission for the spreadsheet, and jhodapp has help me to use silos 003
[13:00] <ycheng> trainguards aha, I don't have the revision that I test it on.
[13:00] <ycheng> trainguards maybe I should get the version and comes back
[13:01] <pstolowski> trainguards, Mirv may I ask for reconfig of silo-004 (#86) - one more MP added?
[13:02]  * Mirv back
[13:07] <jhodapp> Mirv, what is ycheng-afk missing for landing utopic silo 3?
[13:14] <ogra_> brendand, it is in line 90 ... just waiting for a signoff from sergiusens for one branch there
[13:14] <Mirv> bfiller: 001 looks line line 39 with spreadsheet having lost the id.
[13:15] <Mirv> bfiller: I've restored the id now
[13:15] <Mirv> bfiller: so you an set it as tested as usual
[13:16] <bfiller> Mirv: ok, line 63 marked as tested but not showing up as ready to publish
[13:16] <Mirv> 009 funnily doesn't reflect the correct status in the spreadsheet
[13:16] <Mirv> bfiller: yeah, we've had that before, no idea what's it's related to. thanks for pinging about that.
[13:21] <Mirv> robru: another example: 1. assign silo 2. build 3. get https://ci-train.ubuntu.com/job/ubuntu-landing-006-1-build/52/console
[13:21] <Mirv> bzoltan2: building at https://ci-train.ubuntu.com/job/ubuntu-landing-006-1-build/53/console
[13:21] <Mirv> pstolowski: sure you can
[13:22] <Mirv> pstolowski: you just need to ask for a reconfig after you've added it
[13:22] <pstolowski> Mirv, great, thanks. yeah, i updated and asked a few irc lines later ;)
[13:22] <Mirv> pstolowski: I'm just getting there :)
[13:24] <Mirv> pstolowski: dbarth: reconfig requests done.
[13:24] <Mirv> ycheng-afk: jhodapp: so qtubuntu-camera on utopic?
[13:24] <jhodapp> Mirv, yeah
[13:25] <Mirv> ycheng-afk: jhodapp: I'm not sure how, but there's the silo, and no line for it whatsoever
[13:25] <jhodapp> Mirv, yeah me neither...it landed in RTM already
[13:26] <jhodapp> Mirv, we just need it to sync and land in utopic now
[13:26] <pstolowski> Mirv, grr, i think i hit ctrl+z one time too many and removed that change a few minutes ago; just added it back, sorry for that :(
[13:26] <Mirv> ycheng-afk: jhodapp: the silo 003 has version 20140918 of qtubuntu-camera, while both utopic and rtm already have 20140924. so at the very least, the current contents of silo 003 seem obsolete and the silo should be freed, plus a new line added for any new landing
[13:26] <dbarth> thank you sir!
[13:26] <dbarth> :)
[13:26] <sergiusens> ogra_: what is it waiting for me again?
[13:26] <pstolowski> Mirv, can you re-config one more time please?
[13:27] <sergiusens> ogra_: ssh key and shell
[13:27] <sergiusens> ?
[13:27] <ycheng> Mirv: jhodapp I have no permission for the spreadsheet, what I should do now ?
[13:27] <jhodapp> Mirv, sounds reasonable
[13:28] <Mirv> pstolowski: done!
[13:28] <jhodapp> Mirv, do we need a new empty MR then or something?
[13:28] <ogra_> sergiusens, yeah
[13:28] <sergiusens> ogra_: if I run that twice, won't it fail to check properly?
[13:29] <pstolowski> Mirv, thanks!
[13:29] <Mirv> ycheng: jhodapp: so just to be precise, the current silo comments are what landed in rtm at https://lists.canonical.com/archives/rtm-14.09-changes/2014-September/000438.html and to utopic as part of the _next_ upload (from trunk) at https://lists.canonical.com/archives/utopic-changes/2014-September/010654.html
[13:29] <sergiusens> ogra_: as you have an mkdir in there
[13:29] <ogra_> sergiusens, not if you did what it asked for
[13:29] <Mirv> ycheng: jhodapp: if you are only worried about the silo contents getting to utopic + rtm, there's nothing to be done
[13:29] <ogra_> sergiusens, yes, because known_hosts needs to exist
[13:29] <sergiusens> ogra_: well, consider that you run lots of phablet-shell instances and miss the first notice
[13:29] <jhodapp> Mirv, oh so both already have the MR then is what you're saying?
[13:30] <Mirv> ycheng: jhodapp: so what happened is that your utopic landing didn't happen, but the next landing did and it included both the "fix bug on use the lowest resolution instead of highest one" and the "Ensure androidControl is valid before using it to change exposure settings" since it was built from https://code.launchpad.net/~phablet-team/qtubuntu-camera/trunk
[13:30] <Mirv> jhodapp: yes.
[13:30] <ogra_> sergiusens, i wouldnt call that the typical use case (i would also not expect a developer to not own a ssh key indeed)
[13:30] <Mirv> so, I'll just free up that silo
[13:30] <ogra_> sergiusens, if you run it a second time it wuill fail with a key error
[13:30] <jhodapp> Mirv, oh excellent, so this can just be freed then and ycheng's landing is done
[13:30] <ogra_> sergiusens, but at least it tells you the first time what to do
[13:31] <jhodapp> ycheng, seems there's nothing for you to do now :)
[13:31] <Mirv> ycheng: all done already, thank you! ;)
[13:31] <jhodapp> thanks Mirv
[13:31] <sergiusens> ogra_: exit 1 then I guess would be better, wouldn't it?
[13:31] <ycheng> Mirv, jhodapp: I'll de-assign me on that issue, thanks !
[13:32] <ycheng> Mirv, jhodapp: hmm, I can wait for it's landing and then de-assigned myself.
[13:32] <ogra_> sergiusens, well, if anyone checks the exist status i assume yes :)
[13:32] <ogra_> let me fix that
[13:32] <jhodapp> ycheng, it has already landed, you don't have to do anything
[13:32] <Mirv> ycheng: the silo ^ was freed, it has landed and nothing more needs to be done
[13:32] <ycheng> jhodapp: aha, ack, thanks
[13:32] <jhodapp> ycheng, Mirv will remove the line from the spreadsheet
[13:32] <Mirv> jhodapp: thanks
[13:32] <ycheng> jhodapp: Mirv got it.
[13:33] <ogra_> sergiusens, exit 1 pushed
[13:36] <thostr_> Mirv: what is now with line 69?
[13:37] <thostr_> Mirv: I don't see the conflict as the "conflict" is said to have landed?
[13:37] <Mirv> bregma: ^ ignore. triggered wrong silo, aborted, running watch_only build to get the existing status back.
[13:37] <Mirv> thostr_: it was a conflict, not anymore, now assigning a silo
[13:37] <thostr_> Mirv: thanks
[13:47]  * Mirv reaches EODish soon, sil2100 is away today and robert will be here in 2h. I've some errands to run.
[14:01] <ogra_> sergiusens, i changed the MP a bit more now ... please take another look if you have time
[14:12] <thostr_> Mirv: was the package in rtm silo 22 actually built? or just the utopic one copied because build was hit too quickly?
[14:39] <cwayne> jdstrand: it just occurred to me, the cache is going to appear broken until we have an rtm rootfs with the new apparmor-easyprof
[14:51] <jdstrand> cwayne: I don't understand
[14:51] <jdstrand> cwayne: do you mean apparmor-easyprof-ubuntu? (apparmor-easyprof is a different package)
[14:52] <jdstrand> cwayne: assuming you meant apparmor-easyprof-ubuntu, yes, you would not want to push your custom tarball until the krillin image has 1.2.30
[14:52] <jdstrand> s/krillin image/krillin rootfs/
[14:53] <jdstrand> (which is what I was getting at earlier on deferring to you on the timing of server side stuff)
[14:53] <cwayne> right, sorry, I know they're different packages, I'm just lazy I guess
[14:53] <cwayne> jdstrand: right, well it's that + we needed it in the archive to build the new custom tarball anyway
[14:54] <jdstrand> right, and you need it in the archive to build the rootfs
[14:54] <mzanetti> trainguards: please reconfig silo 7 once more
[14:54] <mzanetti> had to add a qtubuntu-gles-sync
[14:56] <cwayne> ogra_: any idea when we might expect a new rtm rootfs?
[14:57] <ogra_> cwayne, 3am UTC
[14:57] <cwayne> :/
[14:58] <cwayne> davmor2: so i guess custom is off again til tomorrow :)
[15:02] <ogra_> cwayne, well, if needed we can indeed just build one
[15:05] <cwayne> ogra_: is there anything else that would prevent us from doing a build?  it's not super-duper-critical, but it'd definitely be good to have this in today
[15:05] <rsalveti> cjwatson: is there anything we can do to unblock glibc from proposed?
[15:05] <rsalveti> it seems the failed test cases were always failing
[15:05] <ogra_> cwayne, well, we just need to make sure everything is in the archive before we start the build
[15:05] <cjwatson> rsalveti: yes I'm working on it, no they weren't always failing
[15:06] <ogra_> theer are two new ones
[15:06] <rsalveti> at least from the jenkins jobs most of them had failures before that, but might be my impression
[15:06] <rsalveti> cjwatson: but cool, thanks
[15:06] <ogra_> most of them are overridden though
[15:06] <cjwatson> the two remaining started failing quite recently
[15:06] <cjwatson> I need to make sure they have nothing to do with glibc before forcing anything
[15:06] <rsalveti> yeah
[15:12] <cwayne> ogra_: ack, the only thing needed from my end would be apparmor-easyprof-ubuntu version 1.2.30
[15:13] <ogra_> cwayne, ok, rmadison says it is in both archives
[15:13] <ogra_> i'm in a meeting atm but will trigger an image then
[15:13] <cwayne> ogra_: thanks
[15:14] <cwayne> davmor2: would you be able to test custom after that ^ or would it be too late
[15:14] <davmor2> cwayne: yeap sure
[15:23] <balloons> ogra_, can you approve and push in with the next release of phablet-tools? https://code.launchpad.net/~nskaggs/phablet-tools/fix-1371241-try2/+merge/236385
[15:23] <ogra_> balloons, see line 90 on the spreadsheet :)
[15:23] <balloons> ogra_, :-)
[15:24] <ogra_> balloons, i'm landing three MPs, but one is waiting for signoff ( sergiusens took a look but didnt sign off yet)
[15:24] <ogra_> i'm confident i can land this within the next hours though ....
[15:24] <ogra_> (i really needed your fix today here(
[15:26] <balloons> ogra_, same, I ran into the issue again and it reminded me
[15:36] <ogra_> sergiusens, ^^^ can i have that phablet-shell MP approved ?
[15:36] <sergiusens> ogra_: well I didn't test yet
[15:36]  * sergiusens doesn't approve without testing
[15:36] <ogra_> ok
[15:45] <mzanetti> anyone here with powers to reconfig silo7?
[15:45] <ogra_> mzanetti, robru should be up soon
[15:45] <mzanetti> ah, great
[15:52] <cwayne> ogra_: has a build been kicked?
[15:54] <cjwatson> mzanetti: doing
[15:54] <ogra_> cwayne, yes, bot should announce it in a moment
[15:55] <cwayne> ogra_: awesome, thank you :)
[15:57] <mzanetti> cjwatson: thanks
[15:59] <imgbot> [16:22] <davmor2> ogra_: just waiting to see if it updates the issues tracker but it is here https://bugs.launchpad.net/ubuntu-keyboard/+bug/1376337 there are also a couple of sound-indicator issues that should probably be tagged but not blockers
[16:26] <Mirv> bfiller: not approved https://code.launchpad.net/~renatofilho/address-book-app/release-30-09-2014/+merge/236630
[16:27] <kgunn> fginther: hey, so, let's say for a silo we'd like to run our ui tests on unity, would there be a way to either a) automagically have these run? or b) is there a way to check out the source from a built silo to manually run them ?
[16:29] <kgunn> fginther: details would be to  ./build.sh, cd builddir, make check (which includes make test and make qmltests)
[16:29] <kgunn> we just keep chasing our tail on landing 1 or 2 broken ui tests
[16:30] <bfiller> Mirv: fixed
[16:30] <fginther> kgunn, can we discuss this later this afternoon (I've got a few meetings first)?
[16:31] <fginther> kgunn, it's sounds possible, but I want to make sure I understand the whole picture first
[16:31] <kgunn> fginther: sure...
[16:31] <kgunn> yep
[16:34] <ogra_> davmor2, http://people.canonical.com/~lzemczak/issues/ looks great, thanks
[16:35] <davmor2> ogra_: there is more yet
[16:35] <ogra_> add away :)
[16:40] <popey> ogra_: i am seeing a bit of memory leaking in unity8-dash with a lot of scopes enabled...http://paste.ubuntu.com/8473625/
[16:40] <popey> is there a bug for that already?
[16:40] <kgunn> popey: we did fix one recently
[16:40] <popey> ok. i have 11 open
[16:41] <kgunn> popey: but it might be different...
[16:41] <popey> started monitoring memory and haven't touched the device since. it's sat unlocked
[16:41] <popey> (odd it's not locking itself)
[16:43] <kgunn> popey: not sure if you can easily tell if this https://code.launchpad.net/~albaguirre/platform-api/fix-1206146
[16:43] <kgunn> is in the image you're on
[16:44] <kgunn> ...things taking longer to hit rtm branch it's hard to say
[17:04] <imgbot> [17:04] <imgbot> [17:05] <ogra_> cwayne, ^^^ enjoy
[17:05] <sil2100> davmor2: hey! I heard you found a regression in our last promoted image - do you have a bug handsy?
[17:06] <davmor2> sil2100: they should be in the issues tracker
[17:06] <davmor2> sil2100: I'm still looking through the image currently though
[17:10] <ogra_> is LP timing out for anyone else ?
[17:12] <dobey> ogra_: it is a bit yes
[17:12] <dobey> well, bug page loaded fine, but my MP timed out
[17:12] <ogra_> right
[17:12] <ogra_> same here
[17:15] <sil2100> davmor2: btw. are those blockers for next promotion?
[17:15] <ogra_> sil2100, they are in the last promoted image ...
[17:21] <bzoltan1> brendand: I have started the validation of the UITK release candidate from the RTM silo14. I see thatthe Unity tests still hang. Is there a special trick i could see the same results as on the CI Dash?
[17:22] <brendand> plars, should the unity8 tests still hang?
[17:22] <ogra_> no
[17:22] <ogra_> they never hung in rtm
[17:23] <cwayne> davmor2: latest custom is available for testing (ubuntu-touch/ubuntu-rtm/14.09-proposed-customized)
[17:23] <cwayne> sil2100: ^
[17:23] <sil2100> Excellent
[17:24] <ogra_> brendand, bzoltan1 http://dashboard.ubuntu-ci:8080/smokeng/utopic/touch_stable/krillin/75:20141001:20140929-d974fdc/503/
[17:24] <sil2100> davmor2: how long does the custom tarball testing take for you?
[17:24] <ogra_> there were unity8 failures today ... but it surely ran
[17:24] <ogra_> (and finished)
[17:24] <plars> bregma: where did you see it hang?
[17:25] <ogra_> plars, i think they are referring to the media-hub/gstreamer/whatever hang we had on utopic for a while
[17:25] <bzoltan1> ogra_: All right, fingers crossed that I will see the same results with my re-run
[17:28] <ogra_> bah
[17:28] <ogra_>  1907 root      20   0   81652   4748   4748 S  99,3  0,5  13:02.57 ubuntu-location
[17:28] <ogra_> lool, didnt you land a fix for that ?
[17:29] <ogra_> wow
[17:29]  * ogra_ has a black screen with panel after unlocking on image 76
[17:29] <ogra_> (and location service eating 100%)
[17:30] <ogra_> apps dont start anymore
[17:30] <ogra_> showing an eternal splash
[17:32]  * ogra_ reboots, this is unusable :(
[17:37] <cwayne> davmor2: sil2100: just for claiification, the custom tarball needing testing is 1412208333 (can be found by running cat /custom/build_id)
[17:37] <cwayne> i've got to run a quick errand, will brb to see if everything's going ok
[17:39] <ogra_> cwayne, could we sync that versioning with something ubuntu-ish at some point ?
[17:43] <cwayne> ogra_: i thought of that, but unsure how system-image server works (i.e. does it care about the version number or just the timestamps)
[17:45] <ogra_> cwayne, that i dont know ... but having something like YYYYMMDD.N-$STAMP would be more in line with all other versioning we use
[17:46] <cwayne> ogra_: i'll poke around, i would definitely like to change it to something more meaningful
[17:46] <cwayne> we need the build_id still because it tells whether or not we do a dconf update, but i dont think it should be used as the version number
[17:46] <ogra_> cwayne, talk to stgraber what s-i supports
[17:58] <bzoltan1> ogra_:  do you have a trick for silencing that device from adb shell? Not as I would not enjoy the music app's tests at 3am :) But am not sure if my family shares my passion to nightly tests.
[17:58] <ogra_> audio you mean ?
[17:58] <ogra_> hmm, no
[17:59] <ogra_> bzoltan1, you could try something like: amixer -D pulse set Master 1+ mute
[18:00] <ogra_> no idea if that would work though
[18:00] <ogra_> probably rsalveti knows another way
[18:00] <bzoltan1> ogra_: thanks, I will test it
[18:02] <davmor2> sil2100: sorry just got back from tea
[18:03] <davmor2> sil2100: So I think they will become blockers if they are not fix in the next 7 days but currently shouldn't blocker as it technically isn't a regression but are so user facing that they need fixing if that makes sense
[18:04] <davmor2> sil2100: custom tarball changes depending on what is landing but an hour or 2
[18:06] <lool> ogra_: no, we don't have a repro for the 100% location-service CPU usage
[18:06] <ogra_> ok
[18:06] <lool> ogra_: brendand might have filed it, haven't seen it yet
[18:06] <lool> will look after dinner
[18:06] <ogra_> lool, well, it is gone again after reboot
[18:07] <ogra_> and i havent noticed it ever before
[18:15] <sil2100> davmor2: btw. will you be able to take a look at utopic mako tomorrow? Since maybe we'll be able to promote a new image for that channel at least
[18:15] <sil2100> Sicne I guess the mediascanner scope issue seems to be fixed
[18:19] <davmor2> sil2100: I can once I get to the box that has my mako flo and manta in ;)
[18:29] <dbarth> hi trainguards, can i get a sync for silo utopic 14?
[18:29] <dbarth> i need it to populate line 54 for rtm
[18:31] <robru> dbarth: ok you got rtm4
[18:31] <dbarth> thank you
[18:31] <robru> you're welcome
[18:31] <dbarth> hey, btw, pitti did what's needed to get the langpacks up to date on rtm
[18:32] <robru> dbarth: oh cool, so you should be able to just rebuild oxide and have it work? or maybe rebuild isn't even needed
[18:32] <dbarth> so that last bug will get fixed on friday
[18:32] <dbarth> a rebuild is not needed
[18:32] <robru> even better
[18:32] <dbarth> right
[18:35] <infinity> camako: Can you give more details on the code that "requires a newer kernel"?
[18:36] <infinity> camako: If it's just a test that can't pass without a newer kernel present, it's fine to conditionally skip that on older kernels.  If it's that your package literally doesn't work with older kernels, that might be a bug on your end, IMO.
[18:36] <infinity> camako: It's generally sane to try to keep things working in a state where they can work in a chroot on top of our oldest supported LTS kernel.
[18:36] <dbarth> robru: and utopic14 is good for publishing
[18:37] <camako> infinity, thanks for the comments ...
[18:37] <camako> infinity, this is for Mir desktop
[18:37] <camako> and we are ok not supporting kernels older than 3.11
[18:38] <camako> where this kernel feature we depend on was introduced
[18:38] <camako> Since mir on the desktop won't be ready for a while
[18:38] <infinity> camako: Right, that's perhaps a fair decision to make.
[18:38] <robru> dbarth: https://ci-train.ubuntu.com/job/ubuntu-landing-014-2-publish/38/console please approve your merges
[18:39] <infinity> camako: It won't prompt us to run around and upgrad the buildds in a hurry, though, so you might want to conditionally skip the test, and work out an alternate testing scenario (ie: build with tests enabled in a virt PPA, which are all 3.13 now).
[18:39] <camako> infinity, yea we discussed this during the review process... So how do you bypass a failing test on an old kernel?
[18:39] <infinity> camako: The test itself should check the running kernel version before attempting to run.
[18:40] <camako> infinity, oh ok...
[18:40] <cjwatson> Have a helper function that tests uname(2) or something
[18:40] <camako> sure, I'll look into that
[18:40] <cjwatson> Or, better, check for availability of the actual kernel feature you're using
[18:40] <cjwatson> Testing kernel version numbers is generally a last resort and not usually a good idea
[18:41] <infinity> Yeah, what he said.
[18:41] <infinity> Testing the feature availability (is it a syscall?) is the sanest route.
[18:41] <camako> cjwatson, yes I believe that would be quite straightforward
[18:41] <cjwatson> Cool
[18:41] <camako> it's just a flag passed to open
[18:41] <camako> O_TMPFILE
[18:41] <cjwatson> infinity: Do you know if we have a policy issue with upgrading buildds to trusty?
[18:42] <cjwatson> I know there's a general thing about "don't upgrade metal to trusty, switch to the cloud", but we know that full conversion of buildds to the cloud is (a) in progress and (b) blocked for a while ...
[18:42] <infinity> cjwatson: So, yes, there's the "don't upgrade metal" issue, but I think elmo and I have already discussed that buildds are a unique snowflake there.
[18:42] <cjwatson> k
[18:43] <infinity> cjwatson: I also am personally annoyed that "the cloud" must mean openstack, as the buildds are ALREADY a cloud and, in fact, the oldest cloud in Canonical. :P
[18:43] <cjwatson> Yeah, not maybe as horizontally scalable as we might like but indeed
[18:43] <cjwatson> We should probably try to figure out who's working on scalingstack/{power,arm}
[18:43] <cjwatson> If anyone
[18:43] <infinity> cjwatson: So, yeah, the only blocker for upgrading to trusty on x86 is time and a ticket, but I've been in no rush because powerpc has a kernel bug to hunt before we can upgrade, and armhf is just going to have the hardware replaced instead of upgraded.
[18:44] <cjwatson> So maybe midway armhf can just be installed fresh with trusty (it might have to be anyway), and that'll take care of most of mir's needs
[18:44] <infinity> cjwatson: But I also don't see any factors other than dogfooding that should force the issue either.
[18:44] <infinity> cjwatson: And the dogfooding argument should usually happen before an LTS releases, not after. ;)
[18:44] <infinity> cjwatson: Yeah, the midways will be tusty from day 1.
[18:45] <infinity> But Mir builds places other than armhf, so the kernel feature testing before running the test thing will be required regardless.
[18:45] <infinity> And is also the right way to do it.
[18:45] <cjwatson> Yep
[18:46] <infinity> Assuming that build environment == runtime environment is pretty much universally wrong, IMO.
[18:47] <infinity> camako: Oh, there are reasons other than kernel version to test O_TMPFILE anyway (and, maybe a good argument to have a forked path in your code, not your testsuite).
[18:48] <infinity> camako: It's not supported on all filesystems.
[18:48] <infinity> camako: So, if this code was running on, say, btrfs, it would explode, even if on a current kernel.
[18:48] <camako> infinity, good point
[18:48] <cjwatson> Yeah, that gets more delicate, you have to make sure your test runs against a file on the relevant fs
[18:48] <infinity> camako: Not sure how one determines this without an expensive try;fail;fall-back, though. :/
[18:49] <cjwatson> You can probably cache it for each fs
[18:49] <davmor2> sil2100, cwayne: I'm not getting a location so I checked the /var/crash folder crashes for trust-store and location ouch
[18:49] <davmor2> not sure if that it the custom image fault or the app-armor update
[18:49] <cjwatson> using statvfs().f_fsid or something
[18:49] <infinity> cjwatson: Well, it depends on how often the flag is passed to open(2) during runtime.  If it's frequent, it's worth a startup check to determine if the target FS will support it, then cache the result.
[18:50] <cwayne> davmor2: there was 0 change in custom pertaining to either of those
[18:50] <infinity> If it's a one-time thing, that's a huge performance hit with little gain, when you could just avoid the flag.
[18:50] <cwayne> or anything related to HERE
[18:50] <camako> we are opening /dev/shm... and it's a one-time thing
[18:50] <infinity> camako: Ahh, if it's /dev/shm, you're safe.
[18:50] <infinity> camako: That's guaranteed to support it (in newer kernels).
[18:50] <cjwatson> ok, so just try O_TMPFILE and fall back if you get EINVAL
[18:51] <infinity> camako: So, going back to "the testsuite can test this" rather than testing it in the code seems reasonable.
[18:51] <cjwatson> (fall back => skip test, if you only want to cover this in the test suite)
[18:51] <camako> indeed
[18:52] <camako> thanks for your feedback guys.. appreciate it..
[18:52] <davmor2> ev: I thought that previous errors was going to get a fix so that the error tracker showed the previous errors :(
[18:55] <davmor2> sil2100: you might want to add tags to https://bugs.launchpad.net/unity8/+bug/1373312 and https://bugs.launchpad.net/unity8/+bug/1373313 too
[18:55] <sil2100> Oh?
[18:55] <sil2100> New stuff!
[18:55] <sil2100> davmor2: blockers?
[18:55] <cjwatson> sil2100: your landing team mail said that emulator images were broken on the RTM channels - are you sure?  the breakage I'm aware of is only in devel-proposed
[18:56] <cjwatson> (possibly devel)
[18:56] <sil2100> cjwatson: someone mentioned to us that the emulator image we promoted for ubuntu-rtm was broken
[18:56] <cjwatson> and I was able to use the emulator on ubuntu-rtm as of this morning
[18:56] <cjwatson> well, ubuntu-rtm/14.09-proposed was fine today
[18:56] <davmor2> sil2100: no user facing again but block in 7days if not fixed they got released in image 3 so not a regression
[18:56] <sil2100> cjwatson: maybe it's fixed in -proposed, but ogra_ mentioned it being broken in ubuntu-rtm/14.09
[18:56] <sil2100> davmor2: ACK
[18:56] <cjwatson> mkay
[19:03] <cwayne> davmor2: so how's it look otherwise?
[19:03] <cwayne> i need to disappear for an hour or so pretty soon, but ill be able to pop in to publish if needed
[19:04] <davmor2> cwayne: so it is broken on 76 ToyKeeper just confirmed so it looks like this isn't an issue with custom, but it means any of the scope that need location don't actually get it
[19:04] <ToyKeeper> I see a crash on boot for both.
[19:05] <davmor2> jdstrand: I'm going to have a dig but I think there were only a couple of things land in image 76 and your app-armor was one :(
[19:06] <cwayne> davmor2: right, but with 76 the scopes that need location won't get them anyway
[19:06] <ToyKeeper> Yesterday one of the new default scopes did ask me to allow location permission...  couldn't tell if it worked though.
[19:06] <cwayne> so no reason to block custom :)  main thing that changed is we set favorites (if the user has never set them) and we have a new cache to match jdstrand's upload
[19:06] <cwayne> so if we block custom, it'll be back to like 5 minute boots on krillin :/
[19:07] <davmor2> cwayne: which will mean that there should be a revert of the thing that broke it if that is app-armor we can't land custom either right
[19:07] <cwayne> davmor2: are there any apparmor denials?
[19:08] <davmor2> cwayne: only just started digging
[19:08] <jdstrand> davmor2: apparmor-easyprof-ubuntu? what broke?
[19:08] <jdstrand> I find it pretty unlikely that would've broken anything
[19:09] <jdstrand> davmor2: are you talking about indicator-sound? that is confined so not affected by that upload
[19:09] <jdstrand> err
[19:09] <jdstrand> that is *not* confined
[19:09] <davmor2> jdstrand: location and trust store started crashing on 76 only adb and app-armor changed
[19:10] <jdstrand> location is also not confined by apparmor
[19:10] <cwayne> i can't reproduce btw on 88
[19:11] <jdstrand> davmor2: please do 'grep DEN /var/log/syslog' and paste the denials
[19:11] <cwayne> well 14.09-proposed-customized 88
[19:12] <davmor2> jdstrand: http://paste.ubuntu.com/8474451/
[19:13] <cwayne> all those leaf-net ones are just noise
[19:14] <rsalveti> bzoltan1: you can use the cmdline tools from pulse to mute the device
[19:14] <rsalveti> don't use alsa
[19:14] <jdstrand> com.canonical.scopes.timeout_timeout_0.4.10 is not using the connection api but trying to access network-manager directly
[19:15] <jdstrand> that is a bug in that app
[19:15] <bzoltan1> rsalveti:  you would not use `amixer -D pulse set Master 1+ mute`?
[19:15] <bzoltan1> rsalveti: any better suggestion?
[19:15] <rsalveti> pactl probably, let me check
[19:17] <cwayne> jdstrand: would you mind logging a bug against hanloon?
[19:17] <jdstrand> yelp is a bug in the scopes api-- it is trying to create a directory not specified in https://wiki.ubuntu.com/SecurityTeam/Specifications/ScopesConfinement
[19:18] <cwayne> that one has an upstream bug, i can try and find it
[19:18] <jdstrand> it looked different to me
[19:19] <jdstrand> cwayne: is hanloon for timeout?
[19:19] <rsalveti> bzoltan1: pacmd set-sink-mute sink.primary 1
[19:19] <davmor2> jdstrand: I can file the bugs if you can point me to what the denial is for
[19:19] <cwayne> jdstrand: hanloon is for all the scopes in /custom, so yep
[19:19] <jdstrand> oh it seems like a bunch of theme
[19:21] <jdstrand> all network manager denials: bug #1376408
[19:23] <cwayne> jdstrand: thank you
[19:23] <cwayne> but thats also unrelated to davmor2's issue (and in fact none of thses scopes except news have even changed since the last custom tarball release)
[19:27] <jdstrand> so, yelp should be using @{HOME}/.local/share/unity-scopes/leaf-net/@{APP_PKGNAME}, but it is using @{HOME}/.local/share/unity-scopes/@{APP_PKGNAME}_@{APP_APPNAME}
[19:27] <jdstrand> that is a bug in yelp of the scopes api
[19:28] <jdstrand> davmor2, cwayne: ^
[19:28] <cwayne> jdstrand: yelp is only using what the scopes api is giving it
[19:28] <cwayne> it could be specific to the go bindings maybe.. but all the scope itself does is call ScopeBase.ScopeDirectory()
[19:28] <cwayne> jdstrand: but regardless I'll take a look and see what I can find
[19:29] <jdstrand> then that is returning the wrong thing
[19:29] <jdstrand> I can't seem to find the bug
[19:29] <jdstrand> I thought there was one
[19:30] <jdstrand> I'll file it
[19:31] <davmor2> ToyKeeper: can you do grep DEN /var/log/syslog and see if it is similar to http://paste.ubuntu.com/8474451/ please I want to double check that they are not masses apart
[19:32] <cwayne> davmor2: jdstrand: I've got to run for an hourish, please shoot me an email if theres any ?'s, but it really seems like whatever is causing location-service to crash is unrelated (and I can't for the life of me reproduce)
[19:32] <ToyKeeper> davmor2: http://paste.ubuntu.com/8474560/
[19:33] <robru> ted: do you have any idea what that error meant? wtf?
[19:34] <ted> robru, No, I built the package locally just to be sure. But no.
[19:34] <davmor2> jdstrand, cwayne: so ToyKeeper 's result is looking pretty similar to the one I pasted but nothing obvious, I'll keep digging in errors to see if I can see the faults that were filed there
[19:34] <ted> robru, Restarting the build I think it's going find now…
[19:34] <robru> ted: messed up
[19:37] <jdstrand> cwayne, davmor2: bug #1376416 for yelp
[19:38] <jdstrand> that leaves two denials:
[19:38] <jdstrand> Oct  1 18:14:46 ubuntu-phablet kernel: [  232.213753] (1)[9350:scoperunner]type=1400 audit(1412187286.501:143): apparmor="DENIED" operation="open" profile="com.canonical.scopes.timeout_timeout_0.4.10" name="/android/system/lib/libGLESv2.so" pid=9350 comm="scoperunner" requested_mask="r" denied_mask="r" fsuid=32011 ouid=0
[19:38] <jdstrand> Oct  1 18:14:46 ubuntu-phablet kernel: [  232.395523] (0)[9388:com.ubuntu.yelp]type=1400 audit(1412187286.681:145): apparmor="DENIED" operation="mkdir" profile="com.ubuntu.yelp_yelp_1.0.26" name="/home/phablet/.local/share/unity-scopes/com.ubuntu.yelp_yelp/" pid=9388 comm="com.ubuntu.yelp" requested_mask="c" denied_mask="c" fsuid=32011 ouid=32011
[19:38] <jdstrand> Oct  1 18:45:47 ubuntu-phablet kernel: [ 2093.373992] (0)[25723:webapp-containe]type=1400 audit(1412189147.661:151): apparmor="DENIED" operation="open" profile="com.nokia.heremaps_here_1.0.1" name="/custom/etc/dconf_profile" pid=25723 comm="webapp-containe" requested_mask="r" denied_mask="r" fsuid=32011 ouid=0
[19:38] <jdstrand> whoops
[19:38] <jdstrand> Oct  1 18:14:46 ubuntu-phablet kernel: [  232.213753] (1)[9350:scoperunner]type=1400 audit(1412187286.501:143): apparmor="DENIED" operation="open" profile="com.canonical.scopes.timeout_timeout_0.4.10" name="/android/system/lib/libGLESv2.so" pid=9350 comm="scoperunner" requested_mask="r" denied_mask="r" fsuid=32011 ouid=0
[19:39] <jdstrand> both of these are due to changes outside of apparmor-easyprof-ubuntu
[19:39] <jdstrand> davmor2: these are also not related to location service
[19:40] <davmor2> jdstrand: https://errors.ubuntu.com/problem/361a1c5dde22e0ce444d9aaa23180449a7a52446 could be this fault which looks like it started on utopic yesterday
[19:41] <jdstrand> it is getting a little frustrating seeing new denials that no one is reporting
[19:43] <jdstrand> cwayne: so, apps aren't supposed to be using dconf
[19:43] <jdstrand> cwayne: do you know what /custom/etc/dconf_profile is about with the here app?
[19:46] <davmor2> jdstrand: I can run grep DEN /var/log/syslog once a day for you and email to you if you want?
[19:48] <jdstrand> davmor2: that could be helpful. I'd really like to see this automated though in the ci infrastructure...
[19:49] <jdstrand> ie, so that things are blocked if they introduce new denials
[19:50] <davmor2> jdstrand: that would be the ultimate in awesome :)
[19:50] <jdstrand> :)
[19:56] <davmor2> hey ogra_ plars would it be possible to make that happen and maybe add the result to the image results? ^  ie run grep DEN /var/log/syslog and initially just store the output on the image results?
[19:57] <davmor2> eventually have it go green if there are none and red if there is :)
[19:58] <plars> davmor2: jdstrand: is this not covered by the /home/phablet/bin/check-clickhook-rules check that we added before?
[20:00] <davmor2> plars: no idea
[20:01] <plars> davmor2: also, is there any possibility that a test (like security tests) could throw a false positive here?
[20:02] <cjwatson> rsalveti: looks like the last unforced autopkgtest (aria2) is passing locally for me - just double-checking that and then I'll force-skiptest glibc
[20:02] <rsalveti> cjwatson: great, thanks
[20:02] <cjwatson> rsalveti: thanks for poking zodb earlier
[20:02] <cjwatson> hate these flaky tests
[20:02] <rsalveti> np
[20:02] <rsalveti> yeah
[20:02] <davmor2> plars: possibly
[20:04] <davmor2> night all, cwayne I'll take another look in the morning but I just ran out of day trying to figure out why location is dying
[20:05] <jdstrand> plars: what project is that in again?
[20:06] <jdstrand> plars: security tests would totally throw false positives (thousands of them)
[20:06] <brendand> mvo_, are you around?
[20:06] <brendand> mvo_, there's an issue with the rtm silo for click
[20:06] <jdstrand> plars: I think we would just want to block on apps suddenly geteting new denials
[20:06] <brendand> cjwatson, ^
[20:07] <brendand> cjwatson, actually it's your name next to the test results
[20:07] <plars> jdstrand: we don't really have a way to inspect history while running the test
[20:07] <jdstrand> plars: at least as a start. apps are what are confined, and they use the services via their autopilot tests, etc
[20:07] <cjwatson> brendand: what is it?  I'm only around for a few more minutes and I suspect mvo has finished for the day
[20:07] <jdstrand> it could be after
[20:07] <cjwatson> (and I'm on vac tomorrow)
[20:07] <brendand> cjwatson, it seems the 'stop apps when uninstalling' fix doesn't work
[20:07] <cjwatson> brendand: yes I already reopened the bug
[20:08] <jdstrand> you'd just need to filter out denials prior to test start
[20:08] <cjwatson> brendand: it's fine as long as it hasn't actually made things any worse (which AFAIK it hasn't)
[20:08] <cjwatson> it fails because it removes the registration link before trying to stop the app, so can't get its manifest
[20:08] <cjwatson> brendand: see end of https://bugs.launchpad.net/ubuntu/+source/click/+bug/1232130
[20:09] <cjwatson> brendand: I don't think this should block landing though - it didn't stop it before and it doesn't stop it now, but it also doesn't break app removal
[20:12] <brendand> cjwatson, alright i'll take that into account
[20:12] <cjwatson> we should absolutely fix it up properly in the next landing though
[20:14] <cjwatson> brendand: I'm glad to see QA noticed this too though! :-)  Sorry, I should've mentioned it in the spreadsheet to save on worry
[20:14] <mvo_> brendand, cjwatson: thanks, I will work on a fix tomorrow
[20:14] <mvo_> (and will also find out why the test did not fail for this :/)
[20:16] <cjwatson> mvo_: because you happened to pick a package name to remove that exists in two database layers, so .remove just removes it from the top one, maybe?  though that should've caused the version to be wrong
[20:16] <cjwatson> hopefully it's shallow-ish anyway
[20:16] <mvo_> cjwatson: right, I check it out
[20:16] <cjwatson> thanks
[20:17] <cjwatson> rsalveti: glibc forced
[20:32] <cwayne> davmor2: so what's the verdict?
[20:39] <cwayne> ah nm sorry davmor2 I'd missed your message earlier, tomorrow's good
[20:39] <robru> bfiller: you got rtm9
[21:59] <rsalveti> slangasek: may I ask some help to approve pulseaudio and indicator-sound? so we can completely land silo 18
[21:59] <slangasek> rsalveti: ok. is there a bug open / patch to review?
[22:00] <slangasek> hmm I suppose clicking through the silo will take me to the diffs
[22:00] <rsalveti> slangasek: the main bug is https://bugs.launchpad.net/ubuntu/+source/indicator-sound/+bug/1368827
[22:01] <slangasek> ah, but maybe not for pulseaudio
[22:01] <slangasek> ok
[22:01] <rsalveti> pulse changes are just bugfixes
[22:01] <rsalveti> and also only relevant to touch
[22:01] <rsalveti> the main one that adds a bit more logic is indicator-sound, but also for touch
[22:01] <rsalveti> slangasek: I though we had a FFe for it, but saw that it was not included at bug 1371635
[22:01] <rsalveti> so my mistake for trying to push it before checking that properly
[22:02] <rsalveti> I added one comment to add indicator-sound to the list of packages
[22:02] <slangasek> right, I responded there - basically, it's not included because the package isn't touch-specific
[22:02] <rsalveti> oh, you already replied
[22:02] <slangasek> doesn't mean it shouldn't go in, but it means we should be extra careful that it doesn't regress non-touch stuff
[22:02] <rsalveti> oh, right, similar to the other indicators in there I guess
[22:02] <rsalveti> let me check
[22:03] <rsalveti> you're right, the other indicators in there are common to the desktop
[22:03] <rsalveti> sorry, not common
[22:04] <rsalveti> slangasek: want me to open a separated bug for this package?
[22:04] <slangasek> no, we can use the existing bug report
[22:12] <rsalveti> slangasek: updated bug
[22:12] <rsalveti> argh
[22:12] <rsalveti> bug 1368827
[22:12] <rsalveti> what is wrong with my copy & paste
[22:21] <robru> bfiller: rtm12
[22:21] <bfiller> robru: fast service today :) thanks!
[22:21] <robru> bfiller: you're welcome!
[22:22] <robru> bfiller: just a heads up, if you change your MPs and need a reconfigure, the button for that moved off the dashboard and into the spreadsheet. I'll make a public announcement about this soon but I'm still ironing out some bugs here
[22:23] <bfiller> robru: thanks for the heads up
[22:54] <slangasek> rsalveti: so the idea here is that the sink-input-by-media-role:$foo are only present if we're on touch?
[22:54] <rsalveti> slangasek: they can be part of the desktop, but the dbus module that export that interface to the indicator is only available on touch
[22:55] <rsalveti> the stream can have basically any role, as the app is responsible for setting that up, we just have a small set of supported ones on touch
[22:55] <rsalveti> and this additional work was to enable this extra dbus interface so it can be used to change volume per roles
[22:56] <rsalveti> so if the dbus interface and the needed roles are not available in the stream-restore internal database, it'll act like today (only controlling the main sink)
[22:57] <rsalveti> if the dbus interface is available, and the required set of roles are available in stream-restore, then the volume will reflect on the current active role (or alert by default)
[22:57] <slangasek> ok. what package provides this new dbus interface?
[22:57] <rsalveti> slangasek: pulse itself, but that's disabled by default, and the config enabling that is part of ubuntu-touch-session
[22:58] <rsalveti> we have a separated pulse audio config for touch
[22:58] <rsalveti> the pulse changes are just basically to fix that use case (like preloading volume per roles, which was broken)
[22:58] <rsalveti> I'm also sending both pulse patches upstream as we speak
[22:59] <slangasek> rsalveti: ok, FFe approved, and indicated this in the bug log
[22:59] <rsalveti> slangasek: great, thanks so much
[23:01] <rsalveti> great, glibc also migrated, next image should make the x86 emulator to work again
[23:43] <rsalveti> slangasek: ok, both pulseaudio patches were sent upstream, will update the package later on once they get accepted