[00:09] <asac> doanac: plars: ok pleas shoot me and dirocks etc. a mail what happened. 'night
[02:51] <veebers> Is there anyone around that is able to tell me/find out why I can't see a CI job for this approved MR? https://code.launchpad.net/~veebers/unity8/adding_unlock_emulator/+merge/191328
[02:53] <cjohnston> veebers: what do you mean can't see a CI job?
[02:54] <veebers> cjohnston: hmm, actually I might be wrong, I was expecting there to be an autolanding job, but was looking at the wrong one (i.e. -ci) and the autolanding is disabled currently
[02:55] <cjohnston> ok
[02:55] <veebers> cjohnston: so  a different, better, way to ask my question is: What do I need to do to take that MR from Approved to Merged?
[02:57] <cjohnston> veebers: what is causing all the things to be unstable?
[02:57] <cjohnston> I'd guess that needs to be fixed
[03:02] <veebers> cjohnston: ack, cheers
[07:51] <ogra_> asac, doanac, i think it would be clever to wait until the session is completely up before running systemsettle ... after all we want to test the user experience
[07:51] <ogra_> (i.e. make it check if unity8 is there before firing)
[07:54] <didrocks> ogra_: do you mind refreshing me on what is systemsettle already?
[07:55] <ogra_> didrocks, it takes ten samples from top and waits if the system goes >97% idle
[07:55] <ogra_> apparently we run it directly at boot
[07:55] <didrocks> ah ok ;)
[07:55] <ogra_> running after the session is up seems like a better usecase to me
[07:56] <didrocks> yeah, makes sense to have multiple tests, one to know how long we take to have everything started
[07:56] <didrocks> and another, to know the idle when the session if fully loaded
[07:56] <ogra_> well i want to introduce bootcharts into the tests
[07:57] <ogra_> so that part should become more fine grained anyway ... if you want to see the load on boot and how much something takes
[07:57] <didrocks> right
[08:01]  * ogra_ grins seeing lool's comment on the bonita thread 
[08:02] <didrocks> ogra_: well, for all java/jboss webapps, I don't expect less time even on a server to start TBH :p
[08:03] <ogra_> i meant the "luckily we didnt disable swap" :)
[08:03] <didrocks> ahah
[08:03] <ogra_> we had so many discussions about that before release ...
[08:03] <didrocks> yeah
[08:03] <didrocks> also, we didn't disable adb
[08:03] <didrocks> told you! ;)
[08:03] <ogra_> there is a usecase ... for the crazy ones
[08:03] <ogra_> didrocks, well, thats just because i ran out of time
[08:04] <ogra_> it was actually planned to habe it off by default so you need to enable it from the terminal first
[08:04] <ogra_> *have
[08:04] <didrocks> ogra_: I know, I just told you we won't have time :)
[08:04] <ogra_> true
[08:04] <didrocks> ogra_: terminal or system settings?
[08:04] <ogra_> i'Äm to optimistic at times
[08:04] <ogra_> terminal
[08:05] <ogra_> there was no UI planned for dev mode
[08:05] <didrocks> interesting, we should maybe
[08:05] <ogra_> (we should do that for 14.10 in any case=
[08:05] <ogra_> )
[08:05] <ogra_> err
[08:05] <ogra_> 14.04
[08:05] <didrocks> ;)
[08:05] <didrocks> so you always live in the future
[08:05] <didrocks> and ev always lives in the past (he keeps telling 12.10 :p)
[08:06] <ogra_> bah so i uploaded an internet radio app and now my BT speaker inst found :(
[08:06] <didrocks> for some games as well it seems?
[08:06] <ogra_> and some news sites
[08:06] <didrocks> yep
[08:06] <ogra_> and a TV program planner :)
[08:07] <didrocks> ahah :)
[08:07] <didrocks> and we have 2 xkcd apps
[08:07] <ogra_> we might end up havfing 10 ... :)
[08:07] <didrocks> right ;) still 0 direction/driving apps
[08:07] <didrocks> but 2 xkcd apps ;)
[08:07]  * ogra_ expects the same chaos as googlew play has over time 
[08:08] <ogra_> well we have OSM ...
[08:08] <ogra_> not with firections though
[08:08] <ogra_> *directions
[08:08] <didrocks> yep
[08:08] <ogra_> and google maps works as well
[08:08] <ogra_> (with directions)
[08:09] <ogra_> webapps are just so easy (creating the click package takes less than 10min if you have a template app ... (of which 9min are used to find a proper icon)
[08:09] <didrocks> google maps?
[08:09] <didrocks> we do have a wrapper for it?
[08:09] <didrocks> or not yet?
[08:09] <ogra_> sure, go to maps.google.com
[08:09] <didrocks> ah ok
[08:10] <didrocks> I'll try to exercise that as a click app as well
[08:10] <didrocks> today
[08:10] <ogra_> it has some user agent issues so the page flips to desktop at times
[08:10] <didrocks> better that we learn our technology :)
[08:10] <ogra_> http://daker.me/2013/10/package-your-webapp-for-ubuntu-touch.html
[08:11] <ogra_> thats an intresting hack to force the user agent for a page
[08:11] <ogra_> (though thats far more effort than i had to do for my apps)
[08:11] <didrocks> ogra_: excellent! will try that :)
[08:11]  * didrocks finishes first the morning tasks
[09:02] <asac> ogra_: didrocks: what time do we want to build the image?
[09:02] <asac> :)
[09:02] <asac> now or later?
[09:03] <didrocks> asac: as we are unsure that the dashboard is going to pick the right image (and to not confuse result, I would prefer to have the change before we have the image built), I would like to wait for doanac "go" on the dashboard fix
[09:03] <ogra_> asac, evening i'D say
[09:04] <ogra_> (independently from the dashboard, the more syncs we can get in the better so we have them cross tested)
[09:04] <asac> didrocks: hmm. its not about the dashboard fx, but making a reasonable soon snapshot to make the set of changes more managable
[09:05] <didrocks> asac: well, without have dashboard results, we don't know of the real quality of the AP tests results
[09:05] <asac> i dont understand why we wouldnt build a new image now and then whenever we feel we need more as well, but *shrug*
[09:05] <asac> didrocks: we dont. so we produce the snapshots now and then get the results later
[09:05] <didrocks> so we can just say "well, it boots"
[09:05] <asac> didrocks: right. its for post-testeing
[09:05] <didrocks> asac: I mean, it will run the tests against 101
[09:05] <asac> so we have bi-sect points in history in case that stuff is broken
[09:06] <asac> didrocks: ah... well, we can surealy ensure that we test the right stuff
[09:06] <asac> after
[09:06] <didrocks> and I'm unsure we have a way to reflash/relaunch a whole set of tests again
[09:06] <asac> just produce the images now and we can test them once the dashboard is fixed
[09:06] <asac> didrocks: we have
[09:06] <didrocks> if you are sure we can, yeah, +1 for now
[09:06] <asac> yes i am sure that we even did that in the past
[09:06] <didrocks> asac: but I'm sure we are going to screw old results with new ones
[09:06] <didrocks> but let's see…
[09:06] <didrocks> asac: we relaunched some tests
[09:06] <asac> what is tricky is testing and image that is not the latest, but that is also possible
[09:06] <didrocks> in the past
[09:07] <didrocks> not changed the image :)
[09:07] <didrocks> ogra_: ok, so let's kick an image, we'll see…
[09:07] <asac> didrocks: i hope the infra has matured a bit
[09:07]  * ogra_ goes and kicks 
[09:07] <nik90> @ci, with the 13.10 freeze over, would it be possible to get the patches https://code.launchpad.net/~renatofilho/qtorganizer5-eds/fix-match-all/+merge/191080 and https://code.launchpad.net/~charlesk/indicator-datetime/lp-1233176/+merge/190009 in the phone image?
[09:07] <nik90> I need those two patches to verify the working of alarm
[09:08] <ogra_> asac, didrocks, build #2 running
[09:08] <ogra_> lets see if it even survives :P
[09:08] <didrocks> nik90: I think we'll need a landing ask (if not already) for that one
[09:09] <nik90> didrocks: I dont think I have the permission to do so..I will ask popey to add a landing task for it.
[09:09] <didrocks> nik90: and we'll start resuming landing tomorrow morning (finishing up transitionning today to trusty)
[09:09] <didrocks> thanks nik90!
[09:09] <nik90> didrocks: okay :)
[09:09] <popey> nik90: didrocks i dont have access either
[09:10]  * didrocks gives popey power
[09:10] <popey> noooooooooooooooooooooooo
[09:10] <popey> ☻
[09:10] <didrocks> popey: powered up! :)
[09:12] <ogra_> asac, what about sending a call for MIRing stuff to the MLs. i think we should have people start getting their stuff into main so we dont have to care about that at the end of the cycle
[09:13] <ogra_> (and the MIR team can process the requests over the cycle instead of getting them all at the last minute)
[09:13] <didrocks> ogra_: MIR team == mterry though
[09:13] <ogra_> yes :)
[09:14] <ogra_> thats what i mean ;)
[09:16] <didrocks> kalikiana: hey, answered on landing ask #185, can you give us more details?
[09:16] <didrocks> kalikiana: I wonder why it worked for you, there is surely a way you tested it differently from us and I want that we fix that gap :)
[09:22] <kalikiana> didrocks: not sure what more detail you're thinking of. you got a bug number and expected fixes
[09:22] <didrocks> kalikiana: I mean, you filed a first landing ask
[09:22] <didrocks> kalikiana: so I intended it was working for you
[09:22] <didrocks> how was it working? did you disable apparmor?
[09:22] <kalikiana> I didn't disable it that I can tell
[09:23] <didrocks> kalikiana: so, you were getting sensors feedback? the toolkit/apparmor regressed you?
[09:24] <didrocks> we try to identify what you differently than us to get sensors feedback working when you requested the landing ask, so that we can write better guidelines on testing
[09:27] <kalikiana> my assumption was apparmor changed, though jdstrand told me it didn't have a policy for the vibration before - the next thought would be android layer changes… but I don't know much about it
[09:28] <kalikiana> is it possible that the container stuff changed permissions?
[09:28] <didrocks> kalikiana: well, can you check with jdstrand? because we tested in the same image than you did I guess (it was the day you added the landing ask) and didn't get it working
[09:29] <didrocks> so maybe it's an application test diff, some confined, some not confined, but would be great that we identify it
[09:29] <kalikiana> didrocks: I repeat I wasn't able to test with that particular image to begin with
[09:29] <kalikiana> I had an older one when I tested before the ask
[09:30] <kalikiana> I ran into tooling problems preventing me from testing anything useful but finding unrelated bugs
[09:30] <didrocks> kalikiana: hum, so, before filing the landing ask, maybe you can check with us if this reproduce?
[09:30] <didrocks> as we were able to test, we can give advice maybe :)
[09:32] <xnox> didrocks and/or other CI people: Why indicators linked to bug #1241539 haven't been released into trusty yet? =)
[09:32] <kalikiana> well Mirv was testing also
[09:32] <kalikiana> I guess you would have prefered not to add it to the sheet before either of us confirms it with the latest image
[09:32] <didrocks> kalikiana: right, it's the deal to have a fast landing flow
[09:33] <didrocks> xnox: well, we are deploying the switch to T. See the emails by asac, we'll get first landing tomorrow
[09:33] <xnox> didrocks: on which mailing list?
[09:34] <xnox> ubuntu-devel?
[09:34] <didrocks> asac: do you remember where you did send that? ^
[09:34] <didrocks> hum, seems only ue-leads, that would explain…
[09:35] <asac> xnox: ue-leads
[09:35] <asac> didrocks: ^^
[09:35] <xnox> didrocks: i see one to ubuntu-phone just now.
[09:35] <asac> you can forward
[09:35] <asac> xnox: thats one without timeline.
[09:36] <asac> xnox: forwarded you the initial mail
[09:36]  * asac will stop using ue-leads for high level allignment as managers seem to not forward such info to their teams :)
[09:38] <Laney> It'd be better to use a public list, really
[09:38] <Laney> where possible etc
[09:38] <xnox> asac: i think ubuntu-engineering@l.c.c is a good one and/or ubuntu-phone@ even better.
[09:39] <xnox> cause everyone is subscribed to ubuntu-engineering@
[09:41] <Laney> Everyone in UE at Canonical
[09:48] <psivaa> asac: didrocks: the smoke is now running trusty image now. the results are starting appear in the dashboard
[09:48] <asac> psivaa: really? wowo!!
[09:48] <psivaa> with image 1
[09:48] <didrocks> psivaa: excellent!
[09:48] <asac> ncie one
[09:48] <asac> http://reports.qa.ubuntu.com/smokeng/trusty/touch/mako/1:20131021.1:20131015/4783/
[09:48] <asac> psivaa: will maguro also go ahead?
[09:48] <psivaa> asac: i'll look at that
[09:50] <asac> plars: doanac: so if i run top -b -d 3 i constantly get better than 97.5
[09:50] <asac> plars: doanac: so if i run top -b -d 5 i constantly get better than 98.5 even
[09:51] <asac> plars: doanac: so maybe we should revisit our parameters used
[09:51] <asac> plars: doanac: e.g. closer to the ones i initially proopsed than the very quick/fast we have now
[10:00] <didrocks> sil2100: Mirv: so, we can build all trusty now?
[10:02] <sil2100> Mirv: did you redeploy everything? (I did qa)
[10:03] <sil2100> Let's keep our fingers crossed that we didn't miss anything ;)
[10:04] <ogra_>  load average: 2.19, 1.01, 0.39
[10:04] <ogra_> hmpf
[10:04] <ogra_> i'd really like to know why our load is so high all the time
[10:05] <didrocks> sil2100: ok, autorun launched
[10:05] <sil2100> Mirv: damn, my qa merge didn't get in (but all is redeployed)
[10:05] <ogra_> (there is no obvious process in top consuming anything)
[10:12] <Mirv> didrocks: sil2100: yes, and let's see how it goes now
[10:14] <sil2100> Mirv: huh, I can't redeploy the SDK stack for saucy it seems - ERROR Can't set the target branch ~ubuntu-sdk-team/qtcreator-plugin-ubuntu/trunk-2.7 for lp:qtcreator-plugin-ubuntu/2.7
[10:15] <sil2100> Mirv: I'm not a member
[10:15] <sil2100> I guess we need to ask them to add all of us, the ubuntu-unity team as members
[10:24] <Mirv> sil2100: yeah sdk team was made more strict lately because the trunk was messed up. I'll add individuals.
[10:28] <didrocks> ogra_: hum, I click install my own package and don't see it in the installed app
[10:29] <didrocks> is there any trick? (I already tried rebooting)
[10:30] <didrocks> ah, click register surely
[10:31] <didrocks> hum, not apparearing after that, let's reboot
[10:32] <didrocks> ah, a reboot did it :)
[10:33] <asac> webbrowser app test failing? is that a known flaki one?
[10:33] <asac> http://reports.qa.ubuntu.com/smokeng/trusty/touch/mako/101:20131018:20131015/4782/ vs.
[10:33] <asac> http://reports.qa.ubuntu.com/smokeng/trusty/touch/mako/1:20131021.1:20131015/4783/
[10:34] <asac> didrocks: unity8 also as results not meeting what we expect, right?
[10:34] <asac> http://reports.qa.ubuntu.com/smokeng/trusty/touch/mako/1:20131021.1:20131015/4783/unity8-autopilot/
[10:34] <didrocks> asac: no, we didn't release any other ones
[10:34] <didrocks> asac: see my answer to doanac :)
[10:35] <didrocks> so it's known to be screwed until we release one
[10:35] <asac> didrocks: release == new unity8 fix?
[10:35] <didrocks> yep
[10:35] <asac> ok. so webbrowser?
[10:35] <didrocks> those are supposed to be good
[10:36] <cjwatson> didrocks: please don't use click install (unless you're very careful with its arguments), use pkcon install-local
[10:36] <cjwatson> didrocks: the click manual page has advice
[10:36] <didrocks> cjwatson: ah, ok will do then :)
[10:36] <asac> didrocks: yeah. http://reports.qa.ubuntu.com/smokeng/trusty/touch/mako/1:20131021.1:20131015/4783/webbrowser-app-autopilot/
[10:36] <cjwatson> didrocks: (I'd point to manpages.ubuntu.com but it doesn't have 13.10 yet ...)
[10:37] <cjwatson> But   "This is a low-level tool; to install a package as an ordinary user you should generally use pkcon install-local PACKAGE-FILE or some higher-level user interface instead, which take care to use the correct set of options.  (Do not use sudo when invoking pkcon, as it needs to know the calling user.)"
[10:37] <didrocks> cjwatson: I guess that we should have the tutorial as well pointing to us (I only used --help TBH)
[10:37] <didrocks> to pkgcon*
[10:39] <cjwatson> didrocks: the help output does point to pkcon
[10:39] <cjwatson> didrocks: http://paste.ubuntu.com/6282270/
[10:39] <didrocks> cjwatson: I just click --help
[10:40] <didrocks> and figured out the parameters then
[10:40] <cjwatson> didrocks: which points to "click install --help" for more on that specific command, which points to pkcon
[10:40] <didrocks> cjwatson: right, but I didn't think that care was needed, so I just click --help and then click install <package>
[10:41] <cjwatson> sigh
[10:41] <cjwatson> OK, I'll add a note to the top level as well
[10:41] <didrocks> cjwatson: well, maybe I'm just stupid thinking that click install <click_file> was safe and didn't need to read something else than click --help
[10:44] <cjwatson> didrocks: +  * Adjust top-level "click help" entry for "install" to point to pkcon.
[10:45] <didrocks> cjwatson: thanks ;)
[10:52] <asac> didrocks: maliit is crashing :)
[10:52] <asac> still;
[10:53] <didrocks> asac: yeah, not news, we knew it, this a crash somewhere in the stack, the keyboard guys were pinged about it
[10:53] <asac> ok so no regression... kk
[10:55] <psivaa> ogra_: i think maguro flashing is taking longer than usual with trusty image 2. looks like more than 25 mins. i'll run once more to find out the exact time
[10:55] <ogra_> ok
[10:55] <ogra_> well, it is usually between 20 and 30 for me
[10:56] <didrocks> ogra_: you are counting download time for you, right?
[10:56] <ogra_> didrocks, no plain flash times
[10:56] <asac> ogra_: can you see if the unity8 upstream merger a) run their AP and b) if it passes currently?
[10:56] <didrocks> ogra_: waow…
[10:56] <asac> err
[10:56] <asac> didrocks: ^^
[10:57] <asac> ogra_: sorry
[10:57] <didrocks> asac: upstream merger? we are not upstream for maliit
[10:57] <ogra_> http://people.canonical.com/~ogra/touch-image-stats/20131022.changes
[10:57] <asac> didrocks: talking about unity8  itself ... sorry :)
[10:57] <ogra_> diff between 1 and 2
[10:57] <ogra_> (FYI)
[10:57] <asac> didrocks: was back on the "unity8 is failing, but fix is in trunk - most likely" topic
[10:57] <asac> didrocks: i figured that if its fixed, the upstream merger should give green on those
[10:57] <asac> but now i dont know if folks have again turned the AP off :)
[10:58] <didrocks> Saviq: https://code.launchpad.net/~unity-team/unity8/trunk
[10:58] <didrocks> Saviq: I don't see your fix btw, you told me on Thursday you merged it, right?
[10:58] <Saviq> didrocks, fix for? the autopilot tests?
[10:59] <didrocks> Saviq: yep
[10:59] <Saviq> didrocks, http://bazaar.launchpad.net/~unity-team/unity8/trunk/revision/473
[10:59] <Saviq> didrocks, asac
[10:59] <didrocks> oh, it was at Christopher's name
[10:59] <Saviq> but we need unity-mir released first
[10:59] <Saviq> and then drop unity8-setcap.conf from lxc-android-config
[10:59] <Saviq> or well, not for image testing
[11:00] <didrocks> Saviq: ? yeah, we are only talking about the tests
[11:00] <asac> Saviq: what does  UNSTABLE: http://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner-mako/2564 mean?
[11:00] <asac> test failed?
[11:00] <asac> why do you merge anyway? :)
[11:00] <didrocks> Saviq: https://jenkins.qa.ubuntu.com/job/generic-mediumtests-touch/3025/console
[11:01] <didrocks> unmet dependency on the one I picked
[11:01] <Saviq> didrocks, look up
[11:01] <asac> i cant really parse this ... https://code.launchpad.net/~veebers/unity8/ap_env_fix_1240801/+merge/191567/comments/440420
[11:01] <Saviq> asac, we're not
[11:01] <didrocks> let's look at a MP older then
[11:01] <asac> so we have some SUCCESS: ... on armhf ->  SUCCESS: http://jenkins.qa.ubuntu.com/job/generic-mediumtests-builder-saucy-armhf/3023
[11:01] <Saviq> didrocks, we never got mediumtests-touch to a working state with mir yet
[11:01] <asac> ah thats building
[11:02] <didrocks> asac: saucy is desktop AFAIK
[11:02] <didrocks> Saviq: it was on the image, apart from 1 failure, right?
[11:02] <Saviq> didrocks, yes
[11:02] <asac> Saviq: well, the idea is that after your merge
[11:02] <asac> it works
[11:02] <Saviq> didrocks, the failure was a random crash, too
[11:02] <asac> so you shouldnt merge it if it doesnt :)
[11:02] <didrocks> 8 is more though
[11:02] <Saviq> asac, really, please stop
[11:02] <asac> ah
[11:02] <asac> ok
[11:02] <Saviq> asac, I'm telling you what's the prerequisite for unity8 even *starting*
[11:03] <Saviq> and that is unity-mir release
[11:03] <didrocks> Saviq: juts to understand on that one: https://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner-mako/2575/?
[11:03] <didrocks> it's your fix
[11:03] <Saviq> didrocks, asac please stop
[11:03] <didrocks> I guess it was ran without this unity-mir dep
[11:03] <Saviq> and listen
[11:03] <asac> yeah lets listen
[11:03] <asac> sorry Saviq. go ahead
[11:03] <Saviq> we need to release unity-mir, so that we can drop unity8-setcap.conf from lxc-android-config
[11:03] <Mirv> sil2100: unity-ubuntu now part of the sdk team (the 11 team members were ones that I would have added individually as well)
[11:03] <Saviq> that will let us install unity8 in mediumtests-touch
[11:04] <Saviq> and only then we can start looking into actually fixing those runs
[11:04] <Mirv> I trust ~ubuntu-unity members not to push --overwrite to ui-toolkit repo :)
[11:04] <asac> ok sounds good
[11:04] <asac> Saviq: do we have all pieces ... in theory?
[11:04] <Saviq> and looking into them if they didn't pass
[11:04] <didrocks> Saviq: I still don't undestand why having just the code executed in https://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner-mako/2575/? (so your fix), I was able to have all tests (but 1) passing on the image
[11:04] <Saviq> asac, yes, unity-mir just needs a release
[11:04] <asac> and lxc-android-config?
[11:04] <didrocks> without any unity-mir/dropping unity8-setcap.conf
[11:05] <Saviq> didrocks, those failures were intermittent - now fixed in trunk
[11:05] <didrocks> Saviq: the 8 of them?
[11:05] <Saviq> didrocks, yes
[11:05] <didrocks> we just got really unlucky?
[11:05] <didrocks> ok
[11:06] <Saviq> didrocks, intermittent as in we fixed them
[11:06] <didrocks> ok
[11:06] <asac> didrocks: guess we should make an ask for this and do this as one of our first things. seems a few components are involved that require coordination :)
[11:06] <didrocks> asac: indeed, I would be interesting if such ask was made to make it a priority
[11:06] <asac> lxc-android, unity8, unity-mir
[11:06] <didrocks> knowing that will dep on a mir ABI bump which is already in the ppa
[11:06] <asac> well, we didnt tell folks if they shyould continue doing asks
[11:06] <didrocks> so we'll need mir as well
[11:06] <asac> now the mail is out
[11:06] <asac> so... :)
[11:06] <didrocks> as it's built against it
[11:07] <didrocks> and so platform-api for this mir abi bump
[11:07] <didrocks> as well as u-s-c
[11:07] <asac> didrocks: lets create this one for saviq
[11:07] <didrocks> asac: ?
[11:07] <didrocks> I disagree
[11:07] <asac> well, your call :)
[11:07] <didrocks> otherwise, there is no value, we just add more paperwork to our own soul
[11:07] <didrocks> for the sake of it
[11:08] <didrocks> and we aren't sure to have all pieces listed
[11:08] <didrocks> nor the impact
[11:08] <asac> Saviq: can you add an ask about fixing unity8 APs and give details about all the bits and pieces so we can coordinate getting all in?
[11:09] <asac> thanks
[11:18] <psivaa> didrocks: ogra_ i am seeing some issues with flashing with trusty image 2.
[11:19] <psivaa> i get 'ERROR:phablet-flash:Installation is taking too long or an error occured along the way.'
[11:20] <psivaa> the installation on my local maguro is hung on boot screen - Google and Padlock
[11:21] <ogra_> psivaa, doing an OTA upgrade here atm ... lets see how that behaves
[11:21] <didrocks> psivaa: interesting (and worrying)
[11:21] <didrocks> ogra_: there was no hybris change right?
[11:21] <ogra_> http://people.canonical.com/~ogra/touch-image-stats/20131022.changes
[11:21] <didrocks> so can't be an android/ubuntu mismatch?
[11:21] <Saviq> are we planning to stop this landind-asks business at some point please?
[11:21] <ogra_> i dont see one
[11:22] <didrocks> Saviq: see asac's email
[11:22] <sil2100> Mirv: thanks!
[11:22] <ogra_> didrocks, lightdm and libpam are new ...
[11:22] <ogra_> as well as lxc
[11:23] <Saviq> didrocks, yeah, didn't find an answer to that question (other than "we'll discuss in OAK")
[11:23] <ogra_> they look like the most possible candidates for the session not starting
[11:23] <didrocks> Saviq: if there was a decision before the discussion, that wouldn't be a discussion
[11:23] <asac> well said
[11:23] <cjwatson> effective diff to pam is pretty small
[11:24] <ogra_> cjwatson, yeah, let me test first to see whats up here
[11:24] <cjwatson> lightdm or lxc seem more probable
[11:24] <cjwatson> (neither was an autosync)
[11:24] <ogra_> both just are obviously involved in session startup
[11:25] <didrocks> knowing that lxc dropped a fix we still needed yesterday for otto
[11:25] <didrocks> not sure if this one was useful for touch
[11:25]  * ogra_ twiddles thumbs watching the android with rotating guts 
[11:25] <didrocks>     - 0006-add-pstore-to-container-fstab.patch
[11:25] <ogra_> we really should switch these animations to something ubuntuish :)
[11:25] <didrocks> ogra_: we needed still that one for otto yesterday ^
[11:26] <didrocks> not sure if it's relevant to you :)
[11:26] <ogra_> didrocks, i thought that was upstreamed
[11:26] <didrocks> ogra_: oh possible (we ship our own fstab for otto, that's why we noticed)
[11:26]  * didrocks looks at the diff
[11:26] <didrocks> yep, in -Index: lxc-1.0.0~alpha1/templates/lxc-ubuntu.in
[11:27] <ogra_> ok,, seems the container is up fine
[11:27] <ogra_> psivaa, confirmed btw
[11:27] <didrocks> ok, so not lxc :)
[11:27] <ogra_> right
[11:27]  * ogra_ tries a manual start lightdm 
[11:27] <psivaa> ogra_: thx
[11:27] <cjwatson> I'd stop autosyncs but they aren't going to run for 4.5 hours anyway.  Let me know if it's needed
[11:28] <ogra_> [+0.34s] DEBUG: Seat: Session authenticated, running command
[11:28] <ogra_> [+0.34s] DEBUG: Registering session with bus path /org/freedesktop/DisplayManager/Session0
[11:28] <ogra_> [+0.35s] DEBUG: Session pid=884: Running command /usr/sbin/lightdm-session ubuntu-touch-session
[11:28] <ogra_> [+0.36s] DEBUG: Session pid=884: Logging to .xsession-errors
[11:29] <ogra_> the lightdm log looks fine as well
[11:29] <ogra_> root@ubuntu-phablet:/# ps ax|grep 884
[11:29] <ogra_>   884 ?        Sl     0:00 lightdm --session-child 10 13
[11:29] <ogra_> and lightdm runs
[11:30]  * ogra_ digs into session logs
[11:30] <Saviq> asac, didrocks, ask added
[11:30] <ogra_> phablet@ubuntu-phablet:~$ start unity8
[11:30] <ogra_> start: Job läuft bereits: unity8
[11:30] <asac> thanks!
[11:30] <ogra_> oh wow
[11:30] <didrocks> thanks Saviq
[11:30] <ogra_> phablet@ubuntu-phablet:~$ ps ax|grep unity
[11:30] <ogra_>  1565 pts/3    S+     0:00 grep --color=auto unity
[11:30] <xnox> ogra_: FYI, your job is running away to unity 8 =)
[11:30] <ogra_> lies !
[11:31]  * xnox somehow finds technical translations to other languages amusing =)
[11:31] <xnox> ogra_: status unity8?
[11:31] <ogra_> terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<std::runtime_error> >'
[11:31] <ogra_>   what():  Could not open hardware module
[11:31] <ogra_> all xnox' fault !!!
[11:32] <xnox> ogra_: right, let me check if unity/mir was rebuild with new boost. I thought I did.
[11:32] <ogra_> xnox, well probably you did but it wasnt let out of CI
[11:32] <ogra_> didrocks, ^^^
[11:33] <didrocks> ogra_: I guess xnox is talking about directly uploads
[11:33] <xnox> didrocks: ogra_: well mir was rebuilt, but not unity-system-compositor.
[11:33] <didrocks> u-s-c isn't used on touch
[11:33] <ogra_> didrocks, no idea i thought mir and unity were not direct
[11:34] <xnox> ah, then no idea.
[11:34] <ogra_> xnox, there is unity-mir though
[11:34] <ogra_> which might need a respin too (not sure ask an expert)
[11:35] <xnox> could be...
[11:35] <didrocks> if a boost objects is leaked through mir, can be, xnox -> #ubuntu-mir?
[11:35] <ogra_> ricmm, already up ? ^^^
[11:36] <xnox> didrocks: templates do leak ABI/API mismatches, via transitive dependencies.
[11:36] <xnox> didrocks: but that's "standard C++" feature.
[11:36] <didrocks> xnox: yeah, it's more than possible that they use templates for their public class
[11:36] <xnox> didrocks: I don't know the code, and only was rebuilding stuff which does link against boost libs.
[11:37] <didrocks> (I asked there)
[11:37] <didrocks> meanwhile, ogra_, can you try a rebuild of unity-mir on your phone?
[11:37] <didrocks> should be quick enough to build
[11:37] <ogra_> hmm
[11:38] <ogra_> have to do that on maguro ... that wont be fast
[11:38] <ogra_> but yeah, i can try
[11:38] <cjwatson> xnox: I think you forgot to quote "feature" there too
[11:39]  * didrocks smells some C++ love from cjwatson :)
[11:39] <cjwatson> You might say I'm not a fan
[11:40] <didrocks> heh :)
[11:50] <cjwatson> didrocks: (http://gerald-duck.livejournal.com/591852.html is a good example - slides from *Bjarne Stroustrup* containing errors)
[11:50] <cjwatson> top tip, if your language is so hard that its creator can't get it right in presentations, choose a new language
[11:50] <didrocks> cjwatson: from Stroustrup? interesting :)
[11:50] <didrocks> cjwatson: will read it for sure :)
[11:51] <cjwatson> well, that's an article commenting on said slides, but yes
[11:52] <didrocks> cjwatson: last time I really wrote a lot of C++ code was 7 years ago (I don't count the unity code I wrote as serious development), and yeah, I have feelings as well :)
[11:57] <asac> psivaa: did we retry webbrowser?
[11:58] <psivaa> asac:  not yet, looking at that to see if the failures were the same as before
[11:58] <asac> right
[11:58] <asac> thanks
[12:01] <psivaa> asac: rerunning it again. i got it confused with weather app tests
[12:34] <asac> slangasek: cjwatson: seems we have a first case of our imports/core-dev uploads caused touch to not boot anymore
[12:34] <asac> slangasek: cjwatson: we thought it was just a rebuild related to boost regression, but seems that didnt make it
[12:34] <cjwatson> asac: I haven't seen an analysis of what actually broke yet
[12:34] <cjwatson> Just a guess, which you're now saying didn't turn out to be the problem after all?
[12:35] <asac> cjwatson: what do you need to know? the symptoms?
[12:35] <cjwatson> asac: I'm just saying that we don't know the cause yet
[12:35] <cjwatson> AFAIK
[12:35] <didrocks> Mirv: sil2100: is it getting better? I see a lot of red in http://10.97.0.1:8080/view/cu2d/view/Head/
[12:36] <cjwatson> ogra_: Any progress tracking this down?
[12:36] <asac> cjwatson: right. so a) who is looking and b) what is the course of action until we know
[12:36] <asac> (that you suggest)
[12:36] <cjwatson> asac: ogra_ was looking last I heard, and 12:27 <cjwatson> I'd stop autosyncs but they aren't going to run for 4.5 hours anyway.  Let me know if it's needed
[12:36] <ogra_> cjwatson, not really, didrocks did a test rebuild of the packages but that doesnt seem to help
[12:36] <asac> cjwatson: thanks!
[12:37] <ogra_> he claims in #ubuntu-mir that he doesnt get a seat
[12:37] <didrocks> I don't have lightdm starting automatically
[12:37] <didrocks> (need to start it manually)
[12:37] <ogra_> (works for me though)
[12:37] <ogra_> let me reboot and see
[12:37] <didrocks> ogra_: yeah, would like a confirmation
[12:37] <cjwatson> If it's lightdm, foundations takes no responsibility :)
[12:38] <ogra_> root@ubuntu-phablet:/# status lightdm
[12:38] <ogra_> lightdm stop/waiting
[12:38] <ogra_> not starting ...
[12:38] <cjwatson> Though the effective diff in lightdm is virtually zero
[12:39] <ogra_> http://paste.ubuntu.com/6282720/
[12:39] <ogra_> ERR !
[12:39] <ogra_> where is the rest of this file
[12:40] <cjwatson> What package is that file in?
[12:40] <ogra_> ubuntu-touch-session
[12:40] <ogra_> ugh
[12:40] <cjwatson> That's the full file in the source package
[12:40] <ogra_> its like that in bzr too
[12:40] <cjwatson> I'd expect it to be getting its script or exec from lightdm.conf
[12:40] <cjwatson> Seeing as that's just the override
[12:41] <cjwatson> I wouldn't expect you'd *need* the "rest of this file"
[12:41] <ogra_> right seems that worked before so likely a red herring
[12:41] <ogra_> i thought override overrides and doesnt merge :)
[12:41] <cjwatson> No
[12:41] <ogra_> k
[12:41] <cjwatson> "Files ending in .override are called override files.  If an override file is present, the stanzas it contains take precedence over those equivalently named stanzas in the corresponding configuration file contents for a particular job.  The main use for override files is to modify how a job will run without having to modify its configuration file directly.  See the section Override File Handling below for further details."
[12:41] <cjwatson> init(5)
[12:41] <Mirv> didrocks: I didn't realize it had tried to run already. it's complaining about missing trusty cow image http://10.97.0.1:8080/view/cu2d/view/Head/view/Apps/job/cu2d-apps-head-1.1prepare-notes-app/338/console
[12:42] <ogra_> root@ubuntu-phablet:/# status lxc-android-config
[12:42] <ogra_> lxc-android-config start/post-start, process 599
[12:42] <ogra_> 	post-start process 601
[12:42] <ogra_> aha
[12:42] <ogra_> looks like thats the issue
[12:42] <ogra_> root@ubuntu-phablet:/# ps ax|grep 601
[12:42] <ogra_>   601 ?        Ss     0:00 /bin/sh -e /proc/self/fd/9
[12:42] <ogra_> hmm
[12:42] <didrocks> Mirv: https://wiki.ubuntu.com/DailyRelease/MovingNewRelease First setup on the jenkins server
[12:42] <didrocks> we need to create a release+1 pbuilder. Ping jibel for it.
[12:42] <didrocks> (we need root access to create it, we don't have it
[12:43] <Mirv> right, there it reads.
[12:43] <Mirv> jibel: could you create trusty pbuilder?
[12:43] <cjwatson> ogra_: could you pastebin the whole "ps auxfww"?
[12:43] <vila> Mirv, jibel: I thought fginther was working on that yesterday ?
[12:44] <ogra_> http://paste.ubuntu.com/6282741/
[12:44] <jibel> Mirv, sure I can but I thought fginther did it
[12:44] <cjwatson> ogra_: So /proc/$containerpid/root/dev/.coldboot_done never gets created, I guess
[12:44] <cjwatson> Since it seems to be in that sleep loop
[12:45] <ogra_> we didnt rebuild android, i wouldnt know why
[12:46] <cjwatson> So where is that file expected to be created
[12:46] <ogra_> root@ubuntu-phablet:/# lxc-info -n android|grep pid
[12:46] <ogra_> pid: 	658
[12:46] <ogra_> root@ubuntu-phablet:/# ls /proc/658/root/dev/.coldboot_done
[12:46] <ogra_> /proc/658/root/dev/.coldboot_done
[12:46] <cjwatson> In android, yes?  http://162.213.35.4/search?weighted=1&q=coldboot_done shows android_20131006-1510-0ubuntu6/system/core/init/devices.c:905 which I guess is related
[12:47] <ogra_> so the file is there
[12:47] <ogra_> and it worked before the #2 build
[12:48] <cjwatson> http://launchpadlibrarian.net/154411166/lxc_1.0.0~alpha1-0ubuntu11_1.0.0~alpha2-0ubuntu1.diff.gz:
[12:48] <cjwatson> -			printf("pid:%10d\n", initpid);
[12:48] <cjwatson> +			printf("pid: \t%d\n", initpid);
[12:48] <ogra_> oh my
[12:48] <cjwatson> while lxc-android-config has:
[12:48] <cjwatson>     containerpid="$(lxc-info -n android|grep pid|sed 's/^pid:.* //')"
[12:48] <ogra_> yeah, i see it
[12:48] <cjwatson> so that needs to be [[:space:]] instead of the ' '
[12:49] <cjwatson> lxc triggered it but this is an lxc-android-config bug IMO :)
[12:49] <ogra_> yay for building on assumptions
[12:49] <ogra_> yes, it is
[12:49] <jibel> didrocks, vila do you want me to proceed with the creation of the chroot or wait for fginther?
[12:49] <cjwatson> ogra_: Beware similar bug in ./usr/bin/android-chroot
[12:49] <cjwatson> ./usr/bin/android-chroot:3:pid=$(lxc-info -n android|grep ^pid|sed 's/^pid: .* //')
[12:49] <ogra_> cjwatson, yeah, android-chroot is due to be removed
[12:50] <cjwatson> ogra_: yeah, but if it isn't actually gone yet it should still be fixed
[12:50] <ogra_> it doesnt do what the name suggests and people confuse it
[12:50] <ogra_> i'll remove it with the same upload
[12:50] <vila> jibel, didrocks: I'd rather check with him to avoid double work and so on, he should be here any time now
[12:50] <fginther> morning
[12:50] <vila> tada !
[12:51] <vila> fginther: hey, perfect timing
[12:51] <ogra_> hey, unity !
[12:52] <fginther> vila, chroots?
[12:52] <ogra_> and it feels a lot snappier (for 2min using it at least)
[12:52] <vila> fginther: ?
[12:52] <vila> fginther: pbuilder ?
[12:52]  * cjwatson codesearches to see if there are any similar bugs elsewhere (which would argue for an lxc reversion if so; otherwise I think we should just fix lxc-android-config to tolerate the whitespace change and be done with it)
[12:52] <fginther> vila, trying to figure out what the perfect timing is for, are we discussing the daily release chroots?
[12:53] <cjwatson> lxc itself does this kind of thing:
[12:53] <cjwatson>         initpid=`lxc-info -P $lxc_path -p -n $container | awk -F: '{ print $2 }' | awk '{ print $1 }'`
[12:53] <vila> fginther: yeah, Mirv didrocks and jibel were wondering if the trusty pbuilder have been created, I said I thought you were doing just that yesterday
[12:53] <vila> pbuilderS even
[12:54] <fginther> vila, Mirv, didrocks, the pbuilders are setup for the upstream merger
[12:54] <didrocks> fginther: no, cu2d uses it as well
[12:54] <didrocks> with cow
[12:54] <vila> same hosts ?
[12:54] <fginther> vila, didrocks, I have not touched the daily release systems yet
[12:55] <vila> fginther: will you ?
[12:56] <Mirv> fginther: ok. me and sil2100 have been updating the cu2d configurations today and now it seems that on the head side the next step missing is the pbuilder (http://10.97.0.1:8080/view/cu2d/view/Head/view/Apps/job/cu2d-apps-head-1.1prepare-notes-app/338/console)
[12:56] <fginther> Mirv, vila ack, I'll start work on that
[12:56] <ogra_> asac, didrocks, xnox, fix uploaded, session should start again with the new lxc-android-config
[12:56] <cjwatson> ogra_: All other callers of lxc-info in the archive use forms that will tolerate this whitespace change
[12:56] <Mirv> thanks fginther
[12:57] <ogra_> cjwatson, lxc-android-config now too :)
[12:57] <cjwatson> ogra_: Thanks
[12:57] <xnox> ogra_: didrocks: so it wasn't related to boost?
[12:57] <ogra_> xnox, not at all
[12:57] <xnox> asac: ^
[12:57] <ogra_> xnox, lxc change that triggered a mis-parsing in lxc-android-config
[12:58] <didrocks> ogra_: hum, it fixes the boot exception as well?
[12:58] <jibel> fginther, the chroot is building, I also updated debootstrap on magners-o so it knows about trusty
[12:58] <fginther> jibel, thanks
[12:58] <ogra_> didrocks, unity starts after i changed the upstart job
[12:58] <didrocks> oh, interesting
[12:58] <ogra_> didrocks, feel free to try yourself
[12:59] <ogra_> -    containerpid="$(lxc-info -n android|grep pid|sed 's/^pid:.* //')"
[12:59] <ogra_> +    containerpid="$(lxc-info -n android|grep pid|sed 's/^pid:.*[[:space:]]//')"
[12:59] <ogra_> in /etc/init/lxc-android-config.conf
[12:59] <didrocks> asac: so not boost transition, new lxc need another change in lxc-android-config ^
[12:59] <didrocks> ogra_: doing
[12:59]  * didrocks stops his unity8 build
[12:59] <ogra_> not another change
[13:00] <ogra_> that code was there forever
[13:00] <vila> fginther: thanks
[13:00] <didrocks>   * make parsing the lxc-info output work with new lxc so our session can
[13:00] <didrocks>     start again
[13:00] <ogra_> yeah
[13:00] <ogra_> lxc changed the output format of lxc-info
[13:01] <didrocks> yeah, so lxc changed :)
[13:01] <ogra_> the parsing above couldnt keep up with thatz
[13:01] <didrocks> (that's what I meant)
[13:01] <asac> didrocks: nice. i like blame-games :)
[13:01] <didrocks> not parsing " " but needing [[:space:]]
[13:01] <ogra_> yeah
[13:01] <didrocks> asac: do we see score going up and down?
[13:01] <ogra_> well, it should be safe now
[13:01] <ogra_> i'll trigger a new image as soon as thats in
[13:01] <didrocks> ogra_: I still wonder why that impact unity8 that way though (the boost exception we saw)
[13:01]  * didrocks reboot
[13:02] <ogra_> and will meanwhile debug video playback in webapps on maguro
[13:02] <ogra_> didrocks, it will at least fill your disk with log spam
[13:02] <Mirv> fginther: and after that the next missing step would be https://code.launchpad.net/~timo-jyrinki/cupstream2distro-config/switch_from_next_to_daily/+merge/192139
[13:02] <ogra_> so it should be fixed asap
[13:02] <ogra_> but i doubt it will do actusal harm
[13:02] <ogra_> on my maguro the #2 image feels actually snappier
[13:02] <ogra_> might be subjective though
[13:03] <didrocks> heh :)
[13:03] <didrocks> ogra_: confirming unity8 starts
[13:03] <didrocks> nice debugging :)
[13:03] <ogra_> :)
[13:04] <didrocks> however, weird side boost effect in unity8 :-)
[13:04]  * cjwatson scores up lxc-android-config
[13:04] <didrocks> xnox: that was close!
[13:06] <fginther> Mirv, looks good to me (did not top approve)
[13:07] <didrocks> jibel: thanks
[13:11] <jibel> fginther, Mirv trusty chroot is ready on m-o
[13:16] <Mirv> jibel: thanks, looks good now from that perspective
[13:16] <dobey> Mirv, pmcgowan: i have a contribution to qt i'm trying to get pushed to gerrit and am having some problems with git. either of you have a minute to help figure it out? the commit-msg (and maybe others) hook doesn't seem to be running for me when i do commit -a
[13:16] <fginther> sil2100, in the services.cfg stack, thumbnailer was enabled for daily_release under saucy, but the head version is not
[13:17] <Mirv> dobey: have you copied the hooks to the local checked out .git/hooks?
[13:24] <dobey> Mirv: yes, that's the only place they exist
[13:25] <kgunn> didrocks: ping
[13:26] <Mirv> dobey: that to make it obvious, the instructions talk about  ~/.git but actually they need to be under the checked out repository's .git/hooks. I haven't heard of problems in using the hooks, other than they missing from the correct directory (hmm, not sure if chmod +x is needed)
[13:26] <Mirv> so one line there is the cp -av ~/.git/hooks/* .git/hooks/
[13:26] <dobey> Mirv: yes, they are only in the checked out repository, i don't have a ~/.git/ directory at all
[13:27] <dobey> and i did chmod +x them
[13:28] <Mirv> dobey: I can't think of any reason they wouldn't get executed. so you don't get the Change-Id in the comment then? and it's called "post-commit" (and not the wget:d "git_post_commit_hook")?
[13:28] <Mirv> dobey: in other words I can't think of anything that is not already written on the instruction page
[13:28] <dobey> i had it work once, but that was with the wrong committer/author e-mail, so i had to blow away the branch because i couldn't find any way to change the existing commit and trying to use revert made the branch worse. so i had to salvage my changes in a patch file, and make a new tree to do it in. but now it's not working
[13:29] <Mirv> dobey: yep, that must be annoying.
[13:29] <dobey> Mirv: yes, i followed the instructions correctly. when i do "commit -a" the huge commentary about [ChangeLog][][] and such is not coming up
[13:29] <Mirv> :(
[13:29] <dobey> Mirv: yes, every time i've ever used git, has been nothing short of wildly frustrating for me ;(
[13:31] <didrocks> kgunn: pong
[13:32] <kgunn> didrocks: hey...i'm premature...sorry....i need to get one more mp approved by ricmm for platform-api mir abi bump
[13:32] <kgunn> i'll bother you later
[13:32] <didrocks> ok
[13:32] <kgunn> didrocks: question is....can i actually merge those mp's ? prior to mir getting pulled into the daily build ?
[13:32] <kgunn> i worry about the order
[13:33] <asac> didrocks: do we feel we have the issue fixed? :)
[13:33] <asac> with the new lxc upload?
[13:33] <ogra_> asac, yes
[13:33] <didrocks> asac: lxc-android-config to fix for new lxc, yeah
[13:33] <didrocks> asac: tested locally as well, confirmed by 2 people
[13:33] <ogra_> waiting for it to come out of proposed
[13:33] <asac> ok. then lets tackle the unity test fixes next :)
[13:33] <asac> once we have that we are back to release state i feel
[13:33] <ogra_> asac, then i'll do a new build
[13:34] <didrocks> kgunn: well, mir trunk already have an abi break, so don't worry about it for now, just merge it
[13:34] <didrocks> kgunn: please add a landing ask as well for the transition
[13:34] <didrocks> FYI, we'll start landing again things tomorrow
[13:34] <didrocks> sil2100: is everything working better now?
[13:34] <asac> kgunn: can we please have a session or just do the source merge of the componnents that share libmirserver?
[13:34] <asac> (and exporting a stable libmirserver for platform-api)
[13:34] <asac> (just got reminded by hearing abi break)
[13:36] <kgunn> didrocks: ack on landing ask
[13:36] <didrocks> thanks ;)
[13:38] <kgunn> asac: me more than anyone wants it to settle, unfortunately its not so easy....its the story of begets....we (unity&mir) would like to leverage qt scengraph & refactor mir-data-model....which means some more breaking, and its going to take some time, then we'll be in position to distill api
[13:39] <sil2100> fginther: ah, so it seems the head-saucy pieces were out of sync
[13:39] <Mirv> didrocks: I've been looking after the head now, and yes it's looking better and builds are starting to appear https://launchpad.net/~ubuntu-unity/+archive/daily-build/+packages?field.series_filter=trusty
[13:39] <sil2100> didrocks: yes, Mirv prepared a branch that we missed and redeployed
[13:39] <sil2100> It will be merged in soon
[13:39] <didrocks> sil2100: Mirv: sweet! all prepare jobs cleaned as well?
[13:40] <jdstrand> didrocks, kalikiana: regarding sensors> kalikiana told me I needed to add a rw access for apparmor. I did not upload that until just now (apparmor-easyprof-ubuntu 1.0.41) so it isn't surprising if testing didn't work
[13:40] <didrocks> jdstrand: well, apparently testing did work when he did the landing ask, (and we saw it wasn't), hence the question
[13:40] <jdstrand> I was waiting on feedback from this channel yesterday, but then saw the email this morning so I uploaded it
[13:40] <didrocks> we want to ensure we write good guidelines for everyone to test their changes and try to identify gaps :)
[13:40] <jdstrand> didrocks: I gave instructions on how to add the access
[13:41] <didrocks> oh, so he did that manually and tested at the time
[13:41] <Mirv> didrocks: sil2100: certainly not for the prepare job cleanage, there has been enough work to get this first run done. now finally we'll get up-to-date statuses at the head jobs.
[13:41] <jdstrand> didrocks: so he probably had that but the testing didn't
[13:41] <didrocks> ok, that makes sense :)
[13:41] <didrocks> so yeah, we really need to have a big landing ask "group", with everything that was needed to make it work
[13:41] <jdstrand> didrocks: I'm guessing that was the case, yes. no matter, now 1.0.41 is uploaded, people can just do that. if it doesn't work, check /var/log/syslog for denials
[13:42] <didrocks> jdstrand: yeah, it's just that we need to write good guidelines for landing those kinds of interdependants change :)
[13:42] <didrocks> thanks for the hint jdstrand :)
[13:42] <jdstrand> mp
[13:42] <jdstrand> np
[13:59] <ogra_> asac, didrocks, lxc-android-config is in, triggering a #3 now
[13:59] <didrocks> ogra_: \o/
[13:59] <ogra_> build running
[13:59] <asac> great
[14:09] <plars> asac, ogra_: so what's the story on the channels? My understanding is that devel-proposed doesn't point at trusty for some reason yet?
[14:11] <ogra_> plars, not for some reason no :)
[14:11] <ogra_> plars, channels can only exist once they have content
[14:11] <plars> ogra_: but there is a trusty image now, yes?
[14:11] <ogra_> plars, until we publish trusty-proposed to trusty we cant switch devel
[14:12] <plars> ogra_: but shouldn't devel-proposed point to the same thing as trusty-proposed?
[14:12] <ogra_> (we could switch devel-proposed but that would cause confusion)
[14:12] <cjwatson> ogra_: next cycle we should just copy saucy to trusty to start with
[14:12] <ogra_> cjwatson, tzhats what i said in the meeting ;)
[14:12] <cjwatson> no real reason not to do that, except that you have to continue the build numbers (you may or may not consider that a downside)
[14:12] <ogra_> right
[14:12] <plars> ogra_: It appears to be causing confusion the way it is now, it was my understanding that continuing to use devel-proposed for trusty images was the right thing to do
[14:13] <ogra_> plars, once we have devel and devel-proposed populated with images, yes
[14:15] <asac> cjwatson: i want the build numbers of devel to always go up :)
[14:15] <asac> yes.
[14:15] <asac> thanks!
[14:15] <asac> :)
[14:16] <asac> maybe should be seeded in our "how to do releases" wiki - so we wont forget next time
[14:18] <cjwatson> feel free to add touch-specific things to NewReleaseCycleProcess as appropriate
[14:19] <ogra_> asac, build numbers are moot ... as long as the OTS upgrader does the right thing
[14:19] <ogra_> *OTA
[14:20] <plars> ogra_: so are you saying there will be nothing for devel-proposed until an image is green enough to be marked "good"?
[14:20] <ogra_> plars, yes
[14:20] <ogra_> plars, unless asac wants to override that for #1
[14:20] <plars> ogra_: that is a change from last cycle then right? We didn't track saucy proposed last cycle, but devel-proposed
[14:21] <ogra_> i personally dont think #1 is worse than #101
[14:21] <ogra_> plars, we didnt have system-image when last cycle began
[14:21] <ogra_> oh, you mean *during*
[14:22] <plars> but if trusty-proposed is going to really be the tip, and devel-proposed is just the images that have been accepted from trusty-proposed as good, then we should always just be testing trusty-proposed this cycle it seems
[14:22] <plars> asac: ?^
[14:22] <ogra_> well, sinc ethey wree equivalent back then ...
[14:22] <ogra_> *were
[14:22] <ogra_> plars, trusty = devel ... as soon as we switched
[14:22] <ogra_> (and equivalently -proposed)
[14:22] <ogra_> plars, saucy = stable
[14:23] <plars> ogra_: but today, saucy=devel still
[14:23] <ogra_> yes
[14:23] <ogra_> until we can create a new devel channel
[14:23] <ogra_> which we cant without an image in there
[14:24] <ogra_> its a catch22
[14:24] <cjohnston> I thought devel-proposed was a symlink to trusty-proposed
[14:24] <ogra_> devel = saucy ... until trusty has its first image
[14:24] <ogra_> then your assumption is true
[14:25] <plars> ogra_: ok
[14:25] <ogra_> cjohnston, plars, though since asac wants to keep saucy testing around too, we should always use the release name for utah i think
[14:26] <ogra_> that should make it easier to distinguish
[14:26] <plars> ogra_: ok, we'll just change to trusty-proposed in ci then, and leave it at that
[14:26] <ogra_> right
[14:26] <ogra_> that way you can still test saucy-proposed in parallel
[14:27] <ogra_> and once Uneasy Unicorn starts we can have that in paralell asd well ;)
[14:39] <asac> plars: yes ignore devel* for the time being
[14:39] <asac> also ignore stable* in the same way :)
[14:45] <ogra_> image #3 done btw
[14:56] <didrocks> let's cross fingers for the dashboard!
[15:11] <slangasek> ogra_: why does lxc-android-config have this coldboot check at all?  Why should it not be sufficient that 'lxc-wait' says the container is running, and the local bridge handling any other android events that are needed?
[15:12] <ogra_> slangasek, ueventd
[15:12] <ogra_> slangasek, it creates that file once it is done processing
[15:13] <slangasek> right - but doesn't ueventd also set an android property?
[15:14] <slangasek> which would be a better IPC mechanism than rooting around in /proc/$pid/root
[15:21] <ogra_> slangasek, not sure, it is definitaley a candidate for revisiting this cycle
[15:21] <ogra_> it should hook into the upstart-local-bridge i think
[15:22] <ogra_> thats why we have it after all :)
[15:25] <ogra_> ARGH !
[15:25] <ogra_> didrocks, asac  ... lxc-android-config update isnt in #3
[15:25]  * ogra_ definitely checked with rmadison before starting the build 
[15:25] <ogra_> damned
[15:26] <ogra_> err
[15:26] <ogra_> hmpf
[15:26] <ogra_> why did phablet-flash #2 for me again
[15:26] <ogra_> didrocks, asac ignore the ablve
[15:27]  * ogra_ doesnt get why he doesnt get #3 ... it was definitely there since a while when i fired off phablet-flash
[15:29] <asac> ogra_: check with stgraber i guess
[15:29] <ogra_> asac, well, i'm starting over now
[15:29] <ogra_> just to be sure the error isnt on my side
[15:29] <ogra_> probably the telekom has a new proxy i dont know about or some weird stuff
[15:32] <slangasek> rsalveti: do you know if there's an android property that's an equivalent to /dev/.coldboot_done ?
[15:49] <ogra_> ok, this time i got #3
[15:55] <didrocks> ogra_: ok, it looks fine here
[15:56] <ogra_> still flashing here
[15:56] <ogra_> and probably taking half the meeting
[15:56] <ogra_> maguro is slooooow to unpack the tarball
[15:58] <asac> :)
[15:58] <Mirv> back for the call
[16:00] <didrocks> sil2100: Mirv: asac: ogra_: plars: joining? (let's try to keep it short and focused ;))
[16:00] <sil2100> \o/
[16:01] <plars> didrocks: will be there in a sec
[16:03] <sil2100> Mirv: https://code.launchpad.net/~sil2100/cupstream2distro-config/transition_webapps_T/+merge/192184 <- can you quickly? :)
[16:05] <asac> doanac: any idea why touch_custom is showing up ont he QA homepage? http://reports.qa.ubuntu.com/
[16:05] <asac> e.g. why not touch?
[16:06] <didrocks> hum, no robru…
[16:08] <doanac> asac: not sure. josepht, cjohnston: any idea why our trusty touch results aren't showing up in the KPI?
[16:09] <doanac> we have a regex gone bad because of the variant changes?
[16:09] <didrocks> cyphermox: around?
[16:11] <cyphermox> yes
[16:11] <doanac> plars: i think when we ran setup_jenkins we failed to enable the "publish" option
[16:11] <didrocks> cyphermox: coming to https://plus.google.com/hangouts/_/calendar/Y2Fub25pY2FsLmNvbV91cTRvNmQyMWJvNmJ0bm1mcW9xZWtsNTdnOEBncm91cC5jYWxlbmRhci5nb29nbGUuY29t.cg7k3h1nmqml7psc1nn68223i0?
[16:11] <plars> doanac: I'm 99.9% certain I did, but let me check my history
[16:11] <plars> doanac: well, we see build 3 showing up, so I have to have enabled it
[16:12] <doanac> yeah. n/m
[16:12] <plars> http://reports.qa.ubuntu.com/smokeng/
[16:12] <doanac> plars: we were missing touch_sf4p
[16:12] <doanac> trying to figure out why
[16:13] <cyphermox> argh, just a moment I'm not setup for voice atm
[16:13] <didrocks> cyphermox: ok, don't worry for today then, sil2100 will tell you what is needed if you have time
[16:14] <cyphermox> ok.
[16:15] <cyphermox> sorry i broke some things  while clearing up / resetting stuff for an upgrade to trusty and all, and my headset is elsewhere :)
[16:15] <sil2100> No problem ;) I'll poke you with some stuff later probably
[16:15] <sil2100> Mirv: approve branch! Please ;)
[16:16] <didrocks> cyphermox: see, never clear stuff, always go forward! :)
[16:16] <sil2100> Mirv: ^
[16:17] <Mirv> sil2100: maybe if you ask nicely ;)
[16:17] <didrocks> ahah blackmailing! that's how it should be :)
[16:18] <sil2100> Mirv: pretty pleaaaseee :D
[16:18] <Mirv> done
[16:18] <sil2100> Oh, magic word!
[16:19] <ogra_> maguro #3 is good
[16:19] <ogra_> didrocks, asac ^^^
[16:19] <sil2100> Mirv: thanks! :)
[16:19] <didrocks> ogra_: sweet! :)
[16:19] <didrocks> let's hope we are getting good dashboard result
[16:19] <didrocks> and publish an excellent first image trusty image tomorrow morning
[16:20] <cyphermox> didrocks: the problem with going forward (at least for me) is that cruft accumulates
[16:21] <asac> ogra_: good as in green on automation?
[16:21] <didrocks> cyphermox: easy, don't make cruft :-)
 :p
[16:21] <ogra_> asac, goog as in manual smoketesting done
[16:22] <ogra_> *good
[16:22] <cyphermox> didrocks: easy, hand over your scripts and tricks :)
[16:22] <ogra_> (and passed)
[16:22] <didrocks> cyphermox: ahah ;)
[16:25] <fginther> vila, want to take a crack at review if it's not too late for you? https://code.launchpad.net/~fginther/cupstream2distro-config/upstream-merger-trusty-updates/+merge/192190
[16:26] <cjohnston> doanac: asac working on the touch stuff on the dash
[16:29] <vila> fginther: no, not too late, but missed the meeting *again*
[16:33] <vila> fginther: approved, does that need an additional review from Mirv/sil2100 if only as a heads-up ? Or is it strictly upstream-merger only ?
[16:35] <fginther> vila, this only touches upstream merger pieces, but would definitely welcome another look by sil2100 and/or Mirv
[16:41] <rsalveti> slangasek: no, but we can add that
[16:42] <rsalveti> slangasek: and indeed, we were checking for that file because we didn't have the bridge running when we did that
[16:43] <rsalveti> we got a bunch of clean-up related WIs and this is part of it as well
[16:44]  * fginther -> food
[17:04] <slangasek> rsalveti: ok
[17:42] <plars> asac: something is causing powerd-cli crashes now, not in every run though. would killing powerd-cli after using it to turn the display on do that do you think?
[17:43] <plars> asac: actually, nm I don't think it could be that at all
[17:45] <plars> asac: it's happening even on the install test, which doesn't ever run the pieces that unlock the screen or use powerd-cli to turn the display on
[17:53] <asac> plars: can you reproduce on image 3?
[17:53] <asac> but not on image 1?
[17:54] <plars> asac: of the tests that we had on 1 at http://reports.qa.ubuntu.com/smokeng/trusty/touch/mako/1:20131021.1:20131015/4783/ I couldn't find any that had this powerd crash
[17:55] <asac> ChickenCutlass: ^^
[17:55] <asac> powerd crash
[17:56] <plars> asac: ricmm said he'd take a look also when I pinged on #u-touch
[17:58] <plars> asac: qmlscene crashes on the filemanager app test too, but that was in 1 as well
[18:19] <dobey> where's the config for the upstream merger (the tarmac.conf) live at?
[18:35] <asac> dobey: check with fginther
[18:36] <dobey> fginther: ^^ if you're around?
[18:37] <fginther> dobey, looking
[18:39] <fginther> dobey, what exactly are you looking for? upstream merger doesn't use tarmac directly
[18:41] <dobey> fginther: what commits the code to projects being merged with the CI/daily-release process?
[18:41] <asac> plars: is this putting our dashboard results at risk?
[18:41] <asac> or just investigation needed?
[18:41] <fginther> dobey, https://launchpad.net/jenkins-launchpad-plugin
[18:42] <plars> asac: tests are done and seemed pretty consistent asac for pass/fail, no, but it adds to the number of crash files
[18:43] <dobey> fginther: ah, it's a fork of tarmac?
[18:44] <plars> asac: from what I'm seeing, the testsuites failing on maguro are the same as the ones failing on mako for image 3, modulo a few extra system-settle failures on maguro which isn't too surprising. I'll try adjusting things on systemsettle as you recommended though and have it in the next build
[18:44] <plars> asac: maguro would understandably be more sensitive to systemsettle though
[18:44] <fginther> dobey, it's best described as a wrapper. tarmac is used internally for a few functions
[18:48] <dobey> fginther: well half-a-fork then? it doesn't use the tarmac config stuff, or any of the plug-ins?
[18:50] <fginther> dobey, No. From a quick look,  tarmac is just used to provide abstractions for bzr branches
[18:52] <dobey> fginther: is there any way to do validation of contributors with the jlp autolander? this is a plug-in in tarmac, and allows us to check that contributors have signed the contributor agreement (because they get put in a special launchpad team when they do)
[18:56] <fginther> dobey, I think this is what you want - https://bugs.launchpad.net/jenkins-launchpad-plugin/+bug/1134428
[18:56] <fginther> dobey, if tarmac already supports this as a plugin, than that's probably something that can be re-used here instead of re-invented
[18:57] <dobey> fginther: yes, it supports it. i wrote the plug-in :)
[18:57] <fginther> dobey, do you mind adding a pointer to the bug report?
[18:58] <dobey> fginther: i would guess a lot of the stuff could be done directly with tarmac instead of having a fork that only uses the branching abstractions. we wrote tarmac to be generally quite robust in that sense. i didn't realize you guys had gone this far away from using tarmac, though :-/
[18:58] <dobey> sure
[19:04] <fginther> dobey, now would be a good time to revisit the divergence this cycle. May I pick your brain regarding tarmac in a week or two?
[19:06] <dobey> fginther: sure, i can answer questions any time.
[19:16] <fginther> sergiusens, how does phablet-tools get into ppa:phablet-team/tools? (it needs a saucy version)
[19:16] <sergiusens> fginther, with a jenkins job
[19:18] <sergiusens> fginther, done, added it here: http://10.97.0.26:8080/view/click/job/ppa-sync-phablet/
[19:19] <fginther> sergiusens, thanks
[19:51] <plars> asac: ok, after some systemsettle tweaking, results on mako(saucy-101), mako(trusty-3), and maguro (trusty-3) match - with the exception of the powerd crashes I mentioned earlier
[20:57] <veebers> fginther: ping
[21:10] <fginther> veebers, pong
[21:10] <veebers> fginther: hey how are things? I wanted to ask you about this: https://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner-mako/2662/console
[21:11] <veebers> it failed not because of a test failure
[21:11] <veebers> looks like a dpkg error: E: Sub-process /usr/bin/dpkg returned an error code (1)
[21:13] <fginther> veebers, there is a slew of unmet dependencies. Unfortunately, apt isn't very good at telling you what exactly is missing
[21:13] <fginther> veebers, it's often a dependency at another level that is causing the problem.
[21:14] <fginther> veebers, I can help debug
[21:14] <veebers> fginther: awesome thanks
[21:15] <veebers> fginther: I was wondering (hoping?) that maybe just firing it off again might do it, as all the other runs installed and worked fine
[21:15] <fginther> veebers, I've seen lots of unity8 builds fail this way
[21:15] <fginther> veebers, I have no idea what the actual problem is as no-one has asked about it until now
[22:44] <cjwatson> fginther: That's usually skew between builds on different architectures, more commonly observed when build queues are long
[22:45] <cjwatson> fginther: Since it's in saucy, I assume that the skew is in a PPA
[22:46] <cjwatson> fginther: This is relevant when there's a mix of architecture-dependent and architecture-independent packages involved, with tight dependencies that constrain each other to be of the exact same version; behaviour then depends on the relative publication dates of builds for i386 and whatever architecture you're testing on
[22:47] <fginther> cjwatson, there was actually another error message that looks like the cause of the problem:"unable to make backup link of `./usr/bin/unity8' before installing new version: Invalid cross-device link"
[22:47] <cjwatson> That's not the cause of the apt messages
[22:47] <fginther> cjwatson, oh?
[22:47] <cjwatson> Oh, wait, maybe it is
[22:47] <cjwatson> Yeah, that's bizarre.  Is some kind of filesystem tetris involved here?
[22:48] <cjwatson> Because dpkg will be making a link from ./usr/bin/unity8 to ./usr/bin/unity8.dpkg-<some suffix>, which is never cross-device unless somebody's bind-mounted something onto ./usr/bin/unity8
[22:49] <cjwatson> Sorry, I didn't notice that.  The problem I describe has very similar symptoms at the *end* of the log ...
[22:49] <fginther> cjwatson, hmm, there's nothing funky going on, just trying to install into on a touch device
[22:49] <fginther> cjohnston, veebers and I investigated a little further and assumed it was a packaging bug
[22:49] <cjwatson> ./etc/init/boot-hooks/setcap-unity8.conf:29:        mount --bind "$RUNDIR/unity8" /usr/bin/unity8
[22:50] <cjwatson> that's the cause
[22:50] <cjwatson> and I believe I saw an MP go by that gets rid of that file in trusty?
[22:50] <cjwatson> https://code.launchpad.net/~saviq/ubuntu/trusty/lxc-android-config/drop-unity8-setcap/+merge/192131
[22:50] <cjwatson> so if you can get rid of that in saucy too, maybe you should?
[22:52] <veebers> cjwatson: So I should update this bug an mark it as invalid as it's not actually an unity8 packaging issue? https://bugs.launchpad.net/unity8/+bug/1243432
[22:52] <cjwatson> veebers: It's not a bug in unity8; it's a bug in lxc-android-config
[22:52] <fginther> cjwatson, what's the story for saucy and touch?
[22:52] <cjwatson> fginther: I don't know
[22:53] <cjwatson> veebers: I'll reassign it
[22:53] <fginther> cjwatson, ack. I'll follow up with Saviq
[22:53] <veebers> cjwatson: ah awesome, thanks for that
[22:53] <fginther> cjwatson, yes, thank you
[22:53]  * fginther has to leave for dinner