[00:03] <cjwatson> (Oh look, I'm still slightly here.)
[00:04] <cjwatson> robru: it says that the attempt renders unity-mir's binaries uninstallable
[00:04] <cjwatson> maybe unity-mir needed to be part of the landing?
[00:04] <robru> cjwatson, so unity-mir needs a no-chance rebuild?
[00:04] <robru> no-change ;-)
[00:04] <robru> camako, ^
[00:05] <cjwatson> robru: Looks like it.  libunity-mir1 Depends: libmirserver23, which the new mir doesn't build any more.
[00:05] <cjwatson> The relevant block of update_output.txt is:
[00:05] <cjwatson> Trying easy from autohinter: mir/0.6.0+14.10.20140811-0ubuntu1 unity-system-compositor/0.0.4+14.10.20140811-0ubuntu1 qtmir-gles/0.4.1+14.10.20140811.1-0ubuntu1 platform-api/2.2.0+14.10.20140812-0ubuntu1 qtmir/0.4.1+14.10.20140811.1-0ubuntu1
[00:05] <cjwatson> leading: mir,unity-system-compositor,qtmir-gles,platform-api,qtmir
[00:05] <cjwatson> start: 78+0: i-37:a-4:a-11:a-4:p-7:p-15
[00:05] <cjwatson> orig: 78+0: i-37:a-4:a-11:a-4:p-7:p-15
[00:05] <cjwatson> easy: 87+0: i-40:a-7:a-11:a-7:p-7:p-15
[00:05] <cjwatson>     * i386: libunity-mir-dev, libunity-mir-tests, libunity-mir1
[00:06] <cjwatson>     * amd64: libunity-mir-dev, libunity-mir-tests, libunity-mir1
[00:06] <cjwatson>     * armhf: libunity-mir-dev, libunity-mir-tests, libunity-mir1
[00:06] <cjwatson> FAILED
[00:06] <cjwatson> Usually I search for "final:" and then search for the package name I care about after that; the first hit that way is normally the interesting one.
[00:06] <cjwatson> (Sorry, slightly larger paste than I'd realised)
[00:06] <robru> cjwatson, ok thanks. it's a pretty overwhelming file
[00:07] <camako> robru, I'm here
[00:07] <cjwatson> Right, navigate it by searching rather than by trying to read the whole thing
[00:07] <camako> unity-mir was deprecated
[00:07] <camako> robru, instead qtmir was introduced
[00:07] <cjwatson> Oh, hm, yeah, nothing seems to depend on it any more
[00:08] <cjwatson> Did anyone think to file a removal bug?
[00:08] <cjwatson> Or to do something with all of https://bugs.launchpad.net/ubuntu/+source/unity-mir/+bugs ?
[00:08] <robru> cjwatson, probably not
[00:08] <camako> cjwatson, good point.. will need to ask Saviq
[00:08] <cjwatson> Anyway, give me a reason that I can copy and paste into the relevant command and I'll remove it for you
[00:09] <cjwatson> But somebody should deal with moving/closing as appropriate all those bugs (not necessarily right now)
[00:09] <robru> cjwatson, 'deprecated -- repaced by qtmir'
[00:09] <camako> right
[00:09] <robru> cjwatson, i can reassign the bugs
[00:09] <robru> camako, or maybe you can look at the bugs since I'm unfamiliar with the project. id' just blanket-reassign them all to qtmir
[00:10] <cjwatson> is gone, enjoy
[00:10] <camako> robru, it's not under my team, and I don't know much about it... do it if you have to :-)
[00:10] <cjwatson> so should migrate next p-m run after the next publisher
[00:10] <cjwatson> ~20min or so
[00:11] <camako> robru, does it have to be done right away or can it wait kgunn/Saviq?
[00:11] <cjwatson> bugs can wait, just don't forget
[00:12] <robru> yeah
[00:13] <camako> sure I'll talk to kgunn/Saviq
[00:14] <camako> thanks guys it's my EoD, but I'll be lurking in case you need me
[00:19] <robru> camako, thanks!
[00:49] <cjwatson>  final: mir,platform-api,qtmir,qtmir-gles,unity-system-compositor
[00:50] <cjwatson> Narrowly missed a publisher run, but will happen in a bit, anyway
[01:42] <jhodapp> robru, how much longer are you around for?
[01:43] <robru> jhodapp, a bit
[01:43] <robru> company coming in 15 minutes but not sure how long they'll stay for
[01:43] <jhodapp> robru, ok, I'll be ready to land a beta blocker bug fix in about 15 mins...as soon as silo 15 is done building
[01:44] <robru> jhodapp, oh cool. i can publish it tonight
[01:45] <jhodapp> robru, awesome...this one fixes the wakelocks for media-hub so that you can still play music when unplugged
[01:45] <robru> jhodapp, oh sweet. yeah cron will build an image in a couple hours (and it's a big one with a new mir) so I guess I'll publish after that.
[01:45] <robru> along with a few other things.
[01:46] <jhodapp> robru, awesome...appreciate it!
[01:46] <robru> jhodapp, you're welcome!
[02:04] <imgbot> [02:25] <jhodapp> robru, alright, silo 15 is ready to land whenever you are ready
[02:45] <robru> jhodapp, ok cool, can you mark it tested:yes in the spreadsheet? will publish it shortly
[02:49] <robru> jhodapp, nm, did it
[03:23] <infinity> robru: I had a migraine that led to an afternoon "nap", sorry.  Looks like Colin took care of you, though.
[03:23] <robru> infinity, yep, no worries, thanks. hope you feel better
[03:24] <infinity> robru: Well, I don't feel worse...
[03:38] <bzoltan> robru: may I ask for a reconf for silo7?
[03:38] <robru> bzoltan, already? I just assigned it ;-)
[03:39] <Mirv> mornings
[03:39] <robru> bzoltan, actually since your new mp is on the same project, you can reconfig it yourself. just click on 'recon' on the silo dashboard.
[03:39] <robru> Mirv, good morning!
[03:40] <robru> Mirv, up early?
[03:42] <Mirv> robru: varies a bit, but surely my alarm is always before 7am. zoltan is often even earlier though.
[03:43] <robru> Mirv, ah, welcome ;-)
[03:45] <Mirv> thanks :)
[03:54] <bzoltan> robru: ERROR:root:ubuntu-ui-toolkit-gles was not in the initial list of components for that silo. You can't reconfigure the silo yourself. Please ask the landing team to reconfigure it for you.
[03:55] <robru> bzoltan, oh I didn't see the -gles, looked like the same project, sorry
[03:55] <bzoltan> robru: I started at 4:30 today :) Woke up early after 6 hours sleep..
[03:55] <bzoltan> robru:  it is kind of the same project
[03:55] <robru> bzoltan, yikes ;-)
[03:56] <robru> bzoltan, kind of, but -gles is a different source package
[03:56] <robru> bzoltan, but it doesn't actually have -gles in the URL which is why I was confused
[03:56] <bzoltan> robru: Good idea, I will add -gles to the landing branch name from now.
[03:57] <robru> bzoltan, makes sense, thanks
[03:57] <robru> bzoltan, ok done.
[04:00] <Mirv> robru: any idea how that gallery is not in known space or time?
[04:00] <Mirv> well, and others.. ubuntu-push-qml, media-hub. or did they go to the rtm distro and that's the reason?
[04:01] <robru> Mirv, well, sil2100 landed a bunch of rtm stuff today that probably broke it. he said to get an archive admin to revert his cu2d changes on snakefruit if there were any problems.
[04:01] <Mirv> ok, I'll just ping him when he wakes up in 3h
[04:01] <Mirv> robru: thanks
[04:02] <robru> Mirv, oh, i didn't think to check if they were in rtm. anyway, if you can find an archive admin (infinity?), tell them to go to snakefruit, find the cu2d dir, and restore it from the .bak directory that's right there. or something
[04:03] <robru> Mirv, hm, nope, gallery-app at least didn't go to RTM. seems like it was just lost in the ether
[04:04] <robru> Mirv, haha, ubuntu-push-qml is a NEW package so I wasn't as worried when that one didn't make it anywhere. only just published those other ones recently, so now hilariously the whole dashboard is full of "no known space and time". oh sil...
[04:08] <jhodapp> thanks robru
[04:09] <robru> jhodapp, oh you're welcome. didn't do much good unfortunately :-/
[04:09] <jhodapp> robru, what do you mean?
[04:10] <robru> jhodapp, http://static.fjcdn.com/gifs/All_edd9de_2472970.gif
[04:10] <jhodapp> lol
[04:11] <jhodapp> oh gosh
[04:11] <robru> jhodapp, hehe, that's my favorite gif ever. but seriously, the train broke and even though I published for you, it didn't go anywhere. waiting for an archive admin to fix.
[04:11] <jhodapp> robru, ok, hopefully it gets resolved and merged by the time I wake up :)
[04:12] <robru> jhodapp, a reasonable expectation
[04:12] <jhodapp> anyway, goodnight!
[04:12] <robru> jhodapp, goodnight
[04:12] <Mirv> robru: right... I'll try to find the poor packages with sil then
[04:13] <Mirv> :D
[07:06] <tvoss> Saviq, around?
[07:13] <Saviq> tvoss, wassup
[07:15] <Saviq> camako, hey, yeah, we thought about removing unity-mir, just didn't think hard enough
[07:22] <Mirv> sil2100: as robru put it, http://bit.ly/1l1Bsoh - packages are in no known space and time
[07:23] <sil2100> Ooooo
[07:23] <sil2100> Mirv: ok ;)
[07:23] <sil2100> Mirv: do you know if robru reverted cu2d in snakefruit?
[07:24] <robru> sil2100, i didn't, because I was EOD when mirv discovered the issue
[07:24] <sil2100> robru: ok, good good!
[07:24] <robru> sil2100, I pinged adam about it, no response.
[07:24] <sil2100> Then we can debug it slowly now
[07:24] <Mirv> sil2100: no, he mentioned you had that option. he only found out about this when I pointed it out, just before he went to sleep
[07:24] <sil2100> robru: sleeeep!
[07:24] <Mirv> oh, he didn't go :D
[07:25] <robru> sil2100, it's only midnight ;-)
[07:26] <sil2100> So it seems that ubuntu-rtm support works, but maybe something went bad regarding ubuntu itself without the workarounds
[07:27] <tvoss> trainguards, can I haz silo for line 34?
[07:28] <Saviq> sil2100, I cleaned rtm silo 0, that bad?
[07:28] <sil2100> Saviq: did it work?
[07:28] <Saviq> sil2100, yeah :)
[07:28] <sil2100> I mean, did it merge into the right branch?
[07:28] <sil2100> Ok, at least that!
[07:33] <sil2100> I might know what could be the problem here, geh
[07:36] <Mirv> tvoss: 014
[07:36] <tvoss> Mirv, thank you :)
[08:00] <sil2100> Mirv, robru: the train has been fixed
[08:00] <robru> yay!
[08:01] <robru> I mean, zzzzzzzzzzzzzzzz
[08:01] <sil2100> Mirv, robru: so, it seems that one backwards-compatibility workaround was needed for the requests not to get rejected
[08:01] <sil2100> Since the PPA scheme has changed, and for backward compatibility I need to handle both in the silo whitelisting
[08:01] <sil2100> All uploads that got missing should now be back and soon appear in proposed
[08:02] <jibel> sil2100, robru you just published media-hub from silo 15, who verified it?
[08:03] <robru> jibel, there was no packaging diff on that one...
[08:03] <robru> jibel, jhodapp tested it
[08:03] <jibel> robru, so who verified previous version?
[08:04] <jibel> from QA I mean
[08:04] <robru> jibel, i have no idea... the spreadsheet doesn't record who granted the qa signoff, only that it was granted. you'd have to ask jhodapp I guess
[08:05] <jibel> robru, okay, thanks.
[08:05] <robru> jibel, you're welcome
[08:05] <sil2100> Those got published some time ago, they only now appeared in -proposed due to a bug I made in copy2distro
[08:05] <sil2100> ;)
[08:08] <jibel> sil2100, it is not about the time of the publication, but who did the verification. It's the 4th attempt to fix that 'next song' bug and I would have like someone from QA doing the verification.
[08:15] <brendand> ogra_, if i restart ubuntu-location-service then camera doesn't prompt for it. does that mean the .override file is being used automatically somehow?
[08:16] <ogra_> brendand, indeed ... as i todl you yesterday, it cumulatively (is that a word?) adds to the default job
[08:16] <brendand> ogra_, right but i was trying to establish whether it was something i had to specify or whether it was automatically used. seems the latter
[08:16] <brendand> ogra_, thanks
[08:16] <ogra_> what you execute is a merge of these two (with bits defined in the .override replacing the originals if they already exist in the original)
[08:17] <brendand> ogra_, so lxc-android-config just has to be installed, that's all?
[08:18] <ogra_> yep
[08:18] <brendand> ogra_, and is that in the image? i didn't deliberately install it last time
[08:18] <ogra_> lxc-android-config ?
[08:19] <ogra_> yes, thats our central package maintaining the android container (and all bits related to it ... like this override file)
[08:19] <ogra_> if you have a working android container you have this package :)
[08:20]  * ogra_ goes to make fresh coffee
[08:27] <brendand> ogra_, is there any documentation for them?
[08:28] <ogra_> "them" ?
[08:28] <Laney> https://code.launchpad.net/~afrantzis/mir/fix-mircommon-debian-replaces/+merge/230583 needs to be uploaded
[08:28] <Laney> upgrades are failing
[08:29] <jibel> robru, sil2100 for example with this version of media-hub, videos stop playing after a couple of minutes :/
[08:29] <sil2100> Damn...
[08:29] <sil2100> jibel: are you sure it's caused by this media-hub landing and not anything else that also landed in the meantime?
[08:29] <robru> jibel, jhodapp told this was the big *fix* that prevented wakelocks so that media can play
[08:30] <jibel> robru, right and it fixes that but introduces another issue.
[08:31] <robru> jibel, bah. well sil2100 can help you back it out if you feel that's appropriate, or wait for jhodapp to bring a real fix
[08:31]  * sil2100 sighs
[08:31] <jibel> robru, sil2100 we'll wait for jhodapp
[08:32] <sil2100> We can revert if needed, but if I understand correctly this would mean re-introducing another bug, right?
[08:32] <jibel> sil2100, yes
[08:32] <robru> jibel, wait, are you testing the silo? because it isn't in any image build...
[08:32] <jibel> robru, I was testing silo 15
[08:32] <robru> jibel, ok
[08:45] <Laney> I'll probably upload mir, shouldn't be a problem if it's just overwritten when that branch ^^^ is merged in
[08:53] <sil2100> Ok, right, upload
[08:53] <sil2100> :)
[08:53] <sil2100> Thanks for the notice!
[08:59] <brendand> tvoss, there's a possible issue in location-service
[08:59] <brendand> tvoss, it seems that when i restart it, the camera app doesn't ask for a dialog the next time
[09:00] <brendand> tvoss, even if i haven't set a fake provider or set the environment variable
[09:01] <tvoss> brendand, it's not the camera app asking for trust, but the service. However, if you restart the service without restarting its associated trust-store instance, the service does not know about the user-specific trust store and just revokes connection attempts
[09:01] <brendand> tvoss, ah that explains it
[09:02] <brendand> tvoss, this is a bit more complicated then i thought it would be
[09:02] <ogra_> tvoss, we should make sure the trust store gets restarted alongside then
[09:02] <brendand> tvoss, so can i restart the trust store seperately?
[09:02] <ogra_> in the upstart job or via a new upstart job that are interconnected
[09:03] <tvoss> brendand, so you should call sudo restart ubuntu-location-service && restart ubuntu-location-service-trust-stored
[09:03] <ogra_> sounds like a security hole ... if the location service crashes under you you can work around the trust store
[09:03] <tvoss> ogra_, you cannot
[09:03] <tvoss> ogra_, it will just reject all connection attempts ;)
[09:03] <ogra_> tvoss, tell that to our smoke tests :P
[09:03] <tvoss> ogra_, so what exactly is happening?
[09:03] <ogra_> obviously we have apps that pass fine where the trust store should block them
[09:04] <tvoss> ogra_, unlikely, their request might time out and they just keep on going
[09:04] <brendand> tvoss, is that name right?
[09:05] <ogra_> tvoss, well, we have trust store crashes in 6 tests today, only one seems to fail hard (camera) while others just pass (webbrowser)
[09:06] <tvoss> ogra_, I haven't had time to look into the trust-store crashes. Also: why would the webbrowser stop functioning if just location cannot be accessed?
[09:06] <ogra_> well, wouldnt it first ask for permission ?
[09:06] <ogra_> or is there a whitelist for the browser in place ?
[09:07] <brendand> ogra_, the browser only asks for permission if the test visits a page which requests that
[09:07] <brendand> ogra_, i don't think any do
[09:07] <ogra_> ok
[09:08] <tvoss> brendand, ogra_ I thought we agreed that we would just switch off the trust store operation in smoke testing for now for the location service?
[09:08] <brendand> tvoss, it can't find that service name
[09:08] <brendand> tvoss, that's what i'm trying to do now
[09:09] <oSoMoN> brendand, ogra_: there’s a couple of browser autopilot tests that request geolocation, but they don’t do any interaction past the permission request
[09:09] <ogra_> tvoss, right ... we are just looking at potential oddities we find during doing that ;)
[09:10] <tvoss> brendand, http://pastebin.ubuntu.com/8034473/
[09:10] <tvoss> brendand, please note that you have to restart the trust-stored portion as ordinary user
[09:11] <brendand> tvoss, http://paste.ubuntu.com/8034490/
[09:11] <brendand> tvoss, that's the same command you ran
[09:12] <tvoss> brendand, that's weird, I'm running on the latest image
[09:12] <ogra_> tvoss, then the trusted store upstart job should get a dependency on the location service job ;)
[09:12] <alf_> cihelp: Hi! Any ideas about CI failure https://jenkins.qa.ubuntu.com/job/mir-mediumtests-builder-utopic-armhf/225/console "java.io.IOException: Failed to mkdirs: /home/ubuntu/jenkins/workspace/mir-mediumtests-builder-utopic-armhf"?
[09:12] <Mirv> popey: umm, I installed http://s-jenkins.ubuntu-ci:8080/job/gallery-app-click-from-branch/95/artifact/out/com.ubuntu.gallery_2.9.1.1040_armhf.click locally and it doesn't start for me...
[09:12] <ogra_> one that restarts it alongside
[09:13] <brendand> tvoss, i'll reflash and check again
[09:13] <tvoss> ogra_, how do I do that?
[09:13] <popey> Mirv: lemme try
[09:13] <ogra_> tvoss, start on started :sys:foobar
[09:14] <ogra_> tvoss, stop on stopped :sys:foobar
[09:14] <ogra_> in the trust-store upstart job
[09:14] <tvoss> ogra_, btw: it's :sys:started foobar
[09:16] <tvoss> ogra_, here is the current setup: http://pastebin.ubuntu.com/8034531/
[09:17] <ogra_> i'Äm not so sure the syntax in the brackets is correct
[09:17] <tvoss> ogra_, it works, so I guess it is, and the upstart syntax checker says it is good
[09:17] <ogra_> in any case you should start again if the location service gets restarted ;)
[09:18] <ogra_> add the same or to the start stanza
[09:18] <ogra_> (well, with sys:started)
[09:19] <tvoss> ogra_, but I cannot make that an AND with the other start conditions as the signal started might be lost then
[09:19] <ogra_> if you add an "or" ?
[09:20] <ogra_> ah no, you actually want an and
[09:21] <tvoss> ogra_, right, but that imposes problems on system startup
[09:21] <ogra_> whats all that JOB= mess ß
[09:21] <ogra_> ?
[09:21] <tvoss> ogra_, according to upstart docs, that's the way to do it
[09:21] <ogra_> lol
[09:21] <ogra_> where did you see that ?
[09:21] <ogra_> look at other upstart jobs :)
[09:22] <popey> Mirv: wfm
[09:22] <popey> Mirv: anything specific not working?
[09:22] <ogra_> tvoss, "start on started JOB=dbus and started JOB=unity8" ... this should just be: "start on started dbus and started unity8"
[09:22] <Mirv> popey: umm, works after reboot
[09:23] <popey> ship it
[09:23] <Mirv> usually things have just launched fine after pkcon local-install
[09:23] <Mirv> :)
[09:24] <tvoss> ogra_, it is exactly the same
[09:24] <ogra_> tvoss, except that is how we write it in all other upstart jobs :)
[09:25] <ogra_> there is no need to shuffle ENV vars for job names around
[09:25] <tvoss> ogra_, not in the one that sergiusens gave me for reference, I think it was nuntium
[09:25] <tvoss> ogra_, JOB is set by upstart itself
[09:25] <ogra_> i know
[09:25] <ogra_> still not the syntax we use anywhere else
[09:26] <ogra_> (except for nuntium apparently ... hadnt seen that yet)
[09:27] <popey> Mirv: i launched gallery, killed it, upgraded it with pkcon and ran again, all fine
[09:28] <ogra_> tvoss, this shoudl work and properly restart when locations restarts: http://paste.ubuntu.com/8034602/
[09:28] <Mirv> popey: I tested it now for a bit for videos, editing photos, everything worked. so, uploaded.
[09:30] <popey> Mirv: sil2100 approved gallery into the store
[09:31] <sil2100> \o/
[09:32] <sil2100> popey, Mirv: thanks guys, so I guess it should be safe now to build a new image then
[09:38] <Mirv> sil2100: probably, after a small pause of "make sure everything's updated"? :) it's clear in case of archive uploads, but I don't know what kind of processes / cron jobs are involved in the store, if any
[09:40] <popey> pretty sure if you build now, it will pull from the store during build
[09:52] <tvoss> ogra_, brendand https://code.launchpad.net/~thomas-voss/location-service/make-sure-trust-store-restarts-on-location-service-restart/+merge/230599
[09:53] <brendand> tvoss, if i update the test to restart both, will that MP break that? or will it do no harm?
[09:54] <tvoss> brendand, it *shouldn't* impact it ... upstart should be clever enough
[09:59] <imgbot> [10:01] <sil2100> 10:00, nice timing
[10:05] <nik90> bzoltan: it looks like the packages failed to build in silo-007
[10:09] <brendand> tvoss, so the last piece is that i have to pass 'TRUST_STORE_PERMISSION_MANAGER_IS_RUNNING_UNDER_TESTING' through - or is it?
[10:09] <brendand> tvoss, or was that one option and this is a different one?
[10:10] <tvoss> brendand, nope, that would be required @env variable, to disable trust prompts for location accesses during testing
[10:11] <brendand> tvoss, so it doesn't seem to be picking it up. i tried initctl set-env as well
[10:11] <tvoss> brendand, do you set that variable pre-start?
[10:13] <brendand> tvoss, well i run initctl set-env, then the command you gave to restart the services
[10:13] <nik90> sil2100: quick question, is it possible to trigger a rebuild of silo-007? Was the build failure due to issues with copy2distro you mentioned earlier?
[10:17] <tvoss> brendand, got the exact command line for me?
[10:17] <brendand> tvoss|test, initctl set-env TRUST_STORE_PERMISSION_MANAGER_IS_RUNNING_UNDER_TESTING=1; sudo restart ubuntu-location-service && restart ubuntu-location-service-trust-stored
[10:18] <psivaa> alf_: sorry, just noticed your ping. i'll take a look
[10:19] <sil2100> nik90: hey! The issues with copy2distro were only in silo publishing, so only problems with copying the package to the end archive
[10:19] <sil2100> nik90: so it should be related, but I can re-trigger a build for silo 007 if needed
[10:19] <tvoss> brendand, from within which job do you run that?
[10:20] <ev> psivaa: thank you
[10:20] <alf_> psivaa: great, thanks
[10:20] <brendand> tvoss, i just run that on the command line
[10:20] <psivaa> np :)
[10:20] <nik90> sil2100: looking through the console log at https://ci-train.ubuntu.com/job/landing-007-1-build/140/console, it just says ERROR arm64 marked as FAILED because i386 build FAILED and we may miss arch:all packages
[10:21] <nik90> sil2100: so I am not sure :)
[10:21] <tvoss> brendand, then it applies to the session upstart instance, you need to run sudo initctl set-env ...
[10:21] <tvoss> brendand, the location service (which is interpreting the env variable) lives on the system bus
[10:21] <tvoss> brendand, or better: lives with the system upstart instance
[10:21] <brendand> tvoss, ah but 'initctl: Not permissible to modify PID 1 job environment'
[10:21] <brendand> tvoss, that's a problem :/
[10:22] <tvoss> brendand, right, that's why I proposed the upstart job override
[10:22] <alf_> psivaa: FYI, mir-mediumtests-builder-utopic-armhf/228 also failed with the same error
[10:23] <sil2100> nik90: from the PPA I see that it failed building for both amd64 and i386, so something is wrong it seems
[10:24] <nik90> sil2100: I will talk to bzoltan to see if he can fix it on his end
[10:28] <brendand> tvoss, you mean i would need to write a new override file that does that, or would the one in lxc-android-config be able to do it?
[10:31] <tvoss> brendand, I would propose adjusting the one in lxc-android-config
[10:32] <brendand> tvoss, is 'exec TRUST_STORE_PERMISSION_MANAGER_IS_RUNNING_UNDER_TESTING=1 /usr/bin/ubun
[10:32] <brendand> tu-location-serviced --bus system --provider $provider $poptions' right?
[10:32] <brendand> tvoss, i mean is ubuntu-location-serviced what is looking for that to be set?
[10:35] <tvoss> brendand, yup :)
[10:36] <brendand> y no work then :/
[10:36] <brendand> tvoss, might i also have to set it for the trust-stored?
[10:37] <tvoss> brendand, nope
[10:37] <tvoss> brendand, let me have a look at the override job again
[10:38] <brendand> tvoss, http://paste.ubuntu.com/8035015/
[10:38] <psivaa> alf_: yea, we had similar issues with that node a couple of days before i guess. Looks like it has some filesystem issues. i'll create a task to reinstall it with fginther's consent. but for now it's fixed: http://s-jenkins.ubuntu-ci:8080/job/mir-mediumtests-builder-utopic-armhf/229/console
[10:38] <brendand> tvoss, that's just for now - obviously i'll make sure it's not always set
[10:39] <ogra_> brendand, urgh
[10:39] <alf_> psivaa: thanks
[10:39] <ogra_> can you please properly export that ?
[10:40] <brendand> ogra_, i can - but i'm just trying to get it to work for now
[10:41] <brendand> ogra_, i have to use env - got it
[10:42] <ogra_> brendand, http://paste.ubuntu.com/8035040/ ... and have your test call: "setprop custom.location.testing true"
[10:43] <ogra_> (you might need env too ... test it :) )
[10:44] <brendand> agh, why is it not working...
[10:46] <brendand> maybe it will be easier just to have autopilot accept the prompt...
[10:53] <brendand> tvoss, is there any trace that the location service leaves of being started in testing mode - a log file anywhere?
[10:54] <tvoss> brendand, nope, not for testing mode
[10:55] <tvoss> brendand, the easiest way: just remove the trust db, reboot, try to access
[11:00] <brendand> tvoss, i rebooted, restarted the service with the variable set (i believe) and still get the dialog. and trust.db is created
[11:07] <brendand> tvoss, finally works
[11:07] <brendand> tvoss, yes if trust.db exists then it won't work
[11:07] <brendand> tvoss, is that right?
[11:08] <tvoss> brendand, nope, if the env variable is set, the location service does not even reach out to the trust-store
[11:08] <brendand> ogra_, if i go 'setprop custom.location.testing "true"' then i don't see it in getprop
[11:08] <brendand> ogra_, what am i doing wrong?
[11:09] <ogra_> phablet@ubuntu-phablet:~$ sudo setprop custom.location.testing "true"
[11:09] <ogra_> phablet@ubuntu-phablet:~$ getprop |grep location|grep testing
[11:09] <ogra_> [custom.location.testing]: [true]
[11:09] <ogra_> brendand, not sure ... missing sudo ?
[11:10] <brendand> ogra_, seems like it. setprop is silent about that
[11:10] <brendand> not even an error code...
[11:10] <ogra_> heh
[11:10] <ogra_> android :)
[11:13] <davmor2> sil2100: accounts → settings app is still playing up so I don't know what got rebroken there but if you hit the back button in accounts you are left with what looks like a crashed phone
[11:16] <sil2100> uh? Crashed phone? i.e. no unity8?
[11:16] <brendand> ogra_, ok i need to push this to lxc-android-config then
[11:17] <ogra_> brendand, the changed uppstart job ?
[11:17] <ogra_> give me a final pastebin and i'll upload :)
[11:18] <brendand> ogra_, your pastebin was almost there. the variable has to be a string though
[11:18] <brendand> ogra_, needs quotes around
[11:19] <ogra_> AROUND TEH VALUE ? http://paste.ubuntu.com/8035295/
[11:19] <ogra_> OOPS
[11:19] <ogra_> sorry for the shouting
[11:19] <brendand> ogra_, i thought 'has ogra finally snapped ?'
[11:19] <ogra_> haha
[11:20] <brendand> ogra_, for the avoidance of doubt, here's my file which works http://paste.ubuntu.com/8035296/
[11:20] <brendand> ogra_, they should be indentical though
[11:20] <brendand> identical
[11:20] <ogra_> ok, i'll land that
[11:21] <ogra_> hmpf, 187 gre quite a bit again
[11:21] <ogra_> sigh
[11:21] <ogra_> *grew
[11:22] <ogra_> another 4MB for the tarball ...
[11:22]  * ogra_ waits for the changelog ... this isnt good ... 
[11:23] <brendand> hmm one issue that's foreseeable - can autopilot tests run under sudo?
[11:23] <brendand> need to try and find that out
[11:24] <ogra_> i think plars' setup for the new non-root adbd puts a blanket sudo allowance in place
[11:24] <ogra_> so you should be able to do something like "adb shell sudo foobar"
[11:24] <brendand> ogra_, does phablet-click-test run with the phablet user?
[11:25] <ogra_> that will indeed not work at home ... and we cant have an interactive sudo prompt across adb
[11:25] <ogra_> not yet, but it will have to
[11:25] <brendand> ogra_, i'll ask plars about it when he's online
[11:25] <ogra_> i'm actually trying to finish that stuff today
[11:27] <brendand> ogra_, but this would have to be something that happens in ci - it's not something i could fix in the test itself?
[11:28] <ogra_> well, if you call sudo you will need a password
[11:29] <ogra_> and do something like: adb shell "echo 12345 | sudo -S foobar"
[11:30] <ogra_> while the automated infra can just put a fully open sudoers file in place thats not really something we can easily do for home testing
[11:34] <ogra_> come on bot ... i see 187 on the server already
[11:34] <imgbot> [11:34] <imgbot> [11:35] <ogra_> :)
[11:35] <ogra_> dpm, argh ... your new spellchecker stuff eats a lot of extra space :(
[11:42] <dpm> ogra_, "my" spellchecker?
[11:50]  * sil2100 goes for lunch
[11:53] <dbarth> hi
[11:53] <dbarth> cihelp?
[11:53] <psivaa> hello
[11:53] <dbarth> psivaa: hi
[11:54] <dbarth> i'd like to clean merge a barnch without landing, cause i have a new set of changes to go
[11:54] <dbarth> this is for ubuntu-system-settings-online-accounts
[11:54] <dbarth> the stuff in silo 13
[11:54] <psivaa> dbarth: for silo, i think you'd need trainguard
[11:54] <dbarth> what's best? stack branches there?
[11:58] <psivaa> trainguards: ^ is that something you guys could answer?
[12:01] <ogra_> dpm, "the spellchecker" :)
[12:02] <dpm> ogra_, I don't know much about it, tbh, but I'm interested. What's taking up the space. Are there lots of packages? Or just a few packages that are quite big?
[12:04] <ogra_> dpm, http://people.canonical.com/~ogra/touch-image-stats/187.changes ... see the list of added packages ... the make up 4MB extra on the tarball (likely something between 20-30B unpacked on the rootfs)
[12:04] <ogra_> *MB
[12:04] <ogra_> *they
[12:04] <ogra_> sigh ...
[12:04]  * ogra_ will really sign up for a typing course ...
[12:06] <Mirv> dbarth: so you'd want to get the changes merged to trunk but not actually published, since you have more changes coming in? couldn't you just include the old silo's branches to the new silo (or reuse + reconfigure the old silo)?
[12:10] <dpm> ogra_, ok, I see it. Why have those particular myspell-* packages have been added, are they dependencies of the updated keyboard layouts?
[12:11] <ogra_> might be ... let me check
[12:12] <ogra_> yep ... llooks like keyboard http://paste.ubuntu.com/8035629/
[12:13] <ogra_> (scroll down for the summary)
[12:14] <dbarth> Mirv: we'er going to just reuse the silo, yes
[12:14] <dbarth> Mirv: ie stack all subsequent changes to ussoa/master
[12:14] <dbarth> and take some extra bits
[12:14] <Mirv> dbarth: ok, just ping us when you've all the branches listed and we can reconfigure the silo
[12:14] <dbarth> i'll cry in a bit to get a reconfig ;)
[12:22] <davmor2> jibel, sil2100: youtube bug is fixed by the latest version of the scope in the store by the look of it \o/
[12:23] <jibel> davmor2, right, I saw the update. thx
[12:26] <jibel> sil2100, bug 1356325 and bug 1356331 on 187
[12:31] <ogra_> brendand, lication change uploaded ...
[12:40] <brendand> ogra_, do you think putting the location-service in testing mode is something we might do in the jenkins job, or should it be specific to each test/suite?
[12:40] <sergiusens> ogra_: tvoss right, the JOB in nuntium is wrong; it's a leftover for when I had a much more complicated start up stanza before migrating the logic to the daemon itself (to check for ofono)
[12:41] <ogra_> sergiusens, well, it works that way too ... i wouldnt say its wrong per-se :)
[12:41] <ogra_> just not the syntax we normally use
[12:41] <sergiusens> ogra_: yeah, wrong in being neat :-)
[12:45] <sil2100> jibel: thanks! Did you talk with the media-hub guys about it?
[12:47] <sil2100> jibel: also, if you could get davmor2 to confirm this issue I would add it to our blocker list
[12:50] <jibel> sil2100, yes, they said this bug already existed but I disagree ig it already existed it happens really frequently now and with videos that used to work
[13:14] <mterry> sil2100, hello!  So for bug 1355726...  I'm worried that it's not reproducable
[13:15] <mterry> sil2100, did you happen to hit it yet (if you tried)
[13:15] <mterry> ?
[13:16] <sil2100> mterry: hey, I didn't try reproducing it yet, but I know davmor2 had no problems getting it to happen, and I think ogra_ also might have seen that
[13:16] <sil2100> davmor2: ^?
[13:16] <mterry> sil2100, last comment from davmor2 said he couldn't hit it anymore
[13:16] <jibel> mterry, I reproduced it yesterday on mako with --wipe. I can try again with latest image.
[13:17] <ogra_> well, i did see it on a non-mako device with a very early image there ... i wouldnt count my experience into that bug for now
[13:18] <mterry> jibel, sil2100: I tried quite a few times to hit it yesterday, no success  :-/  I guess it's just a numbers game
[13:18] <ogra_> mterry, my issue was that there was no ~/.pam_environment created at all after the wizard ran
[13:18] <ogra_> (so i couldnt set language etc)
[13:18] <mterry> ogra_, huh...
[13:18] <ogra_> i guess it crashed before it could create it
[13:18] <jibel> if the serial of the device is a prime number then you're affected ;)
[13:19] <ogra_> back then the wizard was still pretty crashy ... i didnt try with a newer version
[13:19] <davmor2> mterry: I have a horrible feeling that it is a race condition of some sort so I'll keep a close eye and try to reproduce after I get some other testing done, if jibel has time he can certainly try,  Is there anything else useful we can  get from the system if we get into that state again though?
[13:20] <sergiusens> robru: hey, new feature for silos; can we make the testplan link automatic?
[13:20] <mterry> davmor2, very possibly...  contents of /home/phablet/.cache/upstart and /var/log/ would both help
[13:21] <davmor2> mterry: also from the work I and Saviq did I think that the Wizzard seems to remain open.  But I'll keep an eye out
[13:22] <mterry> davmor2, huh..
[13:22]  * mterry is trying to reproduce again, this time with image 187
[13:28] <jibel> mterry, I just reproduced bug 1355726 and kept the device in the black screen state. what info do you need?
[13:28] <mterry> jibel, ooh!  you unlucky devil
[13:29] <mterry> jibel, ok...  can you do a "ps aux | grep -e wizard -e unity8" just to see what's running right now?
[13:30] <Saviq> mterry, yeah, I only guided davmor2 through some fact finding, but didn't get much anywhere
[13:30] <jibel> mterry, http://paste.ubuntu.com/8036188/
[13:30] <Saviq> mterry, don't get fooled ↑ unity8-dash is just in a respawn-loop there
[13:30] <mterry> Saviq, OK...
[13:30] <mterry> jibel, so do you see the greeter?
[13:30] <mterry> jibel, but no dash?
[13:31] <jibel> mterry, I see the top panel and everything else is black
[13:31] <jibel> mterry, no greeter, no dash, no wizard, no spinner
[13:31] <mterry> jibel: you never see the greeter?  just goes straight to panel? hhmmm
[13:32] <mterry> Saviq, was the "UbuntuClientIntegration: connection to Mir server failed" message only in unity8-dash?
[13:32] <mterry> jibel, does /home/phablet/.pam_environment exist?
[13:33] <Saviq> jibel, wait, if you press the power button, greeter gets in doesn't it?
[13:33] <Saviq> jibel, you mean that you unlocked the phone and there's no dash?
[13:47] <renatu> hey guys I am facing this error while building my packages on silo 4 : 1: LLVM ERROR: Cannot select: intrinsic %llvm.x86.sse41.pblendvb
[13:47] <renatu> any idea about that?
[13:47] <kenvandine> ugh
[13:48] <kenvandine> i heard those kinds of problems were blocking migration to release last night
[13:48] <tvoss> davmor2, ping
[13:49] <tedg> davmor2, Would you have some time to make sure silo5 doesn't break anything for you?
[13:49] <tedg> davmor2, You shouldn't notice anything different with it :-)
[13:49] <seb128> kenvandine, renatu: that's being investigated, was discussed earlier on #ubuntu-devel
[13:49] <davmor2> tedg: if I shouldn't notice anything different why do we need it ;)
[13:49] <davmor2> tvoss: hello
[13:49] <tvoss> davmor2, what tedg just asked about :)
[13:50] <renatu> bfiller, ^^^
[13:50] <davmor2> tvoss, tedg: yeap on it
[13:50] <tedg> davmor2, Cool, thanks!
[13:50] <renatu> seb128, thanks
[13:51] <tvoss> davmor2, awesome, thank you
[13:52] <davmor2> jhodapp: music and it plays \o/
[13:52] <jhodapp> davmor2, yay! :)
[13:53] <jhodapp> davmor2, so happy to have the bug fixed
[13:53] <davmor2> jhodapp: and like one after another over and over :D
[13:53] <jhodapp> lol, you mean it's just working now!? ;)
[13:53] <renatu> seb128, should we wait that get fixed before release the silo?
[13:54] <davmor2> jhodapp: you just need to work on getting the browser plugin now ;)
[13:54] <seb128> renatu, not sure, check with sil2100 or doko I guess?
[13:54] <jhodapp> davmor2, alexabreu and jgdx are working on that :)
[13:54] <jhodapp> davmor2, I'm working on getting mp3 seeking working again now
[13:55] <davmor2> jhodapp: \o/
[13:56] <jibel> Saviq, mterry sorry was OTP, here is what I see http://people.canonical.com/~j-lallement/1355726.png
[13:56] <jibel> Saviq, if I press the power button there is no greeter, just the indicator panel
[13:56] <Saviq> jibel, yes, but you can pull in the launcher
[13:56] <mterry> jibel, but never a greeter?  that's weird
[13:57] <Saviq> huh
[13:57] <jibel> Saviq, no I can only pull indicators
[13:57] <Saviq> yikes, wonder what happened there then
[13:58] <jibel> mterry, ~/.pam_environment exists
[13:58] <mterry> jibel, the symptoms you are describing make no sense ;)
[13:59] <davmor2> jibel: is there data in it?
[13:59] <jibel> mterry, thank you, that's why I took a screenshot to prove I am not insane ;)
[13:59] <davmor2> I can confirm that is what I was seeing too
[13:59] <jibel> davmor2, in ~/.pam_environment there is locale and papersize env variables
[14:00] <mterry> jibel, I don't think pam_environment is a big clue to this, I just wanted to confirm it's different than a similar issue ogra_ saw a while back, where he didn't have a pam_environment file
[14:01] <davmor2> mterry: yeah ogra_ asked me yesterday if it had anything in it so I was just checking here too
[14:01] <jibel> mterry, in /var/crash I've a crash for unity8-dash and maliit-server
[14:03] <mterry> jibel, yeah... Saviq said he discovered that unity8-dash is just aborting over and over.  So that doesn't surprise me
[14:03] <mterry> maliit-server is a little odder
[14:06] <davmor2> bfiller: messaging app, new message, add a name from contacts and it moves over under the back arrow by the look of it, I completely forgot to file a bug so I will do that now
[14:11] <jibel> mterry, Saviq unity8-dash crash: https://errors.ubuntu.com/bucket/?id=/usr/bin/unity8-dash%3A6%3Aqt_message_fatal%3AQMessageLogger%3A%3Afatal%3AQList%3AUbuntuScreen%3A%3AcustomEvent%3A_dl_runtime_resolve
[14:12] <mterry> jibel, yeah... looks like an intentional abort because the environment isn't what it wants
[14:13] <jibel> it sounds quite popular
[14:13] <mterry> Saviq, so unity8-dash I could understand if it can't connect to Mir.  But the problem with the greeter / launcher must be different, eh?
[14:14] <mterry> jibel, can I see /home/phablet/.cache/upstart/unity8.log?
[14:14] <jibel> mterry, yes
[14:14] <mterry> jibel, and I suppose unity8-dash.log while there
[14:14] <mterry> thanks!
[14:16] <jibel> mterry, http://people.canonical.com/~j-lallement/1355726_logs.tgz all of /var/log and /home/phablet/.cache/upstart
[14:17] <Saviq> mterry, yeah, that one baffles me
[14:17] <Saviq> mterry, but *maybe* it's a symptom of the same
[14:18] <Saviq> mterry, if dash isn't there, maybe the dash communicator gets weird
[14:18] <mterry> jibel, I've been re-flashing all morning, still no luck to hit it myself  :(
[14:19] <jibel> mterry, I'm sorry for you
[14:19] <mterry> :)
[14:19] <Saviq> mterry, looking at the example https://errors.ubuntu.com/oops/c2b19e56-22f2-11e4-9d72-fa163e373683
[14:20] <Saviq> mterry, procEnviron is rather scarce
[14:20] <mterry> jibel, OK.  so yeah, these logs show unity8-dash dying all over, and unity8 working just fine (it thinks)
[14:20] <Saviq> mterry, and it's a pattern among https://errors.ubuntu.com/bucket/?id=/usr/bin/unity8-dash%3A6%3Aqt_message_fatal%3AQMessageLogger%3A%3Afatal%3AQList%3AUbuntuScreen%3A%3AcustomEvent%3A_dl_runtime_resolve
[14:20] <mterry> Saviq, good point
[14:21] <mterry> Saviq, I'm going to intentionally mess up my unity8-dash run job and see if that causes the problem with unity8
[14:22] <Saviq> mterry, yeah, was thinking the same
[14:22] <Saviq> mterry, but the ProcEnviron is scary
[14:22] <mterry> Saviq, yeah...  I just want to see which side is the root cause  :)
[14:22] <Saviq> mterry, like upstart wouldn't pass the environ to the process
[14:23] <Saviq> mterry, because with list-env you can see all the bells'n'whistles
[14:23] <mterry> true...
[14:24] <mterry> an upstart bug would be fun...
[14:24] <ricmm> anyone who can publish a silo for me? 018
[14:30] <mterry> Saviq, ok, a failing unity8-dash job does not bring unity down.  So it's some shared awfulness between the two
[14:31] <mterry> Saviq, and the unity8-dash.conf job looks so innocent
[14:32] <charles> jdstrand, ping
[14:33] <jdstrand> charles: hey
[14:34] <charles> jdstrand, I had a question for you about apparmor dbus security
[14:34] <charles> jdstrand, I need to add a new system service that will hold the /dev/alarm lock and handle wakeups
[14:34] <charles> right now indicator-datetime is calling the platform-api to do this s.t. the user's wakeup alarms trigger a hardware wakeup alarm
[14:34] <charles> but push needs these too, and it looks like only a single process can hold onto /dev/alarm
[14:35] <charles> so I'm thinking a small service that takes dbus requests from push and from datetime, and holds that alarm lock
[14:36] <charles> jdstrand, iirc when I was adding dbus-visible properties to indicator-datetime you were the Answer Man wrt how to do it correctly wrt security
[14:36] <charles> jdstrand, so with that long prologue out of the way, is there anything I need to take into account when writing this?
[14:36] <charles> it would be a simple dbus API along the same lines of what usensorsd does for haptic
[14:41] <jdstrand> charles: do untrusted (aka confined) apps need to access this new service, or is it only other services that access it?
[14:44] <charles> jdstrand, iiuc only indicator-datetime and push will be using for the time being
[14:44] <charles> jdstrand, the scope for that might expand in the future if we need some kind of alarm-aware cron system for end users
[14:45] <charles> jdstrand, but that creep would be post-RTM
[14:47] <jdstrand> charles: that would also be a separate service
[14:48] <jdstrand> charles: if only services that aren't used by apps or trusted helpers are using the new service, there is no special requirement
[14:49] <jdstrand> charles: I have to step away for a few minutes, I'll be back in a few
[14:49] <jdstrand> charles: (feel free to type here, I read backscroll)
[14:56] <jibel> mterry, can I reboot my device and use it for something else or you need more info?
[14:57] <mterry> jibel, sorry was in meeting
[14:57] <mterry> jibel, uh...  I don't want to stop you from having your device
[14:57] <mterry> jibel, I still am unsure what to do with the info I have.  But I'm not sure holding on to the device for now will help
[14:57] <jibel> mterry, I can always reflash it if you need
[14:57] <mterry> jibel, yeah seems reliable for yolu
[15:15] <mterry> jibel, do you do anything specific when going through the wizard?
[15:15] <mterry> jibel, like, do you always set up wifi and such?
[15:16] <mterry> change language...
[15:16] <jibel> mterry, I select French and set up wifi
[15:17] <brendand> plars, hey
[15:18] <plars> brendand: hi
[15:19] <brendand> plars, almost got a fix sorted for camera-app, but it's going to involve the test running under sudo
[15:19] <plars> heh
[15:19] <plars> ouch
[15:20] <plars> brendand: that sorta throws a kink in things I guess
[15:20] <plars> brendand: why would it need sudo? any other ways you've found around it?
[15:20] <brendand> plars, because it has to restart the location service, which runs on the system bus
[15:21] <brendand> plars, not much else we can do. unless..
[15:21] <brendand> tvoss - would preseeding the trust db require root as well?
[15:22] <tvoss> brendand, nope, it would be per user
[15:22] <ogra_> brendand, ugh, why ?
[15:22] <ogra_> brendand, you would only need to run the one getprop under sudo
[15:23] <ogra_> err
[15:23] <ogra_> setprop
[15:23] <brendand> ogra_, and the service restart
[15:23] <ogra_> yeah
[15:23] <ogra_> but not the whole test :)
[15:23] <ogra_> that would taint the results quite a bit :)
[15:23] <davmor2> tvoss, tedg: so I can open all the apps and trusted helpers that I can think of and everything seems fine
[15:24] <brendand> ogra_, no true. so would i use sudo -A?
[15:24] <tvoss> davmor2, try using the browser together with a few apps and see if the browser is correctly stopped (by inspecting top ideally)
[15:24] <tvoss> tedg, ^
[15:24] <ogra_> brendand, echo <passwd> | sudo -S <command>
[15:25] <davmor2> tvoss: sure
[15:25] <tedg> Yeah, I usually start a bunch of webapps and then do a "ps -ef  | grep oxide" after closing them.
[15:25] <tedg> davmor2, Our issued before (that ogra_ found) was when they were OOM'd. So you really should start enough that OOM gets involved.
[15:25] <ogra_> brendand, though we dont have a password set atm, i guess a plain sudo call would work as well until we dont have that setup anymore
[15:26] <tedg> davmor2, You might have to play some of ogra_'s webapp games :-)
[15:26] <ogra_> or use a device with less ram :)
[15:26] <ogra_> like a non-mako ;)
[15:26] <davmor2> right lots of apps and webapps open then
[15:27] <tedg> ogra_, That's just crazy talk! ;-)
[15:27] <ogra_> 6+ webapps are enough for me to make the first ones getting restarted
[15:27] <brendand> ogra_, ok. will we eventually have a password?
[15:27] <davmor2> ogra_: no the ppa is installed on my mako :P
[15:27] <davmor2> ogra_: I'll just open more apps
[15:27] <ogra_> brendand, yes and no :)
[15:28] <mterry> Saviq, OK..  So this unity8-dash issue could be explained by unity8  being borked.  If it's not properly responding on its socket, the dash would give that same error...
[15:28] <ogra_> davmor2, right, i think my mako starts with around 10-15 apps
[15:28] <mterry> Saviq, meaning all signs would point to unity8 being messed up somehow.  Not sure how though.  it's log is clean
[15:28] <ogra_> brendand, we will ship completely without password, but you wont be able to enable dev-mode without setting one
[15:28] <brendand> ogra_, how will that impact ci?
[15:29] <Saviq> mterry, weeelll... and then ProcEnviron...
[15:29] <brendand> ogra_, so i'll have to update the test some point in the near future?
[15:29] <mterry> Saviq, I was talking to jodh about it.  He reminded me that apport strips ProcEnviron for security reasons
[15:29] <ogra_> brendand, well, as i told you this morning, i think plars has a blanket sudoers file he puts in place
[15:29] <Saviq> mterry, oh ok
[15:30] <mterry> Saviq, so we are probably setting it up correctly and it just can't talk to unity8
[15:30] <mterry> jibel, you said you could interact with panel indicators?
[15:30] <plars> ogra_: no, it doesn't run the autopilot tests under sudo. We just use phablet-test-run for running the autopilot tests
[15:30] <ogra_> brendand, so during smoke you might be able to run everything with NOPASSWD
[15:31] <ogra_> plars, right, but you use a NOPASSWD sudoers for bits needing root
[15:31] <plars> ogra_: brendand: and phablet-test-run runs things as the phablet user. afaik, running autopilot tests under root just doesn't work. Nor would it be good since that's not how the user is going to run them
[15:32] <brendand> plars, we don't want the test to run as root, just specific commands that we specify sudo for
[15:32] <ogra_> plars, right, we dont plan anything like that
[15:33] <plars> brendand: ah, I misunderstood then. Yes, you could do that
[15:33] <plars> I don't think I actually have that getting updated yet though
[15:35] <davmor2> ogra_, Saviq: hmmm okay I opened lots of apps no the scope is dead
[15:35] <plars> brendand: did you already make this change to the camera-app test?
[15:35] <Saviq> davmor2, "the scope"?
[15:36] <davmor2> Saviq: the apps scope does nothing
[15:37] <Saviq> davmor2, sounds like 1295623
[15:37] <Saviq> bug #1295623
[15:37] <brendand> plars, no - i need some code from tvoss and ogra_ to land first
[15:37] <Saviq> davmor2, or do other apps work?
[15:37] <charles> jdstrand, sorry for disappearing mid-discussion, I got called away :)
[15:37] <Saviq> davmor2, can you launch apps from launcher still?
[15:37] <brendand> plars, but then i will need to add some calls to commands requiring sudo in the camera-app tests
[15:37] <charles> jdstrand, I agree, it sounds like there would be no special requirement for this
[15:37] <Saviq> davmor2, is it maybe being apported?
[15:37] <plars> brendand: ok, tell me when you are going to do it, and I'll make sure that I've landed the bits on the ci side to give you sudoers permission
[15:37] <charles> since only push and indicator-datetime would be calling it
[15:39] <davmor2> Saviq: yes I can open apps from the launcher, yes other apps work, I don't see anything apporting
[15:40] <ogra_> brendand, the lxc-android-config change landed already
[15:40] <davmor2> Saviq: root@ubuntu-phablet:/var/crash# ps aux | grep apport
[15:40] <davmor2> root     13066  0.0  0.0   4776   644 pts/58   S+   15:40   0:00 grep --color=auto apport
[15:40] <brendand> ogra_, i thought so, thanks
[15:40] <Saviq> davmor2, how about | grep unity8-dash, is it suspended maybe?
[15:41] <brendand> ogra_, and i don't necessarily need tvoss 's change either so i'll just go ahead and implement this
[15:41] <ogra_> ++
[15:41] <davmor2> Saviq: root@ubuntu-phablet:/var/crash# ps aux | grep unity8-dash
[15:41] <davmor2> phablet   2599  1.9  7.8 447824 147672 ?       Ssl  13:52   2:09 unity8-dash --desktop_file_hint=/usr/share/applications/unity8-dash.desktop
[15:41] <davmor2> root     13264  1.0  0.0   4780   644 pts/58   S+   15:41   0:00 grep --color=auto unity8-dash
[15:42] <Saviq> davmor2, so not suspended, just hanging
[15:42] <Saviq> davmor2, please SIGSEGV it
[15:42] <Saviq> davmor2, make sure there's no .crash for it first
[15:42] <Saviq> davmor2, and apport-bug it to launchpad after that
[15:43] <brendand> well actually, it would make the test cleaner (one service to restart instead of two)
[15:44] <nik90> Saviq: I think I have the same issue
[15:44] <nik90> davmor2: did unity8 just freeze up on you?
[15:45] <nik90> davmor2: everything else works like app launching, switching , app themselves etc
[15:45] <brendand> tvoss, with you branch, if i restart ubuntu-location-service with sudo, will ubuntu-location-service-trust-stored also be restarted with sudo?
[15:45] <davmor2> nik90: only the dash everything else works
[15:45] <brendand> tvoss, because i thought that would stop it from working
[15:45] <tvoss> brendand, the trust-stored lives in the user session
[15:45] <nik90> davmor2: yup that's the issue I am facing
[15:45] <tvoss> brendand, so no sudo
[15:51] <mterry> Saviq, jibel: choosing french seems to kill unity8-dash (though I don't see the unity8-side problems you do)
[15:56] <jdstrand> charles: ok, cool. if apps end up needing direct access or can obtain access through a non-trusted helper, then feel free to ping me or another member of the security
[15:58] <sergiusens> rsalveti: robru can I get a silo for line 36?
[16:00] <Saviq> mterry, I KNEW IT
[16:00] <Saviq> mterry, it's the french!
[16:00] <Saviq> mterry, wonder if it's specific to french or just any language will do ;)
[16:01] <Saviq> mterry, sounds like maybe .pam_environment isn't created properly / picked up properly when created by the wizard?
[16:01] <sil2100> ;)
[16:01] <ogra_> Saviq, thanks ... nobody belives me if i claim that :P
[16:02] <jibel> mterry, Polish must kill it too. I suppose that's the language zyga selected.
[16:02] <Saviq> jibel, imagine so
[16:03] <Saviq> jibel, touché, too!
[16:03] <sil2100> ogra_: boing
[16:03] <sil2100> davmor2, popey: boing
[16:03] <Saviq> sil2100, you drank too much today
[16:03] <Saviq> sil2100, your ping sounds weird
[16:03] <ogra_> sil2100, running over with another meeting, i'll come over soon
[16:03] <sil2100> uh oh!
[16:03] <mterry> so presumably any change kills it -- probably some side effect of what u-s-s does when setting language
[16:05] <ogra_> mterry, when i installed the wizard was completely broken ... (you fixed it the next day) so i tried to just use settings to set the language and timezone ... u-s-s never created that file
[16:05] <Laney> u-s-s does not create that file
[16:06] <ogra_> Laney, accountservice should though
[16:06] <Laney> yep
[16:06] <ogra_> Laney, and u-s-s talks to it
[16:06] <Laney> doesn't mean u-s-s creates it
[16:06] <Laney> there was a polkit problem that mterry uploaded a workaround for
[16:06] <ogra_> well, my process of selecting a language in u-s-s never created it :)
[16:11] <robru> sergiusens, done
[16:13] <davmor2> sil2100: sorry badly timed loo trip and now I can't get on the ho
[16:14] <mterry> Saviq, what's the story with mir_socket_trusted vs mir_socket?
[16:15] <Saviq> dednick, ↑
[16:16] <Saviq> mterry, the trusted one is for trusted helpers
[16:16] <Saviq> AFAIK
[16:16] <mterry> Saviq, are they both supposed to exist?  In my reproduction of this problem, /run/user/32011/mir_socket doesn't exist, which is what we point unity8-dash at
[16:17] <mterry> but mir_socket_trusted does exist
[16:19] <dednick> mterry: the trusted socket is a preauthenticated connection.
[16:19] <dednick> mterry: they are both supposed to exist.
[16:20] <mterry> dednick, hrm
[16:20] <mterry> dednick, do you know why one might not?
[16:20] <mterry> I guess that might be a Mir question
[16:20] <Saviq> mterry, yes, they both need to exist
[16:21] <Saviq> mterry, only reason why one of them would not (that I can think of)
[16:21] <Saviq> mterry, is that...
[16:21] <dednick> mterry: yeah. probably. the mir_socket is created by default by the mir options as far as i know
[16:21] <Saviq> no, I can't think of that
[16:21] <Saviq> dednick, well, it's pointed to by MIR_HOST_SERVER_FILE or so
[16:21] <Saviq> dednick, but if that wouldn't be set
[16:21] <Saviq> then the trusted one wouldn't be there
[16:21] <mterry> dednick, what determines where mir_socket_trusted goes?
[16:21] <mterry> dednick, does it base off of where mir_socket should go?
[16:21] <Saviq> mterry, I'd say it does
[16:22] <dednick> Saviq: hm. i think the trusted one is explicitly set in the unity8 upstart conf
[16:22] <Saviq> mterry, only thing that "enables" it is the _TRUSTED_NAME=1
[16:22] <Saviq> dednick, naah, it's just enabled no?
[16:22] <Saviq> https://code.launchpad.net/~nick-dedekind/unity8/trusted-socket.prompt-file/+merge/227051 ?
[16:23] <Saviq> the PROMPT_FILE thing?
[16:23] <Saviq> why is this PROMPT and not TRUSTED btw :|
[16:24] <mterry> Saviq, dednick: yes, confirmed in Mir code it just adds a suffix
[16:24] <mterry> So both should be there or neither...
[16:24] <mterry> This needs Mir folks now, moving to #ubuntu-mir
[16:24] <Saviq> PING
[16:35] <davmor2> sil2100: I can confirm the video freezing issue
[16:35] <plars> sil2100: well, gallery app ran at least, and it looks terrible: http://ci.ubuntu.com/smokeng/utopic/touch/mako/187:20140813.1:20140811.1/9645/
[16:36] <sil2100> davmor2: ouch, is it easy to reproduce?
[16:36] <plars> I'll try running it locally
[16:37] <robru> sergiusens, sorry I didn't understand. are you talking about the testplan link in the spreadsheet? nothing to do about that. if the cell contains only a URL, google will linkify it, if the cell contains more than just one single url (two urls or a url and some text) then it won't linkify it.
[16:37] <davmor2> sil2100: yes play a video, works fine after the first one though
[16:46] <davmor2> ohhhhhh jhodapp I just played a 4:53 video from the youtube scope and it played without exiting,  trying a much longer one now to see if that plays
[16:48] <ogra_> davmor2, youtube doesnt use media-hub
[16:49] <ogra_> so that wont help ... you need to test actual videos
[16:49] <davmor2> ogra_: no but it stays open now and it didn't use to
[16:49] <ogra_> right, but thats the bultin player of oxide ... usin software rendering etc
[16:50] <ogra_> has nothing to do with the media-player or even media-hub
[16:50] <davmor2> ogra_: such a spoilsport ;)
[16:50]  * ogra_ will leave that to jhodapp 
[16:51] <jhodapp> ogra_, yes that's right
[16:51] <jhodapp> media-hub integration is in the works by the web team
[16:52] <ogra_> right
[16:54] <sil2100> davmor2: so, as our QA expert, do you nominate it as a blocker? ;)
[16:54] <davmor2> sil2100: Yes it is obviously broken and jhodapp hasn't got nearly enough work to do ;)
[16:56] <jhodapp> davmor2, very funny! :)
[16:57] <kenvandine> jhodapp, you eat bugs for breakfast!
[16:57] <jhodapp> kenvandine, I do, they go great with Cheerios! :)
[16:57] <kenvandine> :)
[16:57] <davmor2> jhodapp: on a fresh reboot play a video you'll see what we mean
[16:58] <jhodapp> davmor2, play a video where?
[16:58] <davmor2> jhodapp: local video on a device
[16:58] <jhodapp> davmor2, and then what happens?
[16:58] <davmor2> jhodapp: about 30seconds in it hangs
[16:59] <jhodapp> davmor2, totally normal...that bug has been around since we switched to Qt 5.2
[17:01] <davmor2> jhodapp: you sure?  I'd not seen it until recent images.  Maybe I was just lucky
[17:02] <davmor2> tvoss, tedg: so I have a bunch of apps and webapps and browser open and I'm switching between them quite happily
[17:02] <jhodapp> davmor2, positive, it's possible the timing of it happening has changed, but its always been random for me since this first started happening
[17:03] <davmor2> ah that might be why then,  it seems to happen on the first video after a reboot now fairly reliably for jibel popey and I
[17:05] <jhodapp> davmor2, yes...the timing has changed over the past few months too...like I said it's random and has always been there
[17:05] <jhodapp> davmor2, since Qt 5.2
[17:06] <davmor2> jhodapp: and you haven't fixed it yet?  Shame on you ;)
[17:06] <ogra_> yeah, bad guy ... hasnt re-written Qt 5.2 yet :P
[17:06] <davmor2> hahaha
[17:07] <jhodapp> davmor2, :)
[17:08] <davmor2> ogra_: ouch yes there is
[17:08] <davmor2> wrong channel
[17:08] <ogra_> heh
[17:11] <jhodapp> davmor2, btw, my plan is to work to fix the video issues once I fix the mp3 seeking/memory eating issue
[17:13] <davmor2> jhodapp: then stop hanging around here chatting and start fixin' already ;)  good luck by the way I think you might need it
[17:13] <jhodapp> davmor2, haha, thanks!
[17:13] <jhodapp> :)
[17:14] <davmor2> sil2100: so according to jhodapp that video issue has been around for a while, so even though it should be a blocker if it was in the last promoted then it isn't right? it's just an annoying one :)
[17:15] <jhodapp> davmor2, I was surprised that it wasn't a blocker when it first popped up when Qt 5.2 landed
[17:16] <jhodapp> davmor2, that and image 87 introduced a lower video framerate that should have been a blocker
[17:16] <sil2100> Those were times when the rules were a bit different ;)
[17:16] <jhodapp> apparently :)
[17:16] <sil2100> jhodapp, davmor2: but was that so easily reproducible before as well?
[17:17] <jhodapp> sil2100, yes, you just had to possibly play a bit longer
[17:17] <sil2100> Ok, then I'll remove it from blockers and leave it in the issues list
[17:17] <jhodapp> sil2100, back during the Malta sprint, it would take around 15 mins of playback to get there
[17:17] <davmor2> sil2100: apparently it wasn't as noticeable as it happened randomly now it is happen more reliably
[17:18] <ogra_> so we can claim 187 got mmore reliable than former images :)
[17:18] <ogra_> awesome :)
[17:18] <sil2100> I'm not sure if I should be happy about that or not ;)
[17:18] <jhodapp> davmor2, it has to do with graphic buffer allocation, so perhaps the new Mir 0.6.0 landing influenced the timing (just a wild guess)
[17:19] <davmor2> sil2100: ^
[17:19] <davmor2> jhodapp: okay so it's all kgunn's fault then :)
[17:19] <davmor2> anyway teatime :)
[17:19] <jhodapp> :)
[17:20] <ogra_> davmor2, yeah, kgunn also grew our images by 4MB
[17:20] <ogra_> for nothing !
[17:29] <sil2100> ;)
[17:30] <sergiusens> robru: I'm talking about, if the trunk to land is media-hub; have the spreadsheet or  dashboard check if https://wiki.ubuntu.com/Process/Merges/TestPlans/media-hub exists and add it there so we don't have to copy paste all the time :)
[17:31] <robru> sergiusens, hmm
[17:32] <robru> sergiusens, unfortunately i don't have any way to check that... you can't do cross-domain HTTP requests in JS.
[17:32] <robru> sergiusens, could just make the link blindly...
[17:32] <sergiusens> robru: maybe just create the linnk and when people click on it; it would prove a missing testplan?
[17:33] <sergiusens> yeah, blindly
[17:33] <robru> sergiusens, the question then is, how can I parse the 'root' from an MP list that has multiple projects in it?
[17:34] <sil2100> Ok, need to EOD earlier today, see you tomorrow everyone o/
[17:34] <sergiusens> robru: one for each? Isn't the canonical form lp:[team-name]/[project-name]/[branch-name] ?
[17:34] <sergiusens> robru: the logic is already there for locking silos, right?
[17:35] <robru> sergiusens, no... "the logic" isn't "there". locking silos happens in a python script that runs in jenkins. no way to communicate that into the spreadsheet. what you want can only be done either by JS or by "spreadsheet formulas" that don't have access to that.
[17:36] <robru> sergiusens, but also this falls apart because there isn't a 1:1 relationship between "source package names" and "test plans"
[17:36] <sergiusens> robru: can't the python script be JSified?
[17:36] <sergiusens> robru: I know that's true for dialer-app and friends
[17:36] <robru> sergiusens, I... what? No.
[17:37] <sergiusens> robru: where it would be easy to setup a redirect
[17:37] <robru> sergiusens, I am not porting citrain to run inside of a google spreadsheet. You can not pay me enough to make that happen.
[17:37] <sergiusens> robru: lol; just the logic for creating the links, not the locking itself!
[17:38] <sergiusens> robru: I wish to edit the spreadsheet the least I can; reason for which I seldom write where the testplan is and just hope people can infer where it is after following qa policies
[17:38] <sergiusens> qa policies of where they should be, that is
[17:40] <robru> sergiusens, right, the problem isn't parsing the source package name from the URL, that's a trivial regex. The problem is looking at a spreadsheet cell that contains a dozen URLs with half a dozen different source package names and knowing which one is the one with the test plan. if the result is more than one URL, then google won't linkify it
[17:41] <sergiusens> robru: true; if the link is just in the dashboard it's good enough for me; anyways, just a thought, not a req :-)
[17:42] <sergiusens> robru: wrt to the sheet, we already have the link problem with testplans anyways
[17:42] <sergiusens> Ursinha: ^ for the airline perhaps :-)
[17:43] <robru> sergiusens, not to mention https://wiki.ubuntu.com/Process/Merges/TestPlan/mtp vs https://wiki.ubuntu.com/Process/Merges/TestPlans/ciborium (note how one is TestPlan and one is TestPlans). I really don't think there's a programmatic way of determining this.
[17:44] <sergiusens> robru: the ones without the s are wrong actually
[17:44] <sergiusens> robru: I checked the original email wrt to location
[17:45] <robru> sergiusens, there's more without than with!
[17:45]  * sergiusens sighs
[17:45] <robru> sergiusens, there would need to be a massive wiki cleanup effort before this would even be slightly feasible.
[17:47] <robru> sergiusens, if such a wiki cleanup were to happen, I suppose I could add a 'testplan' link after every source package name on the whole dashboard, and then it would just be up to you to guess which one was the one that had the test plan in it.
[17:48] <sergiusens> robru: it's already a pain to find manually too fwiw
[17:49] <robru> sergiusens, for example look at row 26. the test plan link is for unity8, but that silo contains unity8, unity-scope-click, unity-scope-scopes, etc... I have no way of parsing 'unity-scope-scopes' and inferring that that should link to the unity8 test plan, without keeping some kind of giant list stored somewhere.
[17:49] <sergiusens> robru: yeah; it would be nice to have a master document that links everything together
[17:49] <sergiusens> a launchpad entry perhaps :-)
[17:50] <robru> heh
[17:53] <Ursinha> sergiusens: noted :)
[17:54] <sergiusens> Ursinha: so in summary, central place to match a testplan to a project (launchpad I would guess) and making it easy from whatever dashboard to access them from a silo (or whatever the new name is)
[17:55] <robru> Ursinha, make all my problems go away! Ursinha !!!
[17:55] <robru> ;-)
[17:58] <Ursinha> lol
[18:07] <plars> brendand: the pieces I needed to land for sudo support are in now
[19:07] <davmor2> Apparently having a concert that is 2hourish long playing on flo from youtube makes the device VERY!!!!! Hot.  Also it eats about 75% of the battery too
[19:08] <davmor2> but the on a plus side the sound and video were amazing :)
[19:10] <davmor2> Chipaca: did you change your twitter password after releasing that video?
[19:38] <thostr_> fginther: ping
[19:42] <fginther> thostr_, one moment, in a call
[19:42] <thostr_> fginther: ok
[19:45] <asac> anyone knows about silo 4 case?
[19:46] <asac> robru: ?
[19:48] <fginther> thostr_, I'm free now
[19:48] <thostr_> fginther: cool
[19:48] <thostr_> not sure how much asac already told you
[19:49] <thostr_> but we experience massive problems with jenkins when running tests for scopes
[19:49] <thostr_> problem is when jenkins is heavily loaded (>10)
[19:49] <thostr_> then scope framework timeouts kick in which eventually fail our tests
[19:50] <thostr_> (when load is > than 10 then even a simple exec takes like 4 secs)
[19:50] <thostr_> so, would it be possible to limit the number of jobs jenkins runs in parallel?
[19:50] <bfiller> robru: I need a silo for line 35 please
[19:51] <fginther> thostr_, yes, it might be possible to do that. asac did mention there was a problem here, but it's good to have more specifics
[19:51] <thostr_> fginther: could you adapt that and we do a test run tomorrow?
[19:51] <fginther> thostr_, I can understand that a higher loaded system might trigger failures in tests with time limits
[19:51] <thostr_> yes, everthing just works fine when the load is < 8
[19:52] <thostr_> but with the current high load we cannot land anything as our tests fail...
[19:52] <fginther> thostr_, well, the easiest test would be to limit the number of parallel execution, that's pretty easy, but might have some other consequences
[19:53] <thostr_> fginther: let's give it a try
[19:53] <fginther> thostr_, I'll look into this and try out 8,
[19:53] <thostr_> to much parallelism also slows down things because of too many context switches...
[19:53] <fginther> we may need to adjust and try some other tactics though.
[19:53] <thostr_> right
[19:54] <thostr_> but can we try to limit the parallel execution for tomorrow just to see the impact?
[19:54] <pmcgowan> bfiller, renatu are the latest silo 4 failures different?
[19:55] <fginther> thostr_, can you point me to a failed build, to give us something to monitor?
[19:55] <asac> remember that jenkins is a beast; it just gets slower and stuff
[19:55] <renatu> pmcgowan, the last build was 5 hours ago: 1: LLVM ERROR: Cannot select: intrinsic %llvm.x86.sse41.pblendvb
[19:56] <pmcgowan> renatu, I now see 1: LLVM ERROR: Do not know how to split the result of this operator!
[19:56] <bfiller> pmcgowan: not sure, we get a specific LLVM error, search for llvm in this log: https://launchpadlibrarian.net/182181736/buildlog_ubuntu-utopic-i386.messaging-app_0.1%2B14.10.20140813-0ubuntu1_FAILEDTOBUILD.txt.gz
[19:56] <renatu> pmcgowan, I saw that too in previous build
[19:56] <fginther> thostr_, FTR, the x86 builds have 32 cpu threads and 64GB or ram, it's possible the bottleneck is elsewhere
[19:56] <asac> pmcgowan: i think i still see the messaging-app failure with LLVM in the error
[19:56] <asac> guess dialer-app is not getting there right now
[19:57] <thostr_> fginther: well, but it's still slow as hell
[19:57] <pmcgowan> renatu, so who is looking into it?
[19:57] <fginther> thostr_, I won't disagree with that
[19:57] <bfiller> dialer-app failure is something different, boiko is looking at that one
[19:57] <thostr_> fginther: we investigated for quite a long time and michi figured that the load is the dealbreaker
[19:57] <thostr_> when jenkins is not that loaded (<10) then everything works fine
[19:57] <asac> fginther: do we have good Xmx Xms settings for the jenkins VM?
[19:58] <fginther> asac, I suspect we're just using the defaults
[19:59] <tvoss> asac, pmcgowan might well be something in qml
[19:59] <asac> bfiller: when did you last successfully land messaging-app?
[19:59] <thostr_> fginther: while we're on it. we're also seeing jenkins failure quite often lately, the kind of http://s-jenkins.ubuntu-ci:8080/job/unity-scopes-api-devel-utopic-armhf-autolanding/246/console
[19:59] <asac> see a llvm dangling in proposed since Jul 25
[20:00] <asac> fginther: yeah, those should be tuned to make use of the mem we have avail
[20:00] <asac> dunno what the defaults are
[20:00] <asac> if you have the package those are in /etc/defaults/jenkins or so
[20:00] <bfiller> asac: let me check log
[20:01] <asac> tvoss: is qml doing LLVM stuff?
[20:01] <bfiller> asac: 2014-08-06
[20:01] <tvoss> asac, might be, might also be a shader somewhere
[20:01] <pmcgowan> tvoss, you mean the app could trigger that failure?
[20:02] <tvoss> pmcgowan, well, if llvm is invoked on the code: sure
[20:02] <asac> bfiller: ok, then its unlikely that its caused by the "new" llvm
[20:02] <asac> (i guess)
[20:02] <tvoss> asac, it still might be caused by a new llvm
[20:02] <asac> let me see if the same version got pulled in for that build
[20:02] <asac> tvoss: the new llvm is in proposed since jul 25
[20:02] <tvoss> asac, hmmm ...
[20:02] <asac> nothing changed since
[20:02] <asac> at least https://launchpad.net/ubuntu/+source/llvm-toolchain-snapshot
[20:03] <pmcgowan> fginther, did jibel explain the issue we had last week with the otto job not doing dist-upgrade before building?
[20:04] <tvoss> bfiller, so the tests are run under xfvb, with full UI, correct? that implies that we are using a mesa-software-based gl(es) impl during hte tests
[20:04] <tvoss> and that beast is likely using llvm somewhere
[20:04] <fginther> thostr_, that one appears to be caused by a jenkins bug. I've disabled the node until we can fix it so as not to impact future builds
[20:04] <tvoss> asac, ^
[20:05] <asac> tvoss: is that new?
[20:05] <fginther> pmcgowan, yes, I think I have that solved now. We've been running with an updated version for a little over a day now.
[20:05] <bfiller> tvoss: yes I believe so, renatu can you verify that is correct?
[20:05] <pmcgowan> fginther, excellent
[20:05] <tvoss> asac, well, we should check on xvfb/mesa landings
[20:05] <fginther> pmcgowan, I wanted to talk to you and get a failure case to retry once I caught my breath
[20:05] <pmcgowan> fginther, ok
[20:06] <pmcgowan> tvoss, the test is message bubble so UI test fer sure
[20:06] <tvoss> pmcgowan, yup, and I see xfvb in there
[20:06] <tvoss> xvfb, sorry
[20:07] <thostr_> fginther: ok @ jenkins bug.
[20:07] <thostr_> fginther: can you drop me a line when you adjusted the jenkins vm settings?
[20:07] <kenvandine> seb128 had told me earlier that someone was looking into this llvm thing, it was breaking autopackage tests blocking migrations from proposed to release
[20:07] <dbarth> hiya
[20:08] <fginther> thostr_, I've already adjust the executors down to 8
[20:08] <dbarth> fginther: hi, could i get a silo for line 32?
[20:09] <fginther> trainguards, can you assist dbarth ^ ?
[20:13] <asac> tvoss: so found we indeed have a new llvm
[20:13] <asac> thats why -snapshot failed to upload on i386
[20:14] <tvoss> asac, aha
[20:14] <asac> the llvm we use is actually here: https://launchpad.net/ubuntu/+source/llvm-toolchain-3.5
[20:14] <asac> uploaded yesterday
[20:14] <thostr_> fginther: thanks
[20:30] <robru> infinity, hey, there's some trainy things to do. want me to walk you through them or is now a bad time?
[20:31] <infinity> robru: Not an ideal time. :/
[20:31] <mterry> trainguards: I have a silo I'd like assigned, but the timing of the silo has to be synced with a package that I need to upload directly to the archive.  How best to coordinate this?
[20:31] <robru> infinity, no worries, I can handle it, I'll try you again later
[20:32] <robru> mterry, can you not upload the package to the silo and then we can publish the silo all at once?
[20:32] <mterry> robru, I thought we didn't have upload rights to the silo PPAs?
[20:32] <robru> mterry, also, you know, make sure that one package has a versioned dep on the other, and then it'll wait in proposed until the other one shows up
[20:33] <robru> mterry, I think you might be able to as a core dev... I sure can do it but I have Special Train Powers.
[20:33] <mterry> robru, well this is livecd-rootfs and ubuntu-touch-session -- it's not so much that livecd-rootfs depends on the new version, but if either is used to build an image alone, chaos will happen
[20:33] <robru> mterry, there's a column right in the spreadsheet specifically for the case of source packages uploaded to the PPAs without an MP
[20:34] <robru> mterry, ok well there's an image build scheduled for ~5 hours from now. as long as they both get in within the next 5 hours... (or maybe wait 5 hours ;-)
[20:34] <mterry> robru, 5 hours seems like enough time...
[20:34] <mterry> robru, can I have a silo for line 38?
[20:35] <mterry> robru, and then maybe between the two of us we can figure out how to upload livecd-rootfs to the silo
[20:36] <robru> mterry, yeah, you got silo 17. just try dputting it (it's ready to go right now), if that fails just send it to me and I'll slam it in there
[20:38] <kdub> hey all, mir's last few runs of https://jenkins.qa.ubuntu.com/job/mir-mediumtests-utopic-touch/ have failed in setting up the device, could someone take a look?
[20:42] <mterry> robru, nope, I'm not a member of ci-train-ppa-service
[20:42] <robru> mterry, ok, can you push a tarball somewhere? I'll upload it.
[20:42] <mterry> robru, this is the debdiff on top of current livecd-rootfs, is that good enough?  http://paste.ubuntu.com/8039296/
[20:43] <dbarth> robru: hi, oed'ing here, but can you see with alexabreu for the silo request on line 40; thanks
[20:43] <robru> mterry, ehhhh, it's easier for me if I just have a tarball or a branch, I'm not very comfortable with the debdiff workflow
[20:43] <robru> dbarth, oh sure
[20:43] <robru> alexabreu, you around?
[20:43] <alexabreu> robru, yup
[20:44] <robru> alexabreu, ok. no free silos right now, but there's 4 that are in the process of freeing so i should be able to assign that shortly
[20:44] <alexabreu> robru, awesome
[20:46] <robru> alexabreu, just need the MP URL, looks like there's a bare branch in there right now. https://ci-train.ubuntu.com/job/prepare-silo/1373/console
[20:46] <mterry> robru, ok the three livecd-rootfs files in https://chinstrap.canonical.com/~mterry/
[20:47] <alexabreu> robru, updated
[20:47] <alexabreu> the stylesheet
[20:47] <robru> alexabreu, thanks
[20:47] <Chipaca> davmor2: it's funny that you assume that (a) my password was, actually, swordfish, and (b) that I don't have 2fa turned on in everything
[20:48] <robru> asac, sorry, was on lunch, just reading scrollback now. did you figure out silo 4? looks like it's building, not sure what's wrong.
[20:49] <asac> robru: yeah, for the messaging-app thingy, check out -devel backlog ongoing
[20:49] <asac> IRC
[20:50] <asac> guess not for you, except educating others that run into that issue
[21:19] <Saviq> davmor2, if around, do you remember when you had the dash locked up, any chance location would be requested? Like the weather channel scope for example?
[21:19] <Saviq> davmor2, trying to see if yours would be the same as bug #1356045
[21:48] <asac> robru: hey
[21:48] <asac> robru: so for silo 004 messaging app, we have fix uploaded
[21:48] <asac> 23:32 < asac> pmcgowan: https://launchpad.net/ubuntu/+source/mesa/10.2.5-1ubuntu2
[21:48] <asac> robru: if you see that build hitting archive, could you maybe help bfiller and retry his build in silo 004?
[21:48] <robru> asac, sure
[21:49] <asac> robru: think as soon as its in proposed should be kind of enough if we build against propsed
[21:49] <asac> thanks
[21:49]  * asac goes out for dinner
[22:37] <robru> asac, rebuilding silo 4
[22:41] <Wellark> ** indicator-network crashing during dialer-app and default tests on
[22:41] <Wellark> smoketesting
[22:41] <Wellark> https://bugs.launchpad.net/bugs/1355130
[22:41] <Wellark> [Time counter 2/7]
[22:41] <Wellark> what happens if the counter hits 7 ?
[22:43] <Saviq> trainguards, silo for line 37 please?
[22:43] <Saviq> Wellark, it won't!
[22:44] <Saviq> trainguards, discussed settings conflict with silo 16, they will rebuild tomorrow
[22:46] <robru> Saviq, you got silo 5
[22:46] <robru> gotta run, bbl
[22:46] <Saviq> thanks
[22:46] <Wellark> Saviq: well, the bug was filed with "Low" importance
[22:47] <Wellark> Saviq: and guess how many Critical, High and Medium bugs I have before looking into Low..
[22:47] <Saviq> Wellark, 2?
[22:47] <Wellark> Saviq: <3
[22:47] <Saviq> did I win?
[22:49] <Wellark> Saviq: I will give you a "special price" next time we meet
[23:24] <asac> robru: thx a bunch! seems that silo is now green wrt builds \o/