[01:59] <fginther> kgunn, pong
[02:12] <kgunn> fginther: hey man...sorry to bug you...just wondering about the ci run on this one
[02:12] <kgunn> https://code.launchpad.net/~mterry/unity8/load-testability/+merge/188064
[02:13] <kgunn> it looks like its failling to connect to local host ?
[02:13] <kgunn> or maybe i dont understand the output
[02:14] <kgunn> or is it b/c the autopilot tests fail...which ironically is why this mp is being approved to go thru
[02:15] <fginther> kgunn, this one was human error on my part. I had updated the unity8 jobs to use the old VM test runner since the otto based one was failing every build. I missed an update of the internal test name
[02:15] <kgunn> fginther: hey no prob....it happens
[02:16] <fginther> kgunn, the runs are wired back correctly using the otto runner now. Saviq was able to identify the issue
[03:18] <plars> doanac, psivaa: heads up, I'm regenerating all the jobs, this should bring in ui-toolkit, sergiusens click package check, and eventstat
[03:19] <sergiusens> nice
[03:19] <plars> sergiusens: this isn't full click testing support, this is just the thing you gave me back at the sprint
[03:44] <sergiusens> plars, yup, I remember
[05:47] <didrocks> Mirv: hey! I don't see a lot that entered yesterday, not sure what difficulties had robru and sil2100, are you continuing from there?
[05:47] <didrocks> Mirv: sdk is the latest one, not for that imag please
[05:51] <jibel> didrocks, it 20131001.3 going to be next current or there is another build on the road?
[05:51] <jibel> *is
[05:52] <didrocks> jibel: image 75 should be the next current. We need to investigate on the mediaplayer-app failure though
[05:52] <jibel> didrocks, thanks, I'll start working on this image
[05:52] <didrocks> thanks :)
[05:54] <Mirv> didrocks: yes, I'm continuing. robru seemed to land stuff, sil2100 not so. I'm just about to publish libusermetrics - it does not fix media player app failures, but it's not worse either so I think it should be ok to land?
[05:55] <didrocks> yeah ;)
[05:55] <didrocks> no color automated on the spreadsheet, I read too fast
[05:55] <didrocks> Mirv: +1 on usermetrics
[05:56] <didrocks> Mirv: the failure due to usermetrics is fixed in the initramfs, it's just another protection
[05:56] <didrocks> I hope that robru tested AP with python-ubuntu-platform-api, but let's see
[05:57] <didrocks> jibel: as mediaplayer-app is crashing, maybe we won't promote image 75
[05:58] <Mirv> didrocks: +1 also on http://10.97.0.1:8080/view/cu2d/view/Saucy/view/Indicators/job/cu2d-indicators-saucy-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_libusermetrics_1.1.1+13.10.20131002-0ubuntu1.diff ?
[05:58] <jibel> didrocks, that's fine, I'm testing mir and the shell
[06:00] <didrocks> jibel: ok, if you install python-ubuntu-platform-api (now in archive) on top of it, it's supposed to have AP tests running
[06:00] <didrocks> jibel: can you keep me posted about this?
[06:01] <jibel> didrocks, okay, right after I reported crashes of maliit and hud
[06:01] <didrocks> Mirv: +1
[06:01] <didrocks> :)
[06:03] <jibel> aha, even hud apport hook is buggy
[06:03] <veebers> jibel, didrocks: Hi guys. I'm not sure if mir + autopilot will work at the moment, I see thomi filed this bug: https://bugs.launchpad.net/mir/+bug/1233944
[06:07] <didrocks> veebers: well, the Mir team promissed it was the case, but not sure if it was tested ;)
[06:07] <didrocks> veebers: we'll see
[06:07] <veebers> didrocks: sounds good :-)
[06:09] <didrocks> Mirv: oh, if you have to do a partial publication, I want to try an update to the jenkins job first
[06:09] <didrocks> Mirv: so, just ping me first please ;)
[06:17] <jibel> didrocks, is there any specific AP tests you'd like me to run?
[06:18] <didrocks> jibel: well, start with some apps one (not mediaplayer-app obviously as it crashes)
[06:18] <jibel> (not notes-app, it doesn't start with mir enabled)
[06:18] <didrocks> jibel: we were not able to start any AP tests before
[06:18] <didrocks> jibel: you do have python-ubuntu-platform-api from the archive installed?
[06:18] <jibel> didrocks, yes, that's the only package I upgraded.
[06:18] <didrocks> interesting…
[06:19] <jibel> I disabled mir again, and notes starts fine
[06:19] <didrocks> tell me for other apps if it's the case
[06:19]  * jibel wishes he had 2 devices
[06:22] <Mirv> didrocks: ok, the next one would be ubuntu-system-settings from settings, although I'm a bit struggling finding a way to test the Bluetooth part
[06:23] <didrocks> Mirv: ok, can I deploy my change on the settings stack meanwhile?
[06:23] <Mirv> does anyone happen to know how it should be possible to see non-headsets in ubuntu-system-settings Bluetooth?
[06:23] <Mirv> didrocks: feel free
[06:23] <didrocks> Mirv: if you are confident with the rest, seb128 tested it, so I trust him :)
[06:25] <Mirv> didrocks: ok, I'll poke at it for some time still, since I'm interested, but at least pairing with headset works (no PIN, or actually bluez guesses the PIN because it's always 0000 or 1234)
[06:25] <didrocks> Mirv: oh, bluez guess 0000 and 1234? Interesting ;)
[06:25] <didrocks> Mirv: ok, partial publication is ready in theory ;)
[06:26] <Mirv> didrocks: not generally, but it's some sort of "industry standard" that headsets have it 0000/1234
[06:26] <Mirv> didrocks: sounds nice, the theory part
[06:26] <thostr_> didrocks: do we have a new package by now?
[06:26] <didrocks> heh :)
[06:26] <thostr_> didrocks: or rather image
[06:26] <didrocks> thostr_: new package for what?
[06:26] <didrocks> thostr_: ah, not yet, mediaplayer-app failed
[06:26] <didrocks> (the tests)
[06:26] <didrocks> so there is image 75
[06:26] <didrocks> which is proposed
[06:26] <didrocks> but we can't promote it
[06:27] <didrocks> (mediaplayer-app crashes)
[06:27] <thostr_> didrocks: I see. I'll still give it a shot
[06:27] <didrocks> Mirv: so, normally if you force publication and set "ON_PACKAGES" (replacing FORCE_REBUILD) to filter what you want to publish, it should work
[06:28] <Mirv> didrocks: ok... I think it would be safest if I pick up the online accounts task as well, test that it doesn't blow and then try settings selectively...
[06:29] <didrocks> Mirv: if you can do that, that would be lovely :)
[06:32] <jibel> didrocks, I tried all the pre-installed application, only notes doesn't launch
[06:33] <jibel> I'm reporting a bug but I'd appreciate a confiramtion from some one else
[06:33] <didrocks> jibel: oh interesting
[06:33] <didrocks> jibel: ok doing
[06:33] <Mirv> didrocks: I'll try... any idea about "Try running ubuntu-system-settings-oneline-accounts AP tests", I don't find any autopilot package?
[06:33] <didrocks> jibel: can you try Unity8?
[06:33] <Mirv> I think I remember I tested it manually the last time too, adding some account etc
[06:33] <didrocks> jibel: also, getting the results (failures/pass) would be grand
[06:33] <Mirv> or is the AP tests the new thing, hmm..
[06:33] <didrocks> Mirv: hum, there was a new one, no?
[06:33] <didrocks> it's supposed to be the new one :)
[06:34] <Mirv> oh yes, they are
[06:34] <jibel> didrocks, ack
[06:34] <didrocks> \o/
[06:34] <Mirv> nice to see autopilot tests added
[06:34] <didrocks> jibel: I think that will help to take a decision seeing how many tests are failing with Mir (so basically running tests as the dashboard)
[06:34] <didrocks> jibel: I'm flashing here
[06:34] <didrocks> Mirv: isn't it? ;)
[06:35] <thostr_> don't we support --channel=daily-proposed any longer?
[06:36] <didrocks> thostr_: saucy-proposed
[06:36] <thostr_> ah, so the alias is not valid any more...
[06:37] <Mirv> didrocks: I think the online-accounts is twice in the landing plan? landing no:s 69 and 78
[06:38] <didrocks> Mirv: you're right, feel free to nuke one :)
[06:38] <Mirv> ok
[06:39] <didrocks> thanks!
[06:39] <didrocks> jibel: trying Mir now
[06:41] <jibel> bug 1234001
[06:42] <didrocks> jibel: unity8 is fine?
[06:43] <jibel> 1 minute please
[06:43] <Mirv> didrocks: can you check the error on the selective publishing at settings publish job?
[06:43]  * Mirv afk, brb
[06:43] <didrocks> Mirv: doing
[06:44] <didrocks> hum, didn't I pull on magners?
[06:44]  * didrocks recheck
[06:46] <didrocks> didn't pull strongly enough :)
[07:05] <jibel> didrocks, 24 failures with mir enabled. I re-running the tests without mir to make sure I ran them correctly
[07:05] <didrocks> jibel: ok ;)
[07:05] <didrocks> Mirv: ok, fixed, and published the settings. I'm trying another case right now (publishing ubuntu-system-settings-online-accounts)
[07:11] <didrocks> Mirv: ok, both scenarios work, I'm deploying it everywhere
[07:16] <didrocks> Mirv: everything is redeployed!
[07:18] <jibel> didrocks, unity8 test results: 24/24 tests failed with MIR http://paste.ubuntu.com/6182814/
[07:18] <didrocks> jibel: that's a nice score :)
[07:18] <jibel> without MIR *only* 10/24 failed
[07:18] <didrocks> urgh, really?
[07:18] <didrocks> this is not the results we have in the dashboard, isn't it?
[07:19] <jibel> with 20131001.3 and latest upa
[07:19] <didrocks> jibel: http://reports.qa.ubuntu.com/smokeng/saucy/touch_ro/4512/
[07:19] <didrocks> are they flacky tests?
[07:19] <didrocks> (without Mir)
[07:20] <Mirv> didrocks: ah, ok, thanks, I didn't check the channel :)
[07:20] <Mirv> didrocks: so good that there's a simpler way than ssh:ing and renaming
[07:20] <didrocks> Mirv: yeah, I'm sending instructions now ;)
[07:20] <sil2100> Hi guys
[07:20] <didrocks> Mirv: tell me if you see anything bad
[07:20] <didrocks> hey sil2100!
[07:21] <didrocks> how are you today?
[07:21] <sil2100> didrocks, Mirv: do you know if mediaplayer-app AP tests are ok on the device for you guys?
[07:21] <jibel> I'll try again without MIR and save the logs
[07:21] <didrocks> sil2100: they are real crashers, we can't publish because of that
[07:21] <Mirv> sil2100: not yet, but also not worse than on previous images
[07:21] <didrocks> sil2100: https://bugs.launchpad.net/ubuntu/+source/libhybris/+bug/1234007
[07:22] <sil2100> Since I was running them yesterday as part of the libusermetrics testing, but I was getting crashes in both the new and old versions in mediaplayer-app
[07:22] <didrocks> jibel: thanks! I'll succeed in testing this :)
[07:22] <didrocks> sil2100: yeah, ignore mediaplayer-app for now
[07:22] <sil2100> didrocks: good to know!
[07:23] <jibel> didrocks, which version of UPA do you want me to test, the one on the image or the archive?
[07:23] <Mirv> sil2100: I took some of the open tasks you had, so check the chart. hopefully you'll have time for some of the remaining stuff today since I'll be (mostly) away afternoon and then back in the evening
[07:24] <sil2100> Mirv: sure, I was testing stuff yesterday, but since 75 wasn't released yet - I didn't want to publish stuff before I got a clear ACK on those
[07:24] <didrocks> jibel: well, if you use surface flinger, that shouldn't impact. If it does, would be nice to know :)
[07:24] <Mirv> sil2100: right.. the chart didn't state if anything was done on them so I obviously tested from scratch
[07:25] <didrocks> sil2100: next time, please write that on the char ;)
[07:25] <didrocks> chart*
[07:26] <sil2100> Right... sorry about that, could have done that
[07:33] <didrocks> sil2100: do you use any special video for mediaplayer-app that you send through mtp?
[07:34] <sil2100> didrocks: not really, thought that the tests are self-contained and nothing special is needed
[07:35] <didrocks> sil2100: ah ok, I thought you try to dogfood a little bit as well
[07:37] <sil2100> didrocks: didn't push anything to the device, I was just using the mp4's that are on the nexus
[07:38] <didrocks> sil2100: hum, where are they? I don't see them in music or video
[07:38] <jibel> didrocks, I confirm the 10 failures without MIR, http://paste.ubuntu.com/6182868/
[07:38] <jibel> didrocks, do tests publish on the dashboard run in a special way?
[07:39] <didrocks> jibel: with phablet-test-run, but nothing else
[07:39] <didrocks> jibel: the only thing I can think is downgrading upa
[07:39] <didrocks> just in case it regressed the unity8 tests
[07:39] <jibel> ah, I ran directly on the device
[07:39] <didrocks> jibel: ah, try phablet-test-run -p <autopilot package> -n <AP test name>
[07:40] <jibel> yes but it shouldnt make a difference
[07:41] <didrocks> yep
[07:52] <didrocks> all unity8 are fine here, upgrading upa now
[07:52] <jibel> didrocks, <testsuite errors="1" failures="9" name="" tests="24" time="490.446">
[07:53] <jibel> didrocks, with p-t-r that is
[07:53] <didrocks> and latest upa, right?
[07:53] <jibel> didrocks, I'm reflashing the phone to use upa from the image
[07:53] <didrocks> yeah, let's see if we confirm that
[07:53] <didrocks> tests already running
[07:53] <didrocks> (here)
[07:54] <jibel> didrocks, with 1.1+13.10.20131001.1-0ubuntu1
[07:54] <jibel> didrocks, besides upa is there any other package I should have upgraded
[07:54] <jibel> ?
[07:55] <didrocks> jibel: no, it's the only one we are interested in right now
[07:55] <didrocks> (for Mir support)
[07:57] <ogra_> hmm, webbrowser-app could need a retry on mako for #75
[07:57]  * ogra_ is pretty sure the failure will go away 
[07:58] <Mirv> didrocks: I tend to test on the sintel clip extracted from demo-assets-videos .deb
[07:59] <ogra_> didrocks, http://people.canonical.com/~jhodapp/
[07:59] <didrocks> sil2100: back?
[07:59] <ogra_> there is sintel too :)
[08:00] <didrocks> ah, so you do install/grab it
[08:00] <ogra_> yeah
[08:00] <didrocks> there is nothing in the image by default?
[08:00] <didrocks> jibel: Ran 24 tests in 412.164s
[08:00] <ogra_> nope
[08:00] <Mirv> not anymore by default
[08:00] <didrocks> OK
[08:00] <didrocks> with latest UPA
[08:00] <didrocks> ok :)
[08:00] <didrocks> I wonder if sil2100 didn't flat his install for a long time :)
[08:00] <ogra_> i think design works on something with one video, one mp3 and a few wallpapers
[08:00] <ogra_> but not sure if that will make it in time
[08:01] <didrocks> ogra_: basically you download it, push to the video folder by mtp and it appears after a reboot on the video lens?
[08:01] <didrocks> ah, back with the example package!
[08:01] <ogra_> didrocks, hopefully without reboot :)
[08:01] <didrocks> IIRC, it doesn't work without the reboot, but let's see
[08:02] <ogra_> well, for the final image it should work without ... i wouldnt really like to reboot every time i put some data on my phone
[08:02] <didrocks> yeah ;)
[08:02] <didrocks> no arguement here :p
[08:02] <Mirv> I didn't have luck with the appearing part, so for mediaplayer I tested it from command line..
[08:02] <ogra_> especially in the light that we have no reboot UI support :)
[08:02]  * didrocks tries a reboot :)
[08:03]  * ogra_ would have tried a HUD search first ;)
[08:03] <Mirv> I think it's the mediascanner's responsibility to get it visible
[08:03] <ogra_> it is
[08:04] <didrocks> it's crazy that it's taking less time for me to dl the latest image than rebooting the phone
[08:04] <ogra_> haha, yeah
[08:04] <ogra_> i'll do some bootcharts before end of the week ...
[08:05] <ogra_> probably we can improve some low hanging fruit before release
[08:05] <didrocks> ogra_: hum
[08:05] <didrocks> is it working for you?
[08:05] <didrocks> like I see an empty thumbnail (normal as we don't have thumbnail support anymore)
[08:05] <didrocks> then I click on it
[08:06] <didrocks> it move to the center (but not full screen)
[08:06] <didrocks> and nothing
[08:06] <didrocks> keeping it pressing show the preview
[08:06] <ogra_> on mako or maguro ?
[08:06] <didrocks> and I can play the video
[08:06] <didrocks> mako
[08:07] <ogra_> well, there is bug 1234007
[08:07] <ogra_> fix is attached but waiting approval from jhodapp
[08:08] <didrocks> ogra_: yeah, but this is camera_app itself
[08:08] <ogra_> afaik thats also supposed to fix the AP errors
[08:08] <didrocks> ogra_: I know, I tracked that with ricardo this morning ;)
[08:08] <ogra_> err
[08:08] <ogra_> camera_app ?
[08:08] <didrocks> mediaplayer_app
[08:08] <didrocks> sorry ;)
[08:08] <Mirv> didrocks: I've the same, but I didn't figure out it still also works from the UI, so I played the clip from command line.
[08:08] <ogra_> ah :)
[08:09] <didrocks> Mirv: yeah, it works if you succeed to enter the preview mode and press play
[08:09] <didrocks> not really a stellar experience but good enough to test
[08:10] <ogra_> on maguro everything should work fine
[08:10]  * ogra_ is still flashing 
[08:11]  * StevenK calls the police to ogra_'s apartment
[08:11] <ogra_> *uiiiuuuu* *uiiiuuu* *uiiiuuu*
[08:22] <Mirv> hmm the quiet mid-stop cafe became extra noisy with lunch time, I guess I need to find a better place somewhere
[08:28] <didrocks> heh ;)
[08:38] <sil2100> Damn, not sure why but autopilot tests are hanging up for me
[08:55] <Mirv> sil2100: does something start on the phone side, or nothing seems to happen?
[08:55] <Mirv> sil2100: are you sure you're not running mir which had the AP problem?
[08:56] <sil2100> Mirv: for sure, I guess it happens like every 3-4 runs so it's not that bad
[08:56] <sil2100> Mirv: but it's hanging up and nothing is moving, the application stays frozen - probably not even an AP problem
[08:56] <sil2100> Maybe an overall touch problem
[09:07] <Mirv> sil2100: I tend to reboot a lot anyway when doing tests
[09:58] <didrocks> sil2100: everything's good? need newing?
[10:04] <sil2100> didrocks: all tested, one moment - btw. do you have issues with connecting to mangers today?
[10:05] <sil2100> didrocks: normally it took around a minute to connect, but now it's like forever
[10:05] <sil2100> Mirv: ^?
[10:08] <didrocks> sil2100: why do you need to ssh to it?
[10:08] <Mirv> sil2100: works for me. FYI I'm attending a couple of conference sessions right now, will work more afternoon your time.
[10:09] <didrocks> (yeah, same here, stalled to connect)
[10:09] <Mirv> right, ssh doesn't seem as good as web side
[10:09] <Mirv> sil2100: but with the partial release now supported you shouldn't need to
[10:10] <didrocks> yeah, hence my question :)
[10:11] <sil2100> Stone age from my side, didn't know it was tested already! But good - then just 'ON_PACKAGES' and force_publication, right?
[10:12] <sil2100> I think we need to update the flag descriptions on the head job a bit
[10:12] <didrocks> sil2100: you should have get an email from me :)
[10:13] <didrocks> the description was updated, wasn't it? "space separated list of project that will effect a rebuild or a publication
[10:13] <didrocks> "
[10:14] <sil2100> didrocks: yes, but FORCE_PUBLICATION has: "Force publication of all pending components for this stack"
[10:14] <sil2100> didrocks: should be "for all or the listed components" or something ;)
[10:14] <didrocks> sil2100: it's all but filtered ;)
[10:14] <didrocks> yeah
[10:14] <didrocks> feel free to do it
[10:14] <didrocks> and redeploy :p
[10:14] <sil2100> Nooo, so many jobs, I think it's awesome as it is... ;p
[10:14] <didrocks> sil2100: you didn't get my email then?
[10:15] <didrocks> sil2100: if you can test the command line tool in the next publication, I would be interested
[10:16] <sil2100> I got it, but I think my Thunderbird doesn't check for new e-mail until I don't switch between inboxes
[10:16] <sil2100> Which is probably wrong
[10:16] <sil2100> I'll test the tool
[10:17] <sil2100> didrocks: if a stack is on 'waitonstacks', will running publishing work for the old state?
[10:18] <didrocks> sil2100: yeah
[10:20] <sil2100> -P without -f is the "foo" trick for publishing? Like, ./cu2d-run -P stack_name ?
[10:21] <seb128> sil2100, right click on the tb box, you have a "when receiving new emails, always check that folder" box to tick
[10:27] <sil2100> didrocks: I see a strange problem, I guess not related to the latest changes even - if a stack is waiting on waitonstacks and we tell him 'do publishing without forcing', it will not do that then
[10:27] <sil2100> didrocks: since the second head job will start, second waitonstacks job will successfully finish, but the second head job will still wait for the first (valid) waitonstacks job to finish
[10:28] <sil2100> didrocks: so now there are 2 head jobs waiting on waitonstacks ;p
[10:28]  * sil2100 wonders if the same issue is when forcing stack publication or not
[10:28] <didrocks> sil2100: yeah, without force, it won't publish on waitonstacks automatically
[10:28] <didrocks> sil2100: forcing should work
[10:33] <sil2100> didrocks: cu2d-run works nicely in this case, although in the e-mail in the -P -f <list of packages> case you missed the stack name, so that it's -P -f <stack> <list of packages>, but that's obvious as it doesn't make sense otherwise ;)
[10:35] <sil2100> didrocks: pushed the onlinemusic scope and thumbnailer
[10:36] <didrocks> sil2100: in the email, I was just talking about the change in parameters, but yeah ;)
[10:36] <didrocks> sil2100: \o/
[10:56] <lool> didrocks: outside of music-app, which other coreapps AP tests were failing?
[10:56] <lool> didrocks: I'm joining a HO with coreapps folks in a few, might as well mention these
[10:57] <didrocks> lool: rssreader
[10:57] <didrocks> lool: calendar-app seems flacky as well
[10:57] <didrocks> lool: will be nice to refrain their landing btw
[10:58] <didrocks> lool: do you want me to join?
[10:59] <lool> didrocks: I think I can cover, will mention the landings too
[10:59] <didrocks> ok
[10:59] <didrocks> thanks
[10:59] <lool> chatting with dpm to see how we do this
[11:08] <vila> didrocks: we need some more info about that loop device issue you mentioned about pbuilder, at least whether you know the cases where pbuilder needs such a device. cowbuilder is a clear one but are there others ?)
[11:09] <didrocks> vila: I think only cowbuilder needs it, that was the trace you pointed at, right?
[11:11] <vila> didrocks: damn, where is is now that I need it
[11:12] <didrocks> vila: hidden from you ;)
[11:14] <vila> didrocks: got it: http://10.97.2.10:8080/job/gallery-app-saucy-i386-ci/352/consoleFull it's -ci job, so no cowbuilder used there
[11:15] <vila> didrocks: good
[11:15] <vila> didrocks: I'll keep the cowbuilder <-> loop device issue in the back of my mind but something else was going on there
[11:16] <vila> didrocks: thanks for confirming
[11:16] <didrocks> vila: yeah, this one is different, I saw it once IIRC on magners IIRC (and had to reboot the machine)
[11:28] <sil2100> didrocks: after pushing onlinemusic scope and thumbnailer, I don't see it neither on the queue nor in -proposed, am I unaware of something?
[11:30] <didrocks> sil2100: hum, are you sure the whitelist was refreshed on the server side?
[11:30]  * didrocks looks
[11:30] <sil2100> didrocks: I have no ways of checking that, but seb128 said it was ok
[11:30] <didrocks> seb128: you refrshed on snakefruit, right?
[11:30] <sil2100> Snakewhat?
[11:30] <sil2100> ;O
[11:31] <didrocks> sil2100: wasn't refreshed, so rejected…
[11:31] <sil2100> Names keep getting better
[11:31] <sil2100> seb128: ^ ?
[11:31] <sil2100> didrocks: is snakefruit different from lillypilly?
[11:31] <seb128> didrocks, I followed https://wiki.ubuntu.com/DailyRelease/FAQ#Adding.2BAC8-removing_components_to_a_stack
[11:31] <didrocks> sil2100: yeah, it moved
[11:31] <didrocks> seb128: needs refreshing, was about to do that the other day, but then, interruption…
[11:31] <seb128> didrocks, so no, I pulled on lillypilly
[11:32] <sil2100> I didn't know about the move as well, so I asked seb128 to do it on lilly as well;)
[11:32] <seb128> didrocks, would be good to rm that directory on lillypilly if it's not used there anymore
[11:32] <seb128> didrocks, I would have went "wait"
[11:32] <didrocks> done now
[11:32] <seb128> didrocks, thanks
[11:32] <seb128> didrocks, "done" includes the pull on baskedoffruit?
[11:32] <seb128> :p
[11:32] <didrocks> yeah, wiki updated and pulled :)
[11:32] <didrocks> so I have to resurrect the request
[11:33] <sil2100> didrocks: how should I push it to the queue again now?
[11:33] <seb128> didrocks, thanks
[11:33] <didrocks> sil2100: handling that :)
[11:34] <seb128> didrocks, https://wiki.ubuntu.com/DailyRelease/FAQ?action=diff&rev2=47&rev1=46 ;-)
[11:34] <sil2100> ;p
[11:35] <sil2100> seb128: shouldn't it be... basketoffriuit?!?!
[11:35] <seb128> sil2100, lol, I was trolling on the name ;-)
[11:35] <sil2100> ;D
[11:36] <didrocks> seb128: argh, ok, missed that one :p
[11:37] <didrocks> (done)
[11:38] <didrocks> sil2100: lucky you, copied at 13:37! ;)
[11:40] <cjwatson> seb128: um, what directory on lillypilly?  if /home/ubuntu-archive/anything, everyone's sudo access to ubuntu-archive@lillypilly was already supposed to be locked out to avoid confusion
[11:40] <cjwatson> That was part of the switchover
[11:40] <cjwatson> bah, that regressed
[11:40] <seb128> cjwatson, what I did is
[11:40] <seb128> ssh lillypilly.canonical.com
[11:40] <seb128> sudo -u ubuntu-archive -i
[11:41] <seb128> cd cu2d/cupstream2distro-config/
[11:41] <seb128> bzr pull
[11:41] <seb128> cjwatson, ^
[11:41] <didrocks> (confirmed, I can as well)
[11:41] <seb128> cjwatson, no error
[11:41] <cjwatson> Yeah, reported on #is
[11:42] <seb128> cjwatson, thanks
[11:42] <cjwatson> Anyway, use ubuntu-archive@snakefruit.  It's much faster :)
[11:44] <cjwatson> It hadn't occurred to me to grep the wiki
[11:45] <cjwatson> Cleaning up a few other references now
[11:46] <seb128> cjwatson, I had no idea we migrated to snakefruit (I might have read the mail and forgot about it in my after-holidays-backlog, if there was one)
[11:46] <seb128> well, now I know ;-)
[11:47] <bregma> the libunity version bump has descended the last several Unity7 daily builds into dependency hell...  there's nothing we can do on the code side to fix this, is anyone on the build side tracking the libunity bump consequences?
[11:47] <cjwatson> I thought I'd mailed everyone, but no matter ...
[11:48] <seb128> cjwatson, yeah, as said,  probably my fault, I tried to not spend too much time on emails backlog after my holidays, and I probably overlooked it/read quickly and didn't store the info
[11:49] <cjwatson> I'd also expected the sudo change to stick so that it wouldn't be a big deal if people didn't notice straight away, and it didn't occur to me that IS wouldn't put that change in puppet :-P
[11:49] <didrocks> well, at least, we discovered it, that's all what counts ;)
[11:51] <didrocks> sil2100: as your hands are a little bit more free now, can you look at what bregma's telling?
[11:52] <sil2100> didrocks: ok
[11:52] <sil2100> bregma: let me take a look
[11:54] <bregma> sil2100, thanks... the problem my not be related to the libunity bump after all, but it's still a dependency fail somehow
[11:54] <sil2100> bregma: do you mean the check job? Or is there a crash somewhere? Since I see that the cu2d build job needs updating indeed
[11:56] <bregma> sil2100, I'm looking at http://10.97.0.1:8080/job/autopilot-saucy-daily_release/2283/label=autopilot-intel/console
[11:57] <bregma> nvidia job is the same
[11:57] <sil2100> bregma: right! Merge coming
[11:58] <bregma> I want all the failures to be my fault... no wait...
[11:58] <sil2100> ;D
[12:03] <sil2100> I seem to have redeployed the stack some time ago without having the change merged in, so it got cleared out after subsequent redeployments
[12:03] <didrocks> sil2100: bad bad ;)
[12:03] <didrocks> ok, time for some exercise, be back in ~1h
[12:03] <sil2100> pff ;p Not the first time I did bad things! I'm bad to the bone :(
[12:04] <sil2100> didrocks, Mirv, seb128: https://code.launchpad.net/~sil2100/cupstream2distro-config/bump_libunity_unity/+merge/188822 <- anyone of you can take a peak and approve?
[12:04] <sil2100> *peek
[12:06] <didrocks> sil2100: approved
[12:06] <sil2100> didrocks: thanks! Have a nice exercise ;)
[12:07] <didrocks> thx!
[12:25] <lool> so qtpowerd is coming in later today
[12:25] <lool> with music-app changes
[12:28] <cjwatson> FYI there will be some hopefully brief buildd downtime in about an hour for code upgrades
[12:28] <cjwatson> Things look fairly quiet at the moment aside from the test rebuild
[12:32] <lool> ogra_: is the timezone selection from settings fixed in archive?
[12:32] <ogra_> yes
[12:33] <ogra_> with pittis last upload
[12:33] <lool> ogra_: but not in #75?
[12:33] <ogra_> oh, wait
[12:33] <lool> ogra_: is that systemd upload?
[12:33] <ogra_> no
[12:33] <ogra_> the additional initramfs-tools-ubuntu-touch one
[12:33] <ogra_> from today
[12:33] <ogra_> just strikes me, we need an android rebuild to pick it up
[12:34] <cjwatson> android takes about an hour to build, right?
[12:34] <ogra_> lool, 75 is only half working
[12:34] <ogra_> cjwatson, 40min
[12:34] <cjwatson> if you do it RIGHT NOW it might squeeze in before buildd downtime
[12:34] <cjwatson> looks like 30min in fact
[12:34] <ogra_> i have to donload it ... over 2M
[12:35] <ogra_> thats takes 15min or so
[12:35] <ogra_> lool, ^^^ could you ?
[12:35] <cjwatson> I meant the raw build time
[12:35] <ogra_> (no change rebuild of android)
[12:35] <ogra_> cjwatson, i was referring to the "RIGHT NOW" :)
[12:40] <lool> sorry, was in a HO
[12:40] <lool> I have too little bandwidth
[12:40] <lool> ogra_: you still want that to be done?
[12:41] <ogra_> lool, would be good, yeah
[12:41] <lool> I can try from a remote host
[12:44] <lool> unpacking........... |[12:45] <cjwatson> If it takes that long maybe it isn't a big problem if it waits until after buildd downtime
[12:45] <lool> :-)
[12:45] <lool> building the source package...
[12:51] <lool> uploaded
[12:52]  * ogra_ hugs lool 
[12:52] <lool> it's in unapproved
[12:52] <lool> cjwatson: ^
[12:52] <cjwatson> I expect it'll be auto-accepted
[12:52] <cjwatson> thanks
[12:53] <ogra_> yeah
[12:53] <lool> ah right, unseeded
[12:53] <ogra_> it usually is
[12:54] <cjwatson> Yep
[12:54] <cjwatson> I think I'll cancel the interminable openclipart2 test rebuild to make way for it; I was going to have to cancel that anyway, probably
[12:56] <lool> ogra_: so what's the missing stuff to get timezone selection working?
[12:57] <ogra_> lool, that was it :)
[12:57] <lool> ogra_: ok
[12:57] <ogra_> the "synced" mode needs another fix to not replace links with their target files on boot
[12:57] <ogra_> s/needs/needed/
[13:00] <fginther> didrocks, are you seeing 'autopilot issues' again? I noticed a new one back in the ppa and at least one test run is showing similar test failures again.
[13:05] <fginther> sil2100, are you seeing 'autopilot issues' again on the daily release tests? I noticed a new one back in the ppa and at least one test run is showing similar test failures again
[13:07] <lool> taking a break, bbiab
[13:16] <didrocks> fginther: urgh, really?
[13:16]  * didrocks looks
[13:17] <didrocks> sil2100: new autopilot in the ppa? Not sure how you disable it, but it seems you either don't push the branch or do something wrong… :/
[13:17]  * didrocks will do this one himself
[13:17] <didrocks> fginther: autopilot removed from the ppa
[13:17] <didrocks> (needs to publish the removal)
[13:17] <fginther> didrocks, thanks
[13:17] <didrocks> fginther: I'm pushing to cupstream2distro-config the removal as well
[13:18] <fginther> didrocks, ack
[13:18] <didrocks> fginther: ok, done :)
[13:19] <didrocks> fginther: were those issues the one you reported to thomi? apparently he has no idea that AP is creating issues
[13:19] <didrocks> (or don't want to test)
[13:20] <fginther> didrocks, we discussed just the problem, but in great detail. I'll work with him to test this in the same env
[13:20] <fginther> didrocks, err *not* in great detail
[13:20] <didrocks> fginther: well, basically it's latest image + AP trunk
[13:20] <didrocks> (and running all AP tests)
[13:21] <fginther> didrocks, I see the problem when running ubuntuuitoolkit tests
[13:21] <fginther> didrocks, we'll get it figured out
[13:22] <didrocks> thanks fginther :)
[13:54] <lool> ogra_, didrocks: Who's seeding thumbnailer in the image?
[13:55] <ogra_> is that supposed to land this build ?
[13:55] <didrocks> lool: right now nothing, I think we'll have a dep?
[13:55]  * ogra_ thought that was for next one
[13:55] <didrocks> ogra_: it's in the archive for this one, I think the dep is coming to the next one
[13:55] <ogra_> ah, fine then
[13:58] <lool> didrocks: I think thostr_ wanted it in the image to make their life easier somehow
[13:58] <lool> thostr_: Heya
[13:58] <lool> thostr_: so thumbnailer is in archive, but it wont be in image unless something pulls it in; usually it's a dependency
[13:59] <lool> thostr_: do you need it in the image?  if so, do you have a piece to land that will pull it?
[13:59] <didrocks> lool: not sure how this help compared t ohaving it in the archive
[14:00] <lool> ogra_: Would you know where the powerd changes for dconf are staged?  don't see them in PPA
[14:00] <lool> didrocks: not sure either, hence pinging thostr_
[14:00] <lool> :-)
[14:00] <thostr_> lool: we need that to then build the sdk changes
[14:00] <didrocks> thostr_: so, it's fine in the archive I guess
[14:00] <thostr_> didrocks: yes, then all builds should run at least
[14:01] <lool> thostr_: all builds?
[14:01] <ogra_> lool, in a branch, didnt i link it ?
[14:01] <thostr_> lool: well, getting that properly build
[14:01] <lool> thostr_: so
[14:01] <lool> thostr_: is https://launchpad.net/ubuntu/+source/thumbnailer being in archive good enough for you?  :-)
[14:01] <lool> for now
[14:01] <thostr_> lool: yes
[14:02] <lool> thostr_: ok, marking your landing for this one as DONE then, thanks for confirming
[14:28] <jibel> plars, psivaa quantal ec2 have been failing for a while, is someone taking care of them?
[14:29] <plars> jibel: afaik, the server team looks after those, but we'll check on it
[14:29] <jibel> plars, well they apparently look then run when they see the results
[14:30] <jibel> plars, if they are useless, they should be disabled
[14:30] <jibel> plars, that'll lighten the load on the publisher
[14:30]  * psivaa would like to see the link of that :)
[14:30] <plars> jibel: indeed
[14:30] <didrocks> thostr_: re: libusermetrics, how important is the regression?
[14:30] <didrocks> thostr_: I see the MP, but no assessment of what the impact is
[14:30] <plars> psivaa: http://10.98.0.1:8080/view/ec2/job/quantal-server-ec2-daily/
[14:30] <didrocks> (some tests are failing?)
[14:31] <thostr_> didrocks: that's more a functional regression
[14:31] <psivaa> plars: thanks, lots of red balls
[14:31] <didrocks> thostr_: so, on AP tests are impacted? (like no rush to push it?)
[14:31] <thostr_> didrocks: qml api didn't provide the same as c++/qt api
[14:31] <didrocks> oh, but nothing is using it as of now?
[14:31] <didrocks> ok*
[14:32] <plars> jibel: do you know who set all of those up originally?
[14:32] <plars> jibel: or if there's any documentation of it?
[14:32] <thostr_> didrocks: nothing will crash or so, it just makes the infographic looking a little bit strange in worst case
[14:33] <didrocks> thostr_: ok, I'm planning for image 77 then
[14:33] <jibel> plars, it was James Page and Carlos. I don't know if james is still in charge of these jobs
[14:33] <didrocks> (not 76)
[14:33] <thostr_> didrocks: ok
[14:33] <didrocks> thostr_: when I see "regression", this is like an alarm :p
[14:33] <thostr_> didrocks: ok, will be more careful the next time
[14:34] <didrocks> no worry ;)
[14:34] <didrocks> (just think about my heart ;))
[14:39] <didrocks> sil2100: you can pre-prepare some more task for landing #77 if you want
[14:41] <didrocks> sil2100: also, it would be interesting to see why libfriends want to rerelease
[14:57] <balloons> didrocks, plars lool I have pending fixes for all the failing tests for music, rss reader and calendar. Due to sdk and emulator bugs it's been hard to land them this week
[14:58] <didrocks> balloons: waow, excellent! so this is going to be in for image 77?
[14:58] <didrocks> balloons: can you just wait for 76 to be building (like in 3 hours at max?)
[14:58] <didrocks> balloons: you did rerun AP yourself I guess on them?
[14:59] <balloons> didrocks, well, I've been trying to land them -- they are still pending on not yet merged
[14:59] <didrocks> balloons: ok, let's target image 77 rather
[15:00] <balloons> kk
[15:00] <didrocks> we can warn you if needed
[15:00] <didrocks> balloons: just ensure that all AP tests are back to green with them please ;)
[15:01] <balloons> didrocks, when do you plan to land 77?
[15:01] <didrocks> balloons: we'll certainly kick a build tomorrow morning
[15:01] <didrocks> (my morning)
[15:01] <didrocks> balloons: but you can get them landed in the ppa just when 76 finishes to build
[15:02] <didrocks> balloons: in this 3 hours window (we can ensure to ping you for this)
[15:02] <didrocks> balloons: mind adding a landing ask for those?
[15:02] <didrocks> so that we track them
[15:04] <balloons> didrocks, sure
[15:05] <didrocks> thx!
[15:05] <sil2100> ACK
[15:05] <balloons> didrocks, I actually don't seem to have edit privileges
[15:06] <didrocks> balloons: we can fix that :)
[15:07] <didrocks> balloons: done
[15:08] <balloons> "=_
[15:08] <lool> balloons: (following up from #ubuntu-app-devel)
[15:08] <lool> balloons: yes, list of known ui-toolkit critical bugs still affecting bzr trunk very much welcome
[15:08] <lool> balloons: we were about to consider an updated version
[15:09] <lool> So, I've dist-upgraded to everything in archive + PPA (I know, crazy)
[15:09] <lool> and things were mostly working
[15:10] <lool> music activation only works once though, I see the attempt to tell music-app to load new URL, but it doesn't work
[15:10] <lool> will try to add that to music-app rather than adding workarounds in upstart-app-launch
[15:10] <sil2100> didrocks: for the AP issue - it was disabled and redeployed, but the branch was not pushed to trunk as I thought we'll have it fixed ASAP - and while you were redeploying for the new cu2d functionality it got enabled back again, bad call from my side
[15:10] <lool> launching music-app from shell and from music scope results in a single music app
[15:10] <sil2100> I knew bzr push was the way to go
[15:11] <lool> hmm actually, launching from shell first, then opening URL results in two music-apps
[15:11] <lool> but not the reverse  :-)
[15:12] <didrocks> sil2100: heh, no worry, fixed now
[15:12] <balloons> lool, I would say the only "critical" bug is the one I mentioned already: https://launchpad.net/bugs/1233402
[15:13] <sil2100> didrocks: eh, indeed - one release on the 30th and then next was today ;/
[15:14] <didrocks> yep
[15:14] <lool> balloons: ok
[15:16] <didrocks> ogra_: is really "
[15:16] <sil2100> ogra_: did you seed the onlinescope and thumbnailer? ;)
[15:16] <didrocks> initramfs-tools-ubuntu-touch, android: bugfix for readlink with empty path"
[15:16] <didrocks> in archive?
[15:16] <didrocks> (we set it for image 77)
[15:16] <ogra_> didrocks, no, waiting for 77 :)
[15:16] <didrocks> ogra_: hum, the status is wrong, TODO then?
[15:17] <didrocks> ogra_: oh, sil2100 is right, the onlinescope will need seeding, I can do it
[15:17] <didrocks> (not thumbnailer as we discussed)
[15:21] <Mirv> didrocks: hi. there'd be a qtdeclarative patch request, where could we fit that in?
[15:21] <didrocks> Mirv: I guess image 77 or 78, what the patch is supposed to fix?
[15:21] <Mirv> didrocks: bug https://bugs.launchpad.net/ubuntu/+source/qtdeclarative-opensource-src/+bug/1233705
[15:22] <didrocks> Mirv: ok, please add a landing ask, I think we can get that with the new sdk as you will need to relaunch all AP tests
[15:22] <Mirv> didrocks: so basically any lists, tsdgeos is requesting it. I'll make preparations anyhow and test it.
[15:22] <Mirv> didrocks: ok
[15:22] <didrocks> Mirv: so if you can deal with both, fine with me
[15:22] <didrocks> ensure you have DEP5, forwarded, and so on
[15:22] <Mirv> ok, adding
[15:23] <Mirv> yep
[15:23] <didrocks> ogra_: sil2100: seeded and metapackage uploaded
[15:23] <sil2100> didrocks: thanks!
[15:23] <didrocks> yw ;)
[15:23] <didrocks> sil2100: re: thumbnailer, this will come with a dep I guess
[15:24] <sil2100> didrocks: makes sense, otherwise it's rather useless to include
[15:36] <thostr_> sil2100: didrocks: yes, sdk/unity8 will depend on thumbnailer... working on those MPs right now
[15:37] <thostr_> didrocks: can you schedule line 118 for landing?
[15:37] <sil2100> Awesome
[15:38] <didrocks> thostr_: I'm talking with lool about it
[15:38] <thostr_> didrocks: ok
[15:38] <didrocks> thostr_: there is an upstart-app-launch landing already planned, I wonder if we can sneak that one into it
[15:39] <didrocks> sil2100: don't forget to prepare the HUD req. as well btw ;)
[15:39] <thostr_> yes, 113, 118 and 119 at the same time?
[15:39] <didrocks> oh you did update
[15:40] <didrocks> sil2100: great, well, I think you will let ted knows about the regresssion if it's not flacky tests
[15:40] <didrocks> thostr_: yep, that's what would make sense to me
[15:40] <thostr_> didrocks: then let's go for it
[15:42] <lool> thostr_: so I did some testing with new upstart-app-launch
[15:42] <didrocks> thostr_: yeah, done ;)
[15:42] <lool> thostr_: it kind of regresses a bit if we dont update music-app at the same time
[15:42] <lool> and mediaplayer-app I guess
[15:42] <thostr_> lool: correct
[15:42] <lool> and perhaps webbrowser-app  :-)
[15:42] <lool> thostr_: So I've been looking at updating music-app, but it will take me some time to test
[15:42] <thostr_> lool: bfiller pinged me on that and we need to move all at once
[15:42] <lool> yeah
[15:43] <lool> thostr_: so holding up url-dispatcher + upstart-app-launch to go at the same time
[15:43] <didrocks> lool: as bfiller asked me to ensure before each app landing that they are ready, please ensure that as well :)
[15:43] <didrocks> keeping ? for landing target as of now
[15:43] <lool> thostr_: otherwise, seemed good; I did get two copies of music-app in one case, and haven't tested with Mir yet
[15:43] <lool> thostr_: a couple of settings:/// URLs worked, but not the last one
[15:43] <lool> didrocks: music-app is coreapps though
[15:43] <lool> didrocks: but the other ones would be bfiller indeed
[15:43] <didrocks> yeah, for that one :/
[15:43] <didrocks> right
[15:44] <bfiller> lool: why url-dispatcher and upstart-app-launch at the same time?
[15:44] <thostr_> lool: didrocks: I guess at some point we need to move... it won't get easier trying to sync all settings pages and apps
[15:44] <lool> bfiller: they don't particularly depend on each other for the staged changes, but they touch the same use cases right now (mainly opening URLs)
[15:44] <bfiller> lool: fine with me if they go in together but lets get them in the queue as I believe they are ready
[15:45] <sil2100> ;)
[15:45] <lool> bfiller: as I note above, there are some small regressions with upstart-app-launch and I'd rather we merge them along the *-app updated to deal with opening URLs
[15:45] <lool> bfiller: do you have the webbrowser/mediaplayer changes in the pipe for this?
[15:45] <lool> also, this needs ubuntu-ui-toolkit, which has some regressions
[15:45] <bfiller> lool: yes, the MR's need ui-toolkit before they can be approved and landed
[15:46] <bfiller> lool: and also needs changes to unity8 to promote running apps
[15:46] <bfiller> lool: two oustanding MR's for media player and browser to handle urls when running
[15:47] <lool> bfiller: so music-app missing?
[15:47] <bfiller> I'd prefer to see stuff that is not blocked go in right away rather than waiting for all the related stuff to land
[15:47] <lool> bfiller: Will try to cover the music-app part then
[15:48] <bfiller> lool: don't know about music-app
[15:48] <lool> bfiller: the problem is not that they are related, but that there are regressions if we don't push them together
[15:48] <lool> I think the only thing that might be able to get in alone is url-dispatcher
[15:48] <bfiller> ok
[15:48] <lool> which only adds safety nets
[15:48] <lool> Hmm and calendar URL it seems
[15:49] <bfiller> and support for :/// urls
[15:53] <didrocks> ogra_: i386 published in proposed for hybris, can we push android now?
[15:54] <ogra_> rsalveti, ^^^
[15:54] <ogra_> didrocks, yeah, we should be fine
[15:54] <rsalveti> doing as we speak
[15:55] <didrocks> \o/
[15:56] <didrocks> sil2100: Mirv: I added you to the meeting so that I don't have to paste url everytimes :)
[15:56] <lool> cjwatson: heya, https://launchpad.net/~ubuntu-touch-coreapps-drivers/+archive/daily/+build/5069701 is waiting for an armhf PPA buildd, but Launchpad says there are 0 armhf PPA builders?
[15:56] <vila> didrocks, lool: Finally get out the rabbit hole and fixed 'la mocheté' ;) https://code.launchpad.net/~vila/cupstream2distro/star-log/+merge/188875
[15:56] <vila> *out of
[15:57] <lool> cool
[15:57] <lool> vila: you joining our HO in 2mn?
[15:57] <sil2100> ;)
[15:57] <sil2100> didrocks: thanks!
[15:57] <cjwatson> lool: Mid-upgrade
[15:57] <lool> cjwatson: ah ok; thanks
[15:57] <didrocks> vila: ah nice! will probably review it tomorrow morning though
[15:57] <cjwatson> lool: Unfortunately the upgrade has been a bit rocky and IS is still working on getting the various backend machines back
[15:57] <lool> cjwatson: do we have an ETA?
[15:57] <cjwatson> 16:54 <ChrisS> cjwatson: Some (well, most) of them are misbehaving ("Error: Device 769 (vbd) could not be connected. Hotplug scripts not working") and needing ppa-makebaseing.  Getting there, though.
[15:57] <lool> cjwatson: cause we'd like these builds in an upcoming image build
[15:57] <Mirv> didrocks: I've so poor connection that I can try to listen to but probably need to get the url:s from elsewhere anyhow..
[15:57] <cjwatson> is all I have
[15:57] <cjwatson> lool: Uh, that makes no sense
[15:58] <cjwatson> lool: If it's to be in an image build, surely it should be in a devirtualised PPA instead?
[15:58] <lool> cjwatson: sadly, coreapps PPA is still used in our builds
[15:58] <cjwatson> lool: And all of those builders are back ...
[15:58] <didrocks> Mirv: https://plus.google.com/hangouts/_/e02813c8dad5247b82691825a672a098f47139d5
[15:58] <cjwatson> lool: Oh, ugh, I didn't realise that was virt
[15:58] <lool> cjwatson: maybe it's virt
[15:58] <vila> lool: good idea !
[15:58] <vila> didrocks: no urgency
[15:58] <lool> cjwatson: we're trying to drop this PPA for release BTW, I'm meeting in 30mn to get up to speed on where things stand there
[15:59] <cjwatson> Yeah, it's virt
[15:59] <cjwatson> Let me see if one of the working builders can do the job
[16:01] <didrocks> sil2100: joining?
[16:02] <didrocks> robru: ^
[16:02] <sil2100> !
[16:03] <rsalveti> didrocks: ogra_: pushed android, once available in the archive, please trigger a new image
[16:03]  * ogra_ is already watching https://launchpad.net/ubuntu/saucy/+source/android/20131002-0539-0ubuntu3
[16:03] <ogra_> :)
[16:04]  * ogra_ hugs rsalveti ... thanks for the upload 
[16:05] <ogra_> didrocks, gst1.2 will be all fine, dont be so worried, its just bugfiuxes :)
[16:05] <cjwatson> lool: I *think* hamsa will be able to do it.  I've reassigned it to armhf temporarily, though I don't know how long it'll take to finish its current build
[16:06] <cjwatson> lool: Are there any other vitally urgent builds?
[16:08] <cjwatson> Building.  Let's see ...
[16:09] <lool> cjwatson: yes, but the other one isn't uploaded yet
[16:09] <rsalveti> didrocks: fginther: cyphermox: awe_: needs help setting up CI for ofono, packaging + code branch pushed at https://code.launchpad.net/~phablet-team/ofono/ubuntu
[16:09] <lool> https://launchpad.net/bugs/1233402
[16:09] <rsalveti> bzr bd compatible, source format 1.0
[16:10] <rsalveti> didrocks: fginther: who can help me on that? :-)
[16:10] <cyphermox> rsalveti: I can
[16:10] <fginther> rsalveti, I can help
[16:10] <cyphermox> do you have CI already?
[16:11] <rsalveti> cyphermox: nothing, just created that branch
[16:11] <fginther> cyphermox, no upstream merger yet
[16:11] <cyphermox> ok
[16:11] <lool> cjwatson: https://launchpad.net/~ubuntu-touch-coreapps-drivers/+archive/daily/+build/5069757 is the other one
[16:11] <cyphermox> then I'll let fginther play with it :)
[16:11] <cjwatson> lool: i386, really?
[16:11] <awe_> rsalveti, thanks for the update.  I created: https://wiki.ubuntu.com/Touch/Telephony/ofono
[16:11] <awe_> will update with the branch, and further instructions later on
[16:11] <cjwatson> lool: Oh, arch all I guess
[16:12] <rsalveti> awe_: cool, thanks
[16:12] <cjwatson> lool: scored up
[16:13] <fginther> rsalveti, is there a separate lp branch for ofono upstream?
[16:13] <rsalveti> fginther: https://code.launchpad.net/~phablet-team/ofono/rilmodem, which is an auto-import from git
[16:13] <awe_> fginther, see the page I just posted above
[16:13] <awe_> on the wiki
[16:14] <fginther> awe_, ack
[16:14] <awe_> which describes the setup in a bit more detail
[16:14] <rsalveti> fginther: the branch I gave you (lp:~phablet-team/ofono/ubuntu) has that included + packaging, which works fine with bzr bd
[16:15] <lool> cjwatson: thanks
[16:19] <sil2100> Do the gallery_app tests work ok for all of you all the time? Since I noticed those hang up the most
[16:20] <didrocks> rsalveti: sorry, back from meeting
[16:20] <didrocks> ogra_: worried me? never ever ever :p
[16:20] <didrocks> rsalveti: sil2100 is a good victim for that :)
[16:21] <ogra_> haha
[16:21] <didrocks> robru: can you pair with sil2100 on the tasks assigned to him?
[16:21] <robru> didrocks, sil2100: sure
[16:21] <didrocks> robru: then, feel free to continue during the day one his tasks
[16:21] <didrocks> thanks!
[16:21] <robru> sil2100, which do you want me to start with?
[16:22] <ogra_> didrocks, https://bugs.launchpad.net/ubuntu/+source/telephony-service/+bug/1234087 ... i'll add a landing asks entry for it
[16:22] <didrocks> robru: please don't push anything before 76 is building :)
[16:22] <robru> didrocks, when will that be?
[16:22] <didrocks> ogra_: who needs sound? ;)
[16:23] <ogra_> yeah
[16:23] <didrocks> robru: stare at ogra! ;)
[16:23] <ogra_> heh
[16:23] <robru> ogra_, !!!
[16:23] <ogra_> once this is fully in tegh archive https://launchpad.net/ubuntu/saucy/+source/android/20131002-0539-0ubuntu3 i'll trigger the build
[16:23] <robru> ogra_, http://goo.gl/isDWPJ
[16:24] <didrocks> ogra_: ok, let's see once we get the fix to schedule it ASAP
[16:24] <lool> fginther: ubuntu-touch-coreapps-drivers
[16:24] <didrocks> ogra_: thanks for the notificatoin :)
[16:24] <lool> fginther: ppa:ubuntu-touch-coreapps-drivers/daily
[16:24] <ogra_> should be done building in ~20 min ... then promotion etc
[16:24] <didrocks> (no sound for this notification though :p)
[16:24] <ogra_> robru, LOL !
[16:24] <robru> I am staring at you ;-)
[16:26] <sil2100> What's up?
[16:26] <robru> sil2100, I don't have any work assigned in the landing plan, so i'm helping with yours. pick a couple things for me to do
[16:26] <ev> didrocks: do you think it would be helpful to put gstreamer into the proposed-migration hinting to prevent it from accidentally landing again?
[16:26] <sil2100> rsalveti: if it's about packaging, I'm all ears!
[16:27] <rsalveti> sil2100: actually we just need to set up the CI for, I believe the packaging should be mostly fine, but a review (for the CI infra) would be welcome if you got the time
[16:27] <sil2100> robru: could you tackle 123?
[16:27] <cjwatson> ev: Well, it was already blocked
[16:27] <sil2100> rsalveti: always, that's my greatest passion ;) Let me take a look
[16:27] <rsalveti> I believe fginther is setting up the CI infra for it already
[16:27] <cjwatson> ev: Not in proposed-migration, but it landed in unapproved ...
[16:27] <robru> sil2100, sure
[16:28] <rsalveti> sil2100: thanks!
[16:28] <didrocks> ev: I think we won't have big migration again (like jump from 1.1.4 to 1.2), only small bug fixes from now on. So I don't think that will help us. I don't see the issue being different than someone pushing the SDK today for instance
[16:28] <sil2100> robru: I'll finish up HUD and libusermetrics - last time it didn't really work as mediaplayer-app had issues
[16:28] <didrocks> ev: I mean, it's more a social issue
[16:28] <robru> sil2100, ok
[16:28] <ogra_> cjwatson, all of it ? i think there are universe and multiverse bits that dont
[16:28] <cjwatson> the relevant bits
[16:28] <fginther> lool 0.0.20130924~bzr4~ubuntu13.10.1
[16:28] <ogra_> k
[16:28] <cjwatson> ev: I'm not sure that the release team could have known not to unblock it since the request came from a phonedations developer
[16:28] <didrocks> cjwatson: yeah, I think no one is blaming the release team at all :)
[16:28] <ev> didrocks, cjwatson: ah right, thanks.
[16:29] <ev> yeah, that wasn't my intention here
[16:29] <ev> I'm just brainstorming on how we can feed the landing task force into the loop for this without the release team having to communicate every single action to them
[16:30] <ev> but having been away when all of this was set up, I am not going to begin to propose I have the right answers :)
[16:31] <cjwatson> ev: Well, I'm all for the touch landing team blocking everything they care about in proposed-migration and selectively unblocking; that's why I set that up
[16:31] <cjwatson> ev: I'm just sceptical that it would have solved this particular problem, that's all
[16:32] <rsalveti> didrocks: what is the big issue with the 1.2 transition? the main problem we had was with the media stack itself
[16:32] <didrocks> rsalveti: yeah, but we wanted to promote an image with the media stack first
[16:32] <rsalveti> and that's a stable release, mostly with bugfixes, comparing with 1.1.4, that we had discussed before
[16:33] <didrocks> rsalveti: so the unexpected upload (it's always a risk) is just making 76 at risk if things go wrong
[16:33] <ev> cjwatson: so then perhaps I don't understand the point you're making. So if proposed-migration is before unapproved, wouldn't this have blocked well before hitting the release team?
[16:33] <rsalveti> didrocks: right, but we had another blocker that wasn't related with 1.2 at all
[16:33] <ogra_> didrocks, its like going from a 0.99 version to 1.0 with only bugfixes added
[16:33] <rsalveti> didrocks: it's not unexpected in this case
[16:33] <rsalveti> we tested and verified the media stack on top of it, and our issue wasn't related at all with that
[16:33] <didrocks> rsalveti: well, nobody from the landing team planned to get it before we promote an image
[16:33] <cjwatson> ev: You have it exactly backwards :)
[16:33] <rsalveti> was a broken code
[16:34] <didrocks> rsalveti: so it was added to the landing ask without concertation
[16:34] <robru> didrocks, sil2100: for unity-scope-home / unity-lens-applications, the landing plan says "check that the string change was acked by translators"... who are the translators, how would i check this?
[16:34] <didrocks> landing plan*
[16:34] <ev> cjwatson: whoop. But then surely it still blocks at proposed-migration?
[16:34] <didrocks> rsalveti: no worry, but again, I wish we could have promote an image (so having the media stack landed with all AP tests passing)
[16:34] <cjwatson> ev: And the other point is that only a single unblock is needed - so in exactly the same situation, if somebody comes to the release team and says "we need the new gstreamer" ...
[16:34] <didrocks> then, getting 1.2
[16:34] <rsalveti> didrocks: right, what did you want me to do in this case?
[16:34] <didrocks> rsalveti: just ask us to schedule it on the landing plan
[16:35] <rsalveti> we discussed it was a bugfix release, tested our mediastack, added to the spreadsheet, and landed
[16:35] <didrocks> rsalveti: that was the reason it wasn't on the schedule yet
[16:35] <ogra_> rsalveti, put it on the sheet and wait til next landing team meeting to get approval i guess
[16:35] <didrocks> yep, what ogra told :)
[16:35] <rsalveti> right, that's what I wanted to get
[16:35] <rsalveti> where did we decide that?
[16:35] <rsalveti> when, and how :-)
[16:36] <ogra_> trhere was a mail where the spreadsheet was introduced
[16:36] <ev> cjwatson: so is that more of a social issue? That someone comes to the release team and says "we need this" and so they unblock it at proposed-migration without consulting with the landing task force?
[16:36] <didrocks> rsalveti: we have 2 meetings a day and I send a report after each meeting on ubuntu-phone ML
[16:36] <cjwatson> ev: the release team shouldn't be expected to know about the ins and outs of touch landing, basically
[16:36] <ogra_> i dont think it got across in that mail that this is a mandatory process
[16:36] <rsalveti> didrocks: right, so you want me to put something there and wait your report to expect when such transition could land?
[16:36] <cjwatson> ev: people shouldn't be requesting things of us that aren't touch-authorised in the first place :)
[16:36] <rsalveti> ogra_: exactly
[16:36] <rsalveti> and this is part of the stack we were *landing*
[16:36] <didrocks> rsalveti: indeed, if you want to speed it up or have questions, ping works
[16:36] <cjwatson> ev: (but IMO the entire touch landing process is broken)
[16:37] <didrocks> rsalveti: hum, no that was 2 requests on purpose
[16:37] <didrocks> as you got fears as well about landing it IIRC (from the hangout)
[16:37] <rsalveti> didrocks: right, but we didn't necessarily needed to land both separately
[16:37] <didrocks> like we all have with new code
[16:37] <ev> cjwatson: sure, I wouldn't expect that of the release team. I had just assumed the tools at their disposal pointed to "hints-ubuntu-touch" in the case of this block
[16:37] <rsalveti> didrocks: because we thought we would land the first stack way before
[16:37] <didrocks> let's imagine AP tests for media are screwed tomorrow
[16:37] <didrocks> it will be more difficult to know if it's gst1.2
[16:37] <didrocks> or the change
[16:38] <cjwatson> ev: perhaps they would; it's hard to say yet because the touch landing team generally isn't using the tools I provided
[16:38] <rsalveti> but it was blocked until the point where we decided to do both together, and then fix the remaining issue on top of it
[16:38] <didrocks> I think this could have just wait one image
[16:38] <ev> and so once this was properly socialised, they'd know that the release task force really should be signing off on any override of that
[16:38] <cjwatson> yeah, perhaps
[16:38] <rsalveti> didrocks: but this was a low risk bugfix only, that's why I didn't follow all this process
[16:38] <ev> (to be clear I'm not trying to assign blame here; just trying to prevent this sort of thing from happening again while not creating an incredible burden on the release team)
[16:38] <didrocks> rsalveti: but no worry again, it's just that we have a process for acking things and it's better that everyone follows it
[16:38] <rsalveti> didrocks: but I'll make sure to attend the meeting if I want to land something again
[16:38] <didrocks> noone died ;)
[16:39] <rsalveti> this is just horrible and painful
[16:39] <didrocks> rsalveti: yeah, or ping if you don't want to spend your time on it
[16:39] <cjwatson> rsalveti: amen
[16:39] <rsalveti> didrocks: you're not on-line all the time
[16:39] <didrocks> rsalveti: well, I didn't design the process ;)
[16:39] <rsalveti> so I need to sync my ping as well :-)
[16:39] <ogra_> ev, well, imho the blame lies in the initial email describing the process ... it wasnt clear from it that this is a mandatory process for everyone and how strict it is
[16:39] <rsalveti> exactly
[16:39] <cjwatson> ev: if it takes a small amount of socialisation in the release team of making sure not to override touch hints without checking, in order to burn the spreadsheet landing process to the ground; I would be happy with that
[16:39] <ogra_> ev, imho we have some communication improvement to do here +
[16:39] <didrocks> rsalveti: I'm not the only one, there is lool, ogra, asac…
[16:40] <Laney> all in the eu
[16:40] <ev> ogra_: absolutely! this is *brand* new. It's going to take a few attempts to get it running smoothly.
[16:40] <ogra_> yes
[16:40] <didrocks> Laney: unfortunately yes
[16:40] <ogra_> well it is more about getting people less grumpy by knowing what they have to expect
[16:40] <ev> cjwatson: I can send a mail around asking for that, if you think it would help
[16:41] <cjwatson> ev: Well, I sent mail when I set up the touch hints in the first place; very little response
[16:41] <cjwatson> ev: I don't think there's much to be done in the release team until people start using it
[16:41] <ev> didrocks: so why aren't we really using this yet? ^
[16:41] <cjwatson> ev: And everyone seems too heads-down-focused-on-13.10 to even consider this
[16:41] <ev> I did notice that as well. The only change is from lool, and it's commenting something out.
[16:41] <ogra_> ev, because it is duplication
[16:41] <cjwatson> ogra_: it is intended to be replacement, not duplication
[16:41] <cjwatson> your current process is utterly dire and hopeless
[16:41] <ev> duplication of what?
[16:42] <ev> (this is what I get for going on holiday)
[16:42] <cjwatson> it is the most human-intensive thing I have ever seen, with very poor use of technology
[16:42] <ogra_> ev, as long as we have the spreadsheet and nobody agrees that we can instead use proposed it wont fly i think
[16:42] <cjwatson> (sorry, but nobody seems to be listening to milder criticisms)
[16:42] <ogra_> cjwatson, and i think many of us agree
[16:42] <cjwatson> so it is absolutely not intended to duplicate, but to replace
[16:43] <cjwatson> of course it can be run in parallel as a safety net
[16:43] <sil2100> robru: best use the translator's ML I guess
[16:43] <cjwatson> and in that mode it's indeed somewhat duplicative
[16:44] <cjwatson> I can't do much about that except complain :)
[16:44] <fginther> rsalveti, I should get that ci setup soon, will ping you when it's ready
[16:45] <didrocks> cjwatson: nobody was aware about that process before the email
[16:45] <didrocks> cjwatson: it just went out by surprise
[16:45] <didrocks> we all agree I think that's not the way to go
[16:45] <didrocks> unfortunately, it helped to get a green image, and management seems to think it's the way to go
[16:45] <didrocks> I hope that by enforcing it and showing how intensive this is, we can help post-v1 to revisit it
[16:46] <cjwatson> My fear is that it will simply entrench it
[16:46] <didrocks> I can only see one positive side on this process: we know exactly what enters
[16:46] <cjwatson> And burn you guys out in the process
[16:46] <rsalveti> fginther: awesome, thanks
[16:46] <didrocks> cjwatson: well, I made it clear that I won't continue post v1 with the current process
[16:46] <cjwatson> TBH if I didn't have to work on touch-related things I would be finding other things to do; as an uploader it's utterly demotivating too
[16:46] <didrocks> so either they will find someone else
[16:46] <cjwatson> didrocks: *nod* good
[16:46] <didrocks> or so be it :)
[16:47] <rsalveti> yeah
[16:47] <ogra_> didrocks, lets just all convince asac that proposed is the way better place for gatekeeping
[16:47] <ev> cjwatson: demotivating how?
[16:47] <ogra_> didrocks, after all it was exactly designed for this
[16:47] <rsalveti> why would you propose a fix if you know how painful the process is
[16:48] <cjwatson> ev: instead of "upload source, let it build, request somebody to ack it, they can do that regardless of whether I'm around"
[16:48] <didrocks> ogra_: I think we need propose + some tracking
[16:48] <didrocks> then tracking needs to be automated
[16:48] <ogra_> didrocks, right
[16:48] <didrocks> I don't have any answer for that
[16:48] <ev> cjwatson: *nods*
[16:48] <rsalveti> didrocks: my issue is having this blocked my a human process, and by people as well
[16:49] <ogra_> didrocks, i would also like to have automates PPA image builds, so we can pocket copy feature sets of packages from proposed there and start a special image build
[16:49] <cjwatson> ev: I have to prepare the source, fill in an entry in a cumbersome spreadsheet, wait some undefined time for people to ack it there, then if I happen to still be around I can upload but only if there isn't an image currently being prepared ...
[16:49] <rsalveti> that are not 24 hours available (of course), and that wants to control the pipeline
[16:49] <ev> cjwatson: have you broached this with asac and rick?
[16:49] <didrocks> rsalveti: don't worry, I don't have time to do anything technical anymore due to that, so I can only concurre :/
[16:49] <ogra_> didrocks, that will give us automated testing for free for the stacks
[16:49] <cjwatson> I've tried
[16:49] <rsalveti> while we have tons of stuff that needs to land and get fixed by this cycle still
[16:49] <didrocks> ogra_: yeah, I think we need the feature approach
[16:49] <cjwatson> I set up the proposed-migration stuff after raising my concerns with the current process, as an attempt at constructive contribution
[16:49] <didrocks> with a set of changes coherent between themselves and tested
[16:49] <ogra_> we shouldnt look at single packages or commits anymore
[16:50] <ogra_> but define feature sets we want to land that consist of a bunch of packages ... and then test against the -proposed packages
[16:50] <rsalveti> didrocks: the issue about not getting a green image is not blocking broken stuff in trunk mainly
[16:50] <rsalveti> blocking the package later on is already too late
[16:51] <didrocks> rsalveti: you seem to argue as if I designed this and was the cause of it :)
[16:51] <ogra_> and if we need a papaertrail, lets pelease use a proper ticket system instead of a spreadsheet
[16:51] <ev> what would a "proper ticket system" give us over a spreadsheet?
[16:51] <rsalveti> didrocks: I'm just replying based on what you said
[16:51] <cjwatson> ev: but what's really demotivating is slaving away for months to make the upload/proposed/build/release pipeline as fast and smooth as possible, and then the whole thing is undone by putting a spreadsheet in front of it
[16:51] <rsalveti> not pointing fingers
[16:51] <vila> rsalveti: huh ? You want your trunk to be gated by integration tests with other projects ?
[16:51] <cjwatson> ogra_: bzr commit to the touch hints branch would do fine as a paper-trail
[16:51] <cjwatson> I mean, we're all developers here
[16:52] <ogra_> ev, tickets :) and a proper overview ... did you look at the landing asks sheet yet ?
[16:52] <didrocks> rsalveti: there is the issue that you have a set of changes that are interdependant
[16:52] <cjwatson> the landing asks sheet is a self-created problem
[16:52] <rsalveti> vila: historically, the issue we had was that we got broken stuff that was approved without being properly tested
[16:52] <rsalveti> vila: in trunk
[16:52] <ogra_> cjwatson, well, i think management still wants langing requests and some "lander" who leads it through the testing and actual landing process
[16:52] <rsalveti> didrocks: right, this is fine, and can be done in the integration level
[16:53] <cjwatson> yes, of course if you crank the velocity/risk-aversion slider all the way to the right then you end up with lots of stuff outstanding
[16:53] <didrocks> rsalveti: that was the goal of daily release: in august, I was asked to get faster, so we got 4 hours daily, then a month later, it was too fast…
[16:53] <cjwatson> ogra_: so then I hear we have this bug tracking system
[16:53] <ogra_> cjwatson, ++
[16:53] <Mirv> ok so qtdeclarative seems to compile fine, so should be ready to be tested together with ui-toolkit in the morning
[16:53] <ogra_> cjwatson, i didnt specify which ticket system ;)
[16:53] <vila> rsalveti: right, I got that. I was emphasizing that if you don't want the "package to be blocked later", you need more tests before getting there.
[16:53] <rsalveti> vila: yup
[16:53] <ogra_> cjwatson, we are doing a hardcode version of a freeze atm, so indeed the distro freeze process can apply
[16:53] <ogra_> *hardcore
[16:54] <rsalveti> but anyway, let me get back to coding as I still have stuff to fix
[16:54] <cjwatson> ogra_: it's like we're doing a freeze and trying as hard as possible to ignore the benefit of nine years of experience releasing Ubuntu
[16:54] <ogra_> cjwatson, yeah
[16:54] <cjwatson> sorry.  I'll go away and do some work now
[16:54] <ogra_> dont look at me :)
[16:55] <rsalveti> cjwatson: +2
[16:56] <rsalveti> I don't even know who is the "release team" anymore :-)
[16:58] <ogra_> ah, android is done building
[17:00] <ev> cjwatson: I don't think anyone is intentionally discarding the infrastructure you've built, and I would hope that we all see the value that clearly exists in it.
[17:00] <ev> My understanding was that the landing task force was created to solve a problem that proposed migration did not handle well at the time - moving sets of changes through in a very coordinated fashion, such that we could test just those changes and then move on to the next set. This with clear communication between the stakeholders.
[17:00] <ev> I'm assuming (and perhaps I'm wrong) that this was assumed to be quicker than hacking that into proposed-migration for 13.10, which was satisfactory for testing whether the process itself worked.
[17:00] <ev> If there's a better technical way of accomplishing this with reduced overhead, but still achieving the same goal of moving in chunks with careful coordination (on the archive side - I see no reason to stop developers from throwing everything at -proposed), then great, I think we should make that a reality in 14.04 after discussing it in detail at the client sprint.
[17:01] <ev> rsalveti: so at least as far as the CI side of things is concerned, we're hoping to simplify this with the "sheriff" role I mentioned at the QA/CI sprint. Put a single face on it.
[17:02] <cjwatson> ev: Honestly?  It's simply untrue that proposed-migration couldn't have handled that, and nobody even asked
[17:02] <cjwatson> ev: As far as I know, nobody asked any of the release team (with lots of experience with this kind of thing) how our existing tools might help
[17:03] <ev> cjwatson: okay, but that's why I said perhaps I'm wrong. I wasn't involved in that conversation (being in the desert at the time).
[17:03]  * cjwatson nods
[17:04] <cjwatson> I'm not upset because I feel slighted, I'm upset because everyone talks about how fast we have to move and how vital time is and yet we make no effort to take advantage of existing resources and reinvent the wheel instead
[17:04] <ev> But I want to believe that everyone has pure intentions here. We all want Ubuntu to either not regress or increase in quality with every set of changes. Maybe they just didn't realise that we had tools for this and picked the ones they were most familiar with.
[17:04] <ev> I'll talk to asac about it if he pops up tomorrow
[17:04] <ev> so I'm not just speculating
[17:06] <ev> but I have seen a pattern of things being done in a certain way because either people weren't aware that a better process was available (and thus didn't know to ask about it), or because of history (testing off of CDs because that's what we've done since those sprints in Millbank) - so I don't think it's entirely unreasonable to think that this all boils down to miscommunication
[17:06] <ogra_> cjwatson, i brought up proposed several times prior to the spreadsheet with asac and the answer was "not fine grained enough" ...
[17:08] <cjwatson> ogra_: It's possible there was a misunderstanding there
[17:08] <ogra_> cjwatson, the point he is making every time i bring it up is that people dont seem to test their code in advance before landing it in trunk
[17:08] <cjwatson> Which is completely orthogonal
[17:09] <ogra_> (which i think is valid for a good part of us)
[17:09] <cjwatson> proposed + bug tracking for requests + test-before-unblocking would be a good process improvement, I think
[17:09] <ogra_> might be orthogonal, but the current process enforces exactly this testing
[17:09] <cjwatson> at a great cost
[17:09] <ogra_> yes
[17:09] <ogra_> at a way to big cost imho
[17:10] <ogra_> i agree that there should be such testing in place ...
[17:10] <ogra_> once we can actually provide it automated
[17:11] <sil2100> didrocks: if I see that HUD is fine, can I publish that?
[17:12]  * sil2100 still is having problems in running gallery-app tests
[17:12] <sil2100> But that's not related to hud, as with the reverted hud I get the same hangups
[17:12] <sil2100> I guess my phone is broken in overall
[17:13] <ogra_> sil2100, make sure to never run app tests after doing a unity test
[17:13] <ogra_> they will fail
[17:13] <sil2100> ogra_: I'm running fresh after a reboot, the tests are hanging - unity8 as well
[17:13] <sil2100> No reaction to touch
[17:13] <ogra_> ouch
[17:14] <sil2100> ogra_: at first I thought these are only gallery-app tests but no, webbrowser-app are causing the same problems ;/
[17:15] <ogra_> did you unlock the screen befroe starting the test ?
[17:15] <ogra_> (needs to be done manually)
[17:15] <ogra_> didrocks, lool, android is in, should i fire off a build now ?
[17:16] <didrocks> ogra_: yes please!
[17:16] <ogra_> doing
[17:16] <didrocks> sil2100: not before ogra told that the image is published please :)
[17:16] <ogra_> ~30min
[17:17] <lool> ogra_: yup
[17:19] <lool> fginther: So I try to kick a build of http://91.189.93.70:8080/job/music-app-ci/ and got instant failure everywhere; is that because there was no change in bzr?
[17:19] <lool> e.g. tests failed with bzr: ERROR: Error parsing trunk.recipe:3:14: Expecting the end of the line, got 'lp:music-app'.
[17:26] <fginther> lool, it doesn't have all the necessary arguments, one moment
[17:27] <fginther> lool, this is the build we want to rerun: http://91.189.93.70:8080/job/music-app-ci/88/
[17:27] <fginther> lool, you should see a rebuild link, just hit that and it'll have all the right parameters
[17:31] <lool> ev: asac comes back on Tuesday I think
[17:31] <lool> fginther: ok thanks
[17:34]  * ogra_ wonders if ev became german secretly ... to take advantage of the long german weekend this week :)
[17:39] <sil2100> ;)
[17:46] <sil2100> Damn, after upgrade it's much better now, maybe something got screwed up or I don't know
[17:46] <sil2100> ogra_: how's the publishing going?
[17:46] <bfiller> fginther: can you relaunch the mako test for this MR: https://code.launchpad.net/~schwann/ubuntu-ui-toolkit/uitk-missing-search-focus/+merge/188640
[17:47] <ogra_> sil2100, still needs a bit
[17:47] <ogra_> sil2100, 10min or so i'd guess
[17:47] <fginther> bfiller, yes
[17:48] <ev> ogra_: heh, nope. Just wandered out to walk the dog.
[17:49] <ogra_> heh, that would have been a long walk ... until monday :)
[17:49] <ogra_> sil2100, go !
[17:50] <ogra_> cdimage is done ... system-image might still take a while
[18:04] <rsalveti> great, can test the cdimage one
[18:19] <plars> ogra_: were there two back-to-back builds on system image?
[18:25] <sil2100> ogra_: ok, I did an experiment, and it seems when using image 75 my AP tests are hanging up, on for instance 70 that does not happen
[18:26] <sil2100> ogra_: I guess it's unity8 that's hanging up maybe...
[18:27] <ogra_> plars, not today, no
[18:28] <plars> ogra_: odd, something caused the jobs to get triggered twice
[18:29] <ogra_> sil2100, might be ... i would try to go forward in images to see when it starts ... http://people.canonical.com/~ogra/touch-image-stats/ has all the changelogs
[18:32] <fginther> bfiller, the rerun passed, I re-approved the branch
[18:32] <bfiller> fginther: thanks
[18:35] <fginther> rsalveti, trial run of http://10.97.2.10:8080/job/phablet-team-ofono-ubuntu-ci/1/ passed
[18:36] <fginther> rsalveti, I want to make sure I understand correctly... developers will propose thier MPs against lp:~phablet-team/ofono/ubuntu, correct?
[18:36] <rsalveti> fginther: awesome
[18:36] <fginther> awe_, ^
[18:36] <rsalveti> fginther: correct
[18:37] <fginther> rsalveti, and lp:~phablet-team/ofono/rilmodem is just provided as a convenience, we don't actually need to build anything from that in ci?
[18:37] <awe_> it's where we get our upstream code
[18:37] <dobey> so, is system-settings supposed to freeze and/or crash all the time on the current image?
[18:37] <awe_> in order to create MPs
[18:37] <rsalveti> hm, can't reach 10.*, let me try restarting my vpn
[18:38] <fginther> rsalveti, jenkins is crawlllllling
[18:38] <rsalveti> oh, right then
[18:38] <fginther> as least the Web UI is for me
[18:38] <bfiller> fginther: can you see why I can't access the deb from this MR: https://code.launchpad.net/~thomas-moenicke/ubuntu-keyboard/ubuntu-keyboard-fix-loader/+merge/188878
[18:38] <bfiller> get Status Code 404 errors
[18:39] <fginther> bfiller, the build publisher is stuck, so data isn't currently making is way from 10.97.2.10:8080 to jenkins.qa.ubuntu.com
[18:40] <fginther> bfiller, retoaded is looking at it
[18:40] <bfiller> fginther: thanks
[18:41] <fginther> awe_, rsalveti, do we want something to automatically build updates of  lp:~phablet-team/ofono/rilmodem against the ubuntu branch (or do you already have launchpad setup to do that)?
[18:42] <rsalveti> fginther: not at this point, we'll be proposing mrs manually
[18:42] <fginther> rsalveti, thanks
[18:42] <rsalveti> that's why we only needed the CI for the ubuntu branch right now
[18:43] <rsalveti> yeah, still unable to load it
[18:46]  * ogra_ goes afk to watch the game
[18:46] <awe_> rsalveti, might not be a bad idea though?  We'd know ahead of time if something slipped through which breaks the build...
[18:47] <rsalveti> right, but let's see how this workflow works, then we can proposed this automerge/release
[18:47] <awe_> sure
[19:00] <robru> ugh, is anybody else experiencing launchpad issues? most pages won't load, i get lots of 'connection reset', etc. the pages that do load take several minutes to load
[19:07] <plars> ogra_: I'm seeing a lot of system-settle issues in 76
[19:07] <plars> ogra_: with "upstart-propert" (obviously truncated by top)
[19:08] <plars> upstart-property-watcher
[19:09] <fginther> cyphermox, can you review? https://code.launchpad.net/~fginther/cupstream2distro-config/add-ofono/+merge/188898
[19:09] <fginther> cyphermox, not sure if this is ready for daily-release or not.
[19:10] <rsalveti> plars: yeah, fix in progress, but need to trigger another android build and image
[19:10] <plars> rsalveti: ok, cool
[19:10] <plars> I guess the autopilot stuff didn't make it?
[19:12] <rsalveti> the mediaplayer one got fixed http://reports.qa.ubuntu.com/smokeng/saucy/touch_ro/4523/mediaplayer-app-autopilot/
[19:16] <thomi> fginther: got a second?
[19:16] <fginther> thomi, yes
[19:16] <thomi> fginther: can I download .deb files from CI runs?
[19:16] <fginther> thomi, normally you can
[19:16] <thomi> fginther: I don't have a cross compile setup, and I need armhf binary packages from this MP: https://code.launchpad.net/~robertcarr/mir/1233944-addendum/+merge/188900
[19:17] <fginther> thomi, I don't think we're archive debs for mir, let me check
[19:18] <fginther> thomi, I take that back, they are built, here's an example: https://jenkins.qa.ubuntu.com/job/mir-saucy-armhf-ci/76/
[19:21] <thomi> sweet
[19:22] <thomi> so I just need to wait for the CI job to finish...
[19:26] <cyphermox> fginther: thanks, just need a very minor change
[19:27] <fginther> cyphermox, ack
[19:32] <fginther> cyphermox, done
[19:42] <sergiusens> thomi, where's the code for upstart and click in autopilot again? need to add and APP_URIS entry
[19:43] <thomi> sergiusens: autopilot/testcase.py
[19:43] <sergiusens> thomi, thanks
[19:43] <thomi> sergiusens: make sure you base it on lp:autopilot/1.3!
[19:45] <sergiusens> thomi, ack
[19:52] <thomi> fginther: jenkins is down?
[19:52] <fginther> thomi, yes
[19:52] <thomi> :(
[19:53] <fginther> sad faces all around
[20:08] <fginther> thomi, jenkins is up
[20:09] <thomi> fginther: thanks
[20:14] <veebers> fginther: ping
[20:28] <fginther> veebers, pong
[20:34] <veebers> fginther: hey how are you?
[20:35] <fginther> veebers, good, how's life there?
[20:35] <veebers> fginther: not bad, sunny but windy today
[20:35] <veebers> fginther: following up on my email re: running the tests across the test apps
[20:36] <ralsina> fginther: I get errors from jenkins about it failing to contact launchpad, are you the person to know about that?  https://jenkins.qa.ubuntu.com/job/unity-scope-click-saucy-amd64-autolanding/38/console
[20:36] <fginther> ralsina, yes, one moment
[20:36] <ralsina> fginther: cool, thx
[20:38] <veebers> fginther: oh although I see jenkins is down; so perhaps this isn't the best time to bother you about that?
[20:39] <fginther> veebers, it just came back up. I was just looking at a job related to your request
[20:39] <veebers> fginther: ah awesome, thank you
[20:40] <fginther> ralsina, it's a transient failure, someone already approved the MP again so that it will be re-run (a fix for the underlying issue is in the works)
[20:40] <fginther> veebers, so
[20:40] <ralsina> fginther: awesome, we'll keep retrying then :-)
[20:41] <fginther> veebers, here's the job I ran to test autopilot/1.3 trunk: http://10.97.2.10:8080/job/autopilot-testrunner-otto-saucy-fjg/89
[20:41] <fginther> veebers, it appears to be stuck on the first test suite
[20:42] <veebers> fginther:  :-\ is there any output?
[20:43]  * veebers looks
[20:43] <fginther> veebers, it ran 347 autopilot tests, does that sound like the right number?
[20:45] <veebers> fginther: heh, um I'm not sure. I only really run them as separate testsuites
[20:46] <veebers> fginther: so it's no longer stuck on the first test suite?
[20:46] <veebers> ah, _now_ the page loads
[20:47] <fginther> veebers, guh!
[20:48] <fginther> veebers, I think it was caused by a bug in the runner script (something I added)
[20:52] <fginther> veebers, I don't quite understand, "autopilot run" had finished, but "tee $AP_LOGFILE" was still hanging around.
[20:54] <fginther> veebers, perhaps it didn't receive an EOF
[20:54] <fginther> veebers, it's finishing now
[20:55] <veebers> fginther: that's odd. I don't think that has anything to do with my changes though
[20:55] <fginther> veebers, this test was done using lp:autopilot/1.3
[20:55] <fginther> veebers, I can fire up another with your branch
[20:55] <veebers> fginther: ah I see, not running my branch. I understand now :-)
[20:58] <fginther> veebers, ok, lets see how this goes, which branch do you want tested?
[20:58] <veebers> fginther: awesome, lp:~veebers/autopilot/fixing_backend_being_none
[21:13] <fginther> veebers, I kicked off a touch and otto based job from your branch, details in email
[21:14] <thomi> fginther: I wonder if you could help me? I want to kick off http://10.97.2.10:8080/job/mir-saucy-armhf-ci/ for thsi MP: https://code.launchpad.net/~robertcarr/mir/1233944-addendum/+merge/188900 but some of the parameters in that job are kind of confusing...
[21:17] <fginther> thomi, http://10.97.2.10:8080/job/mir-saucy-armhf-ci/77/, If you're just doing a one-off build, all that's needed is the landing_candidate (the branch to build)
[21:17] <thomi> fginther: cool, thanks
[21:17] <fginther> thomi, beyond the defaults
[21:17] <thomi> right
[21:21] <veebers> fginther: awesome thanks
[21:26] <rsalveti> plars: pushed a new android package with the upstart-watcher fix
[21:26] <rsalveti> will spin a new image once that's in
[21:26] <plars> rsalveti: \o/
[21:27] <plars> rsalveti: I'm not going to obsess too much about the results on 76 - don't think it's worth it. I'll keep a closer eye on 77 when it comes out though
[21:27] <rsalveti> plars: yeah
[21:50] <rsalveti> lool: 77 will be to fix the upstart-property-watcher regression
[21:50] <rsalveti> we hope to get the ringtone regression at 78
[21:51] <rsalveti> lool: can you bump the image numbers in the spreadsheet?
[21:55] <lool> rsalveti: cool
[21:56] <lool> rsalveti: I did bump a few some minutes ago
[21:56] <rsalveti> great
[21:56] <rsalveti> I hope that just communicating this here should be enough
[21:57] <lool> rsalveti: yeah, look at bottom of landing pipeline, I added a slot for you
[21:58] <lool> like literally 10 mn ago
[21:58] <lool> was about to transform into a pumpkin
[21:58] <rsalveti> lool: right, but ringtone is still planned for 77
[21:58] <rsalveti> 77 will be for the upstart-property regression
[21:59] <rsalveti> 78 might hopefully be for the ringtone regression
[21:59] <lool> ah i forgot the other regression, that's right
[21:59] <lool> too many things to add
[21:59] <rsalveti> the pain to track everything manually :-)
[22:00] <lool> rsalveti: surprizing eh?
[22:00] <rsalveti> :-)
[22:00] <rsalveti> thanks for taking care of it
[22:00] <lool> 2 days without promoting images is quite bad
[22:01] <lool> rsalveti: so do you have some details about what the ringtones and upstart fixes entail?
[22:01] <lool> source packages and ETAs mainly
[22:02] <rsalveti> lool: upstart fix is already in, just waiting android to be migrated from proposed
[22:03] <rsalveti> ringtone I'm still investigating the issue
[22:08] <lool> rsalveti: https://launchpadlibrarian.net/152176453/android_20131002-0539-0ubuntu3_20131002-2036-0ubuntu1.diff.gz seemed to reverse other changes; was this intentional?
[22:08] <rsalveti> lool: that's a change that xnox pushed today
[22:08] <rsalveti> related with the goldfish target, which we're not yet using
[22:08] <rsalveti> so that's fine
[22:11] <lool> rsalveti: well, he's working on the emulator
[22:11] <lool> rsalveti: so you reverted his change and we want to reupload it, yes?  :-)
[22:11] <rsalveti> lool: well, he is the one that changed that upstream
[22:12] <rsalveti> so I believe he knows what he's doing in there
[22:12] <rsalveti> I just created a new dump from the repo
[22:13] <lool> rsalveti: ok, so you picked up a new change from upstream, this wasn't an accidental revert; thanks
[22:13] <rsalveti> lool: yeah
[22:21] <rsalveti> lool: android just got published, starting a new build
[22:22] <lool> rsalveti: thanks
[22:22] <lool> rsalveti: hold on
[22:22] <lool> rsalveti: it's not published in release pocket yet
[22:22] <lool>    android | 20131002-0539-0ubuntu3 | saucy/multiverse | source, all
[22:22] <lool>    android | 20131002-2036-0ubuntu1 | saucy-proposed/multiverse | source, all
[22:22] <lool> is what I see in rmadison
[22:22] <lool> don't trust LP web UI
[22:22] <rsalveti> lool: hm, seems to be here
[22:22] <rsalveti> crap
[22:22] <rsalveti> already started it
[22:22] <lool> rsalveti: it's ok, just build another one after that  :-)
[22:23] <rsalveti> well, let's see :-)
[22:41] <cjwatson> rsalveti: It wasn't visible to image builds until :26
[22:41] <cjwatson> 2013-10-02 22:26:51 DEBUG   Moving the new dists into place...
[22:42] <cjwatson> lool is correct, always use rmadison to check this
[22:42] <rsalveti> cjwatson: right, I thought I could trust the launchpad web ui =\
[22:42] <rsalveti> but thanks anyway
[22:43] <cjwatson> The Launchpad web UI reflects the database state, and the database state is flipped to published near the start of the publisher run
[22:43] <cjwatson> Launchpad doesn't actually really know when it hits disk as far as image builds are concerned
[22:43] <cjwatson> At least not in any way that the web UI can get at
[22:44] <rsalveti> right, I just thought that the launchpad ui/database would be the last step of the update/publish part
[22:44] <cjwatson> Nope
[22:44] <rsalveti> but don't know much how this is actually done internally, so thanks for the explanation
[22:46] <rsalveti> cjwatson: btw, is there a way to track the live-build log in realtime?
[22:50] <rsalveti> lool: ^
[22:50] <lool> from nusakan there might be
[22:52] <lool> I think http://%s/~buildd/LiveCD/%s/%s/latest/livecd-%s.out might be updated live if you know the right buildd
[22:53] <lool> rsalveti: http://kishi00.buildd/~buildd/LiveCD/saucy/ubuntu-touch/latest/livecd-armhf.out
[22:55] <rsalveti> lool: cool, thanks
[22:56] <rsalveti> lool: so the android bits are actually consumed later on
[22:56] <rsalveti> when creating the final image, so we might still be good
[22:57] <cjwatson> rsalveti: Yeah, from the DC you can, otherwise not until we get it into LP
[23:09] <veebers> fginther: still around?
[23:13] <veebers> fginther, thomi: Appears http://10.97.2.10:8080/job/autopilot-testrunner-otto-saucy/703/ has finished running. 3 failures, 2 for uut which I need to propose a fix too (creation of mock DbusIntroObj, __init__ now takes an extra argument)
[23:14] <thomi> veebers: uut shouldn't be creating that directly - what's it doing?
[23:15] <veebers> thomi: just looking now, looking at the log it's in the test_emulator suite, so I think it's to do with testing itself (and not in use when you use the emualtors in app tests)
[23:16] <thomi> veebers: OK, well those tests should probably live insdie lp:autopilot, since that's a private API
[23:16] <thomi> maybe add them to lp:autopilot, so we can remove them in uut
[23:17] <veebers> thomi: ok, just checking them out now to see what's involve
[23:17] <veebers> d
[23:19] <veebers> thomi: oh and there was the issue that doanac brought up, but I saw that on my system regardless of which autopilot was used, so I think it's an issue outside of autopilot (probably with the test etc.)
[23:20] <doanac> veebers: its not an issue here: http://reports.qa.ubuntu.com/smokeng/saucy/touch_ro/4523/unity8-autopilot/
[23:20] <doanac> we run each of those autopilot tests 1 by 1
[23:21] <doanac> i'm not opposed to landing the branch, but it will cause 2 tests to fail in unity8 that aren't failing now
[23:22]  * doanac has to step away for dinner
[23:22] <veebers> doanac: How are the tests on that dash run? It says touch_ro, but I'm pretty confident that the unity8 tests won't run without installing the dep. deb?