[00:02] <robru> cyphermox, are you on utopic already? I was a little bit afraid of upgrading just yet ;-)
[00:02] <cyphermox> I am
[00:02] <cyphermox> this early it's probably safe-ish
[00:02] <robru> kgunn, still waiting on the media-hub landing before we can push mir
[00:02] <cyphermox> some point soon things might start breaking
[00:03] <cyphermox> robru: it always depends on whether you're in a position to fix things yourself if they break badly enough
[00:03] <robru> cyphermox, true. at home I have the resources to format & reinstall if things get really bad ;-)
[00:04] <robru> I think it was about 3 weeks into the cycle that I upgraded to trusty, that went mostly pretty well for me
[00:11] <kgunn> robru: thanks, i'll just hang loose
[00:12] <robru> kgunn, yeah, sorry for the delay, it seems this issue with media-hub is quite large.
[00:15] <robru> kgunn, actually just double checked, the problem seems to be "resolved", just waiting for some stuff to get copied around. should be fixed for real pretty soon I guess. oh but then you have to wait at least an hour after that for the image build. so yeah, probably 2-3 hours I think before I can publish mir.
[00:15] <robru> rsalveti, cyphermox : either of you going to be around to kick an image build in an hour or so?
[00:16] <cyphermox> i'll be around
[00:22] <rsalveti> robru: I'll be around as well
[00:23] <robru> rsalveti, cyphermox : cool. so gst-plugins-bad1.0 says valid candidate in the excuses page, should sync soonish I guess.
[00:32] <cyphermox> robru: no, you need to look at http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt too
[00:41] <robru> cyphermox, what? how do I interpret that?
[00:53] <cyphermox> ah, grep for the pacakge you're looking for basically, and it shows the attempts the scripts did at installing the packages
[00:54] <cyphermox> seems like it's basically stuck in multiple transitions, as it was discussed on #ubuntu-release earlier
[00:55] <robru> cyphermox, so what does it mean then? are the transitions happening or is it just blocked?
[00:56] <cyphermox> it's blocked by a shitload of packages due, among others, to an openjpeg transition
[00:57] <robru> cyphermox, right, but the openjpeg transition itself isn't blocked is it?
[00:57] <cyphermox> probably not but some packages are not transitioning and holding back gst-plugins-bad1.0
[00:58] <robru> cyphermox, well, what do you think: worth waiting for, or should we just kick an image build without it, let media-hub be broken for now, and then unblock mir?
[00:58] <cyphermox> oh is mir going to be affected by this?
[00:58] <cyphermox> s/oh/how/
[00:59] <cyphermox> gst-plugins* only contain codecs.
[00:59] <robru> cyphermox, well, mir is blocked waiting for the image build, which is blocked waiting for the media-hub silo finishing it's landing, which gst-plugins-bad is part of, which is blocked by openjpeg
[00:59] <cyphermox> assuming there are others installed (like, -good or whatnot) I'd expect at least some videos to be able to play in media-hub
[00:59] <robru> cyphermox, you'd expect so, but it's untested ;-)
[01:01] <cyphermox> meh
[01:01] <cyphermox> plugins remain plugins as far as gstreamer is concerned
[01:01] <cyphermox> as long as they're all the same version
[01:02] <cyphermox> if not, then media-hub is brain-damaged
[01:04] <robru> cyphermox, so kick an image then ;-)
[01:04] <cyphermox> heh, why not
[01:09] <cyphermox> well we can already make sure while this runs that at least the reverse-depends of gst-plugins-bad1.0 wwork
[01:10] <cyphermox> though it looks like those would be fine..
[01:14] <cyphermox> yeah, both the transitions affecting gst should be done already (100%)
[01:16] <cyphermox> so it's more like mess to clear up in the transitions in general
[01:17] <cyphermox> robru: surely you wanted me to kick an image?
[01:18] <robru> cyphermox, yeah, I did. is there a reason not to? rsalveti disabled the cron job (which would be running about now anyway...) because we were waiting for this gst thing
[01:18] <cyphermox> nah, it was fine to do
[01:18] <AlbertA> cihelp: we got some failures with the mako runner: https://jenkins.qa.ubuntu.com/job/mir-mediumtests-runner-mako/1238/console
[01:18] <AlbertA> https://code.launchpad.net/~mir-team/mir/popen-cpp-wrapper/+merge/217831
[01:18] <cyphermox> worst we will have is an broken image
[01:19] <AlbertA> cihelp: https://jenkins.qa.ubuntu.com/job/mir-mediumtests-runner-mako/1244/console
[01:19] <AlbertA> cihelp: looks like the same failure on all those MP's
[01:23] <robru> cyphermox, have you seen any problems with freeing silos? I just noticed that silos I freed hours ago are still showing as used in the spreadsheet. had to manually poke the status to reflect reality
[01:24] <cyphermox> haven't noticed
[01:26] <cyphermox> I get a fatal error trying to assign a silo for line 14 though
[01:31] <robru> cyphermox, what error?
[01:32] <cyphermox> a generic fatal error from google
[01:33] <robru> cyphermox, oh yeah, it's giving me that too
[01:34] <robru> cyphermox, it's weird, like every thing i click in the spreadsheet gives that fatal error, but then my changes are saved anyway
[01:44] <thomi> robru: cyphermox: are one of you two please able to hit the 'Merge & CLean' btn on silo 18 for me please? I need my phone for 2fa in order to run the jenkins job, and it's charging :(
[01:44] <robru> thomi, yeah I did already ;-)
[01:44] <thomi> robru: oh - the SS shows it still filled in. I guess that's what you were saying before
[01:45] <thomi> thanks :)
[01:45] <robru> thomi, oh really? crap, I guess the changes I made in the spreadsheet aren't getting synced. yeah, something goofy is goingon
[01:45] <robru> thomi, you're welcome
[02:13] <jhodapp> robru, has media-hub successfully landed?
[02:14] <robru> jhodapp, I can proudly report, a resounding... kind of!
[02:14] <jhodapp> ha!
[02:14] <jhodapp> robru, what's going on?
[02:14] <robru> jhodapp, basically yeah, but part of that landing was gst-plugins-bad1.0, which got stuck in proposed
[02:14] <jhodapp> robru, why did it get stuck?
[02:15] <robru> jhodapp, because it depends on some stuff that's blocked my some other stuff. basically there's a huge transition going on
[02:15] <jhodapp> oh gosh
[02:15] <robru> jhodapp, i don't understand it much myself but infinity has been wrestling with it for most of the day.
[02:16] <jhodapp> robru, ok, that's good that it's being worked on
[02:16] <robru> jhodapp, so, I'm not sure how much of an impact that will have; theoretically media-hub is in place and should work extremely well, except for whatever was wrong with the bad plugins, those are still broken
[02:16] <robru> jhodapp, hopefully whatever was wrong with those plugins isn't capable of causing crashes in media-hub
[02:17] <robru> cyphermox, hey did you kick that image build? why didn't the bot say anything?
[02:17] <cyphermox> dude, I asked you this before, I thought you said you kicked it?
[02:17] <cyphermox> I wondered how you could have, but permissions do change
[02:18] <cyphermox> doing nao
[02:18] <jhodapp> robru, well it is needed for video playback to work at all, but music playback should work
[02:18] <cyphermox> do we usually kick both armhf and i386 now?
[02:24] <robru> cyphermox, oh, sorry. just read the scrollback. when I said "I did", what I meant was that I did ask you, not that I did do it. I can see how that would have been confusing.
[02:24] <robru> cyphermox, i still don't have perms, no
[02:24] <cyphermox> right
[02:24] <cyphermox> well it's done now anyway
[02:24] <robru> cyphermox, great, thanks. i'm not sure about the arches
[02:24] <imgbot> [02:25] <robru> i guess so, because of the emulator
[02:25] <cyphermox> I kicked both, since i386 would be the emulator yeah
[02:46] <jhodapp> robru, so I should check in with infinity in the morning for media-hub status?
[02:46] <robru> jhodapp, you can if you want to. I like to think he'll be done soon
[02:47] <jhodapp> oh he's working on it right now then?
[03:04] <robru> jhodapp|afk, as far as I know, yeah. I pinged him about it originally 7 hours ago and he's been busy looking ever since ;-)
[03:05] <robru> busy-looking ;-)
[03:15] <fginther> AlbertA, I've noted the failure. At the moment, I have no idea why it's failing but will start digging
[03:59] <imgbot> [04:00] <imgbot> [04:31]  * rsalveti back
[04:32] <rsalveti> hm, gst still not in release
[04:33] <rsalveti> huge changelog though
[04:49] <cyphermox> nope, it's stuck in britney in a big blob of text ;)
[04:50] <rsalveti> cyphermox: just promoted
[04:50] <cyphermox> yay
[04:50] <rsalveti> at least the video playback might work with apt-get update/upgrade
[04:50] <rsalveti> want to demo this tomorrow lol
[04:51] <cyphermox> shouldn't it work anyway with a different codec from like, good?
[04:53] <rsalveti> no, we don't yet support software decode (we can't render it)
[04:53] <rsalveti> I know, it's bad
[04:54] <rsalveti> old bug
[04:54] <cyphermox> ugh :/
[04:54] <rsalveti> jhodapp|afk need to find time to get that fixed
[04:54] <cyphermox> oh, right, bad was a patch for mir stuffs
[04:54] <rsalveti> hopefully now that media-hub finally landed
[04:54] <rsalveti> yeah
[04:54] <cyphermox> it's far too late for me to think much
[04:54] <rsalveti> indeed
[04:55] <cyphermox> just trying to finish building unity here so I can resume watching this tv show / seminar about physics and stuff by Neil deGrasse Tyson :)
[05:09] <rsalveti> he's awesome :-)
[05:38] <cyphermox> that is true
[05:38] <cyphermox> the show is quite interesting
[05:39] <cyphermox> right now it's dark matter / dark energy
[06:51] <jamesh> Would anyone be able to help me in getting a Jenkins job reconfigured?
[06:51] <jamesh> https://jenkins.qa.ubuntu.com/job/unity-scope-mediascanner-ci/ is testing branches in a trusty environment, when it should be against utopic
[08:39] <alan_g> psivaa: can you help with "W: Failed to fetch http://ppa.launchpad.net/chris.gagnon/mir-demo-tester/ubuntu/dists/utopic/main/binary-armhf/Packages  404  Not Found" - https://jenkins.qa.ubuntu.com/job/mir-mediumtests-runner-mako/1255/console
[08:39] <psivaa> alan_g: let me take a look
[08:52] <psivaa> alan_g: https://launchpad.net/~chris.gagnon/+archive/mir-demo-tester/+packages says 'mir-demo-tester' is only available for trusty under chrisgagnon's ppas
[09:04] <alan_g> psivaa: thanks. I guess I'll have to bug Chris when he appears.
[09:05] <psivaa> alan_g: ack. np
[09:45] <mhr3> wonder if i can get a silo today?
[09:45] <mhr3> trainguards?
[09:55] <mhr3> guess that's a no
[10:14] <Mirv> mhr3: I can put one, since I couldn't restrict myself from glancing at irc..
[10:14] <mhr3> Mirv, woo :) let me add it to the spreadsheet
[10:15] <mhr3> uh oh, i think the spreadsheet is dying
[10:17] <Mirv> mhr3: yeah I just noticed
[10:17] <Mirv> I've never seen that, so it might mean it's a "no" after all :(
[10:20] <Mirv> mhr3: yeah, I've unfortunately zero ideas how to debug that
[10:20] <Mirv> didrocks should be here tomorrow (and me too...) but not sure what could be tried before that
[10:20] <mhr3> shit
[10:21] <Mirv> oh, wait
[10:21] <mhr3> just created a new sheet inadvertedly
[10:21] <Mirv> there's an request id there, so maybe the backend will just work when called directly
[10:22] <Mirv> mhr3: yep, landing-007 for you sir
[10:23] <mhr3> Mirv, maybe try restarting the bot, gdocs don't like long lived connections
[10:24] <Mirv> mhr3: done. but I believe there might be something funny with osomon's landing since it does not have request ID assigned.
[10:25] <Mirv> there was a case where there was a funny utf-8 char in description once..
[10:27] <mhr3> the spreadsheet itself saying that its last edit was yesterday isn't a good sign
[10:28] <Mirv> mhr3: you should be able to run https://ci-train.ubuntu.com/job/landing-007-1-build/ though
[10:28] <Mirv> mandel: (and sergiusens) you have landing-008 for MMS and same applies the backend should work
[10:30] <Mirv> there's nothing in the revision history that seemingly broke things, thins just stoppe
[10:38] <Mirv> ok I'm gone again, I couldn't think of anything more to fix the issue
[10:42] <ogra_> does anyone mind if i kick an image (a for Mir and b for finishing the media-hub landing which is only half breeded in image 6)
[10:43] <ogra_> no complaints ? ...
[10:43] <t1mp> ogra_: nobody is around to object :)
[10:43] <ogra_> yeah, i was hoping so :)
[10:43] <ogra_> (i'm not around either ... just looks like it ;) )
[10:44]  * ogra_ triggers a build then ... i know rsalveti wants to demo media-hub today at a conference 
[10:51] <popey> brave
[10:56] <davmor2> ogra_: Are we nearly there yet?
[10:57] <davmor2> ogra_: I seem to recall that you are on holiday right
[10:59] <ogra_> i am
[11:00] <ogra_> bah, where is the bot ?
[11:01] <ogra_> ah, better
[11:06] <ogra_> imgbot, stop
[11:06] <imgbot> AAAAARRRGH !!! (dying)
[11:07] <davmor2> ogra_: killed the bot, bad ogra_  ;)
[11:07] <ogra_> :)
[11:56] <davmor2> jhodapp: ogra_ just span up a new image with mir and the rest of media-hub :)
[12:11] <jhodapp> davmor2, yay!
[12:11] <jhodapp> davmor2, you're my hero!
[12:11] <davmor2> jhodapp: no ogra_ is I'm just the messenger :)
[12:14] <imgbot> [12:14] <imgbot> [12:15] <ogra_> that looks good :)
[12:19]  * davmor2 tries music from the dash letting the screen blank as a first test
[12:20] <davmor2> hmmm music stops dead on screen blank, I'll try it from the player now
[12:22] <davmor2> ogra_: the mir stuff is the Qt event loop stuff right?
[12:24] <popey> davmor2: is the network/dns issue fixed in #7?
[12:24] <davmor2> popey: not that I know to
[12:24] <popey> ok
[12:25] <davmor2> volume works when the screen is blank Yay, Next track music plays from player too woohoo!!!!!!
[12:26] <davmor2> times right too\o/
[12:27] <popey> nice
[12:33] <pmcgowan> popey, davmor2 my updater is not showing any download progress, ever seen that?
[12:33] <popey> yes
[12:34] <pmcgowan> does it download anyway?
[12:34] <popey> yes
[12:34] <popey> bug 1307683
[12:35] <pmcgowan> working after reboot
[12:39]  * popey plays a song and waits for the next one
[12:40] <popey> \o/ another song plays while phone locked
[12:41] <jhodapp> davmor2, did the image with media-hub finish?
[12:41] <popey> jhodapp: yup
[12:41] <popey> running it here
[12:41] <popey> #7
[12:41] <popey> http://people.canonical.com/~ogra/touch-image-stats/7.changes
[12:42] <pmcgowan> jhodapp is like an expectant father
[12:42] <jhodapp> lol
[12:42] <jhodapp> it felt like it was cooking for months!
[12:42] <jhodapp> popey, video is working for you on that image?
[12:43] <popey> yes
[12:43] <jhodapp> excellent, that means everything made it in
[12:43]  * jhodapp reflashes
[12:44] <popey> looks like mirscreencast broke
[12:44]  * popey fiddles more
[12:45] <popey> jhodapp: video froze after a while
[12:45] <popey> audio still playing but I have a still frame now
[12:45] <jhodapp> popey, yeah I've seen that
[12:46] <jhodapp> popey, it's a high priority bug to fix
[12:46] <popey> k
[12:46] <jhodapp> popey, which channel did you flash?
[12:46] <popey> ubuntu-touch/devel-proposed
[12:46] <jhodapp> cool
[12:47] <popey> hah, mirscreencast now adds "60Hz" to the end of the filename.
[12:47] <jhodapp> lol
[12:48] <jhodapp> popey, try this out: play music in the background and then start playing a video
[12:48] <popey> ok
[12:48] <jhodapp> popey, then swipe back to the music app
[12:48] <pmcgowan> jhodapp, works here
[12:48] <popey> music app is paused
[12:48] <popey> i mean, music is paused
[12:48] <jhodapp> yeah :)
[12:48] <jhodapp> love that feature
[12:49] <popey> nice work!
[12:49] <jhodapp> thanks
[12:49] <jhodapp> I'm working on pausing video when you press the power button and also when a phone call comes in
[13:10] <plars> ogra_: are you around today?
[13:12] <plars> ogra_: I was discussing a problem I'm seeing on a device with sergio yesterday. It seems to complete the flash just fine but never reboots out of recovery into the installed images. Tried multiple different images with the same result, tried fastboot -w, etc. It just never makes it to the reboot but I'm not finding any indication why
[13:13] <plars> ogra_: our best guess was that it was something wrong with that particular device since every other one I tried worked just fine, but last night fginther told me he's got 3 more that seem to have the same symptom
[13:13] <plars> rsalveti: maybe you have some ideas also? ^
[13:35] <popey> plars: he's on vacation
[13:35] <plars> popey: yeah, I thought that might be the case
[13:35] <plars> popey: but I wanted to go ahead and get it out there in case others might have an idea
[13:35] <popey> sure ☻
[13:41] <popey> bfiller: do you have an ETA for the syncmonitor update landing, this merge is blocked on it. https://code.launchpad.net/~renatofilho/ubuntu-calendar-app/fix-1311125/+merge/217251
[13:44] <popey> Man, image 7 is so much better, night and day in terms of usability
[13:45] <bfiller> popey: the problem is sync-monitor (on line 21) is an SRU candidate and is in trusty-proposed. waiting for that to get accepted and flowed into U before we can push additional sync-monitor changes
[13:46] <bfiller> popey: not sure if there is another way to do that
[13:46] <popey> Hm, I thought we usually went the other way. Put it in +1 and backport to current stable.
[13:47] <Laney> You can upload the same thing (+ more changes) to U, no need to wait for the SRU
[13:48] <popey> \o/
[13:49] <Laney> (Unless the train gives you problems here)
[13:51] <plars> jhodapp: is mediaplayer_app your fault? :)
[13:52] <plars> http://ci.ubuntu.com/smokeng/utopic/touch/mako/7:20140501.1:20140501/7833/mediaplayer_app/
[13:56] <jhodapp> plars, lol
[13:57] <jhodapp> plars, ugg
[13:57] <jhodapp> plars, so I wasn't able to test on mako because I don't have one
[13:59] <plars> jhodapp: fails on flo also it seems
[13:59] <jhodapp> plars, sigh
[13:59] <plars> not sure about manta yet, I had to restart that one
[14:00] <davmor2> popey: with your screen blank can you call the phone?
[14:02] <jhodapp> plars, not sure why they're failing yet, they were working for me
[14:02] <jhodapp> plars, all of them
[14:02] <davmor2> popey: reboot fixed it for me was just ringing to answer machine
[14:03] <plars> jhodapp: looks like mediaplayer is one of them that still uses a deb package for the tests
[14:03] <jhodapp> plars, yeah
[14:03] <plars> jhodapp: you may want to try a fresh install of this image if you haven't already
[14:03] <plars> jhodapp: I can try it at home also
[14:03] <plars> maybe something else interacted badly with it?
[14:03] <jhodapp> plars, just did, let me give the tests a try locally
[14:03] <plars> jhodapp: what do you have locally to test with?
[14:04] <jhodapp> plars, flo
[14:04] <plars> ok
[14:04] <jhodapp> plars, but I ordered a mako on ebay and will be getting it by Monday
[14:07] <jhodapp> plars, it seems it can't find the video to play
[14:09] <bfiller> Laney: ok thanks, do we clean the silo then?
[14:09] <Laney> bfiller: I'm not sure what the train says you should do
[14:09] <Laney> bfiller: I just mean that it's a standard thing to do from the distro's pov
[14:09] <bfiller> ok
[14:10] <Laney> but I would assume so, then if there's a problem you'll branch and re-land from a trusty branch
[14:10] <Laney> one of the US guys should be able to advise further
[14:10] <jhodapp> plars, should be able to figure it out
[14:17] <Saviq> cjohnston, hey, apparently there's an issue with the unity8-ci job: https://jenkins.qa.ubuntu.com/job/unity8-ci/2897/console
[14:18] <Saviq> cjohnston, all child jobs completed fine, but artifcat collection failed
[14:18] <cjohnston> looking
[14:20] <Saviq> cjohnston, looks like it's trying to grep for the wrong job name
[14:21] <Saviq> or actually for one that was disabled completely
[14:21] <Saviq> generic-mediumtests-trusty
[14:21] <Saviq> cjohnston, ↑
[14:21] <cjohnston> Saviq: ack.. I'm talking with fginther and he thinks there is a config bug
[14:22] <fginther> cjohnston, Saviq, yep, I think I know what this is now.
[14:22] <fginther> cjohnston, Saviq, I'll have an mp to correct it shortly
[14:23] <Saviq> fginther, thanks
[14:26] <fginther> cjohnston, can you review: https://code.launchpad.net/~fginther/cupstream2distro-config/fix-unity8-aggregate-tests/+merge/217922
[14:27] <cjohnston> done
[14:28] <fginther> danke
[14:41] <bfiller> anyone on silo duty? need a silo for line 50 please
[14:43] <davmor2> pmcgowan: popey: we have a serious issue on r7 if the screen is blank for any length of time the phone no longer receives incoming calls
[14:46] <pmcgowan> davmor2, any more info?
[14:47] <pmcgowan> davmor2, do you have it not plugged into usb?
[14:50] <pmcgowan> davmor2, did the phone resume properly when you hit power?
[14:57] <davmor2> pmcgowan: sorry about that on a call.
[14:58] <pmcgowan> davmor2, ok, working fine so far here
[14:59] <davmor2> pmcgowan: so I dropped my wife off at the hospice, came back updated to 7 ran a few tests everything was fine, Moved of to the packaging part of my job did some work there and my wife rang me to pick her up it went straight through to answer machine.  I rebooted it and then it worked again, I went down to the hospice picked her up and came back maybe 30minutes and it's was dead again till I made a call out
[15:00] <davmor2> pmcgowan: only happens for me when the screen it blank for a while
[15:00] <pmcgowan> davmor2, almost sounds like it was busy
[15:00] <pmcgowan> hmm
[15:01] <davmor2> pmcgowan: I'm wondering if ofono needs a tweak to work with the new qt event loop code?
[15:01] <pmcgowan> davmor2, I think it would be more consistently not working then
[15:04] <davmor2> pmcgowan: I'll keep an eye on it
[15:36] <plars> anyone have a manta and seeing issues with the device coming in/out of availability in adb?
[15:38] <fginther> AlbertA, the mir-mediumtests-runner-mako issue appears to be fixed now. Watching a few more builds to make sure they don't blow up
[15:50]  * davmor2 hug jhodapp|lunch music mute on an incoming call
[16:07] <popey> robru: bfiller was asking for a silo for line 50 earlier, dunno if anyone else picked up on it, maybe one for after your coffee
[16:08] <robru> popey, sure, thanks
[16:15] <bfiller> robru: hoping we can do a merge and clean on silo 1 as well, as it's in trusty-propsosed
[16:15] <robru> bfiller, sure
[16:15] <mhr3> robru, also if you could publish 007 pls
[16:15] <robru> bfiller, started a build for you: https://ci-train.ubuntu.com/job/landing-004-1-build/44/console
[16:16] <bfiller> great
[16:18] <AlbertA> fginther: thanks!
[16:18] <robru> mhr3, what's going on in silo 7? the spreadsheet seems very confused
[16:18] <mhr3> robru, the spreadsheet is broken, whatever is updating it doesn't work
[16:18] <robru> yeah I can see that!
[16:19] <rsalveti> plars: what is the behavior with recovery? can you access it via adb at least? (issue about not being able to reboot the phone)
[16:20] <rsalveti> davmor2: did you get any crash when you were not able to get the phone call?
[16:20] <rsalveti> that's a critical one, wonder how we can easily reproduce that
[16:21] <rsalveti> in case you get it again, we can enable debug mode in powerd and ofono to see what is going on in there
[16:22] <davmor2> rsalveti: lets have a look
[16:23] <davmor2> _sbin_cgproxy.0.crash
[16:23] <davmor2> _usr_bin_unity8.32011.crash
[16:24] <davmor2> the rest are apps
[16:24] <davmor2> rsalveti: ^
[16:24] <rsalveti> haha, quite a few crashes :-)
[16:24] <robru> rsalveti, hey, did you re-renable the cron job for kicking images?
[16:24] <rsalveti> but yeah, at least not ofono related
[16:24] <rsalveti> robru: not yet, will do it now
[16:24] <robru> rsalveti, thanks
[16:24] <rsalveti> robru: done
[16:25] <robru> rsalveti, thanks!
[16:26] <davmor2> rsalveti: http://paste.ubuntu.com/7374028/ this is the full list
[16:26] <davmor2> rsalveti: so only cgproxy today
[16:26] <plars> rsalveti: yeah, I can get on it with adb just fine
[16:26] <plars> rsalveti: I see messages in the log indicating the install completed, but it just never reboots
[16:27] <rsalveti> plars: so adb reboot tails but can you call adb shell reboot?
[16:27] <rsalveti> davmor2: bunch of crashes, but probably not related
[16:28] <plars> rsalveti: yes, and adb reboot works fine
[16:28] <mhr3> davmor2, you know apport won't overwrite existing crash file, right?
[16:28] <mhr3> davmor2, so if for example unity8 crashed for you right now, there wouldn't be a new .crash
[16:28] <rsalveti> plars: hm, ok, so do you mean it's just not rebooting automatically after flashing it?
[16:28] <davmor2> mhr3: ah okay I'll wipe the lot and see what I get :)
[16:29] <plars> rsalveti: exactly
[16:29] <plars> I'm about to try out one of fginther's phones to see if it's for sure the same problem. he was thinking earlier it might not be
[16:31] <rsalveti> plars: could be, would be weird as we didn't change the recovery itself
[16:31] <rsalveti> plars: do you have the flashing logs from recovery?
[16:31] <plars> rsalveti: yep, one sec and I can pastebin some stuff
[16:32] <fginther> plars, rsalveti, the general problem I see is the 'adb reboot-bootloader' doesn't actually go to the bootloader, it just does a reboot
[16:32] <plars> rsalveti: http://paste.ubuntu.com/7374087/ is the last_log
[16:32] <plars> fginther: ah, that would be different from what I'm describing
[16:32] <plars> fginther: though it just worked for me on that device you pointed me to
[16:33] <plars> fginther: I started off with reboot-bootloader and I'm flashing now
[16:33] <fginther> plars, hmm
[16:33] <plars> rsalveti: /tmp/recovery.log http://paste.ubuntu.com/7374098/
[16:33] <plars> rsalveti: dmesg http://paste.ubuntu.com/7374102/
[16:33] <plars> fginther: oh wait, maybe not
[16:34] <plars> fginther: looked like it was going but it's not
[16:35] <rsalveti> fginther: did that start with a specific image?
[16:36] <plars> rsalveti: this was on a device that was not part of our regular testing, it's been instrumented with relays on the power/volume buttons, which made me suspicious at first, but I'm not seeing any reason why that would matter
[16:37] <plars> the relays are off while this is all happening, so it should just be a normal device
[16:37] <fginther> rsalveti, yes, they probably all have ubuntu-touch/trusty-proposed 303
[16:37] <rsalveti> indeed
[16:38] <rsalveti> nothing changed in recovery and android in that version specifically, weird
[16:38] <plars> fginther: yeah, that device is hosed, reboot -f bootloader doesn't even work
[16:38] <plars> fginther: all 3 of the ones you showed me last night are having the same "no boot into fastboot" issue?
[16:39] <rsalveti> yeah, if reboot itself fails, some other issue is going on
[16:39] <plars> it's rebooting, just not into fastboot
[16:39] <rsalveti> oh, hm
[16:39] <rsalveti> plars: can you check /proc/cmdline?
[16:40] <rsalveti> but that will not tell you the right bootmode it'd use to get inside the bootloader
[16:40] <fginther> plars, yes
[16:40] <davmor2> oh but I did get this again _sbin_cgproxy.0.crash
[16:40] <rsalveti> davmor2: this is happening for every image it seems
[16:41] <plars> rsalveti: I can check it on  fginther's device right now, the one with the no fastboot problem:
[16:41] <plars> console=ttyHSL0,115200,n8 androidboot.hardware=mako lpj=67677 user_debug=31 uart_console=enable lcd_maker_id=primary lge.hreset=off lge.reset=mode_reset gpt=enable lge.kcal=0|0|0|x lge.rev=rev_11 mdm_force_dump_enabled androidboot.emmc=true androidboot.serialno=04ccca120acd4dea androidboot.bootloader=MAKOZ10o androidboot.baseband=mdm bootreason=watchdog
[16:41] <davmor2> rsalveti: yeah I wipe all my crashes prior to going out though so this is fresh :)
[16:41] <plars> that was after an adb reboot bootloader
[16:41] <rsalveti> bootreason=watchdog
[16:41] <davmor2> rsalveti: and the only thing I've done is called the phone :)
[16:42] <rsalveti> wonder why that and if normal
[16:42] <davmor2> I'm assuming nm might of reconnected to the network too
[16:42] <rsalveti> right
[16:42] <bfiller> is the CI Train spreadsheet screwed up for everyone? either maxs my cpu or won't load
[16:50] <rsalveti> plars: it seems bootreason=watchdog means that the device was booted because you had a usb cable connected to it
[16:50] <rsalveti> you usually see 'reboot' or 'fastboot' as reason when booting with adb reboot and such
[16:50] <plars> there's a usb cable connected for sure :)
[16:51] <plars> but not newly so
[16:51] <plars> rsalveti: so I have mako-12 in that stuck state also now, if there's any other information that would be useful from it
[16:52] <rsalveti> plars: right, but I mean, it was powered because it had a usb connection, not because anyone requested it to boot
[16:53] <rsalveti> plars: is this the utopic based image?
[16:53] <plars> fginther: we may want to see if we can get rfowler to start fresh on those devices also - I was going to see about trying something similar with mako-12
[16:53] <plars> rsalveti: I've tried ubuntu-touch/stable /trusty-proposed and utopic-proposed
[16:53] <plars> rsalveti: on mako-12
[16:54] <plars> rsalveti: on fginther's, it's on trusty 303 right now
[16:54] <plars> which was the last one iirc
[16:54] <rsalveti> yeah, not sure yet what might be wrong then
[16:54] <boiko> robru: hey, so I ran merge&clean on landing-006, but now it is saying packages built!?
[16:55] <robru> boiko, yeah the spreadsheet is messed up. trust no one
[16:55] <boiko> robru: ah ok, well, at least the changes got merged correctly, so can I simply ignore that or do I need to run some jobs again to get it to a consistent state?
[16:55] <robru> boiko, http://people.canonical.com/~rbpark/citrain/ here is a simple dashboard that bypasses the spreadsheet and tells you directly the backend status of the system, much more trustworthy. it shows silo 6 cleaned.
[16:56] <boiko> robru: nice! thanks
[16:56] <robru> boiko, not much we can do, just waiting for google to stop sucking out loud
[16:56] <robru> boiko, yw
[16:56] <boiko> robru: lol, ok
[17:07] <davmor2> plars: are the clock tests around alarms edit by any chance?  If I try and edit an alarm the app crashes
[17:09] <plars> davmor2: looks like, yeah: http://ci.ubuntu.com/smokeng/utopic/touch/mako/7:20140501.1:20140501/7833/ubuntu_clock_app/
[17:11] <davmor2> plars: so looking at this on flo once you set an alarm if you go back to the alarm page and touch the alarm in anyway it crashes the app.  popey is this the bug that reported or not?  If so I can confirm it or write a new one
[17:11] <popey> bug 1309057
[17:12] <davmor2> popey: thanks
[17:15] <popey> np
[17:18] <robru> bfiller, gallery-app landed and I cleaned your silo, IIRC you need to update the click package now?
[17:18] <bfiller> robru: yes, need popey or sergio to help with that part
[17:18] <xnox> how to get notes-app released?
[17:19] <xnox> does it need to get merged into trunk first, and then get click released?
[17:19] <bfiller> xnox: yes
[17:19] <xnox> i'm after https://code.launchpad.net/~xnox/notes-app/py32/+merge/210254
[17:19] <bfiller> xnox: I'll request a silo for that
[17:19] <xnox> bfiller: \o/ thanks a lot!
[17:19] <popey> bfiller: i can't upload to store, balloons, mirv, sergio can. I can accept once uploaded though, but I'd urge whoever uploads (or whoever requests upload) to run all AP tests and provide log of success to speed that approval up.
[17:20] <xnox> popey: well, i can do uploads as well. which click/thing i need to run tests on?
[17:20]  * xnox upgrades phone to latest.
[17:21] <bfiller> popey: ok now that gallery changes are merged into trunk I can create a click to actually test run AP on the device
[17:21] <bfiller> have not done that yet
[17:21] <balloons> ping if you need me, sounds like xnox has it :-)
[17:22] <bfiller> robru: argh, looks like google ate a few of my silo requests (:
[17:23] <robru> bfiller, yeah, the spreadsheet is really bizarre right now, lots of sync issues going on
[17:23] <bfiller> robru: should I hold off on adding new requests to it until it's better?
[17:24] <robru> bfiller, depends, you got anything urgent? there are free silos available, if you add a request I can try to get the silo assigned before the spreadsheet reverts
[17:24] <balloons> ping fginther
[17:24] <bfiller> robru: not urgent, I'll just wait
[17:24] <xnox> bfiller: i thought there is a jenkins jobs that generates clicks. last time i fetched click from jenkins.
[17:24] <popey> xnox: balloons can guide you through that, but I generally do this:- http://paste.ubuntu.com/7331155/
[17:25] <bfiller> xnox: there is, but I think it's per MR. My landing had about 6 MR's associated with it. Don't think CI Train generates the resultant click
[17:25] <bfiller> would really like it to though :)
[17:26] <balloons> bfiller, if you can get it into one branch that helps ;)
[17:27] <balloons> all has to merge down sometime right?
[17:27] <bfiller> balloons: should all be in trunk as the silo has been published
[17:34] <jhodapp> davmor2, I'll be adding mute on phone call very soon :)
[17:35] <robru> mandel, i started building udm in silo 1
[17:48] <cyphermox> bschaefer: still good for me to upload the autopilot dep change for unity, while I'm not forgetting it? :)
[17:48] <fginther> balloons, pong
[17:48] <bschaefer> cyphermox, yeah :)
[17:48] <cyphermox> alrighty
[17:50] <bschaefer> cyphermox, thanks!
[17:50] <balloons> fginther, trying to nail down what testsuite name jenkins wants to run reminders with. https://code.launchpad.net/~elopio/reminders-app/test_go_to_accounts2/+merge/214163. Is it reminders, or reminders_app?
[17:51] <balloons> fginther, we'd like it to just be reminders.. and I *think* that's why the merge is failing. I was playing with my own merge to discover what it needs to be and thought I'd just ping and get it set properly
[17:52] <fginther> balloons, jenkins is using 'reminders'
[17:53] <fginther> balloons, but it does complain about an import error "could not import package reminders: No module named 'reminders'"
[17:53] <balloons> fginther, right.. so it seemed like perhaps the module was misnamed somewhere
[17:55] <balloons> ok, so I'll work with the idea the issue is on this end, ty
[17:56] <fginther> balloons, jenkins also thinks this is a python3 test suite
[17:56] <balloons> fginther, all the core apps should be at this point
[17:57] <fginther> ok
[17:57] <balloons> mm.. are you still running the tests in jenkins as py2?
[17:58] <balloons> by default the desktop will run as py2, and the phone will run as py3 so that makes sense you would be running as py2.
[17:58] <fginther> balloons, no, jenkins detects 'python3' in the package dependencies and then runs with "python3 -m autopilot.run run -v -o /tmp/test_reminders.xml -f xml -r -rd /tmp/ reminders"
[17:58] <balloons> fginther, ohh.. nice :-)
[17:58] <fginther> balloons, if there is no python3 dependency, it will use py2
[17:59] <fginther> balloons, wait, why would the desktop test be different then the phone?
[18:00] <balloons> fginther, I'm not saying they are. I'm just saying I hit tat snag a couple weeks ago. Everything passed for me on the desktop but failed on my phone.. I realized I was running under python2 on the desktop, while the phone was running py3
[18:00] <fginther> balloons, ahh, got it
[18:00] <balloons> just doing autopilot run will grab the default, so ;-)
[18:01] <balloons> fginther, oO.. I do see the last successful run was with py2
[18:02] <balloons> fginther, looks like sometime on 4/24 you made the switch
[18:02] <davmor2> jhodapp: it already does :)  That was my point, if it's not meant to they maybe we should look at what is going on there :)
[18:02] <jhodapp> davmor2, that's news to me :)
[18:02] <fginther> balloons, actually looking at the MP, the python3 dependencies were added on 4/24
[18:02] <jhodapp> davmor2, does it resume when the calls ends too? :)
[18:03] <balloons> ohh.. sneaky, I missed that. ok so that's it
[18:03] <davmor2> jhodapp: no I think it just stops playback
[18:03] <jhodapp> davmor2, stops it or pauses it?
[18:03] <davmor2> jhodapp: pauses
[18:04] <davmor2> jhodapp: same as flipping between media player with a video and music player
[18:04] <jhodapp> davmor2, does the app pause/play button toggle correctly?
[18:06] <davmor2> jhodapp: right so currently, music plays, call starts ringing music pauses, call ends, but dialer app still has focus, if I switch back to the music app I can press play and it carry on where it left off
[18:06] <jhodapp> davmor2, ha, I have no clue how that's happening!
[18:06] <jhodapp> davmor2, I guess I'm just *that good* :)
[18:07] <jhodapp> anyway, obviously I'll figure it out as I need to add resuming for when the call ends
[18:07] <davmor2> jhodapp: I'm assuming the ringtone is being played by the system through media player maybe?
[18:07] <jhodapp> davmor2, right, that's actually it
[18:08] <jhodapp> davmor2, I forgot the ringtone would go through media-hub
[18:08] <davmor2> jhodapp: \o/
[18:08] <jhodapp> that's awesome :)
[18:09] <jhodapp> davmor2, right now anything that plays with media-hub simply pauses anything else that's playing in media-hub
[18:09] <jhodapp> davmor2, next step is to add various categories and to make it more nuanced
[18:10] <davmor2> jhodapp: yes so I'm wondering what would happen with alarms but that is a bit tricky right now cause you can't set alarms from the clock app currently for some reason :(
[18:10] <jhodapp> hmm interesting
[18:12] <davmor2> jhodapp: oh hang on alarms work from calendar let me try that instead
[18:15] <plars> rsalveti: so I asked rfowler to restore android, re-unlock and try to re-install an image on one of the mako devices that was not wanting to reboot into fastboot. Hitting some new weirdness. It looks like it got an oom during the flash and a lot of errors like: E:Error in select (Bad file number)
[18:15] <plars> rsalveti: https://pastebin.canonical.com/109474/ and https://pastebin.canonical.com/109475/ are interesting
[18:17] <rsalveti> I:Skipping execution of extendedcommand, file not found...
[18:17] <rsalveti> it seems it's not using the right recovery
[18:17] <rsalveti> or it failed in a bad way when setting the commands
[18:17] <rsalveti> no, it's the right recovery
[18:17] <rsalveti> Ubuntu Touch (CWM-based) Recovery v6.0.4.6
[18:18] <davmor2> popey: if you set a calendar appointment locally do you get an alarm for it?
[18:19] <davmor2> jhodapp: I might have to wait till the scheduled one tomorrow am
[18:19] <jhodapp> hehe ok
[  146.058538] Out of memory: Kill process 157 (ueventd) score 1 or sacrifice child
[18:20] <rsalveti> yeah, went really bad
[18:21] <rsalveti> plars: can you try it again to see if you can reproduce the crash?
[18:22] <rfowler> rsalveti: i've done it twice
[18:23] <rsalveti> rfowler: which android version did you use as base?
[18:23] <rfowler> rsalveti: 4.4.2
[18:26] <robru> i'm gonna take lunch, hopefully the spreadsheet calms down a bit while i'm out
[18:48] <davmor2> pmcgowan: bluetooth seems to be turning itself back on again, that was another bug that was fixed.  I wonder if the fixes got pushed upstream or not and we have undone all the good work from last release?
[18:50] <pmcgowan> davmor2, like we lost some distro patches?
[18:50] <pmcgowan> I suppose it could be
[18:51] <davmor2> pmcgowan: was just a thought after I noticed the bluetooth indicator was back on :)
[18:55] <pmcgowan> davmor2, thats weird behavior, you turn it off and the indicator immediately gets removed
[18:55] <davmor2> pmcgowan: always did, you can re-enable it via settings
[18:56] <pmcgowan> davmor2, I just think its odd, at least should have a transition
[18:56] <davmor2> pmcgowan: all the temporary indicators are on the left so technically I guess location should do the same only there is no way to re-enable it if you do
[18:57] <pmcgowan> davmor2, I would personally prefer they stay put, but perhaps one could have too many
[18:58] <davmor2> pmcgowan: you only need an alarm set to nearly hit the search section
[18:59] <davmor2> anyway eod for me, night all
[20:09] <thomi> hello slangasek and barry
[20:10] <barry> hi
[20:10] <slangasek> thomi: hi
[20:11] <slangasek> thomi: so I was talking to barry and trying to figure out https://blueprints.launchpad.net/ubuntu/+spec/core-1311-python3-roadmap... the stuff now marked as "TODO" was previously labelled "FUTURE", and I'm trying to figure out if these are supposed to be blockers for dropping python2 or not
[20:12]  * thomi looks
[20:12] <slangasek> since these are all pretty core pieces, I can't figure out how they were *not* blockers previously
[20:12] <slangasek> but that seems to be how xnox labelled them
[20:13] <thomi> you're referring to the TODO section in the whiteboard?
[20:13] <barry> thomi: yep
[20:14] <barry> thomi: well, of the ones INPROGRESS and TODO, which are blockers for dropping py2, and are there any we are missing?
[20:14] <thomi> hmmm
[20:14] <thomi> so, yes, they're blockers for dropping py2 support from the image
[20:15] <thomi> the only way I know of to detect if there are any missing is to look at the list in the smoke test dashboard
[20:15] <barry> thomi: which url would that be?
[20:15] <thomi> barry: http://ci.ubuntu.com/smokeng/utopic/touch/flo/7:20140501.1:20140501/7832/ for e.g.
[20:16] <thomi> some of those can be discounted of course.
[20:16] <thomi> 'security', 'default' etc
[20:16] <slangasek> xnox: is there some reason we're missing why things like the dialer_app were marked as not blockers for python2?
[20:16]  * barry was going to discount the non-green ones ;)
[20:17] <thomi> suggestion: We take everything not ported to py3 and make it depend on autopilot-touch-legacy
[20:17] <thomi> that way we can use rdepends on that package to track our porting completion
[20:17] <thomi> but I guess we might just port them before then :)
[20:17] <barry> thomi: yeah
[20:18] <barry> i'll just re-iterate: porting is the easiest part of all this
[20:18] <slangasek> I think that's actually a good idea; that should be an easy change to get merged everywhere
[20:18] <slangasek> and once the dep is added, we can unseed autopilot-touch-legacy
[20:19] <thomi> We'd like to drop py2 support from the autopilot-touch package ASAP, ideally mid-late next week
[20:19] <thomi> I wonder if we could change that dependency before then...
[20:19] <barry> +1
[20:19] <barry> well, again, it's just been difficult getting any change to be reviewed, siloed and landed
[20:19] <slangasek> there's no reason that shouldn't be doable
[20:20] <thomi> Landing a packaging change should be easier than landing a code change
[20:20] <slangasek> barry: can you please verify that https://blueprints.launchpad.net/ubuntu/+spec/core-1311-python3-roadmap has the complete list?
[20:21] <thomi> also, once we have this in place, there'll be an extra incentive to port to python 3: you won't get any of the new autopilot hotness while you depend on the -legacy packages
[20:21] <barry> slangasek: sure, i will review the smoketest list (and CoreApps?) and make sure we have everything under todo.
[20:21] <slangasek> thanks
[20:22] <slangasek> once we have that list, we can divide and conquer adding the deps
[20:22] <barry> slangasek: i think we will need you to push at a higher level to get mps reviewed and on the train
[20:22] <slangasek> yep, I will
[20:22] <slangasek> this plan should also be announced on ubuntu-phone
[20:23] <barry> cool.  okay, give me 10m or so and i'll review the full list.  i'll update the blueprint when i have the data
[20:23] <barry> slangasek: i did send a message out to the mlist yesterday which touched on most of this (not the last bit about the deps)
[20:24] <slangasek> barry: well, you buried it in a landing team thread... :)
[20:24] <slangasek> we need an announcement
[20:24] <barry> ok
[20:24] <slangasek> here's what it needs to message:
[20:25] <slangasek> - python2 is going away; python2 is not allowed for any new test suites
[20:25] <slangasek> - packages that currently have python2 deps will need an explicit dependency on autopilot-touch-legacy
[20:25] <slangasek> - once the set of packages depending on autopilot-touch-legacy is gone, autopilot-touch-legacy (and python2) are also gone
[20:26] <slangasek> - so if you ignore both of points 1) and 2) above, you get to keep both pieces
[20:26] <thomi> (maybe) also add that 'autopilot-touch' will (soon) pull in py3, not py2 ?
[20:27] <ahayzen> plars, ping
[20:27] <plars> ahayzen: hi
[20:27] <ahayzen> plars, i've just got a fix to the UITK landed into staging, and was wonder how long the new merging structure takes for this to land into an image?
[20:28] <barry> slangasek: the only part i didn't understand was "- so if you ignore both of points 1) and 2) above, you get to keep both pieces"
[20:28] <ahayzen> plars, this is the mp https://code.launchpad.net/~andrew-hayzen/ubuntu-ui-toolkit/fix-swipe-delete-002/+merge/217338
[20:28] <plars> ahayzen: that might be a better question for robru
[20:29] <ahayzen> plars, cool thanks for ur help :)
[20:29] <slangasek> barry: i.e.: we are not responsible for making sure no one adds new python2 test suites without a dependency, the developers themselves are
[20:29] <plars> if it's landed though, I would think it should be in the next image, so probably tomorrow?
[20:29] <barry> slangasek: ah.  if you don't fix it you buy it :)
[20:29] <slangasek> thomi: well, we can provide whatever additional details we like in the message, but I think the above four points are the key things we need to communicate to devs
[20:29] <ahayzen> plars, ah cool, i was just wondering as before packages were periodically made
[20:30] <thomi> slangasek: ack
[20:30] <barry> slangasek: ack
[20:42] <robru> ahayzen, hey, the "periodically made" packages (aka daily_release) has been shut off since december, now we're doing CI Train, in which you have to ask for releases at the landing spreadsheet, but it's being a bit goofy today. consult your manager for the full procedure
[20:44] <ahayzen> robru, ah i see, i'm a community contributor to the music-app and a patch we need has landed in the UITK staging so do i need to request a release or will it happen automatically?
[20:51] <robru> ahayzen, ah, community. ok. in that case I think you need to go through popey for a release.
[20:51] <robru> core apps are a bit different. I mostly just deal with canonical-internal projects.
[20:51] <popey> hmm?
[20:51] <ahayzen> robru, ok thanks :)
[20:51] <popey> robru: this is a toolkit landing, not music-app
[20:51] <robru> popey, derp, yes
[20:52] <robru> ahayzen, sorry, got my wires crossed there.
[20:52] <ahayzen> robru, no problem
[20:52] <robru> ahayzen, so for uitk you need to go through bzoltan
[20:52] <ahayzen> robru, ok thanks for ur help :)
[20:54] <robru> ahayzen, oh I just looked at your MP, it's already merged into their staging branch. in that case I guess they would release it sooner or later. not automatically, but eventually
[20:55] <ahayzen> robru, cool thanks, is there any place community members can see/track the CI train?
[20:56] <robru> ahayzen, https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AuDk72Lpx8U5dFlCc1VzeVZzWmdBZS11WERjdVc3dmc&usp=sharing&pli=1#gid=0 i believe the spreadsheet is public, however it's very information-dense so it might be a little overwhelming ;-) (uh, also it's gone totally haywire today and is not to be trusted one bit, but generally that's where you'd go to check the status of landing tasks)
[20:57] <ahayzen> robru, awesome thanks
[20:59] <xnox> slangasek: only the clicks are blockers, the deb based ones are not.
[20:59] <xnox> slangasek: as to test the deb based apps, one needs to switch the image into RW mode and install debs system wide -> and thus can pull legacy autopilot.
[20:59] <xnox> slangasek: at the time "futurum" only had .deb based tests.
[21:00] <xnox> slangasek: however since that list was created some of them got converted into clicks.
[21:00] <xnox> barry: ^
[21:00] <slangasek> xnox: ok
[21:00] <xnox> slangasek: to drop python2 support in autopilot upstream, all of them are blockers.
[21:00] <slangasek> xnox: how do I see which ones have been cliquified?
[21:00] <xnox> slangasek: adb shell click list
[21:01] <slangasek> xnox: hum, the only blocker for the latter is that any remaining debs which need python2 declare a dependency
[21:01] <xnox> slangasek: which they must, per-policy. And python-autopilot as well for that matter.
[21:02] <slangasek> xnox: yes, so if that's the case, autopilot doesn't have to keep python2 upstream... so the splitting it off to a branch is ok
[21:02] <xnox> slangasek: or that, yes.
[21:12] <robru> plars, what were your thoughts on the image build? I did get rsalveti to re-enable the cron job so I'm expecting an image build in ~5 hours. That work for you?
[21:13] <plars> robru: sure
[21:13] <robru> great
[21:13] <plars> robru: the results ought to come a bit faster this time too, thanks to something cool that doanac just merged :)
[21:13] <robru> nice
[21:14] <robru> plars, oh, can you set the known issues to say that the spreadsheet is going crazy and the CI-SNCF bot is not to be trusted?
[21:14] <plars> robru: that will be pretty late in my time zone so I probably won't see it finish, but I might with the speed improvements. Either way, I'll try to check on things before falling asleep.
[21:14] <robru> plars, cool
[21:15] <plars> robru: that work?
[21:15] <robru> plars, perfect, thanks ;-)
[21:27] <slangasek> xnox: I don't see online_accounts_ui as either a .deb or a click; is this ubuntu-system-settings-online-accounts ?
[21:29] <slangasek> xnox, barry, thomi: with the exception of online_accounts_ui that I'm not sure about, I've confirmed that all of the remaining 'TODO's listed there are still .debs, so are not blockers for pulling python2 off the image
[21:30] <barry> slangasek: ack.  here are the list of clicks on a pristine utopic image:
[21:30] <barry> com.ubuntu.calculator
[21:30] <barry> com.ubuntu.calendar
[21:30] <barry> com.ubuntu.camera
[21:30] <barry> com.ubuntu.clock
[21:30] <barry> com.ubuntu.developer.webapps.webapp-amazon
[21:30] <barry> com.ubuntu.developer.webapps.webapp-ebay
[21:30] <barry> com.ubuntu.developer.webapps.webapp-facebook
[21:30] <barry> com.ubuntu.developer.webapps.webapp-gmail
[21:30] <barry> com.ubuntu.developer.webapps.webapp-twitter
[21:30] <barry> com.ubuntu.dropping-letters
[21:30] <barry> com.ubuntu.filemanager
[21:30] <barry> com.ubuntu.gallery
[21:30] <barry> com.ubuntu.music
[21:30] <barry> com.ubuntu.notes
[21:31] <barry> com.ubuntu.shorts
[21:31] <barry> com.ubuntu.stock-ticker-mobile
[21:31] <barry> com.ubuntu.sudoku
[21:31] <barry> com.ubuntu.terminal
[21:31] <xnox> slangasek: how did you verify they are all ported to python3? click list --manifest -> should have autopilot dir key for each one (if there are autopilot tests for a given click)
[21:31] <barry> com.ubuntu.weather
[21:31] <barry>  
[21:31] <barry> (that's the output of adb shell click list)
[21:31] <barry> i'm now going through and correlating with existing mps and ports
[21:31] <xnox> barry: can you pastebin $ adb shell click list --manifest ?
[21:32] <barry> http://paste.ubuntu.com/7375775/
[21:32] <xnox> slangasek: also e.g. there are "extra" scripts that CI use that rely on python-evdev and are in python2 only. Which is the reason why autopilot upload dropping python2 support was reverted by asac+landing team
[21:32] <xnox> late in trusty
[21:32] <slangasek> xnox: I did not verify they are ported to python3 at all, I verified they are all .debs
[21:32] <barry> xnox: that was unity7
[21:32] <slangasek> xnox: which, per above, means they are not a blocker for removing python2 from the image
[21:33] <xnox> barry: so why do we need autopilot-touch to use python2 on touch image which does not have unity7?!
[21:33] <thomi> barry: you mean unity 8?
[21:33] <xnox> camera-app click -> does not declare python3 compat
[21:34] <barry> xnox: we don't but it got reverted while we were at pycon and nobody asked us ;)
[21:34] <xnox> gallery-app click -> does not declare python3 compat
[21:34] <xnox> barry: asac and other people were talking to me, and i did ask them to seed python2-autopilot on touch images, instead of uploading autopilot revert.
[21:34] <barry> thomi: i'm thinking of unity7 requiring python-compizconfig which won't be ported to py3
[21:34] <xnox> barry: imho autopilot-touch package should die and those deps be seeded via ubuntu-touch seeds as needed.
[21:35] <thomi> barry: yes, but we've solved that problem, and that's for desktop only
[21:35] <bschaefer> hey anyone running up to date 14.10 unity, could you try ctrl+alt+t. I'm seeing a very delayed result (30 seconds between terminals opening)....
[21:35] <thomi> so not germaine to this conversation :)
[21:35] <barry> thomi: right
[21:36] <xnox> barry: slangasek: camera-app, gallery-app, notes-app, stock-ticker-mobile-app, sudoku-app -> are all clicks, and do not declare that their tests are python3 compatible from barry's paste http://paste.ubuntu.com/7375775/
[21:36] <xnox> thus if we drop python2 form the image today, one would not be able to test above in RO mode.
[21:36] <veebers> bschaefer: works fine for me (i'll just dist-upgrade to make sure it's most recent)
[21:36] <bschaefer> veebers, dam my machine...
[21:36] <slangasek> xnox: yes, and that's not what I'm talking about
[21:37] <bschaefer> veebers, i got angry and pressed it 30-100 times, and now i just randomly get terminals popping up
[21:37] <bschaefer> veebers, thanks!
[21:37] <barry> xnox: gallery, camera, notes all have mps waiting
[21:37] <bschaefer> at lease its not a regression
[21:37] <slangasek> xnox: those are the ones listed in the 'INPROGRESS' section on the blueprint
[21:37] <barry> xnox: i think you said stock-ticker is ported right?
[21:37] <xnox> slangasek: ok, then i'm not so sure what you were after then. Ah, right. yea.
[21:37] <barry> which leaves sudoku as the sole blocker not yet in progress
[21:37] <xnox> barry: ported, all AP tests pass on the desktop, all AP tests fail on mako.
[21:37] <xnox> barry: not released.
[21:37] <veebers> bschaefer: heh :-) I'm glad my keyboards are built like bricks considering the amount of times I do something similar
[21:38] <slangasek> xnox: this goes back to barry having changed the label on the section that you had identified as not-blockers, leading to confusion about whether they were blockers :)
[21:38] <xnox> slangasek: oh, right, so then blueprint is up-to-date =)
[21:38] <bschaefer> veebers, haha, i agree!
[21:38] <slangasek> xnox: then you said "some of the .debs got moved to clicks in the meantime", and I was confirming that none of the ones currently listed there have been
[21:38] <xnox> slangasek: sans the miss-titles =)
[21:38] <barry> xnox: so then stock-ticker is a blocker, but it's a ported blocker :)
[21:39] <xnox> barry: one would think ported blockers ain't blockers =))))
[21:39] <barry> xnox: well, if the tests are failing and it hasn't been published, that's a problem right?
[21:40] <barry> let me rearrange that section
[21:40] <xnox> barry: as far as i can tell stock-ticker tests never passed, and stock-ticker is not a release image criteria as per ci.ubuntu.com
[21:41] <xnox> cihelp - are all pre-installed clicks are image promotion blockers? e.g. is stock-ticker being considered?
[21:41] <cjohnston> xnox: that sounds like a question for the landing team, not for CI
[21:41] <xnox> cjohnston: thanks.
[21:42] <xnox> asac: are all pre-installed clicks are image promotion blockers? e.g. is stock-ticker being considered?
[21:42] <josepht> xnox: I think asac is on holidays :)
[21:42] <slangasek> correct
[21:42] <xnox> josepht: ok, didn't know =)
[21:42] <slangasek> xnox: why the question about blocking promotion?
[21:43] <slangasek> landing the python2 removal should introduce no regressions in any of the test suites
[21:43] <slangasek> anything less than that is not going to work
[21:43] <plars> xnox: does stock ticker have tests? it's not in the smoke runs at the moment
[21:43] <xnox> slangasek: whilst stock-ticker is a click, it is a community app, and thus no RO image testing is executed against it, only .deb based.
[21:43] <xnox> slangasek: thus removing python2 from the image will not affect stock-ticker, nor image stats.
[21:43] <slangasek> xnox: so, its .deb should continue to depend on autopilot python2
[21:44] <xnox> plars: it does have tests, they have never passed however, as far as i can tell.
[21:44] <xnox> plars: also i don't know if any jenkins actually execute tests against it.
[21:44] <plars> xnox: :(
[21:44] <plars> xnox: I know we don't in smoke, and that's probably why it was never asked for
[21:45] <xnox> plars: which jenkensii do core-apps live at?
[21:45] <plars> xnox: but really the tests should get fixed up if it's going to be a preinstalled app I think
[21:45] <barry> well, i updated the blueprint https://blueprints.launchpad.net/ubuntu/+spec/core-1311-python3-roadmap
[21:45] <slangasek> plars: of course they should; but that's not the problem we're working on
[21:45] <xnox> plars: community lead developer is busy/missing-in-action i did fix up some, more are still needed.
[21:46] <fginther> xnox, core-apps jenkins is done here: http://91.189.93.70:8080/
[21:46] <barry> i'm glad this is all so crystal clear :)
[21:46] <xnox> fginther: does it have dns-name?
[21:46] <fginther> xnox, nope
[21:46] <slangasek> fginther: ... that's a public IP.  Isn't the real jenkins internal?
[21:47] <fginther> slangasek, the core-apps are processed on a seperate jenkins instance that is public
[21:47] <xnox> fginther: no utopic, and still configs for precise, quantal, raring and saucy?
[21:47] <slangasek> ah hmm
[21:47] <xnox> fginther: let me assign dns name for it - core-apps.surgut.co.uk would do?
[21:48] <slangasek> xnox: .chiark.greenend.org.uk or it doesn't count
[21:48] <fginther> xnox, I'm still working on the transition to utopic, but it should be done in another day or two
[21:48] <xnox> slangasek: i envy the day when i can get an account on that machine!
[21:48] <slangasek> xnox: step 1) move to Cambridge, step 2) travel back in time 20 years?
[21:48] <xnox> slangasek: i wonder if i need to complete a course in cambridge or something to get there.
[21:49] <barry> xnox: i'm actually surprised that filemanager has an x-test key in its manifest because afaict, its tests weren't ported.  but maybe they worked by accident anyway
[21:49] <xnox> barry: during "no way to build click" -> "cmake click/deb building" transition, x-test key was initially added for all apps.
[21:49] <xnox> barry: only later we backtracked to declare that key a flag for python3 compatibility
[21:50] <slangasek> xnox, barry: are you guys just eyeballing the --manifest output, or do you have a pipeline to spit out the list we care about?
[21:50] <xnox> slangasek: mit.edu email alias might be easier to get then =)
[21:50] <barry> slangasek: i'm just eyeballing the manifest
[21:50] <slangasek> ok
[21:50] <slangasek> xnox: if you invent time travel, I'm sure MIT will also be happy to give you an email address
[21:50] <barry> xnox: then is that key a reliable indicator for whether the tests have been ported yet, i.e. whether porting them is a blocker for dropping py2?
[21:51] <xnox> slangasek: yeah, we want time travel -> it doesn't really matter when we invent it ;-)
[21:51] <slangasek> barry: if the key is set, it means the tests are /being run/ under python3, doesn't it?
[21:51] <xnox> barry: well, ci.ubuntu.com uses that key to run things under python3.
[21:51] <slangasek> the whole point of that key is to trigger this behavior change
[21:51] <slangasek> so either no porting was required, or they're broking and nobody cares. :P
[21:51] <xnox> cjohnston: plars: fginther: is that actually true? ->  ci.ubuntu.com uses that key to run things under python3.
[21:51] <barry> slangasek: okay, i guess for our purposes, that's equivalent :)
[21:52] <xnox> phablet-test-run sure uses that key.
[21:52] <xnox> and phablet-click-test-setup.
[21:52]  * xnox wrote those patches....
[21:52] <plars> xnox: I think it's phablet-test-run handles that for the most part
[21:52] <slangasek> note that http://s-jenkins.ubuntu-ci:8080/job/filemanager-app-click/ shows success
[21:52] <fginther> xnox, yes, ci.ubuntu.com does that... plars beat me to it
[21:52] <plars> there's *one* case (for custom image tests) where we have to do it ourselves, but it's an oddball
[21:53] <slangasek> how do we determine from the log if the tests are being run under python2 or python3?
[21:53] <barry> slangasek: when i run autopilot{,3} it tells you where the tests are imported from, but i think that's only for deb tests.  i'm not sure click tests tell you
[21:53] <xnox> slangasek: that job builds a click, not actually runs the tests.
[21:54] <slangasek> xnox: ah; just figured that out
[21:54] <thomi> barry: autopilot prints that no matter where the tests come from
[21:55] <barry> thomi: what i mean is that autopilot tells you it imported the tests from, e.g. /usr/lib/python3/dist-packages, but that path isn't relevant for click tests
[21:55] <xnox> barry: in phablet-test-run against a click, the tests always will be imported from '.'
[21:55] <barry> xnox: right, so how do we *know* it's running the py3 tests?
[21:55] <xnox> barry: or maybe it will print ./legacy-py2/ for py2 tests ?!
[21:56] <xnox> barry: i use ps output to verify =)
[21:56] <barry> slangasek: i'm sorry, i think i keep stepping on your blueprint toes.  i will stop editing it until you give me the all clear
[21:56] <xnox> barry: maybe i should add an announce in the logs.
[21:56] <slangasek> barry: you just need to reload the page... :)
[21:56] <barry> xnox: yes.  even printing sys.executable would be great
[21:57] <slangasek> xnox: yes, please
[21:57] <barry> slangasek: i killed your .debs comment :(
[21:57] <slangasek> barry: I know - readded, please refresh the page before editing again ;)
[21:57] <xnox> slangasek: barry: clearly we should use google-docs for blueprints....
[21:57] <xnox> =)
[21:58] <slangasek> xnox: make me a spreadsheet
[21:58] <barry> xnox, slangasek, thomi are we in agreement then that to drop py2 we need to: 1) land the mps already in the ==BLOCKERS== section; 2) port sudoku; 3) celebrate
[21:59] <xnox> barry: 3) go to malta =)
[21:59] <xnox> barry: oh, wait. tsh
[21:59] <thomi> heh
[21:59] <barry> xnox: look for my spirit animal
[21:59]  * xnox looks behind the shoulder
[22:00] <barry> xnox, see that unicorn? :)
[22:00] <slangasek> barry: I think the list of blockers on the blueprint is accurate; your summary omits some of the finer detail :)
[22:00] <xnox> i think this is the first animal where i refer to the release by the animal instead of adjective.
[22:01] <barry> slangasek: like, exactly how we're going to celebrate? :)
[22:03] <slangasek> barry: well, I'm gonna celebrate on the beach with a malta mai tai ;)
[22:03] <slangasek> barry: why is filemanager "other in progress" rather than a blocker?  It's a click
[22:04] <xnox> slangasek: because it works?! http://ci.ubuntu.com/smokeng/utopic/touch/manta/7:20140501.1:20140501/7831/
[22:04] <barry> slangasek: it has an x-test key
[22:04] <slangasek> oh; "it works" is a good reason
[22:05] <slangasek> barry: so what does that MP have to do with this blueprint?
[22:05] <barry> i'm frankly suprised it works though
[22:06] <barry> actually no
[22:06] <xnox> barry: from https://jenkins.qa.ubuntu.com/job/utopic-touch-manta-smoke-daily/13/consoleFull (and click to see full log)
[22:06] <xnox> it shows that ubuntu_filemanager is pushed as python3.
[22:06] <barry> the diff in the code just cleans up a few things, and the other changes are probably only relevant for deb builds
[22:06] <xnox> plars: surprisingly stock_ticker tests are also pushed to the image
[22:06] <barry> i.e. d/control and t/a/CMakeLists.txt
[22:06] <slangasek> aha
[22:07] <plars> xnox: by phablet-click-test-setup I suppose
[22:07] <plars> that's good
[22:07] <xnox> plars: right. can it be actually executed please?
[22:07] <plars> xnox: I'll look at adding it, but didn't you say they all fail?
[22:08] <xnox> plars: yes. but at the moment, because those results are not published at all there is no attention to resolve them.
[22:08] <xnox> plars: yet we demo phones everywhere with stock-ticker which people do try out.
[22:08] <barry> slangasek: i'm going to move the OTHER IN PROGRESS to TODO (.debs)
[22:09] <xnox> plars: "3. We will not hide problems" -> either we need to fix the app or the tests or kick the stock-ticker of the pre-installed on the image.
[22:09] <slangasek> barry: please just drop filemanager from the blueprint altogether, if we already have click tests running under python3 this doesn't seem to be related to the transition
[22:10] <slangasek> barry: or rather, wrt the blueprint I think filemanager is "done"
[22:10] <plars> xnox: agree, but if it's that bad, perhaps it should be kicked out rather than adding the tests
[22:10] <barry> slangasek: ok
[22:11] <xnox> plars: but i do need it to be running _somewhere_ at the moment the ci tests for stock ticker do not run /anywhere/
[22:12] <xnox> plars: can it be added to jenkins without pushing results to ci.ubuntu.com? or something like that?
[22:12] <slangasek> or having it marked xfail
[22:13] <plars> fginther: is there some earlier point where it can be added for landing? I think that would only run if there was a change
[22:13] <plars> otherwise, we can run them in smoke, and they run on every image - which would probably get it the most visibility
[22:14] <plars> xnox: who in on the hook to make sure they get fixed? you? balloons?
[22:14] <fginther> plars, xnox, I can add the stock-ticket tests to the core-apps jenkins desktop testing
[22:15] <fginther> plars, xnox, I also have a plan to add click test to the click build jobs that run on s-jenkins
[22:15] <xnox> plars: who is on the hook -> product owner who decided which clicks are preinstalled, or delegate as appropriate.
[22:16] <balloons> are we speaking of stock ticker or file manager?
[22:16] <xnox> balloons: stock ticker.
[22:19] <xnox> plars: i guess it would be a landing team's decission.
[22:21] <slangasek> I don't think it's the landing team who decides if it's preinstalled
[22:21] <slangasek> the landing team can specify the requirements for promoting a new version to be preinstalled, but it's someone else who decides whether to drop it from the image vs. fixing it
[22:28] <pmcgowan> slangasek, I may be able to help there, is something busted with stock ticker?
[22:29] <slangasek> pmcgowan: apparently it has tests that have never passed and aren't being run
[22:29] <pmcgowan> slangasek, let me check on it, not sure how it got into the image anyway
[22:29] <slangasek> pmcgowan: so someone should decide if they should be run, and the failures driven to zero; or if it should be removed from the image - I'm happy for you to be the decider :)
[22:29] <balloons> afaik, stock ticker is not a core core app.. in other words, it is not meant to be pre-installed
[22:30] <pmcgowan> yeah
[22:30] <xnox> fginther: core-apps.surgut.co.uk should be starting to go live across dns networks -> e.g. propagated to usa already.
[22:30] <xnox> balloons: is "core core app" ~= "system app" ?
[22:31] <balloons> veebers actually worked on stock tickers tests last year and we just finally rejected the MP.. I'm not sure of the state but I know work was done to make it work with ap 1.4
[22:31] <slangasek> xnox: ... "across dns networks"?  are you using a DNS CDN? :)
[22:31] <xnox> balloons: as in dialer is a system app.
[22:31] <balloons> xnox, yes.. community developed system app :-)
[22:31] <xnox> slangasek: yeah, the term i used doesn't make sense -> i mean this https://www.whatsmydns.net/#A/core-apps.surgut.co.uk
[22:31] <veebers> balloons: I saw that :-), not sure if any comment is required from my end?
[22:32] <balloons> veebers, yea, I wanted to see what the dev would say and it sounds like he's not interested for whatever reason. There's definitely some development work that needs done.
[22:32] <slangasek> xnox: did you make the mistake of loading that page before you'd added it to the authoritative DNS servers? :) No server should have negatively cached a DNS record it had never been asked for
[22:34] <veebers> balloons: aye, agreed
[22:34] <xnox> slangasek: i did not know that =) i believe it's been added to authoritative dns servers first, but  i actually have no ultimate control, so it might not have been.
[22:34] <balloons> veebers, on the mocking stuff you did, well that is definitely handy
[22:35] <veebers> balloons: yeah, I utilised some existing code for that, there was talk about formalising it to make it easily usable across projects.
[22:36] <veebers> I seem to recall the result was "It's easier to copy the pattern due to it's simple nature" or something along those liens
[22:36] <balloons> veebers, yes that
[22:36] <balloons> 's what I remember as well
[22:38] <pmcgowan> slangasek, pretty sure we should just drop that app, is there any urgency or is tomorrow ok?
[22:38] <slangasek> pmcgowan: no urgency at all
[22:38] <pmcgowan> ok
[22:56] <slangasek> thomi, xnox, barry: why is a separate autopilot-touch-legacy package needed at all?  AFAICS the only thing autopilot-touch does is apply some apparmor rules (which should be interpreter-independent), and pull in dependencies - and for python2 the latter can be sidestepped, the affected packages already depend on python-autopilot
[22:58] <slangasek> except for webbrowser-app-autopilot, which has a transitive dep via unity8-autopilot, and mediaplayer-app, which is just missing a dependency and can be fixed
[22:59] <xnox> slangasek: i want to drop autopilot-touch package full stop, and just seed the needed bits.
[23:00] <xnox> slangasek: ideally all we need on the image is libqt5autopilotsupport.so (or whatever it is) python3-autopilot / python2-autopilot can be pulled in with all the dependencies, the same way we push actual tests to the image.
[23:00] <xnox> slangasek: it's pure python after all.
[23:00] <thomi> I don't have a problem dropping the -touch and -desktop metapackages, but they were created for a reason, and I think that reason is still valid, so I'd be cautous...
[23:01] <thomi> ugh, excuse my typing today :-/
[23:02] <xnox> thomi: we have metapackages already, mananaged by seeds. So for now, i'd want to seed those packages in proper ubuntu-touch / ubuntu-desktop seeds. Get those build and published, and then drop the autopilto-metapackages.
[23:02] <xnox> thomi: why was qt4 and qt5 bundled together?
[23:02] <xnox> thomi: i see evidence that they used to be separate library modules.
[23:02] <thomi> xnox: you mena in libautopilot-qt?
[23:02] <xnox>  / packages.
[23:02] <xnox> thomi: yeah.
[23:02] <thomi> *mean
[23:03]  * thomi tries to remember
[23:05] <thomi> hmmm, I think.. probably because there was no strong argument not to ship them in the same package at the time. IIRC, at the time they didn't have the dependencies they do now
[23:07] <xnox> thomi: cause at the moment it's undesirable to pull-in qt4 & X on touch images.
[23:07] <thomi> xnox: I understand. I don't have an objection to splitting that into libautopilot-qt4 and libautopilot-qt5 - obviously some work would have to be done to make sure we pulled in the correct packages everywhere
[23:08] <xnox> thomi: ack. let me proposed a patch to do the split the right way.
[23:08] <xnox> with a migration / transition path.
[23:08] <thomi> you'd also either need libautopilot-qt-common *or* to change the way the libraries work, at the moment
[23:08] <thomi> -common would contain libqttestability.so (or whatever it's called)
[23:09] <thomi> which is what apps actually load
[23:09] <thomi> and it then dlopen's the appropriate driver for whatever qt version the app is running
[23:09] <xnox> oh that thing =) yeah.
[23:09] <xnox> thomi: i'll work on it.
[23:09] <thomi> ahh, that reminds me - *that's* why it didn't have the deps previously that it does now
[23:10] <thomi> because if an app is loading the library, it must already have those qt libraries installed, or it wouldn't get that far
[23:10] <thomi> but I guess that changed at some point
[23:12] <xnox> thomi: yeah at the moment libautopilot-qt has depends on both qt stacks, so you are saying all of those should be generated as depends or even suggests instead?
[23:12] <xnox> thomi: we can certainly change packaging to do that.
[23:13] <slangasek> xnox: so AIUI you're agreeing with me that autopilot-touch-legacy is not needed, and I can ignore it in favor of a dependency on python-autopilot where needed?
[23:13] <slangasek> (mediaplayer/webbrowser)
[23:13] <xnox> slangasek: yes, i have no idea where "autopilot-touch-legacy" came from, it is entirely redundant.
[23:13] <xnox> i maybe missing discussions around that.
[23:14] <slangasek> do we know what exactly was using python-evdev?
[23:14] <thomi> hang on guys
[23:14] <xnox> slangasek: sorry, i don't.
[23:14] <thomi> I might have missed something
[23:14] <thomi> the -evdev package is needed by all AP test suites running on touch
[23:15] <thomi> (obviously the python2/python3 package, as appropriate)
[23:15] <slangasek> hmm
[23:15] <slangasek> so
[23:15] <thomi> the autopilot-touch[-legacy] packages exist to pull in that dependency
[23:15] <slangasek> should python-autopilot depend on python-evdev directly?
[23:15] <thomi> it's not part of the main ap package because we don't want or need it on the desktop
[23:15] <xnox> thomi: python2 or python3? there were appearantly some scripts which where python2 only, maybe they just needed to change shebang instead of reintroducing python3 on the images?
[23:16] <thomi> slangasek: similarly, autopilot-desktop pulls in some X11 deps, because we don't want them on touch
[23:16] <thomi> I'm open to other/better ways of doing this, but that's the rationale behind those metapackages anyway
[23:16] <slangasek> thomi: the issue I'm seeing is that all the touch .debs today that use autopilot depend on python-autopilot, not on autopilot-touch; we should aim to eliminate the magic seeded dependency pulling in python-evdev "because everything needs it".  So if we shouldn't have python-autopilot depend on python-evdev (even though it's a cheap dependency), then we need to switch all of the python2 autopilot test packages to depend on autopilot-touch-legacy
[23:17] <slangasek> I would argue that python-autopilot Depends: python-evdev is a lot less work
[23:17] <slangasek> and even if the dependency is extraneous from the desktop's perspective, it shouldn't be harmful
[23:17] <xnox> thomi: instead python-autopilot must depend on python-evdev, and python3-autopilot should depend on python3-evdev.
[23:17] <xnox> thomi: why need an extra dependency in between?
[23:18] <xnox> thomi: similarly click.rules can move to libautopilot-qt package.
[23:18] <xnox> thomi: and seed all current autopilot-touch dependencies into ubuntu-touch seed.
[23:18] <thomi> slangasek: ok, I think I understand that. What baout the other way around? Do we eliminate the autopilot-desktop package  and add those deps to python*-autopilot as well?
[23:19] <xnox> thomi: seeds are meant to be changed by core-devs only, not by anybody who can upload autopilot.
[23:19] <slangasek> thomi: if the autopilot-desktop package pulls in X, then no
[23:19] <slangasek> xnox: seeds are meant to be changed by the seed owners, which are not always core-dev
[23:19]  * barry is back from dinner
[23:19] <barry> xnox, slangasek https://code.launchpad.net/~barry/sudoku-app/py3autopilot/+merge/217990
[23:20] <xnox> slangasek: right, that.
[23:20] <thomi> slangasek: OK, so my *only* objection then is that we'd have an asymmetrical system - which I suppose is a cosmetic objection at best  :)
[23:20] <xnox> thomi: true. for now. in the future everything will use qt5 and thus not require any X stuff?
[23:21] <xnox> thomi: the python3-autopilot can e.g. Recommend or Suggest X.org stuff.
[23:21] <thomi> xnox: it's nothing to do with qt, it's more to do with input methods
[23:21] <slangasek> thomi: we may come up with a better answer for the desktop side later... but I wouldn't like the symmetry question to cause us to have things more complicated on the phone
[23:21] <xnox> thomi: ah, ok. Well when everyhting uses qt5/mir?
[23:21] <thomi> slangasek: fair enough
[23:23] <robru> bfiller_afk, hey, I'm trying to reconcile the discrepancies between the spreadsheet and the assigned silos. one of the requests you made that got lost was already in silo 4. I tried to recreate it but I have no way to verify it. if you could take a look at spreadsheet line 50, correct the description, and confirm the MP urls, that'd be great
[23:23] <xnox> slangasek: thomi: is it ok to move apparmor click.rules from autopilot-touch to libautopilot-qt ?
[23:24] <xnox> or even to apparmor itself, given that we ship that preinstalled everywhere anyway.
[23:25] <thomi> xnox: slangasek: So, I'm concerned about the number of things we're talking about changing here. Moving apparmor rules is fine, except that, when they're not installed (for whatever reason), autopilot breaks
[23:26] <xnox> thomi: ack. and autopilot breaks without libautopilot-qt, no?
[23:26] <thomi> xnox: if you're testing a Qt app, yes
[23:26] <xnox> thomi: a click Qt app.
[23:27] <xnox> ?
[23:27] <thomi> xnox: uuuh, right.. well, one started in an apparmor containment thingy, to be precise
[23:27] <xnox> thomi: oh, so not at all related to click?
[23:28] <thomi> xnox: I believe some apps are started via upstart, not click, and they need it as well. I could be wrong though
[23:28] <xnox> thomi: in that case it might make sense to name it autopilotpy2.rules & autopilotpy3.rules and ship in both python-autopilots respectively?
[23:28] <xnox> thomi: or get it to be shiped in apparmor itself.
[23:29] <xnox> thomi: looking at the rule itself.
[23:29] <xnox> thomi: it appears that it must be shipped in python2 & python3 - autopilots. It's unrelated to clicks, and it's purely about confinments.
[23:29] <thomi> xnox: yup, I'd be happy with that
[23:31] <xnox> thomi: and horay, we are getting more balance =) as those rules legitimately can be needed on desktop as well.
[23:32] <thomi> :)
[23:32] <thomi> as long as we can land it without breaking everyone :)
[23:32] <xnox> thomi: 61-autopilot-uinput.rules is currently broken.
[23:32] <xnox> thomi: it's not shipped in python3 package, only in python2 package.
[23:33] <xnox> despite the good intentions.
[23:33]  * xnox ponders about autopilot-common package with uinput, apparmor rules + testability
[23:35] <xnox> thomi: how is click.rules used? as far as i can tell nothing looks into /usr/share/autopilot-touch/apparmor/click.rules?
[23:36] <xnox> def _handle_autopilot(adb, args):
[23:36] <xnox>     if args.dbus_probe == 'enable':
[23:36] <xnox>         rfile = '/usr/share/autopilot-touch/apparmor/click.rules'
[23:36] <xnox>         adb.shell('aa-clickhook -f --include=%s' % rfile)
[23:36] <xnox>     else:
[23:36] <xnox>         adb.shell('aa-clickhook -f')
[23:36] <xnox> in phablet config....
[23:38] <thomi> yeah
[23:38] <xnox> thomi: so it's more reasonable for that click.rule to move to click-apparmor and keep on shipping it at that legacy location.
[23:38] <xnox> thomi: since click-apparmor ships aa-clickhook tool.
[23:39] <thomi> xnox: I have a luncxhtime appt in town, and I need to leave the house pretty soon
[23:39] <xnox> thomi: no worries =) go, i'll file a bug report about this.
[23:39] <thomi> xnox: I'm happy if you want to make MPs against lp:~autopilot/autopilot/temp-dev
[23:39] <thomi> xnox: otherwise we can pick this up some other time
[23:50] <slangasek> against temp-dev?
[23:50] <xnox> slangasek: i'm thinking debdiffs to a bug report =)
[23:50] <xnox> slangasek: that way any lander can apply and merge it anyway they need it.
[23:51] <slangasek> xnox: "any lander can" != "some lander will"